7/27/2019 03_-_Teich_-_9929178

1/11

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 andmedical 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 referralsand 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 compelsystems 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 ofhealthcare 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.

2. New referral relationships. Referral habits

change as providers are incentivized to make

referrals to in-network specialists. If familiar

referral relationships are replaced withunfamiliar ones, more effort must be devoted to

ensuring good communication among providers.

3. 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.

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:

7/27/2019 03_-_Teich_-_9929178

2/11

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.

5. 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 toproper performance of health maintenance

screening. Providers are struggling to stay

abreast of constantly changing rules of

increasing complexity.

6. Decision support promise. A growing body of

literature confirms the ability of computerized

reminders, alerts, and other clinical decision-

support programs to improve care, prevent

adverse events, and reduce costs2,3

. These

successes have bred an increased demand for

such functionality.

Benefits of an HNICEGiven 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 clinicaldecision support applications can make use of

data acquired at any site.

2. 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

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.

3. 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.

4. 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.

5. 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 remotely-located providers.

6. 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.

Overall, information systems are substantially moreimportant 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.

7/27/2019 03_-_Teich_-_9929178

3/11

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 andclinical 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 affiliatejoins the network.

2. 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.

3. 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 re-keying, and leaving on paper are all options,

each with advantages and disadvantages.

4. 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.

5. Distributed governance. Decision-making insome 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 creating an overly

fragmented system.

6. 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.

7. 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.

8. 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.

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

7/27/2019 03_-_Teich_-_9929178

4/11

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 attractivemethod 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

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 browser-

based 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 straddleperiods.

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

Mainframe Client-server Web (HTML) Web (Java)

User interface Character-based GUI GUI GUI

Display

capabilities

Simple High Medium-to-high High

Applicationstartup time

Short Short Short Long, unless app storedon client*

Interactivity Question-at-a-time High Only by submitting page High

Security risks8 Few (terminal

scripts); access

controlled at

mainframe

Scripts, rogue

applications*, viruses*

Cookies, browser history.

On Internet: sniffing*,

access to rogue sites*,

access from all

Internet*9,10

Same as HTML, plus

still-unknown Java risks

(perceived or real?)

Client

requirements

Terminal High-performance

w/s, specific

architecture

NC or simple workstation Variable; may need high-

performance w/s; some

incompatibilities

Remote access Simple dial-up Remote-control or remote-node software

Any browser Most browsers; app loadtime long over dial-up

Updates Done at host Must update each

client if presentation

tier changes*

Done at host Must update client if

presentation tier changes

(or at each run)*

*commercial technological solutions exist to combat these disadvantages

Table 1. Comparison of different architectures.

7/27/2019 03_-_Teich_-_9929178

5/11

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, inmost 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

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. Considerablework 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 LOINC13for 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, tosee the data.

CDRs can be real or virtual. A virtual CDR5,14does

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

Logic Engine

KnowledgeBaseCDRMPI

Other reg

systems

user interface obj/services

GUI (Windows, etc.) Intranet Internet

User interface services

Data

Warehouse

Image

store

Other clinical

systems

Reg/sched

Demo-

graphics

ClinicalSummary,

Visit

Records

Results

Review

Orders

Inpatient

Records

Message

CenterDirectories

Referral

Tele-

medicine

Data access/ confidentiality services

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

7/27/2019 03_-_Teich_-_9929178

6/11

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 eachmust 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 whenthe 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 real-

time or 24x7 performance, and performs its data-intensive 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 centraldiagnostic 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 (non-

diagnostic) 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 cancontinue 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

7/27/2019 03_-_Teich_-_9929178

7/11

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 offunctions. 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 advan-

tages 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, anHNICE 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 fora 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

7/27/2019 03_-_Teich_-_9929178

8/11

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-to-

patient 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. End-

of-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 therules 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 anIHN 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 1shows, 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 out-of-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

7/27/2019 03_-_Teich_-_9929178

9/11

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 endsystems, 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-to-know 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 andexecute 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-but-

one 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

7/27/2019 03_-_Teich_-_9929178

10/11

considering implementation and maintenance, some

problems may be magnified in an IHN because the

core IT personnel may not be normally present on-

site, 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, mayhelp 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 well-implemented 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

1 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 computer-

based clinical decision support systems on clinician

performance and patient outcome. A critical appraisal of

research. Ann Int Med 1994; 120(2):135-142.3Overhage 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.4Grossman 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.7Kittredge 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).:628-

632.

8Barrows RC Jr, Clayton PD. Privacy, confidentiality, and

electronic medical records. J Am Med Inform Assoc 1996;

3(2):139-148.9Cimino 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.10Masys 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.11Tang 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 clinicallaboratory 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.15Sideli RV, Friedman C. Validating patient names in an

integrated clinical information system. Proc SCAMC

1991; 15:588-592.16Http://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):215-

224.18Kuperman 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.20Zielstorff 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.21Sittig 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.22Einbinder 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.24Brannigan 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

7/27/2019 03_-_Teich_-_9929178

11/11

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.

27Bozeman, TE, et. al. North Mississippi Health Services.Proc. 3rd Ann Nicholas E. Davies CPR Symposium.

Chicago: CPRI, 1997.