MEDINFO 2001 V. Patel et al. (Eds) Amsterdam: IOS Press © 2001 IMIA. All rights reserved
Experience with an XML/HTTP-based Federative Approach to Develop a HospitalWide Clinical Information System Antoine Geissbuhler, Christian Lovis, Alexander Lamb, Stéphane Spahni Division of Medical Informatics, Geneva University Hospital, Geneva, Switzerland Abstract
The need for tighter integration and for the development of synergies between various professional groups has led to the IAIMS initiative [1] and to a more patient-centric design of information systems, based upon reusable infrastructure and bridges across professional boundaries.
The authors present a two-year experience with an approach aimed at federating applications into a component-based hospital-wide clinical information system. Recognizing the need for better integration, clearer separation of knowledge from applications, as well as the necessity to respect and integrate the diversity of roles in a healthcare network, a strategy was implemented that included the development of a shared vision, organizational changes to promote appropriation at all levels, and the elaboration and maintenance of a common architecture and terminology by an instrumental technical group.
The development of healthcare delivery networks is increasing the diversity of different stakeholders, thus complicating the task of integration. A good example of this progression is the evolution of the IAIMS acronym: originally standing for Integrated Academic Information Management System, the meaning of the letter "A" changed to Advanced, then, as Stead [2] suggested, to Area, illustrating the importance of integrating healthcare information at a regional level.
Choices for federative technologies were in part based on their level of acceptance and potential to evolve. XML was used as the syntactic framework and HTTP as the transfer protocol.
Beyond hardware and software architectures, it is crucial to build such complex and evolving systems upon people, their knowledge and the processes they use [3,4].
Within twelve months, the shared vision was developed, the architecture was specified, the key central components implemented, incorporated into the applications, and applications teams started producing shareable services using XML and HTTP.
The diversity of stakeholders is a characteristic of a large health care organization. Each professional group deals with its own, and often partial view of the global system, with its knowledge, culture and terminologies. Moreover, the same
Keywords:
researchers laboratories
Clinical Information System; Architecture; Organizational Issues; Change Management
patient
home care
pharmacies
specialized physicians
general practitioner
students
Introduction
family
other care providers
patient record(s)
A large hospital is often described as a "city in the city". Thousands of collaborators, dozens of professions coexist, interact and cooperate to provide healthcare to patients. Professional groups each have their own specific culture, their view of the world and their information needs.
global knowledge local knowledge
Historically, computer-based systems have been built to help each professional group deal with their information needs, thus respecting or reinforcing the functional boundaries of the groups. These systems have then been interfaced to others in order to form hospital-wide information systems, generally in a way that mimicked existing paper-based transactions.
case managers coders
payers regulatory agencies
administration
Figure 1 - healthcare stakeholders and information types: diversity, blurred boundaries, interdependency
735
Chapter 8: Health Information Systems
support of the hospital-wide clinical information system, and provides an architectural and technical framework for the convergence and integration of the components of the system. The strategy is implemented with the following key actions:
professional can have multiple roles: a nurse can be planning the care of a patient, checking vital signs at the bedside or rounding with physicians. In each role, the information needs and the ergonomics of the system will be different: a computer at the nurses station would be necessary for the care planning while a handheld device would work best at the bedside.
1. Develop a realistic -- albeit ambitious -- vision of the functionality of the target clinical information system. End-users often find it difficult to project themselves working within new computer-enabled processes. Use cases, rapidly-evolved prototypes, and early clinical immersion are often necessary.
Figure 1 represents the spectrum of stakeholders, as well as the three main groups of information that a clinical system deals with: information about the patient (medical, social, administrative), local knowledge (regional, institutional or personal, formal and informal), global knowledge (reference information, guidelines, expert systems...). The boundaries between the different roles are getting more and more blurred and the various types of information become increasingly intertwined.
2. Setup institutional working groups to help evolve the vision according to strategic objectives and to address issues such as access rights policies. These groups improve the appropriation of the project by the institution's top management.
To cope with this diversity of users and information types, a scaleable, evolving, federated system must be able to produce role- and context-specific user interfaces: the knowledge that drives the applications must therefore be separated from the user interaction logic. From a technical perspective, this can be achieved in several ways: distributed components in a multi-tier architecture can provide specific services. Alternatively, centrallymaintained knowledge bases can be compiled and embedded into applications. However, the main challenge is the ability to represent the knowledge in a way that is usable, maintainable, and meaningful to diverse users. It is therefore crucial to implement, as early as possible, a process that manages a central repository for the controlled vocabulary, and to which semantic layers can be added, as implemented in CPMC's Medical Entities Dictionary [5]. The same needs apply at the inter-components messaging level: various XML-based models are currently being developed [6-8] to address this issue.
3. Elaborate a common technical architecture including a high-level object model. The challenge is to model the system at a conceptual level while still remaining linked to real-world processes. In a componentbased architecture, one of the main difficulties is to segment the constituents into entities that reflect the real processes and can evolve with them. 4. Make an inventory of existing systems, components and interfaces. 5. Make an inventory of short term needs, both functional and technical. Deploy early prototypes in clinical settings in order to gain support from the end-users as well as positive pressure for funding. 6. Define a mid-term critical path for the federation of the system's components. When making the path from the present situation to the projected vision, it is essential to be able to decide which components are going to be built, sub-contracted or bought to last and which are merely throw-away solutions that are necessary to move forward.
Another challenge relates to security and confidentiality: the removal of traditional boundaries between areas of information enables new modes of collaborations but challenges established policies on access rights. This becomes particularly sensitive when access to information crosses institutional boundaries and becomes the potential substrate of economic competition. Moreover, the implementation of computer-based systems requires the explicit formalization of processes and rules, which, in reality, are often expanded and operationalized by tacit, informal knowledge.
7. Setup a group to supervise the evolution of the object model and guarantee the technical harmonization of the system's components, whether these components are purchased, built locally or their development outsourced. Technical choices A 3-tier architecture was chosen in order to separate the presentation layer from the logic layer, thus facilitating the implementation of multiple role-specific applications. This architecture also facilitates the externalization of business logic and knowledge from the applications and their packaging into reusable, centrally-maintained components.
We describe our strategy and experience in federating numerous applications into the institution's clinical information system [9] at Geneva University Hospital, a 2200-bed consortium of primary- secondary- and tertiarycare hospitals.
Materials and Methods
XML, the eXtensible Markup Language [10], provides a syntactic framework that, although powerful and potentially complex, has a favorable learning curve and a widespread acceptance. Its flexibility is particularly suited to rapidly evolving environments. Moreover, most development
Strategy Our strategy is aimed at setting up an environment that increases management and end-users appropriation and
736
Chapter 8: Health Information Systems
replace the project management activities.
environment provide XML support and useful industrial tools are being built around this technology.
Within this setting, a common, shared technical architecture was developed within 6 months (Figure 2). The main challenges were to define the boundaries of each component and to find the right balance between the cost of externalizing business logic and knowledge from applications, and the benefits of reuse and central management.
HTTP, the HyperText Transfer Protocol [11] is the transfer protocol of the Web. It is particularly suited for stateless connections and for the exchange of multiple types of information. Various technologies allow for the implementation of longer-term sessions on top of HTTP. Similarly, HTTP-related encryption and security technologies are well developed. This later point is particularly interesting when distributing the development or the implementation of certain components outside the boundaries of an intranet: firewalls can be configured to allow for selected HTTP messages; for example, the outsourced development of a component can readily be tested with the target environment, thus simplifying development and reducing throw-away code and integration time.
Underlying this architecture, and by far the most discussed but federative effort, is the ongoing task of defining and maintaining a common object model and its translation into XML. Going down to the level of the syntax and terminology within a group that has a view on all projects has proven to be an efficient way of reducing the idiosyncrasies that are common when designing isolated point-to-point interfaces. The two first components developed centrally to be used by all applications reflect the institution's concern on patient data protection: a) a single authorization server that handles access rights at a very granular level, thus preventing distributed applications and components to implement their own authorization logic; b) a single journaling service replacing all logging activities done by application and components, useful not only for an a posteriori access control, but also for the monitoring and debugging of intercomponent transactions.
On the client-side, we opted for a hybrid configuration combining a dedicated client and a Web browser. The Web browser provides the flexibility and power of hypertext and the integration of Web-based applications. The dedicated client provides the high interactivity needed in some information processing tasks, as well as a controlled environment for strong authentication, timeouts, and the control of the lifecycle of locally-stored information, including the cached Web pages used in the integrated Web browser.
The interaction with the hospital information system for authentication, patient tracking (ADT) and order entry/result reporting, typically developed in many clinical applications, is consolidated into a set of components that abstract many of the peculiarities of the underlying systems. This has already proven quite useful when it "protected" the clinical information system from the changes due to the merger of two HIS that followed the merger of two hospitals.
Results The preparation of the numerous institutional information systems for the Y2K transition facilitated the understanding of a need for normalization both at the top-management and at the technical levels. The relative sense of urgency helped opening doors, thus facilitating the inventory of the various systems, databases and interfaces.
New components are mostly developed within the context of specific projects, but in a way that makes them readily available to others. These include nomenclature servers for the nurses charting system, for diagnoses and procedures encoding, the management of user preferences, patient lists, knowledge servers for provider order entry (drugs, protocols), as well as document management tools (indexing, anonymization, report generation).
The shared vision focuses on the quality of care and the collaboration between the various stakeholders in a patientcentered health network. The awakening to the potential of e-Health as well as influential reports on the need for improving the health system [12,13] facilitated this process. The steering committee, composed of senior clinicians, administrators and specialists of legal issues meets every month and deals with the transversal, institutional issues. A larger group, mandated by the hospital direction, works specifically on access rights issues related to the clinical information system. End-users are heavily involved in specific projects and are asked to participate to their neighboring projects.
Discussion The motivation for initiating a federative process implies the recognition, through a common vision, that all the stakeholders will benefit from it. The formulation and wide acceptance of this vision, even if costly to achieve, is therefore a prerequisite.
The technical group has the critical role of "guarding" the architecture and the shared terminologies. It is composed of senior informaticians and project leaders and meets weekly. All projects are reviewed, discussed and technical options are negotiated, voted on if necessary, so that formal decisions can be taken. This group represents the central executive power of the federalist approach. It does not
In a federation, as opposed to a fully distributed system, some level of centralization persists. Central structures should focus on promoting and maintaining the common architecture and should have the resources to implement the
737
Chapter 8: Health Information Systems
access logs analysis
user profiles management
role-adaptable integrated patient recordviewer with data capture, order entry and decision-support tools
role-specifi applications applications role-specific
handheld viewer
application layer
knowledgebases baseseditors editors knowledge
HTTP/XML access logs
ICD coding document anonymizer
authorization authentification
document indexer
problem list
medical orders
distributed printing
drug prescription decision-support
questionnaires PACS
HIS interface critical pathways results user preferences
ADT orders management
document generator
middleware layer
complex access rights
patients lists
nursing nomenclatures
database access
RDBMS
persistence layer
documents DB
Figure 2 - Clinical information system's overall architecture, illustrating the emphasis on building federated business logic components within the middleware layer, thus enabling their reuse in role-specific applications
sharing infrastructure, including the initial overhead for each new member.
The increasing number of components also complicates systematic authorization at the service level. The implementation of signed services using certificates is considered.
However, the success of the federation can only be acknowledged when members start working not only with others, but also for others, when the overhead due to harmonization and negotiation is effectively outweighed by the benefits of integration, scalability and coherence.
Finally, when standard clinical XML-based object models [7] mature and get wider acceptance, these should become the target for the evolution path of our clinical system's object model.
In our experience, it took twelve months from the initial elaboration of the common vision to reach this stage, during which the key element for success was the capacity of the technical group to keep the focus and motivation, despite natural tendencies to revert to a more fragmented world.
Conclusion When integrated in a strategy for institutional appropriation and change management, the use of non-intimidating technologies such as XML and HTTP can help federate components into a coherent, scaleable clinical information system.
Another success factor was the association of the two processes (what to share-externalize, how to sharecommunicate) within the context of a favorable framework (strong central support and resources) as well as the use of non-intimidating technologies for sharing (XML and HTTP). The simultaneous work on both externalization and harmonization helped move the impact of the reflection deeper into each application, and created a more uniform approach to further developments.
References [1] West RT. IAIMS: an interview with Dick West. Integrated Advanced Information Management Systems. J Am Med Inform Assoc 1999;6:447-456
Future plans
[2] Stead WW. The evolution of the IAIMS: lessons for the next decade. J Am Med Inform Assoc 1997;4:S4-9
With the growth of the clinical information system, it becomes necessary to deal more effectively with events and notifications, including the functionality of a publishsubscribe service, for which HTTP is not well-suited.
[3] Massaro TA. Introducing physician order entry at a major academic medical center: I. Impact on
738
Chapter 8: Health Information Systems
organizational culture 1993;68:20-25
and
behavior.
Acad
architecture paradigm with special emphasis on its middleware design. In: Iakovidis I, Maglavera S, Trakatellis A (eds.), User acceptance of health telematics applications, looking for convincing cases, 1997. IOS Press, Amsterdam 1998:15-31
Med
[4] Friedman CP, Corn M, Krumrey AJ, Perry DR, Stevens RH. Managing information technology in academic medical centers: a "multicultural" experience. Acad Med 1998;73:975-979
[10] http://www.w3.org/XML/
[5] Cimino JJ, Johnson SB, Hripcsak G, Hill CL, Clayton PD. Managing vocabulary for a centralized clinical system. Medinfo 1995;8:117-120
[11] http://www.w3.org/Protocols/ [12] Kohn LT, Corrigan JM, Donaldson MS, eds. To Err is Human: Building a Safer Health System. Washington, DC: Institute of Medicine; National Academy Press, 2000
[6] Dolin RH, Alschuler L, Behlen F, et al. HL7 document patient record architecture: an XML document architecture based on a shared information model. Proc AMIA Symp 1999:52-6
[13] Leape LL. Error in medicine. JAMA 1994;272:18511857
[7] Dolin RH, Alschuler L, Boyer S, Beebe C. An Update on HL7's XML-based Document Representation Standards. Proc AMIA Symp 2000: 190-4
Address for correspondence Prof. Antoine Geissbuhler MD Division of Medical Informatics Geneva University Hospital 24, rue Micheli-du-Crest 1211 Geneva 14, Switzerland
[8] Kahn CE, de la Cruz NB. Extensible markup language (XML) in health care: integration of structured reporting and decision support. Proc AMIA Symp 1998:725-729
[email protected]
[9] Scherrer JR, Lovis C, Baud R, Borst F. Integrated computerized patient records: the Diogene 2 distributed
739
