FHIR Artifacts > Structure Definition: DocumentReference Profile
Structure Definition: DocumentReference Profile
Canonical URL:http://ehealthontario.ca/fhir/StructureDefinition/ca-on-eReferral-profile-DocumentReference
Simplifier project page:
Derived from: DocumentReference (R4)
Formal Views of Profile Content
Description of Profiles, Differentials, Snapshots and how the different presentations work
Differential View
Hybrid View
Snapshot View
Table View
JSON View
Usage
The primary use of the DocumentReference in this IG is to exchange binary .content
(attachments to ServiceRequests) in DirectMessaging integrations.
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 further background and discussion about potential approaches see: https://infocentral.infoway-inforoute.ca/en/resources/docs/3551-documentreference/view-document
Notes
.id
- used to uniquely identify the resource
- if a persistent identity for the resource is not available to use when constructing a message Bundle for transmission via Direct Messaging, a UUID SHOULD be used in this element (with a corresponding value in
Bundle.entry.fullUrl
)
.meta.profile
- used to declare conformance to this profile
- populate with a fixed value:
http://ehealthontario.ca/fhir/StructureDefinition/ca-on-eReferral-profile-DocumentReference|1.0.0
.identifier
- business identifier(s)
.status
- populate with a fixed value "current"
.subject
- MAY be used to associate the DocumentReference with the Patient it is about
- where
.subject
is populated, it SHALL reference the same Patient resource asServiceRequest.subject
- for DirectMessaging integrations, the Patient resource SHALL be included in the message as a
Bundle.entry
and, if a persistent resource is available, MAY also be resolvable at a RESTful FHIR endpoint
.date
- populate with the instant in time when the DocumentReference was created for transmission to the recipient
- format: YYYY-MM-DDThh:mm:ss.sss+zz:zz (e.g. 2015-02-07T13:28:17.239+02:00 or 2017-01-01T00:00:00Z).
.content.attachment
- this is the document referenced
- implementers SHOULD use
.content.attachment.url
to enable the recipient to securely retrieve a binary attachment after the message is received instead of passing large documents as base64.content.attachment.data
- for further background and discussion about potential approaches see: https://infocentral.infoway-inforoute.ca/en/resources/docs/3551-documentreference/view-document