37-semantic Integration In Healthcare Networks

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 ( 2 0 0 7 ) 201–207

journal homepage: www.intl.elsevierhealth.com/journals/ijmi

Semantic integration in healthcare networks Richard Lenz a,∗ , Mario Beyer a , Klaus A Kuhn b a b

¨ Marburg, Institut fur ¨ Medizinische Informatik, Bunsenstrasse 3, 35037 Marburg, Germany Philipps-Universitat ¨ Munchen, ¨ ¨ Medizinische Informatik, Munich, Germany Technische Universitat Lehrstuhl fur

a r t i c l e

i n f o

a b s t r a c t

Article history:

A seamless support of information flow for increasingly distributed healthcare processes

Received 31 December 2005

requires to integrate heterogeneous IT systems into a comprehensive distributed infor-

Received in revised form

mation system. Different standards contribute to ease this integration. In a research

23 March 2006

project focussing on the development of a reference architecture for inter-institutional

Accepted 2 May 2006

health information systems, we identified concurring standards currently in use. We therefore categorized these integration standards by distinguishing between technical and semantic integration on the one hand, and data and functional integration on

Keywords:

the other hand. In addition, standards for semantic integration are roughly categorized

Information systems [MeSH]

according to their scope. By placing standards into a corresponding matrix a “seman-

Information management [MeSH]

tic gap” is revealed, which cannot be covered by standards as it contains volatile

Hospital information systems

medical concepts. As a conclusion, it is recommended to conceptually consider the

[MeSH]

necessity of system evolution in system architectures and also in future integration standards. © 2006 Elsevier Ireland Ltd. All rights reserved.

1.

Introduction

Healthcare increasingly changes from isolated treatment episodes towards a continuous treatment process involving multiple healthcare professionals and various institutions. This change motivates comprehensive, inter-institutional IT support in health information systems and imposes new demanding requirements for IT [1]. IT applications should guide data acquisition in a way that data are placed in a meaningful context from the beginning, so that they are ready for reuse in different contexts without the need to manually index or transform the data. To achieve such an IT support, heterogeneous IT systems have to be integrated into a comprehensive distributed information system. Integrating autonomous software components, however, is a difficult task, as individual applications usually are not designed to cooperate. Applications are often based on differing conceptualizations of the application domain. Today powerful integration

∗

tools (e.g. application servers, object brokers, different kinds of message-oriented middleware, and workflow management systems [2]) are available to overcome technical and syntactical heterogeneity of autonomous system components. Yet, semantic heterogeneity remains as a major barrier to seamless integration of autonomously developed software components (cf. [3]). Semantic heterogeneity occurs when there is disagreement about the meaning, interpretation or intended use of the same or related data [4]. It occurs in different contexts, like database schema integration, ontology mapping, or integration of different terminologies. The underlying problems are more or less the same, though they are often complex and still poorly understood. Stonebraker characterizes disparate systems as “islands of information” and points out two major factors which aggravate systems integration [5]: 1. Each island (i.e. application) will have its own meaning of enterprise objects.

Corresponding author. Tel.: +49 6421 28 66205; fax: +49 6421 28 63599. E-mail address: [email protected] (R. Lenz). 1386-5056/$ – see front matter © 2006 Elsevier Ireland Ltd. All rights reserved. doi:10.1016/j.ijmedinf.2006.05.008

202

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 ( 2 0 0 7 ) 201–207

2. Each island will have data that overlaps data in other islands. This partial redundancy generates a serious data integrity problem. Based on this statement, data integration can be led back to a mapping problem (how to map different conceptualizations in a semantically correct way) and a synchronization problem (how to ensure mutual consistency of redundant data which are stored in different databases under the control of autonomous applications). The mapping problem is essentially related to the schema integration problem of database systems, which has been extensively discussed in the database literature in recent years (e.g. [6–9]). A major perception in data integration research has been that schema integration cannot be automated in general. In [10] it is stated: “The general problem of schema integration is undecidable.” Heiler states that “understanding data and software can never be fully automated” [11]. As a consequence, the process of schema integration always needs a human integrator for certain semantic decisions. Colomb even goes a step further by stating that there are cases where no consistent interpretation of heterogeneous sources is possible (“fundamental semantic heterogeneity”) [12]. In such cases one either has to accept a low degree of data quality, or systems have to be modified to resolve fundamental semantic heterogeneity. In order to reduce the integration efforts caused by semantic heterogeneity standards for systems integration are needed. Moreover, as medicine is a rapidly evolving domain, concepts for system evolution are needed. Fortunately, there are already far reaching standards that support information interchange in the medical domain. Yet, healthcare software is still far away from plug and play compatibility, and systems integration is typically a difficult process. In a research project in which we focus on the development of a reference architecture for comprehensive information systems in healthcare networks [1,13], we have identified concurring and semantically overlapping standards. To get an overview of the standards’ characteristics and interrelations, we have arranged them to a system of standards which we find to be helpful for architecture development.

2.

Objectives

In this article we try to clarify how different standards contribute to systems integration by distinguishing different aspects and dimensions of integration. The objective of this approach is to identify and characterize the “semantic gap” which is not covered by current standards, and which is responsible for the high effort for systems integration. The goal of this clarification is to derive recommendations for future system architectures and standards development.

3.

Methods

At a conceptual level, information systems are designed around three layers: presentation, application logic, and resource management [2]. According to this well known abstract model of information systems, we distinguished dif-

ferent aspects of integration: data integration, functional integration and presentation integration: • Data integration: we have already characterized semantic heterogeneity as the main cause for high integration efforts. We thereby focused on data integration. The reason for this is that data integration is considered to be the most important precondition for further integration. It is the backbone and starting point of each successful integration project, because any process control always requires a meaningful exchange of data, too. The goal of data integration is to create a unique semantic reference for commonly used data and to ensure data consistency. To create such a semantic reference different facets of data semantics have to be considered. In this article three facets are roughly distinguished: ◦ The instance level, referring to the semantics of individual data objects, which corresponds to the meaning of entries in a database. ◦ The type level, designating the semantic classification of data objects, which roughly corresponds to the database schema. ◦ The context, which refers to the semantic relationships that associate an object with other objects. To illustrate the difference of these aspects we may consider a concept “diagnosis” on the type level, and a particular instance, say “encephalitis”, and the context of this instance, which is determined by the patient, the physician who made the diagnosis, and other objects that contribute to a particular statement (information). • Functional integration refers to the meaningful cooperation of functions of different software components. Uncontrolled data redundancy is often the result of an insufficient functional integration of disparate systems. Autonomously developed systems often overlap in their functionality, partly providing the same or only slightly differing functionality. This aggravates integration even if the systems are already based on common ontologies. In our characterization of integration aspects data integration is concerned with the consolidation of declarative knowledge, while functional integration is concerned with the consolidation of procedural knowledge on which applications are based. Both aspects have to be considered for application integration. • Desktop integration or presentation integration refers to the user interface of a distributed system. Desktop integration is aimed at user transparency, meaning that the user would not know what application was being used or what database was being queried [14]. This requires more than a unified layout and uniform interaction mechanisms. Examples for functions needed to achieve desktop integration are “single sign-on” and “desktop synchronization”. Desktop synchronization is needed when a user has multiple windows to different applications on her desktop that share a common context. Synchronization is required when the context is changed in one of the interlinked applications. Another orthogonal aspect of integration standards is their scope. We can distinguish between technical and semantic integration. By “technical integration” we refer to the tech-

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 ( 2 0 0 7 ) 201–207

Table 1 – A classification of integration standards Technical integration

Semantic integration

Data integration

Syntactic frameworks

Ontology and vocabulary

Functional integration

Middleware

Application frameworks

nical infrastructure which supports application integration. “Semantic integration”, in contrast, refers to the meaning of data and functions. By contrasting the scope with data and functional integration we receive a rough matrix that helps to characterize different integration standards (Table 1). Subsequently we explain how different standards can be positioned into this matrix. Desktop integration has not been explicitly mentioned in our matrix, because standards supporting desktop integration cover both functional and data integration aspects. The architecture of a distributed system must adhere to certain requirements, such as a central context manager, in order to enable desktop synchronization. Moreover, the applications to be synchronized must agree on the semantics of context data and on a common coordination protocol for context synchronization. Note, that the remaining distinction between data integration and functional integration corresponds to the well known distinction between declarative and procedural knowledge, respectively.

4.

Results

XML and RDF are examples for standard syntactic frameworks supporting data integration [15]. Standards for semantic integration in healthcare are increasingly based on XML in order to improve syntactical compatibility with commonly accepted data processing formats. Middleware standards typically provide a common infrastructure for interconnecting distributed software components. Such standards are primarily intended to provide programming abstractions, which help a programmer to easily bridge different hardware, operating systems, and programming languages. Examples for standardization efforts in this area are CORBA, .net, EJB, or Web Services. Ontologies and vocabulary standards support semantic data integration, as they serve as a semantic reference for system programmers and users (cf. [16]). Considering the different facets of data integration we find that well accepted standards like HL7 V2 and DICOM are primarily concerned with organizational issues on a type level and rarely provide means for terminological control on the instance level. Newly arising standards like CDA [17,18] and DICOM SR are intended to support the interchange of medical contents also on the type and context levels. There are numerous standards that support terminological control for medical issues at an instance level, and the necessity to interlink such terminological standards with the data definitions in HL7 and other type level standards has been widely recognized (e.g. [19,20]). Practical examples demonstrate how to effectively combine different standards on the type and instance level in order to gain more

203

comprehensive semantic compatibility [21]. The German SCIPHOX project provides a practical example of how to combine CDA with standards on the terminological level [22]. Despite well accepted standards for data integration like HL7 V2 and DICOM, healthcare applications are still far from plug and play compatibility. One reason for this is that the existing standards do not address functional integration issues sufficiently. Autonomously developed system components typically overlap in their functionality and it is not clear, how different components should interact in order to perform a common task. In order to avoid these difficulties common application frameworks are required which serve as an additional semantic reference for programmers to create functionally compatible software components. Requirements for such an application framework directed towards open systems in the healthcare domain are described in [23]. In general such a framework must provide clear specifications of interfaces and interaction protocols which are needed for embedding a software component into a system of cooperating components. The best example for such a standard in the healthcare domain is the IHE initiative (“Integrating the Healthcare Enterprise”) [24]. IHE does not develop new standards for data interchange but specifies integration profiles on the basis of HL7 V2 and DICOM. Thereby “actors” and “transactions” are defined independently from any specific software product. An integration profile specifies how different actors interact via IHE transactions in order to perform a special task. These integration profiles serve as a semantic reference for application programmers, so that they can build software products that can be functionally integrated into an IHE conformant application framework. HL7 V3 will also take a step into this direction, as conformance to HL7 V3 is specified in terms of “application roles” [25]. Like IHE actors, an application role is associated with some dedicated functionality (e.g. “lab order sender”)—it comprises a set of trigger events, messages and data elements which are needed to integrate an IT component with this functionality. An IT component will typically fill many such application roles. Fig. 1 shows a rough characterization of standards according to our classification matrix. The position of HL7 in this diagram refers to HL7 V2. Some improvements that come with HL7 V3 and related standards are roughly indicated by circles for RIM, CDA and CCOW [26]. The intention of the diagram is not to precisely and comprehensively classify the different standards but to get an idea which aspects of semantic integration are typically covered by such standards. It turns out that there is a gap in the lower right corner where standardized medical processes could have been expected (such as IHE addresses organizational processes). Medical pathways and guidelines fall into this category. This is essentially medical knowledge which has to be consented by medical experts and which evolves over time. Consented medical knowledge is necessary for cooperative patient treatment, but it is probably unsuitable as a subject of standardization, as it evolves rapidly. Note that common formats for knowledge representation (e.g., Arden Syntax [27], GLIF [28,29] PROforma [30], EON [31], Asbru [32], etc.—surveys in [33–36]) are related to this problem, but do not fill this gap, as they typically only provide standardized syntactical frameworks for medical knowledge.

204

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 ( 2 0 0 7 ) 201–207

Though such common knowledge representation formats are an essential precondition for knowledge exchange among disparate systems, semantic integration is not addressed by them. The data definitions in pre-defined formal guidelines may not map to the data available in an existing electronic health record system [37] unless additional standards for semantic data integration on type and instance level are considered. In practice very often operational systems have to be modified and extended in order to acquire the necessary information needed for guideline implementation. Moreover, effectively implementing guidelines in a specific healthcare setting requires a careful and coordinated evolution of both medical treatment processes and embedded healthcare applications in order to support organizational learning [38]. Standards can only support generic process patterns which remain stable over longer periods of time. In order to provide adequate and embedded decision support IT systems must be capable of flexibly adapting to new requirements. Fig. 1 also contains numerous standards for medical terminology. Yet, despite of many attempts, a unique and comprehensive ontology of the medical domain is not within sight. A closer look at the given examples would reveal that medical terminologies continuously evolve over time (cf. [39]), and that there is no stable unique reference for system programmers. Thus, semantic integration of heterogeneous systems in healthcare will have to deal with volatile medical concepts.

5.

Discussion and conclusions

Different kinds of standards are necessary to ease systems integration. In particular, both reference ontologies and application frameworks are needed to support semantic integration. Yet, standards should not try to comprehensively model an application domain, because systems must be capable to rapidly adapt to an evolving application domain. If IT systems should bring medical knowledge to the point of care they must be capable of incorporating the results of ongoing consensus processes among healthcare professionals into a concrete setting [40]. Thus, the evolution of information systems should be

a demand-driven process under the control of healthcare professionals. Process integration is concerned with the alignment of IT systems to actual business processes in a concrete setting. This is not addressed by standards, but by appropriate models for demand-driven software development (e.g. [41]). Desiderata for such a demand-driven process are. • Rapid application development: In order to be able to flexibly react to newly arising demands, tools and techniques for rapid application development (RAD) are desirable. To reuse existing data and services and to achieve integrated applications, such tools should be built upon a standard IT infrastructure for healthcare networks. • Robust and stable integrated domain-specific IT infrastructure: An IT infrastructure for a healthcare network should provide a robust and stable basis for application development. Thus, the framework should be based on generic but stable domain models instead of comprehensive but volatile domain models. • Separation of domain concepts and system implementation: In order to cope with domain evolution, modeling of domain concepts should be separated from IT system implementation. IT systems should be implemented by IT experts and medical knowledge should be modeled and maintained by domain experts. Yet, separating the modeling of medical knowledge from implementing an IT infrastructure is not easy, because algorithms (such as reminder systems) typically refer to medical knowledge in order to fulfill their task. • Multi-level software engineering approach: To bring application development as close to the end user as possible, a multi-layered software engineering approach is proposed. An idealized abstract model for such a multi-level approach for software engineering is shown in Fig. 2. The basic idea is to distinguish different competencies and different responsibilities on the different layers of system design. The aim is to reduce complexity within each layer and to provide reusable services for higher layers. • Layered ontologies: To support semantic integration within such a layered approach, layered ontologies are needed,

Fig. 1 – Contribution of different standards to application integration.

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 ( 2 0 0 7 ) 201–207

205

Fig. 2 – A layered approach for system evolution.

which may serve as semantic references on different levels of software development. The layered approach of the clinical document architecture (CDA), and the generic HL7 V3 reference information model (RIM) are emerging standards which are already built on this fundamental principle (cf. [19]). Yet, these standards are not explicitly aimed at supporting a multilevel software-engineering process as suggested here. This would require to assign responsibilities to the different layers. However, the layered approach of CDA already helps to incrementally improve semantic compatibility within an evolving healthcare information system and to support a stepwise migration process. Layered approaches have proven to be a successful technique for separating concerns and reducing system complexity (cf. [42,43]). Transferring this principle to the development of information systems in complex application domains is aimed at allowing application developers and end users to build well integrated healthcare applications without the need to do low level coding and debugging [41]. Appropriate tool support is needed at each level of abstraction in order to effectively make use of the lower system layers. A layered approach, as sketched above, fosters a system evolution process that follows the principle of “deferred systems design” [44], which is aimed at closing the gap between systems design and healthcare process reality [45]. Volatile concepts are not pre-modeled and hard-coded in software, instead knowledge can be added or modified on demand and at runtime, as the domain evolves. We have presented a layered model which can be used as an abstract reference model for evolutionary information systems. An example for an adaptation of this model to a real world hospital information system on the basis of commercially available system components is given in [41]. This adaptation is limited in several respects: as commercial vendors typically do not adhere to standard architectural layer-

ings a proprietary vendor-specific approach had to be adopted. This approach allows for site-specific demand-driven software development on the basis of a generic core system. The approach supports both system integration and system evolution at the cost of vendor dependency and limited expressiveness. Semantic integration in widespread healthcare networks will necessarily require more general approaches, as singlevendor solutions are not applicable to fully support crossorganizational processes. Multi-layered service-oriented architectures are expected to provide a suitable technical platform for IT support in heterogeneous healthcare networks, as they provide the necessary technical infrastructure for loosely coupled interoperating components [1,46]. Generic healthcare-specific services could be implemented on the basis of this infrastructure providing a stable domain-specific platform for distributed healthcare applications. Examples for core services might include patient identification and lexical query. The latter can help to separate terminological control from application development. A successful proprietary example of a terminology server is the Medical Entities Dictionary (MED) from Columbia Presbyterian Medical Center [47,48]. Functional interfaces for such services have already been proposed in various attempts aimed at standardization of healthcare-specific middleware (e.g. HISA [49] or CORBAmed [50]). Research prototypes based on these recommendations have already been developed [51]. In addition to such a basic healthcare-specific service infrastructure there is a need for concepts that help to separate different layers of software engineering, as different responsibilities and competencies are to be addressed for technological evolution, domain evolution, and site-specific adaptation. A first step towards such a separation of concerns is provided by the “archetype” approach, which has been developed in the context of the GEHR project [52,53]. This concept is aimed at separating IT systems from domain

206

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 ( 2 0 0 7 ) 201–207

knowledge, in order to enable medical knowledge to be modeled by domain experts rather than IT specialists. Archetypes are focused on the specification of declarative medical knowledge. However, as we have seen in our discussion of standards, procedural knowledge is equally important for seamless integration and it also evolves rapidly. Thus, in addition to standard formats for guideline representation we also need architectural approaches that allow for separate specification of medical guidelines. Such issues have been addressed in the context of research projects like EON [54] and GUIDE [55], which strictly follow the idea of separation of concerns. Despite of many promising approaches there are still numerous challenges to solve before comprehensive evolutionary information systems for healthcare networks can become a reality. To develop future-proof IT platforms we should keep in mind that these systems are part of complex socio-technical systems which can only be effective if they flexibly support organizational learning.

references

[1] M. Beyer, K.A. Kuhn, C. Meiler, S. Jablonski, R. Lenz, in: H. Haddad, A. Omicini, R.L. Wainwright, L.M. Liebrock (Eds.), Towards a Flexible, Process-oriented IT Architecture for An Integrated Healthcare Network, ACM, 2004, pp. 264–271. [2] G. Alonso, F. Casati, H. Kuno, V. Machiraju, Web Services—Concepts, Architectures and Applications, Springer, Berlin, 2003. [3] J.T. Pollock, The Web Services Scandal—How Data Semantics Have Been Overlooked in Integration Solutions, EAI J. (2002) 20–23. [4] A. Sheth, J. Larsen, Federated database systems for managing distributed, heterogeneous, and autonomous databases, ACM Comput. Surv. 22 (3) (1990) 183–235. [5] M. Stonebraker, Integrating islands of information, EAI J. (1999) 1–5. [6] A. Elmagarmid, M. Rusinkiewicz, A. Sheth (Eds.), Management of Heterogeneous and Autonomous Database Systems, Morgan Kaufmann Publishers, San Francisco, California, 1999. [7] S. Conrad, Schemaintegration-Integrationskonflikte, ¨ ¨ Losungsans atze, aktuelle Herausforderungen, Informatik Forschung Entwicklung (17) (2002) 101–111. [8] A. Bouguettaya, B. Benatallah, A. Elmagarmid, Interconnecting Heterogeneous Information Systems, Kluwer Academic Publishers, Boston, 1998. [9] E. Rahm, P.A. Bernstein, A survey of approaches to automatic schema matching, VLDB J. 2001 (10) (2001) 334–350. [10] C. Batini, M. Lenzerini, S.B. Navathe, A comparative analysis of methodologies for database schema integration, ACM Comput. Surv. 18 (4) (1986) 323–364. [11] S. Heiler, Semantic interoperability, ACM Comput. Surv. 27 (2) (1995) 271–273. [12] R.M. Colomb, Impact of semantic heterogeneity on federating databases, Comput. J. 40 (5) (1997) 235–244. [13] R. Lenz, M. Beyer, C. Meiler, S. Jablonski, K.A. Kuhn, Informationsintegration in Gesundheitsversorgungsnetzen-Herausforderungen an die Informatik, Inform. Spekt. 28 (2) (2005) 105–119. [14] B.T. Pille, R.K. Antczak, Application integration, in: M.J. Ball, J.V. Douglas (Eds.), Performance Improvement Through Information Management, Springer, New York, 1999, pp. 144–152.

¨ [15] H. Schoning, XML und Datenbanken—Konzepte und ¨ Systeme, Carl Hanser Verlag, Munchen, 2003. [16] R. Lenz, K.A. Kuhn, Intranet meets hospital information systems: the solution to the integration problem? Meth. Inform. Med. 40 (2) (2001) 99–105. [17] R.H. Dolin, L. Alschuler, C. Beebe, P.V. Biron, S.L. Boyer, D. Essin, et al., The HL7 clinical document architecture, J. Am. Med. Inform. Assoc. 8 (6) (2001) 552–569. [18] R.H. Dolin, L. Alschuler, S. Boyer, C. Beebe, F.M. Behlen, P.V. Biron, et al., HL7 clinical document architecture, release 2, J. Am. Med. Inform. Assoc. 13 (1) (2005) 30–39. [19] G.W. Beeler, HL7 version 3—an object-oriented methodology for collaborative standards development, Int. J. Med. Inform. 48 (1–3) (1998) 151–161. [20] P.E. Zanstra, A.L. Rector, W. Ceusters, P.F. de Vries Robbe, Coding systems and classifications in healthcare: the link to the record, Int. J. Med. Inform. 48 (1–3) (1998) 103–109. [21] J.F. Coyle, A.R. Mori, S.M. Huff, Standards for detailed clinical models as the basis for medical data exchange and decision support, Int. J. Med. Inform. 69 (2–3) (2003) 157–174. [22] K.U. Heitmann, R. Schweiger, J. Dudeck, Discharge and referral data exchange using global standards—the SCIPHOX project in Germany, Int. J. Med. Inform. 70 (2–3) (2003) 195–203. ¨ [23] R. Lenz, S. Huff, A. Geissbuhler, Report of conference track. 2. Pathways to open architectures, Int. J. Med. Inform. 69 (2–3) (2003) 297–299. [24] P. Vegoda, Introducing the IHE (Integrating the Healthcare Enterprise) concept, J. Health Inform. Manag. 16 (1) (2002) 22–24. [25] Health Level Seven I. HL7 Version 3 Statement of Principles. Health Level Seven Inc., URL: http://www.hl7.org/Library/datamodel/SOP 980123 final.zip. [26] R. Seliger, Overview of HL7’s CCOW Standard. Health Level Seven Inc., URL: http://www.hl7.org/library/committees/ sigvi/ccow overview 2001.doc. [27] R.A. Jenders, G. Hripcsak, R.V. Sideli, W. DuMouchel, H. Zhang, J.J. Cimino, et al. Medical decision support: experience with implementing the Arden Syntax at the Columbia—Presbyterian Medical Center. In: Proceedings of the Annual Symposium on Comput. Appl. Med. Care, 1995, pp. 169–173. [28] L. Ohno-Machado, J.H. Gennari, S.N. Murphy, N.L. Jain, S.W. Tu, D.E. Oliver, et al., The guideline interchange format: a model for representing guidelines, J. Am. Med. Inform. Assoc. 5 (4) (1998) 357–372. [29] M. Peleg, A.A. Boxwala, O. Ogunyemi, Q. Zeng, S. Tu, R. Lacson, et al., GLIF3: the evolution of a guideline representation format, Proc. AMIA Symp. (2000) 645–649. [30] J. Fox, N. Johns, A. Rahmanzadeh, Disseminating medical knowledge: the PROforma approach, Artif. Intell. Med. 14 (1–2) (1998) 157–181. [31] M.A. Musen, Domain ontologies in software engineering: use of Protege with the EON architecture, Meth. Inf. Med. 37 (4–5) (1998) 540–550. [32] Y. Shahar, S. Miksch, P. Johnson, An intention-based language for representing clinical guidelines, Proc. AMIA Annu. Fall Symp. (1996) 592–596. [33] P.A. de Clercq, J.A. Blom, H.H. Korsten, A. Hasman, Approaches for creating computer-interpretable guidelines that facilitate decision support, Artif. Intell. Med. 31 (1) (2004) 1–27. [34] R. Van de Velde, P. Degoulet, Clinical Information Systems, Springer-Verlag, New York, 2003. [35] M. Peleg, S. Tu, J. Bury, P. Ciccarese, J. Fox, R.A. Greenes, et al., Comparing computer-interpretable guideline models: a

i n t e r n a t i o n a l j o u r n a l o f m e d i c a l i n f o r m a t i c s 7 6 ( 2 0 0 7 ) 201–207

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43] [44] [45]

case-study approach, J. Am. Med. Inform. Assoc. 10 (1) (2003) 52–68. P. Votruba, S. Miksch, R. Kosara, Facilitating knowledge maintenance of clinical guidelines and protocols, Medinformation (2004) 57–61. T.A. Pryor, G. Hripcsak, Sharing MLM’s: an experiment between Columbia-Presbyterian and LDS Hospital. In: Proceedings of the Annual Symposium on Comput. Appl. Med. Care, 1993, pp. 399–403. R. Lenz, M. Reichert, IT support for healthcare processes—premises, challenges, perspectives. Data Know. Eng., in press. C.J. McDonald, J.M. Overhage, P. Dexter, B. Takesue, J.G. Suico, What is done, what is needed and what is realistic to expect from medical informatics standards, Int. J. Med. Inform. 48 (1–3) (1998) 5–12. R. Lenz, M. Reichert, IT support for healthcare processes, in: W. van der Aalst, B. Benatallah, F. Casati, F. Curbera (Eds.), Business Process Management, Springer, Berlin, 2005, pp. 354–363. R. Lenz, K.A. Kuhn, Towards a continuous evolution and adaptation of information systems in healthcare, Int. J. Med. Inform. 73 (1) (2004) 75–89. ¨ T. Harder, Realisierung von operationalen Schnittstellen, in: P.C. Lockemann, J.W. Schmidt (Eds.), Datenbank-Handbuch, Springer-Verlag, Berlin, 1987. A.S. Tanenbaum, Computer Networks. 2nd. Aufl., Prentice-Hall, Englewood Cliffs, NJ, 1988. N. Patel, Adaptive Evolutionary Information Systems, Idea Group Publishing, London, 2003. R. Heeks, Health information systems: Failure, success and improvisation, Int. J. Med. Inform. 75 (2) (2006) 125–137.

207

[46] J. Mykkanen, J. Porrasmaa, J. Rannanheimo, M. Korpela, A process for specifying integration for multi-tier applications in healthcare, Int. J. Med. Inform. 70 (2–3) (2003) 173–182. [47] B.H. Forman, J.J. Cimino, S.B. Johnson, S. Sengupta, R. Sideli, P. Clayton, Applying a controlled medical terminology to a distributed, production clinical information system, in: Proceedings of the Annual Symposium on Comput. Appl. Med. Care, 1995, pp. 421–425. [48] J.J. Cimino, From data to knowledge through concept-oriented terminologies: experience with the Medical Entities Dictionary, J. Am. Med. Inform. Assoc. 7 (3) (2000) 288–297. [49] J.R. Scherrer, S. Spahni, Healthcare information system architecture (HISA) and its middleware models, in: Proceedings of AMIA Symposium, 1999, pp. 935–939. [50] B. Blobel, M. Holena, Comparing middleware concepts for advanced healthcare system architectures, Int. J. Med. Inform. 46 (2) (1997) 69–85. [51] N. Saranummi, PICNIC architecture, Stud. Health Technol. Inform. (2005) 37–60. [52] T. Beale, Archetypes and the EHR, Stud. Health Technol. Inform. 96 (2003) 238–244. [53] T. Beale, Archetypes: constraint-based domain models for future-proof information systems. In: OOPSLA 2002 Workshop on Behavioural Semantics, 2002. [54] M.A. Musen, Y. Shahar, E.H. Shortliffe, Clinical decision support systems, in: E.H. Shortliffe, L.E. Perreault, G. Wiederhold, L.M. Fagan (Eds.), Medical Informatics—Computer Applications in Healthcare and Biomedicine, Springer, New York, 2000, pp. 573–609. [55] P. Ciccarese, E. Caffi, S. Quaglini, M. Stefanelli, Architectures and tools for innovative Health Information Systems: the Guide Project, Int. J. Med. Inform. 74 (7–8) (2005) 553–562.