eReferral Spec Development work stream

Thanks for your feedback and thoughts on that, Tim. That is helpful.

If there isn't currently a spot for Received Date, another thought, along with the possibility of adding to Task, is to possibly add Received Date as an extension to Service Request. It looks like there are some other Wait Time concepts that have been added as extensions there, i.e. DARC and DART.

Interesting. My first thought was to use the "authored on" field in the service request, but that doesn't seem to quite fit your use case.

Instead, this is a "task" concept about when the receiving system into or past one of the statuses that represent your concept of received.

I think that this would require an extension on the Task resource.

I have been looking through general FHIR profiles as well as the latest Ontario eReferral FHIR Implementation Guide, and I am wondering if anyone has encountered the scenario of how to represent the Received Date of a ServiceRequest (i.e. referral)?

The Received Date is a business concept and more than just an electronic timestamp of when the ServiceRequest was received. There are several use cases for the Received Date - it can be the received date stamped on a referral letter, a timestamp on a faxed referral or it could also be when the Referral Management System electronically received the ServiceRequest. For the first examples, the Received Date can be manually entered and also updated later on if it was entered in error. This timestamp is critical for calculating wait times.

After the ServiceRequest has been received, how is this Received Date communicated back to the referring provider or to other systems that care to know this important date in the referral journey? Could it be sent in the Task profile as it does represent a business action that is taken after receipt of the ServiceRequest to timestamp when the referral was received. The task can be completed by either a user or the system.

Hi Tim,

The quotation of the previous content is:
Discussion 2: extending identifier element, to allow for multiple identifiers.
- TODO: Radhika to draft extension, share with group and also discuss on chat.fhir.org because it may be eligible to be a standard extension. It was an oversight originally not to make referenced identifiers able to have many - but now is normative.

To conform with the constrain, one complex extension has been created to demo the implementation of the request.


Best Regards,
Thomas Zhou


<!-- Start of the demo extension of reference.identifier -->
<?xml version="1.0" encoding="utf-8"?>
<StructureDefinition xmlns="hl7.org/fhir">
<url value="example.org/fhir/StructureDefinition/performer.identifier" />
<name value="Pidentifier" />
<status value="active" />
<fhirVersion value="4.0.1" />
<kind value="complex-type" />
<abstract value="false" />
<context>
<type value="element" />
<expression value="ServiceRequest.performer.identifier" />
</context>
<type value="Extension" />
<baseDefinition value="hl7.org/fhir/StructureDefinition/Extension" />
<derivation value="constraint" />
<differential>
<element id="Extension">
<path value="Extension" />
<max value="1" />
</element>
<element id="Extension.extension">
<path value="Extension.extension" />
<slicing>
<discriminator>
<type value="value" />
<path value="url" />
</discriminator>
<rules value="open" />
</slicing>
<min value="0" />
</element>
<element id="Extension.extension:Pidentifier">
<path value="Extension.extension" />
<sliceName value="Pidentifier" />
<sliceIsConstraining value="false" />
<min value="0" />
</element>
<element id="Extension.extension:Pidentifier.url">
<path value="Extension.extension.url" />
<fixedUri value="Pidentifier" />
</element>
<element id="Extension.extension:Pidentifier.value[x]">
<path value="Extension.extension.value[x]" />
<label value="Instance of Pidentifier" />
<short value="Value of extension:Pidentifier" />
<type>
<code value="Identifier" />
</type>
</element>
<element id="Extension.url">
<path value="Extension.url" />
<fixedUri value="example.org/fhir/StructureDefinition/performer.identifier" />
</element>
<element id="Extension.value[x]">
<path value="Extension.value[x]" />
<max value="0" />
</element>
</differential>
</StructureDefinition>
<!-- End of the demo extension of reference.identifier -->

Notes for FHIR eReferal Meeting - Dec 7 2021
========================================

Discussion 1: ValueSets
- Radhika walked us through a number of changes to value sets for which everybody was in agreement. 

- TODO: The main item of interest was for contact relationship - which was inspired by CHRIS, needed to ensure that: a) any values that match the existing extensible value set use the original codes, b) extend any additional values

Discussion 2: extending identifier element, to allow for multiple identifiers.
- TODO: Radhika to draft extension, share with group and also discuss on chat.fhir.org because it may be eligible to be a standard extension. It was an oversight originally not to make referenced identifiers able to have many - but now is normative.

Discussion 3: Forwarding
- There's some commentary in the iGuide in the Business Context > Business rules > Chaining & Branching Referrals section, section, as well as in the technical specifications > direct messaging > branching and/or chaining requests.
- Summary of iGuide: Create a new ServiceRequest that uses the .basedOn field to point to the original ServiceRequest. The messageHeader.focus should point to the forwarded referral and not the original one.
- TODO: The text in these sections doesn't reference how the MessageHeader should behave, so there's an improvement there to be made.
- TODO: Indicate that should include the original ServiceRequest in the bundle.
- TODO: One interesting thing to ponder is if you send them with a shared Patient resource between both ServiceRequests ... I suggest that using the same or distinct resources would probably both be fine as an approach.
- Ocean uses ServiceRequest.reasonCode to indicate what a serviceRequest was sent or updated. This overlaps a little bit with messageHeader.event, but works here too.
- TODO: Determine standardized reasonCodes. A sample set of reasonCodes used is listed at the bottom of this message
- TODO: Determine if REQUESTER should change between initial and second referral.
- Case for YES: A central intake that does meaningful processing of the referral, like an intake, want to track who did that work. The original requester could always be found in the original serviceRequest
- Case for NO: simple cases when the person in the middle isn’t really doing any meaningful processes (or perhaps it’s an algorithm)
- What we're really talking about here is a "CC" function, where you notify somebody with updates abut the referral
- TODO: (Jon F) Write an extension example in the ServiceRequest for CC'ing updates.
- Minor concern: with two serviceRequests, gets a bit bulky (but, leaves the case to be more flexible)
- Minor concern: Different IDs for the two serviceRequests even through you can think of them as the same thing
- TODO:


SAMPLE LIST OF ServiceRequest.reasoncode

public enum ChangeType {
STATUS_UPDATED,
CANCELED,
COMPLETED,
RESUBMITTED,
MESSAGE_ADDED,
MESSAGE_DELETED,
MESSAGE_REVIEWED,
EVENT_LOGGED,
REFERRAL_NOTE_EDITED,
CC_LIST_EDITED,
DEMOGRAPHICS_UPDATED,
REFERRER_UPDATED,
HEALTH_SERVICE_REASSIGNED,
APPOINTMENTS_UPDATED,
CHILD_REFERRAL_ADDED,
REVIEW_NOTE_SAVED,
BOOKING_COMMENTS_UPDATED,
BOOKING_FILES_UPDATED,
REFERRAL_SPLIT,
REFERRAL_FORWARD
}

Notes for FHIR eReferal Meeting - Aug 17 2021
========================================

1. chat.fhir.org Canadian eReferral group spaces
- eReferral: chat.fhir.org/#narrow/stream/279576-Canadian-eReferral)
- HealthcareService: chat.fhir.org/#narrow/stream/257492-Canadian-HealthcareService.20Directory
- to find the streams, click on the "+" beside streams, then search "Canadian to find all the relevant Canadian streams and subscribe to them.

2. Collaboration with eConsult
- Still in preliminary investigation at Ontario Health

3. GET Operations
- Preliminary discussion on how to introduce some RESTful elements to eReferral (in particular GET, _include, _revinclude, search by _lastUpdated, etc...)


Next meeting:
--> go over FHIR APIs and how related to Canadian eReferal Guide. (Ocean + Caredove + CHRIS? + Others?)
--> Next Meeting Radhika to organize a little presentation on process differences between eReferral & eConsult