Development of an ontology architecture to ensure semantic interoperability
between communication standards in healthcare
Appendix with additional explanations

Home -> Frank -> My Thesis

First Appendix A: Standards as a basis for the work

If a common standard is not used for communication, a company needs to convert the information received from a communication partner into their own data (database) format often at great expense. If it has multiple communication partners, this can result in great expense, if other data formats need be realized for each partner. The available resources force the vendors to agree on a few uniform standards.

In health care a variety of communications standards have been established over the years, which a number of organizations and institutions have specified. In part, these are complementary or competing standards. The two main standards - HL7 v2.x and V3 - will be examined in this appendix again.

As an introduction, the available standards are briefly presented with their essential characteristics. In part, fundamentals concerning usablity towards interoperability become obvious and can be evaluated.

1.1. EDI

EDI (Electronic Data Interchange) is the generic term for the "intervention-free" exchange of messages for controlling of business processes. With "intervention-free" we mean that in the exchange of structured data only computer programs are involved and therefore no manual intervention is necessary. As the data were originally only form-based information are to be transferred, as for example in orders or invoices. In the meantime, however, EDI has been extended to documents as well.

EDI standards are specified by official bodies (Standard Developing Organization, SDO) and be published in the form of specifications. However, each SDO has made their own rules for the specification of the transmitted data. These vary by country, region, industry and initiator.

Thus, by the United Nations (UN/ECE), the independent industry-standard EDI UN/EDIFACT [EDIFACTORY, UN/EDIFACT, a, UN/EDIFACT b] was developed and published as ISO standard 9735 in 1987. This standard is particularly widespread in Europe and thus for example also the basis for the reimbursement declaration pursuant to German §301 SGB V [§301] and the technical appendix 3 (TA-3) [§300 TA-3], and 4 (TA-4) for pharmacy data [§300].

1.2. ASC X.12

In the U.S. and Canada has prevailed in return by the Accredited Standards Committee (ASC) publishing ANSI X.12. X.12 is a logistic standard supporting orders, deliveries, goods receipts, invoices and payments [X.12].

1.3. HL7

Already in 1987, in Palo Alto a group of companies around the data exchange in healthcare - specifically between applications within hospitals - has come together to facilitate a cross-joint arrangement. "Health Level Seven" or HL7 was just born. At that time, it was based onASTM (American Society for Testing and Materials) [ASTM]. Very quickly, the first version (1.0) of the HL7 standards was developed, whose descendant (the family of the 2 versions) is now widely used and ANSI (American National Standards Institute) standard [ANSI].

In Germany an association founded in 1993 by a group of users [HL7-DE] has adopted the standards and tried by the use of HL7 interpretations (translations) to support extensions (Z-segments) and adapted to national requirements. By that time, one started with HL7 version 2.1, which was very rudimentary and quickly replaced by v2.2. The field of application was the hospital's internal communications. Even today, "HL7" is often associated with this type of communication directly referencing the v2 family.

HL7 [HL7] was originally designed purely to communicate patient-related administrative data. Meanwhile, the standard was expanded to include the exchange of medical data that captures the entire health and social services. Communication is the basis of the entire event-oriented message exchange.

HL7 now represents a family of standards that should be mentioned, since these also deal with the exchange of data:

Version 2.x and version 3.0 - the latter is a recent development based on its own methodology (MDF [MDF HL7]; further developed as HDF [HL7 HDF]) - are for the exchange of patient-related administrative and medical data in the form of messages. Details will be made in the Addendum.

It is not evident in the foreseeable future, which "family" will survive. Politically seen it should establish the version 3, however, purely pragmatic v2.x is so widespread, that's a relief is out of scope. Therefore, the focus is on version 3 to new domains that are not covered with v2.x yet. These two families are mutually incompatible. Closer inspection reveals that even within a family between the various versions/editions compatibility problems exist for which no solutions have been developed.

The Clinical Document Architecture (short CDA) [CDA] specifies the structure of clinical documents. Unlike a message-based standard, such as v2.x or V3, a persistent document is to be transmitted with the text in the foreground. It attempts to create a framework for the medical context in which a clinical document with any type of document (doctor's letter, findings, notes, ..) can be realized. The aim is to formulate any document so that it is both readable for humans and the computer. Hence, structuring and encoding of the text based on a markup language is necessary. This is achieved by encoding in the eXtensible Markup Language (XML [XML]) that can contain any text, including known markups for semantic information. (The beginnings of the CDA works go far back in time, that as the data format SGML (Standard Generalized Markup Language [SGML]) was intended due to the unavailability of XML.)
The documents themselves are divided in two parts - the header and body. The accompanying information (e.g. patient, author, ...) are placed in the header as meta-data, the body houses the text and additional clinical data. On the one hand, the body may contain a complete document in coded form such as PDF or RTF, then the header is only used for the transmission of additional data. On the other hand, it is assumed that at least (ASCII) text with corresponding XML markup is submitted. This can be prepared with the help of so-called XML style sheets so that the text is easily readable for the user. In addition, the text can be enriched with further markup, a computer program that extract these details in a structured way and re-use it.

Meanwhile, there are different releases to CDA (Rel. 1 + Rel.2) that are based on different versions (0098 and 0207) of the HL7 RIM (see below) [HL7-RIM]. Release 3 and a more general format ("Structured Document Architecture") are in progress as well. Furthermore, different levels are defined that uses the aforementioned different granularity in the body for various use cases.

<!-- Anamnese Komponente -->
Level 2   <code code="10164-2"
Level 1 <title>29.08.2005: Anamnese
Seit Jahren wiederholt chronische Bronchitiden besonders bei kalter Luft.
Bei Anstrengung expiratorische Atemnot.
Kontakt mit Haustieren.
Level 3 <entry>
<code code="195967001"
codeSystemName="SNOMED CT"

Figure 1: Level 3 CDA Rel.2 extract as example

Rarely explicitly mentioned is level 0, which provides for the embedding of arbitrary document formats such as PDF or Word in a NonXMLBody element. For CDA Rel.3 a level 4 is considered for references.

The Clinical Context Object Working Group (short CCOW) [CCOW] deals with the so-called "visual integration". Here it is meant, that different applications share their work context. The individual applications exchange context information via a special Context Manager, i.e. which patient data can be processed or just user logging in or off. Synchronizing a workstation's desktop eliminates time-consuming steps. The specification also provides that a context can be left (broken), for example in order to be able to finalize a document about a patient independently of other steps. The patient context can then be taken up by re-synchronization mechanisms. This type of integration requires a working data integration and master data on patient-level, so that patients or users can be identified by corresponding identifiers.

Furthermore, a number of "smaller standards" have been added, which also deal with communication and knowledge representation: Arden Syntax, GELLO, GLIF, ...
They play no role for this work.


SCIPHOX (Standardized Communication in Physician Offices and Hospitals using XML) [SCIPHOX] is a German initiative to facilitate data exchange between hospitals and GPs. Basis of this data exchange is the CDA standard. The first works for the referral and discharge letters were implemented (in 2000) based on the Release 1. In addition to the specifications, which information will be transmitted in the header, a series of message fragments, so-called "Small Semantic Units" (SSU), were specified which are transmitted in the body and normalize the important semantic constructs. A shortcoming of the Rel.1 of the CDA standard is the lack of structuring of the actual medical data. This shortcoming was partly compensated by the SSU.
For Rel.1 of the CDA standard one has sought to allow for conveying varying structured data to make a smooth transition from a purely text-based communication to achieve encoded information. This step in Rel.1 was however overtaken by the development of standards for CDA Release 2.

<birth_dttm V="1936-08-09"/>
<administrative_gender_cd V="M" S="2.16.840.1.113883.5.1"/>
<local_header ignore="all" descriptor="sciphox">
<sciphox:sciphox-ssu type="insurance" country="de" version="v1">
<sciphox:Kostentraegerbezeichnung V="AOK Köln"/>
<sciphox:Vertragskassennummer V="27101"/>
<sciphox:Institutionskennzeichen V="7632267"/>
<sciphox:Versichertennummer V="0612304653"/>
<sciphox:Versichertenstatus V="F" S="2.16.840.1.113883."/>
<sciphox:KVKgueltigbis V="2002-09"/>

Figure 2: Sample XML for SSU

The currently defined SSUs are listed in [SCIPHOX] in detail.

With the development of Rel.1 CDA has focused on the primary structure of documents in order to carry out the voting process successfully. At that time they had already thought about how a subsequent clarification of the information might look like without having to ask for it directly in the first step. With the parallel development of the XML standard, the enhancement of the HL7 Reference Information Model of Version 3 (RIM) and a better definition of one's own ideas a partial re-design of the CDA structure was carried out at this point with the Rel.2. One has then made up its mind from originally using different XML document root element in order to respect the XML capabilities to embed different elements. The finely-granular information was then introduced through deeper structured details accodring to the RIM and HL7 V3 convention methodology. Thus, the known Rel.1 SSUs became unnecessary and were be replaced by so-called Level 3 constructs in analogy to the Clinical Statement pattern/templates [HL7 V3 Templates].

Furthermore, the initial specifications (e-prescription) was developed based on Release 2. This work were performed by the TeVeGe [TeVeGe], a subsidiary of the KBV, based on the specifications of the Gematik [Gematik]. Thus can be stated here that the substantive work of SCIPHOX were outdated. The consortium was also dissolved and transferred to HL7-DE. The working group was then an important initiative to include the outpatient sector in the standardization of communication.

1.5. Detailed Clinical Information Models

A recent initiative in which the author is inititatingly involved, deals with generic clinical information models that are defined by a common activity of HL7 and IHE PCC Patient Care, Terminology and Vocabulary [DCM]. The results presented in this thesis papers on scores and assessment systems are incorporated there. Thus, the developed model is now accepted as DSTU (Draft Standard for Trial Use). The accompanying publication is in preparation.


Last Update: January 12, 2012