CDA API FOR JAVA
Description and Guided Tour
Robert Worden
[email protected]
Table of Contents
1.
Overview
2
2.
A Flavour of the Java Code
2.1 Code to Read a CDA Document
2.2 Code to Write a CDA Document
3
3
4
3.
Exploring the JavaDoc Documentation
5
4.
Running the Demonstration Programs
9
5.
Developing Applications to Use the CDA API
11
6.
Green CDA, and Other Serialisations of CDA
13
7.
Extending And Modifying the CDA API
15
8.
Other Features of the Java CDA API
8.1 Using Eclipse EMF Features with the CDA API
8.2 Using Open Mapping Tool Features with the CDA API
19
19
19
9.
Components and Reuse of the CDA API
20
1.
OVERVIEW
The CDA API for Java is a set of tools and Java code for reading and writing standard CDA documents, using a
simple Java API. Its features are:

On reading a CDA document, the CDA is converted to a linked set of Java objects with meaningful
class names (Patient, Author, Address, and so on), with getter methods to read fields from the CDA.

To write CDA documents, the same Java objects are created with factory and setter methods, and then
serialised as a standard CDA.

The Java code is model-based, being derived from a UML class model of CDA.

The API is simpler than a RIM-based CDA API, containing the same simplifications as a Green CDA;
so developers are shielded from the technical complexities of CDA.

API code is available for several CDAs in the ITK, including the Non-Coded Document and the
Personal Health Monitoring Record (PHMR)

API code is tool-generated, using the Eclipse Modelling Facility (EMF) and other Open Source
mapping and transformation tools

The API can be extended or modified, or created for other CDA profiles, without hand coding using the
Open Source tools.
Pending resolution of HL7 intellectual property issues, the CDA API for Java is not Open Source, but is freely
available to members of HL7. You can download the CDA API software pack from the members’ area of the
HL7 UK website, or you can obtain an evaluation copy of the software from Open Mapping Software Ltd, for a
nominal fee.
This document can be read on its own as a description of the CDA API, or can be read alongside the CDA API
pack as a guided tour.
The API materials in the pack are sufficient to build and run applications which read and write the CDA
NonCodedDocument (profile POCD_RM010011GB02). To use the API for other CDA profiles, you may either
extend the API yourself, using open source tools from www.Eclipse.com and www.OpenMapSW.com, or
contact [email protected] to find out what else is available.
The API has already been used on one Information Sharing Challenge Fund (ISCF) project, and we hope it will
find wider use across NHS, as a low-cost way of interfacing to CDA documents while avoiding the technical
complexities of CDA. We hope there will be a community of developers involved in both applying and
extending the API, using the open source tools to do so, and sharing their results.
[Type text]
2.
A FLAVOUR OF THE JAVA CODE
The Java API can be used to read or write CDAs, using straightforward calls to the API methods. To get a
flavour of what this Java code looks like, you can inspect the source code of the demonstration programs, in the
following Java classes:


Code for reading a CDA, in class cda_api.demo.Reader_Demo
Code for writing a CDA, in class cda_api.demo.Writer_Demo
This code is zipped in the file cda_api.jar, in the ‘runtime’ folder of the CDA API pack. Extracts of these Java
classes follow.
2.1
Code to Read a CDA Document
A short section of the code used in Reader_Demo to read a CDA is:
// make a 'ClinicalDocument' object from the CDA XML root element, and find one of its properties
ClinicalDocument clinDoc = reader.getClinicalDocument(cdaRoot);
String creationTime = clinDoc.getCreationTime();
// Some attributes of the patient
Patient patient = clinDoc.getPatient();
String gender = patient.getGender().getDisplayName();
Address addr = patient.getAddress().get(0);
String[] addressLine = CDA_Util.getOrderedAddressLines(addr);
// an attribute of the (first) author
Author author = clinDoc.getAuthor().get(0);
String orgId = author.getOrganisation().getExtension();
Some features of this code:
1. An instance of the class ClinicalDocument describes the whole CDA instance which has been read in,
and is the starting point for navigating the Java class model to retrieve or modify the document
properties
2. The object ‘reader’ is an instance of the supplied class CDA_Reader, which converts the incoming
XML to the ClinicalDocument object representing the CDA.
3. Properties of the CDA, such as its creation time, are found by getter methods in the API such as
getCreationTime()
4. Constituent objects of the CDA are represented by Java classes such as Patient, and their instances are
retrieved from the top ClinicalDocument object by obviously-named getter methods like getPatient()
5. The constituent objects of Patient are represented by classes such as Gender and Address, with
obvious getter methods, which have been automatically generated by Eclipse EMF
6. There is a utility class CDA_Util, which builds on the generated getter and setter methods to provide
convenience methods; one such method is used here to retrieve address lines in order.
The CDA Java classes such as Patient are grouped into packages, according to the CDA template they are
derived from. The imports at the head of the Reader_Demo class show a few of the packages:
import
import
import
import
com.openMap1.cda.nonCodedCDADocument.ClinicalDocument;
com.openMap1.cda.patientUniversal.Patient;
com.openMap1.cda.datatypes.Address;
com.openMap1.cda.authorPersonUniversal.Author;
Package names like ‘authorPersonUniversal’ are derived from DHID templates – in this case
‘COCD_TP145200GB01#AssignedAuthor’.
[Type text]
This package structure enables API code for any template to be reused without change, for all the different CDA
document profiles in which the template is used.
2.2
Code to Write a CDA Document
This code is taken from the class Writer_Demo, in package cda_api.demo.
Patient patient = PatientUniversalFactory.eINSTANCE.createPatient();
patient.setBirthDate("19490101");
patient.getId().add(CDA_Util.makeId(null,CDA_Util.NHS_NUMBER_ROOT, "22334455"));
patient.setGender(CDA_Util.makeGender("1", "Male"));
patient.getName().add(CDA_Util.makePersonName("Mr", "Fred", "Gilbert"));
String[] streetLines = {"2 Bishops place","Surbiton","Surrey"};
Address address = CDA_Util.makeAddress(streetLines, "SU4 5PQ");
patient.getAddress().add(address);
Points to note about the code:
1. The same classes ClinicalDocument, Address, Patient and so on are used for creating a CDA
document, as are used for reading it.
2. Each package contains a factory class (here, PatientUniversalFactory) with ‘create’ methods to make
instances of every class in the package.
3. The API classes such as Address all have generated setter methods, either to set their properties, or to
attach constituent objects of their contained classes.
The class CDA_Util has a number of convenience methods which package up the EMF-generated creation and
setter methods, to make commonly used objects such as ids with their properties in a single call.
Once the complete ClinicalDocument object has been assembled by these API calls, an instance of the class
CDA_Writer is used to serialise it into the standard CDA XML form:
Element cdaRoot = writer.clinicalDocumentElement(cda);
In this way, the Writer_Demo code creates a complete CDA, which passes the ITK CDA Instance Checker
tests with no errors.
The creation and setter methods do not need to be called separately to create every element, or set every XML
attribute, in the final CDA document. For instance, for the ‘Patient’ component of the CDA header, you do not
need explicitly to create both <RecordTarget> and nested <PatientRole> elements, with all their fixed attribute
values. The whole set of nested elements and attributes:
<recordTarget typeCode="RCT" contextControlCode="OP">
<npfitlc:contentId root="2.16.840.1.113883.2.1.3.2.4.18.16" extension="COCD_TP145201GB01#PatientRole"/>
<patientRole classCode="PAT">
<templateId extension="COCD_TP145201GB01#PatientRole" root="2.16.840.1.113883.2.1.3.2.4.18.2"/>
is made automatically by serialising one Patient object of the API. Therefore the CDA API is a very
economical method, in terms of required code, to create standard CDA documents. Most of the work of creating
the fixed structures of CDA documents is done for you, and is done correctly.
[Type text]
3.
EXPLORING THE JAVADOC DOCUMENTATION
The previous section has given a flavour of how the API classes and methods work together, to create or read a
standard CDA document. To know in detail what classes and methods are available in the API, you need
detailed documentation accessible from your development environment. This is supplied with the CDA API as
JavaDoc. It is worth opening and exploring the JavaDoc while reading this section. One way to do this is to
unzip the file cda_api.jar in the ‘runtime’ folder of the demonstration pack, and explore the resulting ‘doc’
folder with a browser.
There is a fairly long list of packages in the CDA API:
In what follows, package names (in italics) are given in terms of the innermost one or two package names,
dropping ‘com.openMap1.cda’ from the name. The package cda_api.demo is not part of the CDA API itself,
but contains the demonstration programs which use the API. The package cda_api.nongen contains four helper
classes which are described below.
The other packages all come in threes – for instance, ‘authorPersonUniversal’ , ‘authorPersonUniversal.impl’,
and ‘authorPersonUniversal.util’. There are three packages for every CDA template included in the API; three
packages for the top CDA profile (in this case, nonCodedCDADocument with its impl and util packages) and
three data type packages (datatypes, with its impl and util packages seen above).
The packages come in groups of three because the CDA API code is generated using Eclipse EMF, which
always generates packages in threes. The first package contains Java interfaces, with names like
ClinicalDocument, Author, Patient and so on; the second ‘impl’ package contains classes which implement
those interfaces (which you do not need to refer to directly); and the third ‘util’ package contains two utility
classes, which you can ignore for most purposes.
In practice, you can navigate around the interfaces/classes, regardless of which package they are in. First go to
the top package, nonCodedCDADocument, for this CDA profile:
[Type text]
Apart from the Factory, Package, and Literals interfaces, this package contains two interfaces representing
parts of the CDA (here called ‘model objects’): ClinicalDocument and NonXMLBody. Go to the top
ClinicalDocument interface, and scroll to its method summary:
Here are the getter methods that allow you to navigate from the top ClinicalDocument object to its component
objects such as Author, Encounter, and so on. (Some setter methods, which allow you to add components to a
ClinicalDocument object, are further down the list). Following the link to the Author interface, you will see:
[Type text]
This JavaDoc defines how the Author object is related to a full CDA document:




It gives the XPath in the CDA XML (ClinicalDocument/author) at which this object occurs
It gives a link (DMS) to the full documentation of the author node, in the DHID Domain Message
Specification.
It gives the template id
It defines all the fixed values which will be created in a CDA you write with the API, or will be required
in any CDA you read with the API.
Following the DMS link takes you to the Domain Message Specification (DMS) documentation for Author:
From here, you can for instance jump onwards to detailed documentation of the data types.
(Because of potential copyright restrictions, the DMS documentation folders are not contained in the CPA API
Javadoc as you download it; to make the DMS links work, you need to copy two folders ‘Domains’ and
‘Datatypes’ from the DHID DMS into the ‘doc’ folder of the JavaDoc).
If you go to the Factory interface of any template package, you find the factory methods to create objects in the
package:
[Type text]
There follows the overview of the ‘nongen’ package which contains useful helper classes – which were used in
the sample code in section 2 above:
You can drill down to inspect the methods provided by these classes.
Therefore the JavaDoc is a complete guide to the interfaces and methods you will need when coding with the
CDA API.
If you wish to extend the CDA API – for instance to handle other CDA templates – the instructions for doing so
(using the Open Mapping tools and Eclipse EMF) are contained in their Eclipse Help files. This process is
described in outline below.
[Type text]
4.
RUNNING THE DEMONSTRATION PROGRAMS
There are three demonstration programs provided in the pack:
To run these demonstration programs under Windows:
1. Unzip the demonstration pack to make a folder ‘CDA_API_Pack’.
2. Make a copy of this folder at the root of the C: drive.
3. In the folder CDA_API_Pack/Runtime, double-click the command file reader.bat to run the CDA
reader demonstration.
4. Look in the CDA_API_Pack/Results sub-folder (which was initially empty) to see the results.
5. Double-click the command file writer.bat to run the CDA writer demonstration, and look in the results
folder
6. Double-click the command file translater.bat to run the CDA translater demonstration
When you run these demonstration programs, nothing much shows except a new command prompt; you need to
go to the ‘results’ sub-folder to see the results files (XML and text).
The writer demonstration creates a CDA which is complete enough to pass the NHS CDA Instance checker:
To run the demonstrations from any other location, you will need to:
1. Edit the properties file cda_api.properties (in the ‘Runtime’ folder) to alter the ‘driverFolder’ property
to point to the correct location.
2. Edit the files reader.bat, writer.bat and translater.bat (in the ‘Runtime’ folder) so that the one argument
of the Java main program points to the correct location.
There follows a description of the runtime requirements of the CDA API.
[Type text]
The file cda_api.jar (in the folder CDA_API/Runtime) contains the source code, compiled code, and JavaDoc
of the CDA API. That file on its own is sufficient to pull into some Java development environment such as
Eclipse, and start developing applications for the CDA API.
To run applications of the CDA API, other resources are needed as well:



Four other .jar files – three from Eclipse, and one from the Open Mapping tools
A small number of driver files, generated by the Open Mapping tools, in a defined folder structure
A Properties file which defines where to find the driver files.
The required .jar files are:





cda_api.jar (the CDA API)
openMapperLib.jar (Open source mapping and transformation tools)
org.eclipse.emf.common_2.3.2.v200802051830.jar (or later version)
org.eclipse.emf.ecore.xmi_2.3.2.v200802051830.jar (or later version)
org.eclipse.emf.ecore_2.3.2.v200802051830.jar (or later version)
The folder of driver files must have the following sub-folders:



ClassModel: containing an EMF Ecore representation of the Java API class model
MappingSets: containing mapping (.mapper) files for each supported serialisation of the CDA
(typically at least the standard CDA serialisation)
Translators: containing writer driver (.wproc) files for each serialisation of the CDA (typically at least
the standard CDA serialisation)
These driver files are created by the Open Mapping tools.
The properties file must define the following properties:




driverFolder: absolute path to the folder holding all driver files; e.g 'C:/CDA_API_Pack/Drivers/'
classModel: path within the driver folder to the EMF ecore class model; e.g.
'ClassModel/POCD_RM010011GB02_simple.ecore'
serialisations: names for different serialisations of the class model, separated by ';' e.g.
'CDA;GreenCDA'
a property for each serialisation name: the location in the driver folder of the .mapper file, e.g. the
property 'CDA' has value 'MappingSets/NonCodedCDA_full.mapper'
Having run the demonstration programs, you can edit the source code of the classes Reader_Demo,
Writer_Demo, or Translater_Demo to alter how they behave, compile and recreate the jar file cda_api.jar,
and re-run them.
[Type text]
5.
DEVELOPING APPLICATIONS TO USE THE CDA API
The main use of the CDA API is to enable healthcare applications to read and write full standard CDA. This
could be done by following and extending the demonstration programs, whose source code is provided in the
pack. Here we briefly describe the steps in developing any application to read or write CDA.
The file cda_api.jar contains the source code, the compiled code and the JavaDoc of the CDA API for Java. To
develop applications using the API, you will import this file into some Java development environment. While
you will not need the source code supporting the API, you will need the compiled API code to support the code
you write which makes calls to the API – and you will use the JavaDoc to guide you when writing this code.
For instance, in the Eclipse Java development environment, you declare the file cda_api.jar as one of the
‘referenced libraries’ for a project. Then, when coding in that project, you will be able to import and use all the
classes of the CDA API. The JavaDoc for the CDA API is visible when coding the application:
This fragment of code illustrates using the API to navigate down from the top ClinicalDocument object,
through the Patient and Id objects, to find an NHS number, and viewing the JavaDoc by hovering over code.
Similar facilities are available in other Java development environments.
The design pattern for developing a CDA reader application with the API is:
 Make an instance of the class CDA_Reader, using the appropriate driver files for CDA in the
demonstration pack (as defined by the properties file)
 Use that instance to convert the root element of a CDA XML document to an instance of the top
ClinicalDocument class of the API, or instances of other contained classes such as Patient and
Author.
 Use getter methods such as getPatient(), getName() and so on to navigate to other classes Patient,
Name and so on, and retrieve the attributes you need from the CDA.
The design pattern for developing a CDA writer application with the API is:
 Make an instance of the class CDA_Writer, using the appropriate driver files for CDA in the
demonstration pack (as defined by the properties file)
 Use the supplied factory methods to make instances of the API classes, such as ClinicalDocument,
Author and so on.
[Type text]


Use setter methods and utility methods to set their properties and link them together (note that for
associations with variable cardinality, there are not separate getter and setter methods; to add an author
to a document you use the getter method and ‘add’, as in ‘doc.getAuthors().add(author)’ )
Use the instance of CDA_Writer to serialise the ClinicalDocument instance as CDA XML.
These design patterns are illustrated in the classes Reader_Demo and Writer_Demo which run the
demonstrations. They can be combined in an application which reads a CDA, modifies it, and then writes it out
in the same or a different serialisation.
[Type text]
6.
GREEN CDA, AND OTHER SERIALISATIONS OF CDA
The CDA API properties file can define one or more XML serialisations of the CDA Java class model. One of
these is the full standard CDA serialisation, which is used to send and receive CDAs over the wire (for
interoperability, and for ITK accreditation), and which featured in the demonstration programs. That is the most
common application of the CDA API.
The API can also be used to read and write CDAs from other XML serialisations, provided the appropriate
driver files are present in the drivers folder (and are referenced in the properties file). Driver files are created by
the Open Mapping tools.
Another serialisation of the Java class model, which is a much simpler XML than the full CDA Serialisation, is
Green CDA. Green CDA is a technique for using a simplified XML to implement CDA interfaces; any
application can be interfaced to Green CDA, and then use reliable supplied transforms to transform between
Green CDA and full standard CDA. This is a much easier job than interfacing an application directly to full
CDA, because Green CDA is much simpler XML than full CDA.
There is a close relationship between the CDA API for Java and Green CDA. Both of them offer a simple way
to interface systems to full CDA, and they both do this by reducing the huge range of leaf nodes which are
available in full CDA. For both Green CDA and the Java CDA API, design decisions have been taken, to
populate or read only certain leaf nodes, out of the huge range of leaf nodes made available by the HL7 data
types. For instance, the CE data type, used for some codes in CDA, has many attributes (nullFlavor,
updateMode, code, codeSystem, codeSystemName, codeSystemVersion, displayName, value) and child
elements, most of which are rarely used. Green CDA and the Java CDA API do not make all these attributes and
child nodes available, but only make one or two nodes available in specific contexts. This greatly simplifies the
job of building interfaces, while introducing restrictions where they are expected to be appropriate.
In practice, simplifications and restrictions of full CDA - such as those which are embodied in Green CDA and
the CDA API - are necessary to achieve interoperability. If the community were not able to agree such
restrictions, different implementers would implement different subsets of the huge set of available CDA nodes,
and where those implementations did not overlap, they would not be able to exchange information. There would
be no point in one implementation writing certain CDA nodes, if no other implementation could read them.
While it might be possible to develop a Green CDA by hand (developing green => full CDA transforms by
hand) in practice it is not economical to do so, because the transforms are complex and hard to maintain.
Similarly, while it would be possible to develop a Java CDA API using hand-coded Java, it is not necessary to
do so, because the job can be done automatically and reliably by tools. In practice, the same Open Mapping
tools can be used to develop a CDA API for Java, and a Green CDA, at the same time. Then the Green CDA
and the CDA API will both embody exactly the same restrictions and simplifications of the full CDA.
The Open Mapping tools allow you to navigate the tree structure of the full CDA XML, choose which leaf
nodes are allowed to be populated, and give them business names. Similarly you can collapse or rename the
internal nodes of the tree, reducing it to a smaller and simpler tree structure which is the green CDA XML
structure. Then the tools automatically generate transforms between the Green CDA and full CDA. The tools
will also automatically generate the Java code which supports the Java API. This means there is a 1:1
equivalence between the Java API and the Green CDA, along the following lines:
1. Every internal node of the simplified tree structure corresponds to a class in the Java API (and an
association to that class from a parent class), with a factory method for the class, and setters and getters
for the association; and it is also an internal node in the Green CDA XML. There is one Java API class
for each unique internal node name of the tree.
2. Every leaf node of the simplified tree structure is a property of some Java class (with its own setter and
getter methods); and it is also an XML attribute of the Green CDA XML.
[Type text]
Thus the Green CDA XML is the simplest possible XML serialisation of the Java API class model, while full
CDA is a more complex serialisation of the same class model. The tools generate driver files supporting both
serialisations – so it is then possible for the Java API code to read in one serialisation of CDA, and then emit the
other serialisation, effecting a translation between the two (either Green => Full, or Full => Green). This is what
is shown in the ‘translater’ demonstration.
The Open Mapping Tools, which are used to develop the Java API, can also be used to develop mappings
between the Java API classes and any other XML serialisation (such as some XML that has previously been
used in a local context). Then the mapping tools generate the driver files to interface the CDA API to that other
serialisation.
[Type text]
7.
EXTENDING AND MODIFYING THE CDA API
We have described how the CDA API embodies certain restrictions and simplifications of the full CDA. These
restrictions are necessary both to simplify the job of building CDA interfaces, and to achieve interoperability.
However, sometimes the simplifications are not exactly what you want, and you would like to remove some
restriction from the CDA.
For instance, the CDA API allows each Author object to have a Name object, and the name can have Prefix,
Given, and Family name parts. The method summary for the interface Name is:
However, these are not all the name parts supported by CDA; for instance, CDA also allows a suffix in the
name. The API does not yet support this, and you might want to extend it to do so.
Because the Java code which supports the CDA API is automatically generated, it is quite straightforward to use
the generator tools to extend or modify the CDA API when necessary. This section illustrates how it is done.
(Detailed instructions for doing so are included in the Eclipse Help files of the tools listed below.)
The tools you need to do this are:


The Eclipse Modelling Framework (EMF), downloadable from http://www.eclipse.org/downloads/
The Open Mapping tools, downloadable from http://www.openmapsw.com/downloads/downloads.htm
The Open Mapping tools are a set of plugins which are installed on top of Eclipse. Assume you have
downloaded and installed these tools, and imported into the Eclipse workspace the mapper project ‘CDA_API’
which was used to create the CDA API, and will be used to extend it (this is in the folder ‘CDA_API’ of the
pack). Open the ‘MappingSets’ folder of that project, and then double-click to open the mapping set
‘NonCodedCDA.mapper’. First look at the right-hand ‘Mapped Class Model View’, which gives an expandable
tree view of the whole CDA structure. This is shown below, expanded down to the author’s name:
[Type text]
By navigating around this tree, and marking which nodes are to be retained in the API, renamed or collapsed,
you can completely control the form of the CDA API. Having found the ‘suffix’ node you wish to add to the
author name, you can inspect its attributes in another view:
Note that the attribute ‘textContent’ has been checked in the ‘include’ column, to denote that you wish to
include the text content of the ‘suffix’ element in the capabilities of the CDA API. This is the only change you
need to make to the CDA model, in order to include the suffix in the CDA API. All the other stages in the
process are automated generation steps:
1. You use a menu option ‘Mapper Editor > Simplify > make Simple Model and Mappings’ to
generate two of the driver files you will need for the Java API (the .mapper file and the .ecore class
model)
2. You run a translation test to generate the third driver file (the .wproc file) needed to write CDAs
3. You use the Eclipse EMF code generation facility, to generate the Java API code from the ecore class
model created in the first step
4. You then use the JavaDoc tool to generate documentation.
The result shows how the Suffix class, with the required setter and getter methods, has been added to the API.
In the documentation of the Name class/interface:
[Type text]
In the documentation of the Suffix class/interface:
A simple change to the CDA API like this can be made in a few minutes.
It is also useful to inspect the simplified class model ‘POCD_RM010011GB02_simple.ecore’, which is created
in the ‘ClassModel’ folder by the generation process, and is one of the runtime driver files. If you open this file
using the supplied ‘sample Ecore model editor’ you will see its structure of packages and classes:
[Type text]
This is the class model which is implemented in Java by the EMF-generated CDA API code. This view shows
the package and class structure of the Java API code mode concisely than the JavaDoc documentation. For
instance ,you can see the ‘one package per template’ structure here.
[Type text]
8.
OTHER FEATURES OF THE JAVA CDA API
Because the CDA API code is automatically generated by Eclipse EMF, there are several additional features
that can be used in conjunction with it. These are divided into Eclipse EMF features, and Open Mapping Tool
features.
8.1
Using Eclipse EMF Features with the CDA API
Eclipse EMF is a rich set of Open Source tools for model-based Java code development. ‘Model-based’ means
that the Java code is based on a UML class model, expressed in Eclipse ecore. This class model is the simplified
CDA class model generated in the Open Mapping tools, and used to generate the Java code.
The range of associated Eclipse EMF tooling has been described in books such as ‘EMF:Eclipse Modelling
Framework’ by Steinberg et al., in the Eclipse help files, and in the Eclipse.org mailing lists. There follows a
selective list of some of the things that can be done with EMF:




EMF Validation: The EMF framework has extensive facilities for validating instances of models, for
instance against OCL constraints. These could be used to validate CDA instances against template
constraints.
EMF Model Comparison: There are EMF comparison tools to compare instances of the same model
and report the differences.
EMF Editors: It is possible to automatically generate editors for instances of EMF models, which in
this case would be CDA Editors; these editors are probably more suitable for technical, rather than
clinical use.
EMF Model Query: EMF provides a framework to construct and execute queries against model
instances – in this case, to execute queries on CDA instances
This is just a small snapshot of the work going on in the large Eclipse EMF community.
8.2
Using Open Mapping Tool Features with the CDA API
Using the Open Mapping tools which were used to generate the CDA API, some other applications can be run
in conjunction with the CDA API:



Mapping and Transforming to other XML serialisations: The Open Mapping tools are designed to
create mappings between any XML serialisation and any Ecore class model. So for any existing XML
format (or relational database structure) they can be used to create mappings and transformations
between CDA and that data format. The Green CDA transforms are an example of this.
Mappings and Transforms to HL7 V2: The Open Mapping Tools include tools to create and test
transforms to HL7 Version 2.
Clinical Document Editor: An output of the tool that creates the CDA API is a simple, configurable
web-based editor for the CDA, using the same driver files as the CDA API. This editor can be
configured with extra validation features for clinical use, or in read-only configurations for patient
access, and so on.
The Open Mapping tools can also generate XSLT versions of all transforms, such as the Green-Full CDA
transforms. However, unlike the other features described in this paper, the XSLT facilities are licensed rather
than Open Source or free to HL7 members.
[Type text]
9.
COMPONENTS AND REUSE OF THE CDA API
We hope, if the CDA API for Java proves to be useful, that a community of developers will emerge to develop,
apply, and share CDA APIs for the CDA profiles used in the UK. This community could both apply the CDA
API – building applications which use it – and develop the API, using the tools to extend and maintain the API
itself.
Such a community would be a natural discussion forum for the many design decisions (decisions about which of
the many allowed nodes in the CDA definition are actually to be used, and how they are to be interpreted) which
need to be addressed if interoperability is to be achieved.
The template-based package structure of the API is intended to facilitate reuse of CDA API components. There
are three Java packages in the API for each distinct template in a CDA, all named after that template. So if CDA
APIs are developed independently for two separate templates, they can be combined for any CDA profile which
uses both templates, by importing the different packages. Where the APIs for different templates need to agree
is in the classes in the datatypes package, which need to be used consistently across all templates. For this
reason, it seems desirable to be able by default to confine all classes to their own template packages, except for
those classes and APIs which are so uncontroversial that they will be widely used. It is possible to have two
classes with the same name in different packages, although this might cause confusion if not used carefully.
To achieve reuse across different teams of developers, the main resources which need to be shared are not the
packages of generated Java source code, but the mapping projects which are used to generate the code. We
envisage that these project folders are the main resource to be kept and managed in a repository, capable of
forking different versions, and so on.
If you are interested in contributing to the Java CDA API, as well as using it, please express your interest to
[email protected].
[Type text]