Representing Recalls

Recently I was asked by a local vendor what was the best way to record a recall in a Practice Management System (PMS).

As background, in New Zealand (and likely elsewhere) it is common for a Primary Care Practitioner (what we call a General Practitioner) to create a ‘recall’ for a patient. These are essentially reminders that a patient needs a follow up for some purpose within some time frame. 

Examples of recalls include:

• The patient has a mildly abnormal blood test – not worth acting on immediately, but should be checked again in a month or so to see if it is changing
• A mildly elevated blood pressure was taken during a routine visit. Again, not high enough to consider treating immediately, but should be checked in a month or so.
• The patient is eligible for a screening program – such as a cervical smear – and needs to have one performed in 2 years time
• A child due for their scheduled immunization
• An elderly person is not coping at home – have the nurse contact them in a week to see how they are going

As you can see, there’s a combination of ‘ad hoc’ reasons – something unusual was noted – and ‘scheduled’ reasons – the cervical smear or immunization. Although different in how they were created, it’s convenient to group them together to help ensure they are completed and the PMS often just has a ‘recall list’ for the patient that includes all these reasons why the patient should contact or be contacted by  their practitioner. 

So how to represent this in FHIR?

There is (of course) more than one way to do this, but let’s follow the same pattern used in the PMS – there is a list of recalls – where a recall has a reason, and a period when the recall should be completed. The recall will be a resource of some sort that can easily be queried for or shared.

In some cases, the recall is the result of some planned set of activities – an immunization or screening programme, and we’d represent the definition of that programme as a PlanDefinition as discussed in this set of posts. Periodically (likely some automated process) the PlanDefinitons are examined for new activities needed and CarePlans created/updated as required.

The ad-hoc recalls are just created directly as needed.

So what are the requirements for our ‘recall’ resource? Really we just need 4 main elements:

• The person the recall applies to
• The reason for it
• The time frame it needs to be actioned by
• Optionally, the ‘source’ of the recall (such as the PlanDefinition from which it was derived, if any)

There are others we may need – for example in some cases we may want to assign responsibility to someone.

There are a number of candidates for the ‘recall’ resource.

The Task resource is used to track the progress of some activity that needs to be completed. It has all the required elements – and many others that could be used for specific purposes. But its main strength is where there is a set of things that need to occur, often by different actors – it feels a bit overkill for this requirement.

How about the ServiceRequest? We are certainly noting that something needs to happen. But often the date that the recall is due is months or years out. And we’re really just making a note that the activity needs to occur – we haven’t yet scheduled that it should occur.

And speaking of scheduling, how about an Appointment? Well, same issue really – we don’t have a date or time for the activity to occur – just when it should be done by.

Or there’s the ever useful Observation – perhaps we use a specific category for recalls, then we can easily query for our recalls. Though, in truth, a recall isn’t really ‘observing’ anything…

And there’s always the Basic resource – with the appropriate extensions it can do anything, but it’s really a ‘last resort’ resource, when nothing else will work.

All of these options could be made to work, but there is a better one – the CarePlan. In fact, when we look at the description of CarePlan we see this:

Care Plans are used in many areas of healthcare with a variety of scopes. They can be as simple as a general practitioner keeping track of when their patient is next due for a tetanus immunization through to a detailed plan for an oncology patient covering diet, chemotherapy, radiation, lab work and counseling with detailed timing relationships, pre-conditions and goals.

And even better, the CarePlan is a defined component in the International Patient Summary (IPS) so it’s straightforward to include them when producing the summary.

So it looks as though CarePlan is the resource to use for our recalls, but there are still a few things to consider – for example, is there one CarePlan or more than one?

A single CarePlan is certainly possible – a CarePlan can have multiple activities so we could have a ‘recall CarePlan’ – setting the category to some appropriate value so we can easily find it, and just updating it as recalls are created and completed. 

But the downside to this is that recalls are independent ‘things’ – they occur at different times, by different people, some may be completed and others not. And the recalls are about lots of different things – lumping them all into a single plan doesn’t feel quite right.

So multiple plans does seem a better way to design it – we could add a category, though really any CarePlan does need to be monitored – recalls aren’t that different.

And there is certainly a hybrid approach – we could have a single plan for immunizations and another for screening – it doesn’t really matter – it’s what suits the PMS (and the local ecosystem) best.

And the other resources we considered remain useful – after all, the CarePlan is just what we intend to do – we might also want to track the execution of one in more detail. For example you could imagine creating a Task to track that a Cervical Smear is completed, reported and reviewed. Something like:

• A CarePlan activity becomes due (.activity.detail.scheduledPeriod)
• Create a Task to track its completion
• Create a ServiceRequest to the Nurse to contact patient to make an appointment with a reference to the task
• Then an appointment for the patient to attend
• A procedure records that the smear was taken, along with a Specimen to represent the swab
• Another ServiceRequest to the lab for the smear to be examined, and the DiagnosticReport / Observation when the result is available.
• The task is completed once the result has been viewed by the practitioner.

All these activities potentially result in updates to the Task as activities are performed, and the Task is closed (completed) once the practitioner has reviewed the swab. And, of course, the results of the smear may result in further workflow resources being created and/or another CarePlan for the next swab. 

Here’s an example of what the completed graph might look like for a simpler Blood Pressure follow up:

And there may well be a set of Task versions as each step is completed.

So there you go, recalls in FHIR (or, at least, one way to do them 🙂 )