The Circle of Care in FHIR
December 9, 2014 7 Comments
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).
We could use this information in a number of ways:
- For example for Access Control: determining whether a person should have direct access to the patient notes (eg they are the patients Primary Care Provider), or whether they need to justify their need for access (eg they are an EC clinician and the patient is in the EC)
- Or Auditing – accesses by people not in the Care Circle could be subject to closer scrutiny
- Another use could be for alerting – maybe these are people who need to be advised when something happens to a patient
- Or it could help us in the UI for things like updating Care Plans or Referrals – if there are already people in the Care Circe we probably want to include them first.
So, given that there’s not an actual Care Circle resource in FHIR – how can we represent one? Well, there are (at least) 3 options:
- We can derive it from the patients Care Plan/s
- We can use a List resource
- Or – there is always the Other resource.
Let’s consider these options in a bit more detail.
Deriving it from the Care Plan does have some attraction. Presumably if a person is involved in the Care Circle then it will be for some purpose and in some role. The Care plan records this, so in deriving the Circle from the Plan we’ll always be able to know more details of that involvement.
But there are some issues. What if there’s a person (like a supporting friend) who is in the Circle, but not formally in a Plan? Are we going to allow this? And if a plan is completed, does the person remain in the Circle, or are they automatically removed? Makes changing the state of a Plan a bit more significant. And then there’s the simple technical aspect to consider – every time we want to display the circle we need to retrieve all the care plans and parse through them looking for participants. Seems like excessive effort…
What about the List then? Well, it is a resource designed for lists of things so would seem to fit. We would have a list ‘type’ that indicates that it is a Care Circle – hopefully a code that is universally recognized (technically we’d create a Profile and suggest that it be an ‘official’ HL7 one, the profile would then define the code for us).
As an aside – since we’re talking about profiles – the profile is able to indicate that a particular property has a given value to be compliant with the profile – this is NOT the same as a default value however – we’ll talk more about this in a later post.
We can record the participants of the circle in the entry element (could be a Practitioner, Person, RelatedPerson, Patient or some other appropriate resource). We’d need to add the role as an extension to the entry – and it would make sense to draw that valueset from the same one used by Care Plan – that would make it a simple matter to have a function that compares the List to the Care Plan/s ensuring that all plan participants are also in the List.
Downsides of this approach? Well, it does require the use of extensions and profiles for a consumer to make sense of the list – but in FHIR that’s a requirement anuway. The query is a bit more complicated than we’d like:
[base]/List?code={value}&subject={patientId}
or as a compartment:
[base]/Patient/{patientId}/List?code={value}
but we can live with that. Oh, and naturally we’d only want a single instance of the List – unless we really thought that the patient should have multiple circles. This might happen if the Care Circle was condition specific – for example one for Diabetes, another for COPD and so forth. Though a better approach might be to stick with a single list and add ‘condition’ to the reason for a participant to be in the circle…
The last option we identified is the ‘Other’ Resource. This is a resource that is specifically intended for situations where we want to use a resource that is not yet defined by FHIR (or where there is insufficient support in the implementer community to do so). It contains a code, subject and author, and everything else is added using extensions. We could easily add the extra items we need and then use it in much the same way as the List resource.
But does the Care Circle justify special treatment in this way – more so than medication list, problem list etc.? And, really, does this offer significant advantages over the simple List? The actual design is going to have some rather complex and nested extensions for example.
We’d probably use this if we really believed that it justified being ‘called out’ as a real resource – maybe as part of convincing the community that it is a good idea, but I’m not sure we’re at that point yet…
For now, let’s keep with the simple List approach and see where that takes us (though happy to receive comments of course)! We’ll make sure that our design is aligned with the data in the Care Plan so we can easily change our mind)
In a later post, we’ll take a look at what the Profile describing this might look like – there have been significant changes to Profiles, Extensions & Conformance in the next FHIR DSTU, and these are going to be a stream at the next connectathon so this will be a good opportunity to review those changes.
Addendum: See the comment from Lloyd – seems that the CarePlan is intended to record the Care Circle, so the List approach above is not the best way to go. sigh. Though I do think there will be complications for patient with multiple plans.
About David Hay
CarePlan was anticipated to be used as the primary representation for “circle of care”. If that particular “plan” has ended, that would tend to indicate that the either the condition for which the plan was needed is resolved or the organization responsible for maintaining the plan/circle is no longer concerned about the care (presumably because the patient has transitioned into the care of some other organization). Being in the CarePlan doesn’t necessarily mean they’re going to be performing any of the activities, but they do need to have some sort of role, even if it’s just as advocate or “person to inform”. Keep in mind that with CarePlan, the activities (and even Goals) are optional. It’s perfectly legitimate to have a CarePlan whose only purpose is to represent the circle of care. (And if this isn’t clear from the spec, please submit a change request to enhance the documentation – we should probably add “Circle of Care” as a synonym at a minimum.)
I think it would be of interest to clearly define what a Circle of Care is? I will use the definition from the Canadian Medical Protection Assn’s definition – The “circle of care” is the group of healthcare providers treating a patient who need information to provide that care.
Simply, this is captured as:
Patient.(Practitioner )careProvider[0..*]
By definition (not mine), every Practitioner provided in this careProvider list is in the patient’s circle of care. I see this list as a synonym for Circle of Care, notwithstanding the concept of non-provider membership. The FHIR definition for its careProvider attribute is:
“A Patient’s nominated care provider[s]”
And let’s include ‘implied consent’ as a common trigger for the nomination, for Canada!
So, CarePlan.participation for Practitioners, is nothing more than stating a likely addendum to the membership of the Patient’s circle of care, their careProviders. In other words, it says that this would be always be true:
Patient.careProvider[].count() >= CarePlan.(Practitioner)participant[].count()
when we’re focussed of the same Patient, i.e. Patient = CarePlan.patient.
And the practitioner in the plan is (likely through implied consent) to be considered participating , and thus in their circle of care, whether the practitioner is explicitly associated to an Activity in the CarePlan, or not.
A trigger of a practitioner being defined as a participant in a care plan is cause for the provider to be included into the patient’s circle of care. It is not necessary for the provider to have have explicit participation in an Activity within a care plan before being considered a member of the patent’s circle of care.
Additionally, a care plan is not needed to trigger the definition of a circle of care, so I would not wish a circle of care to be realized only through a CarePlan model construct.
In other words, a CarePlan may expand the circle of care of a given patient at a given point in time. When a new CarePlan is defined, the circle of care may grow to include the care providers deemed as participants in the CarePlan.
So, how do we model the Patient’s circle of care at any point in time? Answer: Patient.(Practitioner )careProvider[].
I see a weakness in the FHIR model, in that it lacks potentially useful associative attribution as to the reason, time lines, consent type, intent, etc, of the provider being a member of the patient’s provider list, but that’s beyond this discussion.
If all you care about is practitioners involved in the care of the patient, no need to capture that in a resource. You’d use the CarePlan resource to define a circle of care if you wanted to identify (and curate) a specific set of people to be involved in a specific type of care (specific type could be very broad in some cases) including what their respective roles were. And that set of people might include both practitioners as well as RelatedPersons (friends, relatives, etc.) The establishment of such a circle of care might influence access controls, notifications, billing, etc. or it might just serve to answer the question “who should I contact or coordinate with about X”
Patient.careProvider is more about identifying the “primary care provider”. E.g. “Who is your family doctor?”. It’s not intended to fulfill the full purpose of “circle of care” (and there’s an open “to do” to make this clear).
Consent is a whole separate discussion. There’s a draft profile on Contract that will support that.
It seems the CarePlan is geared around management of specific conditions? Given one of our key use cases is around access control I think you’ll see the value of it get diluted. Consider that we will have rules like:
* If you were the attending physician at the ED you have ongoing access to the record for 60 days from the last encounter with the patient
* if you are the PCP you have access for 2 years from the last encounter with the patient
* if you are a specialist, e.g. the patients cardiologist you have access for 1 year from the last encounter with the patient
These concepts are poorly expressed through a CarePlan since likely the way this would be expressed is through a Care Plan per provider with a period corresponding to the first and last encounter with this physician, but no goals/activities or other elements associated with a “proper” CarePlan and possibly modifier extension to indicate clients shouldn’t process these care plans if they don’t understand the special meaning, but this feels like a lot of effort/hackery. Without a CarePlan-per-provider you have no way to indicate “freshness” (i.e. last activity between patient and provider) without additional custom extensions on the participants to enable that. This is starting to feel like a lot of customisation for a Resource that is intended to be synonymous with Circle Of Care. Thoughts?
One of the uses for CarePlan is just to maintain a care team – a list of the practitioners (and others) involved in supporting a particular type of care for the patient as well as their role in delivering that care. It would be pretty straight-forward to add an extension to track “last engagement” if you wished, though I expect it would be safer to drive off of source data (e.g. SecurityEvent) rather than something that could be maintained/edited. A CarePlan that just represents a care team for a particular condition or for a particular type of care would not need to be suppressed in queries.
I think there is a model here that can works with both these concepts.
We generally do talk about a care plan as a plan for managing a single condition at a single organisation. Of course in this model there is a set of people involved that care plan which is the participants.
In addition when we’re talking about connecting heath care we’re often talking about an overall record thats the best guess at the overall plan for the patient. Sometimes it’s automatically created by linking together all the care plans from different conditions and organisations, sometimes it’s curated by a care-coordinator type role. Potentially this may even be curated by the patient themselves.
What this suggests to me is that while each care plan is defiantly an individual resource targeted at a particular condition by a particular organization, it does make sense for an HIE level system to expose a current “overall care plan” containing the “overall circle of care”, “overall goals” and the like. This is what I would see the patient directly interacting with rather than the isolated per-condition or per-organization plans.
It would be relatively coherent to have a specific “magic” care plan which is the current “overall” care plan. Essentially a similar concept to On Demand CCD documents that are often used with XDS.
There are lots of models. A patient could have a single centrally organized care plan. A multi-organizational team might form around a single condition or a set of related conditions. A care plan could be specific to an individual practitioner. A patient could maintain their own care plan, allowing updates from various practitioners.