Stream: implementers
Topic: DisagnosticReport for Labs
Dave Henderson (Feb 11 2019 at 16:20):
Hi,
Can I ask the community how they are using the diagnosticReport.code element within a pathology lab ? FHIR has this as a mandatory element that uses a LOINC codes as the preferred valueset. We have various use cases that require coded and non-coded values, in addition to 1..* requirements (which we can't support using this element as its 1..1) . We don't want to enforce the use of any specific Terminology either.
Any info would be appreciated.
Dave
Lloyd McKenzie (Feb 11 2019 at 16:25):
You can use non-coded with DiagnosticReport.code.text. If the usecase for multiple codes is representation of the concept in multiple code systems, that's handled by DiagnosticReport.code.coding which is 0..*. If not, can you expand on having a single report that has multiple codes? If the codes represent the results within the report, those would be on the Observation.code for the observations contained within the report.
Lloyd McKenzie (Feb 11 2019 at 16:25):
The choice of terminology is preferred, but not mandated. You're free to use what codes are appropriate in your jurisdiction.
Eric Haas (Feb 11 2019 at 18:43):
There are standard extensions to link the DR ( DiagnosticReports) together as well. http://build.fhir.org/diagnosticreport-profiles.html
I too would like to know the use case for 0..* codes as well since a report is typically about one thing.
Dave Henderson (Feb 14 2019 at 11:37):
Thanks for the replies guys. I'll feed back how I've used the diagnoticReport.code within our implementation once it's been agreed. Hopefully this will help others that may be looking at pathology messaging.
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Mar 06 2019 at 21:21):
Is your pathology report structured or unstructured data (text blob, pdf, etc.)? If structured, each observation should be LOINC or other code system encodable. Do you have another code system required in your area? Are you talking questions or answers too?
Last updated: Apr 12 2022 at 19:14 UTC
