preBallot - The specification is currently in ballot review and subject to change. . . . For a full list of available versions, see the Directory of published versions
L1: 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.
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 | 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-request1 | 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-request1 | 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-request1 | Target System | Update Service Record by replacing resource(s) received |
Note:
- ServiceRequest is in focus when adding supporting information because
ServiceRequest.supportingInfowill 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.