Stream: implementers
Topic: ProcedureRequest and DiagnosticRequest
Eric Haas (Jan 09 2017 at 16:43):
This GF#11119 tracker is comparing and contrasting ProcedureRequest and DiagnosticRequest - they are structurally nearly identical in STU3 and as we explain here lots of overlap in usage. We are wondering if there is a case for combining Diagnosticrequest and ProcedureRequest? What is the case for keeping them separated?
Lloyd McKenzie (Jan 09 2017 at 22:58):
Do existing systems currently track these separately - and are they consistent in the boundaries they draw between the two types? That should be the primary driver
Grahame Grieve (Jan 10 2017 at 01:30):
i think they're different because a diagnostic request is actually asking for an outcome - that a diagnostic report be produced. What procedures need to happen varies. Specimen collection, for instance
Michelle (Moseman) Miller (Jan 10 2017 at 02:12):
In our system, these are both tracked as orders. The FHIR boundaries have already caused us some headaches when we tried to use the order catalog to infer the boundaries, which we quickly learned doesn't work well. From my notes, the following are example order catalog types that might have a mix of diagnostic and non-diagnostic orders, thereby making the identification of which subset to expose as DiagnosticRequest more challenging.
- Women's Services -- radiology tests (diagnostic) as well as orders to check dilation (non-diagnostic)
- RT -- pulmonary function test (diagnostic) and orders to change ventilator settings (non-diagnostic)
Grahame Grieve (Jan 10 2017 at 02:28):
does that raise a wider issue about mixed composite orders?
Lloyd McKenzie (Jan 10 2017 at 02:35):
At the moment, composite orders are expected to be treated as independent orders grouped either by requisition id or as sub-tasks of a common task
Eric Haas (Jan 10 2017 at 02:47):
Isn't the outcome determined by the Task? I don't really understand what is meant by asking for a outcome and how that would differentiate them. A ProcedureRequest for a Specimen draw would be asking for a Specimen. Or an ProcedureRequest for an upper GI scoping would result in a report as well. Isnt that the same thing. was thinking more along the lines of Lloyd's point. Are these handled separately already?
Lloyd McKenzie (Jan 10 2017 at 03:00):
All orders have an outcome. The main difference is that DiagnosticRequest have a primary outcome that is informational while ProcedureRequests have a primary outcome that is a modification of the subject. So I would say that an order to check dilation would be diagnostic - you get back a value. Agree that an order to change ventilator settings would result in a Procedure.
Stephen Chu (Jan 10 2017 at 04:50):
There are semantic and structural differences between the two.
Semantically and outcome perspective:-
Diagnostic procedures are done to detect and diagnose. They may or may not result in change in the patient/subject.
Colonoscopy without biopsy - no change; colonoscopy with biopsy - results in change
Intervention/therapeutic procedures are intended to produce therapeutic effect, whether that is behavioral or physical - results in change
Structurally:
Diagnostic procedure - requires structure to support specimen collection and details
Intervention/therapeutic procedure - does not involve specimen collection
Stephen Chu (Jan 10 2017 at 05:39):
BTW, there are a number of inconsistencies between the two resources that will need to be resolved, examples:
DiagnosticRequest.context and ProcedureRequest.encounter
DiagnosticRequest.occurrence[x] and ProcedureRequest.schedule[x]
DiagnosticRequest.authoredOn and ProcedureRequest.orderedOn
DiagnosticRequest.request and ProcedureRequest.order
DiagnosticRequest.reasonCode .reasonReference and ProcedureRequest.reason[x] (reasonCodeableConcept | reasonReference)
Grahame Grieve (Jan 10 2017 at 06:21):
most of those differences probably need to be reslved anyway
Eric Haas (Jan 10 2017 at 18:18):
Still, in my mind the big question is whether implementers are splitting these requests based on the semantic niceties that Stephen and Lloyd described. If not then I think we should consider combining them.
Grahame Grieve (Jan 10 2017 at 20:13):
a DiagnosticRequest is fulfilled by the provision of a DiagnosticReport. various procedures may or may not be required to get to that point
A ProcedureRequest is filfulled by carrying out a procedure. is there intended/required to be a record of fulfillment?
Grahame Grieve (Jan 10 2017 at 20:15):
all institutions I've worked with have different forms for diagnostic and procedure and supply requests....
Michelle (Moseman) Miller (Jan 11 2017 at 13:59):
I agree with you, @Grahame Grieve , that the "forms" are not the same. That said, let me reconcile that statement with my prior comments.
The "forms" for entering and modifying diagnostic request and procedure request orders differ in our system, too. However, there isn't a single "form" for all diagnostic requests and a single "form" for all procedure requests. The "forms" will flex depending on a variety of variables (e.g. orderable, user placing the order, location, encounter type, etc.). Despite the variances in what is visually shown to the end user, the backend persists all orders (medications, too) in a generic orders schema (i.e. abstracting each attribute/element within the form to be an "order detail"). We are able to differentiate medication requests because they all share the same pharmacy order catalog type. However, that methodology doesn't work to identify diagnostic requests as my prior examples illustrated.
Last updated: Apr 12 2022 at 19:14 UTC
