Building a comprehensive clinical information system from components. The approach at Intermountain Health Care.

OBJECTIVES: To discuss the advantages and disadvantages of an interfaced approach to clinical information systems architecture. METHODS: After many years of internally building almost all components of a hospital clinical information system (HELP) at Intermountain Health Care, we changed our architectural approach as we chose to encompass ambulatory as well as acute care. We now seek to interface applications from a variety of sources (including some that we build ourselves) to a clinical data repository that contains a longitudinal electronic patient record. RESULTS: We have a total of 820 instances of interfaces to 51 different applications. We process nearly 2 million transactions per day via our interface engine and feel that the reliability of the approach is acceptable. Interface costs constitute about four percent of our total information systems budget. The clinical database currently contains records for 1.45 m patients and the response time for a query is 0.19 sec. DISCUSSION: Based upon our experience with both integrated (monolithic) and interfaced approaches, we conclude that for those with the expertise and resources to do so, the interfaced approach offers an attractive alternative to systems provided by a single vendor. We expect the advantages of this approach to increase as the costs of interfaces are reduced in the future as standards for vocabulary and messaging become increasingly mature and functional.

Architecture for a Web-based clinical information system that keeps the design open and the access closed.

We are developing the Patient Clinical Information System (PatCIS) project at Columbia-Presbyterian Medical Center to provide patients with access to health information, including their own medical records (permitting them to contribute selected aspects to the record), educational materials and automated decision support. The architecture of the system allows for multiple, independent components which make use of central services for managing security and usage logging functions. The design accommodates a variety of data entry, data display and decision support tools and provides facilities for tracking system usage and questionnaires. The user interface minimizes hypertext-related disorientation and cognitive overload; our success in this regard is the subject of on-going evaluation.

Costs and benefits of connecting community physicians to a hospital WAN.

The Washington Heights-Inwood Community Health Management Information System (WHICHIS) at the Columbia-Presbyterian Medical Center (CPMC) provides 15 community physician practices with seamless networking to the CPMC Wide-Area Network. The costs and benefits of the project were evaluated. Installation costs, including hardware, office management software, cabling, network routers, ISDN connection and personnel time, averaged $22,902 per office. Maintenance and support costs averaged $6,293 per office per year. These costs represent a "best-case" scenario after a several year learning curve. Participating physicians were interviewed to assess the impact of the project. Access to the CPMC Clinical Information System (CIS) was used by 87%. Other resource usage was: non-CPMC Web-based resources, 80%; computer billing, 73%; Medline and drug information databases, 67%; and, electronic mail, 60%. The most valued feature of the system was access to the CPMC CIS. The second most important was the automatic connection provided by routed ISDN. Frequency of access to the CIS averaged 6.67 days/month. Physicians reported that the system had significantly improved their practice of medicine. We are currently exploring less expensive options to provide this functionality.

Evolution of a knowledge base for a clinical decision support system encoded in the Arden Syntax.

Clinical decision support systems (CDSS) are being used increasingly in medical practice. Thus, long-term maintenance of the knowledge bases (KB) of such systems becomes important. To quantify changes that occur as a KB evolves, we studied the KB at the Columbia-Presbyterian Medical Center. This KB has a total of 229 Medical Logic Modules (MLMs) encoded in the Arden Syntax. Eliminating those never used in practice, we retrospectively analyzed 156 MLMs developed over 78 months. We noted 2020 distinct versions of these MLMs that included 5528 changed statements over time. These changes occurred primarily in the logic slot (38.7% of all changes), the action slot (17.8%), in queries (15.0%) and in the data slot exclusive of queries (12.4%). We conclude that long-term maintenance of a KB for a CDSS requires significant changes over time. We discuss the implications of these results for the design of KB editors for the Arden Syntax.

Design and implementation of a multi-institution immunization registry.

One of every four children in the USA is underimmunized. Surveys of children in New York City have documented rates of appropriate immunization as low as 37% in certain populations in northern Manhattan. In response to this, government and private agencies have undertaken efforts to improve immunization rates. As part of one such multiinstitution effort in northern Manhattan, we have begun implementation of a computer-based immunization registry. Key features of this registry system include adaptation of legacy software in order to perform initial capture of data in electronic format; design of a user interface using a World Wide Web server that provides data review and capture functions with appropriate security; implementation of a registry database with links to the server, communication links between hospital registration systems, a Master Patient Index, community providers and the central registry; and integration of decision support in the form of Medical Logic Modules encoded in the Arden Syntax. We discuss our design of this multi-institution immunization registry and implementation efforts to date.

Practical lessons in remote connectivity.

Community Health Information Networks (CHINs) require the ability to provide computer network connections to many remote sites. During the implementation of the Washington Heights and Inwood Community Health Management Information System (WHICHIS) at the Columbia-Presbyterian Medical Center (CPMC), a number of remote connectivity issues have been encountered. Both technical and non-technical issues were significant during the installation. We developed a work-flow model for this process which may be helpful to any health care institution attempting to provide seamless remote connectivity. This model is presented and implementation lessons are discussed.

Electronic forms: benefits drawbacks of a World Wide Web-based approach to data entry.

It has long been realized that, compared to paper-based records, electronic record systems provide many advantages in the healthcare environment, including increased availability, improved legibility, long-term accessibility, (potentially) greater completeness, data encoding, and automated decision support and analysis. In spite of these recognized benefits, collection of patient data at the point of service generally does not occur, in large part because each such effort usually requires application-specific software and hardware, and, most significantly, provider time. Given the presence of WWW browsers now available on nearly every desktop, the support and access concerns for data entry applications can be substantially lessened. Despite these advantages, there are also downsides to the use of the WWW for data entry, including user interface issues and security. At CPMC, we are currently using web-based forms to gather patient charge data from physical and occupational therapists. Benefits of this approach have included a 98.2% user compliance rate for at least weekly data entry, and the reduction of charge posting from an average of 24.3 days to 2.3 days following the date of service. Drawbacks to WWW-based applications have included increased security exposure and persistent human tendencies to enter data in batches rather than at the time of service. A final conclusion was that, in the absence of a strong central mandate, providers must perceive a clear benefit in order to be willing to learn and use a new technology.

Design of a clinical event monitor.

The issues and implementation of a clinical event monitor are described. An event monitor generates messages for providers, patients, and organizations based on clinical events and patient data. For example, an order for a medication might trigger the generation of a warning about a drug interaction. A model based on the active database literature has as its main components an event (which triggers a rule to fire), a condition (which tests whether an action ought to be performed), and an action (often the generation of a message). The details of implementing such a monitor are described, using as an example the Columbia-Presbyterian Medical Center clinical event monitor, which is based on the Arden Syntax for Medical Logic Modules.

Privacy, confidentiality, and electronic medical records.

The enhanced availability of health information in an electronic format is strategic for industry-wide efforts to improve the quality and reduce the cost of health care, yet it brings a concomitant concern of greater risk for loss of privacy among health care participants. The authors review the conflicting goals of accessibility and security for electronic medical records and discuss nontechnical and technical aspects that constitute a reasonable security solution. It is argued that with guiding policy and current technology, an electronic medical record may offer better security than a traditional paper record.

Dialogue. Privacy protection: paper or computer records? Confidentiality of healthcare records.

In summary, security concerns surrounding health data are justified, but solutions are surmountable with currently available technologies. Whether systems are paper or electronic, human factors such as errors, negligence and unethical activities can result in breaches of confidentiality, despite optimal implementations. Neither automated teller machines (ATMs) nor EMRs are free from instances of abuse, but policies and protocols for electronic systems can be implemented that may provide better security than analogous paper record systems.

OzCare: a workflow automation system for care plans.

An automated environment for implementing and monitoring care plans and practice guidelines is very important to the reduction of hospital costs and optimization of medical care. The goal of our research effort is to design a general system architecture that facilitates the implementation of (potentially) numerous care plans. Our approach is unique in that we apply the principles and technologies of Oz a multi-user collaborative workflow system that has been used as a software engineering environment framework, to hospital care planning. We utilize not only the workflow modeling and execution facilities of Oz, but also its open-system architecture to interface it with the World Wide Web, the Medical Logic Module server, and other components of the clinical information system. Our initial proof-of-concept system, OzCare, is constructed on top of the existing Oz system. Through several experiments in which we used this system to implement some Columbia-Presbyterian Medical Center care plans, we demonstrated that our system is capable and flexible for care plan automation.

The economic motivations for clinical information systems.

For three decades (1960-1990) the primary use of computers in hospitals' in the U.S. was to ease the task of reimbursement for care rendered and to automate results reporting for high-volume, time-critical tests such as clinical laboratory procedures. Hospitals were regarded as independent organizations/revenue centers which could pass costs to third party payers. Beginning in the mid-eighties, U.S. hospitals were no longer reimbursed on a fee-for-service basis for many patients, but received a fixed payment regardless of the actual cost of treating a patient. The size of the payment depended upon the patients' type of illness (Diagnostically related group). This approach gave hospitals incentives to reduce costs, but did not foster a fully competitive environment. Now, in the mid-nineties, hospitals in the U.S. are seen as cost centers in an integrated health care delivery system. Within this environment, a longitudinal patient record is necessary to increase levels of communication between healthcare providers. While certain management functions remain hospital-centered, clinical information systems must now cover a spectrum of patient activities within the ambulatory and inpatient arena. Several of the leading healthcare providers use computer-based logic to alert care givers whenever standards of care are not being achieved. These institutions feel that such capability will be the real impetus to reduce cost and improve the quality of care. Based upon observations over four decades, it appears that economic considerations play the major role in determining which kinds of information systems are deployed in the healthcare arena.

Clinical workstations: An architectural prespective.

The role of a clinical workstation is examined as an integral part of a larger, clinical information delivery and acquisition system. Different care scenarios and environmental factors influence the behavior of a workstation. The common functional components of a workstation are information resources, application logic and presentation. A workstation is successful when each of its components operates within an information architecture and contributes to meet user needs. New technologies to integrate and display information are making the workstation functions independent of the actual hardware and software platform.

Internet as clinical information system: application development using the World Wide Web.

Clinical computing application development at Columbia-Presbyterian Medical Center has been limited by the lack of a flexible programming environment that supports multiple client user platforms. The World Wide Web offers a potential solution, with its multifunction servers, multiplatform clients, and use of standard protocols for displaying information. The authors are now using the Web, coupled with their own local clinical data server and vocabulary server, to carry out rapid prototype development of clinical information systems. They have developed one such prototype system that can be run on most popular computing platforms from anywhere on the Internet. The Web paradigm allows easy integration of clinical information with other local and Internet-based information sources. The Web also simplifies many aspects of application design; for example, it includes facilities for the use of encryption to meet the authors' security and confidentiality requirements. The prototype currently runs on only the Web server in the Department of Medical Informatics at Columbia University, but it could be run on other Web servers that access the authors' clinical data and vocabulary servers. It could also be adapted to access clinical information from other systems with similar server capabilities. This approach may be adaptable for use in developing institution-independent standards for data and application sharing.

Unlocking clinical data from narrative reports: a study of natural language processing.

OBJECTIVE: To evaluate the automated detection of clinical conditions described in narrative reports. DESIGN: Automated methods and human experts detected the presence or absence of six clinical conditions in 200 admission chest radiograph reports. STUDY SUBJECTS: A computerized, general-purpose natural language processor; 6 internists; 6 radiologists; 6 lay persons; and 3 other computer methods. MAIN OUTCOME MEASURES: Intersubject disagreement was quantified by "distance" (the average number of clinical conditions per report on which two subjects disagreed) and by sensitivity and specificity with respect to the physicians. RESULTS: Using a majority vote, physicians detected 101 conditions in the 200 reports (0.51 per report); the most common condition was acute bacterial pneumonia (prevalence, 0.14), and the least common was chronic obstructive pulmonary disease (prevalence, 0.03). Pairs of physicians disagreed on the presence of at least 1 condition for an average of 20% of reports. The average intersubject distance among physicians was 0.24 (95% Cl, 0.19 to 0.29) out of a maximum possible distance of 6. No physician had a significantly greater distance than the average. The average distance of the natural language processor from the physicians was 0.26 (Cl, 0.21 to 0.32; not significantly greater than the average among physicians). Lay persons and alternative computer methods had significantly greater distance from the physicians (all > 0.5). The natural language processor had a sensitivity of 81% (Cl, 73% to 87%) and a specificity of 98% (Cl, 97% to 99%); physicians had an average sensitivity of 85% and an average specificity of 98%. CONCLUSIONS: Physicians disagreed on the interpretation of narrative reports, but this was not caused by outlier physicians or a consistent difference in the way internists and radiologists read reports. The natural language processor was not distinguishable from the physicians and was superior to all other comparison subjects. Although the domain of this study was restricted (six clinical conditions in chest radiographs), natural language processing seems to have the potential to extract clinical information from narrative reports in a manner that will support automated decision-support and clinical research.