MDHT enables IHE PCC and HL7 CCDA Harmonization

One of the things I really like about MDHT is that it gives me programmatic access to the information model associated with templates.  The access is through the Eclipse Modeling Framework (EMF), and the EMF Core classes (eCore).

I've downloaded the MDHT All-In-One release, and started writing some Java code against the Java classes created by MDHT to represent the various templates.  I am using eCore's introspection capabilities to enable comparision between the IHE PCC Templates in final text, and the HL7 Consolidation Guide templates.

MDHT delivers the two different workspaces, one including CCD, IHE and HITSP templates, and another including the HL7 Consolidation guide templates.  I simply imported the projects from the former workspace into the latter one, so I could work with both.  If you go to do that yourself, you will note that you cannot copy some of the projects over (because of name clashes).  Don't worry about those, as they are the base CDA and HL7 datatypes and RIM models that are in shated in common.

What I wanted to do with this data was to be able to compare the differences between the IHE and CDA Consolidation templates.  The C-CDA comes with a template crosswalk (see the section on Template ID Changes in Appendix B in the guide) that enables this.  MDHT has a template comparison facility (which I'd have to use manually).  I had a challenge making that template comparison work, because I didn't have all the right projects open (I'm not sure why the MDHT comparison has that requirement). But I was eventually was able to get it to work with the help of Sean Muir.

That facility compares the templates based on their general structure.  However, I needed my comparison to be based on the deep structure as resolved through closure over all templates.  In other words, if template A and template B had the same constraint on an attribute, either directly or indirectly through another template, then I considered that to be no difference, regardless of the source of the constraint.  So, it was time to write some code.

The next challenge I had was configuring my project to have access to the eCore libraries that all my imports worked.  I did what just about everyone else does, looked at what worked elsewhere and copied it.  I created my the build path from what appeared in the org.openhealthtools.mdht.uml.cda.ihe project (where the IHE template classes were created), and I also included the various projects.  I probably have too much included, but will not both cleaning that up until later.  What I know is that I have what I need, and I'll figure out what I don't need later.

So now I get to go spelunking through the models, to figure out how the various relationships are recorded in eCore.  Once I have that figured out, I should be able to compute the intersection of common constraints between them.  That becomes the basis for version 2 of the IHE templates. There will be some constraint that IHE won't give up even though they've been dropped or weakened in C-CDA.  It will be very easy to identify those as well.

This should be fun.  It's a good thing I can automate this, because I have to have the basic framework for Volume 2 ready in just a couple of weeks.