Groups of patients in FHIR

I was approached by one of the Dev teams here at Orion Health for some help in ‘FHIR-enabling’ a patient selection service that they have been asked to build. My initial reaction was that we could model this directly as a restful query against /Patient, but after talking to them, the requirements were a bit more complex.

The application/module that they want to query against is a Clinical Pathways one. Patients are registered against a pathway – like diabetes management – and the requirement is to be able to return a list of patients on that pathway. The current requirement is just to return the list, but at some time in the future it is likely that there will be other query parameters as well.

The ‘twist’ to the story was that they wanted to be able to include in the returned list the ‘access level’ of the user making the query for each patient. This would be used by the client to display ‘hints’ to the user in the list UI – eg if the user would need to ‘break the glass’ to view that patients records then the UI would display a lock icon & so forth.

There may also be situations where the user should not even know if the patient is on a pathway, and in that case the patient should not even be in the list. In this scenario the client needs to know that the returned list is incomplete (but not the details of course).

Lets think about this in two parts – the format of the List, and how to represent the access levels.

We talked over a number of options for the list format.

Initially we were thinking of a DSTU-2 style operation to allow for different query parameters and back-end processing – but after some discussion this seemed overkill, and also we preferred to use DSTU-1 at this stage, as that is what the other FHIR initiatives in Orion Health are using – and consistency across the organization is important (especially as we are using the HAPI library to handle the manipulation of resources).

Eventually we settled on the Group resource. From the spec: “To define a group of specific people, animals, devices, etc. that is being tracked, examined or otherwise referenced as part of healthcare-related activities” so that seemed ideal. We can use the identifier property to identify the specific pathway that we want to list the patients on, and the type property to indicate that we are expecting Patient resources in the list.

So now for the ‘security’ aspects of the list.

What this requires is that the server, when processing the query will need to perform the following actions:

1. Retrieve the list of patients from the pathway.
2. For each patient in the list, call the internal privacy service to determine the level of access of the user making the query (naturally it will be an authenticated user). Depending on the access level, then the server will place the appropriate annotation in the list so the client can render the UI.

There a quirk though – If the user is unable to access a patient – but is allowed to know that they are on the list then that is just another annotation – but what to do if they aren’t even allowed to know? Maybe the patient is a VIP of some sort? We should let the client know that the list is incomplete, but no more than that. In the end we decided that an OperationOutcome resource in the returned bundle would be the best approach – and we can add an extension to the type property (of datatype CodeableConcept) that indicates the reason why the list is incomplete (and we’ll create a ValueSet that has the list of possible values, with a Profile connecting the two).

So how do we do the annotation? Well, that seems a good fit with the tags ability of FHIR. All we need to do is place the appropriate tag against each patient and we’re done. Initially we looked at the defined security labels (which are a specific type of tag), but after some discussion on the skype implementers chat we decided that this wasn’t the best fit. We were wanting to indicate the outcome of privacy processing rather than attributes of a resource that would be the inputs into such a decision so the fit wasn’t really all that good. We decided to use a custom set of tags with a ValueSet that lists the possible values for the tags.

So there you have it.

The query (which would be made by an authenticated user) will look something like:

[server]/Group?identifier={pathway}&...

The response will be a bundle that contains:

• A Group resource representing the pathway group. We may add extensions to this resource if there’s more we want to tell the client about the pathway, though we do have the text property if we just want to display text to the user.
• Zero or more Patient resources, each patient being referenced by the member property of the Group. Note that the client didn’t need to tell the server to include the Patient resources – the server is allowed to add other resources as it sees fit, though it can also respond to an _include request if it has the functionality.
• Similarly there may be some Practitioner resources from the Patient.careProvider property
• Each patient will have one of our custom tags to indicate the action the user will need to take if they select that patient (obviously security will be applied when the patient is selected – not when the list is generated!). Of course, if this service is consumed by a client that doesn’t understand our tags then no harm has been done – the security will still be applied when the patient is selected regardless.
• An optional OperationOutcome resource – at this stage only when the list is incomplete, but we could use it in any other situation when we want to notify the user of something.

We should also create a profile that describes this service, binds the various ValueSets to the coded properties, and includes the definitions of the extensions as well. Perhaps a topic for another post!

It also raises questions about whether every internal ‘end point’ that is FHIR related should have a Conformance resource exposed by it (I suspect that the answer is yes, as it helps with documentation if nothing else).