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.