Stream: implementers
Topic: Bridging lab test request status valueset with custom values
frank cao (Dec 01 2021 at 20:41):
Hi, we are building a lab implementation with R4. The current lab solution uses v2 based values plus some custom values for test request status. When we try to map it to ServiceRequestStatus valueset, there are some gaps because the meanings are not well aligned. There is better alignment with DiagnosticReportStatus valueset, so we are thinking about creating an extension in ServiceRequest and use DiagnosticReportStatus values in it. We will create a mapping to map the solution values to DiagnosticReportStatus values. Is this a good design to solve our problem? Any suggestion is appreciated!!
Grahame Grieve (Dec 01 2021 at 23:19):
what are the values?
frank cao (Dec 02 2021 at 14:37):
These are the values used by the current solution for test request status:
A - Some, but not all, results available
C - Correction to results
E - Expired. Solution has expired the test request because no activity has occurred within a reasonable amount of time.
F- Final results; results stored and verified. Can only be changed with a corrected result.
I - No results available; specimen received, procedure incomplete. Use this code to indicate that a specimen has been collected.
O - Order received; specimen not yet received.
P - Preliminary: A verified early result is available, final results not yet obtained.
X - No results available; Order cancelled.
Lloyd McKenzie (Dec 02 2021 at 17:30):
A = preliminary or final?
C = corrected
E = cancelled
F = final
I = cancelled
O = registered
P = preliminary
X = cancelled
Having an extension to capture cancelation reason. Wasn't clear on whether A indicated that the Observation was 'complete' but didn't necessarily cover everything or was still in progress. If the former, then it'd be final (and you'd have member Observations that were 'cancelled' to indicate what wasn't done).
frank cao (Dec 02 2021 at 18:41):
Lloyd, based on your suggestion, are you saying that using an extension with reportStatus values is okay? The request status value in FHIR are "draft | active | on-hold | revoked | completed | entered-in-error | unknown". Since ServiceRequest status is mandatory, we want to use "unknown" and then ask implementer to use the value in the extension, is this reasonable?
We may not be able to support cancellation reason because we do not capture it in the solution.
Lloyd McKenzie (Dec 02 2021 at 20:32):
The statuses you're reflecting are statuses of results, not requests. The request is either 'active' or 'complete'. Details about what's happened with respect to fulfillment are not captured on the request. If you're tracking a specific fulfillment request, that can be done by Task, but even there, you've just got 'accepted', 'in-progress', 'complete' or 'failed'. Anything else could be conveyed in businessStatus.
If you're capturing 'expired' vs. 'no results' vs. 'order cancelled', then you're capturing 'reason' - you're just doing it as part of the status code.
Rita Pyle (Dec 03 2021 at 21:38):
In a Microbiology Result for example the Procedure Request would be for a Culture and Sensitivity .... Observations (results) would be posted against it - like a microscopic gram stain...like a colony count... like a organism ID, like sensitivity results - The status of the request depends on whether there are any results, whether there are some results (prelim or partial) -or whether all the results have been posted (final). - so really, in the labs we do need a status at the test request (procedure request) level to reflect whether the test is prelim, partial, interim, final, corrected, ammended, cancelled....and the Procedure Request Status required value sets (draft | active | on-hold | revoked | completed | entered-in-error | unknown") are just not semantically the same...which is why we want to use the FHIR Diagnostic Report Status values to status the Procedure Request.
We would also use the same values to status the Diagnostic Report (ie You could have ordered (Procedure Request) a PCR, Viral Culture, Bacterial Culture and Sensitivity on the same Requisition (Diagnostic Reqport ) - The Status of the Diagnostic report is determined by the statuses of the tests requested (procedure request) .... Hope that makes sense...
Lloyd McKenzie (Dec 03 2021 at 23:30):
Typically you'd have a DiagnosticReport or Observation representing the overall panel that corresponds to the ServiceRequest. That would reflect the overall status of the test. The status of the ServiceRequest itself doesn't change.
frank cao (Dec 06 2021 at 21:13):
The lab report in our solution is the primary entity so we want to map it to DiagnosticReport. If we map each OBR to a DiagnosticReport and we search multiple reports, implementers need to do more work to produce the report. I wonder if FHIR lab working group has any documented guidance on how to consistenly mapping lab information.
Lloyd McKenzie (Dec 07 2021 at 03:13):
Then Observation is probably best level - as a panel Observation. You can certainly ask on the #Orders and Observation WG stream (include a reference to this discussion when you post there)
frank cao (Dec 08 2021 at 14:22):
Thanks Lloyd. This is very helpful!
Last updated: Apr 12 2022 at 19:14 UTC
