Read what our expert contributors have to say

What is your pathway to HL7 FHIR?

I’ve been asked many times about where to start with FHIR, and the answer is “It Depends”. Why does it depend? It depends on the use case that you are dealing with.

It is a large standard and can be daunting on where to begin.

Are you looking to replace a legacy integration pattern with more modern RESTful APIs?

Are you trying to interact with an existing FHIR implementation?

Are you wanting to open data access for mobility and need an international standard that you can point developers to, to fast-track adoption?

Regardless of where in the standard you want to start, I would take an incremental approach. HL7 FHIR is all about the implementation – a standard to be implemented, and not a theoretical exercise. I call this Pragmatic Interoperability. Pragmatic – because you must be practical about what you can do. Sometimes you are working with legacy applications that cannot easily be updated to natively support FHIR. In these cases, you may need to consider alternative approaches including creating facades or using middleware to transform the data to FHIR.

With Pragmatic Interoperability, start with your use case in mind. The use case could be something like a patient questionnaire assessment tool, or a clinical task management application.  But, for our example, we will consider a use case where we want to provide the ability for patients to update their contact details within an application, then let’s see how these influence where we start with FHIR.

So, we first think about the resources that we might need. We need the Patient resource because it will have our contact information within it. We might also want to create a Task resource and manage the workflow of our change to the Patient resource.

We can then consider what profiles or implementation guides we might need to use to fit into our particular implementation (depending upon the geography or given project). The profiles and implementation guides are going to point us to terminologies that we will need to consider, extensions that are available, and constraints that we need to work within.

Now is where I suggest we test our implementation. And when I mean test – I am suggesting that we manually create (or mock-up) a couple of resource examples to get us started. An example of a Patient resource with our contact details present and then a before and after view of the patient. This will help us consider how the resources will be modified by our application – without writing a line of “insert name of funky cool programming language here”. This step allows us to identify potential issues with our use of a resource. A great way of testing an implementation is at a HL7 Connectathon. These events bring together likeminded health interoperability people to test out the standard and find out how they are supposed to work, and what changes may be required to the standard.

We can also validate the resource against the profile that we are using to make sure it is valid. The other great part about this piece of work is that it can be re-used. We can add these examples and documentation into our implementation guide. This is the great part of an incremental approach – we can test our use of the standard and if needs modification then we can pivot very quickly.

I have 3 tips for anyone interested in healthcare interoperability.

1.       Join the community – working with the standard is a team sport. Come and help us refine the standard to make it work in Australia.

2.       Make a start with FHIR – no matter how small. Start incrementally. When you have an interoperability project, make HL7 FHIR your default choice.

3.       Attend HL7 events – HL7 FHIR Connectathons, information sessions, training, working groups are great ways of learning and sharing your knowledge with the community. Everyone can give something to the development of the standard to make it better.

17th OCT 2023 | BY CHRIS ROYLE