DFT - The specification is currently in development and subject to change. For a full list of available versions, see the Directory of published versions

L1 + L2: Attaching Supporting Information

In eReferral and eConsult workflows a Service Request is typically accompanied by Supporting Information needed to support intake, triage or processing of a referral including pathway or destination specific referral forms, results of diagnostic tests, images, etc. It is recommended that implementers determine which method of document sharing will be used prior to integration.

Supporting information may be passed in different formats:

• structured data
  • commonly "form" data in the FHIR QuestionnaireResponse resource
  • less commonly, specific FHIR clinical, observation or medication resources specified outside of this FHIR IG
• binary attachments referenced in the FHIR DocumentReference resource

Within messages exchanged using FHIR messaging, FHIR resources containing Supporting Information are referenced from the ServiceRequest.supportingInfo element.

Exchanging Supporting Information

To support the electronic exchange of supporting information for a referral, the basic requirements are below.

A Source System claiming compliance with the eReC FHIR messaging:

• SHALL have the ability to send references to binary documents using DocumentReference resource (more information below)
• SHOULD have the ability to send structured form information using the questionaireResponse (this is a requirement is some jurisdictions)
  • for compatibility with other systems, it is recommended that structured form information also be passed in an unstructured format as a binary attachment and/or as free text ServiceRequest.note
• MAY have the ability to send structured clinical information using other FHIR resources, for compatibility with other
  • for compatibility with other systems, it is recommended that structured form information also be passed in an unstructured format as a binary attachment and/or within QuestionnaireResponse

A Target System claiming compliance with the eReC FHIR messaging:

• SHALL have the ability to receive references to binary documents using DocumentReference resource as well as to retrieve the referenced document (more information below)
• SHOULD have the ability to receive structured form information using the questionaireResponse (this is a requirement is some jurisdictions)

Trigger Events & Interactions

The table below illustrates real-life trigger events associated with the exchange of supporting information with a referral with the specific event codes within the FHIR message. This list is not intended to be exhaustive.

Party	Action / Trigger	Sending System	Focus of Message	State Change	Event Code	Receiving System	Expected action upon receipt of message
Requester HCP	Creates and submits a request	Source System	ServiceRequest (CA:eReC)	request activated	add-service-request (L1)	Target System	Create a Service Record for the request and initiate processing
Requester HCP	Adds additional supporting info (binary or structured)	Source System	ServiceRequest (CA:eReC)	record updated	notify-update-service-request (L2)	Target System	Update Service Record by adding additional resource(s) received
Requester HCP	Changes content of binary attachment	Source System	DocumentReference (CA:eReC)	record updated	notify-update-service-request (L2)	Target System	Update Service Record by replacing resource(s) received
Requester HCP	Changes content in structured form	Source System	QuestionnaireResponse (CA:eReC)	record updated	notify-update-service-request (L2)	Target System	Update Service Record by replacing resource(s) received

Note:

• ServiceRequest is in focus when adding supporting information because ServiceRequest.supportingInfo will be updated to contain the additional reference
• when a binary attachment is updated, the DocumentReference .date and .content.attachment will be updated

Exchanging Binary Documents

In the referral workflow multiple, large binary files could potentially be referenced as ServiceRequest.supportingInfo.

To reduce message size, message performance and scalability, implementers are strongly recommended to use .content.attachment.url to enable asyncronous retrieval of binary attachments from a secure server instead of passing attachments within a message as base64 .content.attachment.data.

For future version, add information about patterns used to provide access to referenced attachments.

---