Stream: implementers
Topic: Referrer's referral requirements
Dave Barnet (May 26 2021 at 13:45):
We are looking to implement a booking and referral system whereby when making a referral, the "referred to" endpoint can say what information they require to enable the referral. So if Organization A referrs to Oragnization B, then B says "yes that's OK if you send me this information to enable the referral". The type of information required will vary depending on where the patient is being referred to. We are intending to specify the information that is required for a referral on a CapabilityStatement (type=requirements) and using the CapabilityStatement to list the profiles that are required for the referral.
Has anyone done anything similar? Does this sound like a good idea?
Kevin Mayfield (May 26 2021 at 15:11):
I think we will end up with a series of Questionnaires which list a basic list of questions/data items (or something similar). Ideally organisation wide with Questionnaire A to be used by specialty or service X, Y and Z.
Using profiles seems a bit STU3 to me.
Lloyd McKenzie (May 26 2021 at 15:34):
- I would not recommend using CapabilityStatement to reflect what's desired. CapabilityStatement is about defining what behavior a system must have the capability to support, not to request specific information.
- I would not recommend describing what information that you want as profiles. Most systems aren't able to retrieve information by profile. Also, profiles don't necessarily allow filtering of the subset of information that you want back.
- Usually, requests for information should expressed as queries - that allows you to specify the desired resource and any filters on it - and aligns with how systems typically know how to find information. By default, you'll get back the intersection of what the system is capable of returning and what you have permission to see. You have no hope of getting more than that, regardless of what profile you want, nor do you have a hope of getting systems to organize the data in the way you might like it to be. The most you can do is enumerate the specific elements you want (using _elements) and having the sender filter out everything else.
- If you have the ability to query directly, just do that. If you don't, I'd encourage you to look at the CDex Task-based mechanism for soliciting additional information. Your 'request for information' would have a 'partOf' relationship to the original 'please fulfill' Task for the referral (establishing context) and would specify the query you want executed. The placing system could then return the desired information as an output of the Task.
Kevin Mayfield (May 27 2021 at 05:23):
I think this needs to be atomic and include existing behaviour which is probably either:
- faxed referral letter
- emailed referral letter
- using V3 ERS (includes appointment scheduling and a referral letter)
So roughly we have
- Referral metadata (FHIR Service Request)
- a letter which is either a form or a letter
- attachments
- (RESTful) scheduling
Stage 1 is probably a FHIR referral Message with attachments (referral letter and attachments). Including rejections and updates.
Main aim is to introduce a referral/handover mechanism which is focused on the health admin side (to replace fax and email). The attachments are purposely decoupled from health admin.
Stage one is strategic, it's introducing a nuts and bolts standard. The decoulping allows changes
- ServiceRequest can be supplemented with Task and probably linked to CarePlan.
- supportingInfo/attachments can be enhanced to include Questionnaire, FHIR Documents, etc
Of these I think Questionnaire or FHIR Documents is probably the next stage. PRSB will favour FHIR Docs, suppliers may go for Questionnaires, techs may go for a query approach. Don't believe we have to decide early on.
Kevin Mayfield (May 27 2021 at 05:34):
I do like @Lloyd McKenzie suggestion. This would be to move from the placer sending the letter and detailed clinical information to a more restful solution which avoids sending detailed clinical information.
The placer (& EHR) still sends the serviceRequest + referral letter but the filler (/payer) looks up clinical information they need.
Kevin Mayfield (May 27 2021 at 05:38):
It avoids 'war and peace' referral documentation.
Last updated: Apr 12 2022 at 19:14 UTC
