Clinical Order Workflows
1.0.0-ballot - STU 1 Ballot International flag

This page is part of the Clinical Order Workflows (v1.0.0-ballot: STU 1 Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. No current official version has been published yet. For a full list of available versions, see the Directory of published versions

Sharing Outputs from an Order or Referral

Page standards status: Informative

Many types of referrals and orders will involve the creation of output resources, either as a final product or as part of an intermediate workflow step. This could include a results report, individual observations, a proposed plan of care, a consult note, etc.

This section provides basic guidance for how these outputs may be communicated between the Fulfiller and the Placer.

Generally, the creator of an output will make a resource representing that output available on their FHIR server and provide a reference in the shared Coordination Task's Task.output, wherever that coordinating Task is hosted.

Placers may choose to create their own local representation of that content, and additionally, to host their own copy of that content on their own FHIR server so that its information is discoverable for others involved in a patient's care. Provenance FHIR resources MAY be used to indicate that the originator of the latest version of the Output is the owner, though note that many Event resources will already implicitly indicate their source (such as in DiagnosticReport.performer and .resultsInterpreter).

Preliminary Results, Addenda, and Updates with FHIR Servers

In some contexts, a partial result may be shared from one system to another, or a later actor in the chain of care may decide to modify an earlier result. When this occurs, the actor may do so by updating their local representation of the earlier output, updating their FHIR resources for that content, and updating the Provenance, if recorded, to indicate that they are now the source of truth. The actor may notify others in the chain of the update based on their business agreements and using mechanisms described in this guide.

For example - that update may be communicated with a Message that's been pre-defined to indicate a correction or update, or the originator of the Output document may receive a SubscriptionStatus notification that a copy of their document has been modified and should now be seen as the source of Truth. In that case, they SHOULD update their local copy and any provenance as needed.

PlacerPlacerFulfillerFulfillerIf Fulfiller creating an output1Performs Service, creates output2Updates Task.output to reference the output3Update Task and Service Request.status == CompletedInterim statuses are also possible if a placer needs to review the outcome beforeconfirming the service is complete (like deciding whether to continue therapy).Optionally - if Placer needs to be able to surface or modify that outcome in future4Read Output5Save a copy. MAY update Provenance.location to indicate the Fulfiller as the source of truthThe DocumentReference, DiagnosticReport etc. can also point back to the Request on the Placer's systemIf Placer may later addend that output:6Placer and Fulfiller coordinate how to share updates, such as a Subscription