journal of biomedical informatics
All submissions of the EM system will be redirected to Online Manuscript Submission System. Authors are requested to submit articles directly to Online Manuscript Submission System of respective journal.
Bernd Blobel1,2,3* and Frank Oemig4
1 Medical Faculty, University of Regensburg, Germany, Email:
2 eHealth Competence Center Bavaria, Deggendorf Institute of Technology, Germany, Email:
3 First Medical Faculty, Charles University in Prague, Czech Republic, Email:
4 Deutsche Telekom Healthcare and Security Solutions GmbH, Essen, Germany
*Correspondence: Prof. Dr. habil. Bernd Blobel, FACMI, FACHI, FHL7, FEFMI, MIAHSI, Medical Faculty, University of Regensburg, Germany, Email:

Received: 12-May-2018 Accepted Date: May 23, 2018 ; Published: 06-Jul-2018, DOI: 10.24105/ejbi.2018.14.3.2

This open-access article is distributed under the terms of the Creative Commons Attribution Non-Commercial License (CC BY-NC) (, which permits reuse, distribution and reproduction of the article, provided that the original work is properly cited and the reuse is restricted to noncommercial purposes. For commercial reuse, contact


Introduction: Progressive health paradigms, involving many different disciplines and combining multiple policy domains, requires advanced interoperability solutions. This results in special challenges for modeling health systems.

Methods: The paper discusses classification systems for data models and enterprise business architectures and compares them with the ISO Reference Architecture.

Results and Conclusions: Existing definitions, specifications and standards for data models enabling interoperability are analyzed, and their limitations are evaluated. Amendments to correctly use those models and to better meet the aforementioned challenges are offered.


Healthcare transformation; Interoperability; Data models; Knowledge management; Architectures


In order to support highly distributed, personalized, predictive, preventive, participative, and cognitive care healthcare systems have to provide and to ensure reliable environments. The approach requires the exchange of data in a highly interoperable fashion across different disciplines and domains. The involvement of stakeholders from different specialties and policy domains, offering different levels of knowledge, skills, and experiences to act in different scenarios accommodating different business cases has to be supported by allowing specific methodologies, terminologies, and ontologies to enable analysis, design, implementation, deployment, maintenance, and evaluation of systems within their lifecycle. The management of such highly dynamic, complex, heterogeneous and context-depending business processes, i.e. the execution of ICT (Information and Communication Technology)-supported business operations from a business process expert’s view, must be formalized [1, 2] to enable automation of the business process management. A system-oriented, architecture-centric, ontology-based modeling approach based on ontology languages, repositories, reasoners, and query languages provides methods and tools scalable and adaptive to communities, user groups and even individuals, transferring their knowledge, experience, expectations, and intentions into machine-accessible representation and manipulation of business knowledge [1]. Such approach has been developed by the authors and standardized at ISO and CEN [3, 4]. It covers all levels of ICT-related interoperability from technical interoperability through structural interoperability, syntactic interoperability, semantic interoperability and organization/ service interoperability health informatics interoperability standards usually address, but also interoperability beyond ICT-related business cases represented through domainspecific ontologies such as knowledge-based domain-domain interoperability and even skills based interoperability addressing the end-user [4]. Dealing with the data modeling dilemma for enabling interoperability, this paper introduces data model classification systems to analyze widely spread data model based interoperability specifications in comparison with the ISO Interoperability Reference Architecture Model [4], thereby summarizing work published in other context [5, 6].


General Aspects of Modeling

According to Alter [7], a model is a partial representation of reality. It is restricted to attributes the modeler is interested in. Defining the pragmatic aspect of a model, the interest is depending on the addressed audience, the reason and the purpose of modelling the reality and using the resulting model for a certain purpose and for a certain time instead of the original. A purpose of developing and deploying models is the creation of knowledge. An outcome of developing mathematical models is that it helps model builders and decision makers understanding the relationships between important sets in a business situation. On the other hand, description and especially the interpretation of real systems are based on knowledge. This aspect is especially highlighted by Langhorst et al. [2], defining a model as an unambiguous, abstract conception of some parts or aspects of the real world corresponding to the modeling goals. Hereby, the domain of discourse, the business objectives, and the stakeholders involved have to be defined. A concept shall be uniquely identifiable, independently accepted by experts and users, and has a representation. A concept is a knowledge component that can be specialized and generalized as components can. Knowledge can be represented at different level of abstraction and expressivity, ranging from implicit knowledge up to fully explicit knowledge representation, i.e. from natural language up to universal logic (Figure 1). A key parameter in choosing or creating a proper knowledge representation (KR) is its expressivity. A more expressive knowledge representation language enables an easier and more compact expression of knowledge within the semantics and grammar of that knowlegde representation. However, more expressive languages are likely to require more complex logic and algorithms to construct equivalent inferences. A highly expressive KR is also less likely to be complete and consistent. Less expressive KRs may be both complete and consistent. This is an important advantage of domain-specific terminologies and their underlying ontologies, extensively exploited in good modeling best practices.


Figure 1: Ontology types, after [8], changed.

Data Modeling

Data modeling is frequently described as a series of processes to define data requirements for supporting business processes by enabling all related process decisions, so defining the system behavior to meet the business objectives. Depending on the level of abstraction, we distinguish conceptual, logical and physical data definition representing the informational components of the considered ecosystem [9]. Especially for managing complex multi-domain ecosystems, the definition of business cases and involved assets including a comprehensive metadata repository and accurate quantifiers as well as data governance management is impossible without deploying the business domains’ ontologies [10].

Modeling Health Systems

Conceptual Model of Architectural Descriptions

ANSI/IEEE 1471-2000 - IEEE Recommended Practice for Architectural Description for Software-Intensive Systems considers aspects and principles to be considered when modeling information systems [11]. In that context, the importance of the business domain and its mission represented by the domain experts as relevant stakeholders has been highlighted in some detail. The resulting conceptual model of architectural descriptions for such systems is presented in Figure 2.


Figure 2: ANSI/IEEE 1471 conceptual model of architectural descriptions [11].

Data Modeling Best Practices

Hoberman et al. describe a data model as a visual representation of people, places and things of interest to a business, and is composed of a set of symbols that communicate concepts and their business rules [12]. Starting point is the definition of the business, thereby aligning its scope and the common interest of the different stakeholders from different domains involved. The resulting very-high- level data model represents scope, requirements and related basic concepts of the business case. The high-level data model defines the relevant information and the representation and relationships of the basic concepts. The logical level data model describes in more detail the layout and types of the data as well as the object relationships. At this level, data modelers and analysts enter the stage, while the former levels are accommodated by domain experts. However, for properly managing data governance as discussed later on, business domain experts should be involved throughout the project lifecycle. The physical level data model considers ICT paradigms and related platforms, addressing implementation-related aspects relevant for storing, processing and communicating information such as architectures and principles of relational versus non-relational databases, communication protocols, Web services, representation styles, etc.

According to Langhorst et al., relevant stakeholders must define the provided view of the business model as well as the way of structuring and naming the concepts of the problem space [2]. Following the ontology-based business integration, thereby first capturing key concepts and key relations at a high level of abstraction, different abstraction levels should be used iteratively, where the first iteration is performed in a top-down manner to guarantee the conceptual integrity of the model. This requires meeting design principles such as orthogonality, generality, parsimony, and propriety [8].

Another approach for interrelating the different model levels uses the dimension of modeling from the 1-dimensional data modeling through information modeling, knowledge modeling up to the four-dimensional knowledge space representation [13], allowing for transformation between the different representation levels. The knowledge dimension covers the knowledge of one domain. The knowledge space dimension represents multiple domains’ concepts and their relations, so enabling their mapping. The higher the dimension the more the modeling process is dominated by business domain experts.

Data modeling enabling advanced interoperability in distributed multi-domain healthcare systems must be guided by domain experts’ business models, so representing the main stakeholders perspective, terminology and ontology.

Figure 3 presents the modeling dimensions and the related transformation pathway.


Figure 3: Dimensions of data modeling (after Krogstie [13]).

The ISO Interoperability Reference Architecture

This description of the ISO Interoperability Reference Architercture corresponds to the related text in ISO 13606:2018 Health informatics – EHR communication provided by the first author [14].

Meeting the objectives of improving safety, quality and efficiency of care with ICT support requires advancing interoperability between computer systems towards a business process specific co-operation of actors representing the different domains participating in the business case. For that purpose, the agreed domain knowledge, but also individual (language, education, skills, experiences, social and psychological aspects, etc.) and environmental context have to be represented correctly and formally for integration in the ICT system as part of the business system. As the domain experts involved describe specific aspects of that business system in a specific context, using their specific terminologies and ontologies, methodologies and frameworks, the resulting informational representations are quite inconsistent, requiring a peer-to-peer interoperability adaptation process. Adapting existing standardized informational representations of domain-specific use cases as practiced in most current interoperability specifications to changing contexts or including other domains requires another common harmonized informational representation or results in permanent revisions of specifications. A pretty bad example of the latter fact is ISO 13606, which has been revised in more than 15 versions provided over three years.

It is impossible to represent the highly complex, highly dynamic, multi-disciplinary/multi-domain healthcare system by one domain‘s terminology/ontology or - even worse - by using ICT ontologies. The same holds when using one domain’s representational style and models or standards as reference or master all the interrelated components must be adapted to.

The alternative is an abstract domain-independent representation of systems using Universal Type Theory and corresponding logics as philosophers do to describe the universe [15, 16]. The mathematical concept representation in combination with systems engineering methodologies allows representing any system architecturally (i.e. the system’s components, their functions and internal as well as external relations) by generically describing its composition/decomposition as well as the aspects (domains) of the system relevant in a specific context (e.g. business case). For correctly and formally representing the concepts and relations of the domainspecific subsystems involved in that business case, those subsystems are represented by their corresponding approved domain ontologies, resulting in a system-theoretical, architecture-centric, top-level ontology driven approach [17, 18]. The reference architecture model can be used recursively, so representing, e.g., the real-world systems’ continuum from elementary particles to the universe (Figure 4).


Figure 4: Interoperability Reference Architecture Model granularity levels.

By combining that model with ISO/IEC 10746 [19], the Interoperability Reference Architecture Model (introduced in the nineties as Generic Component Model - GCM) as well as the applicable rules - the Interoperability Reference Architecture Model Framework - (also known as GCM Framework) is completed (Figure 5) [20].


Figure 5: The Interoperability Reference Architecture Model.

This Interoperability Reference Architecture Model allows consistently transforming and interrelating any domainspecific subsystem’s structure and behavior (e.g. domainspecific standards and specifications) by ontologically representing its concepts and relationships at the real world system component’s level of granularity. In other words, the domain-specific subsystem (e.g. a domain-specific standard or specification) is re-engineered using the Interoperability Reference Architecture Model, by that way providing a standardized interface to that specification (Figure 6).


Figure 6: Interoperability mediated by the ISO Interoperability Reference Architecture Model [4].

Bound to the GCM Framework, inter-domain relationships must happen at the same level of granularity [3]. To get there, intra-domain specializations/ generalizations have to be performed. In summary, the Interoperability Reference Architecture Model supports ontology harmonization or knowledge harmonization to enable interoperability between existing systems, standards and solutions of any level of complexity without the demand for continuously adapting/revising those specifications.

Examples for re-engineering existing standards to provide cross-specification or even inter-disciplinary interoperability can be found in [21, 22] regarding interoperability between HL7v2 and HL7v3 or in [23, 24] enabling use case and domaincrossing interoperability in the context of ISO 13972 Health informatics - Detailed clinical models [25]. The approach has also been adopted for ISO and CEN standards such as ISO 13606-1 Health informatics – EHR communication – Reference Model [14], where the reference model used for all parts has been re-engineered. The feasibility of the Reference Architecture Model and Framework has also been practically demonstrated for automatically designing inter-domain Web services to facilitate multi-disciplinary approaches to Type 2 Diabetes Care management [26]. Several cross-domain ISO specifications, such as ISO 22600 Privilege management and access control [27], ISO 21298 Functional and structural roles [28], or the HL7 Composite Security and Privacy Domain Analysis Model [29] are based on the ISO Interoperability Reference Architecture. A simplification of the model is the basis of the open architectures for national health information systems in developing African countries [30]. The approach also allows a comparative analysis and evaluation of ICT Enterprise Architectures [3].


Different interoperability standards, like HL7 Version 3 (including its Clinical Document Architecture – CDA, and its Clinical Information Modeling Initiative - CIMI) [31], openEHR/EN 13606/archetypes [32], OHDSI [33], OMOP [34], ISO 13972 [25], and HL7 FHIR [35], are all claiming to work on enabling and improving interoperability. Unfortunately, their concepts cover diverse aspects in different regards and maturity: communication, system architecture, reference architecture, network access across enterprises, layout/forms structure for data capture, persistency, entity relationship models, and last but not least conformance claims and capabilities. The use of vocabulary like classifications and terminologies, further advanced into knowledge representation in form of ontologies, adds another level of complexity. The dilemma is roughly demonstrated in Figure 7.


Figure 7: Modeling aspects for data integration.

In a previous study different interoperability levels from technical through structural, syntactic, semantic, service interoperability knowledge-based to skills-based interoperability are defined [4]. The HL7 V2 EDI protocol, but also HL7 V2/V3 Implementable Technical Specification (ITS) [31] as well as specifications of the observational health data initiatives OHDSI [33] and OMOP [34] define data structure and related data types at the physical data model level, addressing the modeling dimension of the 1-dimensional data approach. With HL7 V3, following the HL7 Development Framework (HDF), the HL7 Reference Information Model (RIM) – also standardized at ISO as ISO/HL7 21731 – has been defined [36]. That way, business case related data exchange via messaging, documents or services was defined, using ICT ontologies and therefore ICT concepts to reflect the business case. The related data model level is the logical one, considering the modeling dimension perspective of the 2-dimensional information approach. When representing the business concepts deploying the knowledge and methodologies of the involved domain experts expressed using their terminologies and ontologies, the high-level data model (or in the three levels metrics the conceptual data model) must be exploited. Regarding the modeling dimension, the 3-dimensional knowledge model applies here. The challenge of advanced interoperability for personalized, preventive, predictive, participative and cognitive care and precision medicine can only be managed by very-high-level data models, or the 4-dimensional knowledge space modeling approach, respectively. The four stages modeling dimensions roughly correspond to the modeling levels and their relations to specs as presented in Table 1.

Table 1: Comparing Data Model Levels [12], Dimensions of Modeling [13], and the ISO Interoperability Reference Architecture Model [4, 6], applied to specification examples.

Data Model Level Modeling Actors Model Scope Dimension of Modeling Interop. Reference Architecture Examples
Veryhighlevel data model Business domains stakeholders Scope, requirements and related basic concepts of business case Knowledge space Business View     ISO/CEN Interoperability Reference Architecture
Highlevel data model Business domains stakeholders Relevant information and representation & relationships of basic concepts Knowledge Enterprise View DCM, CSO ISO 10746 ODP-RM
Logical data model Data modelers and analysts Layout & types of data and object relationships Information Information View HL7 V3 (CMETs), HL7 CIMI, openEHR Archetypes, FHIM
Computational View HL7 FHIR
Physical data model Data modelers and developers Implementationrelated and platformspecific aspects Data Engineering View

As stated both in [8] and in [12], the described top down approach is inevitable when developing new, complex and interoperable health systems solutions. When adopting solutions within a well-defined business framework, a combination of top down and bottom up modeling processes is possible. The importance of ontologies has been declared in many papers. However, some just refer to the IT part of the interoperability, so addressing the ontology stuff just with IT ontologies such as the Web Services Modeling Ontology (WSMO) [1]. Table 1 summarizes the described data model levels [12] and the dimensions of modeling [13] in relation to the systemoriented, architecture-centric, ontology-based, policydriven ISO Interoperability Reference Architecture Model [4, 6] with its different model viewpoints. In the rightmost column, some sample standards and their association with the corresponding level or view is presented. Starting with platform specific specifications at the physical data model level, most of the so-called “higher level” standards must be placed on the 2nd level. Also newer developments such as the Federal Health Information Model (FHIM), a project under the Federal Health Interoperability Modeling and Standards (FHIMS) program within the US Federal Health Architecture initiative [37], belong to that level. Only a few reflect the conceptual level of business and domain knowledge to reach the 3rd data model level such as Detailed Clinical Models (DCM) [38] or the Communication Standards Ontology (CSO) [39]. Currently, just the ISO/CEN Interoperability Reference Architecture Model and standards including it fulfill the 4th level requirements, covering all modeling levels and dimensions.

Discussion and Conclusion

Despite the definition and standardization of architecture models for enabling advanced interoperability [4], many standards and specifications still rely on data models for managing that challenge, however ignoring or even incorrectly claiming to overcome the related limitations demonstrated in this paper. This does not just apply to the aforementioned specifications such as the RIM-based solutions, but is also a concern in managing clinical models such as the HL7 CIMI approach [38]. For more information, see, e.g., [23, 24]. Not just the presented classification systems, but also standard modeling conventions and data modeling best practices advise in overcoming the problems in data modeling and data governance management. The data modeling best practices [9] require getting the right people timely and properly involved in defining requirements. Furthermore, appropriate metadata must be recorded including core definitional qualities from physical attributes in the database or communication protocol context through any type of policies up to business terminology and business process management. Third, also the business understanding must be harmonized. That way, data modeling is a form of data governance from the definition through the production and the usage of data [9]. The data use includes risk management by protecting sensitive information and managing compliance. Details around data governance will be managed in another paper in preparation. All those data modeling best practices address more or less business domain experts and only partially information scientists, who currently wrongly dominate the process. To enable business process management and related decision support, the crucial level of data modeling is the very-high-level data model, equivalent to the 4-dimensional modeling process. Thus, the performed analysis justifies the interoperability approach of a system theoretical, architecture centric, domains ontology based and policy driven model [4] as approved by ISO TC 215 and CEN TC 251 and realized or in process in ISO 13606 [14] and ISO 12967 [40]. Other specifications will follow soon.

In this volume, Ed Hammond presents a very interesting consideration of the interoperability ecosystem [41]. Combining that work with our methodology can help formalizing a multitude of interoperability instances health systems are facing.


The authors are indebted to thank their colleagues from HL7, ISO TC 215 and CEN TC 251 for their kind and constructive support and cooperation.