IFR vs IDE

I'm still playing catch up from being away from the office for two weeks, so today's post comes late and is a little disjoint.  Recently I had a very good experience with standards that I'd like to share.  The other day, an old computer I inherited suffered a terminal power supply failure, but I needed to get data off it's hard drive.  I bought an external drive enclosure and plugged my drive it into the Standard EIDE connector, checked the very nicely labeled jumper connections on the drive, and installed it into the enclosure.  The enclosure contains a very nice little gadget that bridged between the EIDE connector of the drive to a USB connection.  I plugged the drive into the USB connection and my home laptop recognized it nearly immediately.  I was able to use some diagnostic tools to fix the partition corruption and will later offload the files we wanted.

Now, a USB connection has 4 connectors, two for power and two for signal.  An EIDE connected is one of those big wide things that uses ribbon cables.  One transmits data in parallel and the other serially.  There's also a lot of details about interrupts, addressing, and other stuff on the EIDE connector that all gets serialized in USB communications.  Fortunately for me, theres a nice little simple-minded piece of hardware that goes from the EIDE connector to the USB connector.  It is very simple minded because these two standards (and the USB standard for media) are very well specified.  The most perplexing thing would have been the drive jumpers but those were also very well labeled and the instructions on the enclosure were very clear.  The way they operate is very different, but the functionality is the same, and bridging between the two nearly painless and VERY inexpensive.  This is interoperability at its best.

On the flip side, when we look at doing something that should seem very simple (connecting an interface), it can take quite a bit longer.  You'd think that all you need to do there is hook up a network cable, enter an internet address (and port), install a few certificates, and be done.  In fact, to achieve interoperability at the transport level, that is all you need to do and I can train someone to do repeatedly and well in less than an hour.  It's the other issues that take up all the time.  What is the format of the data? What has to be there? What should be there? Et cetera.  What are the policies that surround the use of the interface? And on and on.

What I realized from this experience is that SOAP vs REST is a pointless discussion SO LONG AS THE FUNCTIONALITY IS IDENTICAL where it matters (I remain unconvinced, but lets ignore that for now).

1.  Transport is easy, and if functionally two transports are the same, bridging between them is also easy (and cheap).  SOAP, REST, I really don't care.
2.  Deciding on content to exchange is hard.
3.  Crisp documentation is a big help.

That hard drive?  The hardest thing about making it work again was selecting the appropriate content format to exchange.  Fortunately for me, there were only 18 choices for the file system format, and I knew exactly which one would work for my situation, and for other things, the crisp documentation was really valuable.  For healthcare content exchanges, there might be 18 choices for the first item you need to decide, and another 18 choices remaining.  That's something like 18¹⁸ which is a pretty big number (~40 sextillion).  Those are the real choices that we need to reduce. 

Let's look at a very simple example from the recent IFR.  In order to communicate information between an EHR and Public Health Agencies, we are directed to use HL7 Version 2.3.1 or HL7 Version 2.5.1.  That's a start, even if a choice between two items.  Look further.  Which of the more than 100 HL7 V2 messages should be used?  The IFR doesn't say.  Could I use a BAR message to post a charge transaction in HL7 V2.5.1 to post information to public health?  That seems remarkably unlikely.  Given what I know, it should be ADT, ORU or MDM, and probably would be the second or first.  Having gotten that far, there are a number of different segments than have to be debated.  Where does the patient ID go?  PID-2, PID-3 or PID-4?  Well, according to the standard, it could be any of these...  Moving on, what must PV1 contain?  Do you even need a PV1?

So, lets stop worrying about whether everything should be SOAP or REST, and start worrying about these more challenging issues.  I'm concerned about what a system needs to do for public health surveillance. The current IFR has basically solved the EASY problem without any guidance for the hard one, and there is no crisp documentation identified that would help.

If you happen to have any insight or ideas about what is intended for public health reporting, or what SHOULD go there, I'd very much like to hear your thoughts and would also ask you to share them with others.