Tuesday, September 9, 2014

Healthcare Standards: Where is the XSD for CCD?

Stumbled upon this blog post while doing my research and I thought this should be advertised more.



Healthcare Standards: Where is the XSD for CCD?

Saturday, August 9, 2014

Adopting Agile: Faster Waterfall is not Agile

Adopting Agile: Faster Waterfall is not Agile: Most of the organizations have a myth that if they have shorter release cycles they are agile. Here is a nice blog by my friend Tabassum. Read on...

Wednesday, July 23, 2014

②ality – JavaScript and more: A JavaScript survival guide

②ality – JavaScript and more: A JavaScript survival guide: Are you a programmer who is considering learning JavaScript, but unsure whether it is worth the pain? Then this blog post is for you:

Thursday, May 22, 2014

JavaScript For Loops and its Cousins

What?! JavaScript doesn't have a for-each loop? You gotta be kidding me!

That was my reaction to my co-worker whose code I was peer-reviewing. I suggested him to use a for-each loop instead of a vanilla for. And he said - "I don't remember seeing a foreach loop in JavaScript?!"

JavaScript has some interesting variations to the for loops and I feel they are not really that popular. So in a bid to learn and understand them I wrote a post on CodeProject. I hope you find it helpful. 


Tuesday, May 6, 2014

CCDA Generation Using Everest API

As explained in the previous post in this series, I evaluated some of the APIs available in the market and found Everest to be the best suited among them if you are trying to be within the confines of .net and generate HL7 documents based on standards such as CCDA or QRDA.

Please read the article on Code Project which includes a small Proof Of Concept console app that generates CCDA documents.

It is important to note that even QRDA documents can be generated using the same approach and API. 

Friday, February 7, 2014

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. 

Thursday, January 16, 2014

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. 

Friday, January 10, 2014

How To Generate CCDA/CCD XML Documents for MU 2014

Most of the IT service providers in the healthcare space are busy taking steps towards getting Meaningful Use (MU 2014) certified. One of the key certification compliance criteria is the generation of various documents in XML format that adhere strictly to the CCDA or Consolidated Clinical Document Architecture. 

If you are new to these terminologies or the concepts then I recommend you go through these immensely helpful tutorials first:
  • The bible of all healthcare industry standards: HL7
  • Very nicely explained tutorials (videos) at: healthit.gov
  • Another one describing MU 2014 and CCDA (ppt) at: healthit.gov
So, you want to generate CCDA compliant document from your .net code.

But How? 

Well, there are 2 parts to the making of a CCDA document. 
  1. Prepare a .net type that mimics the XML. When serialized, this type will give us the XML that we want. Now, there are 3 ways to do this:
    • Hand-code the entire .net type(s). This requires in-depth analysis and understanding of the CCDA standard. Also considerable effort is required to develop and maintain the code when the standards change.
    • Download the schema XSDs as published by HL7 and then generate the .net type(s) out of it. This can be done by using tools like xsd.exe.
    • Use an API that already has such a .net object and exposes it to be used in the code. 
  2. Populate this .net type with the relevant data and serialize it to generate an XML out of it.
It is obvious that the API approach sounds the most cost effective and quick. In a later blog post we will evaluate a few APIs for this purpose.