Software Implementation of CDA
Notes:
- this page contains a draft deliverable for RIMBAA project 550
- the whitepaper is based (in part) on a Dutch whitepaper, elements of which have yet to be translated
Contents
Summary
This paper addresses the creation of a software application that has to support the CDA R2 model. It discusses the application architecture, and discusses various approaches with regard to code generation and persistence. Note that this paper assumes the application has to support one HL7 version 3 model only. There are drawbacks to locking down an application to a specific SIM (a.k.a. R-MIM). The use-case whereby one needs to support multiple version 3 SIMs is covered in these discussion pages: Schema based code generation and MIF based code generation.
Although it is tempting to use XML techniques to support the creation, validation and parsing of CDA documents this paper shows that this is associated with a high risk of non conformant CDA instances. A model driven class code generator should be used if one wants to ensure compliance with the CDA standard as well as the appropriate implementation guide and associated templates.
Introduction
The HL7 e-Document standard (Clinical Document Architecture or CDA) is part of the HL7 version 3 standard. The current release of that standard (Release 2) was published in 2005 . CDA documents are used in a large number of projects, quite often in combination with HL7 version 3 messages or services. This article covers the development of software applications that support the CDA standard. The primary audience consists of application architects and software developers.
The implementation of the CDA standard and the validation of CDA-conform XML instances is based on two types of specifications:
- The CDA class model, a refinement of the HL7 Reference Information Model (RIM). The class model is expressed in MIF (Model Interchange Format ), the meta model format used by HL7 for all version 3 artefacts, or in derivations thereof such as UML or XML Schema. The CDA class model references Hl7 version 3 data types and coding systems.
- Context-specific constraints (Templates) of the generic CDA model, as defined in an DA implementationguide for specific document type and one specific context (e.g. country or project). Templates could express constraints on the class model itself, the use of data types, the values defined by coding systems, or they could be expressions of business rules. An example of the latter category is a template which defines that documents of the type “Natal report” SHALL be created within 7 days after the birth of the child.
At this point in time Templates are mostly defined as part of a CDA implementation guide in a textual form; these can be transformed into software processable specifications such OCL or Schematron . An increasing number of implementation guides are made available with Schematron-based versions of the templates.
The management aspect of templates is a major issue: a single CDA implementation guide may define hundreds of templates – which are quite often defined in terms of templates defined in other (more generic) CDA implementation guides.
MIF en XML schema
HL7 HL7 levert een MIF-bestand die correspondeert met het CDA-klassenmodel. De CDA MIF kan worden omgezet in minder “rijke” uitdrukkingsvormen zoals UML en XML Schema . Bij deze omzettingen gaan delen van de specificatie verloren.
CDA maakt gebruik van een XML syntax en de standaard vereist dat CDA documenten valideren tegen het gepubliceerde CDA XML Schema. Veel CDA-implementaties gaan dan ook uit van het gepubliceerde XML schema. Hoewel dit vanwege de brede beschikbaarheid van XML tools een aantrekkelijke optie is levert het tevens een aantal problemen op. Zo is de XML Schema-taal bij lange na niet “rijk” genoeg om alle eisen die in het CDA-klassenmodel aanwezig zijn tot uitdrukking te brengen. Dit houdt in dat een XML instantiatie die valideert tegen het XML Schema niet per se een valide CDA-document is, want dat vereist dat men valideert ten opzichte van het CDA-klassenmodel zoals gedefinieerd in de CDA-standaard.
Een voorbeeld van de beperking van de XML Schema-taal zijn conditionele attributen van een element: een CD data type dient of de attributen {@code en @codeSystem}, of het attribuut @nullFlavor te bevatten, een eis die simpelweg niet met XML Schema te testen is met als gevolg dat een CDA-document waarin alleen @code voorkomt eveneens als geldig document wordt gezien. Andere voorbeelden: lege XML-elementen (<element/>) zijn in HL7 versie 3 instantiaties nooit toegestaan, maar dit kan met behulp van XML Schema niet worden afgedwongen; de validatie van codes zoals gebruikt in codersingssystemen is problematisch.Sommige van de genoemde beperkingen zijn wel via XML Schema zijn af te dwingen maar zouden leiden tot een onwerkbaar groot en complex schema met heel veel gevalsonderscheidingen. Nictiz, de organisatie die de specificaties levert voor de Nederlandse zorginfrastructuur, levert vanwege de onvolledige validatiemogelijkheid van XML Schema een extra set Schematron files uit om data typen en coderingsystemen te valideren.
Om alle aspecten van het CDA-klassenmodel te ondersteunen zou het uitgangspunt voor softwareontwikkeling de CDA MIF moeten zijn. MIF heeft echter als nadeel dat het een HL7-specifiek formaat is dat slechts door een beperkt aantal tools ondersteund wordt.
Software development approaches
De huidige CDA software-implementaties zijn te verdelen in twee groepen: een groep die zich uitsluitend baseert op XML-technieken en tools, en een andere groep die zich baseert op het CDA-klassenmodel (MIF of UML).
CDA implementation using XML techniques
De basis voor het toepassen van XML-technieken bij de implementatie is gelegen in het feit dat CDA gebruik maakt van XML: de CDA-documenten zijn XML documenten, er is een XML Schema voor CDA, en templates worden veelal gepubliceerd in de vorm van Schematron-bestanden. Schematron behoort tot de standaard XML technieken; een Schematron compiler heeft alleen een XSLT engine nodig om te kunnen werken.
Naast bekende technieken als Xpath, DOM/SAX wordt er veelal gebruik gemaakt van klassegeneratoren : bijvoorbeeld JAXB, een tool die het CDA XML Schema omzet in Java-klassen.
Een aantal online CDA validatietools maakt gebruik van XML technieken (Schema en Schematron), o.a. NIST (http://xreg2.nist.gov/cda-validation/validation.html ), Alschuler Associates (http://www.alschulerassociates.com/validator/), en IHE (http://gazelle.ihe.net/EVSClient/cda/validator.seam?cid=9) . Deze tools kunnen gebruikt worden voor testdoeleinden. Het feit dat een document valide is volgens deze tools houdt niet automatisch in dat een document een valide CDA document is.
Model driven CDA implementation
De basis voor een modelgebaseerde implementatie is het CDA-klassenmodel zoals vastgelegd in MIF. De CDA MIF kan, vanwege het feit dat CDA documenten alleen bestaan uit een informatie model, zeer goed in een UML representatie worden omgezet.
De CDA MIF (of de UML versie daarvan) dient als uitgangspunt voor het genereren van klasse generatoren , die het MIF/UML formaat bijvoorbeeld omzetten in Java klassen. Op dit moment (Augustus 2010) zijn er twee vrij beschikbare ontwikkeltools waarvan men het gebruik zou moeten overwegen:
- MDHT (http://www.cdatools.org/), een CDA-specifieke klassengenerator. De tool maakt Java klassen aan op basis van enerzijds een UML representatie van het CDA model, en anderzijds OCL representaties van de templates. De tool bevat tevens een goed beheersysteem voor de veelheid aan template definities die gebruikt worden in CDA-implementatiehandleidingen. MDHT stelt het de gebruiker in staat een Template op een relatief eenvoudige wijze aan te maken in een tabel-achtige structuur. Templates kunnen als inperkingen op al eerder aangemaakte Templates worden gedefinieerd. De aangemaakte template definitie wordt vervolgs omgezet naar OCL statements.
- MARC-HI Everest (http://everest.marc-hi.ca/), een HL7 versie 3 (niet alleen CDA) klassengenerator. De tool maakt C# klassen aan op basis van de CDA MIF. De tool biedt op dit moment geen ondersteuning voor CDA templates; voorlopig zou men gebruik kunnen maken van de Schematron versies van de templates.
- Java SIG (http://aurora.regenstrief.org/javasig), een (helaas niet recent bijgewerkte) toolkit die op basis van de CDA MIF (uit 2005) Java klassen genereert. Deze toolkit is in tegenstelling tot de eerder genoemde toolkits al relatief lang beschikbaar en zij is in gebruik in meerdere implementaties, o.a. DRV Bund (Duitsland) en PCS (Oostenrijk). De tool biedt geen ondersteuning voor templates.
MDHT heeft tevens een online validatie tool (http://cdatools.org/validation/ ). Er bestaat tevens een MIF gebaseerde validatie tool voor het Eclipse platform (http://hl7book.net/index.php?title=Eclipse_Instance_Editor).
Persistence
De CDA standaard bevat een aantal eisen ten aanzien van de archivering van CDA documenten. Eén van de vereisten is dat als men een document opslaat, men in staat moet zijn het XML document zo op te leveren dat het gelijkluidend is aan het originele document. In relationele databases worden CDA documenten om die reden veelal als “blob” opgeslagen.
Indien men gebruik maar van een klassengenerator is het aan te raden daarnaast gebruik te maken van een ORM applicatie om de gestructureerde gegevens afkomstig uit het CDA document in de database op te slaan. Hierbij dient men de relatie met het document bij de daaruit afkomstige gegevens vast te leggen – het kan zijn dat het document op een later moment ongeldig wordt verklaard, in welk geval men tevens de daaruit afkomstige gegevens als dusdanig moet kunnen markeren. Aanbevelingen Het gebruik van de CDA XML schema leidt in de praktijk tot het aanmaken van CDA documenten die geen valide instantiaties van de CDA-standaard zijn. Indien men door omstandigheden gedwongen wordt uitsluitend gebruik te maken van XML-technieken, dan dient de implementatie extra aandacht te besteden aan extra validatiemodules voor de HL7 versie 3 data types en coderingssystemen. Omdat de XML schema taal niet de vereiste “rijkheid” bezit leiden vooral die gebieden tot een veelheid aan fouten in CDA documenten.
Een anonieme bron bij een van de aanbieders van een online CDA validatie tool bevestigt het bovenstaande: indien men nu zou beginnen aan de ontwikkeling van een dergelijke tool, dan zou deze niet gebaseerd worden op XML technieken. De huidige tool levert teveel false positives – documenten worden als geldige CDA documenten gevalideerd terwijl zij dat niet zijn. Het beheer van template definities in de vorm van een collectie schematron files is eveneens problematisch.
Voor een correcte ondersteuning van de CDA standaard dienen software applicaties gebruik te maken van het CDA-klassenmodel. Applicaties die uitsluitend gebruik maken van de CDA XML Schema kunnen geen garantie bieden dat de resulterende documenten ook werkelijk valide CDA-instantiaties zijn. Op dit moment biedt de MDHT tool voor Java het beste uitgangspunt voor het ontwikkelen van een CDA-klassenmodel gebaseerde applicatie. Deze toolkit levert tevens ondersteuning voor het beheer en testen van Templates.
Software Architecture
CP-CO-CS (using technology matrix terms) is probably the way to support this,
- with MIF based code genration for CO (e.g. using Dave Carlson's CDA tool) or schema based code generation if one can't use the MIF tool.
- And use a standard ORM tool for CP-CO.
