This conversation is from the Implementers Chat. It describes what is likely to be quite a common scenario, so I’m sticking it where for when I need to remember it.
Question:
We have a usecase where a Practitioner in small practice creates a CarePlan for a Patient and assigns himself as a Participant, and sends out this CarePlan using FHIR messaging to another Application. Over time, he creates CarePlans for hundreds of Patients. Now at one point in time he hires another MD to provide care to the same Patients. This would required sending out all CarePlans that are still active with the second MD being also mentioned as a Participant.
In order to avoid these massive retransmits, we would like to use a Group resource to group all active Practitioners and assign that Group as Practitioner to all CarePlan, and only send out the Group when a member has been added or is removed.
Now the problem is: CarePlan.particpant.member is defined as Reference(Practitioner | RelatedPerson | Patient | Organization)
This is actually just an example of a bigger issue, namely, if a Group of X is allowed, each Reference( X ) should ideally also allow Reference(Group)
Any feedback from the group?
Answer from Ewout:
Hi Theo, in this case, the group of MD’s are actually acting collectively and towards the same goal (taking care of the patient), so this informal group is actually an organization (note that the definition of Organization in FHIR is broader than in normal life):
“A formally or informally recognized grouping of people or organizations formed for the purpose of achieving some form of collective action. Includes companies, institutions, corporations, departments, community groups, healthcare practice groups, etc.”
I think organization matches your purpose, so the Organization becomes the “Participant”!
I was asked an interesting question yesterday by one of my colleagues at Orion Health – how to best represent a patients ‘Circle of Care’ (or Care Circle) in FHIR. Now, there are a number of different interpretations of what a Care Circle actually is, but in our scenario it’s all about relationships between a patient, and those who are involved in their care (which includes clinical and non-clinical alike).
As you know (or should by now!), FHIR has from the outset been an implementer driven standard. The focus has always been on making healthcare interoperability as straightforward as possible, and regular connecathons have been an important part of that process (and we’re up to our 7th now).
However, it has to be admitted that thus far it has been the ‘techies’ – the ‘geeks’ – that are the main attenders at connectathon – and that’s kind of inevitable, given all the base work that’s needed to make FHIR a realistic standard for exchanging health information.
But FHIR is all about exchanging clinical information, and that means that it has to meet the needs of clinicians (which I use in the widest sense) as well as the technical folk. (And patients too – though that is another story).
At the last Working Group Meeting in Phoenix, we decided that it was time to think about a ‘Clinical Connectathon’ – where the emphasis was on meeting the needs of clinicians delivering care rather than the needs of technical people supporting them – can FHIR do that?
So, at this WGM in September (held in Chicago) we’re going to have our first Clinical Connectathon (as well as the usual one – sigh). The focus of this event is to allow clinicians to focus on the “clinician to clinician connection” rather then the underlying technical resources that support those interactions. Read more of this post
After the previous discussion on how to represent an Immunization plan, I had intended to talk about how to represent the Immunization protocol (or schedule), and how to apply that to a patients’ plan, but (as so often happens) I got a bit side-tracked, and thought we could first think about how we might create a Profile against the CarePlan resource to represent an immunization plan.
Now, we’ve talked about FHIR profiles before so I’m not going to repeat that here, other than to say that it is the profile that takes a standard resource (or resources) and makes them fit more precisely to a particular Use Case of some sort, so profiling CarePlan to support an Immunization plan seems a perfect fit!
There’s actually quite a lot to do to get a good profile (and I’m sure I haven’t got it completely correct), but at a high level, once you have your use cases you go through the resource and:
Alter multiplicity of elements (e.g. to make an optional element required or not used. Remember you can’t make a required element optional though)
Specify a particular terminology or codeset for a binding (and often you’ll define a ValueSet to hold the list of allowable codes)
Add a new element (as an extension) where it’s needed by the Use Case but not defined in the base resource
(There’s other things you can do as well, but that’s enough for our current needs).
Overall design
Here’s the structure of the Care Plan resource (Sorry about the image quality – its a screen scraping from my computer – here’s the original)
How we’ll structure our profile overall is to use the goal element to list the diseases that this plan is intended to protect against (using an extension), then optionally link the activities back to the goals/diseases that are covered by that vaccine. That way we can say which activities contribute to protection against which disease. We’ll make this all optional, as not everyone will want to go to this level of detail (and, in truth, is probably a bit overkill). (btw – Another way of doing the same thing would be to add extensions to the activity directly to indicate the diseases being covered)
The activity will generally be the administration of a vaccine, however we’ll keep it a bit flexible to allow for, say, educational sessions as part of the plan. We’ll know which activity is an vaccination because the activity.simple.category will have the value ‘drug’.
We only need to profile the CarePlan resource for this Use Case.
For simplicity, we’ll put all the extensions in the same profile – in real life we might try to re-use existing extensions or to make some of ours a bit more general. This will really need common registries of profiles, which the FHIR team are working on at the moment…
Layout
So the following section lists the changes (in a textual format) that we’ve going to make to the CarePlan resource to allow it to hold the information required to represent an immunization plan. Each entry has the path to the element, followed by the multiplicity (which may not be the same as that in the base resource). If the entry is an extension (and remember that extensions can be at any level in a resource) then the path will end in a #{extensionDef code} and the data type will be displayed. Thus:
Careplan.goal#disease (0..1) CodeableConcept
means that this extension is against the goal element of the CarePlan resource, that it’s optional and there can only be one, and that the datatype is CodeableConcept.
If the values of the element (extension or base element) come from a ValueSet, then we’ll place the name of the ValueSet in square brackets at the end. Eg
means that the value of the code (which is required in this profile) comes from the valueset whose name is immunizationVaccines. (Actually, this should really be a complete URI, but we’ll keep it simple to avoid cluttering the page). Note that this layout is just the one we’re using for this post – the formal representation will be the profile resource and maybe other artifacts that the core team is working on. (Actually, I think the next connectathon is going to focus on profiles and conformance)
So, here we go. To minimize space, we’ll only include entries that are different to the base resource, or where there’s a particular comment to make.
We’ll also do this in 2 posts. This one will be more of a ‘design’ session – what we’re going to do and why. The next post will build the actual profile.
Items in the Profile
Careplan#protocolDescription (0..1) string
An extension where we can describe the protocol that this plan was drawn from.
Careplan#protocolUri (0..1) uri
A direct link to the protocol (if known).
CarePlan.patient (1..1)
You have to have a patient in our plan…
Careplan.patient#dob (0..1) date
The patients Date of Birth. This is a bit naughty as you should really retrieve the Patient resource and look up the Date of Birth from there. The reason to include it here as an extension is to allow us to be able to determine if an immunization is overdue just on the information in the plan. In reality, you probably woudn’t do this but, hey, its my blog and I’ll de-normalise if I want to…
Careplan.period (0..1)
This would be the age range over which the immunization plan was active – eg from birth to 18 years
Careplan.modified (1..1)
This should be updated when the plan itself is changed – ie a new activity is added, to the status of an existing activity changed. The multiplicity is changed to make it required.
Careplan.concern (0..0)
As this plan is specifically about immunizations, the concern is not needed – i.e. the whole point is to avoid the patient getting those conditions. Change the multiplicity to 0..0 to remove it.
Careplan.goal#disease (0..1) codeableconcept
We’ll use the goal to list the diseases that this plan is intended to protect against, then optionally link the activities back to the goal. That way we can say which activities (immunizations) are protecting against which diseases. Note that there’s only a single disease per goal, but multiple goals per plan.
Careplan.goal.status (0..0)
The overall status of the plan is at the careplan level, not the goal.
An extension that references the Immunization reference. Should be populated when the vaccine is either given or offered and declined.
Careplan.Activity.goal (0..*)
To allow us to link this activity back to the goals (the diseases this vaccination is intended to protect against) if we want to.
Careplan.Activity.status (0..1)
Really the only codes that makes sense here are ‘completed’ and ‘cancelled’. However, this is a fixed code set in FHIR so we can’t change it. If due then we can either leave it blank, or we could use the value ‘not started’ or ‘scheduled’
Careplan.Activity.actionResulting (0..0)
Don’t want to record this in the plan
Careplan.Activity.detail (0..0)
The careplan.activity.notes can capture the level of detail that may be required, so this is not required.
Careplan.Activity.simple.category (1..1)
Fix the value as ‘drug’. We might want to suggest that ‘immunization’ be added as an option to the base resource.
Fix to use a period and make required. The ‘start’ property is required. ‘end’ is optional. This will be the period over which the vaccine must be given to be effective.
Careplan.Activity.simple.location (0..0)
No need to specify location in the plan
Careplan.Activity.Simple.product (0..0)
This information is in the code
Careplan.Activity.simple.dailyAmount (0..0)
Not needed
Careplan.Activity.simple.quantity (0..0)
Not needed
So now that we have an idea about what our profile is going to look like, we can build the profile itself. That will be the topic of the next post!
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’?
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 3rd 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.
Recent Comments