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.