Loading...

XML

Word

Printable

JSON

Specification:

US Post Acute Orders (FHIR)
Raised in Version:

0.3.0
Work Group:

Orders & Observations
Related URL:
http://hl7.org/fhir/us/dme-orders/2020Sep/restful_fhir_exchanges.html
Related Page(s):

(NA)
Related Section(s):
Both Flow Diagrams
Grouping:
- Block-Vote-5
Resolution Description:

Hide

Clarify the situations that may exist when updates occur to the Task and/or Orders (e.g. ServiceRequest, MedicationRequest, DeviceRequest) need to use the business status (need to clarify / define the exact values) and reason for change to indicate what needs to be done (such as retrieve orders and determine the specific updates that have been requested).

Indicate which task statuses prohibit further updates. (cancel, completed)

Show
Clarify the situations that may exist when updates occur to the Task and/or Orders (e.g. ServiceRequest, MedicationRequest, DeviceRequest) need to use the business status (need to clarify / define the exact values) and reason for change to indicate what needs to be done (such as retrieve orders and determine the specific updates that have been requested). Indicate which task statuses prohibit further updates. (cancel, completed)
Resolution Vote:
Bob Dieterle / Marti Velezis : 4-0-8
Change Category:
Clarification
Change Impact:
Compatible, substantive

Possible synch conflics when "Ordering Provider System" updates the task.

The Rendering provider can update the task while the Ordering provider is sending the updated task.

I suggest the ordering provider sending a new task to cancel, or update the task. See more info at https://www.hl7.org/fhir/workflow-ad-hoc.html item 12.7.6.4

In both diagrams. In the first one is in "Get Task (to make sure we are acting on the most current information)".

is voted on by

BALLOT-13846 Negative - Ricardo Quintano : 2020-Sep-FHIR IG DME R1 STU