FHIR enabling an Immunization registry – part 4

So we’ve talked about how to represent an immunization program both in the abstract (the overall definition of a national plan) and the specific (the plan applied to an individual). In addition, we discussed how to submit the actual administrations to the registry.

What we haven’t really talked about is how to measure the performance of an individual against the plan.

There are (at least) a couple of ways that we could do that. Note that both do assume that the patients record of administrations is available – which is kinda obvious really.

First off, recall from the last post that the PlanDefinition described the administration of a number of specific ‘series’ of administrations (e.g. a specific vaccine) over a period of time, with a set of ‘doses’ represented as a dose number within the series.  That series/dose was copied into the ImmunizationRecommendation and eventually into the actual record of administration – the Immunization. (Incidentally, we didn’t mention this, but an Immunization can also say why a particular does wasn’t done – e.g. because of allergy or refusal to allow administration)

It seems logical that if we have the series/dose information in both plan and administration, then determining if someone is up to date is a simple matter of checking whether there are the right number of Immunizations that the person should have given their age, right?

But that won’t work quite so well, as the immunization plan will change over time as new vaccines become available and new diseases need coverage (and others don’t). And we can’t really assume that all Immunizations will have this information anyway.

An alternative way is to think of this in terms of the disease being covered, rather than what has been administered. Here’s how it might work.

• Based on the patients age, we determine for each disease of interest how many doses of a vaccine that protects against that disease they should have received. We can get that from the information in the plan – the ActivityDefinitions.
• Next we examine their immunization history to see what vaccines they have received. For this we need to know what disease each vaccine covers – information we were careful to place on all the resources, though we really only need it on the plan for this to work.
• From there it’s a simple matter to look at the difference between the number of doses they should have had and what they have had, and we can see what’s needed. If we were really clever, we’d also ensure that the doses in the history were appropriately spaced for proper effect and only count the ones that would be effective.

The way that we report the differences could also be done in a number of ways.

• We could simply report that the person needs to receive x doses of some vaccine that covers a given disease and let the client figure it out.

• If we were smarter, we could report that back as specific vaccines – some covering multiple diseases. This is preferable, as we’ll get better quality if the calculation is done in one place (eg the registry) rather than assuming that all the client applications will get it right, but could be non trivial.

Another consideration is timing of the ‘catch-ups’ – when should they be given, especially as the child still has to complete the remainder of the plan. I’m going to duck on this one – I suspect that it could be complicated to get right for an individual so it may be better to report on what is needed, provide guidelines to how to do it, and leave it to the user to work it out.

So let’s assume that we can figure out the catch up vaccines the child needs, but are going to let the client figure out the timing (with guidance) – how to report that back to the client? The most obvious way is to add this to the ImmunizationRecommendation resource. We can set the recommendation.forecastStatus to ‘overdue’ and the forecastReason to a code of some sort that indicates there is a missing vaccine in the sequence. But, there may be other ways…

To wrap up this post, let’s take a look at a sample app I created that allows you to look at this in real time – you can find at clinFHIR.com/immRegistry.html.  It’s a simple thing that shows how a client app might interact with the information from the registry.

There are a couple of tabs.

The first shows the plan as a tree. Clicking any of the elements displays the details (as json) to the right. If it’s a ‘top level’ action (representing the age of administration) then the action from the plan is shown. If it’s a detail action (an actual vaccine) then the ActivityDefinition is shown as well. If you need to, refer to the post where we discussed this.

The second view shows the details of a sample patient and is a bit more interesting.

In the yellow bar across the top is the patients current age. Changing that will update the display below, which has 4 main parts.

• The List of Immunizations represents that Immunizations that the patient has received – in this case only 1.
• To the right of that list is a compressed view of what they should have received – derived from the plan of course
• Below the Immunization list is the result of the disease analysis described above. It’s coded in javascript on the client – though would be nice if it could be performed by the registry in some way for the reason we discussed. For each disease, the number of vaccine doses due and administered is shown, with the row colour coded appropriately.
• To the right is a place where you can decide what ‘catch ups’ are needed. Clicking on the + symbol adds that vaccine to the catchup list and updates the analysis. Basically, you are trying to make the analysis all green – at which point the catch up can be planned. For the example patient aged 2 months, you’re going to need a PRV1 and PCV10.

This is really intended to show the sort of functionality that a client could implement, if the data and functionality were available. You could imagine the immunization nurse using a tool like this to plan out the catch up programme – perhaps saving the output as a customized ImmunizationRecommendation on the registry so anyone can see it. You’d want some way to allow the user to set the dates due as well of course.

And finally, a list of the API calls needed for this.

• GET [host]/PlanDefinition/{paediatric program id}   (May be a search on some specific elements if the id isn’t known)
• GET [host]/ActivityDefinition?url={activityDefinition uri} – for the plan details
• GET [host]/Immunization?patient={patient.id} – for the patients’ current data

If you were going to save the catchup as an ImmunizationRecommendation, then you’d need to PUT that as well (There’s a bit more thought needed about the best way to manage these if they are to be persisted).

And we’ll also need an API for the disease analysis if not done on the client – haven’t quite worked that out yet either.