Referral requests in FHIR

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.

referral

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.

 

 

About David Hay
I'm a Product Strategist at Orion Health, Chair emeritus of HL7 New Zealand and co-Chair of the FHIR Management Group. I have a keen interest in health IT, especially health interoperability with HL7 and the new FHIR standard.

5 Responses to Referral requests in FHIR

  1. Dunmail says:

    We’ve seen a couple of use-cases where a third party exposes their appointment book, so that the referral process includes appointment booking information. In FHIR terms this could be captured via Order.schedule, but it may be advantageous to include Appointment/Slot as part of the data flow.

  2. Your HISO's on FHIR says:

    Referral request will be a powerful resource. But it may be tricky to pin down the details. How should a request be expressed? And what form should the response take? I’ve seen referral systems that comprise a (coded) presenting complaint, a narrative enquiry and a code indicating whether this is a request for advice, assessment, treatment etc, which is a fairly simple approach. But we need something more sophisticated.

    • David Hay says:

      Indeed it will be!

      And now is the time to raise these requirements while the resource is still being developed, so any feedback is welcome! For example to pick up on the points you raise:

      The reason for request is a codeableconcept (backed up by a description) so should cover the coded aspect. The ReferralRequest.type should support the “request for advice / treatment/ assessment” etc.

      The response is a good question. At first I thought the OrderResponse might do it, but that explicitly excludes “information arising from performing the order”. Maybe we need a ReferralResponse resource as well? Or, we just use existing (or planned) resources like Observation,Appointment & Assessment, and the OrderResponse just references them (sounds like a better approach actually)

      keep the comments (and use cases) coming!

      cheers…

  3. Kieran Holland says:

    Hi David

    Thanks for the overview.

    In the public sector, provision of advice is increasingly a core aspect of referral due to resource constraints. Some services manage 25-50% of requests with advice. In many cases the initiating event is not a request for advice but a request for transfer of care converted to provision of advice. In these cases referral becomes a dialogue:

    • Will you see this patient because…
    • No, we don’t have capacity, try this treatment…
    • OK we tried that, but this happened…
    • OK try this…
    • OK that didn’t work either…
    • OK we will see the patient…

    One of the key benefits of eReferral is enabling shared care through provision of advice as highlighted in Dianne Davis’s paper:

    http://www.hinz.org.nz/uploads/file/2013conference/Electronic%20Triage%20-%20Davis.pdf

    This scenario is touched on in the draft resource under ‘Request for more information’ however I believe needs to be identified as a primary use case, rather than an exception.

    Some may argue that dialogues should happen elsewhere however the referrer would then need to realise in advance that they are about to enter a dialogue…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: