Important Step to Fill the Gap? - The German SCIPHOX Project

1. Introduction

In many countries two arenas of electronic medical data interchange can be found: the HL7 (Health Level Seven) domain, largely to support the information exchange between applications in a hospital environment and the non-hospital arena, f. i. the communication between Physician Offices / General Practitioners (GPs).

In Germany the use of HL7 [1] is widespread for communication within and between applications in hospitals. In the GP arena a local proprietary protocol suite has been established here, called "*DT".

2. The general practitioner arena in Germany: *DT

First interface specifications for the "*DT" set of protocols were endorsed by the German physicians statutory association in 1988 and were intended for storing and also exchange of data in the outpatient area only. This suite of exchange formats primarily support the reimbursement process (ADT), the storage and communication of lab results (LDT) and other medical findings (BDT), among others. It is a tag-oriented format that includes a four-digit tag number, the content and a length specification. Figure 1 shows an example.

Figure 1: Example of information encoded in the German *DT forma

An example of information encoded in the German *DT format (city and zip given). len=length of information in bytes, tag=tag number (drawn from a repository, see text), content and a fixed <CR><LF> as an end indicator (thus it is a line oriented format).

Although it is a pragmatic approach without an underlying data model an important advantage of the specification is that it includes a repository of tag numbers for data fields along with their semantics, type and rules how to fill in information (f. i. how to denote a quarter year). The presence of a repository also implies that requirements of amount and content of electronic data exchange in this area are known and defined within the specifications. This fact clearly influenced the design and implementation of physician office systems (POS) of various vendors towards interoperability.

Most implementations of the *DT format focussed on local storage of data rather than exchanging the information between systems in terms of messaging. Only some projects in the past could show that the protocols might also be used for communication purposes, although they have to be adapted to this use case.

There have also been efforts to express the original format in XML (called XDTML) but without adding additional advantages to the specification.

3. The hospital area in Germany: HL7

HL7 (Health Level Seven [1]) is commonly used to exchange information between applications in hospital information systems (HIS). HL7 v2 is a very widespread sequence oriented message format that not only covers medical but also administrative (f. i. admission, discharge of transfer information of patients within the hospital) and financial information, among others. It is an ANSI accredited specification, originally developed in the US which meanwhile also adopted international requirements: 15 international HL7 affiliates from all over the world influenced the development of HL7 over the last years towards an internationally accepted standard. The development of HL7 v3, a model based international approach uses new technologies such as UML modelling etc. but also takes advantage the extensive experiences gathered through the v2 development process.

HL7 v2 has low requirements for specific properties of the involved applications or for a specific data model. The HL7 specification comprises of the definition of the message structures (syntax) and the message content (semantics) given in the abstract message definitions and also provides an interchange format (see Figure 2 for examples) and management rules for message processing, given in the encoding rules. Although v2 messages are commonly denoted in the so called vertical bar encoding (Figure 2 part a), there is also an alternative interchange format based on XML available called v2.xml (Figure 2 part b) It is expected that it will be used more and more when new or revised HL7-aware software application are build. Several European projects already rely on this alternative encoding using XML. The upcoming version 3 of HL7 that is expected to come out at the end of 2001 will explicitly make use of XML.

Figure 2: Classic HL7 Version 2 Encoding

"Classic" HL7 version 2 encoding (a) using vertical bars (example shows only a fragment of an HL7 message, i.e. a single segment, with a medical observation result) and the new alternative XML based message encoding called v2.xml (b). Although v2.xml messages are obviously longer, off-the-shelf processors could be used to process v2.xml messages rather building proprietary parsers for the "vertical bar syntax" shown in (a). Version 3 of HL7 - expected to come out at the end of 2001 - will explicitly make use of XML.

In Germany HL7 v2 is used since 1993 in the sense of intra-hospital communications. Some projects also deal with hospital to hospital communication (H2H). Because of the preceding presence of the *DT protocols in the outpatient area the use of HL7 in Germany was never extended to cover the GP to GP communication, although HL7 v2.3 and higher could be used for that purpose. For the GP to hospital communication, f. i. for referral or discharge letters, there is no appropriate electronic data exchange at all - there is a gap.

4. The SCIPHOX-Project

The goal of the German project "Standardisation of Communication between Information Systems in Physician Offices and Hospitals using XML" (also called SCIPHOX) is to close this gap by providing an XML based method of communication between the two parts. The project started at the beginning of the year 2000 with a pilot study aiming on content definitions and the implementation of a prototype demonstrator. Partners for this first phase came from both arenas described above, namely the Physicians Statutory Organisation and associated institutes, POS and HIS vendors, various vendors associations, the HL7 user group Germany (the German international affiliate of the HL7 US organisation) and some universities.

Phase I aims a discharge letter from Hospital Information Systems to Physician Office Systems and the exchange of referral information. In this context, discharge letters are intended as instant short reports ("immediate discharge letter lite") to the corresponding/referring GP as an end-of-treatment summary. It contains major aspects of the treatment episode including diagnoses, procedures, findings and further medications. Ideally it's directly derived from clinical documentation and/or from HL7 messages in the hospital information system. Content definition is done in the project using the experiences made creating the HL7 and the *DT information models or repositories respectively. The first official documents appeared in the first quarter of 2001 (see [2] ).

SCIPHOX phase II starts in summer 2001 as a real-world implementation project and will cover the transport logistics and the accompanying security mechanisms.

5. SCIPHOX, technically spoken

As a "backbone", HL7's Clinical Document Architecture CDA ( [3]) was chosen. The CDA is an ANSI approved XML based document architecture for exchange of clinical information. The CDA specification provides a header and a body. The header part contains information about

• the document itself including version handling,

• the event that caused the creation of the document,

• service providers such as physicians, and

• service targets such as patients.

The SCIPHOX proposal specifies the use of the CDA header, taking local needs (insurance information etc.) into account. It also provides a kind of mapping between the *DT information and CDA tags and a repository of tags used in the CDA body and the local parts of the CDA header. In this context the preceding independent efforts on alternative XML based encoding on both, the *DT and the HL7 protocols were helpful. Furthermore coded items make use of a defined vocabulary, for instance to express clinical locations.

The body part, largely structural markup, conveys the most important information like diagnoses, procedures, further steps (medication etc.), scheduling information or even free text (with or without further markup). Here also the efforts of building a repository for clinical data exchange during the *DT deployment process contributed important input to the project, although the *DT development only covered the GP to GP communication. Thus HL7 provided the complimentary part of input for the content definitions, a third role played intensive document analyses of the forms used for "normal" paper based information exchange.

6. First results

One important point in using the CDA as a document specification is that CDA documents persist by definition. Messages do not necessarily persist after being sent from let's say system A to system B. Normally message item content is stored in database fields but context is not necessarily preserved.

Second, because the CDA specification is completely build on XML different needs in today's clinical reporting can be covered:

• narrative reporting as usually used in paper based correspondence with or without additional markup

• coded entries such as diagnoses or procedures that can be (and must be by legal requirements) encoded in specific coding systems such as ICD (international classification of diseases) or ICPM (international classification of procedures in medicine)

• anything in between these two extremes of narration and highly structured documentation.

This fact can be seen as a possibility for a "smooth" migration process rather than enforce superfluousness of existing (and successfully running) approaches in healthcare application communication and data storage. Relying on the standard approach also ensures a high degree of "shared semantics" and thus tries to find a compromise between local specialisation and global generalisation.

A third aspect must be mentioned that comes from the flexibility of XML itself. Because of (legal) requirements in healthcare in Germany and many other countries, several efforts were ignited to create clinical reports such as discharge letters, message specifications or even electronic patient record systems. They are based on various but sometimes not standardised work. The outcome from these activities f. i. is a variety of XML based specification that each uses different tag names for the same semantic content and - which could be even more fatal - different underlying data models. The flexibility of XML not only allows this effect, it "encourages" diversity and thus could elicit lack of interoperability.

Future projects in healthcare using XML should be build on already available standardisation efforts and they should participate in or contribute to the never ending story of healthcare standardisation. Data repositories along with controlled vocabulary will surely play an important role. An important goal for the very near future is to utilise XML as a vehicle for interoperability rather than for individuality.

Design and Development by deepX Ltd.