Skip to Content

eHealthData – a Guideline for Schema Creation for Data Exchange in Health Care

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: 

  • KBV decided to use XML based specifications for data exchange instead of xDT formats.
  • KBV couldn’t use Clinical Document Architecture (and so its german adaption SCIPHOX) because it was designed to code clinical information only of one patient. So this specification is not suitable to submit master data like EBM(“Einheitlicher Bewertungsmaßstab”) or aggregated data of many patients.
  • They favoured uniformity over uncontrolled growth of different specifications.
  • 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:element />
        <ehd:element />
        <ehd: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=”” 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.


    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.
    You must be Logged on to comment or reply to a post.
      • Hi Ezequiel,

        the main difference between ehd and HL7 V3 is that ehd has no framework for modelling business messages, we don’t have RIM for example.

        It’s a lightweight approach that could be replaced by HL7 V3 Messages – and perhaps it will be. In my opinion it is a very pragmatic solution but in my opinion the inventors have been able to improve the quality of existing data exchange scenarios.


    • Hi Tobias Trapp,

      no doubt that it is easy to develop new messages resp. their syntax with ehd.
      The simple, straightforward and intuitive approach makes it easy to derive some syntax from a given meaning.
      Another good  reason – also mentioned in your article – is the ability of available tools to process huge data with some classes having a large number of instances.
      However, XML is the syntax of one of multiple possible ITSs for a given information model, there may be other suitable formats as well.
      The discussion is not about a syntax or a format but its capability to express elements of complex information models.
      So, the real point is whether to work model-driven or not – having in mind, that information models (together with implementation guides) can capture the meaning of concepts in the application domain, i.e. “outside” of IT.
      Without the related information model and without a syntax that expresses the model’s elements, there is no defined way to express and process “meaning” – in the clinical sense.
      So the real value of a message format is its relation to an information model plus the expressive power of that model – in terms of the medical application domain.
      In addition, to make the various IT-systems of players in health care or even within a single organization, work together seamlessly, the related information model must be standardized and publicly available.
      Without a reference information model, the same meaning or intention would have different syntactical representations since there is no guidance to mapping meaning to message. On the other hand, a single given ehd message could have different interpretations, since the various elements of xml act as containers for something and not as containers for application concepts
      As far as I know, in the healthcare domain there is no comparable model to HL7v3, there is no standard available so easy and well-documented and there is not a group of users and vendors working together as enthusiastic as the HL7 community.
      The broad range of expertise available to HL7v3 domains and the established balloting process guarantee, that relevant knowledge is integrated into the models and that investments into IT are long-lived, since the models are more stable than home-brew models which are often updated secretly and without public notice or justification.

      Protect IT-investments, go for a standardized, publicly available information-model and choose an ITS that expresses the elements of that model

      With best regards,
      Georg Heidenreich

      Siemens AG
      Medical Solutions
      MED S&T 2
      Henkestr. 127
      91052 Erlangen, Germany
      Tel.: +49 (9131) 84-6498
      Fax: +49 (9131) 84-6555
      Mobile: +49 (160) 7067131

      Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Klaus Kleinfeld, Chairman, President and Chief Executive Officer; Johannes Feldmayer, Joe Kaeser, Rudi Lamprecht, Eduardo Montes, Juergen Radomski, Erich R. Reinhardt, Hermann Requardt, Uriel J. Sharef, Klaus Wucherer; Registered offices: Berlin and Munich; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322