4.17 DiagnosticOrder リソース
Home ＞ Clinical ＞ DiagnosticOrder [diagnosticorder]
Resource DiagnosticOrder - Content4.17
A request for a diagnostic investigation service to be performed.
The resource name as it appears in a RESTful URL is [root]/diagnosticorder/
A Diagnostic Order is a record of a request for a set of diagnostic investigations to be performed. The investigation will lead to aDiagnostic Report that summarizes the outcome of the investigation, and includes any useful data and/or images that are relevant to the treatment/management of the subject.
The principal intention of the Diagnostic Order is to support ordering diagnostic investigations on patients (which includes non-human patients in veterinary medicine). However in many contexts, healthcare related processes include performing diagnostic investigations on groups of subjects, devices involved in the provision of healthcare, and even environmental locations such as ducts, bodies of water, etc. The Diagnostic Order supports all these usages.
The general work flow that this resource facilitates is that a clinical system creates a diagnostic order. The diagnostic order is then exchanged, perhaps via intermediaries, with a system that represents a diagnostic service that can perform the investigation as a request to do so. The diagnostic service will update the request as the work is performed, and then finally issue a report that references the requests that it fulfills.
Note that the Diagnostic Order itself is not a request to perform the investigation - it is just a record of the fact that a request was made. The Diagnostic Request must be paired with an Order resource to convey the actual instruction, or part of an explicit messaging or service workflow that carries the instruction.
Resource Content4.17.1
<DiagnosticOrder xmlns="http://hl7.org/fhir"> <!-- from Resource: extension, narrative, and contained --> <subject><!-- 1..1 Resource(Patient|Group|Location|Device) Who/what test is about --></subject> <orderer><!-- 0..1 Resource(Practitioner) Who ordered the test --></orderer> <identifier><!-- 0..* Identifier Identifiers assigned to this order --></identifier> <encounter><!-- 0..1 Resource(Encounter) The encounter that this diagnostic order is associated with --></encounter> <clinicalNotes value="[string]"/><!-- 0..1 Explanation/Justification for test --> <specimen><!-- 0..* Resource(Specimen) If the whole order relates to specific specimens --></specimen> <status value="[code]"/><!-- 0..1 requested | received | accepted | inprogress | review | complete | suspended | rejected | failed --> <priority value="[code]"/><!-- 0..1 normal | urgent | stat --> <event> <!-- 0..* A list of events of interest in the lifecycle --> <status value="[code]"/><!-- 1..1 requested | received | accepted | inprogress | review | complete | suspended | rejected | failed --> <date value="[dateTime]"/><!-- 1..1 The date at which the event happened --> <actor><!-- 0..1 Resource(Practitioner|Device) Who recorded or did this --></actor> </event> <item> <!-- 0..* The items the orderer requested --> <code><!-- 1..1 CodeableConcept Code for this item --></code> <specimen><!-- 0..* Resource(Specimen) If this item relates to specific specimens --></specimen> <bodySite><!-- 0..1 CodeableConcept Location of requested test (if applicable) --></bodySite> <status value="[code]"/><!-- 0..1 requested | received | accepted | inprogress | review | complete | suspended | rejected | failed --> <event><!-- 0..* Content as for DiagnosticOrder.event Events specific to this item --></event> </item> </DiagnosticOrder>
Alternate definitions: Schema/Schematron, Resource Profile
Terminology Bindings 4.17.1.1
Notes:4.17.2
- In normal practice, there would always be at least one item in a request (no point requesting nothing), but the minimum cardinality is 0 so that a workflow can quote order details (identifiers, requester) without having to list the items
- Typically the system placing the order sets the status to requested. There after, the order is maintained by the receiver that updates the status as the request is processed
- If the request has multiple items that have their own life cycles, then the items will have their own status while the overall diagnostic order is (usually) "in progress"
- The event list is not the same as an audit trail - it is a view of the important things that happened in the past. Typically, there would only be one entry for any given status, and systems may not record all the status events
- Many investigation requests will create a need for specimens, but in these cases, the request itself is not actually about the specimens. This specimen elements in this resource are provided for when the diagnostic investigation is requested on already existing specimens
- A single specimen should not appear in both DiagnosticOrder.specimen and DiagnosticOrder.item.specimen
- The clinical notes may be used to decide how the diagnostic investigation will be performed, or even if it will be performed at all
Search Parameters 4.17.3
Search Parameters for RESTful searches. The standard parameters also apply. See Searching for more information.