Clinical Information Systems for Integrated Healthcare Networks

Jonathan M. Teich, MD, PhD Clinical Systems Research & Development, Partners HealthCare System, Boston, MA
In the 1990s, a large number of hospitals and medical practices have merged to form integrated healthcare networks (IHNs). The nature of an IHN creates new demands for information management, and also imposes new constraints on information systems for the network. Important tradeoffs must be made between homogeneity and flexibility, central and distributed governance, and access and confidentiality. This paper describes key components of clinical information systems for IHNs, and examines important design decisions that affect the value of such systems. INTRODUCTION A dominant trend in US healthcare in the 1990's is the merger of hospitals and individual practices into large integrated healthcare networks (IHN's). This trend, a result of escalating cost pressures and an increasingly competitive environment, has changed the landscape for healthcare information systems. First and foremost, the geographic and political separation of an IHNs practices creates increased problems in data sharing and communication. Information systems can bond together the members of a far-flung IHN by providing access from any location to all clinical data, by facilitating referrals and communication among providers in the network, and by sharing medical knowledge resources across all institutions. At the same time, the essential structure of an IHN creates problems for effective information sharing. Data may originate from many disparate systems with differing formats and structures; to provide shared access, these systems must be combined and reconciled. This information must be accessible to providers who have a wide range of technical capabilities and architectures. Variations in practice patterns and governance from site to site compel systems to be more flexible than ever before. Concerns about loss of privacy and control increase as patients' personal information becomes available to a larger clinical community. Finally, entire new applications may be needed to support new processes of medical care, such as documentation requirements and referral management. This paper explores some of the major properties of healthcare network integrated computing environments (HNICEs), concentrating on how IHN computing needs and solutions differ from those found in a single hospital or ambulatory practice. INFORMATION NEEDS IN AN IHN Properties that increase need for IT Clinical practice in an IHN differs in several ways from practice in a self-contained hospital or medical office. Some of these differences have significant ramifications for the use and storage of clinical information. 1. Geographic dispersion. The most obvious property of an IHN is that it includes several practice sites usually, one or more hospitals, a number of office practices, and other facilities separated by tens or hundreds of miles. A single patient may present for different services at several different sites; similarly, a single provider may work in several different settings. New referral relationships. Referral habits change as providers are incentivized to make referrals to in-network specialists. If familiar referral relationships are replaced with unfamiliar ones, more effort must be devoted to ensuring good communication among providers. Ambulatory care focus. There is a change in emphasis from tertiary care at a single site to ambulatory care across multiple sites. Ambulatory practice is marked by reduced time allocation per visit, coupled with increased complexity of patient information and increased documentation requirements. There is an increased need for at-a-glance comprehensive views and templates that manage a visits information needs in one or two screens. Clinical information, such as medications, allergies, and care management plans, needs to be transferred from inpatient to outpatient sites as needed1.

2.

3.

In addition, other new aspects of the healthcare environment are not unique to IHNs, but certainly affect the way that information systems can be used:

4.

Change in computing perception. The explosion of the Internet during the past four years has increased patient awareness of, and demands for, access to information. Computing has also become a network marketing tool, for recruiting both patients and new practices. Managed care rules and government regulation. Payors have established complex rules that directly affect patient care, such as drug formularies, dosing recommendations, and restrictions on the use of diagnostic studies. Reimbursement and provider income are tied to compliance with these rules. The US government has also promulgated new guidelines and regulations that affect care. For example, HCFAs guidelines for evaluation and management (E&M) coding tie reimbursement to formal levels of documentation; the HEDIS health-maintenance criteria tie accreditation to proper performance of health maintenance screening. Providers are struggling to stay abreast of constantly changing rules of increasing complexity. Decision support promise. A growing body of literature confirms the ability of computerized reminders, alerts, and other clinical decisionsupport programs to improve care, prevent adverse events, and reduce costs2,3. These successes have bred an increased demand for such functionality. 3.

sites) between sister departments at different sites, helping them to work in concert. Messaging and notification services can ensure that a provider is aware of important clinical information, even if the provider works at multiple sites in the network. External communication. Economy of scale allows all practices to use common software for such functions as prescription transmittal, referral access from outside the network, and electronic data interchange for payment authorization. Value-added applications. IHN-specific applications and functions help providers navigate through new processes, such as network referrals and telemedicine consults, and through new practice issues, such as prescription services and documentation requirements. Through appropriate displays in its applications, the system helps promote cost-efficient care methods, compliance with government and payor rules, and adherence to network-wide care-improvement initiatives. Bonding. Value-added features such as the above, that increase the desirability of the HNICE, also increase the desirability of affiliation with the IHN an important fact for the IHN that wants to strengthen its relationship with affiliated providers. By establishing a common working environment, the HNICE imparts a sense of network identity to remotelylocated providers. Marketing presence. One benefit that an IHN offers to its affiliates is the power to join together as a marketing unit, not only for negotiations with payors but also as an attractive feature for patients who want to feel that they have access to a wide array of services. Similarly, IHNs are large enough to have an attractive World Wide Web presence with an extensive array of on-line patient materials and self-referral information.

5.

4.

6.

5.

Benefits of an HNICE Given these facts about the IHN practice environment, one can immediately speculate that the HNICE might provide substantial benefits in a number of areas. These are listed in brief here; some of these topics are explored in more detail in the following sections. 1. Shared data. An integrated clinical data repository (CDR) facilitates multi-site care of a patient by providing a single (real or virtual) shared record of all medical care rendered across the network. If the records adhere to a common data model as well, then clinical decision support applications can make use of data acquired at any site. Internal communication. The HNICE enhances communication among providers at different locations, making it easier for them to form new referral relationships within the IHN. The HNICE can also provide direct communication (e-mail, newsgroups, videoconferencing, Web

6.

2.

Overall, information systems are substantially more important to an IHN than they are when a providers (or a patients) clinical world is contained in one or two buildings. Increased integration of practices brings increased demand for effective information exchange.

Properties that impose constraints on IT Different clinical, technological, and organizational environments place different constraints on the HNICE architecture; an IHNs effectiveness may depend on its ability to make the right choices for its environment. Many of the significant factors are related to the varied computing environments and clinical information-gathering models already in place at the IHNs practice sites. 1. Legacy system incompatibility. In some ways, older IHNs could install comprehensive new systems more easily, because of the relative lack of pre-existing computing resources4. The task of combining data from existing systems is daunting5. In newer IHNs, disparate hardware platforms, data structures, database formats, term vocabularies, normalization values, and date conventions must all be resolved. This problem may reappear each time a new affiliate joins the network. Legacy functionality. Providers are likely to demand that any new system provide, at a minimum, all of the functionality they have with their current system. This is an important factor when deciding whether to implement new network-wide applications or to interface data to existing applications. External paper. As with non-IHN systems, attention must be given to outside lab results, electrocardiograms, out-of-network notes and letters. Scanning, interfacing, manual rekeying, and leaving on paper are all options, each with advantages and disadvantages. Communications disparity. In order to improve communication, the system must take into account the varying technical capabilities of the affiliates. Some providers may have access to full network data sharing; others may only have e-mail (with or without attachments), Web access, fax, or paper mail. An effective messaging system must be able to get all messages and documents to each provider. Distributed governance. Decision-making in some IHNs is heavily centralized. Other IHNs are loose confederations, in which a large amount of clinical policy decision-making is made at the level of the regional service organization (RSO) or even the individual practice. Politically, it behooves the IT department to establish decision-making procedures that represent all of the appropriate

viewpoints, without fragmented system. 6.

creating

an

overly

Flexibility vs. homogeneity. Clinical practice policies, workflow, and relevant data types may vary widely at different sites in the network. Careful decisions must be made about where the HNICE needs to provide application flexibility to support differences in practice, and conversely, where the need for integration and homogeneity outweigh these differences. Confidentiality focus. Issues of patient information confidentiality are of high importance in most healthcare settings. The federated nature of an IHN brings on new challenges: even while geographic dispersion increases the need for comprehensive access to a patients information, complex legal issues arise about access to information obtained at another site in the network. Size and scalability. The sheer size of the new merged institution can be significant, with tens of thousands of workstations spread over long distances. These numbers affect technology decisions because of issues of architecture scalability and the capacity of the IT department to implement, maintain, and support projects on such a wide scale.

7.

2.

8.

3.

These various requirements and needs are often in conflict; system designers and purchasers must decide which requirements are the most important for their own network. Some of the major design choices and key components of an HNICE are examined in the next section. KEY COMPONENTS System architecture Modern clinical computing systems have generally been based on one of two fundamental architectures: mainframe and client-server. Web server-browser architectures are now additional options. Each of these architectures has inherent advantages and disadvantages (Table 1). The main advantages of client-server and Java architectures are greater interactivity and system responsiveness to user input; system responses can occur immediately after each user action. However, to provide this, more information must be stored on the client, resulting in greater client hardware requirements and/or longer application startup times. Browser-based architectures run on many different hardware platforms; this is a significant advantage, although

4.

5.

some incompatibilities must usually be resolved. At the current state of the art6, browser-based clinical systems have been effectively used for display applications such as results review and knowledge access7,9, but have been less effective for highly interactive applications such as order entry. In an IHN, size and distance are compelling factors. An IHN may have thousands or tens of thousands of workstations; any per-station hardware and software costs are greatly multiplied, and the architecture must be highly scalable. Service and software updates are also concerns. To obtain the interactivity advantages and scalability of a client-server system, mechanisms must be in place to update each workstation when the client software changes. The simplicity and relative standardization of the Web browser may reduce remote service calls, and the ubiquity of Internet access makes this an attractive method of providing connectivity to many far-flung sites, although real and perceived security issues are still concerns. Cable television companies that provide Internet service may be able to provide virtual private networks (VPNs) to reduce Mainframe User interface Display capabilities Application startup time Interactivity Character-based Simple Short Question-at-a-time Client-server GUI High Short High

connectivity costs. Some IHNs have chosen to use a mix of technologies: client-server for full-function, highly interactive data entry applications in hospitals and core network locations, coupled with a browserbased light client, offering clinical data display, messaging, and reference applications to small or loosely affiliated practices.11. Sustaining legacy systems. While some IHNs mandate a single consistent architecture for all sites, many IHNs continue to use some pre-existing information systems. In fact, this state is unavoidable in the short term; even with the installation of a new HNICE there must be a straddle period, during which legacy applications continue to run while their data are being merged with the network system. If the IHN continues to add new affiliates, each with its own pre-existing system, there will be a succession of such straddle periods. A legacy system may be sustained over the long term if it is not practical or valuable to recreate its functionality in the new system. The price of this strategy (other than increased maintenance) is that Web (HTML) GUI Medium-to-high Short Web (Java) GUI High Long, unless app stored on client*

Only by submitting page High

Security risks8 Few (terminal scripts); access controlled at mainframe Client requirements Terminal

Scripts, rogue Cookies, browser history. Same as HTML, plus applications*, viruses* On Internet: sniffing*, still-unknown Java risks access to rogue sites*, (perceived or real?) access from all Internet*9,10 High-performance w/s, specific architecture NC or simple workstation Variable; may need highperformance w/s; some incompatibilities Most browsers; app load time long over dial-up Must update client if presentation tier changes (or at each run)*

Remote access Simple dial-up Updates Done at host

Remote-control or Any browser remote-node software Must update each client if presentation tier changes* Done at host

*commercial technological solutions exist to combat these disadvantages

Table 1. Comparison of different architectures.

the legacy system usually exists at only one or two sites, and does not share data with other sites. It is often possible to feed data from this system into a common data repository where it can be used by other network applications. Ideally, the legacy application would also be able to see data from other sites by reading from the repository. However, in most cases, this is not easily accomplished, so that continued users of the legacy application do not get the benefits of shared data access12. Each network must decide where the advantages of shared data outweigh the advantages of retaining existing systems. Master databases Common data repository (CDR). The CDR is the central storage area for combined network data. Compatible applications from any site can read from the CDR to use shared data, and write data back to it so their data can be used elsewhere in the network. The CDR takes data directly from HNICE applications written specifically for it; it is also connected to other sources of data by interfaces. If data from disparate systems is to be truly shared, it must be merged at five different levels. The data must be co-located on a single platform (see exceptions below); must have a common data
GUI (Windows, etc.)

structure and format; must use the same or compatible data vocabularies; must be normalized, so that the same value for a test result has the same clinical meaning regardless of the data source; and must be ordered or indexed. The last requirement allows data obtained alternately at two sites to be viewed in proper chronological order. Considerable work is required to achieve this level of merging, but it is necessary for advanced functions such as clinical alerts based on laboratory trends. Adoption of standard data dictionaries by the source systems, such as LOINC13 for laboratory tests, greatly reduces the effort required. Lesser degrees of data merging can be useful for view-only purposes, as long as the provider is aware of varying units and unsequenced data. The next level down is existence-only a common index that simply indicates that data exists for the current patient at one of the other sites; the provider has to use a different application, or even connect to that site, to see the data. CDRs can be real or virtual. A virtual CDR5,14 does not physically hold the data. Rather, when a request is made for a given patients data, data access service routines are executed. These routines fetch data from each of the available source databases, collate the data to some degree, and display it, typically in a
Intranet Internet

User interface services user interface obj/services

Reg/sched Demographics Clinical Summary, Visit Records Orders Results Review Inpatient Records Message Center Referral Telemedicine Directories

Data access/ confidentiality services

Logic Engine CDR

MPI

Knowledge Base

Other reg systems

Other clinical systems

Data Warehouse

Image store

Figure 1. Block diagram of a typical HNICE, showing interface, application, and data layers.

Web browser. Virtual CDRs are quick to implement to a first degree of usability because they do not require the robust multi-level merging typical of a real CDR. They also do not require duplicate data storage and a large central storage bank. The disadvantages are that the independent databases must each be maintained independently, and each must meet the uptime, reliability, and security standards desired. Each database must be polled for each data request (including any necessary login handshaking), to see if it holds any relevant data; thus, there are more potential performance bottlenecks. The varying data formats are less controlled and tend to diverge, making them more suitable for view-only applications than for more sophisticated data mining and event detection. For an IHN that needs multi-site data access as soon as possible, and is willing to forgo the advantages that come from tighter data merging, the virtual CDR may be the most effective answer, especially when the shared data is primarily in text format. Data warehouse. The same database can be used for real-time clinical data transactions and for aggregate data analysis and research. However, an increasing number of institutions have a separate data warehouse for the analysis functions. For IHNs with a strong research community, and for any IHNs management reporting needs, a separate warehouse may be worth the investment. The data warehouse platform is optimized for user-driven queries (in SQL or similar form), does not need to provide realtime or 24x7 performance, and performs its dataintensive work without impairing the performance of the CDR. The data warehouse gets some of its data directly from the CDR through batch transfers during off-hours; it is also fed by other data sources not related to the CDR. As with the CDR, the usability of the warehouse depends on how well the data from various sites are matched. Image databases. Picture archiving and communication systems (PACS) are especially important in the IHN setting, since the geographic dispersion makes access to photographic films difficult. Using a PACS, an IHN can provide central diagnostic imaging and/or interpretation services, ensuring that the image is available to both the radiologist and the ordering provider. For performance and storage reasons, the PACS usually resides on a separate database from the CDR, but it can be used by the same applications using a parallel set of data-access services. For general (nondiagnostic) viewing, standard personal computer

monitors are sufficient to view compressed image data with good quality. Larger, high-resolution monitors are used for diagnostic-quality display. The image database can also be used to solve the problem of external paper, storing scanned data from almost any source. Ideally, this random data should be indexed semantically for easy retrieval. Master patient index. Along with the CDR, the MPI is the most important database in the HNICE. It is a single unique list of all patients registered in any of the IHNs practices. Maintaining a correct, non-duplicative list of patients is difficult enough for a single practice; the task of merging existing databases, each with thousands or millions of patients, resolving all duplications, and continuing to match new registrations in real time is formidable. However, a high-quality MPI is an absolute requirement if data is to be shared when a single patient visits more than one practice in the network. Patients commonly visit multiple sites; in our own IHN we reviewed the last 3 years of visits to our two tertiary-care hospitals (located 5 miles apart, each with about 600,000 visits annually) and found that 16% of the patients seen at one hospital were also seen at the other. Because of the importance of this task, an industry has arisen specifically to provide these matching services. Matching algorithms15 compare demographic information to determine the likelihood that two entries represent the same patient. Most entries can be positively matched or distinguished; intermediate matching scores represent an uncertain match which must be manually resolved. The work involved in creating an MPI depends on the number of patients to be matched, and the certainty threshold required to automatically match or distinguish. Once created, new or existing registration systems can be used in the usual manner; when a new patient is registered at a site, the MPI service determines whether the patient already exists in the MPI, and assigns an old or new identification number to the patient. With a well-designed MPI database, the matching can be completed in a few seconds or less. Using cross-reference tables, legacy applications can continue to use the local ID number for a patient, while still gaining access to clinical data obtained at other sites, where the patient has different local ID numbers. Currently, intensive discussion has arisen about developing a universal patient identifier for all patients in the US, a consequence of the Health Information Portability and Accountability Act of

1996 (HIPAA). If such an identifier were to be created, it could significantly change the amount of work necessary to create an MPI. However, such a plan has not yet been implemented, and once implemented it may be several years before its effects are felt in this domain. Other databases. Several other clinically-oriented databases and master lists take on added importance in the wide-area IHN, either because they solve problems created by geographic dispersion or because they take advantage of economies of scale. These include a master provider list, analogous to the MPI; enterprise-wide schedules; drug formularies; a knowledge base, storing rules and decision-support logic tables; on-line reference storage; and vocabulary databases to support use of standards for tests, diagnoses, and other medical entities. Each of these can range from a simple list to an enhanced database supporting a wide range of functions. For example, the provider list may also include information to help guide referrals. Homogeneity vs. Flexibility We have seen that a CDR can be built so as to force greater or lesser structural homogeneity in the data that is fed into it. This same choice is repeated many times in the development of an HNICE, which because of its diverse nature usually has a variety of different clinical applications. The homogeneity issue influences decisions to keep or replace legacy applications, to purchase integrated or best-of-breed systems, or to develop components internally. Applications, dictionaries, and parameters can be made to require tight uniformity among all users, or to permit wide variability in operation. Decisions of homogeneity vs. flexibility will affect the ease of integration of new practices, the usability of the applications for different practice types, and the ability to efficiently combine multi-site data. Homogeneity. Greater homogeneity brings advantages in a number of areas. Consistent data objects and dictionaries allow related data to be shared on many levels. This applies to clinical object classes that transcend sites and levels of care, including problems, medications, allergies, observations, demographic, and financial information. Allergies entered using an outpatient documentation program should be available to an inpatient order entry application. A medications core structure (drug, form, route, dose, frequency) should be kept consistent across inpatient and outpatient applications. Data homogeneity is especially important so that all patient data can be used in

clinical decision support logic. Adherence to dictionary and structure standards, such as HL7, Corba, and LOINC, maximizes the ease of merging in the next new practice. Consistent system services are important for processes that are re-used in many applications. Examples include services that access CDR data, and those that check confidentiality rules before data is returned. In a system that can run several clinical applications concurrently, services should also ensure that all applications are working on the same patient, to prevent confusion. The Clinical Context Object Workgroup16 is working on standards for this. Consistent functions and interface across different applications minimize training requirements and user frustration; these take on extra importance in IHNs. Examples include ordering outpatient and inpatient tests, selecting a new patient, entering a note, and responding to an alert. In some cases, an HNICE contains a visual integration layer, providing homogeneity and standard services on top of a variety of disparate applications5. If the core structures are the same, then drugs and therapies are easily moved between applications upon admission and discharge; clinic notes are easily included in a tertiary referral; new drugs ordered in the emergency department are checked for interactions with a patients regular outpatient drugs; and medical management rules are more enforceable across the spectrum of care. Flexibility. On the other hand, flexibility is vitally important in an HNICE supporting a diverse IHN. It allows practices to realize the benefits of common access and consistent storage, while still allowing enough variation to handle different practice patterns. Appropriate flexibility actually increases homogeneity by allowing the HNICE to be used for a greater variety of practices; practices whose needs are met by the HNICE will be less likely to buy a separate system outside the HNICE. Flexibility is important in several ways. A flexible HNICE should be able to create specific views and forms for a practices needs. The summary view for a mental health practice may display different data types than would be found in an internal medicine practice. Similarly; flowsheet items for an oncology practice differ from those used in a prenatal clinic. A flexible system supports structured notes in different practices. Many vendors now offer structured documentation, where data items are

selected and arranged from a common data dictionary. Note templates can be edited manually for different practices and situations, and sections automatically expand or contract for patient-topatient variation. Different practices require different parameters and elements of common functions. Parameters for medication and test ordering differ for pediatric vs. adult use, and for ambulatory vs. inpatient use. Endof-visit functions (diagnosis and procedure code entry, standard tests and procedures) are also common concepts whose specific parameters must vary from practice to practice. Varying clinical situations call for differences in rules and alerts. Clinical decision support rules may vary among types of practices (for example, an abnormally low hematocrit means something different to an oncologist than to a cardiologist). A single rules engine structure is desirable17,18, but the rules themselves should be editable on a site-by-site or departmental basis. Local dictionaries, provider lists, and formularies must be supported. Each practice may have its own preferred drugs, doses, and diagnostic studies. Inpatient formularies are very site-dependent; outpatient formularies can be more flexible, and may be a function of the patients payor. Preferred diagnostic studies and laboratory tests may vary similarly from site to site and payor to payor. As these examples illustrate, flexibility is ideally realized as variability of parameters and processes on top of a common infrastructure. Typical infrastructure tools to provide flexibility include templates and template builders that can create customized views and forms; master databases of concepts and questions, from which a variety of structured notes can be built while still retaining data compatibility; a logic engine with a rule editor that allows rapid editing and customization of rules; and an algorithm engine19,20 that can incorporate these forms and rules into larger disease-management information agents. Local-properties file. As mentioned above, in an IHN there are many affiliate sites with many different levels of technical capability. An effective messaging system can deliver a given document to any of these providers. The system must know what a providers capabilities are, in order to properly post and transmit messages. A site properties file lets the system know the communications parameters of a given practice, so that the messaging system can

choose the appropriate transport mechanism for each recipient. Core applications As Figure 1 shows, most of the core applications in an HNICE are similar to applications found in hospital and ambulatory information systems. Extra application needs for an HNICE primarily address the need to serve providers at remote locations A referral support application is valuable. Surveys have shown that communication is the most important factor in referring providers satisfaction; however, information flow between consultant and referring provider is unsatisfactory in a majority of cases21. Referral support applications send the consultant useful information in advance of the patients visit, ensure that the referring provider gets feedback about all visits and important studies, and also facilitate financial and medical management22,7. A network provider database23 helps distant or outof-network providers find appropriate consultants. A clinical message center guarantees that each provider has access to important news, alerts, and messages as they move around the network. Messages can be reviewed from the system GUI, Web browser, or other technologies such as voice and faxback. Telemedicine is used in a variety of applications remote interpretation of studies, tele-consultation, educational program offerings, and inter-site conferences. Originally envisioned for use in sparsely populated regions, telemedicine services are also of great value in an urban network. Outpatient/inpatient linkage (OIL) and other automatic transfer programs automatically move information as the patients care venue changes. These programs ensure that outpatient allergies and drug interactions are considered when the patient presents at the emergency department, and are easily included in admitting orders. Upon hospital discharge, OIL programs forward medications, skilled-care referrals, follow-up appointment schedules, and therapy plans to the appropriate outpatient data store1. SECURITY AND CONFIDENTIALITY ISSUES The issue of confidentiality of patient data is by no means exclusive to the IHN environment, and many other documents explore this area in depth.8,24 This paper will briefly examine only those aspects that are of special importance to computing in an IHN: these

areas of special interest are cross-site access and complications in establishing need-to-know. Cross-site access. Different sites in an IHN are likely to vary widely in their confidentiality awareness, policies, and capabilities. Patients and providers from one site may be especially concerned about release of information to caregivers at other sites without express permission. The usual authorization that patients sign when entering a hospital gives access permission to hospital-based providers that are involved in the patients care. It is not clear whether such a blanket authorization can be extended across an IHN; it may be dependent on the specific organizational structure of the network. Network-wide cross-site access policies must be established, and legally validated, so that it is clear when data obtained at one location may be viewed at another. If network data is viewable from legacy front end systems, these systems must be able to handle the new policies. When shared network data is only accessible through CDR services, software to manage access policies can be incorporated into these services. When clinical data is placed on the Internet or any other remote-access arrangement to facilitate data sharing, then access controls must be embedded in the application9,10, often using special software to block security holes in the browser, such as the Back button and IP-address spoofing. Additionally, for remote access, technologies such as physical tokens (such as SecurID) may be necessary, since physical access to the workstation is no longer a barrier. Need-to-know. The federated nature of an IHN, and complex cross-site referral relationships, complicate the maintenance of need-to-know lists. Programmatic need-to-know determination has been proposed as one way to appropriately restrict access without unduly inconveniencing the patients legitimate caregivers25,26. For example, when a consultation is initiated, the consultant and the referring provider might automatically gain the right to access each others data for a period of time. Such automated mechanisms are necessary if need-toknow restrictions are to be practical at all12. Even so, it is impractical to try to predict every legitimate user of a patients data; a method of handling exception requests, with more aggressive checking and auditing, must be included as well.

ORGANIZATION AND PLANNING Governance and IT organization Governance in an IHN is centralized in some areas, distributed in others. The IT department has a customer service mission, so it must be responsive to the individualized needs of different practices; at the same time, it must be centralized enough to plan and execute network-wide projects efficiently, and to cultivate homogeneity where necessary. The IT department should be organized with an awareness of the decision-making processes of the IHN. Usually, IT itself should be a single organization for best efficiency and integration. In highly centralized IHNs, interaction with the sites may be in the form of advisory committees that collect input from site representatives27. In networks with more distributed governance, each site may have its own board with control of some IT resources. In either case, there must be an appropriate allocation of IT resources to site-specific and to network-wide efforts, so that projects useful to one site, to all sites, or to all-butone site each have the appropriate amount of attention. Our own IT organization has directors with functional portfolios (technology planning, clinical systems, etc.) and directors who represent each of the major sites, to serve as advocates for site interests. The CIO may report to the CEO, CFO, or COO of the IHN. In at least one network, the CIO reports to the director of quality improvement, a hierarchy which reflects the networks desire to guarantee appropriate resources for QI efforts. Implementation planning The large size of the IHN requires careful planning of implementation of the HNICE. Large networks require installation and maintenance of thousands of workstations. Speed of implementation of a new project may be limited by the ability to provide hardware, software, and training across the enterprise, and by the emergence of new technical problems when the project is implemented in large scale. However, rapid implementation is usually desirable because it minimizes technological and functional straddle. Solutions to this dilemma have been put in play on several fronts: computer-based training to reduce training personnel requirements, automatic software distribution technologies, Web-based applications where the interface is suitable, scalability benchmarking, and automatic fault detection systems. These are young technologies at present; they will serve better as they mature. When

considering implementation and maintenance, some problems may be magnified in an IHN because the core IT personnel may not be normally present onsite, as they would be in a single hospital system. Train-the-trainer programs, which produce resident site experts who can handle simple, common maintenance issues and questions, may help distribute IT expertise to many locations at low cost. CONCLUSIONS Although healthcare networks have been around in one form or another for decades, aggressive forces in the 1990s have created many new IHNs from formerly independent institutions and practices. There are compelling needs to share clinical data across many widely separated sites of care, even as there are new pressures for increased confidentiality protection. Overall, a well-designed and wellimplemented HNICE can alleviate some of the special problems of the IHN environment, and can be a major factor in unifying practices across the network. Issues of size, governance, technology, and flexibility must be carefully considered by each network; rather than being a one size fits all proposition, the design of an HNICE can directly affect its success in the enterprise. REFERENCES
OConnell EM, Teich JM, et. al. A comprehensive inpatient discharge system. J Am Med Informatics Assoc 1996, 3(suppl), 699-703. 2 Johnston ME, Langton KB, et. al. Effects of computerbased clinical decision support systems on clinician performance and patient outcome. A critical appraisal of research. Ann Int Med 1994; 120(2):135-142. 3 Overhage JM, Tierney WM, et. al. A randomized trial of corollary orders to prevent errors of omission. J Am Med Inform Assoc 1997; 4(5):364-375. 4 Grossman JH, Barnett GO, et. al. An automated medical record system. JAMA 1973; 224(12):1616-21. 5 Halamka JD, Szolovits P, et. al. A WWW implementation of national recommendations for protecting electronic health information. J Am Med Inform Assoc 1997; 4(6):458-464. 6 Sittig DF, Kuperman GJ, Teich JM. WWW-based interfaces to clinical information systems: The state of the art. J Am Med Informatics Assoc 1996, 3(suppl):694-698. 7 Kittredge RL, Estey G, et. al. Implementing a Web-based clinical information system using EMR middle layer services. J Am Med Inform Assoc 1996; 3(Suppl).:628632.
1

Barrows RC Jr, Clayton PD. Privacy, confidentiality, and electronic medical records. J Am Med Inform Assoc 1996; 3(2):139-148. 9 Cimino JJ, Socratous SA, Clayton PD. Internet as clinical information system: application development using the World Wide Web. J Am Med Inform Assoc 1995; 2(5):273-284. 10 Masys DR, Baker DB. Patient-centered access to secure systems online (PCASSO): a secure approach to clinical data access via the World Wide Web. J Am Med Inform Assoc 1997; 4(suppl).:340-343. 11 Tang PC et. al., Northwestern Memorial Hospital. Proc. 4th Ann. Nicholas E. Davies CPR Symposium. Chicago: CPRI, 1998. 12 Kahn MG. Three perspectives on integrated clinical databases. Acad Med 1997; 72(4):281-6. 13 Forrey AW, McDonald CJ, et. al. Logical observation identifier names and codes (LOINC) database: a public use set of codes and names for electronic reporting of clinical laboratory test results. Clin Chem 1996; 42(1):81-90. 14 Kohane IS, Greenspun P, et. al. Building national electronic medical record systems via the World Wide Web. J Am Med Inform Assoc 1996; 3(3):191-207. 15 Sideli RV, Friedman C. Validating patient names in an integrated clinical information system. Proc SCAMC 1991; 15:588-592. 16 Http://www.mcis.duke.edu/standards/CCOW/ 17 Pryor TA, Hripcsak G. The Arden syntax for medical logic modules. Int J Clin Monit Comput 1993; 10(4):215224. 18 Kuperman GJ, Teich JM, et. al. Representing hospital events as complex conditionals. J Am Med Informatics Assoc 1995; 2(suppl):137-141. 19 Ohno-Machado L, Gennari JH, et. al. The guideline interchange format: a model for representing guidelines. J Am Med Inform Assoc 1998; 5(4):357-372. 20 Zielstorff RD, Teich JM, et. al. P-CAPE: a high-level tool for entering and processing clinical practice guidelines. J Am Med Inform Assoc 1998; 5(Suppl):in press. 21 Sittig DF, Franklin M, et. al. Design and development of a computer-based clinical referral system for use within a physician hospital organization. Medinfo 1998; in press. 22 Einbinder JS, Klein DA, Safran CS. Making effective referrals: a knowledge-management approach. J Am Med Inform Assoc 1997; 4(Suppl.):330-334. 23 McHolm G, Obeid J, et. al. Facilitating physician referrals on the World Wide Web: representation and appropriate utilization of clinical expertise. J Am Med Inform Assoc 1996; 3(Suppl.):724-728. 24 Brannigan VM, Beier BR. Patient privacy in the era of medical computer networks: a new paradigm for a new technology. Medinfo 1995; 8(1):640-643. 25 Rind DM, Kohane IS, et. al. Maintaining the confidentiality of medical records shared over the Internet

and the World Wide Web. Ann Intern Med 1997; 127(2):138-141. 26 Hiltz FL, Teich JM. Coverage List: a provider-patient database supporting advanced hospital information services. J Am Med Inform Assoc 1994;1(Suppl):809-813. 27 Bozeman, TE, et. al. North Mississippi Health Services. Proc. 3rd Ann Nicholas E. Davies CPR Symposium. Chicago: CPRI, 1997.