This blog entry is about specification for data exchange in health care. ehd (a short form for aHealthData) is a guideline for schema creation in health care invented by KBV. It was created because of following reasons:

ehd wasn’t designed as a standard, in fact it’s related to other standards like CDA and SCIPHOX. If these standards should develop in direction that they fulfil the above described needs it is not unlikely that ehd will re replaced by an adaption of HL7 Messages for example. But even in this case changing a family of specifications that are similar to existing HL7 specifications is easier than replacing a bunch of specifications with no defined structure.

Generic Concepts of Modern Specifications for Data Exchange

Modern specifications for data exchange are family concepts that contain rules for

• transport layers,
• naming conventions,
• business messages,
• repositories for data types and
• rules for designing messages.

This is no surprise: XML is just a syntax for tree like data structures but doesn’t contain any semantics so this has to be defined on its own. Therefore we can use the “XML infrastructure” to model appropriate messages and to process them using transformation languages or standardized APIs.

A Brief Look onto ehd

What are the differences between ehd and SCIPHOX? SCIPHOX defines XML schemas for called Small Semantic Units (SSUs). SSUs define patient information that are relevant for german health care system. Therefore local markup of CDA was used. ehd wasn’t created for SSU definition but for creating data centristic XML documents that are similar to CDA documents. Compared to HL7 V3 ehd is a lightweight approach because it isn’t a framework for modelling business information.

ehd has following properties:

• It is defined using W3C XML Schema and every valid ehd document is valid according a basic schema: consisting of at least three XSD files:

• It uses a slightly modified CDA header without any patient information. The “payload” is contained in the body element.
• It uses ISO 8859-1 (Latin 1).
• The elements (i.e. their complex type) ehd, header, body and keytabs will be derived by restriction and will be redefined in a concrete specification:

• The header is extensible by using local elements that can be redefined :

  <xs:element ref="local_header" minOccurs="0" maxOccurs="unbounded"/>
  

  ehd recommends to use a collection pattern (an enclosing element) for repeatable elements:

  <ehd:collection_of_element>
    <ehd:element />
    <ehd:element />
    <ehd:element />
  </ehd:collection_of_element>
     

  This helps to use serial transformation languages like Simple Transformations and STX to process mass data.
• Like CDA and SCIPHOX ehd uses OIDs to refer to external code lists:

  <ehd:element V=”1” S=”1.2.276.0.76.5.237” SV=”1.01”>
              

  Here’s the link to the german OID register for health care.
• With the keytab-element we add code lists to the payload. With schema validation we can ensure that they are double codes within a code list specified by an OID. Furthermore we can check whether the codes in the payload correspond to submitted code list.
• ehd supports reusing type libraries from SCIPHOX (sciphox.xsd) and ehd types (ehd_typelib.xsd) and allows to create own libraries.
• ehd can be used by other institution than KBV. This is described in the ehd guideline.

Summary

In this blog entry I gave a short introduction into ehd. I think the following is worth mentioning:

• If you can’t use an existing standard try to be as close to the standard as possible.
• XML schema creation is a difficult task. Standards are a source of good practices for schema design. So recommend to create guidelines for schema design by an XML expert.

When I worked with ehd I learned the following:

• If you expect to process huge XML documents you should use a simple structure so that the document can be processed using serial transformation languages resp. serial APIs.
• Last but not least: A lot of people think of XML as a silver bullet and this is completely wrong. When we choose to modify an existing data exchange scenario and use a modern syntax we should also try to analyse the existing processes and ask whether we can apply IT driven optimization.

But what is IT driven optimization and why it is important? Today most business processes are done using IT – but are these IT scenarios designed in an appropriate way to support business processes? In my opinion we should start to ask what kind of problems in existing processes occur. Let me mention a few together with possible solutions:

• If data quality matters we can try to use the full power of XML infrastructure to define the correctness of an XML message or even of parts of them using formal methods. Sender and receiver can use standard software to check the payload in a data exchange scenario.
• If existing specifications use proprietary code lists we can try to use existing standards in new data exchange scenarios.
• We can try use request/response scenarios to make data exchange more transparent.