Clinical modeling—A critical analysis

ARTICLE IN PRESS

IJB-3034; No. of Pages 13

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 x x x ( 2 0 1 3 ) xxx–xxx

journal homepage: www.ijmijournal.com

Clinical modeling—A critical analysis夽 Bernd Blobel a,∗ , William Goossen b , Mathias Brochhausen c a b c

eHealth Competence Center, University Hospital Regensburg, Regensburg, Germany Hogeschool Windesheim, Zwolle, and Results 4 Care, Amersfoort, The Netherlands Division of Biomedical Informatics, University of Arkansas for Medical Sciences, Little Rock, AR, USA

a r t i c l e

i n f o

a b s t r a c t

Article history:

Background: Modeling clinical processes (and their informational representation) is a prereq-

Received 9 October 2012

uisite for optimally enabling and supporting high quality and safe care through information

Received in revised form

and communication technology and meaningful use of gathered information.

17 July 2013

Objectives: The paper investigates existing approaches to clinical modeling, thereby sys-

Accepted 25 September 2013

tematically analyzing the underlying principles, the consistency with and the integration opportunity to other existing or emerging projects, as well as the correctness of representing

Keywords:

the reality of health and health services.

Clinical models

Methods: The analysis is performed using an architectural framework for modeling real-

Architectural framework

world systems. In addition, fundamental work on the representation of facts, relations, and

Ontologies

processes in the clinical domain by ontologies is applied, thereby including the integration

Knowledge representation

of advanced methodologies such as translational and system medicine.

Data elements

Results: The paper demonstrates fundamental weaknesses and different maturity as well as evolutionary potential in the approaches considered. It offers a development process starting with the business domain and its ontologies, continuing with the Reference Model-Open Distributed Processing (RM-ODP) related conceptual models in the ICT ontology space, the information and the computational view, and concluding with the implementation details represented as engineering and technology view, respectively. Conclusion: The existing approaches reflect at different levels the clinical domain, put the main focus on different phases of the development process instead of first establishing the real business process representation and therefore enable quite differently and partially limitedly the domain experts’ involvement. © 2013 Elsevier Ireland Ltd. All rights reserved.

1.

Introduction

In health and welfare systems, information and communication technology (ICT) is used to facilitate high quality and safe services as well as efficient processes. Our approach

focuses on the needs of real world stakeholders (providers and consumers) in health services to meet their objectives. We state that the representations of the stakeholders’ activities, the objects and processes involved, constitute the medical domain, not the technological requirements for representing medical information, storing and retrieving it. Therefore, not

夽 The paper is based on Keynote to the International HL7 Interoperability Conference (IHIC) 2012, 27-28 September 2012 in Vienna, Austria. A short German version has been published in the book “eHealth 2012– Informationstechnologien und Telematik im Gesundheitswesen”, MF-Verlag, Solingen, Germany. ∗ Corresponding author at: eHealth Competence Center, University Hospital Regensburg, Franz-Josef-Strauss-Allee 11, 93053 Regensburg, Germany. E-mail address: [email protected] (B. Blobel). 1386-5056/$ – see front matter © 2013 Elsevier Ireland Ltd. All rights reserved. http://dx.doi.org/10.1016/j.ijmedinf.2013.09.003

Please cite this article in press as: B. Blobel, et al., Clinical modeling—A critical analysis, Int. J. Med. Inform. (2013), http://dx.doi.org/10.1016/j.ijmedinf.2013.09.003

ARTICLE IN PRESS

IJB-3034; No. of Pages 13

2

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 x x x ( 2 0 1 3 ) xxx–xxx

the supporting ICT services but the health business with its consumer–provider interactions is the focus of our considerations. From this viewpoint, we will carry out the critical analysis of clinical modeling approaches.

1.1.

Systems approach to health

Health is a subjectively perceived and objectively underpinned physical, mental and social status of individuals. The health system aims at improving citizens’ health or keeping them healthy. Historically, the domain of healthcare has been changed and extended continuously. It started from the traditional view of healthcare as an interaction between a healthcare provider and a subject of care; a description of the original and still valid healthcare system. Later on, social services, self-care, lifestyle and prevention have been included, turning the healthcare system with its original focus on diseases to a broader oriented health system [1]. The care process has been facilitated step by step by appropriate equipment and tooling. Beside persons, also organizations, devices, applications, etc., became active components in that process. The human and non-human actors have been summarized as principals by the Object Management Group (OMG) in 1995 [2]. To bridge between all health-related domains contributing to practice, research, development, and deployment on the one hand and their ontologies, terminologies, taxonomies, information models, etc., on the other hand, an overarching approach that allows abstracting from the aforementioned domains is needed. We propose a system-theoretical approach that provides this necessary basis for integration [1,3]. System boundaries separate the system with its components from the system’s environment. Objectives and context might change characteristics and criteria for inclusion or exclusion of system’s components, thereby changing those system boundaries. The pertinent (static) system components and their relationships define the system’s structure and the functions/operations of the components and the outcome of the relationships determine the system’s behavior. When functioning, a system is in structural and/or functional transition and changes its state; it undergoes or performs a process. As stated by Smith and Klagges, functions are generally realized in processes [4]. Each system can be considered at different levels of granularity of its components, thereby decomposing systems into sub-systems or composing them to super-systems. Accordingly, the related processes happen at different granularity levels. So, the overarching healthcare system as a whole performs the generic healthcare processes, while specialized components perform specialized processes or special workflows. This top down breakdown of systems and sub-systems ends at the level of the detailed component – a single service point. At such service point, special functions are realized establishing a process or workflow step, which itself consists of transactions aiming at the individual subject of care [1]. In other words, the process model must conform to the architectural model of the system in question. In analogy, a clinical process consists of clinical workflows, composed of workflow steps realized as functions and actions, which combine basic functional steps or transactions for the subject of care.

1.2.

Representation of systems and related processes

A system’s principle structure and behavior, i.e. the system’s generic components, their functions and interrelations are called that system’s architecture. Communication and cooperation between system components for meeting a man-made system’s business objective require that this system be appropriately represented. For that purpose, the architectural elements are classified into structural and behavioral categories and appropriately named and described according to accepted ontologies or terminologies. Universal or abstract systems are represented by basic categories as introduced by, for instance, Aristotle, and formalized by Upper Ontologies, for instance the Basic Formal Ontology (BFO) introduced later on in this section [5]. Domain-specific systems or domain-specific perspectives on a multi-domain system are represented by domain-specific ontologies. One way to validate ontologies is to compare the way they structure and interrelate their elements to reality, as incrementally revealed by empirical science [6]. Therefore, the realist approach proposed by both BFO and the General Formal Ontology (GFO) [7] is fundamental to our paper. The system in its composition/decomposition represents both universals (categories, kinds, classes) and particulars (instances, particulars) of reality, ruled by scientific laws [8]. We call the representation of those parts of reality, the creator and/or user is interested in, a model. A system as part of a certain domain consists of its details (atomic components within the system’s scope), their aggregations within a sub-domain represented by a sub-domain ontology, and the concatenation of aggregations forming a network of interrelated components from different sub-domains [9]. This is reflected in the architectural dimension of the Generic Component Model (GCM) initially created by the German CORBA Group in the early nineties. Subsequently, the GCM was refined by the Magdeburg Medical Informatics Group [1,10,11]. It is now widely used in international projects and standards [12]. Generic architectural models like the GCM can be represented by Upper Ontologies. The GCM is discussed in more details in Section 2.2. An ontology, in general, is a representation of the entities in reality and the relations between those entities. Ontologies can be expressed at different levels of abstraction and expressivity, providing different level of explicitness. The languages used for representing ontologies can be informal, formal, or anything in between, starting from natural languages through meta-languages up to universal logic. The rules defining functional aspects of components and their interrelations using ontologies can be deterministic or stochastic, represented through algebraic, statistical, fuzzy, heuristic and/or logical expressions. Choosing one of the sets of rules selectively limits the systems’ structural and behavioral representation. Determining the appropriate rules according to certain components, granularity levels, and ontologies involved facilitates meeting the challenge of ontology harmonization [12]. Regarding ontologies for the Semantic Web, the Web Ontology Language (OWL) has become a standard. OWL is based on Description Logic (DL). Despite providing enormous advantages due to its decidability, the use of DL confronts the researcher with limitations regarding its expressivity [15]. However, these problems will always occur when we plan to

Please cite this article in press as: B. Blobel, et al., Clinical modeling—A critical analysis, Int. J. Med. Inform. (2013), http://dx.doi.org/10.1016/j.ijmedinf.2013.09.003

IJB-3034; No. of Pages 13

ARTICLE IN PRESS 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 x x x ( 2 0 1 3 ) xxx–xxx

3

BFO:enty connuant independent connuant object object boundary object aggregate fiat object part site

dependent connuant generically dependent connuant specifically dependent connuant quality realizable enty funcon arfactual funcon biological funcon

role disposion

spaal region zero-dimensional region one-dimensional region two-dimensional region three-dimensional region

occurrent processual enty process process boundary process aggregate fiat process part processual context

spaotemporal region scaered spaotemporal region connected spaotemporal region spaotemporal instant spaotemporal interval

temporal region scaered temporal region connected temporal region temporal instant temporal interval

Fig. 1 – General categories of BFO (after [5]).

create a logical representation of reality with the goal of using that representation for automated reasoning. BFO is an Upper Ontology that is widely used among Open Biological and Biomedical Ontology (OBO) Foundry ontologies, which are relevant to biomedicine and the healthcare domain [13]. Fig. 1 presents the basic categories of BFO according to [5]. We are aware of the fact that a new version of BFO, named BFO 2, has been made public in July 2012 [14]. However, since this is not a release version and still under development, we continue to adhere to the last official release. According to the BFO framework, the GCM in its abstract form deals with universals. Within the GCM, system components, their functions and static interrelations belong to the category of continuants, while structural and functional transitions and rearrangements of the system as process in time – not the resulting new static state – belong to the category of occurrents. The GCM also allows representing components that are particulars, thus enabling to model a concrete system.

1.3.

The clinical care system and its representation

As elaborated in Sections 1.1 and 1.2, good healthcare system models must be able to consistently describe the care system at any level of granularity, i.e. the overarching, high level consideration of the system as a whole, but also, e.g., the cellular and sub-cellular issues in clinical pathology or even the omics disciplines, thereby enabling correct transfer

between the levels. This has to be done in a way guaranteeing the conceptual integrity of the models by deploying the good modeling design principles introduced in some more details in Section 2.1. Reality justifies the correctness of the structural and functional decomposition of the system, and ontologies consistently designed in an ontology framework as the one presented in Fig. 1 name and describe the components and their relations properly. The model must be able to combine the perspectives of different disciplines contributing to a specific topic. Many approaches to clinical modeling work top down. Frequently, they result in quite vague specifications for the detailed views that do not comply with reality but are just limited to ICT needs (e.g., database or message structures). The granularity of health continuants and occurrents at cellular, sub-cellular, or even molecular and atomic level do need specific attention for optimal system functioning and integration. The consistency of fine-grained specifications, usually represented in different sub-domains, is necessary for merging those sub-domains when aggregating the components in the process design. The alternative bottom up approach starts with basic concepts that are usually completely independently developed and cannot be consistently aggregated. This approach will rarely congregate easily into a level that views the system in its totality. One approach that facilitates the organization of domain knowledge in health systems and pays attention to the detail of the reality of health is Detailed Clinical Models (DCM)

Please cite this article in press as: B. Blobel, et al., Clinical modeling—A critical analysis, Int. J. Med. Inform. (2013), http://dx.doi.org/10.1016/j.ijmedinf.2013.09.003

IJB-3034; No. of Pages 13

4

ARTICLE IN PRESS 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 x x x ( 2 0 1 3 ) xxx–xxx

[16]. DCM allow both top down and bottom up approaches to systems analysis and design. DCM can be aggregated or composed both into procedural models or Clinical Templates and system structural components. Finally, DCM can be concatenated to specialty-specific complex systems and interrelated clinical workflow descriptions forming the whole system model in its structure and behavior, i.e. describing its architecture. The system represented by the subject of care and the processes analyzing and managing his/her health comprises all levels of granularity from atoms through molecules, cell components, cells, tissues, organs, bodies, communities, up to population. This fact is reflected in the translational medicine approach or system medicine, as described by biocybernetics and medical cybernetics in the fifties, sixties, and seventies of the last century already. Regarding the functional, or in general inter-relational, aspects of that system, the relations comprise – starting in the nano-world – quantum-mechanical effects, biochemical processes, physical interrelations based on classical physics, and finally social interrelations in the macro-world. The models for describing this continuum start from mathematical and cybernetic approaches, include kinetic, calorimetric, spectral and other measurements up to methods for biological and social investigations. Talking about the system of medicine, the corresponding system’s characteristics must be modeled in consistent architectures. As we can consistently model and compute only systems of reasonable complexity, the system analysis or design has to address also its partial systems when considering higher granularity levels of the whole system in question. In other words, we always only look at parts of the system along the GCM composition/decomposition axis [1]. The system-theoretical approach to biomedical systems based on empirical, evidencebased sciences has already been successfully applied in the late sixties and early seventies in the first author’s dissertation on a general, membrane structure related transducer model for bioreceptors [17]. Systems consideration and related methods clearly demonstrate the problems with the representation of such real systems based on ICT ontology [18]. In particular, specialized health system representation in IT related reference models such as the HL7 Reference Information Model (RIM) [19] or the ISO 13606-1 Reference Model [20] and equivalents like the CIMI Reference Model introduced in Section 3.4 are burdened by this type of problems.

2.

Methods

In the paper, different current approaches for modeling clinical processes are systematically and semi-formally analyzed, using the GCM and major ontology work as reference. The main approaches considered are: Archetypes defined and used at openEHR [21] as well as in ISO EN 13606 EHR communication [20]; HL7 v3 Clinical Templates [22]; and the attempt of harmonizing both approaches (with some more emphasis to the Archetype model and underlying tools) established in the Clinical Information Modeling Initiative (CIMI) [23]. Furthermore, the paper shortly discusses efforts and activities around the ISO TC 215 DTS 13972 Health informatics – Requirements and methodology for Detailed Clinical Models [24], and

analyzes examples of this approach as currently available in the Dutch ICT in health care community.

2.1.

Good modeling practice

For developing and managing ICT solutions capable to enable clinical processes, we first need to understand and to properly represent those real world systems before being able to make useful assumptions. Before continuing working on clinical modeling, we should remember good modeling practice as discussed, e.g., in [25]. A model is an unambiguous, abstract conception of some parts or aspects of the real world corresponding to the modeling goals. This means that the domain of discourse (which is the business view on the real world domain represented by the related specialty’s ontology), the business objectives, and the stakeholders involved have to be defined. As modeling is not an end in itself but has to serve the business under consideration, the relevant stakeholders define the provided view or often views of the model. Next, stakeholders will define the way of structuring and naming the concepts in domain of discourse. When modeling a system in question, the first step is to capture key concepts and key relations at a high level of abstraction. Then, different abstraction levels should be used iteratively, starting with a top-down approach. Hence, the conceptual integrity of the model is provided, i.e. the degree to which somebody can easily understand the model, despite its complexity. For ensuring conceptual integrity, design principles such as orthogonality (not linking independent aspects), generality (not introducing multiple similar functions), parsimony (not introducing irrelevant aspects), and propriety (not restricting inherent aspects) have to be recognized. A good modeling process offers different ways for modeling concepts and relations as well as for structuring and visualizing models. Nevertheless, the different resulting models shall be consistent and coherent. Finally, taking a component-based approach to modeling supports re-usability [25]. Such good modeling practice should also be followed in the context of modeling the healthcare system and its Detailed Clinical Models.

2.2. GCM – a system-theoretical approach to an architectural framework for modeling reality The GCM describes in its architectural dimension the composition/decomposition of a system’s components [1] (Fig. 2). The defined four generic granularity levels business concept, relation network, aggregations, and details are interrelated through inheritance and constraints of the components (the y axis in Fig. 2). The iterative application of those granularity levels to sub-systems or super-systems makes it possible to model any real world system from elementary particle to the universe, thus meeting the challenge of translational medicine. Domain specific aspects of the system, represented by corresponding ontologies, can be modeled through the GCM domain dimension (the z axis in Fig. 2). The representation of a system’s architecture in a domain specific context is ruled by that domain’s ontology providing the needed meta-data. For connecting the different instances within and between the dimensions y and z, reference models

Please cite this article in press as: B. Blobel, et al., Clinical modeling—A critical analysis, Int. J. Med. Inform. (2013), http://dx.doi.org/10.1016/j.ijmedinf.2013.09.003

ARTICLE IN PRESS

IJB-3034; No. of Pages 13

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 x x x ( 2 0 1 3 ) xxx–xxx

Business Concepts Relations Networks Development Process Perspective

Aggregations

Technology View

Engineering View

Information View

Computational View

Business View

Enterprise View

Details

System Component Composition

Domain Perspective

System’s Architectural Perspective

Domain n Domain 2 Domain 1

System Viewpoint

Fig. 2 – The Generic Component Model.

Fig. 3 – GCM representation of the ontology system for business domain and ICT.

(enabling design by specialization) or meta-models (enabling design according to given specifications) are needed. These reference or meta-models include the ontologies and terminologies used for representing concepts as well as for mapping between different domain languages. For the model-driven implementation of specified solutions, the GCM is completed by the ICT development process dimension (the x axis in Fig. 2) according to the views of the Reference Model-Open Distributed Processing (RM-ODP) [26]. The first GCM view on the x axis goes beyond the RM-ODP Enterprise view, as it covers the real world system’s architecture represented by the domain ontology and called the Business view, while the RMODP focuses only on the IT-representation of the business using ICT ontology [18]. The GCM methodology hence offers a multi-model approach, as every domain and therein every view is separately modeled. This allows for a scientifically stronger triangulation of views, normally leading to more reliable representations of reality. Despite its formal foundations [1,11,12], here the GCM is only deployed in a semi-formal way for not going beyond the limits of this article. Fig. 3 shows the GCM representation of the ontology system [27]. The provided outcome represents the architecture of the real world system in question, in our case: the health care system in all its facets and components. By its abstract, generic nature, starting with the ICT-independent business view, i.e. the health

5

system as real domain of discourse, the GCM a priori meets the aforementioned good modeling practice. Focusing on an information system solution, alternative approaches force health systems’ reality into a pre-defined ICT-centric model. Given that a model reflects only what its goal is, important structural and behavioral aspects of the real business components could get lost this way. Fielding et al. and Rosse et al. warned that modelers in ontological engineering frequently try to conflate divergent perspectives on reality within a single hierarchy [28,29]. Notably, basing all representation on an agreed-upon reality can prevent this. Different perspectives, which of course exist, are always perspectives on reality. BFO fosters representations of a universally excepted reality and creation of multiple perspectives by providing formalized ways to deal with nonrigid designators, for instance roles. The GCM clearly separates those perspectives by defining a new domain with a new ontology tree representing it in an iterative way when needed. In order to review the various modeling efforts we will summarize the presented GCM principles that are used to judge the instances of clinical modeling, and we will refer to them in the analysis chapter:

1. Modeling aims at representing the reality of the healthcare domain, thereby following good modeling practice (Business Domain Model); 2. The GCM allows for analyzing (decomposing) and designing (composing) a system in its structure and behavior, i.e. considering its components, their functions and interrelations – the system’s architecture. In an iterative process, the GCM system-theoretical approach enables a flexible definition of a system as a domain of discourse separated from the system’s environment regarding (a) the criteria/characteristics defining the inclusion of components and (b) the granularity/complexity of the considered part of reality. This way, the separate consideration of different domains as well as the reflection of the entirety of reality from elementary particle up to universe is enabled. This approach is consistent with good modeling practice (Architectural Considerations); 3. In the GCM, the architectural components of a system as universals or particulars are represented using appropriate ontologies. Those ontologies are sub-systems of a consistent system of ontologies, enabling ontology harmonization (Ontological Representation); 4. Applied to the business system healthcare, the consistent architectural model of reality (Principle 1 and 2) is represented by a consistent system of ontologies (Principle 3) describing business components and related business processes composed and decomposed to meet business objectives (Business System Considerations).

3.

Results

3.1. Evaluation of existing approaches to clinical modeling The analysis presented in this section is a snapshot of an emerging development. It does not exclude future partial

Please cite this article in press as: B. Blobel, et al., Clinical modeling—A critical analysis, Int. J. Med. Inform. (2013), http://dx.doi.org/10.1016/j.ijmedinf.2013.09.003

ARTICLE IN PRESS

IJB-3034; No. of Pages 13

6

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 x x x ( 2 0 1 3 ) xxx–xxx

improvements of the methodologies offered. As this analysis focuses on the underlying principles and axiomatic definitions stated the results of this investigation can be expected to remain valid over a longer period despite possible future adaptations and might hopefully be adapted in some of the discussed projects to overcome the current deficiencies.

3.2.

The Archetype approach

An archetype is a user-defined table in relational database models, so intentionally or not-intentionally notifying the ICT-focus of the Archetype approach. Papers describing the Archetype paradigm usually focus on its dual model approach. This has meanwhile been extended to a three-model approach (see below) to overcome the lack of composition rules. The lack of such rules leads to the situation that aggregated concepts have to be represented by newly defined Archetypes [30]. Archetypes express clinical information requirements in a reusable way by maximally reducing complexity. We will now analyze this more deeply. The Archetype approach supports semantically enriched EHR systems by encapsulating domain expert’s knowledge in archetypes. Those archetypes can be used, e.g., in query answering mechanisms in order to improve recall and precision. In principle, archetypes offer an ontologybased data access system that uses a class level ontology designed as a schema in the EHR context. For enabling this, the ISO EN 13606 Reference Model is deployed to store the data in a database. Based on the Archetype Query Language (AQL) [31], queries receive tuples of individuals answering the query. However, the archetype schemas used, refer to existing ontologies like SNOMED CT [32] just as terminology. We should remember that SNOMED CT itself has developed from a terminology and is still in process of growing into a logically and ontologically coherent ontology. The problem still is a strong conceptualist legacy. So, it might be better to derive schemas from realism-based ontologies, e.g., from members or candidates of the OBO Foundry [13], most of which are based on BFO.

3.2.1.

Business Domain Model

The Archetype model provides an ICT ontology instantiated for a specific domain. In this way, basic requirements for good modeling practice such as starting with the stakeholders’ view on the business domain and representing their business objectives according to their business rules are violated. The business system representation should be based on the ontologies of the business domain (in our case medicine including translational medicine as well as supporting domains such as administration, legal affairs, technology, etc.). It should begin with a top level view, thereafter continuing iteratively and recursively at appropriate granularity levels. Business processes are not supported with archetypes, and only a top down approach is basically possible. The composition of the business system out of basic components represented by the business domain’s ontologies is not covered.

3.2.2.

Architectural Consideration

The openEHR Semantic Architecture consists of three layers. The Archetype layer is topped by the Template layer

and based on the Reference Model layer including related data types. Templates enable the definition of groupings of archetype-defined data points for particular business cases, and selections from information constructs in individual archetypes [33]. Archetypes are as inclusive as possible by defining maximal data sets for the information construct they represent, allowing the domain specific use via Templates. The Archetype approach is based on a clear methodology and supported by extended tooling.

3.2.3.

Ontological Representation

Compared with the GCM approach, the Archetype methodology represents only one domain with two granularity levels. One is represented by the Archetype Model and the other is represented by the Template Model, without detailing the relationships. The GCM, e.g., identifies four levels for the business analysis and their linkage to multiple domains in health. The lack of the latter would become obvious when introducing, e.g., security and privacy archetypes as demonstrated using the multiple domains of the GCM [34]. It also not enables recursive modeling as the GCM does. The Archetype methodology focuses on the RM-ODP Enterprise view, based on ICT ontology together with a clinical terminology binding instead of a binding to clinical ontologies. Further, the Information view and some Computational View aspects are included. Those two RM-ODP views have led to the name ‘dual model approach’.

3.2.4.

Business System Considerations

Archetypes enforce limitations when representing inherent aspects of clinical domain content and processes. The basic intention of the Archetype approach is the facilitation of health information entry and retrieval in EHR systems. In this context, archetypes provide the logical structure and representation of data belonging to clinical concepts using basic record organization principles. The ordering principle used is the concept, in general not facilitating entity-related processes and events. So it supports clinical studies, concept timelines, etc., more than individual case management. Archetypes do not support the workflow of clinicians, one important aspect of clinical reality. For realizing this, the GCM suggests that both the continuants and the occurrents are modeled at different levels of granularity present in health systems. Thereby, the component design and aggregation has to follow the real business system’s architecture, represented through the corresponding ontologies.

3.3.

HL7 v3 Clinical Templates

HL7 v3 CDA documents and messages are encoded in Extensible Markup Language (XML). They derive their machine processable semantics from the HL7 RIM and use the HL7 Version 3 data types and class structures. In that context, they provide a mechanism for the incorporation of concepts from standard coding systems such as SNOMED CT [32] and LOINC [42]. HL7 Templates are a constraint on the CDA R2 object model and/or against a Clinical Statement Model. The HL7 Clinical Statement Model focuses on harmonizing clinical statement requirements into a single CDA or message model [22,35].

Please cite this article in press as: B. Blobel, et al., Clinical modeling—A critical analysis, Int. J. Med. Inform. (2013), http://dx.doi.org/10.1016/j.ijmedinf.2013.09.003

ARTICLE IN PRESS

IJB-3034; No. of Pages 13

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 x x x ( 2 0 1 3 ) xxx–xxx

3.3.1.

Business Domain Model

The basis of HL7 v3 Clinical Templates – the HL7 RIM – has been developed to group and classify the components used in existing HL7 messages for application-agnostic communication between computer systems. It provides an ICT ontology instantiated for a specific domain. By that way, basic requirements for good modeling practice as mentioned in the related statement of Section 3.2 are violated.

3.3.2.

Architectural Considerations

In contrast to the archetypes that are derived from a top down approach, the clinical statement structure in HL7 v3 allows a top down decomposition through the headers, sections, and core content. However, it also allows bottom up compositions from several clinical statements to more abstract levels, using the organizer Acts. Compared with the GCM approach however, the HL7 v3 Clinical Templates methodology represents just one domain with currently two granularity levels established by the different CDA releases. Hence, recursive iteration as offered with GCM and good modeling practice is not possible. Its use in messages is slowly progressing, using a similar approach.

3.3.3.

Ontological Representation

HL7 v3 Clinical Templates offer only one RM-ODP view: the Information view (not talking here about CDA Implementation Guides). Therefore, they are focused solely on information about things and events. It is hard to relate them to things and events in reality. HL7 v3 Clinical Templates do not use biomedical ontologies, but refer to existing, and for use in HL7 partially fixed, terminologies. They even fall behind a richer ICT ontology, a fact which might change with the move to Service Oriented Architecture (SOA) and architectural projects at HL7 [36].

3.3.4.

Business System Considerations

The basic intention of HL7 v3 Clinical Templates is the facilitation of health information systems communication despite of the human-readable part of CDA. Its ordering principle is based on event-driven, entity-related processes, not taking into account the various Architectural Considerations of the GCM and their Ontological Representation.

3.4. The Clinical Information Modeling Initiative (CIMI) The Clinical Information Modeling Initiative is an international collaboration that is dedicated to providing a common format for detailed specifications for the representation of health information content. The goal is to facilitate creation and sharing of semantically interoperable information in health records, messages, documents, decision support tools, and for secondary data uses [23]. It is mainly based on the Archetype Object Model (AOM) [37] and expressed in the Archetype Definition Language (ADL) V 1.5 [38]. It further deploys the Unified Modeling Language (UML) Stereotypes expressed using UML 2.0 [39] and the Object Constraint Language (OCL) [40]. To create maximum interoperability within the CIMI Clinical Modeling Architecture, a draft version of the CIMI Reference Model is developed. It is

7

independent of logical and implementable models. This Reference Model defines a rigorous and stable set of modeling patterns, including a set of structural patterns, complex data types, and demographic classes (see Fig. 4 [23]). In that context, the ISO EN 13606-1 Reference Model has been slightly adapted by adding the classes PATHABLE (root), LOCATABLE, LINK and ARCHETYPED as well as DATA VALUE (colored in yellow in Fig. 4). LOCATABLE, from which the 13606 RM is specialized, is linked to ARCHETYPED and LINK. Note that the current outcome is a Draft Standard for Trial Use. The CIMI Reference Model provides a consistent computational framework upon which model authoring and translation tools can be based. It is a single information model – if needed refined by further constraints to represent specific information requirements – offering a ‘common modeling language’ for describing all instances of all clinical models. It represents the core artifact that is implemented in software, providing the physical structure of the clinical models and their example instances. All CIMI clinical models will be defined by constraining the CIMI Reference Model regarding both the generic classes and instances. The Reference Model allows reducing the demand on Archetype design such as the timing of observations, including interval measurements such as maximum and minimums, and the ability to provide a reason if mandatory information is not available at the time a record was created. The CIMI Reference Model can be expressed in UML diagrams offering the whole range of modeling options in UML tooling.

3.4.1.

Business Domain Model

Core of the CIMI Reference Model is the ISO EN 13606 Reference Architecture which is – as mentioned already above – contrary to the real architectural and multi domain GCM just a structural model. The CIMI Reference Model as specialized ICT ontology has been extended by references to reference Archetypes, locations, and links to the Archetype deployment. An overview on the CIMI project is presented in Fig. 5, clearly demonstrating the aforementioned ICT focus of the approach, partially relying on ICT-related ontologies such as IBM’s ICT ontology [18] or SOA ontology [41]. Nonetheless, the ontologies defined in the project (not just referenced) lag behind the richness of that ICT ontology (Fig. 6), despite that ontology being small compared with the biomedical ontology. Being closely related to the openEHR Archetype approach, the CIMI project violates basic requirements for good modeling practice such as starting with the stakeholders’ view on the business domain and representing their business objectives according to their business rules. The CIMI approach is not facilitating an iterative modeling process.

3.4.2.

Architectural Considerations

Fully corresponding to the Archetype approach, the necessary system-theoretical and architecture-centric principles are not met. Archetypes are quasi used as blueprint for any model. At this stage it is not possible to determine any guidance on compositions and decompositions of business artifacts. Business processes are not supported with archetypes, and only a top down approach is basically possible.

Please cite this article in press as: B. Blobel, et al., Clinical modeling—A critical analysis, Int. J. Med. Inform. (2013), http://dx.doi.org/10.1016/j.ijmedinf.2013.09.003

IJB-3034; No. of Pages 13

8

ARTICLE IN PRESS 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 x x x ( 2 0 1 3 ) xxx–xxx

Fig. 4 – Draft CIMI Reference Model [23]. (For interpretation of the references to color in the text, the reader is referred to the web version of the article.)

Fig. 5 – Overview on the CIMI project [23].

Please cite this article in press as: B. Blobel, et al., Clinical modeling—A critical analysis, Int. J. Med. Inform. (2013), http://dx.doi.org/10.1016/j.ijmedinf.2013.09.003

ARTICLE IN PRESS

IJB-3034; No. of Pages 13

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 x x x ( 2 0 1 3 ) xxx–xxx

9

Fig. 6 – ICT ontology (after Akerman and Tyree [18]).

3.4.3.

Ontological Representation

On the one hand, the defined concepts in CIMI are to be bound to a single existing terminology, i.e. SNOMED CT [32], despite missing coverage of clinical concepts known. It also fully ignores the system of domain-specific ontologies highly important for the stakeholders to be served. On the other hand, Fig. 5 clearly shows the special value of the CIMI project from the system development process perspective by enabling the combination of different specification tools and implementation environments. If CIMI would follow the GCM framework for properly representing the real business processes in healthcare, it will offer a platform for collaboratively and openly implementing appropriate solutions.

3.4.4.

Business System Considerations

The ordering principle of the CIMI approach is the concept. It intends to facilitate any implementation, irrespective of a specific architecture. However, at this stage CIMI is not taking into account the various Architectural Considerations of the GCM and their Ontological Representation.

3.5.

ISO 13972

In 2008, William Goossen from the Dutch ISO National Member Body NEN launched a New Work Item Proposal (NWIP) on Detailed Clinical Models based on the analysis of existing approaches [43,44] and submitted this to ISO TC 215 Health Informatics. The objective of that work item – anticipated as content standard(s) for clinical modeling – was to harmonize the existing different approaches also presented in this paper. The work also aims at a standardized framework and related processes specifying the criteria for clinical models to assure semantic interoperability across technical platforms, including archetypes and HL7 templates [24,44]. From the beginning, there was a debate about mission and scope of that work item, meanwhile labeled ISO 13972 [24], among the different national/regional DCM groups aiming at defending their claims and enforcing their developments. As the ISO 13972 project aims at harmonizing the existing approaches, it will not be included in the comparative analysis presented in this chapter. Instead, we will provide some

Please cite this article in press as: B. Blobel, et al., Clinical modeling—A critical analysis, Int. J. Med. Inform. (2013), http://dx.doi.org/10.1016/j.ijmedinf.2013.09.003

ARTICLE IN PRESS

IJB-3034; No. of Pages 13

10

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 x x x ( 2 0 1 3 ) xxx–xxx

recommendations to successfully manage that project. In that context, we will use the Dutch example DCM, created using a UML software tool, as one approach to ISO 13972 deployment.

3.5.1.

Business Domain Model

Compared with the GCM, the Dutch DCM examples include the business view of system components in the medical domain at the GCM Details granularity level as well as the ICT-related system viewpoints from enterprise through information to computational view, correctly leaving the platform-specific engineering and technology views out of consideration. For implementation, the Dutch example logical UML models are transformed into XML, HL7 v3 Clinical Statements, Archetypes, and in the CIMI expression format. This approach follows the GCM development process dimension.

3.5.2.

Architectural Considerations

The offered approach aims at purpose-related combining different DCM into compositions similar to the Templates in the openEHR space and the organizer in HL7 v3 Templates. Contrary to the GCM approach however, this aggregation is currently limited to the structural aspects of compositions, does not cover multiple levels of granularity and its representation is not based on a formal biomedical ontology. Plans to link it to workflow are underway, but cannot be reported in this phase.

3.5.3.

Ontological Representation

The core of the Dutch DCM examples consists of a small subontology limited to the clinical concept which is modeled only, in which the data elements are expressed, bound to one to many terms from terminological systems or classifications. The relation to formal biomedical ontologies necessary for guaranteeing conceptual integrity is missing, however. That would be relevant for the bottom-up compositions of DCM in particular, linking DCM to domain ontologies.

3.5.4.

Business System Considerations

Following a fixed package in UML, the Dutch DCM examples comprise reference to the medical knowledge, such as clinical purpose, evidence base and interpretation of values (where applicable). In addition to Archetypes and HL7 templates however, it also includes intrinsic, granular workflows expressed in those DCM. Examples would cover the processes around the specific order of activities and test moments for a glucose tolerance test, or the specific sequence of assessments, such as the Apgar score to be carried out after birth at exactly 1 min, 5 min, and 10 min. The ordering principle of the Dutch DCM approach is the small collection of concepts. The Dutch DCM examples intend to facilitate any implementation, irrespective of a specific architecture and a specific technology.

4.

Discussion

There are two opportunities for approaching the challenge for semantic interoperability between the different DCM representations:

(a) the development of an overarching reference information model as done with HL7 RIM and intended by CIMI and (b) the development of an architectural representation of the real system of medicine. The latter includes the system of clinical medicine, based on biomedical ontologies. Its architectural framework allows for automatically deriving the models of the different RM-ODP views, thereby approaching the Unified Process for ICT systems developments (e.g., [45]). While (a) is focused on the ICT perspective of real world systems, (b) supports the domain experts’ view based on their knowledge space represented by their ontologies and expressed using their terminologies. Furthermore, (b) not just separates platform-independent and platform-specific views, it also strictly separates the domain of discourse from its representation in the ICT domain. Finally, (b) enables the integration of emerging or future developments such as systems medicine, systems biology and systems pathology, as well as decision support services based on that. More or less ignoring the requirements of the domains of discourse as well as the foundational considerations about good modeling, good ontology design and representation of reality, the presented approaches are information models. Therefore, they are not derived based on the ontology of the domain served, but on ICT ontology, discussed already, e.g., in [1,27,46]. To underpin this limitation, the first three approaches are based on certain reference information models such as the Archetype Object Model (AOM), the ISO EN 13606 Reference Model, the HL7 Reference Information Model (RIM), or the CIMI Reference Model. Therefore, they are facing the problem that the architectural representation and composition/decomposition of real-world classes and instances cannot be provided appropriately. Instead, the models are quite different from reality and themselves inconsistent. Referencing the GCM as explanatory basis, the fourth example of the Dutch DCM expressed in UML goes in the right direction of (better) expressing the domain experts’ view. Nevertheless, it also does not meet all the fundamental principles laid down in the Generic Component Model framework. The Dutch DCM still have to be further developed, hopefully supported by an evolving ISO 13972 standard. The ICT perspectives on healthcare processes are necessary to support the healthcare business domain by ICT. The domain of discourse shall define its informational representation, not vice versa as most frequently done, including the Reference Model based DCM approaches discussed in this paper. In addition, the developers have to acknowledge the fact that for supplying ICT with rich semantics, ICT model representation needs to advance to rich UML including OCL, or better to transfer to one of the semantic web languages such as OWL. Furthermore, in order to facilitate modeling and foster harmonization with pre-existing, semantically rich ontologies taking up an upper ontology would be beneficial [47]. openEHR and CIMI are based on the Archetype approach, thereby getting closer to the presented approach (b). Nonetheless, their architectural basis is insufficient. Furthermore, they use their own application ontology (see Fig. 1), only binding the concepts to standard terminologies instead of consistently deriving it from an architecturally sound and internationally accepted ontology system, proofing the entire process at

Please cite this article in press as: B. Blobel, et al., Clinical modeling—A critical analysis, Int. J. Med. Inform. (2013), http://dx.doi.org/10.1016/j.ijmedinf.2013.09.003

IJB-3034; No. of Pages 13

ARTICLE IN PRESS 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 x x x ( 2 0 1 3 ) xxx–xxx

reality, like the GCM does [9,48]. HL7 v3 Clinical Templates face similar problems as the archetypes, but are an example of approach (a) where an ICT ontology based overarching reference information model – the HL7 RIM – strictly determines the expression of clinical content. The example DCM presented in UML try to move to approach (b), nevertheless still lacking the strictness of an architectural ontology-driven approach like GCM. Because of their Reference Model independency, they hold the potential for the needed improvement. In addition, similar to the ICTbased approach there are concerns regarding harmonization with pre-existing ontologies and issues regarding the expressivity of UML. For making sense and enabling the integration of any project including CIMI, the ISO 13972 project should strictly follow the aforementioned approach (b).

5.

Conclusions

For improving safety, continuity, and quality of care, enabling clinical decision support systems as well as personalizing health processes, sophisticated clinical modeling is inevitable. Four existing clinical modeling projects and artifacts have been semi-formally analyzed. This analysis is based on a system-theoretical, architecture-centered approach to the clinical business domain, represented through internationally accepted ontologies, as well as by following good modeling practice. The criteria of using business domain models representing the reality of health, Architectural Considerations, the system representation using a consistent, domain-related set of multiple ontologies, and the application of those principles to the business system with its components and processes were applied against 4 DCM instances, revealing their strengths and weaknesses. What is driving the development seems to be more competition and the defense of market shares than a sophisticated methodology. Three examples of modeling approaches are based on ICT-related reference models as ICT top-level ontologies and do not, or not sufficiently, adhere to ontological and architectural principles proven at the real business domain addressed: medicine and related sciences. Health care defines the problem, and life sciences frame possible solutions. The fourth example of representing DCM in UML better complies with architectural principles as depicted in the GCM. The ontological deficiencies of that approach should be investigated to overcome them soon. To re-use and automatically harmonize those existing solutions for providing comprehensively interoperable healthcare services, the ISO 13972 standard should be reshaped according to the proposed approach. The demonstrated substantial weaknesses caused by ignoring the rediscovered systems approach to the domains of discourse and the resulting needs for architecturally sound and ontology-driven modeling approaches are inherent in most of the health informatics standardization efforts intended to go beyond the traditional health information systems’ perspective toward a comprehensive reflection of the business domain. Here, also the HL7 architectural project has to be mentioned, which remains far behind the original proposal of the HL7 Technical Transition Task Force [46].

11

Summary points What was already known on the topic: • There is a series of papers describing the existing clinical modeling approaches. • Semantic interoperability is provided by deploying Reference Information Models based on Information and Communication Ontology. What this study added to our knowledge: • Semantic interoperability is provided through a system-theoretical, architecture-centric approach represented by domain ontologies. • The paper deploys the architecture centric GCM framework for semi-formally comparing and evaluating current approaches, at the same time proposing an optimized approach to clinical models which can easily transformed in any of the existing implementations. • The paper bridges between system-theoretical and ontological considerations, thereby architecturally classifying ontologies and interpreting BFO. • It recommends scope and objectives as well as underlying methodologies and interrelations for a corresponding ISO specification for Detailed Clinical Models.

Author contributions BB has established the system-theoretical and architecturecentric framework for semi-formally comparing the discussed clinical modeling approaches. He performed the provided analysis. WG has contributed to the analysis and delivered the Dutch demonstrator. MB has contributed to the analysis. All authors elaborated on discussions and conclusions as well as on the overall presentation the paper.

Competing interests The authors declare that they do not have any conflicts of interests regarding in relation to this article.

Acknowledgement The authors are indebted to thank the reviewers for their recommendations and important help to improve the paper, their colleagues from IHTSDO, ISO TC 215, HL7, and CIMI, and especially Dr. Frank Oemig, Mülheim, for invaluable discussions and support.

references

[1] B. Blobel, Architectural approach to eHealth for enabling paradigm changes in health, Methods Inf. Med. 49 (2) (2010) 123–134.

Please cite this article in press as: B. Blobel, et al., Clinical modeling—A critical analysis, Int. J. Med. Inform. (2013), http://dx.doi.org/10.1016/j.ijmedinf.2013.09.003

IJB-3034; No. of Pages 13

12

ARTICLE IN PRESS 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 x x x ( 2 0 1 3 ) xxx–xxx

[2] OMG, The CORBA Security Specification, OMG, 1995 (Doc.No. 95-12-01). [3] L. Bertalanffy, General Systems Theory: Foundations, Development, Applications, Braziller, New York, 1968. [4] B. Smith, B.R.E. Klagges, Philosophy and biomedical research, Allg. Z. Philos. 30 (1) (2005) 5–26 (in German) www.ontology.buffalo.edu/bio/Lebensformen.pdf (accessed 30.12.12). [5] R. Arp, B. Smith, Function, role and disposition in basic formal ontology, Nat. Precedings (2012), hdl:10101/npre.2008.1941.1 (posted 02.06.08; accessed: 30.12.12). [6] B. Smith, Introduction to Biomedical Ontologies. Training Course, University at Buffalo, 2008 ontology.buffalo.edu/08/TrainingCourse/Slides.pdf (accessed 30.12.12). [7] H. Herre, B. Heller, P. Burek, R. Hoehndorf, F. Loebe, H. Michalek, General formal ontology (GFO) – Part I: Basic principles, Technical Report 8, Onto-Med, University of Leipzig, 2006. [8] B. Smith, Beyond concepts: ontology as reality representation, in: Proceedings of FOIS, 2004. [9] B. Blobel, M. Brochhausen, C. Gonzalez Serrano, D. Lopez, F. Oemig, A system-theoretical, architecture-based approach to ontology management, in: J. Mantas, S.K. Andersen, M.C. Mazzoleni, B. Blobel, S. Quaglini, A. Moen (Eds.), Quality of Life through Quality of Information, Series Studies in Health Technology and Informatics, vol. 180, IOS Press, Amsterdam, Berlin, Oxford, Tokyo, Washington, 2012, pp. 1087–1089. [10] B. Blobel, Assessment of middleware concepts using a generic component model, in: Proceedings of the Conference “Toward An Electronic Health Record Europe’97”, London, 1997, pp. 221–228. [11] B. Blobel, Application of the component paradigm for analysis and design of advanced health system architectures, Int. J. Med. Inf. 60 (3) (2000) 281–301. [12] B. Blobel, Standards and solutions for architecture based, ontology driven and individualized pervasive health, in: B. Blobel, P. Pharow, F. Sousa (Eds.), pHealth 2012, Series Studies in Health Technology and Informatics, vol. 177, IOS Press, Amsterdam, Berlin, Oxford, Tokyo, Washington, 2012, pp. 147–157. [13] B. Smith, M. Ashburner, C. Rosse, et al., The OBO Foundry: coordinated evolution of ontologies to support biomedical data integration, Nat. Biotechnol. 25 (11) (2007) 1251–1255. [14] BFO2: http://code.google.com/p/bfo/ [15] S. Schulz, H. Stenzhorn, M. Boeker, B. Smith, Strengths and limitations of formal ontologies in the biomedical domain, Rev. Electron. Comun. Inf. Inov. Saude 3 (1) (2009) 31–45. [16] W. Goossen, A. Goossen-Baremans, M. van der Zel, Detailed clinical models: a review, Healthc. Inform. Res. 16 (4) (2010) 201–214, http://dx.doi.org/10.4258/hir.2010.16.4.201, http://pdf.medrang.co.kr/Hir/2010/016/Hir016-04-01.pdf (accessed 30.12.12). [17] B. Blobel, About the mechanism of information processing and energy transformation in bioreceptors – a general and membrane structure related transducer model, Technische Hochschule “Otto von Guericke” Magdeburg, Magdeburg, 1976 (in German, Ph.D. Thesis). [18] A. Akerman, J. Tyree, Using ontology to support development of software architectures, IBM Syst. J. 45 (4) (2006) 813–815. [19] Health Level 7 International Inc. Reference Information Model (RIM). www.hl7.org (accessed 30.06.13). [20] ISO 13606 Health informatics – EHR communication. www.iso.org (accessed 30.06.13). [21] openEHR Foundation. www.openehr.org (accessed 30.06.13). [22] Health Level 7 International. HL7 Clinical Templates. www.hl7.org (accessed: 30.06.13).

[23] CIMI Reference Model Report, Draft V 0.3, May 2012. [24] ISO 13972 Health informatics – Requirements and methodology for Detailed Clinical Models. www.iso.org (accessed 16.07.13). [25] M. Lankhorst, et al., Enterprise Architecture at Work, The Enterprise Engineering Series, Springer, Berlin/Heidelberg, 2009. [26] ISO/IEC 10746 Information technology – Reference Model Open Distributed Processing. www.iso.org (accessed: 30.12.12). [27] B. Blobel, Ontologies, Knowledge representation, artificial intelligence – hype or prerequisite for International pHealth ˇ Interoperability? in: L. Stoicu-Tivadar, B. Blobel, T. Marcun, A. Orel (Eds.), e-Health Across Borders Without Boundaries. E-salus trans confinia sine finibus. Series Studies in Health Technology and Informatics, vol. 165, IOS Press, Amsterdam, Berlin, Oxford, Tokyo, Washington, 2011, pp. 11–20. [28] J.M. Fielding, J. Simon, W. Ceusters, B. Smith, Ontological theory for ontological engineering: biomedical systems information integration, in: Proceedings of the Ninth International Conference on the Principles of Knowledge Representation and Reasoning (KR2004), Whistler, BC, 2–5 June, 2004. [29] C. Rosse, A. Kumar, J.L.V. Mejino Jr., D.L. Cook, L.T. Detwiler, B. Smith, A strategy for improving and integrating biomedical ontologies AMIA Annu. Symp. Proc. 2005 (2005) 639–643. [30] G. Freriks, G. de Moore, D. Kalra, White paper: Archetype paradigm: an ICT revolution is needed. The EPR of the future demands flexible plug-and-play exchange between ICT systems. Version 1.0, UCL 2007, 2007. [31] T. Beale, openEHR Archetype Query Language Description, 2012 http://www.openehr.org/wiki/display/spec/Archetype+ Query+Language+Description (accessed: 30.12.12). [32] IHTSDO: SNOMED CT. http://www.ihtsdo.org/snomed-ct/ (accessed: 30.06.13). [33] T. Beale, openEHR ADL & AOM 1. 5 – Templates and Specialised Archetypes, openEHR Foundation, 2012 www.openehr.org (accessed: 30.12.12). [34] B. Blobel, Ontology driven health information systems architectures enable pHealth for empowered patients, Int. J. Med. Inf. 80 (2011) e17–e25. [35] R.H. Dolin, L. Alschuler, S. Boyer, C. Beebe, F.M. Behlen, P.V. Biron, A. Shabo, HL7 Clinical Document Architecture, Release 2, J. Am. Med. Inform. Assoc. 13 (2006) 30–39. [36] Health Level 7 Inc. SOA Workgroup. www.hl7.org/Special/committees/ (accessed: 30.1212). [37] T. Beale, Archetype Object Model AOM 2.1, openEHR Foundation, 2012 www.openehr.org (accessed: 30.12.12). [38] T. Beale, S. Heard, Archetype Definition Language ADL 1.5, openEHR Foundation, 2012 www.openehr.org (accessed: 30.12.12). [39] Object Management Group Inc., Unified Modeling Language (UML) 2.0, 2012 www.omg.org (accessed: 30.12.12). [40] Object Management Group Inc., Object Constraint Language (OCL) 2.2, 2012 www.omg.org/spec/OCL/2.2 (accessed: 30.12.12). [41] The Open Group, Service-Oriented Architecture Ontology, 2010 www.opengroup.org (accessed: 30.12.12). [42] Logical Observation Identifiers Names and Codes (LOINC® ). www.loinc.org (accessed: 30.12.12). [43] W.T.F. Goossen, Using detailed clinical models to bridge the gap between clinicians and HIT, in: E. De Clercq, et al. (Eds.), Collaborative Patient Centred eHealth. Proceedings of the HIT@Healthcare 2008, IOS Press, Amsterdam, 2008, pp. 3–10. [44] W.T.F. Goossen, A.T.M. Goossen-Baremans, Bridging the HL7 Template – 13606 Archetype gap with Detailed Clinical

Please cite this article in press as: B. Blobel, et al., Clinical modeling—A critical analysis, Int. J. Med. Inform. (2013), http://dx.doi.org/10.1016/j.ijmedinf.2013.09.003

IJB-3034; No. of Pages 13

ARTICLE IN PRESS 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 x x x ( 2 0 1 3 ) xxx–xxx

Models, in: C. Safran, et al. (Eds.), MEDINFO 2010, Stud. Health Technol. Inform. 160 (Pt 2) (2010) 932–936. [45] M. van der Zel, W. Goossen, Bridging the gap between software developers and healthcare professionals. Model Driven Application Development, Hosp. Inform. Technol. Eur. 3 (2) (2010) 20–22. [46] B. Blobel, Architectural Interoperability Framework, in: Proceedings of the 12th International HL7 Interoperability Conference IHIC 2011 “The TomorrowLand of Health”, 2011 www.hl7.org/events/ihic2011/papers/IHIC Blobel%20

13

[47] B. Smith, M. Brochhausen, Putting biomedical ontologies to work, Methods Inf. Med. 49 (March (2)) (2008) 135–140. [48] M. Brochhausen, B. Blobel, Architectural approach for providing relations in biomedical terminologies and ontologies, in: A. Moen, S.K. Andersen, J. Aarts, P. Hurlen (Eds.), User Centred Networked Health Care – Proceedings of MIE 2011. Series Studies in Health Technology and Informatics, vol. 169, IOS Press, Amsterdam, Berlin, Oxford, Tokyo, Washington, 2011, pp. 739–743.

Please cite this article in press as: B. Blobel, et al., Clinical modeling—A critical analysis, Int. J. Med. Inform. (2013), http://dx.doi.org/10.1016/j.ijmedinf.2013.09.003