Open Source APIs for CCDA Generation

This blog is a continuation of my previous blog post: How To Generate CCDA/CCD XML Docouments for MU 2014.

Here we evaluate five 3rd party open source APIs for CCDA generation that comply (as claimed by the APIs themselves) with MU 2014 standards. 

The objective is to assess the fitment and ease of integration with an existing EHR system so as to enable the latter to achieve 2014 EHR Certification for objectives such as:
170.314(b)(2) - Transitions of care - create and transmit transition of care/referral summaries
170.314(b)(1) - Transitions of care - receive, display and incorporate transition of care/referral summaries
170.314(e)(1) - View, download, and transmit to 3rd party

The comparison brings out the benefits/shortfalls of each of the products, and also makes recommendations. This blog also provides the ground work for further research that may need to be done keeping business priorities of the service provider.

So, Which API?

I sat down to do an evaluation in similar lines as what NHS Networks has done. I examined 5 products available in the market today and came up with these findings. 

Note: This evaluation is done keeping a .net based EHR system in mind. 

Model-Driven Health Tools (MDHT)

Technology: Java

Observations:

• The most popular and mature product available in the market today.
• Being Java based, doesn’t lend itself easily for use inside a .net library. 
• The generated sample XML available here fails validation by NIST. (MDHT, you listening???)

Everest Framework

Technology: .net

Observations:

• Extensive API. Can be used for various other things than just CCD generation. 
• The generated sample XML passes validation by NIST.
• There is a bit of a learning curve using the API because of lack of documentation.
• If the XML changes in future, then we need to rely on the API to update as well. This is a potential risk. A possible way to mitigate this is to maintain the source code of the API and extend it ourselves.
• It doesn’t lend itself to make CCD+ complaint XMLs.

HL7SDK

Technology: .net

Observations:

• Wasn’t easily usable for a quick evaluation. 
• Lack of documentation. User forum not very active.

CDAAPI

Technology: .net

Observations: 

• Emerging, not rich enough yet.
• Targeted towards NHS, UK.
• Makes use of components of the Everest Framework previously mentioned.

NHapi

Technology: .net
Observations:

• Confirms only to HL7 2.x.
• Old API, not updated actively.

Conclusion

As of the time of writing this blog, Everest seems to be best choice available. In a later blog post I will cover how to use Everest API to generate CCDA documents with code samples.