Building a Security Capable Organization

The debate about medical information security tends to polarize into two broad perspectives. The media and privacy advocates argue that easy trafficking in medical information poses grave risks to patients’ privacy, a situation that the computerized patient record (CPR) only promises to exacerbate. CPR advocates argue to the contrary that the entire progress of health reform including improvements in maintaining patients’ privacy depends upon adopting electronic record keeping systems and their associated technologies such as universal health identifiers. How should a contemporary health care provider responsibly act in the face of such diverse and uneasily mediated positions? Congress and the Department of Health and Human Services will provide guidelines within the next two years thanks to a variety of medical record reform efforts underway. As with all such guidelines, nonetheless, health care providers will have to interpret and indeed go well beyond the legal requirements in order to meet their obligations to both their patients and themselves. In this paper we will present general principles and case examples of how health care providers might prepare themselves to become data security capable organizations; that is, organizations in which ensuring the security and confidentiality of medical information becomes incorporated into the every day working routines of all staff. Building a security capable organization requires institutionalizing a security surveillance process, not just implementing security measures.

Implementing a security surveillance process requires several steps, including:

1. Monitoring the changing legal and regulatory environment;

2. Enhancing patient understanding of the organization’s data security efforts, and;

3. Continuously updating data security policies, procedures and practices in light of changing mission.

Some of these tasks clearly fall under the responsibility of professional staff dedicated to managing medical records. When properly implemented, however, a comprehensive security surveillance process incorporates everybody including patients, all individual staff, an organization’s general administration and the data security team. Like universal precautions for infectious disease, maintaining the security of our organizations’ and patients’ valuable medical information should become simply part of how we do our jobs rather than another in an ever expanding list of onerous supplemental tasks. After having begun the process of data security surveillance, we will discover that we have created a new relationship with our “customers” in which we are accountable to them for our business practices in addition to our medical care. As we institutionalize the data security surveillance, we should coopt, not simply coerce our health care colleagues into the process.

Monitoring the legal and regulatory environment

Questions of medical privacy occupy center stage in the contemporary United States. Hardly a day goes by that the Washington Post, New York Times, or USA Today do not feature an article about some aspect of medical privacy. Opinion polls document that the American public regards the data management practices of most large organizations with great skepticism. In partial response to these and other expressions of public concern, President Clinton commissioned a task force on medical privacy as part of his health care reform efforts. Although the recommendations of the privacy task force died along with Clinton’s plan, federal legislators have incorporated some of their intent (particularly the requirement of federal medical privacy legislation) into the piecemeal approach to health care reform developed during the last three years. The Health Insurance Portability and Accountability Act of 1996 (HIPA) otherwise known as the Kennedy-Kassenbaum Act creates specific requirements for the Congress and the Department of Health and Human Services. Because of Kennedy-Kassenbaum, within two years the legal and regulatory environment for managing patient medical records will dramatically change. Either Congress will pass comprehensive medical privacy legislation or the Department of Health and Human Services will implement regulations requiring health care providers throughout the United States to adopt new policies, procedures and practices in managing medical information. DHHS must also lead the way by designing model rules to guide Congress and/or implement the laws it passes.

Under the rubric of “Administrative Simplification”, HIPA requires Congress to pass laws that “improve… the efficiency and effectiveness of the health care system by encouraging the establishment of standards and requirements for the electronic transfer of certain health care information” (PL ). In sections 261 through 264, HIPA calls for standards and laws for two circumstances, namely 1) the electronic interchange of financial and administrative data between health plans, healthcare clearinghouses and health care providers, and 2) maintaining the privacy of individually identifiable medical information. HIPA also establishes a timetable by which Congress and DHHS must act.

The HIPA Timetable - Enacted

Date Event

July 31, 1996 HIPA enacted

July 31, 1997 DHHS recommendations on confidentiality due

February 28, 1998 DHHS draft transaction standards due

August 21, 1999 Deadline for federal privacy legislation

Under the direction of the National Council on Vital Statistics, the Healthcare Finance Administration (HCFA) leads the DHHS effort to draft transaction and model privacy standards. By any stretch of the regulatory imagination, HIPA establishes an aggressive timetable for DHHS to draft, release for comment and recommend for adoption such a complex, extensive and important set of regulations. Although behind schedule, DHHS has made a valiant effort. New regulations are regularly released for comment in the Federal Register. As of August 3, 1998, the status of the various sets of recommendations is listed below.

The HIPA Timetable – Status as of August 12, 1998

Date Event

July 31, 1996 HIPA enacted

September 11, 1997 DHHS recommendations on confidentiality released

February 28, 1998 DHHS draft transaction standards

May 7, 1998 NOI: National Provider Identifier

May 7, 1998 NOI: Electronic Transaction Standards

May 7, 1998 NOI: Medical Code Set Standards

June 16, 1998 NOI: National Employer Identifier

July 6, 1998 White Paper: Unique Health Identifier – Individuals August 12, 1998 NOI: Security Standards to Protect Health Info

Pending NOI: Identifier for Health Plans

Introduced federal privacy bills, including

1) S 1360 (1995) “Medical Records Confidentiality Act of 1995”, Sen. Bennett

2) S. 1368 (1997) “Medical Information Privacy and Security Act”, Sen. Leahy

3) H.R. 1815 (1997) “Review of Protected Health Information by Subjects of the Information”, Rep. McDermott

4) H.R. 3900 (1997), “Consumer Health and Research Technology (CHART) Protection Act”, Rep Shays

5) H.R. 52, “Fair Health Information Practices Act”. Rep Condit

6) S. 1921 (1998), “Health care Personal Information Nondisclosure Act of 1998 or the “Health care PIN Act”

7) Miscellaneous provisions of other acts

To consult the text and follow the legislative status of each bill, go to the federal legislation website, http://thomas.loc.gov and search on “medical privacy”.

None of these bills is yet law; but, the DHHS recommendations on maintaining confidentiality of individually identifiable information both provides a model of what any federal law should address and stipulates what actual regulations will take effect if Congress fails to act. To consult the text of these recommendations as well as the existing draft regulations for electronic transactions, please consult the DHHS website, http://aspe.os.dhhs.gov/admnsimp/pvcrec/htm. You may also enroll to receive email notice of new posted draft regulations through this same website. A security capable organization will study, understand and begin to formulate responses to possible legislation on the basis of the DHHS recommendations on medical privacy. Although these recommendations do not exhaust the changes health care providers will have to make in response to upcoming legal and regulatory reforms, they will certainly constitute the foundation of any organization’s plan of action. For that reason, I will provide an overview of the recommendations now.

The DHHS Recommendations on Confidentiality of Individually Identifiable Information

The DHHS begins discussion of its specific recommendation by addressing their scope of coverage; that is, to whom, to what activities and to what information should the recommendations apply.

To whom do the recommendations apply? All health care providers, payers and others who receive health information without authorization (such as health oversight, public health and research organizations) should be subject to the new privacy legislation. Health service organizations are third parties who process health information from providers and payers as part of services rendered. The recommendations should apply to deceased persons for two years after death with specified rights being exercised on deceased’s behalf. Conventional rules apply to minors, people with power of attorney and people unable to act on own behalf. The recommendations should not apply to self-pay patients, prison inmates or detainees, liability insurers, life insurers, workers’ compensation carriers, or employers unless acting as payers or providers. Federal departments responsible for members, civilian employers and contractors of the military should develop their own regulations. The Department of Veteran’s Affairs should have the right to release information without authorization for internal departmental use only.

To what activities should the recommendations apply? The recommendations should apply to three general types of activities, including:

1) Any preventative, diagnostic, therapeutic, rehabilitative, maintenance or palliative care, counseling, service or procedure with respect to the physical or mental condition or functional status of a patient or affecting the structure or function of the body;

2) Any sale or dispensing of a drug, device, equipment or other item pursuant to a prescription, and;

3) Procurement or banking of blood, sperm, organs or any other tissue for administration to patients.

To what information should the recommendations apply? The recommendations should apply to any information, oral or recorded, in any form or medium, including demographic information that has the following characteristics, including:

1) relates to past, present, or future physical or mental health or conditions of a patient, the provision of health care to a patient, or the past, present, or future payment for the provision of health care to a patient;

2) is received, created, used or maintained by a health care provider in the ordinary course of business or practice of a profession, or by a health care payer, or received by entities receiving information under the provisions of the legislation without authorization, and;

3) identifies the individual, or with respect to which there is reasonable basis to believe that the information can be used to identify the patient.

In summary, the recommendations should apply to most people working in the health care business, to most of their patients, to almost everything they do that involves patients and almost all the information created, interpreted and stored thereby as a matter of federal law. Although important, the exceptions to coverage underscore rather than minimize the change we face in the health care business.

The DHHS articulates five basic principles and makes specific recommendations implementing each basic principle of confidentiality. In general, the recommendations increase restrictions on the release of information to third parties, expand obligations to explain and document information management practices to patients, and impose new penalties for breaches of patient confidentiality. The DHHS also tries to balance patients’ rights to confidentiality with society’s need for knowledge derived from aggregating confidential information in the context of public health efforts.

Five principles underlie the DHHS recommendations, including:

1) Boundaries: an individual’s health care information should be used for health purposes and only those purposes, subject to a few carefully defined exceptions;

2) Security: organizations to which we entrust health information ought to protect it against deliberate or inadvertent misuse of disclosure;

3) Consumer Control: Patients should be able to see what is in their records, get a copy, correct errors, and find out who else has seen them;

4) Accountability: Those who misuse personal health information should be punished, and those who are harmed by its misuse should have legal recourse, and;

5) Public Responsibility: Individual’s claims to privacy must be balanced by their public responsibility to contribute to the common good, through use of their information for important, socially useful purposes, with the understanding that their information will be used with respect and care and will be legally protected.

In order to implement these principles, federal law should therefore accomplish the following tasks, namely:

1) impose a legal duty of confidentiality on those who provide and pay for health care and on other entities who receive health information from them. This duty has an affirmative and a negative component. An affirmative duty should exist only to use or disclose health information as authorized by patient or required by law. No duty should exist to disclose information except to patients. The federal laws, moreover, should provide only a privacy “floor” thus supporting and maintaining other laws providing grater protection for patient confidentiality to remain in effect. Health information should moreover be used only for purposes compatible with and directly related to the original purposes for obtaining the information and for which health entities are authorized to disclose it. Please note: the DHHS directly addresses in this context the release to and use of health information by employers.

2) require security measures. The DHHS recommends requiring by federal law that health providers, payers and service organizations maintain reasonable and appropriate administrative, technical and physical safeguards to ensure the integrity and confidentiality of health information and protect it against threats, hazards or unauthorized disclosures.

The DHHS synthesizes the boundary and security principles in what one might call “The Rule of Minimum Disclosure”. Instead of releasing whole chunks of a patient’s record without regard to a requestor’s required use, organizations should in the future restrict all uses and disclosures, as practicable, to the minimum amount of information necessary to accomplish the purpose for which it is requested. In my opinion, this recommendation virtually requires adoption of the computerized patient record with its automated indexing and segmenting capabilities.

The DHHS recommends a complete overhaul in how health care providers and payers manage their patients’ access to and control over personally identifiable health information. They must strengthen the ability of consumers to understand and control what happens to their information in the following ways, including:

1) providing written explanation of the organization’s information practices and patient’s rights with respect to their health information;

2) granting patients access to own records for the purpose of inspecting and/or copying them;

3) permitting patients to seek correction and/or amendment of health information under certain conditions, and;

4) maintaining records of most disclosures of information;

The DHHS recommends allowing organizations to deny patients access to their record when access might cause grave harm to a third person or jeopardizes an oversight activity, legal proceeding or clinical trial. In the event that an organization refuses a patient’s request to correct and/or amend health information, it must inform the patient of the refusal and allow the patient to file a concise statement explaining the requested correction and reason for disagreeing with refusal to change. The patient’s statement should be included in the record, but the burden of proof for correction lies on the patient. None of these recommendations should abrogate existing reporting laws about such things as vital statistics and infectious disease or abrogate existing state or federal laws that impose greater restrictions on use of private information.

The DHHS recommends providing new sanctions and new avenues for redress for consumers whose privacy rights are violated, including:

1) civil proceedings: actual and equitable relief including physical, mental and pecuniary losses. Attorney’s fees should be paid in cases of knowing violation of confidentiality, and;

2) criminal proceedings: criminal penalties for obtaining health information under false pretenses and knowing and for unlawfully obtaining, using, or disclosing health information.

In an acknowledgement of its own interests in the debate about patient confidentiality, the DHHS recommends identifying those limited arenas in which public responsibilities warrant access to individual medical information but sharply limiting uses and disclosure of information. The issue in this case affects the ability of NIH and other public health research agencies to aggregate data originally obtained from the records of individual patients into large databases that could potentially reflect broad trends. The problem requires simultaneously stripping aggregate records of individual identifiers while maintaining the ability to trace the original sources.

In the months to come, Congress and the DHHS will make new laws and rules based on these principles. Although the legislative process will undoubtedly affect the precise requirements, health providers, payers, service organizations and other organizations potentially affected should begin now to ready their responses. Preparing themselves to meet the new federal guidelines constitutes the first step in becoming security capable organizations.

Enhancing patient understanding of organization’s data security efforts

As the preceding discussion of the DHHS recommendations on confidentiality make clear, we face new obligations in informing our patients about how they manage health information. The DHHS recommendations signal some broad social changes, however, whose significance transcends the narrow legal and regulatory context of their development. Our relationship with our patients is fundamentally changing. On the one hand, the reforms in health care finance (specifically the emergence of managed care) are refocusing some aspects of health care from the doctor-patient relationship to the health care organization-patient relationship. On the other hand, chronic illness has emerged as the dominant context of medical care. These major changes mean that we are accountable to our patients as organizations in new ways. In addition to being accountable for health care processes and outcomes, we are becoming accountable to our patients for our business practices, particularly for what we do with information about their individual cases. As our relationship to our patients thus changes, we must reexamine some of the ethical principles guiding our practice. The doctrine of informed consent stands at the heart of the doctor-patient relationship in medical care and research. We must therefore ask, “What implications do all these changes have for informed consent?”

Case Study: KP Online and Changing Patient Relations in an HMO

Case Study: “HelpBot” and Data Security in Project Phoenix

In collaboration with Lance Hoffman, Anya Kim, and Arwa Al-awaz from George Washington University, Georgetown has developed a World Wide Web instructional tool known as “HelpBot” to inform patients about how we safeguard the security of patient information in Project Phoenix, a telemedicine in hemodialysis project funded by the National Library of Medicine. In addition to presenting material about our data security program specifically written for HelpBot, the tool contains links to other sources of information on the Internet. The design of “HelpBot” incorporates principles of human-computer interface theory and computer-based education to make it easy for anyone to use with little or no support. Because HelpBot resides on the World Wide Web, anyone with Internet access may use it. To view the current version of “HelpBot”, please see http://www.seas.gwu.edu/seas/projects/phoenix or http://www.telemedicine.georgetown.edu/ProjectPhoenix.htmand click on “HelpBot”.

The key point is that “HelpBot” enables patients and family members to explore our approach to data security as deeply as individually required simply by clicking through various levels of the tool. Four basic levels exist, including a homepage that introduces the whole project, a level that explains the telemedicine network, a level that explains the risks to data security found during our risk assessment of the telemedicine network, and a level explaining our risk management plan. A user can migrate through the tool in an infinite number of ways depending on their own need to know and personal approach to learning. For example, if a patient wants to go straight from the beginning to the end, he can proceed horizontally from the introduction to the risk management plan. If a family member wants vertically to explore a particular component of the system, the telemedicine unit for example, she can click on the telemedicine unit, then click on the risks in the telemedicine unit and finally click on how the risks are being handled. At any point, a user can change the search pattern, return to the beginning or exit. In relevant sections, a user can activate hot links to other sites (for example, the firewall guide of the International Computer Security Association) while staying literally within the HotBot frame. We thus provide as detailed an explanation as possible of our approach to data security with the patient determining the level of detail actually searched.

Please note: HelpBot demonstrates our process of data security management as much as it explains its components. HelpBot explains that the telemedicine network exists physically in a particular setting, contains certain types of equipment, moves information along certain pathways, and depends on the actions of certain people. HelpBot also explains, however, that we performed a risk assessment of the telemedicine network; that is, we searched for risks to breaches of data security in the physical plant, the dialysis and telemedicine equipment, the information flow and the people. HelpBot also demonstrates that having identified the risks to data security, we developed policies, procedures and practices to secure the physical facility, maintain the equipment, manage the flow of information and educate the people. “HelpBot” illustrates how we would proceed given any other data security project. Thus “HelpBot” is both a model of and model for our approach to data security management at Georgetown.

“HelpBot” illustrates several critical dimensions of how we are incorporating our patients into building a security capable organization at Georgetown. First, “HelpBot” synthesizes the two key pillars of our data security program in Project Phoenix, namely:

1) HelpBot explains the process whereby we evaluated the risks to data security in the telemedicine system, developed a plan for managing them, and implemented our plan, (that is, it demonstrates how we addressed Hypothesis One in Project Phoenix) and;

2) HelpBot makes the information available to patients in a readily accessible, highly reviewable form over which they have control (that is, it embodies the central idea of Hypothesis Two of Project Phoenix).

Second, “HelpBot” reflects our recognition of the organizational relationship between Georgetown University Medical Center, TRC, Inc and our patients. Our end stage renal disease patients are chronically ill. Although some will leave because they receive kidney transplants, become disaffected with our care, move from the region or die, we will maintain long term care relationships with many if not most of them. Moreover, the patients directly develop that relationship with TRC and Georgetown as recipients of renal care, not secondarily simply as a service to the nephrologist. Third, “HelpBot” will certainly become part of our response to the new requirements to provide written explanation of Georgetown’s approach to information management. Although currently focused on Project Phoenix, we can easily adapt “HelpBot” to document and explain the institutional approach to data security management of Georgetown or any other health care organization. ²

“HelpBot” also reflects our approach to a more fundamental problem, informed consent in the context of contemporary health care. When we think of informed consent in the traditional way, we tend to think of doctors and patients discussing a procedure in the context of an acute episode or a research project. Clinical or research care may occur over an extended period, but the process of informed consent as represented by the act of reading, questioning and ultimately signing a consent form appears as an event. We have such consent forms in Project Phoenix. Indeed, we have incorporated two different explanations of our approach to data security in Project Phoenix into the experimental design and the consent forms of Project Phoenix. We are evaluating whether or not patients vary in their willingness to participate in telemedicine projects depending on the comprehensiveness of the explanation about data security management received in the consent form. The preliminary data indicates that no, our patients have almost without exception agreed to join Project Phoenix irrespective of the consent form. We have nonetheless resisted drawing the conclusion that patients do not require detailed explanations of our data security practices. On the contrary, we have reconceptualized the process of informed consent from being an event to being a continuous process. Given the chronic nature of our patients’ illness, the long term nature of the relationship between the patient and our organization, and our emerging new legal obligations, keeping patients continuously informed about our business and medical practices must become key to how we remain accountable to them and their families. As all the opinion polls document, trust is the issue. “HelpBot”, a dynamic, patient controllable, easily accessible online tool should therefore replace the fixed, provider-controlled, inaccessible consent form as the central image of a new process of informed consent.

Updating data security policies, procedures and practices in light of changing mission

Security capable organizations continuously update their data security policies, procedures and practices to manage the risks emergent from their changing mission. The security team must take primary responsibility for coordinating this effort but an organization’s administration and individual staff members must all contribute. Even if they accept the need for maintaining the confidentiality of patient identifiable information, the administration and staff will probably resist taking on new tasks or complicating the work necessary to discharge their current tasks. The security team must recognize that enhancing the organization’s security capability requires transforming institutional resistance into work in service of the security effort. In summary, security capable organizations coopt not coerce their members into the security surveillance process.
Case Study: Securing KP Online

Case Study: Securing the ISIS Center

The Imaging Science and Imaging Systems (ISIS) Center, Department of Radiology, Georgetown University, conducts research in applications of advanced computing and telecommunications technology to health care. In its capacity as an important civilian research laboratory for the Department of Defense, the ISIS Center has established its reputation for technical sophistication and organizational effectiveness through projects such as DINS ( the prototype and technical specifications for the DOD filmless radiology system known as MDIS), Project DEPRAD (the deployable teleradiology network built in support of NATO troops in Bosnia), and digital mammography (proof of concept and working model of digital mammography adapting computed radiography technology). The ISIS Center also successfully competes for extramural funding from other government agencies including the National Institutes of Health and the National Science Foundation in the areas of image processing, computer-aided diagnosis, telemedicine, and image guided therapy.

The ISIS Center faces major changes in its research environment. On the one hand, projects in all aspects of its work are beginning to acquire, manipulate and archive patient identifiable information on the ISIS Center local area network. This includes running clinical trials for government and commercial funding agencies subject to Food and Drug Administration rules and regulations. On the other hand, investigators, physicians, and patients increasingly require remote access to such data using dial-up and web-based technology. Whereas the ISIS Center has historically not faced major data security problems in its links with untrusted networks, these two new conditions require developing a plan for managing the security and confidentiality of patient identifiable information on its LAN. Our RFP addressed important technical components in the ISIS Center’s approach to managing data security. Ongoing risk analyses, risk management plans and data security policies supported the technical approach being sought in this RFP. The ISIS Center will not function as a repository for clinical information; but, must nonetheless protect the security and confidentiality of patient identifiable information used in pursuit of its research mission.

Technical Environment of the ISIS Center

The ISIS Center currently operates its LAN in an open, unrestricted mode (Collmann, Meissner et al 1997). Because the ISIS LAN is connected to untrusted networks, we designate it as open. Moreover, it functions in a relatively unrestricted mode because few access controls or authentication measures exist beyond those provided by individual computers on the LAN. Anyone with rights to work on ISIS projects may use the equipment and the network with minimal password control. Vendors, other university investigators and students with whom ISIS investigators collaborate have unencumbered remote and local access to the ISIS LAN. Data security policies have been the responsibility of individual investigators with little or no effort to educate users in or enforce a center wide security policy. Investigators also determine what services they use in their research, including modem access, telnet, web access and other functions. This approach to data security met the needs of ISIS when research projects functioned without patient identifiable data and before we conducted clinical trials.

The ISIS Center intends in the future to operate its LAN in an open, restricted mode. The ISIS LAN will remain connected to untrusted networks. Access controls and authentication measures will be installed to enforce new policies protecting patient identifiable data and meeting data security requirements of our funding agencies. Individual investigators will retain the right to determine access and use privileges for data in their own projects consistent with the data security policies of the ISIS Center and their funding organizations. Their policies will be documented and included formally as appendices to the written ISIS Center data security policies, including lists of authorized users and their privileges. Each investigator will collaborate with the ISIS Center network administrator in appropriately programming access and authentication tables in firewalls and databases to enforce policy. The ISIS Center will sponsor regular staff training sessions in the new policies and procedures. This approach will attempt to incorporate the autonomy and responsibility of investigators conventionally associated with a research environment into practices increasingly expected of all organizations creating, manipulating and archiving computerized patient identifiable data.

The decision-making environment of the ISIS Center

Because the new data security policies and procedures will affect the work of independent investigators and highly sophisticated staff who have enjoyed wide autonomy in their use of services, all ISIS staff collaborated in designing the new system. Over a period of several months, ISIS staff convened meetings to discuss key issues related to the firewall, including our individual and collective need to communicate with networks outside of the ISIS LAN and potential architectures of the ISIS LAN after installation of the firewall. Although most of the staff are technically trained and experienced in advanced computing and telecommunications technology, few claimed any real expertise in “computer security”. Above all few had direct knowledge or experience with firewalls or their impact upon system performance. These discussions were an initial opportunity to investigate the technology and implications of enhanced network security. Throughout the entire discussion, ISIS staff expressed great concern about potential declines in service as a result of installing the firewall, particularly reductions in network speed and the possibility of firewall failure. The debate about access to the outside world and the future architecture of the ISIS LAN fundamentally concerned negotiating the tradeoff between security and service the ISIS staff was willing to accept in light of its new responsibilities and mission. Although organizations can mandate such tradeoffs, we tried to coopt not coerce our colleagues into making the decisions.

Defining the LAN Architecture

The ISIS LAN connects now directly to the Georgetown University network through a router located on the first floor of 2115 Wisconsin Avenue with two hubs in a communications closet across the hall from the ISIS Center which is located on the sixth floor of the building. No firewall currently limits access to the ISIS LAN or to the 2115 segment of the Georgetown University LAN. The ISIS LAN network runs on 10BaseT Ethernet and ATM media using TCP/IPand IPX/SPX protocols. The ISIS LAN supports a range of equipment including desktop personal computers, high end workstations, a Cray supercomputer, Wolfcreek magnetic tape silo and the usual peripherals.³

We want to enhance the security of the ISIS LAN, software and data by installing a firewall between some parts of the ISIS LAN and the Georgetown University network. Determining the number of firewall interfaces and thus domains of the ISIS LAN became a major issue in our discussions. A firewall segments a network into trusted and untrusted domains by restricting access to some segments of the network. A segment becomes “trusted” because the firewall restricts access to only those users who have permission to enter according to the organization’s security policy. Networks or network segments not subject to the organization’s restricted access policies become “untrusted” by that very fact even if they function as part of its overall infrastructure. Please note: the concepts of “trusted” and “untrusted” are relative. A particular network segment may be “trusted” with respect to one network but “untrusted” with respect to another network. For example, people often think that firewalls guard internal networks from the Internet thus making the Internet an “untrusted” network and the internal network a “trusted” network. Many firewalls will support more than two interfaces, however, and thereby permit two or more network segments to be shielded from the Internet. Both network segments may be “trusted” with respect to the untrusted Internet; but, untrusted with respect to each other. Adding interfaces and increasing network domains increases security but adds burdens.

The question for the ISIS staff was whether to create one or two trusted domains on the ISIS LAN. After much discussion we decided that upon installation of the firewall, two ISIS domains will exist, an internal, trusted domain protected by the firewall and an external, untrusted domain not protected by a firewall. Please consult Figure 1 illustrating this architecture.

Figure 1. Proposed ISIS LAN Architecture

The answers to several questions conditioned our final approach to the firewall, including:

1) Where will the patient identifiable data reside? In our discussions of the firewall, we reviewed our use and storage of patient data. We have purchased a magnetic tape silo with the intent of modeling a centralized archive. We decided nonetheless to plan as if data might be stored and/or used on almost all ISIS computers, including but not limited to the magnetic tape silo. This decision reflects two fundamental features of ISIS work; namely, that principle investigators manage projects, not the ISIS Center and data potentially moves throughout the ISIS LAN during use irrespective of where it may become archived. We should create an infrastructure that supports the principle investigators and that protects patient identifiable data wherever it may temporarily or permanently reside.

2) How shall ISIS researchers access patient data? ISIS researchers now gain access to and manipulate data from any point on the ISIS LAN including their desktops, home and other remote locations. On the one hand, everybody understood that some kind of restrictions on access from outside the ISIS Center were necessary. The question remained of how much control should be exerted on traffic on the ISIS LAN itself. This question depended in part on the answers to the question above because, as we studied the issue, we realized that we do not clearly draw the line between investigators and other staff as well as the line between “workstation” and “archive”. Potentially every person and every machine could become responsible for patient identifiable information. We decided that traffic inside the trusted ISIS domain should flow unimpeded by the firewall.

3) How much effort do we want to invest in maintaining interfaces? Our lack of experience with firewalls raised concerns about the effort and expertise needed to maintain multiple interfaces. Purchasing expert support was possible and inevitably necessary. The fact remained that our own staff would function on the frontline of the firewall war. We also did not want to mortgage the ISIS Center just to maintain the firewall. The ISIS staff adopted the KISS principle. Until we become more experienced and confident of our ability to manage problems with the firewall, we should minimize potential sources of trouble.

In light of all these conditions, we selected the option of a single trusted domain and a single untrusted domain as illustrated above. Such an arrangement will create a secure domain for managing confidential patient information while supporting the ISIS Center’s investigator driven approach to managing research projects. We could more easily maintain the firewall as we gained experience in its use and operation. Finally, we would compensate for potential losses of security by training ISIS staff and depending on their sense of professional responsibility

Communicating with the Outside World

The ISIS staff now routinely communicates with the outside world from the ISIS LAN and with the ISIS LAN from the outside world using a variety of protocols. In order to enhance security on the ISIS LAN, we had to restrict access from outside to authorized personnel, but not sacrifice use of our communication tools. This made a certain kind of firewall known as a proxy or application firewall necessary. Proxy firewalls “open” packets in specific applications such as FTP, Telnet, SMTP, and HTTP thus enabling exact identification of their source. The inspection process exacts a performance price. Had we not required authenticating the identity of remote users, we could have potentially considered a packet filter firewall that screens according to IP addresses. This type of firewall offers protection to data, equipment and systems while minimizing impact on network performance but cannot authenticate remote users. Our requirements to move image data into and out from the ISIS LAN using DICOM standard poses a problem: no proxy yet exists for DICOM. We will work with our firewall vendor to resolve this issue. Since issuing their response to our RFP, our firewall vendor has produced proxies for IP videoconferencing, non-IP videoconferencing and shared conferencing thus enabling us to use these applications without violating the firewall’s integrity.

Following in the footsteps of organizations like Kaiser Permanente, we want to provide our staff with secure, authenticated access to the ISIS LAN and data from remote locations. Kaiser Permanente employs the Secure Socket Layer (SSL) to protect transactions between their patients and KP Online. We are examining the relative merits of SSL technology and a proprietary, transaction-based approach developed by our firewall vendor. We will report on our experiences as we acquire them.

After defining our architecture and identifying our proxy requirements, I drafted and circulated for comment an RFP. You may find it on the WWW at http://www.telemedicine.georgetown.edu/ProjectPhoenix.htmand click on “Firewall RFP”. We received four responses. In contrast to their ready participation in the needs assessment phase of this project, the ISIS staff showed little interest in the bids. After additional study made necessary by the heterogeneity of the bids and certain technical issues, we this past week awarded the contract to a large engineering firm with a local unit specializing in computer security based in Northern Virginia.

Questions about the Process

The concept of “cooptation” describes well the process we tried to implement in choosing our firewall. While recognizing the need for enhanced security on our LAN, the ISIS staff remains loathe to sacrifice its ready access to the Internet, the World Wide Web and all the other functions upon which each person depends every day in their work. They worry that th