Stream: Orders and Observation WG
Topic: Query intent of DiagnosticReport resource
David McKillop (Jul 13 2020 at 03:56):
Is the intention in the structure of the DiagnosticReport resource to semantically limit a single DiagnosticReport instance to reporting on a single orderable?
Subsequent questions:
- Can and should a single DiagnosticReport resource aggregate multiple panels/test groups?
- How desirable is it for the content of DiagnosticReport.code to relate to the content of that report?
Lloyd McKenzie (Jul 13 2020 at 04:04):
- It can. Whether that's acceptable or not may be driven by business rules/local regulation
- Don't understand the question. What would be the use-case for it to not relate to the content of the report?
David McKillop (Jul 13 2020 at 04:10):
@Lloyd McKenzie 1. thanks for the feedback.
- If a DiagnosticReport (DR) had an attached pdf report representing many orderables eg UE, LFT, Urate, Mg the DR.code becomes more "dilute" e.g "General Chemistry" rather than being a direct representation of the codes ordered.
Lloyd McKenzie (Jul 13 2020 at 04:12):
It's certainly possible for the code for the DiagnosticReport to differ from the code ordered - either being more generic or more specific (though presumably there should be some correlation).
David McKillop (Jul 13 2020 at 04:18):
OK - thanks. In the case of a report with UE, LFT, Urate, Mg the DR.code becomes nearly as generic as the DR.category.
With the following example of 3 different reports of a) UE, b) LFT and c) UE & LFT they would all have different DR.code. Is that an issue with systems searching or mapping content?
Lloyd McKenzie (Jul 13 2020 at 04:22):
@Eric Haas may be able to give a better answer to that than I can.
Grahame Grieve (Jul 13 2020 at 23:16):
the lab I used to work at would take a request for E&Us, LTF, Uric Acid, and Magnesium and return 2 Reports with category = biochem (I think that was OBR-22?) and codes of General Chemistry and Metal Ions. (I remember that we flipped on where Mg should be while I was there, but don't remember which way we flipped)
David McKillop (Jul 14 2020 at 01:42):
Thanks @Grahame Grieve .
Main question is "Has it been considered for DiagnosticReport.code to be [1..*] rather than [1..1]"?
Grahame Grieve (Jul 14 2020 at 07:34):
I haven't. what's the cardinality in v2?
Craig Newman (Jul 14 2020 at 19:59):
Assuming we equate a DiagnosticReport to the ORU message, OBR-4 is not allowed to repeat, but it being a CE or CWE data type (depending on version), you can have the code and an alternate code (and in CWE a second alternate code) for a total of 2 (or 3) codes. But typically, they are expected to all be equivalent codes from different systems (eg. LOINC and your lab's local code). So basically it seems like the equivalent of multiple codings in CoedableConcept
Angus Millar (Jul 15 2020 at 01:48):
I also work with @David McKillop and will give some more context. I feel the issue comes about between what are two different use cases. I will talk in terms of HL7v2 messages for now. First is sending atomic pathology reports to a system that can natively consume OBRs and OBX's and then rerenders those on-screen in some fashion. At a minimum, it can use the OBR-4 as the heading and display the OBXs under that OBR-4 heading. The other use case is sending pathology reports as PDFs or even just printing them to a page. Here we want to minimise the number of separate pages or PDFs in order to save the doctor's time in having to open many separate PDFs to see all the reports. Often it is clinically relevant and user friendly to print many reports on the same page with only a single patient banner at the top of each page.
The problem arises when these two use cases clash together in a HL7 v2 message, or in the FHIR DiagnosticReport resource. We now have a single PDF that holds many panels, how do we express the list of panels found in the single PDF. The problem is not new to FHIR the same problem is found in HL7v2, because OBR also has only one code allowed just as the code property of the FHIR's DiagnosticReport's does.
So the issue is, in a FHIR context, if the DiagnosticReport's presentedForm property (Entire report as issued) contains many reports, how do we then set the DiagnosticReport's code property. More so, how does a user searching for LFT find that LFT report hidden inside a PDF's that also contains other tests such as LFT, U&E and UricAcid? We have some ideas but are very keen to hear views of others.
Grahame Grieve (Jul 15 2020 at 01:50):
it's certainly not a use case in scope when we designed DiagnosticReport. I'm not sure it's a sensible thing to do either; it means that a doctor has to scroll through pages of stuff to find what she's looking for, and software can't help. Really, this sounds like a bad idea to me.
Grahame Grieve (Jul 15 2020 at 01:50):
is it an agency pecularity?
Angus Millar (Jul 15 2020 at 01:58):
I don't believe so, is sending Pathology PDFs purely an Agency phenomenon? Do you propose that when sending PDFs that each separate Panel should be its own PDF? Is that driving towards the best outcome for the consumers/doctor. I have heard many times the complaint from doctors in receiving V2 messages that ever single test is on a separate page. I feel a large portion of these complaints come down to this limitation on OBR-4, now carried over to DiagnosticReport in FHIR.
Angus Millar (Jul 15 2020 at 02:08):
The way the Agency CI team is currently looking to work around this it to have Observations resources for each Panel LFT, U&E and UricAcid hanging off the DiagnosticReport resource and then each of those Observations will have many hasMember child Observations representing the atomic results for each panel. I don't mind this approach yet it leaves the question hanging, what do you put in the DiagnosticReport code and how do you search for DiagnosticReport resources for a given report like LFT. I guess you can chain [base]/DiagnosticReport?result.code= system|code.
Grahame Grieve (Jul 15 2020 at 02:51):
ever single test is on a separate page
That's to do with how the PDFs are built and/or displayed.
Grahame Grieve (Jul 15 2020 at 02:52):
I don't think it's right to bake software limitations like that into the interop format for ever
Grahame Grieve (Jul 15 2020 at 02:52):
because then there'll be no way to do anything better in software ever than display the whole set of reports
Grahame Grieve (Jul 15 2020 at 02:57):
but: if you want to do this, then the DiagnosticReport.code should be a general code that indicates the breadth of the grouping. (Hopefully the proposal isn't to smash different disciplines into a single pdf). And then use some extension to indicate the set of pdfs that have been smashed together
Grahame Grieve (Jul 15 2020 at 02:57):
Do you propose that when sending PDFs that each separate Panel should be its own PDF
yes, I do. You are confusing structure and presentation, which is a classic agency clinician led process mistake to make.
Angus Millar (Jul 15 2020 at 03:07):
I feel we are only being reactive to the industries capabilities. When they produce PDFs they often contain many panels and have very generic names, like General Chemistry, General Haematology. I do appreciate what you are saying, in a information sense I want the content to be as discrete as possible as that allows it to be far more reusable is various ways. However, if the content producer is going to wrap many into a non-compuabloe format such as PDF then I want them to describe what is in that PDF as discreetly as possible and they can't do that with a 1..1 code.
Grahame Grieve (Jul 15 2020 at 03:11):
well, the lab I was in did use "General Chemistry" as the code, and we did expect the doctors in the hospital to know what that meant (lovely to have a captive audience). But in as much as it's already being done, as I said: one code in the DiagnosticReport that indicates the scope, and that matches OBR-22, and extensions to indicate the contents of the PDF. Which for me, if we were actually being useful for the clinicians, would be the list of requests that the PDF covers, not the panel codes. But maybe that's just me.
Angus Millar (Jul 15 2020 at 03:40):
Yes, what does it mean? The bigger problem is not what they think it means but how do they find the report they are looking for, say 'LFT' among many reports called "General Chemistry". I assume you mean OBR-24 (Diagnostic Serv Sect ID). I also agree we should be talking about the requested codes and not the Panel codes. Yet many reports are not electronically ordered to know those codes, as yet. The requested codes would go in the 0..* DiagnosticReport.basedOn(ServiceRequest). Again while It is fine to say the report covers many ServiceRequest codes you can't then say the DiagnosticReport consists of many 1..* codes. So we cover the case of many ordered tests producing a single report but fail to allow many orders test to produce a single report containing many reports. Like a FBC & IM, the IM must be a separate DiagnosticReport. I don't disagree with you, I would like every DiagnosticReport to be a discrete report of one type, but I feel that is not the world we live in and, if using PDFs, not what the consumer wants. On the flip side, what is all that wrong with the notion of a DiagnosticReport.code that is 1..*, what are the negatives of that?
Grahame Grieve (Jul 15 2020 at 03:54):
ok, yes OBR-24. Was going from memory and it's been a long time
Grahame Grieve (Jul 15 2020 at 03:54):
Agree that while requested codes would be better, that isn't always possible.
Grahame Grieve (Jul 15 2020 at 03:55):
what are the negatives of that?
Well, the most obvious negative is that you're going to be based on R4 for at least 3 years, and changing the cardinality is a R5 thing.
David McKillop (Aug 28 2020 at 02:35):
Following on from @Craig Newman comment - Assuming the FHIR Diagnostic Report equates to the HL7 V2.x ORU message (note: { . . . } = repetitions; [ . . . ] = optional), the ORU^R01 message has OBR.4 (Universal Service Identifier) that is required and non-repeatable which is the same as DiagnosticReport.code with a cardinality of 1..1. However, in the ORU, the OBR segment is allowed to repeat which accommodates an OBR for UE, an OBR for LFT an OBR for Ca, and there is a final OBX with the pdf with all of the UE, LFT, Ca results as the pathology provider intended for the report to be presented. Hence the HL7 v2.4 model (v 2.3.1 or v2.4 are the most common is AU) accommodates having multiple panel results in a message with a single pdf.
In comparison the DiagnosticReport does not have the equivalent of a repeating OBR segments and hence the DiagnosticReport.code must become a more generalised code eg “General Chemistry” in the case of a report with UE, LFT, Ca etc.
Have I misinterpreted the comparison of ORU to DiagnosticReport or is this not a reasonable comparison?
Your thoughts @Grahame Grieve , @Angus Millar ?
Grahame Grieve (Aug 28 2020 at 02:53):
I think of DiagnosticReport as matching the ORM segment, not ORU message
Vassil Peytchev (Aug 28 2020 at 03:01):
I don't think you can straight up compare the ORU message with DiagnosticReport. With diagnostic report, you can have direct links to the multiple ServiceRequests, each with it's own code, just like the message has multiple OBR segments; you can have links to multiple Observations (flat list, or hierachically organized), each potentially linking to one or more ServiceRequests as well.
From what I understand from the question, there is definitely a way to clearly express what you need, but it's more than just DiagnosticReport...
David McKillop (Aug 28 2020 at 05:50):
Thanks @Grahame Grieve - I'm confused with "ORM segment"? Do you mean ORM message or OBR segment? Looking at ORM segment and ORU message both allow for a repeating OBR, so they're equivalent in that respect. If you're referring to OBR segment then I agree DiagnosticReport.code maps to OBR-4 Universal Service Identifier and there is only one code.
Thanks @Vassil Peytchev - I agree in DiagnosticReport there can be links to "panels" or results via observations with hasMember observations, but then the DiagnosticReport.code becomes a more generic value.
Grahame Grieve (Aug 28 2020 at 05:51):
sigh. it's such a long since I did a lot of v2. yes, the OBR
Last updated: Apr 12 2022 at 19:14 UTC
