Implementation comments

<Apologies in advance, for such a long mail>

DSTC, here in Australia (www.dstc.edu.au), in conjunction with the GEHR
(Good Electronic Health Record) group, is working on an Electronic Health
Record implementation, based on the XML-Schema candidate recommendation. As
a result of using XML-Schema for Health Records, we would like to share some
of our experiences.

To briefly describe our use of XML-Schema:

The Good Electronic Health Record (GEHR) (www.gehr.org) is an open EHR
framework. Rather than prescribing a single and fixed clinical model, the
GEHR Object Model (GOM) provides the "building blocks" by which any clinical
model can be represented within the standardized framework. When GEHR
extracts are exchanged in XML, the health record instances must conform to
the structures defined in the GOM, to ensure that any GEHR-compliant
software product can interpret the basic structure of any Health record.
'Clinical archetypes' are then used to define how clinically valid
structures are constructed out of the GOM primitives. This approach allows
the process of standardizing the EHR framework to be separated from the
process of standardizing clinical data models. This is advantageous because
clinical data models may vary between different countries, states and health
care facilities.

Our goal has been to use XML Schema at two levels. Firstly, for representing
the structures and constraints in the GEHR object model. Secondly, to
represent the clinical archetypes, so that EHR extracts can be validated for
basic clinical correctness. In designing the GOM in XML-Schema the main
problems we encountered were:
        · The native GEHR Object Model used multiple-inheritance, which
could not directly be represented in XML-Schema. To overcome this we chose a
single supertype to inherit from, and included the elements of the other
supertype in an element group. This solution was satisfactory in most cases.
        · In some cases, unique and foreign keys could not be represented.
In particular, some of our EHR (Electronic Health Record) structures were
recursive, such as:
        <complexType name="G1_ORGANISER">
            <element name="name" type = "gom:G1_PLAIN_TEXT"/>
            <element name="content" type = "gom:G1_DEFINITION_ CONTENT_LIST
minOccurs="0"/>
            <element name="organiser" type ="gom:G1_ORGANISER" maxOccurs="
unbounded"/>
        </complexType>
Therefore to represent the foreign key constraint, that the recorder of an
EHR transaction must be defined in a demographic entity transaction, the
foreign key field would need to be defined as something like:

GEHR/event_clinical_transactions/transactions/transaction/versions/transacti
on/content/[{organiser/}]content_item/context/recorder
However, as the subpath "organiser" is optional and repeatable, this foreign
key cannot be represented as an XPath.
This example illustrates that some forms of unique and foreign key
constraints cannot be represented using XML Schema. This is probably,
however, a failing of XPath, rather than of XML Schema.

In designing the clinical archetypes in XML-Schema the single biggest
problem we had was:
        · In order to promote interoperability of health records, we require
that the GEHR XML instances must conform to the basic building blocks of the
GOM (using elements such as 'transaction', 'organiser', 'hier_group',
'hier_value', etc). Therefore, we needed to ensure that the archetypes could
be defined as "restrictions" on the complex types found in the GOM
XML-Schema. This, however, proved to be impossible.
        In particular, difficulties arose when it was necessary to predefine
the values that appeared in a list of items. For example, in representing an
archetype for 'blood pressure', the first value of the proposition must be
defined as a 'systolic' value, and the second value of this list as a
'diastolic' value. However, since it is not possible to repeat an element in
XML-Schema, it was not possible to express this structural constraint
naturally. For example, we would have like to be able to say:
        <complexType name="bpProposition" base="gom: HIER_ITEM_LIST"
derivedBy="restriction">
            <element name="hier_value" type="bp:SystolicItem" maxOccurs="1"
/> <!-the first value in the list -->
            <element name="hier_value" type="bp:DiastolicItem" maxOccurs="1"
/> <!-the second value in the list -->
        </complexType>
Because this definition is illegal, the only way to define this structure
was to extend "bpProposition" with the new values "Systolic" and "Diastolic"
; namely:
   <complexType name="bpProposition" base="gom:HIER_ITEM_LIST"
derivedBy="extension">
      <element name="systolic" type="bp:systolicItem"/>
      <element name="diastolic" type="bp:diastolicItem"/>
   </complexType>
The two major disadvantages of this approach are:
        1. You cannot constrain what extensions are valid for a list, and
therefore the GOM no longer constrains the valid building blocks of an EHR,
as intended.
        2. The XML instance can no longer be structurally interpreted by any
GEHR implementation, as the standardized GOM building blocks are no longer
used.
This problem arose in several places (such as predefining organiser
structures), and therefore a number of lists needed extending for this
reason.
This problem proved to be the single, biggest difficulty in using XML-Schema
for Electronic Health Records. Because of this problem, XML-Schema could not
be used as the primary means of defining clinical models in our Health
record.

Other problems we had included:
        · A similar problem occurred when trying to specify some archetype
constraints. In particular, we often need to restrict the value of a 'TERM'
to being from a set of valid coded terms - for example, the value of
"Patient Position" in a blood pressures' protocol must be restricted to one
of {('Lying', 75, 'GEHR_TermSet-v01'), ('Standing', 76, 'GEHR_TermSet-v01'),
('Sitting', 74, 'GEHR-TermSet-v01')}. While XML Schema allows enumeration
constraints over simple types, there is no similar mechanism to define
enumerations on complex types.  Therefore it was not possible for us to say
something like:
        <complexType name="bpPosition" base="gom: HIER_VALUE" derivedBy="
restriction">
            <element name="name" fixed="position"/>
            <choice>
                <element name="value" type="bp:LyingTerm"/>
                <element name="value" type="bp:StandingTerm"/>
                <element name="value" type="bp:SittingTerm"/>
            </choice>
        </complexType>
Although a number of methods for solving this problem were considered (e.g.
equivalence classes, extending existing types with new elements, qualifying
tags), no method was found which would not alter the structure of the
instance documents, and could be used consistently in all required positions
within the EHR.

        · Specifying keys and key references were not possible in some cases
(besides the case of recursion, as described earlier). Clinical archetypes
are defined at three levels - namely, the transaction, organiser and content
levels. Transactions contain organisers, which contain other organisers
and/or content. Therefore transaction archeytpes reference organiser
archetypes, which reference content archetypes (and other organiser
archetypes. Now because it was necessary to extend organiser definitions,
rather than restrict them (to predefine lists of organisers in an 'organiser
archetype', as per the main problem explained earlier), it is not possible
for a 'content archetype' to reference the full element path of the elements
it contains. This is because a 'content archetype' does not know which
organiser it is contained in (it is the organiser which knows which content
archetypes can be used within it). This means that it is not possible to
specify key references inside content archetypes.

We believe that the problems that we have encountered in using XML Schema in
the context of Electronic Health Records are not restricted to our GEHR
implementation, but will be shared in other approaches and standards. We
would, however, like to say that, despite the few problems described in this
letter, we feel quite positive about the XML Schema language as a whole.

Received on Sunday, 28 January 2001 20:59:08 UTC