Stream: implementers
Topic: Laboratory result
mohammad navab husain (Feb 13 2019 at 13:57):
Hi all,
We have used Diagnostic Report resource for capturing the Laboratory panels such as Urinalysis panel, CBC panel and etc.
Similarly we have used Observation resource for capturing Laboratory panel values and we have sliced the DiagnosticReport.result element which will captures the Laboratory values. Is this a right process or not?
Thank you,
Lloyd McKenzie (Feb 13 2019 at 16:20):
DiagnosticReport generally represents a full report from a lab - though it could be a component of a larger report (e.g. if part of a set of tests was delegated to another lab). Typically you'll have one DiagnosticReport for each order. Within a report, if you organize the results into sub-sections, that organization will be done using Observations that link to component Observations using the 'member' relationship.
Eric Haas (Feb 13 2019 at 17:16):
There is some variability in the laboratory community on how this is done. You order "Profiles" aka panel of panels and they could be represented in a single DiagnosticReport or as many bundled together. I would like to investigate this further in this cycle. @Andrea Pitkus, PhD, MLS(ASCP)CM is there any regs or best practices here?
Mark Kramer (Mar 18 2019 at 17:33):
Many LOINC panels contain other panels (examples: 24362-6, 57021-8). If you use DiagnosticReport to represent panels, you can't nest panels in panels. I've concluded you have to Observation for panels because that's the only way to properly nest panels in panels. This is not how US Core and Argonaut have done it, however. Comments?
Eric Haas (Mar 18 2019 at 18:52):
you are correct next level nesting is done in Observation and that is documented. Does not change the fact that the entry point for most labs is through a report. The standard is a reflection of that.
Mark Kramer (Mar 18 2019 at 19:14):
Unfortunately the "top level" in one case could be a sub-level in other cases. You don't know in advance what the "top level" is.
Grahame Grieve (Mar 18 2019 at 19:45):
why does it matter?
Grahame Grieve (Mar 18 2019 at 19:45):
it's a list of Observations in either case
Lloyd McKenzie (Mar 18 2019 at 19:46):
@Eric Haas How do you handle a situation where a diagnostic report incorporates a report from a downstream lab? My understanding was to use diagnosticReport-extends
Mark Kramer (Mar 18 2019 at 19:50):
It matters because if I model a panel as a diagnostic report, it can't be included in a diagnostic report. You get into the situation where the same panel has to be modeled twice, once as an Observation with members because it is part of another panel, and once as a DiagnosticReport because it can be delivered as a top-level report. That would be evil.
Grahame Grieve (Mar 18 2019 at 19:51):
would it? what's a panel? A code, and a list of observations with codes. yes?
Mark Kramer (Mar 18 2019 at 19:52):
A panel is a list of observations, yes.
Grahame Grieve (Mar 18 2019 at 19:57):
so it's a list of observations either way...
Mark Kramer (Mar 18 2019 at 19:58):
To be exact, it is a list of observations and lists of observations.
Eric Haas (Mar 18 2019 at 19:58):
depends what is it is. if it is a pdf --> presentedForm.
the extends extension was created with AP in mind but I agree it could be in this use case as well. This is a good question and would like to see some more examples.
Rob Hausam (Mar 18 2019 at 19:59):
I think it makes sense to model a panel as a list of Observations, and include that in a DiagnosticReport if that is what was ordered (or resulted).
Eric Haas (Mar 18 2019 at 19:59):
I think the order code is typically the top level
Grahame Grieve (Mar 18 2019 at 20:00):
not the order code in the report
Eric Haas (Mar 18 2019 at 20:00):
that is the entry point to the panels
Rob Hausam (Mar 18 2019 at 20:00):
I meant to add with a top level Observation for the panel
Eric Haas (Mar 18 2019 at 20:03):
You get into the situation where the same panel has to be modeled twice, once as an Observation with members because it is part of another panel, and once as a DiagnosticReport because it can be delivered as a top-level report.
Thats what happens in the real world.
Eric Haas (Mar 18 2019 at 20:03):
depends what is ordered a panel or panel of panels or which lab is doing it
mohammad navab husain (Mar 19 2019 at 13:31):
Hi all, we want to fix some observations to one DiagnosticReport which captures Lab Panel using DiagnosticReport.result element. How to do that? Can anyone suggest me.
Lloyd McKenzie (Mar 19 2019 at 15:18):
Can you explain what you mean by "fix some observations to one DiagnosticReport"?
mohammad navab husain (Mar 20 2019 at 05:00):
@Lloyd McKenzie We created a CBC panel using DiagnosticReport resource and added its values to DiagnosticReport.result element which will be the Observations. How to add those number of values?
Lloyd McKenzie (Mar 20 2019 at 05:33):
I'm still not following. You'll have one Observation for each finding within the panel. The values of each will be in the Observation.value. The DiagnosticReport will point to the URLs of the various Observations.
mohammad navab husain (Mar 20 2019 at 05:49):
In CBC panel Diagnostic report , We want to add multiple observations with its values like WBCs, RBC, Hb,Hgb, Hct, Platelets. We can add those observations to Diagnostic report result as references. We want to customize Diagnostic report as CBC panel Diagnostic report user can add only references of any one of selected codes of CBC panel observations.
Lloyd McKenzie (Mar 20 2019 at 05:50):
So you're wanting to create a 'profile' of DiagnosticReport and indicate what types of Observations the DiagnosticReport is allowed to point to? Have you looked at the http://hl7.org/fhir/profiling.html page?
mohammad navab husain (Mar 20 2019 at 05:55):
Yes. I have gone through the documentation.
mohammad navab husain (Mar 20 2019 at 06:05):
That's why we have sliced the DiagnosticReport.result element and added multiple observations. Can you tell me is this a right approach?
Lloyd McKenzie (Mar 20 2019 at 06:09):
Yes. Slicing the DiagnosticReport.result (likely by pattern by resolve().code) and having each point to a distinct Observation.profile each of which has a different different pattern declared for the Observation.code element is correct and appropriate.
mohammad navab husain (Mar 20 2019 at 06:14):
Okay @Lloyd McKenzie Thank you.
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Jun 11 2019 at 14:01):
@Eric Haas Thanks. late to party here. @mohammad navab husain
The performing laboratory determines the order (which would be represented in service request) and result(s) that are part of the order (panel, individual result, etc.) Orders may be 4 types (individual, panel, reflexive and profile/tiered). Profile and reflexive may have nesting such as in microbiology cultures, transfusion testing, and physician convenience orders. The nesting/grouping of orders can be met with Service Request type (original for top level, order for other orders/tiers.) @Lloyd McKenzie feel free to jump in from our workflow discussions.
The laboratory performing the testing reports both the order and results as there is important clinical and semantic context in each that go together (along with the specimen/specimen resource, but will skip that for now.)
For a CBC, it is an order (see the LOINC codes for CBC, as they are all listed as orders. all lab panels are naturally orders too. they may be nested or added on as part of a top medical/legal requisition such as susceptibility panel added onto each organism identified in a Culture.) The result components/observations of the CBC indicated above are the Hgb, HCT, RBC, WBC, Plt, etc. Each would have a numeric value and listed as individual observations in a Diagnostic Report Resource (which would be used anytime there is more than one observation/result reported.) A single Hgb request/order, can result in a single Hgb result/observation too.
The question highlights an important issue though, some implementers of the same types of data/same items may be using different resources (i.e. Hgb in Observation resource vs diagnostic report) . Both are currently valid, but if the community implements both ways, those performing queries will need to query for both resources as one lab may have results modeled one way and another the other way. Would be nice to recommend a single way forward to reduce variability and increase interoperability. (DR seems the way to go.)
Also the upcoming DR discussion will be valuable to work through these issues, and also the issue of report sections. In CG, and OO, especially with pathology and radiology reports, the Q&A/order and result pattern also exists. There are report sections currently used and addition of special stains in pathology or FISH testing, whereby these add on orders have their own defined result components which are reported back. They would fit into the "nesting" paradigm. A CBC could be included as part of a bone marrow biopsy path report, as it is important clinical information we often referenced (although some hematopathology labs may only reference key result parameters and not the whole report). Either way, FHIR needs to support the needs of daily patient care activities Haven't seen a CLIA compliant complex report implemented yet (if folks know of them, please share), but hopefully will over the next year or so as FHIR adoption continues to increase.
PS. also taking an individual result component out of context may result in a patient safety issue, depending on the lab result. (Some are fine, others not so much, which is another issue.)
Last updated: Apr 12 2022 at 19:14 UTC
