A Bake Off

I've been working quite a bit on my ABBI Prototype lately.  It's nearly ready for demonstration.  At the same time I've been doing that, I've been looking at three different standards based formats for returning the results.

Right now, my preferred format is Atom, as I've specified it's use specifically for ABBI.  The nice thing about Atom is that it has a well defined separation of metadata and content.  An atom <entry> is mostly metadata.  The only thing that isn't appears inside the <content> element.  (The type and src attributes associated with the content element are also metadata about the content.).

Last night, I put together similar output using the IHE Mobile Access to Health Documents profile (I think I have the official name right now).  And this morning, I threw together some output using the newly defined /XdsEntry FHIR resource (It will be done in about 20 more minutes, and I've spent about 40 on it so far).

I don't like the MHD format.  Perhaps because it's JSON, but more likely because of the disconnect between metadata and content, and the fact that MHD right now doesn't have a way to get both.  The same is true of FHIR, but, I've already proposed the addition of an optional attachment element that could be used to contain the content.

One of the things that we've learned over the years in IHE is that there are use cases where people want the metadata AND the content in one network transaction, and other cases where they want the metadata in one transaction, and will get individual contents in subsequent transactions as needed.  Some of these use cases are being driven by regulatory requirements.  Servers for some folks need to be totally stateless and storage free so that they are doing nothing other than acting as a gateway for data.  That gets them out of certain regulatory or legal requirements for consent.  In other cases, they cannot afford to accept huge packets of data (e.g., because of device limitations), and so would like the transactions split up.  In other cases, they know they'll be grabbing everything, so why should they have to generate umpteen transactions to get what they want, when in fact, the server has all the data to begin with.

There's no easy solution to pick a single way that meets everyone's needs.

In any case, almost all of the infrastructure that I've put together for ABBI allows me to test out each of these content formats in a bake off.  At the end of it all, I expect, we'll all converge to one format.  I think I'd like for it to be an intermediate between what FHIR specifies, and what I already did for ABBI.  In fact, all I'm doing is just adding Atom fields to the specified FHIR output, so it's not really incompatible with FHIR in any way.

If I'm lucky, I should have my demonstration server working online by early next week, so you can compare the results for yourself.  I've already got Tomcat running in the cloud to test this out ("UR cloud iz my sandbox"), so it's just a matter of bundling up and deploying the WAR file once I've got it tested well enough for casual users.

As I think about it: If there can be only one, perhaps bake-off isn't the right phrase.  It's more like a sword fight.

ABBI's First Data Holder Connection to IHE XDS via OHT

I started my ABBI Prototype yesterday by refreshing my development environment.  The next step was to ensure that I could connect my application to a Web Service that would provide data I could start playing with to develop the service.  I spent several hours last night trying to get it to work and went to bed having not succeeded.  Today, I finally got it to work.

The architecture for my prototype is based on the IHE Documents for Mobile Health profile.  It will respond to RESTful queries by reformatting them into XDS/XCA queries to an Initiating Gateway, and return responses that reformat the ebXML gunge response into an Atom feed that is much more useful for developers.  So, my first step was to connect my application to the NIST XDS Test Facility on the intertubes.

I've used this in the past, but it's been a while.  Refamiliarization took a little bit of time.  When connecting to the NIST Test facility as an XD* Client, the first thing you need to create is a patient identifier.  It took me a bit to find this page where I could do that.  That page also points you to testing tools that allow you to perform queries on that identifier, submit test data, and a bunch of other goodies.  It's great that I don't have to create a full blown XCA Server just to test my prototype.

Having now created a patient, and given them a document, my next step was to ensure that I could create an application that would be able to do the same.  As I mentioned previously, I'm using the Open Health Tools IHE Profiles project to do that.  This is where I got stuck last night.  I'm apparently an odd-ball, in that I like to write POJO's to do the work, rather than adding a bunch of other stuff.  I suppose I could have used the Bridge to make life easy, but that requires I configure another service, and I'm always swapping Tomcat in and out depending on what I'm up to right now.  It's not like I have extra computers devoted to my build/deployment environment.  It's all running on my laptop.

The challenge I learned later has to do with the way that Axis2 works.  It needs to be configured with an XML file that you have to tell it where to find.  That doesn't come with the ihetools project of OHT.  You have to pull it from another project.  It also likes to be in charge of class loading.  This is in part because you need to be able to maintain several versions of a handler in memory at the same time to deal with different possible cases where messages can be handled in various ways, with multiple services running at the same time, et cetera, and so on.  So, rather than putting certain things in my classpath, like I'd expect (or in WEB-INF\lib), I had to do things differently.  Axis 2 is cool.  But it's also enterprise class software, and quite honestly, for a client application, is probably overkill.

Somewhere along the line, I decided to replace the Axis jar that shipped with OHT with the original jar files that come from the Apache Axis project.

It took me quite a while to figure out how to make things run, but eventually, I figured out the right command line switches, and everything worked.  Today, I was able to verify that I could connect to the NIST Test Registry and get metadata about my test patient's documents in a simple POJO with a main() method.  The next step was to make sure that my Web Application, which would be serving up the ABBI API could do the same.  It turns out that starting Tomcat with the same JVM switches solves the problem.  It's NOT the right way to do it, but it works.  I can dink with classpaths and server.xml files later.

My first test isn't connecting to the NIST Registry securely.  To do that, I need a certificate.  I think I have one from last year that still works, and I'll be getting a new one for the connectathon this year.  For now, I know what needs to happen, and how to secure that link.

My next steps are to figure out how I want to set up the prototype to show off what it can do.  Now that I know I can get to the data, generating queries from RESTful API and transforming results into atom are just a simple matter of writing code.

  -- Keith

---

If you are an OHT User, these notes might be helpful to you if you just want to write simple Java command line applications to access an XDS Registry.

1. Download the IHETools ZIP File from OHT
2. Unzip it and copy the resulting JARs to location1.
3. Rename  location1/org.apache.axis2_1.4.1.jar to location1/org.apache.axis2_1.4.1.bak
4. Grab Axis2 from Apache's web site (I used V1.4.1) and unzip it to location2.
5. Download axis2.xml from here and put it in location3.
6. Copy location2/repository/modules/addressing-1.41.mar to location1/addressing-1.41.jar
7. When you run your Java application, add these parameters:
1. -Djava.ext.dirs=location2/lib 
2. -Daxis2.repo=location2/repository
3. -Daxis2.xml=location3/axis2.xml
4. CLASSPATH=location1

These do several things:

1.  Makes Java happy about where to find and how to load certain Axis classes.

2.  Makes Axis Happy.

3.  Configures Axis to generate SOAP Headers.

4.  It makes it possible for your application to find the addressing module which is needed to generate those SOAP headers.