In conjunction with the Patient Care workgroup, we’re currently working on the ReferralRequest Resource. You can see a draft here, and the here is the resource request (but do be aware that it is very much a work in progress, and WILL change prior to appearing in the next DSTU).
Referrals are one of the most interesting (and contentious) aspects of the ‘art of medicine’ – particularly in this era of increasing ‘shared care’ where many providers (clinical and other) are going to be involved in a patients care.
After some discussion in the group, we decided to create a single resource that would cover off both:
- The ‘Transfer of care’ scenario where a provider assumes (or has completed) care of a patient. An example of this being the Discharge Summary.
- The ‘Referral’ scenario where the care is only for an aspect of the patients health – for example a referral for consideration of hip replacement, or on-going management of their diabetes.
There’s a property (ReferralRequest.type) which can be used to specify what ‘sort’ of ReferralRequest this is – we’ll need to define the common types in a ValueSet I suspect, unless there is already a list we can use.
There’s also the question of whether a patient can be an initiator of a referral (the so-called ‘self-referral’) – I suspect there will be a fair bit of discussion about that!
(This is a very simplified description so please don’t flame me!)
What’s especially interesting from a FHIR perspective, is that a ReferralRequest is very unlikely to be used alone – at least there will likely be an Order resource to manage the workflow aspects, and almost always there will be supporting information that needs to be a part of the referral (for example it’s unusual not to include the patients Usual Medications in clinician to clinician ReferralRequests).
You could imagine that there are 2 parts to a ReferralRequest (I admit I stole this idea from Grahame):
- The focus of the referral – what, why and when – that is in the ReferralRequest resource
- The context of the patients health and other events/plans that are in play.
We also need to think about how ReferralRequests will operate in all the paradigms that FHIR supports (Messaging, REST, Documents and Services).
And for a particular implementation we also need to take account of the environment – eg
- Is this within or between facilities
- Is there some shared source of data that we can just reference, or do we need to include that in the ReferralRequest package (eg if there’s a single source of medications that both sender and recipient use, then we don’t even need to include that – the recipient will just look it up when they need to).
- Are there local policies we must adhere to?
So what are the resources that we need to think about? Well:
- The ReferralRequest will have the details of this particular request – what is the reason, whats expected to be done, urgency, dates etc.
- The Order & OrderResponse resources that track the workflow around the request – ie that this an action that should be performed, and what happens over the course of the request. Aspects of this will be reflected in the status of the ReferralRequest.
- The Composition is about documents and rendering
- We’re bound to need a List
- Other clinical and administrative resources are required (Patient, Practitioner, MedicationPrescription, AllergyIntolerance) and so forth.
With that as background, let’s think about this might work in a couple of scenarios:
- One scenario being a RESTful ReferralRequest within a facility where all the information is stored in one place (eg the medication list is in a single source of truth) – maybe there’s a single EMR
- Another scenario being between facilities – perhaps a GP (Ambulatory Care) to a hospital where the data is completely separate. We’ll use a Document for this.
The first scenario is quite straightforward, as the ‘context’ part of the patients record is in a known place, and accessible to the recipient, so all we need to do is to create a ReferralRequest resource with the what/why/when, and then create an Order resource that refers to that ReferralRequest. We might choose to use the ReferralRequest.supportingInformation to refer to the context data (as it was when the ReferralRequest was generated) – or not, depending on the circumstances.
The Order is the part that will ‘show up’ in the recipients ‘inbox’ or ‘Referral Management Solution’, and will track the overall processing of the ReferralRequest. (Though, on reflection, we may want some extensions on ReferralRequest or Order for some of the facility-specific ‘status-es’ (e.g. triaged, appointment made, for investigations etc.)
The next scenario is a bit harder – and closer to what exists in many jurisdictions today. Because there is no common source of context information, we really have no option other than to include all the relevant information in the ‘package’. We’re going to use a Document, but the same arguments apply to a Message or a Service.
The diagram below shows how we could structure our document.
It looks complex, but it’s not really that bad – many resources are referenced from both Composition and ReferralRequest (but it’s just a reference). The right hand side is the clinical stuff, and the left the admin stuff (kind of like CDA!). In effect we’re using the Composition to determine the rendered output of the ReferralRequest, while still continuing to reference everything from the ReferralRequest as well.
One question that did come up when we were skyping about this was how to render the referral. When we use a document as the package, then that becomes a bit easier because there are rules about that. The first scenario is a bit more problematic, and I’m not sure there is a good answer yet.
So there you have it. Theses are only a couple of possibilities – and won’t suit all requirements, but hopefully food for thought.
Remember: this is a draft resource and WILL change prior to DSTU. The purpose of the post is to generate comments – either here or to the Patient Care list, whatever works for you.