Building man–man–machine synergies

Building man–man–machine synergies

International Journal of Medical Informatics 69 (2003) 127 /133 www.elsevier.com/locate/ijmedinf Building man man machine synergies Experiences fr...

400KB Sizes 3 Downloads 135 Views

International Journal of Medical Informatics 69 (2003) 127 /133 www.elsevier.com/locate/ijmedinf

Building man man machine synergies Experiences from the Vanderbilt and Geneva clinical information systems /

/

Antoine Geissbuhler Division of Medical Informatics, Geneva University Hospital, Hoˆpital Cantonal, 24 rue Micheli-du-Crest, Geneva 141211, Switzerland

Abstract Objectives: To demonstrate how a transition to an open hospital information system architecture can help foster stronger collaborations between computer-based clinical tools and the network of care process stakeholders. Methods: Description of two evolution strategies towards an open, component-based architecture: the vertical decomposition of a monolithic system, and the transversal integration of foundation components such as terminology servers, documentation management, prescription, scheduling, workflow and notification engines. Conclusion: The progressive migration of production clinical systems towards a component-based architecture is feasible at a reasonable cost and leads to substantial benefits in terms of user acceptance through participative design and collaborative maintenance of knowledge bases, as well as improved ability to evolve, scale and share individual components. A taxonomy of the components of a health information system and their interactions should be developed to realize the collaborative potential of a marketplace of interoperable components. # 2002 Elsevier Science Ireland Ltd. All rights reserved. Keywords: Man /man /machine synergies; Component-based architecture; Computer-based clinical tools

1. Introduction The potential of computer programs to assist the decision-making process of care providers has been recognized since the early days of computing [1]. Human have a limited short-term memory which, in the informationoverloaded world of health care, can lead to errors of omission. The ever-expanding body of biomedical knowledge is beyond the capacity of memorization, and cognitive biases reduce the ability to deal with probabilities [2].

Computer-based tools can help coping with these limits, by means of computer-generated reminders [3] and clinical decision-support tools. However, computers have limits of their own: current knowledge representation techniques are unable to provide an electronic version of common sense or empathy, and even in specific domains, extracting knowledge from experts is a daunting challenge. Man machine synergies appear when human intelligence and computer performance are associated in a cooperative mode [4]. These /

1386-5056/02/$ - see front matter # 2002 Elsevier Science Ireland Ltd. All rights reserved. PII: S 1 3 8 6 - 5 0 5 6 ( 0 2 ) 0 0 1 0 2 - 8

128

A. Geissbuhler / International Journal of Medical Informatics 69 (2003) 127 /133

work best when they are tightly integrated within the clinical information processes. Another level of functionality can be reached when such synergies are expanded to the complex network of healthcare stakeholders which, in addition to patients and care providers, include patient groups, home care, families, researchers, administrative personnel, third-party payers and regulatory agencies. At this stage, the main challenge of these ‘‘man man machine synergies’’ is the support and facilitation of the communication needs [5] by providing a common informational ground while respecting the specific perspectives of each group of stakeholder. Requirements for an information system that would support this function include: /

/

. The generation of multiple role-specific views that provide differential access to a coherent information system: thousands of collaborators and dozens of professions that coexist, interact and cooperate to provide health care to patients, each needs specific views of the clinical information system, views that relate to their specific culture, workflows and their information needs. These views must be based on a global reference information model and a set of linked profession-specific terminologies. . The ability to encapsulate institutional and departmental systems and minimize the effects of their changes: as boundaries between administrative and clinical systems are fading, the need for a seamless interoperation becomes imperative. Administrative and departmental systems evolve rapidly, often with little coordination, as they are chosen for their specific qualities, as is typical in the ‘‘best-of-breed’’ attitude that prevails in large academic environments. In order to cope with the changing nature of the underlying informational

environment, which is also aggravated by mergers and deep structural reorganizations, it is important to create a layer of interfaces that abstract the capabilities of the underlying systems and expresses them in a form suitable for the clinical applications. . The distributed and collaborative management of the knowledge bases: the added value of a health information system depends mainly on the quality of its knowledge bases. The architecture of the system should allow for the direct maintenance of knowledge by experts, even if the representation models and the knowledge management processes are heterogeneous. A component-based architecture is well suited to implement these requirements. Components are defined by Szyperski [6] as ‘‘units of composition with contractually specified interfaces and explicit context dependencies only’’, which ‘‘can be deployed independently and are subjected to composition by third parties’’. This definition encompasses the various levels of granularity encountered in health information systems, from monolithic applications to highly modular ones. It also provides a conceptual framework focusing on modularity, openness and interoperability. In the light of systems developed at Vanderbilt University Medical Center and at Geneva University Hospitals, this paper suggests pathways to open, component-based health information system architectures that could support man man machine synergies. /

/

2. Vertical decomposition of a monolithic system The feasibility of an all-encompassing single information system that would meet all needs for the support of care processes is a recurring

A. Geissbuhler / International Journal of Medical Informatics 69 (2003) 127 /133

proposition of the medical software industry. So far, it has not proven feasible, and will probably not be shortly, particularly in the complex setting of a teaching hospital or a healthcare network. The following example describes how a monolithic commercial system was encapsulated, then decomposed into smaller entities in order to meet the users’ needs for function and evolution [7]. The commercial system (Fig. 1a), whose customization took over 2 years, did not meet the needs of the clinicians, when implemented in the pilot care units. It also appeared quickly that further parameterization would not get to an acceptable level of functionality. However, the cost of the system, its efficient back-end functionalities and the efforts already invested in building the interfaces to the hospital information system made it desirable to reuse parts of the system instead of replacing it completely. The first step (Fig. 1b) was the encapsulation of the user interface, hiding it by a new interface, designed by the end-users through rapid prototyping. This end-user involvement was critical in improving the acceptance of the

129

system. Once implemented in production, the new interface remained stable even though further modification of the underlying system was taking place. Progressively, and in parallel with its institution-wide deployment, the system was decomposed (Fig. 1c). The results reporting functions were replaced by a full-blown electronic patient record. The admission discharge transfer (ADT) functions were replaced by another commercial system. The order entry logic was redesigned and new functionalities were incrementally implemented through dedicated components. Finally, the order-processing logic and the interface with the hospital information system were replaced and the commercial system decommissioned. This example shows that the progressive decomposition of a running clinical information system is feasible at a reasonable cost: an effort of about 3 men-years was necessary to complete this evolution, in addition to the resources already allocated for the parameterization, deployment and support of the original commercial system. The evolution was greatly facilitated by the existing architecture /

/

Fig. 1. Vertical decomposition of a monolithic clinical information system.

130

A. Geissbuhler / International Journal of Medical Informatics 69 (2003) 127 /133

based on a central interface engine and the availability in the institution of all necessary informatics skills, in particular for the reconfiguration of databases and of the interface engine. The main benefits of this restructuring included: . The increase in flexibility that allowed the participation of the end-users to the design of the system’s interface and functionalities, leading to a rapid and sustained acceptance, and to the iterative design of specific byproducts that improved the productivity of the users, including patient record summaries, sign-out sheets and automated identification of patients eligible for studies. . A tight integration with the institution’s electronic patient record [8], providing a seamless navigation for users and two-way programmable interfaces. . The ability to quickly adapt to new needs of the institution, through the incremental implementation of knowledge-rich components that would ‘‘plug-in’’ the order entry and decision-support logic. These components were tailored to the needs of the domain experts and their local processes of knowledge management, thus facilitating the formalization and maintenance of their knowledge bases and its integration into the decision-making processes [9,10]. These components, built as DLLs, are loaded dynamically and have similar interfaces, making use of a set of ‘‘exit points’’ in the system’s workflow logic: for example, components can be invoked at the start of a session, when a new order is placed, a new lab result is produced or orders are finalized. Examples of these ‘‘plug-in’’ include an antibiotic advisor that comments the usage of antibiotics on the basis of microbiological cultures and institution’s specific rules, a drug prescription advisor that takes

into account care-plan formularies, a calculator that estimates the cost of ordered resources, a search engine that automatically looks up a reference database for potentially relevant literature about the patient, advisors for blood products prescription, for streamlining the discharge process and preferences of private pediatricians for the care of newborns.

3. Transversal integration on institutional foundations Application components, business logic components and knowledge components have to be organized in order to meet the institutional needs for coherence that underlie an efficient communication between the care stakeholders. When considering the health information system globally, the boundaries between administrative and clinical components disappear. The key properties of the system become the transversality of the care delivery processes and the longitudinality of the patient-specific information. The Geneva Health Information System architecture [11] uses two axes for its transversal organization of components: care-production workflow and foundation components (Fig. 2). The care-production workflow organizes the flow of patient-specific information throughout the care process. At various points in the care process, stakeholders interact with the system through dedicated interfaces, consistent with their current role. These views mobilize the various components needed: application, business logic and knowledge components. These in turn invoke the foundation components. Externalizing the workflow from the actual applications and their views maximizes flexibility in a domain that is most susceptible for rapid evolution. Ideally, the

A. Geissbuhler / International Journal of Medical Informatics 69 (2003) 127 /133

Fig. 2. Architecture for the transversal integration of components on common foundations.

rearrangement of the workflow due to practice changes should therefore be limited to a parameterization effort. Its formalization should also open the way to new optimization capabilities. Foundation components provide the key functions that are shared across the information system: . The access control component provides a single point for user authentication, authorization and for the generation of certificates for secure inter-component transactions. It also handles all logging activities as well as the distributed maintenance of access rights. . The terminology component provides lookup and navigation capabilities to the institutional terminologies, as well as links between them. . The documentation component provides the low-level functionalities for handling structured information on the basis of the institutional terminologies. Documents produced by a variety of processes (e.g. dictation with paragraph-level structuring of the transcription, structured data entry through forms and direct interfaces to data producers) can therefore be structured in a globally coherent way, thus improving the

131

sharing of information throughout the institution. . The prescription component provides the basic business logic for generating valid orders and communicating them to the appropriate components. Prescription can therefore be implemented in various application components such as a physician order entry application, a nursing care planning system or the automated generation of orders by care pathways or reminder systems. . The scheduling component handles the planning of all the institution’s resources. This component federates the two axes of the system: the patient’s agenda (longitudinal view) and the mobilization of resources to implement the care plan (transversal view). . The notification component provides basic functionalities for synchronous and asynchronous notification of information to other components, including escalation strategies. This approach is particularly suited in an environment where most of the development is done in-house. Transverse foundations create an isolation layer that shields the components from the constraints and changes of the underlying legacy systems. This permits the de novo specification of coherent interfaces for the network of components. Ideally, these interfaces should conform to a standard reference information model such as the HL7 RIM. As this model was not mature enough when the project started in 1999, a locally defined dictionary of XML tags and schemata was used instead. It is too early to measure the effect of this architectural evolution on the end-user’s collaboration capabilities, but the effort of bringing together analysts and developers to work within a coherent framework proved highly

132

A. Geissbuhler / International Journal of Medical Informatics 69 (2003) 127 /133

beneficial in terms of shared understanding of the system and productivity. The reduction in cost for the production of new functionalities enables the rapid development of targeted components, answering specific end-users needs and thus changing the perception that they have of the information system. The ability to reuse knowledge components on various form factors (on handheld computers, on the intranet and inside clinical applications) has generated significant enthusiasm for the distributed formalization and maintenance of institution-specific knowledge by clinicians [12].

4. Perspectives According to Szyperski’s definition, components can be deployed independently and recomposed by third parties. This leads to the idea of a marketplace of components, where, instead of trying to share information and knowledge, a community would share the access to services, thus dividing up the efforts for creation and maintenance of the components, without having to duplicate or move the components. Sharing components rather than applications allows for the composition necessary to build locally acceptable systems while reusing existing services. This model would also be consistent with an open-source philosophy, whose potential for peer-review and innovation is enticing. However, significant efforts are necessary to model and normalize a common framework for building and using these components. To progress in this direction, a taxonomy of the possible components of a health information system is needed, as well as a model of their interactions, in order to specify the interfaces and dependencies that would define interoperable components. This

taxonomy should be built upon existing standards and reference information models.

Acknowledgements This paper is dedicated to the memory of Prof. Jean-Raoul Scherrer, pioneer in the field of medical informatics [13]. He designed one of the first patient-centered hospital information systems in the early 1970s, the Diogene information system at Geneva University Hospital [14,15], which included innovative solutions to the cultural problems of human machine interfaces, illustrated by the phoneoperator-mediated lab order entry system. He also led the research in distributed systems, and in particular in federated electronic health records, as well as in the field of natural language processing and knowledge representation, helping to bring human and machines closer towards productive synergies in health care. /

References [1] R.S. Ledley, L.B. Lusted, Reasoning foundations of medical diagnosis, Science 130 (1959) 9. [2] A. Tversky, D. Kahneman, Judgment under uncertainty: heuristics and biases, Science 185 (1974) 1124 /1131. [3] C.J. McDonald, Protocol-based computer reminders, the quality of care and the non-perfectibility of man, N. Engl. J. Med. 295 (1976) 1351 /1355. [4] R.A. Miller, F.E. Masarie, The demise of the Greek oracle model for medical diagnostic systems, Meth. Inf. Med. 29 (1990) 1 /2. [5] E. Coiera, When conversation is better than computation, J. Am. Med. Inform. Assoc. 7 (3) (2000) 277 /286. [6] C. Szyperski, Component Software, ACM, New York, 1997. [7] A. Geissbuhler, R.A. Miller, A new approach to the implementation of direct care-provider order entry, Proc. AMIA Annu. Fall Symp. (1996) 689 /693. [8] D.A. Giuse, A. Mickish, Increasing the availability of the computerized patient record, Proc. AMIA Annu. Fall Symp. (1996) 633 /637. [9] J. Heusinkveld, A. Geissbuhler, D. Sheshelidze, R.A. Miller, A programmable rules engine to provide clinical

A. Geissbuhler / International Journal of Medical Informatics 69 (2003) 127 /133 decision support using HTML forms, Proc. AMIA Symp. (1999) 800 /803. [10] A. Geissbuhler, R.A. Miller, Distributing knowledge maintenance for clinical decision-support systems: the ‘‘knowledge library’’ model, Proc. AMIA Symp. 1 (1999) 770 /774. [11] A. Geissbuhler, C. Lovis, A. Lamb, S. Spahni, Experience with an XML/HTTP-based federative approach to develop a hospital-wide clinical information system, Medinfo 10 (2001) 735 /739. [12] M. Tschopp, A. Geissbuhler, Institutional clinical knowledge management using web-enabled processes and palmtop computers, J. Am. Med. Inform. Assoc. Suppl. Proc. AMIA Symp. (2001) 840.

133

[13] A. Geissbuhler, C. Lovis, C. Boyer, R.D. Appel, D. Hochstrasser, R. Baud, A humanist’s legacy in medical informatics, Meth. Inf. Med. 31 (2002) 237 /242. [14] J.R. Scherrer, C. Lovis, R. Baud, F. Borst, Integrated computerized patient records: the Diogene 2 distributed architecture paradigm with special emphasis on its middleware design, in: I. Iakovidis, S. Maglavera, A. Trakatellis (Eds.), User Acceptance of Health Telematics Applications, Looking for Convincing Cases, IOS Press, Amsterdam, 1998, pp. 15 /31. [15] F. Borst, R. Appel, R. Baud, Y. Ligier, J.R. Scherrer, Happy birthday Diogene: a hospital information system born 20 years ago, Int. J. Med. Inf. 54 (3) (1999) 157 /167.