Medical Informatics in a United and Healthy Europe K.-P. Adlassnig et al. (Eds.) IOS Press, 2009 © 2009 European Federation for Medical Informatics. All rights reserved. doi:10.3233/978-1-60750-044-5-200
200
Semantic Interoperability between Health Communication Standards through Formal Ontologies Frank OEMIG a,1 , Bernd BLOBEL b Agfa HealthCare GmbH, Bonn, Germany b eHealth Competence Center, University of Regensburg, Germany a
Abstract. The paper shortly analyses the HL7 communication standards for resolving the gap between them by developing a set of ontologies reflecting the concepts and relationships which is exemplified with the incompatible HL7 versions 2.x and 3. Bridging between the different ontologies is performed by introducing a reference ontology to which a mapping is defined. The paper discusses problems and solutions which appeared during the development process. Keywords. HL7 Version 2.x and V3, semantic interoperability, formal ontology
1. Introduction Diverse underlying methodologies cause incompatibility between the different families of HL7 messaging communication standards – version 2.x and V3. Hence without adaptation, an interface engine is unable to fully understand the contents of a message sent in the inappropriate version. The European Union has funded the ARTEMIS project [1] introducing the use of ontologies to cope with this problem beside others. Bicer et al. [2] describe how an ontology has been created to convert instances of specific messages of one family into instances of the other, thus simulating the functionality of a traditional communication server facilitating the Web Ontology Language (OWL) [3]. Therefore, every change within a message instance requires an adaptation. This paper describes the approach to establish semantic interoperability among the different HL7 versions 2.x and 3 by creation of related formal ontologies and bridging between them, facilitated by a reference ontology.
2. Methods Assuming that the reader is aware of the different HL7 standards families [4], they are not described in detail. Instead, short explanations about the creation of ontologies are provided. The integration of a reference ontology bridging the different structures of
1 Corresponding Author: Frank Oemig, Agfa HealthCare GmbH, Konrad-Zuse-Platz 1–3, D-53227 Bonn, Germany; E-mail:
[email protected]; http://www.agfa.de/healthcare; http://www.oemig.de/hl7.
F. Oemig and B. Blobel / Semantic Interoperability
201
those standards appears necessary. The complete work is analyzed using the Generic Component Model (GCM) architecture framework [5, 6]. 2.1. HL7 Version 2.x In order to detect inconsistencies within the v2.1 standard specification, the first author has created a database for HL7 version 2.1 in 1993 [7]. By incorporating all consecutive v2.x versions until today, an unofficial meta-model has been developed which is widely accepted now (i.e., used by different vendors as background for their IDE) and supports meeting the interoperability requirements. The database can be used as foundation for creating version-related ontologies which are generated by VB scripts reflecting the meta-model behind. In principle, it covers the tables (vocabulary), data types with assigned components, and message structures with segments and fields with recursive one-to-many relationship. The dashed arrows in Figure 1 provide an overview of this generation process. 2.2. HL7 Version 3 In contrast to version 2.x, version 3 is built according to the HL7 Development Framework (HDF). The HDF introduces different artifacts, which are necessary to create domain-specific models including the vocabulary binding and the conversion into XML schemas by incorporating the abstract data type specification. A set of tools supports this process. In return, the whole standard is provided in the so-called Model Interchange Format (MIF), which is an XML dialect close to XMI. The MIF files are taken as input to XSL-Translations which convert them into a set of OWL files representing appropriate sub-ontologies. The resulting structure reflects the three basic columns of HL7 V3: vocabulary, data types and the reference information model (RIM). Due to the complex structure of the MIF files, the intended ontology is built by importing the generated sub-ontologies (represented as “import ontology” in Figure 1). According to the HDF, the aforementioned columns are used to define domain-specific models. The latter’s contents are again represented as MIF files and can be translated into ontologies specific to those domains via XSLT. In order to achieve semantic interoperability, the relevant ontologies must be combined with additional information from the domain information models and derived refined models (RMIM, HMD) resulting in a domain-specific ontology. 2.3. BFO: Basic Formal Ontology as a Foundation As a first approach starting with the development process, a suitable reference ontology (RO) has been created from scratch. Research on the Internet revealed an RO which seemed to be applicable and could be used instead: the Basic Formal Ontology (BFO) [8]. BFO itself is used as foundation ontology for a set of other ontologies which are built for specific purposes. The specification for Advancing Clinico Genomic Trials on Cancer (ACGT) [9] is one of those which also contains more domain-specific details and may play the role of an RO as well.
F. Oemig and B. Blobel / Semantic Interoperability
202
2.4. Tools: Protegé Our newly created ontologies as well as the downloaded ones can be visualized with Protegé [10], a WYSIWYG editor for ontologies provided by the Stanford University. As most of the ontologies are generated or converted from another source, this tool is primarily used for visualization. Only the mapping ontologies must be created manually. In order to support future mappings, it must be discussed whether this process can be semi-automated by the help of other resources.
3. Results The presented results are based on conceptual work and represent the current status. 3.1. Ontology Structure As introduced above, Figure 1 provides an overview on the resulting HL7 standards mapping structure. The dashed triangle arrows represent the tooling process as already mentioned, while the solid open arrows represent the structure which is used to import the underlying ontologies. The latter is required due to the way ontologies according to OWL are managed, only allowing a complete import instead of including files. Top-Level Ontology v2.x
Reference Ontology
Top-Level Ontology V3
is-a is-a
HL7 v2.x Ontology
Domain Ontology
ACGT imports
imports
Mapping Details
Mapping Details SBO
Mapping Details
imports
Vocabulary
ImportOntology Data Types
RIM
XSLT / VB-scripts is-a
VB-scripts
HL7 DB
is-a
BFO
Mapping 1
Mapping 2
MIF
MIF
MIF
MIF
Figure 1. Ontology structure
The top-level ontologies are abstract, while the next lower level represents the instantiated and implemented ontologies. 3.2. Use of ACGT as RO An analysis of ACGT in comparison with the requested concepts has demonstrated that it lacks essential concepts or has partially a different understanding of concepts (e.g., “legal name”), respectively. Instead of providing the same level of granularity as required, it is just very close to the desired and necessary structure and granularity of concepts. To bridge this gap, ontologies are designed to reuse fitting components. On the other hand, the import functionality of OWL allows enriching it with new concepts. Therefore, two different options are possible: a) changing the existing ACGT
F. Oemig and B. Blobel / Semantic Interoperability
203
specification or b) defining a new ontology completed by importing ACGT. The authors have decided to follow the second approach as it would facilitate the discussion with the creators of ACGT and the track of differences. This is represented as “mapping details” by importing ACGT. 3.3. SBO SBO – the Semantic Bridging Ontology [11] – is the RO to define the details of structural mappings. Only a few items can be mapped directly. Most of the information requires a mapping of structures, e.g., the name parts are provided differently. 3.4. Mapping Functions In order to achieve semantic interoperability, the different ontologies have to make use of the same atomic concepts. Therefore, we have to normalize the structure by adding a level for “atomic” concepts. This level is represented as “mapping details” in Figure 1. As far as possible, these ontologies should be generated from existing sources. This step is necessary because some information is only available as complex elements. Regular expressions may help to support this generation process. Table 1 provides a rough overview of the required functionality. Table 1. Required functionality for mapping concepts
Function concatenate/split equal/same as map
Explanation Elements must be concatenated or split using regular expressions. Information items can directly be assigned to each other on the granular/atomic level. Look-up tables allow for converting coded elements.
The information for telephone numbers is a good example demonstrating that this process must allow for nested (recursive) definitions. 3.5. Conditions In some cases, the mapping depends on conditions which must be expressed in the mapping ontology. A good example thereof is the mapping of names where the nametype specifies the pre-condition to execute a mapping into the appropriate target concept structure. 3.6. Expanding the Reference Ontology The core principle of the described solution is the mapping to a central reference ontology. As a consequence, the RO must contain all (atomic) concepts which are necessary to allow a mapping. In order to keep it simple, the RO should be domainspecific. Therefore, each domain will be mapped to a special RO which can be defined as an addendum to the base RO. As represented in Figure 1, semantic interoperability between different communication standards is established by mapping to the same domain-specific reference ontology. Therefore, the bridging between two different ontologies is achieved by an
204
F. Oemig and B. Blobel / Semantic Interoperability
engine which concatenates two different mappings. This process is indicated by the big white arrow in Figure 1. By this way, a high level path is given which can be pursued from one basic ontology (either v2.x or V3) to the other one and vice versa. 3.7. Maintenance/Versioning Another important issue is the maintenance of the RO and the mapping to, and from, the communication standards trying to reduce manual adjustments. This approach profits from the generic definition of structural mappings which integrate the different parts provided by sub-ontologies.
4. Conclusions Contrary to the approach described by Bicer et al. [1, 2], the details are not mapped based on specific messages. The biggest advantage of ontologies is the reuse of defined relationships between concepts establishing a hierarchy of structural mappings. This includes “inheriting” relationships from one part of an ontology to another. It also enables transferring the mapping specification from one domain to another and making it applicable for a set or messages in parallel, by that way reducing the efforts to be spent to the distinct set of “structural concepts”. However, a huge set of mappings must be provided.
References Artemis-Project, A Semantic Web Service-Based P2P Infrastructure for the Interoperability of Medical Information Systems, http://www.srdc.metu.edu.tr/webpage/projects/artemis/. [2] Bicer, V., Laleci, G.B., Dogac, A., Kabak, Y. (2005) Providing semantic interoperability in the healthcare domain through ontology mapping. In Cunningham, P., Cunningham, M. (Eds.) Proceedings of eChallenges: Innovation and the Knowledge Economy: Issues, Applications, Case Studies. IOS Press, Amsterdam. http://www.srdc.metu.edu.tr/webpage/publications/2005/2005healthcareSemanticInteroperability.doc. [3] OWL: Web Ontology Language, http://www.w3.org/TR/owl-features. [4] Health Level Seven, Inc., http://www.hl7.org. [5] Blobel, B. (2002) Analysis, Design and Implementation of Secure and Interoperable Distributed Health Information Systems. Studies in Health Technology and Informatics Vol. 89, IOS Press, Amsterdam. [6] Blobel, B. (2000) Application of the component paradigm for analysis and design of advanced health system architectures. International Journal of Medical Informatics 60(3):281–301. [7] Oemig, F., Dudeck, J.W. (1996) Problems in developing a comprehensive HL7 database. In Proceedings of the AMIA Annual Fall Symposium 1996, 841. [8] BFO: Basic Formal Ontology, http://www.ifomis.org/bfo. [9] ACGT: Advancing Clinico Genomic Trials on Cancer, http://www.ifomis.org/wiki/acgt. [10] Protegé, http://protégé.stanford.edu. [11] Maedche, A., Motik, B., Silva, N., Volz, R. (2002) MAFRA – An MApping FRAmework for distributed ontologies. In Knowledge Engineering and Knowledge Management: Ontologies and the Semantic Web, Proceedings of the 13th International Conference EKAW 2002, Springer, Berlin, 69–75. [1]
