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. 

jQuery Datepicker Issue: Month and Year dropdowns in IE have to click twice

While working on a legacy code base recently, I was facing an issue with the jQuery Datepicker. 

For some reason our customer's code is stuck with jquery-ui-1.8.13.custom.min.js. And the browsers mandated for the application is IE 9 with compatibility view with IE8 standards.

Issue

Load up a page with a Datepicker in it, with both the year and month dropdowns enabled. Click on one of the year/month dropdown lists, it appears and disappears. Click it again and it appears correctly.

After being clueless for few minutes, I realized some event is getting triggered right after the click event that is causing the dropdown list to collapse. Then I noticed this:

Reason

So the problem is jQuery Datepicker is binding two methods to the onchange and onclick events of the select. When I dug more and found this:

Hack

So I figured a quick hack is to get rid of the onclick method body in the plugin code itself. I could do that in the minified file (do it only if you know what you are doing!). Then a co-worker showed an even lower impact change, which is to remove the setTimeout() function body portion only – which, if doesn't break any of your existing functionality, is better.

On searching more I found that this is an issue with that version of the plugin tracked here but I am not sure which version has the fix.

Solution

Ideally I should override the onclick method using something like this. I am yet to try it because I have the "we-will-refactor-later" syndrome. 

CodeProject