Cornelia's Weblog

my sporadically shared thoughts on, well, whatever is capturing my attention at the moment.

Posts Tagged ‘HL7’

IHE Connectathon – An Oustanding Event

I’m sitting at O’hare waiting for my flight home after a wonderful visit with some friends from my graduate school days at IU that was preceeded by a week of work at the IHE North American Connectathon. As I start writing, it’s in the forth quarter of the NFC championship game, right here in Chicago, and to mood isn’t that great. Go Bears?

I’d be lying if I said that I had been looking forward to this trip. We in the CTO Office had built an XDS Registry and Repository solution to bring to the Connectathon, and while I was very happy with the solution architecture (I’ll write a separate post on this shortly) and we learned a great deal constructing it, I wasn’t expecting the actual Chicago event to be that interesting or fun. I couldn’t have been more wrong.

The event is held in the lowest level of the Hyatt Regency Hotel that sits right on the lake and river in downtown Chicago. There is nothing fancy about the Connectathon layout, in fact, if you follow the link above to the Connectathon site you’ll see it exactly. There are three very long stretches of tables that seat perhaps 75 people on a side. Most companies participating in the event bring 1-2 solutions (EMC brought 2) with about 3 people supporting each solution. A solution has an assigned location along these tables onto which they set up their system. While we brought (shipped) a couple of racks, one primary and one redundant, and some vendors brought actual medical equipment, most just run their solutions on one or more laptops. Setup begins on Sunday, which is a time you can ensure that your system still checks out okay, can properly connect to the network, etc. and Monday at 10:30 the games begin.

The aim of the Connectathon is very simply to demonstrate the use of the IHE Technical Framework (TF) for IT Infrastructure in facilitating the connectivity between a variety of vendors in order to support operations in a healthcare setting. The IHE TF for IT is litterally hundreds of pages spread over a half dozen volumes plus another dozen addendums. They are almost exclusively specified via the application of multitude of standards such as SOAP, ebXML and HL7,plus a significant details specific to the healthcare market such as the definition of a domain for medical records, documents, patients, etc. I worked a bit with these standards more than a year ago, but then got very familiar with them over the last several months as we built out our registry and repository solution. After this development period and some pre-Connectathon testing I was already fairly impressed with the standards, they are certainly thorough, although also extraordinarily complex in places.

What happens when the “games begin” is that each vendor is assigned partners to whom they are to connect to within certain scheduled testing periods, and a list of specific tests that they must demonstrate and pass with that partnership configuration. For some tests the IHE provides a tool that dispatches those tests and for all tests the IHE provides a system into which test results are recorded by each of the vendors. As results are recorded they are graded by a team of a couple of dozen monitors or proctors who are also there to answer questions and help interpret the specs. As a registry and repository vendor we had partnerships that tied our registry with third party repositories, consumers (of data) and sources (of data), and similarly tied our repository with third party registries, consumers and sources. We didn’t know ahead of time who our partners would be. The services of a system are all offered (as specified by the IHE) as (I think exclusively HTTP) endpoints so when you connect to a partner you simply configure in their URIs and you should be good to go.

And here’s the thing – IT WORKS! This is my first reflection on the whole Connectathon event. With hundreds of pages of specifications,and probably thousands of developers interpreting them, for the most part, the systems could then interoperate. We had sources submitting documents and medical records, other sources applying lifecycle events such as versioning of existing documents, consumers querying for content, and other consumers retrieving DICOM images, etc. It was really, really cool. No one off solutions, no custom code to work with vendor A vs. vendor B. It actually all works the way it is supposed to.

My second reflection on the event is that it is a valuable event for the IHE organization because it does expose areas of vagury in the specifications when one vendor implements things one way and another does things another way. In some cases the verbiage in the spec leaves too much room for interpretation.

And third, what an extraordinary opportunity for us vendors. The five days we spend in that room connecting our systems to other vendors tests our solutions in a way that dozens or even hundreds of days of testing within in-house labs could never do.

In retrospect, I was totally blown away.

Finally, I’d be remiss if I didn’t mention how collaborative the spirit was in the room. Of the 101 vendors at the event, more than 70 of them had essentially competing registry and repository solutions, yet we really stretched to help each other as much as possible, finding and sometimes diagnosing bugs with those “competitors” and burning the midnight oil to resolve something. I’m sure this spirit is largely due to the fact that the vast majority of the folks in the room are technologists, and well, geeks have in common an enthusiasm for technology and a desire to make things work. The days were long, but very fun and rewarding.

Oh, and I’m pleased to report that the EMC solutions both passed all tests receiving a nod of approval from the IHE. This is our ticket into HIMSS so come see us there if you are interested.

Every business trip I go on I ask myself at the conclusion whether it was worth it. This time the answer is a resounding “YES!”

Oh, and GO Jets!! (hi Boss. :-) )

Open eHealth IPF – Getting the HL7 Tutorial Running (in version 1.7 of the IPF)

The Open eHealth Integration Platform is pretty darn cool. In addition to enhancements that serve the healthcare domain, it also extends Camel with a great number of features that are of general value, including a Groovy based DSL that supports the likes of closures (!!) and more. I’m liking it.I’ve been looking at the available tutorials and didn’t get too, too far in before I hit a snag – in the third tutorial on the page, the HL7 Processing tutorial. The solution is very, very simple, and is given at the very end of this post, though finding the solution took me on a very instructive tour through the platform and a bunch of embedded packages. Fortunately, I had the benefit of time (the boys went to my son’s homecoming game last night) and absorbed a lot on the scenic route. Come along…Following the tutorial instructions to the letter resulted in an error when I tried to run it (unit testing run either from within eclipse or by running mvn test at the command line):SEVERE: Caught exception while allowing TestExecutionListener [org.springframework.test.context.support.DependencyInjectionTestExecutionListener@3bfc47] to prepare test instance [org.openehealth.tutorial.SampleRouteTest@2f996f]java.lang.IllegalStateException: Failed to load ApplicationContextat org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:201)...[snip - a big stack trace with some cascading "Caused by:..." messages the last of which was the root cause]...Caused by: ca.uhn.hl7v2.HL7Exception: No map found for version 2.2. Only the following are available: [2.5, 2.3.1, 2.4, 2.6, 2.1, 2.5.1, 2.0D, 2.0, 2.3, 2.2]at ca.uhn.hl7v2.parser.Parser.getMessageStructureForEvent(Parser.java:352)...[snip - a bunch more stack trace]This error was getting thrown at bean instantiation time – the init method for the validationContext was failing. Of course, this error message is puzzling in two respects. First, most obviously, an error message that says “nothing available for x, only x, y and z are available” is rather contradictory. Second, when we look into the code for initialization of the validationContext we see that what we are doing is starting with a DefaultValidationContext and then we fill it in with the rules that are defined in the beans declared in the context.xml file. The DefaultValidationContext has a map, initially empty, from the HL7v2 versions (i.e. 2.1, 2.2, etc.) to the set of rules that apply to that version. Put that together with the error message above and we are easily mislead into thinking the system is complaining about some problem with the ruleMap in the DefaultValidationContext. Yes, mislead. This is NOT the map that is causing the problem.What happens at bean initialization time starts out exactly as I describe in the previous paragraph – the validationContext bean is instantiated and during initialization a DefaultValidationContext is created at the rules specified in the context.xml file are added. As the rules are added the forContext Groovy method is called, a RuleBuilder is instantiated and the forVersion method is called on it – that is, the rules are basically parsed (more on this in a moment). The rules in the defaultTypeRules are not a problem and are loaded without issue. The difference between these and myCustomRules, which are not loading, is that the custom rules we’ve defined are using the abstractSyntax method (those in the defaultTypeRules are specifying rules using different approaches).And here is the key…What happens when you define a rule using abstractSyntax is that the rule is validated against the abstractsyntax of the designated HL7 message version. That’s right, the IPF is doing a bunch of work here to make sure you’ve specified rules that are relevant against the version of HL7v2 that you are targeting. So, for example, if you tried to define a rule against an ADT_A25 message and you targeted it forVersion(’2.2′), you’re cool. If however you target it forVersion(’2.1′) then the rule itself won’t validate because version 2.1 only has ADT messages up through ADT_A24. And it even does validation into the message formats. This is a huge value add, it’s a point of model governance that I wasn’t necessarily expecting to have in IPF.So, back to the error message. The exception is thrown in ca.uhn.hl7v2.parser.Parser.getMessageStructureForEvent, the Parser does, indeed, contain a map from version numbers to messageStructures and the exception occurs because, indeed, there is no entry for version 2.2 (or any other version number for that matter). The question then is from where and when are they supposed to have been loaded. We don’t have to look too far, the Parser class includes a method called loadMessageStructures() and looking at the code in there we see:for (int i = 0; i < versions.length; i++) {   String resource = "ca/uhn/hl7v2/parser/eventmap/" + versions[i] + ".properties";   InputStream in = Parser.class.getClassLoader().getResourceAsStream(resource);   ...That is, for each version (the list is hardcoded in a class variable) load up the structure from a properties file with the right name. I knew then that this had to be a packaging issue, and, assuming the tutorial once worked as written, a result of some recent change. Digging through jars, this specifically had to do with HAPI libraries, and vaguely remembering seeing something about HAPI versions, here:

As of IPF 1.7-m3, the underlying HAPI library has been updated. The HL7 version-dependent classes have to be included separately.

was the solution.All that is to say that the only thing you need to do beyond what is described in the tutorial is add the following lines in the dependencies section of the pom.xml:<dependency>    <groupid>ca.uhn.hapi</groupid>    <artifactid>hapi-structures-v22</artifactid>    <version>0.6</version></dependency>