Stream: implementers
Topic: Multiple OBR
George (Jul 11 2016 at 21:38):
Hi:
We are trying to map Lab message to FHIR. For HL7 v2 message with multiple OBRs, should we map them into a single DiagnosticReport with multiple Observations or should we map each OBR to one DiagnosticReport?
Grahame Grieve (Jul 11 2016 at 22:02):
well, generally, OBR = DiagnosticReport, so that would be the default expectation. However, use of OBR/OBX is highly variable, and I've seen OBR used is a section header in a report - that would equate to Observation, not DiagnoticReport
George (Jul 11 2016 at 22:09):
Is there any preference for Lab messages?
Grahame Grieve (Jul 11 2016 at 22:27):
the default would be the preference. you might choose to do otherwise for specific lab messages based on manual inspection of their content
Rob Hausam (Jul 12 2016 at 02:43):
I don't think this is hard and fast - as Grahame said, there is considerable variability in the V2 world. I've seen V2 messages containing multiple OBR's that would be reasonable candidates for a single DiagnosticReport.
George (Jul 12 2016 at 16:19):
Each OBR represents a battery. So in the same message, it contains multiple different battery codes.
When we display to the end user, we put all OBRs and its associated OBX into 1 PDF lab report.
To Rob: What scenarios would make multiple OBRs become reasonable candidates for single diagnosticReport?
Grahame Grieve (Jul 12 2016 at 19:21):
user preception that it's a single report, and the fact that all of them are authorised together and published as a group, not separately
George (Jul 12 2016 at 21:29):
Yes, user perception is a single report.
If we map it to a single diagnostic report, does this mean that we need to map each OBR code to Observation.code and use Observation.related to map the OBX?
On the other hand, if we use multiple diagnosticReport to represent one single report, can we use Bundle resource to group them together?
Eric Haas (Jul 12 2016 at 21:53):
Yes or they may be linked by a single order patient-encounter as well and can be associated that way without bundling.
Grahame Grieve (Jul 12 2016 at 22:25):
yes, each OBR to Observation.code + use related for the OBXs
Grahame Grieve (Jul 12 2016 at 22:25):
with regard to bundle, it's a physical arrangement, not a logical one. Resources move in and out of bundles e.g. when you search or not. Putting a resource in a bundle doesn't have any *meaning*
Grahame Grieve (Jul 12 2016 at 22:25):
and I think that's what you want - what links them together logically.
Grahame Grieve (Jul 12 2016 at 22:26):
what do you want to link them together? a common order?
Stefanie Walter (Jul 13 2016 at 16:17):
Hi Grahame,
Thank you for the help. I am working with George for this mapping exercise.
To link them logically we map diagnosticReport.identifier to Report ID and battery ID. So the diagnosticReport resources that belong to the same report will have same report ID.
Will this approach work to link them together?
Grahame Grieve (Jul 13 2016 at 19:45):
that definitely links them together, for sure.
Last updated: Apr 12 2022 at 19:14 UTC
