FHIR Connectathon – Conclusions

No coding in this post, just some opinions and thoughts (emphasis on opinions).

FHIR is very new. It’s only a proposal at this time and is far from being a standard. The Connectathons that have been held at recent HL7 meetings have primarily server to educate developers and implementers. The concept sounds like it could work but it is only when FHIR starts to be used for real clinical data communication that it can be proven. My first Connectathon highlighted some areas that need further consideration.

Firstly, it is now obvious that FHIR is not ‘plug and play’ and is unlikely to ever be so. There is a place to put the patient identifier and the address for example but it became apparent that these mean different things to different systems. The first step to any integration will remain as it has always been – discover what is being sent, what needs to be received and what the data means in a real world setting.

One of the goals of HL7 V3 was to remove the ambiguity of V2 messages by defining everything but everyone had different needs. That resulted in V3 becoming huge and complex and just too hard to use. FHIR wants to simplify the structure but allow for variations from site to site. It does this through extensions that are available for every field. When the meaning of the data needs to be clarified, an extension can be added to carry some additional information or code. This means that FHIR is infinitely customisable. Again, the implementer will need to carefully review the specification of the inbound messages or the expectations of the receiving system and adapt the FHIR resource structure to suit.

The structure and communication protocols for FHIR are well defined but it is very light on implementation profiles and use-cases, obviously because it’s too early for them to have been developed. These will become essential. There is still a lot of variability in how the transfer of data occurs. If one system is to send a resource to another system, it can either create it or update it. Just the existence of the create interaction indicates that the sender needs to know whether the resource exists in the destination system or not – it needs to do a query.

Alternatively, the sender can just issue an update which will create the resource if it doesn’t exist. Updating a resource when you know the resource ID is very good, especially if the sending system has found the resource on the destination first, but the update also allows the sender to specify the resource ID they want the destination to use when it’s created. It’s too easy for the sending system to only use updates and set a sequential counter as the resource ID to be used in the destination. When two systems do the same, the possibility of duplication is very real. One system thinks it’s sending a new patient resource for example, but really it’s updating a different patient created by a different system.

Management of resource IDs on the destination system becomes a nightmare. Personally, I’d be happy if an update did only that, update. These interactions between systems will need to be much better defined before FHIR can become anything more than an ad-hoc mash-up of data and resources.

Can resource management get any more difficult? Perhaps it can. For this Connectathon, I focussed on the patient resource. It was mostly about moving some data from one system to another but I’ve started to look into other resources that I will need to use – encounters, orders, results – and I’m getting more and more confused.

Consider a Patient Administration System (PAS) where a new patient is entered. A resource now exists in the PAS for that patient. The PAS uses a FHIR Create interaction for each clinical system to add the patient. In the Order Entry system, the clinician orders a test for the patient. Now a resource exists in the Ordering system for the order so it uses a FHIR interaction to create the resource on the destination clinical system, say a Radiology Information System. Part of that interaction is to include a reference to the patient resource, the Subject, in the FHIR resource.

Which resource does it use? Does it send a reference to its own resource or does it send a reference to the resource on the PAS which is the source of truth. Of course, the PAS also created the patient resource on the RIS so maybe the Ordering system should reference the patient resource in the RIS.

The RIS accepts the request and creates an order that goes to the PACS which only gets updates from the RIS so it knows nothing about the PAS or Ordering system resources. Which references are used here? The PACS eventually sends an ImagingStudy resource out to the RIS and also the Clinical Information System. Now I’m getting completely lost.

It’s claimed that FHIR will be cheaper to implement than HL7 V2 or V3. I’m not convinced, unless …

Maybe I’m thinking about this all wrong, still stuck in a point-to-point messaging paradigm. Perhaps what we need is a FHIR server that just stores FHIR resources with no interpretation of the data. Each system publishes its resources to the FHIR server – Patient and Encounter resources from the PAS, DiagnosticOrders from the Order Entry system, DiagnosticResults from the RIS, ImagingStudy from the PACS, etc. This becomes the repository for the one and only copy of a resource.

Each system is able to subscribe to the FHIR server for the resources that want to receive. The RIS subscribes to get the Patient, Encounter, radiology DiagnosticOrders and ImagingStudy resources. It may also subscribe to Location and Practitioner which will replace V2 MFN messages, automatically adding new wards and referrers as they are published by other systems. The Clinical Information System subscribes to get the RIS DiagnosticResults and PAS Patient resources, and so on.

Suddenly, the reference to a resource becomes obvious; it’s the only true one there is, the one on the FHIR server. The FHIR server specification may also define the meaning of key data and essential extensions relevant to the organisation.

Now that might just make things a little easier, if only I had some way to store all the new resource reference information in the existing clinical database that I support.

Really interesting three posts Garry – thanks so much for sharing.