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 Philipps-Universität Marburg, Institut für Medizinische Informatik, Bunsenstrasse 3, 35037 Marburg, Germany
b Technische Universität München, Lehrstuhl für Medizinische Informatik, Munich, Germany

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 tools (e.g. application servers, object brokers, different kinds

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 manu-
ally index or transform the data. To achieve such an IT sup-
port, 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 cooper-
ate. Applications are often based on differing conceptualiza-
tions of the application domain. Today powerful integration
of message-oriented middleware, and workflow management
systems [2]) are available to overcome technical and syntac-
tical 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 disagree-
ment 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 integra-
tion 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: lenzr@staff.uni-marburg.de (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 conceptual-
izations in a semantically correct way) and a synchroniza-
tion problem (how to ensure mutual consistency of redun-
dant 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 per-
ception 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 inte-
gration 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 hetero-
geneous sources is possible (“fundamental semantic heterogene-
ity”) [12]. In such cases one either has to accept a low degree
of data quality, or systems have to be modified to resolve fun-
damental 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 archi-
tecture for comprehensive information systems in healthcare
networks [1,13], we have identified concurring and semanti-
cally overlapping standards. To get an overview of the stan-
dards’ 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 con-
tribute 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 inte-
gration 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 impor-
tant 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 cre-
ate a unique semantic reference for commonly used data
and to ensure data consistency. To create such a seman-
tic reference different facets of data semantics have to be
considered. In this article three facets are roughly distin-
guished:
◦ 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 con-
sider a concept “diagnosis” on the type level, and a par-
ticular 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. Uncon-
trolled 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 func-
tionality. This aggravates integration even if the systems
are already based on common ontologies. In our charac-
terization of integration aspects data integration is con-
cerned with the consolidation of declarative knowledge,
while functional integration is concerned with the consoli-
dation 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 synchro-
nization 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 Semantic
integration integration
Data integration Syntactic Ontology and
frameworks 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). Subse-
quently 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 integra-
tion 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 synchro-
nization. Note, that the remaining distinction between data
integration and functional integration corresponds to the well
known distinction between declarative and procedural knowl-
edge, respectively.
4. Results
XML and RDF are examples for standard syntactic frameworks
supporting data integration [15]. Standards for semantic inte-
gration 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 infras-
tructure for interconnecting distributed software compo-
nents. Such standards are primarily intended to provide pro-
gramming abstractions, which help a programmer to easily
bridge different hardware, operating systems, and program-
ming 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 orga-
nizational issues on a type level and rarely provide means
for terminological control on the instance level. Newly aris-
ing 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 sup-
port terminological control for medical issues at an instance
level, and the necessity to interlink such terminological stan-
dards 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 SCI-
PHOX 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 compo-
nents 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 addi-
tional semantic reference for programmers to create function-
ally 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 compo-
nents. The best example for such a standard in the healthcare
domain is the IHE initiative (“Integrating the Healthcare Enter-
prise”) [24]. IHE does not develop new standards for data inter-
change 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 inte-
gration profile specifies how different actors interact via IHE
transactions in order to perform a special task. These inte-
gration 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 appli-
cation framework.
HL7 V3 will also take a step into this direction, as confor-
mance 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 com-
prises 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 accord-
ing 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 differ-
ent 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 stan-
dardized medical processes could have been expected (such
as IHE addresses organizational processes). Medical pathways
and guidelines fall into this category. This is essentially med-
ical 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 prob-
ably unsuitable as a subject of standardization, as it evolves
rapidly. Note that common formats for knowledge represen-
tation (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 dis-
parate 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 modi-
fied and extended in order to acquire the necessary informa-
tion needed for guideline implementation. Moreover, effec-
tively 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 termi-
nology. Yet, despite of many attempts, a unique and compre-
hensive ontology of the medical domain is not within sight.
A closer look at the given examples would reveal that medi-
cal terminologies continuously evolve over time (cf. [39]), and
that there is no stable unique reference for system program-
mers. 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 appli-
cation frameworks are needed to support semantic integra-
tion. 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 set-
ting [40]. Thus, the evolution of information systems should be
Fig. 1 – Contribution of different standards to application integration.
a demand-driven process under the control of healthcare pro-
fessionals. Process integration is concerned with the alignment
of IT systems to actual business processes in a concrete set-
ting. 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 flex-
ibly 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 infrastruc-
ture: An IT infrastructure for a healthcare network should
provide a robust and stable basis for application develop-
ment. 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 implementa-
tion: 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 model-
ing of medical knowledge from implementing an IT infras-
tructure 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 appli-
cation 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 respon-
sibilities 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,
 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
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 clin-
ical 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 sup-
porting a multilevel software-engineering process as sug-
gested here. This would require to assign responsibilities to
the different layers. However, the layered approach of CDA
already helps to incrementally improve semantic compati-
bility within an evolving healthcare information system and
to support a stepwise migration process.
Layered approaches have proven to be a successful tech-
nique for separating concerns and reducing system complex-
ity (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 effec-
tively make use of the lower system layers.
A layered approach, as sketched above, fosters a system
evolution process that follows the principle of “deferred sys-
tems 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 com-
mercially available system components is given in [41]. This
adaptation is limited in several respects: as commercial ven-
dors typically do not adhere to standard architectural layer-
205
ings a proprietary vendor-specific approach had to be adopted.
This approach allows for site-specific demand-driven soft-
ware development on the basis of a generic core system. The
approach supports both system integration and system evolu-
tion at the cost of vendor dependency and limited expressive-
ness. Semantic integration in widespread healthcare networks
will necessarily require more general approaches, as single-
vendor solutions are not applicable to fully support cross-
organizational processes.
Multi-layered service-oriented architectures are expected
to provide a suitable technical platform for IT support in het-
erogeneous healthcare networks, as they provide the nec-
essary technical infrastructure for loosely coupled interop-
erating components [1,46]. Generic healthcare-specific ser-
vices could be implemented on the basis of this infras-
tructure providing a stable domain-specific platform for dis-
tributed healthcare applications. Examples for core services
might include patient identification and lexical query. The
latter can help to separate terminological control from appli-
cation 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 var-
ious attempts aimed at standardization of healthcare-specific
middleware (e.g. HISA [49] or CORBAmed [50]). Research pro-
totypes 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 sep-
arate 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 con-
cerns 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 mod-
eled by domain experts rather than IT specialists. Archetypes
are focused on the specification of declarative medical knowl-
edge. However, as we have seen in our discussion of stan-
dards, procedural knowledge is equally important for seam-
less integration and it also evolves rapidly. Thus, in addi-
tion 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 evo-
lutionary 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,
Lösungsansätze, 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. Schöning, XML und Datenbanken—Konzepte und
Systeme, Carl Hanser Verlag, München, 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. Geissbühler, 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/data-
model/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
case-study approach, J. Am. Med. Inform. Assoc. 10 (1) (2003)
52–68.
[36] P. Votruba, S. Miksch, R. Kosara, Facilitating knowledge
maintenance of clinical guidelines and protocols,
Medinformation (2004) 57–61.
[37] 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.
[38] R. Lenz, M. Reichert, IT support for healthcare
processes—premises, challenges, perspectives. Data Know.
Eng., in press.
[39] 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.
[40] 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.
[41] 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.
[42] T. Härder, Realisierung von operationalen Schnittstellen, in:
P.C. Lockemann, J.W. Schmidt (Eds.), Datenbank-Handbuch,
Springer-Verlag, Berlin,
1987.
[43] A.S. Tanenbaum, Computer Networks. 2nd. Aufl.,
Prentice-Hall, Englewood Cliffs, NJ, 1988.
[44] N. Patel, Adaptive Evolutionary Information Systems, Idea
Group Publishing, London, 2003.
[45] 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.