Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

CCDA Generation using Everest API

0.00/5 (No votes)
6 May 2014 1  
This tip is a continuation of my series on CCDA XML Generation. It talks about how to quickly get up and running on generating CCDA documents.

Introduction

I recommend you go through these 2 short articles to get an introduction to the concepts and terminologies. They should also give you a good background to this post.

  1. How To Generate CCDA/CCD XML Documents for MU 2014
  2. Open Source APIs for CCDA Generation

Basically, we want a quick way to generate documents such as Transition of Care, Discharge Summary, etc. which need to be compliant with standards such as CCDA, QRDA, etc. which are part of the HL7 umbrella standard. MARC HI Everest API exposes .NET types that help us do this as explained in this tip. Typically, you would have an EMR/EHR system written in .NET where you would want to integrate this functionality as part of the MU certification compliance initiatives.

Pre-requisites

First, go to their website and download the installer. Install like you would install a regular app.

Assuming you are on Windows, you should see the program menu items such as this:

All Programs  -> Mohawk College -> Everest 

And an installation folder such as:

C:\Program Files (x86)\Mohawk College\Everest 

If you are planning to use Everest on long term projects and want to use many of its features, then it is worth spending time through various menu items. I recommend you click on "Getting Started" in the menu and start browsing through the content there. Please note that Everest is much more than just a HL7 document generator. Though the documentation is quite exhaustive, it is clearly not good enough for a beginner. Be aware, you may feel lost at times.

How to Use the API

To get started making CCDA documents programmatically, follow the steps as mentioned below.

First up, add references to the following DLLs in your .NET project:

MARC.Everest.Attributes
MARC.Everest.Formatters.XML.Datatypes.R1
MARC.Everest.Formatters.XML.ITS1
MARC.Everest.RMIM.UV.CDAr2  

You should be able to find them in the folder:

C:\Program Files (x86)\Mohawk College\Everest\lib\ 

Then add the relevant using statements like this:

using MARC.Everest.Attributes;
using MARC.Everest.DataTypes;
using MARC.Everest.DataTypes.Interfaces;
using MARC.Everest.Formatters.XML.Datatypes.R1;
using MARC.Everest.RMIM.UV.CDAr2.POCD_MT000040UV;
using MARC.Everest.RMIM.UV.CDAr2.Vocabulary;
using MARC.Everest.Xml;  

Now, we are ready to build the CCDA XML document.

Build CCDA

Now we will write code to build the CCDA XML. However, before that, we need to know a bit about the document itself.

I am assuming you have read the articles pointed out in the Introduction. A CCDA document is an XML document that has a set structure. We have to ensure that we make a document that adheres exactly to that structure, else the document will not pass the validations and hence wouldn't be compliant to the MU certification requirements.

The CCDA XML has nodes that can be broadly classified into 3 sections:

  1. The static header section - comprising nodes like realmCode, typeId, id, title, etc.
  2. The dynamic header section - comprising nodes like recordTarget, author, dataEnterer, custodian, etc.
  3. The body section - comprising of component nodes inside the node structuredBody.

First, we initialize the clinical document object with this:

ClinicalDocument ccda = new ClinicalDocument(); 

Then, we populate the static nodes at the beginning of the document like this:

//CONF 16791
ccda.RealmCode = new SET<CS<BindingRealm>>(new CS<BindingRealm>(BindingRealm.UnitedStatesOfAmerica));
//CONF 5252
ccda.TemplateId = new LIST<II>();
ccda.TemplateId.Add(new II(
    "2.16.840.1.113883.10.20.22.1.1"));
//The next templateId, code and title will differ depending on what type of document is being sent.
//Confirms to the document specific requirements
ccda.TemplateId.Add(new II("2.16.840.1.113883.10.20.22.1.2"));
//CONF 5363 
ccda.Id = new II("1.1.1.1.1.1.1.1.1", "Test CCDA");
//CONF 5253 "CCD document"
ccda.Code = new CE<string>(
    "34133-9",
    "2.16.840.1.113883.6.1",
    "LOINC",
    null,
    "Summarization of Episode Note",
    null);
//CONF 5254
ccda.Title = new ST("Primo Adult Health: Health Summary"); 

Not all fields are depicted above for brevity. But it is enough to understand how to locate the fields and how to populate them in the ClinicalDocument object. Similarly, we populate the other sections of the document.

Source Code

At this point, you can download the source code of the Proof Of Concept attached to the tip. This code shows how each and every field is populated in the document object. Just open the solution using VS 2010 and build it. If you face any problems building or generating XMLs, ping back.

The code is broken down into methods per section to make it readable. It also has an XML along with it that has all the static fields and their values. We load that into a dictionary object and use it from the memory each time we need the value of a static field.

Formatting and Generating the XML

Now to the critical bit, formatting and generating the XML that will pass the validation.

We initialize the formatter like this:

MARC.Everest.Formatters.XML.ITS1.Formatter fmtr = new MARC.Everest.Formatters.XML.ITS1.Formatter(); 

Then we build the XML using the XmlStateWriter class provided by the API:

XmlStateWriter xsw = new XmlStateWriter(
    XmlWriter.Create("D:\\EverestPoC.xml", new XmlWriterSettings() 
    { Indent = true }));
DateTime start = DateTime.Now;
var result = fmtr.Graph(xsw, ccda);
xsw.Flush(); 

That's it! We are done!

How to Validate?

Depending on which type of document you are trying to build for which type of provider, you may use one of the validators at NIST's website.

Disclaimer

Please note the following before you use the code or the instructions mentioned above:

  • The conformance to the certification requirement is as claimed by the API. I have verified the generated XML for my specific case using the NIST validator mentioned above [See the message validator page and Transitions Of Care Ambulatory Summary - MU2 170.314(b)(2) option].
  • The source code is just a proof of concept. It is not a working solution to an existing EMR/EHR system that you may have. You will have to populate all mandatory fields depending on the specific document that you are trying to create. Most of the fields may come from patient specific data from your transactions DB.
  • Again the source code is just a proof of concept. It may need to be optimized at various places for better performance.
  • This tip doesn't intend to be a tutorial on CCDA or HL7 itself. However, there are links to good tutorials in my blogs mentioned in the Introduction section in this tip.

History

  • 3rd May 2014: v 1.0

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here