Using the mailbox endpoint for Immunization Decision Support

One of the great things about attending a FHIR connectathon is that you get to meet smart people who are doing interesting things with FHIR.

At the recent connectathon in phoenix, I saw some work that Richard Ettema of AEGIS  had done with an Immunization forecasting application (these are the same guys helping out with the HL7 conformance testing pilot).

The idea is that there is an immunization Decision Support service (in this case supplied by Nathan Bunker http://tchforecasttester.org/  ) that can take as input  patient demographics  (it only needs their Gender & Date of Birth) and immunizations that they have already received, and returns a list of the immunizations that they are overdue for – and ones that are due in the future.

Now, this application resonated with me for a couple of reasons.

In a previous life I was a PMS (Practice Management System / EMR) vendor, and I recall than one of the hardest things I had to do was to cope with changes to an immunization protocol. It’s just plain hard dealing with children who are part way through a programme to figure out what ‘catch-up’ vaccines they should receive – and when – plus the new ones they need. I remember at the time thinking ‘there must be a better way than everyone doing the same thing’. I also worried about getting it wrong. What if I made a mistake and children got the wrong immunizations? Who would know?

The second reason was that this is a use of the mailbox endpoint in FHIR – and I simply hadn’t picked up on the value of using a real-time messaging paradigm in this way. The mailbox endpoint takes a bundle with a MessageHeader (or Composition) as the first resource, and whatever resources are required for the particular business process. In the case of a message, the MessageHeader resource has an ‘event’ property that indicates the event that caused the message to be created (and by implication/agreement what the server is expected to do with the message). The server performs whatever processing is appropriate and returns a bundle with the response – in this case a collection of ImmunizationRecommendation resources.

Now, I admit that in many cases there does need to be an agreement between sender and server about what the server responsibility for particular event codes in (this is called ‘trading partner agreements’ in the spec) – though I’m sure that the existing v2 event codes and their meanings will apply –  but this does seem to be a neat way of implementing task orientated services within the standard spec.

I ‘borrowed’ these images from the presentation that Richard gave at the WGM (sorry about the image quality – they are screen grabs).

This one shows the overall principle – using FHIR as a common interface to potentially different Immunization DSS engines

The next image shows a couple of implementation architectures. The top image using a ‘proxy’ to interface between FHIR and the DSS engine, and the bottom being where the DSS engine implements the FHIR interface directly (both were demoed at the WGM).

So go check out the demo – it’s all on-line at  http://wildfhir.aegis.net/fhirgui

Click the “Mailbox” tab, and select “TCH Forecaster” as the FHIR provider (Nathan Bunker’s forecaster service.)

All forecasts assume the current date for the basis of the results returned.  You need to enter the patient demographics (gender and Date Of Birth) at a minimum.  You can then enter up to three (3) immunizations and the date they were administered. (in reality you’d get this from the PMS of course).

Now click the ‘Forecast’ button next to the provider dropdown.

After a short delay, the results are displayed in the tab panel below. The nicest display is the ‘Display Results’ tab that is most useful for a practitioner – the other tabs show the details of the FHIR response from the DSS service, which is what a PMS vendor would use for internal workflow, displays within the product etc.

And please be nice – this sample is supplied as an example service to the community – it’s not a hardened, production level implementation with sophisticated UI, so you could break it I’m sure if you’re that way inclined (and I’d rather you weren’t reading this blog if you are)…

Thanks Richard and AEGIS!