Using FHIR to record Immunizations

At the last Working Group Meeting we agreed that it would be a good idea to think about holding a ‘clinical connectathon’ where the focus of the event was on how we can use FHIR to meet real clinical scenarios, rather than the more technical, developer based focus of the current connectathons.

The idea is that as we progress through the ‘maturity’ stages of FHIR towards a normative standard, we want to be really sure that it’s fit for purpose, so having an event that takes clinical scenarios, and then ensuring that the standard supports those scenarios makes a lot of sense.

At the moment we’re at the stage of choosing representative scenario’s and then matching the current FHIR resources against those scenarios to see how they work, and identify gaps. I’ve been given the task of looking at paediatric immunizations, so thought I’d share the thinking here. (Actually I volunteered – after all, how hard can it be? <s>)

So lets set the scope of the discussion.

Most countries have a standard paediatric immunization programme (or protocol) – a set of vaccinations that applies to most children, and specifies the ages at which they are given. This can actually get quite complicated – especially when the programme changes and there is a ‘catch-up’ set of vaccinations required for children partway through the programme.

This programme is applied to a specific child, and can be customized for that child – for example they may be allergic to a particular vaccine or to eggs (which influences what vaccines they can be given). This is, in effect a Care Plan (or at least part of a care plan). If the care plan is altered in this way, then there needs to be some record made of why this was done – both for the patients clinical record, but also important for reporting.

When a vaccine is actually administered, the plan is updated and an entry is made in the clinical record for the patient, which includes such details as the date given, person who gave it, vaccine type and other details such as the manufacturer, lot number, site etc.

In some cases, the childs parent will decline to have their child immunized. Again, the reason for this needs to be recorded in the notes, and the plan updated accordingly (it may be the whole plan that was declined, or just a part of if – a specific vaccine).

So here are the main use cases (excluding the ‘workflow’ use cases – the process of recalling the child for the immunizations):

• Create the childs initial immunization plan from the standard protocol
• Administer a vaccination, updating clinical record and plan
• Record any reactions that occur – updating the plan if required
• Record that a vaccination was declined – updating the plan and the record
• Update the plan to reflect personal issues – such as allergies – or additional vaccines required
• Update the plan to reflect a change in the standard protocol (which will include ‘catch up’ vaccinations)

(I’m sure there are others, but these will suffice for this discussion).

So how does FHIR rate against these requirements?

Let’s start with the simple stuff: recording an immunization.

The Immunization resource is used to record the actual administration of a vaccine (or not, as we shall see). It has elements to record the details of the vaccine given, who gave it and when it was given. One thing it doesn’t have is a reference to the Encounter in which it was given, but that’s easily managed by an extension. There are a number of things worth calling out about this resource:

• vaccineType is the vaccine given (or refused)
• refusedIndicator is a required Boolean that lets you record that an immunization was offered but declined by the parent. If true, you can use explanation.refusalReason to record why it was refused.
• reported lets you record vaccinations that you have been told have occurred, but haven’t given yourself.
• reaction is an element that allows you to record any adverse reaction that occurs subsequent to giving the vaccine. (Of course, this field would be filled in as an update to the Immunization resource – not at the time of creation – unless you are slow at updating your records or the reaction was particularly quick! You’d create the AdverseReaction resource and then reference it from the immunization)
• performer and requestor record details of the people administering the vaccination.
• site, route, doseQuantity – how much was given and where
• manufacturer, lotNumber, expirationDate – details about the vaccine
• vaccinationProtocol allows you to record the protocol/s that this immunization is a part of – including where it is in a sequence of vaccinations, and the disease being protected against.

Retrieving a childs immunization history is then simple:

GET [host]/Immunization?subject={patientid}&refused=false

(Note I included the refused in the query to only get back the actual administrations. I could just as easily leave that out and manage client side if I wished to – for example – indicating immunizations that had been declined)

Recording the plan

So recording an immunization is straightforward  – what about the set of immunizations that a child should receive – their ‘immunization plan’?

Looking at the spec, there would appear to be a couple of ways – the ImmunizationRecommendation or  Careplan.

Lets talk about ImmunizationRecommendation first.

FHIR defines this resource intended specifically for holding details about what immunizations a patient should receive (Actually it states “A patient’s point-of-time immunization status and recommendation with optional supporting justification“, so we might be on the wrong track, but let’s run with it for the moment…)

Each resource is specific to a patient, and has one or more recommendation elements (each representing a specific vaccine), each with one or more dateCriterion elements giving the dates on which each dose of the vaccine is due.

Properties to callout:

• recommendation is the element storing details of a single vaccine.
• recommendation.vaccineType is the actual vaccine to give
• recommendation.doseNumber is which dose this is in a series. For example, if the vaccineType is ‘pneumococcal’ and there are 4 doses to give, then this recommendation element version might be the date for the 3^rd dose.
• recommendation.forecastStatus indicates where the child is with respect to the protocol – ie due or overdue.
• recommendation.protocol has more details about the protocol (though I’m not quite clear about how some of these elements differ from those in the recommendation – eg the Recommendation.doseNumber and Recommendation.protocol.doseSequence.

So you can imagine a sequence as follows:

A new child is born (hurrah!). A new ImmunizationRecommendation resource is created for them from the standard protocol (more about that soon). In the most common use case, the ImmunizationRecommendation would simply be a ‘copy’ of the immunization protocol.

Each time an immunization is given, an immunization resource is created and the ImmunizationRecommendation resource updated by removing the appropriate dateCriterion element. (an alternative would be to use an extension to indicate that the vaccine had been given – this would need to be a modifierExtension as it changes the meaning of the element).

Thus the ImmunizationRecommendation resource for a patient has a number of versions representing updates to the plan (generally when an immunization is given, but also updated when declined.

Now let’s have a look at the careplan.

We’ll model this as a separate careplan resource for immunizations. We could incorporate immunization elements in a single larger plan if we wanted do, but a separate plan with a goal of ‘keeping up to date with immunizations’ does seem a bit cleaner, especially if a patient has multiple plans stored in multiple systems).

Properties to callout:

• Goal is what we’re trying to achieve with this plan.
• The activity is where we record the vaccinations that the child should receive – one entry per vaccine dose.
• Activity.simple has the details:
  • Category (this would have the value ‘drug’, though we might want to add ‘immunization’ to the list of possible values )
  • Code – not sure what we’d use this for – the product would indicate the actual vaccine
  • Timing – when the dose needs to be given.
  • Product – this would be the actual vaccine
  • Quantity – how much to give.

The actual sequence is going to be much the same as that for ImmunizationRecommendation.

A child is born and an immunization careplan created for them from the standard protocol. The plan would have one activity for each dose of a vaccine that is required.

As the child progresses through the plan, immunization resources are created and the plan updated. We can be a bit more creative by using the activity.status code though – setting that value to ‘completed/cancelled’ as an immunization is given or declined. This would mean that the status of each dose is immediately obvious from the plan.

(Alternatively we could delete the activity from the plan as it is completed, but that just doesn’t feel right when we have a status to record the outcome.)

What might be quite nice would be to reference the actual immunization resource from the activity using an extension once it has been given or declined.

We’d probably create a profile against careplan to specify the appropriate coding systems, add extensions (like a reference to the actual immunization) and remove the properties that don’t make sense for immunizations .

So which to choose?

Well, to my mind the careplan seems the logical choice.

• It is where all other planning activity is going to be recorded (either in a single common plan or a collection of them).
• It has an element (activity.prohibited) that we can use to indicate that a vaccine should not be given – that we might want to use if there is a serious allergy to a vaccine
• It keeps a nice history of our activity against the plan – and referencing the actual Immunization would be useful here.
• The timing element can be a period rather than a fixed date – useful to indicate the range of dates when a vaccine can be given to be effective.
• ImmunizationRecommendation feels like it is more intended to answer the question ‘What should this child receive now (and are they overdue)?’ or ‘how well is this child doing with respect to their immunization plan’ rather than a formal plan of care for an individual.
• There are elements in ImmunizationRecommendation that don’t really fit in this context – like recommendation.doseNumber and recommendation.protocol.doseSequence

In fact, after I wrote this post the careplan seemed such an obvious choice that I nearly went back and edited out the ImmunizationRecommendation as an option, but in the end decided to leave it there to record how I came to this conclusion.

So we’ve talked about how to record immunizations and how to store the immunization plan for a child. What we haven’t talked about is how to record the standard immunization protocol and apply that to a child – and we’ve got a few options to consider. This applies equally to changes to the standard protocol, and how that effects the plans of children already receiving immunizations.

We should also think about reporting – most jurisdictions have a requirement to report at a population level the overall status of immunization so we want to be sure we’ve covered that off as well.

However, this post is already over-long so we’ll consider these in the next post.

Comments (as always) welcome!