Balisage Paper: An XSLT Translator for the openEHR Archetype Definition Language

Introduction

A typical electronic health record contains an array of information about a patient, built up over their lifetime; some information is very structured (laboratory text results, for example), some almost completely unstructured (e.g. notes on a consultation in clinic). The ISO-13606 standard [1] includes a specification for the structured representation of the health record as a set of Compositions, containing Sections with Entries containing Elements and Clusters of Elements. The Compositions can (optionally) be organised in Folders, so that the whole health record resembles a filing cabinet (the EHR_Extract) containing folders of paper documents, as shown in Figure 1

Figure 1: Structure of an Electronic Health Record in ISO-13606.

The HL7 CDA standard (Health Level Seven, Clinical Document Architecture) [2] defines an XML vocabulary for the markup of a clinical document and follows the same basic structure as the ISO-13606 standard, starting at the composition level (a Composition in ISO-13606 is equivalent to the document element cda:ClinicalDocument in HL7 CDA).

The structure of the health record defined by ISO-13606 and HL7 CDA is completely generic; the same structure applies to a record of vital signs made during an operation, to a set of laboratory text results sent from the lab to a general practitioner or to questions about lifestyle answered by a patient when attending a clinic.

The cityEHR Electronic Health Records system, which has been developed since 2010, is an XRX (XForms, REST, XQuery) application for managing electronic health records [3]. The system runs as an Enterprise Java application, using the Orbeon Forms framework [4], accessed through a web browser and web services interfaces. It is designed as a completely open system, using XML and healthcare-specific open standards, and although running through a Java framework, it contains no Java code of its own; all code is XML, XSLT, XQuery, XForms, XHTML or CSS. The health record in cityEHR is stored as a collection of HL7 CDA XML documents in the eXist native XML database [5].

cityEHR uses a multi-stage modelling approach to define the clinical data set that will be gathered in any specific clinical setting. The intention is that clinicians themselves should design the information models that define the entries and elements in the dataset for their specific requirements, which are usually a combination of the requirements for their clinical specialty (e.g. Rheumatology, Respiratory, Liver and Bilary, etc) and the requirements for secondary use of the data in clinical studies. The stages of modelling in cityEHR are shown in Figure 2.

Figure 2: Information Models for the Electronic Health Record in cityEHR.

The multi-stage modelling approach used in cityEHR is inspired by an earlier initiative, whose roots can be traced back almost thirty years. openEHR (openehr.org) is an open framework for modelling healthcare information, in a form suitable for the design and implementation of Electronic Health Records systems. It builds upon a number of funded European initiatives, from the early 1990's onwards, and the ISO 13606 standard that arose from those initiatives [6].

openEHR has an abstract reference model for healthcare information that is based on, and extends, ISO-13606. It uses a two-stage modelling process whereby the models for specific clinical settings, called Archetypes, are specified using the Archetype Definition Language [7] which applies the constraints of the Archetype Object Model. In its simplest form, an archetype corresponds to an Entry in the ISO-13606 model (cda:Entry in HL7 CDA), but a collection of entries can be grouped into a template which corresponds to a Composition in ISO-13606 (cda:ClinicalDocument); to achieve this, a template may include other externally defined archetypes. A template_overlay is an Archetype that is used to overload, or specialize, an existing template (for example an internationally published template may be adapted for use in a particular local setting); an operational_template is a template that has been flattened by expanding any included archetypes and applying any overlays. All four types – archetype, template, template_overlay and operational_template – are referred to generically as Archetypes.

The Archetype Definition Language, in its original form, was an example of a domain-specific language [8], created to describe specific clinical information models that conform to a more general model of the structure of an Electronic Health Record. Since it was first conceived, it has been generalized, so that it can be used to define any set of models that conform to any underlying reference model. This generaliztion has made ADL similar to an XML schema language, except with its own unique syntax, and complicates the task of creating a parser in XSLT. However, since XSLT2 is a Turing complete language [9], it should, theoretically, be possible to build such a parser.

In recent years there has been a growth in the number of published archetypes available through public repositories and there are now a number of large-scale EHR systems, both commercial and open source, that can be configured using them (so in that sense can be said to be openEHR compliant systems). In consequence, it was decided that the cityEHR should be enhanced with the ability to consume and generate information models expressed using ADL.

Although there are existing Java implementations of ADL parsers and AOM serializers [10], the design principles of cityEHR prohibit the use of third-party Java code, outside the unmodified code of Orbeon and eXist. To maintain this principle, an ADL translator has been developed in XSLT 2 so that cityEHR can now be configured using information models published using ADL.

Methods

The ADL translator is implemented using the principles of multi-pass compilation, whereby the target code is constructed in stages, through multiple passes through the source code [11]. The multiple stages are implemented using the XML pipeline implementation in Orbeon Forms, and follow the four classical stages of a multi-pass complier: lexical analysis, syntax parsing, semantic analysis and target code generation.

Each of these stages is implemented in XSLT2, using the regular expression support in the XPath functions tokenize() and matches(), together with the XSLT <analyze-string> element and a number of recursive templates.

The output of the first three stages is an Abstract Syntax Tree (AST), in XML, representing the source ADL at increasing levels of detail. This is similar to the approach described by Badros [12] in generation of JavaML, an XML representation of Java source code, and more generally by Maletic et al [13]. By the final stage, the input AST is complete enough to generate the target code, which is a set of OWL/XML assertions suitable for loading in cityEHR, to define its information model.

The regular expression (regex) capability of the XSLT <analyze-string> element can be used to parse parts of the source ADL. However, the mathematical model underlying regex is that of a Finite State Automaton – a process which consumes the source code string by matching patterns and at each point is in a single state, from a finite set of defined possibilities. This model is not sufficient to parse the repeated nested patterns that exist in some sections of ADL; these require a more sophisticated Pushdown Automaton, which uses a stack to keep track of the state of nested patterns which could lead, in theory at least, to an arbitrary number of states. One method of implementing a Pushdown Automaton in XSLT is to use a recursive template to push the current state onto the stack, which is passed as a parameter to the template.

Structure of the Archetype Definition Language

An ADL source code file can be one of four types – archetype, template, template_overlay, operational_template – which is specified in an initial ADL Declaration. Following this declaration, the overall structure is a sequence of sections; the sections are always in the same order but some are included, excluded or optional, depending on the declared type.

The ADL Declaration has its own syntax and within each subsequent section the syntax follows one of three defined sub-languages; cADL (constraint ADL) [14], ODIN (Object Data Instance Notation) [15] or FOPL (First Order Predicate Logic). In addition, there are several sub-languages that are used at defined points in the ADL code for referencing objects in the model (the ADL Path Language) and the The overall structure of the ADL source code for an archetype of type template is shown in Figure 3.

Figure 3: Overall structure of ADL Source Code for a template archetype.

Conclusions

It has proved feasible to implement a translator for the Archetype Definition Language using XML pipeline processing and XSLT 2. The target language for the translation was OXL/XML, using assertions specific to the cityEHR architecture, but target code could also be generated in other representations, if required.

The motivation for implementing using pure XML technology was to avoid dependence on third-party Java packages and achieving this is probably the main advantage offered by the methods outlined in this paper.

There is a large body of ADL archetypes and templates available in public repositories and the next step in this work will be to test the translator against a sample of these test cases, which will inevitably lead to refinement and improvement of the first version described here.

Although the translator described here is sufficient to generate valid OWL/XML information models for cityEHR in a practical subset of ADL archetypes, it is envisaged that more thorough testing will lead to additional refinement, especially of the semantic analysis stage, in order to accurately translate any published ADL archetype.