There are lots of places where FHIR shows underlying problems in it’s conception.
One of the areas is in how to handle database transactions. It’s a big topic of discussion within the FHIR team of how to handle this. I tried to think of a few constructive ways to solve the problem – maybe flattening out resources and allowing composite updates to be made in a single envelope.
Nope.
Didn’t smell right.
Real world RESTful interfaces don’t have this problem. Real world RESTful interfaces closely mirror the underlying data model of the application they are exposing and so decisions about how transactions are implemented is something which is very specific to the application.
You don’t see 37Signals explaining how their RESTful API handles database transactions because they have grouped the data in their API calls that makes sense for transactions in their application. This simply isn’t a problem that you have to think when you use real world RESTful APIs.
The problem shows up because FHIR is trying to do something which is a flawed idea to begin with. No one has ever tried to make a general purpose vertical RESTful API which covers as wide a range of disparate data as FHIR.
Why?
Because it’s a bad idea!
What bites FHIR in the butt is the whole principle of leaky abstraction. FHIR has negative value because it confuses the integrator with as to the nature of how the underlying application actually works.
Look at the patient resource:
http://www.hl7.org/implement/standards/fhir/patient.htm
and imagine putting this on top of real EMR system. Some EMRs are really flexible – they have the concept of a person table. Others represent a patient using a flat record with say HomePhone, BusinessPhone and OtherPhone implemented as columns in a single table.
How the application stores data inevitably leaks through into it’s interface. Having a generalized interface like FHIR makes each integration harder work. It will take more time per interface because as an integrator you have to figure out the underlying limitations of each system. This is same problem as Version 2.0 HL7 – HL7 interfaces – HL7 interfaces are invariably a thin wrapper around the underlying data-structure of the application.
Why? Because there is no other way.
This is what makes HL7 integration hard. It’s easy enough to consume HL7 data. But it’s hard work figuring out what parts of the HL7 standard that a vendor has implemented and what data fields to populate because invariably you have to figure out the right ones to populate to get the data in the right spot to display in the right part of the GUI that the user needs in their work flow.
A native RESTful API that is fits like a glove on to a real application is going to be a lot easier to use than HL7, and a lot less costly to integrate with than FHIR.
Welcome to the real world. Deal with it. 🙂
