Stream: implementers
Topic: DiagnosticReport.code - broader granularity or an extension
David McKillop (Jun 25 2020 at 11:21):
Given the cardinality of DiagnosticReport.code is [1..1] it seems that when multiple codes are to be reported e.g. Diagnosticreport-example-ghp the value of the code becomes "broader" to accommodate the content e.g. <display value="General Health Profile"/> for this example.
What are people doing when a full blood count (FBC) plus an erythrocyte sedimentation rate (ESR) are reported? These tests are reported on the same lab report, so is the DiagnosticReport.code.text = "General Haematology" (or an appropriate code)?
Similarly if UE's and LFT's which are reported together, does the DiagnsoticReport.code.text = "General Chemistry" with the first Observation.code = "UE" with the appropriate hasMember Observations for the UE elements (Na, K, CL etc) and the second Observation.code = "LFT" with appropriate hasMember Observations for the LFT elements (Total Protein , Albumin, Globulin etc)? This would keep the UE & LFT elements together.
Or do many implementers use the extension diagnosticReport-extends which seems to be meant for sibling reports with the description of "The report references related ("sibling") reports." In the examples above FBC & ESR and UE & LFT these are on the same lab report or is that what the extension is meant for (tests on the same report)?
Hence my query is to:
1) Have the one DiagnosticReport.code and just use a broader term to encompass all the tests on the report in which case a UE when ordered on it's own the DiagnosticReport.code = "UE" or if ordered with an LFT will be part of a DiagnsoticReport.code = "General Chemistry"?; OR
2) Use the extension (if it is appropriate to use in these cases) to accommodate all the tests/panels e.g. UE, LFT that appear on the one report? OR
3) Any other suggestions?
Thanks
Lloyd McKenzie (Jun 25 2020 at 14:40):
@Eric Haas
Eric Haas (Jun 25 2020 at 14:56):
I am also interested in what is out there in the wild. WE have had several modeling discussions regarding adding sections to DR but nothing firm yet.
David McKillop (Jun 25 2020 at 21:38):
A related question which follows on from query 1) above - what is the feedback on the content of DiagnosticReport.code that relates to the report rather than the specific contents of that report, e.g.:
Option 1 - DiagnosticReport.code relates to the specific contents being reported:
| Report | Reported Test(s) | DiagnosticReport.code |
|---|---|---|
| 1 | Potassium (element of UE) | Potassium |
| 2 | Urea and Electrolytes (UE) | Urea and Electrolytes |
| 3 | Liver Function Test (LFT) | Liver Function Tests |
| 4 | UE & LFT | General Chemistry |
| 5 | UE, LFT, Glucose, Mg, Ca, Phos | General Chemistry |
Option 2 - DiagnsoticReport.code relates to the report no matter what component elements are being reported:
| Report | Reported Test(s) | DiagnosticReport.code |
|---|---|---|
| 1 | Potassium (element of UE) | General Chemistry |
| 2 | Urea and Electrolytes (UE) | General Chemistry |
| 3 | Liver Function Test (LFT) | General Chemistry |
| 4 | UE & LFT | General Chemistry |
| 5 | UE, LFT, GLucose, Mg, Ca, Phos | General Chemistry |
@Eric Haas , @Andrea Pitkus, PhD, MLS(ASCP)CM, CSM and any others?
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Jun 26 2020 at 12:43):
Your threads have several aspects.
-
Regarding structure of lab results. The simple structure of order-result(s) and as panels are defined by the performing lab must be preserved. Often there are calculations and other "results" like interpretations that are context specific. This can be achieved by using service request for the order. Tiered/physician convenience panels, such as the General Health Profile noted, and reflex orders are more complex and it's even more important from a patient safety aspect to keep the structure in place. Have yet to see complex panels and reports completely modeled out in FHIR. Have asked O&O for correct examples for implementers. @John David Larkin Nolen has shared a Bone Marrow Report to help jumpstart the process.
-
There is work on overall DR with @Richard Esmond leading charge on radiology DR and overlap of common elements with pathology DR. Work has been on and off for structuring the common sections found from each specialty in a typical DR. The Bone Marrow report touches on many aspects, including parts of the CBC from the clinical lab, as well as pathology aspects, and genomics aspects would touch several areas and be a great example.
-
For the GHP, it can be coded as original request and the CBC and Urinalysis can also be modeled as a request linked to the original request. Appropriate specimens for each also need to be linked to each as well as procedure for collections for each, such as venipuncture for CBC, but clean catch collection for Urinalysis.
-
Each result (observation) can refer back to the service request, but each order is necessary to provide additional context for the laboratory "test" performed, but also keep observations "grouped" together that are in panels and retain the report structure from the performing lab. It's not like 52 pick up where a random order of observations are reported.
-
That said, the DiagnosticReport.code is often the LOINC order code, which represents each panel order (i.e. CBC, Urinalysis) and the required results which are part of the panel. There are different LOINC order codes for CBC with differential and CBC without differential/hemogram, for example. [image.png](/user_uploads/10155/AmZF38TDaiz37ebzVEddaqor/image.png Keep in mind folks should be mapping LOINCS accurately uding the most specific/detailed LOINC as accurately describes the order or result. If the UA is reflexive, a reflexive LOINC shoudl be mapped. Having these maps at the service request level can allow for a single query of the CBC or other panel, instead of querying each of the individual results (observations) that are usually part of a CBC.
-
In addition, each laboratory has their own mnemonics and ordering codes for referring to an order. Some countries also have defined panels and the order LOINCs that should be used. Service Request also supports a "code." Where results of an order are all reported together as the same panel in a Diagnostic Report, such as CBC order reported as results of the CBC referring to the order in the DR, the codes should be the same, whether LOINC or performing laboratory code. The items are the same. A single order for a Potassium, may have a different result code for the resulted potassium, permitting distinctions when the same naming conventions are used for orders and results. They would have the same LOINC code. What gets tricky is the reflex or physician convenience orders. The GHP panel or other customer physician convenience panels like a stroke panel may not have a LOINC. Regenstrief has indicated they will not create LOINCs for every single panel, such as those that vary by a result component, but guidance is in place with a design that allows flexibility with optional items.
-
There are laboratory "sections" as used by CMS in the US, CLIA Proficiency Testing (PT), many laboratories to indicate which "benches" or areas of the laboratory a test is performed in, and many EHR and LIS vendors to "group" lab results by whether they are hematology, chemistry, pathology as you seem to indicate. These are able to be represented by FHIR observation category. It allows all the chemistries to be "grouped" together or orders to be listed together for CPOE.
Hope that helps! Andrea
David McKillop (Jun 29 2020 at 01:21):
Hi @Andrea Pitkus, PhD, MLS(ASCP)CM, CSM , thanks greatly for your detailed and considered reply. Greatly appreciated. We'll digest what you've said and use it to reflect on our models.
Cheers
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Jul 01 2020 at 16:53):
You're welcome. Thank you for sharing. This is fantastic! Reviewing and Digesting.
Could you clarify what pathology and laboratory entail in Australia, as different countries use the terms with different meanings?
Do you anticipate the DR will be used for surgical pathology reports (and have you/will you model the RCPA cancer checklists in FHIR)? Have/will you also model genetics and molecular reports in the FHIR DR? Or are there areas (any of these) excluded from scope of use of the FHIR DR? Trying to get a better idea of use case scope.
Also shared the thread with others working on the same problems
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Jul 01 2020 at 17:01):
@David McKillop reviewing the fbc DR html and it looks beautiful :) I'd expect to see the units to the right of the numeric values and units with the reference range values in case there are any differences. Also a numeric value for microbiology sensitivity testing may include a numeric result value for the antibiotic followed with an interpretation of Susceptible, Resistant, Intermediate.
Are these considered publically available and can they be referenced in presentations/education to the laboratory community on what FHIR implementations may look like?
Kurt Allen (Jul 01 2020 at 17:24):
On the Breast Radiology Report IG we used a Fhir Document (Bundle with a Composition as the first element 'index) as the base structure. You can add one or more Diagnostic Reports (with associated observations) to this, so possibly have one Diagnostic Report for each order? Having the whole shabang (technical term) in the fhir document also allows the report to be signed with a hash so you can better show provenance.
Here is a link to the base structure
http://build.fhir.org/ig/HL7/fhir-breast-radiology-ig/StructureDefinition-BreastRadiologyComposition.html
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Jul 01 2020 at 19:10):
Thanks @Kurt Allen One of the challenges discussed is some labs will report separate DRs resulting from an order (usually reflexive, add on, but may be individually ordered), while others may report in a single integrated report (which wouldn't have the performing lab, CLIA#, address repeated).
David McKillop (Jul 02 2020 at 02:10):
In reference to @Andrea Pitkus, PhD, MLS(ASCP)CM, CSM comment Thank you for sharing. This is fantastic! Reviewing and Digesting., it's in reference to a separate communication (non Zulip) containing the Australian Digital Health Agency’s Diagnostic Report FHIR implementation guide is released for stakeholder engagement and review supporting pathology reports, diagnostic imaging reports, and specialist and other diagnostic reports.
This draft release has been developed with a suite of draft profiles (derived from HL7 AU) and some early examples in order to form a basis for engagement with industry and other stakeholders.
There have been a number of modelling decisions made including:
1) We separated the domains of pathology, diagnostic imaging and specialist & other diagnostics with each having their own set of Compositions, DiagnosticReport and Observation profiles;
2) We’ve split each domain to suit our use cases of:
a) My Health Record content – which includes a pdf and some meta data (results values may be included, but not accepted in the current My Health Record CDA content)
b) atomic content – capable of exchanging a diagnostic report with atomic data.
3) When sending a report of a multi-test study or panel:
• result is sent with the Observation representing the study / panel
• code is sent with the same code in that study / panel Observation
• the individual component tests are referenced by that Observation (Observtion.hasMember) and not directly referenced by the DiagnosticReport
Number 3) allows for structure of the test group/panel to be as the diagnostic provider intended, thereby improving clinical safety, though I’m sure it will stimulate discussion for those familiar with HL7 V2 messaging.
There are some examples present including “FBC + ESR” and a “COVID” for pathology and an “Echocardiography Report” (complex report with multiple hasMember observation layers) in the other diagnostic report. More examples need to be developed to demonstrate the profiles, but current time constraints meant that more examples will need to be in future development.
David McKillop (Jul 02 2020 at 03:33):
In response to @Andrea Pitkus, PhD, MLS(ASCP)CM, CSM 's questions refer to the following:
Could you clarify what pathology and laboratory entail in Australia, as different countries use the terms with different meanings?
In Australia, the term “pathology” covers both:
• - Laboratory (Clinical Chemistry, Hematology, Microbiology, etc.)
• - Pathology / Histopathology / related disciplines
Do you anticipate the DR will be used for surgical pathology reports (and have you/will you model the RCPA cancer checklists in FHIR)?
Back in 2015, the RCPA PITUS 15-16 had a project “report modelling” to produce structured reporting of cancer where Grahame was primarily involved with the output found here. This content was a demonstration and wasn’t progressed. The current RCPA PITUS 18-20 has a project 4. “SPRC Infostructure and Conformance will develop a model and terminology for four protocols and undertake Informatics External Quality Assurance (IEQA) trial for one protocol” which @Grahame Grieve is doing and I believe he is close to finalising this content. I’ll let you know when it becomes available. FYI - Grahame’s structured reporting of cancer protocol content will be separate to the Agency profiles.
Have/will you also model genetics and molecular reports in the FHIR DR? Or are there areas (any of these) excluded from scope of use of the FHIR DR? Trying to get a better idea of use case scope.
No, we haven’t modelled genetics or molecular content. I have seen lots of chatter on the Zulip genomics channel and we don’t have the same subject matter expertise involved here in AU, so we’ve excluded it from out scope at this stage. We’ll see what comes out of the USA developments for this content.
So, our use case for the 3 domains which we’ve treated separately – 1) pathology (not specific structured cancer reporting as per the RCPA protocols), 2) diagnostic imaging and 3) specialist & other diagnostics, is for both the:
- My Health Record which is a pdf with some meta data (e.g. service section id, test name)
- DR with atomic content for exchange.
David McKillop (Jul 02 2020 at 04:53):
@Kurt Allen I see that your Composition has a slice on Composition.section with a section for the various content including DR's which allows you to do what you need.
In the Diagnostic Report FHIR implementation guide we have the option for using a Composition (within a Bundle) as a wrapper for the DR, but the DR can be sent in a Bundle without the Composition. For our use case of the My Health Record, both the Composition.section and Composition.section.entry have been constrained to [1..1].
For pathology it also makes sense to constrain the Composition similarly as the attached report is linked in the DR.presentedForm and the reportable codes need to be associated with that report.
One of our queries/issues is with the cardinality of DR.code of [1..1]:
In the case with pathology in AU, the RCPA are very concerned that the results are interpreted as the diagnostic provider intended. The RCPA have developed Standards for Pathology Informatics in Australia (SPIA) which has a standard:
S10.1 Data must be sent in a rendered format and may be accompanied by atomic results which must be coded.
so in the case where there are multiple requested codes that appear on the same report (pdf) e.g. UE, LFT, Mg, Urate, etc the problem becomes one at the DR level as the DR.code has a cardinality of [1..1]. The problem is what do you have for DR.code is it a generic term eg "General Chemistry" (refer to scenario in table earlier in this thread) which is no more specific than DR.category. Ideally, all the reported codes (e.g. UE, LFT, Mg, Urate etc) that appear in the same attached pdf would be "grouped" together in the same DR. There are options to deal with this including:
1) Use of a generic code at the DR.code level e.g. "General Chemistry"
2) Use the extension extends where each code is listed via the extension
3) Any other suggestions?
What is the logic/reasoning for DR.code being [1..1] ?
Andrea Pitkus, PhD, MLS(ASCP)CM, CSM (Jul 02 2020 at 11:19):
It is true that panel orders need to retain their "grouping" as defined by the performing laboratory. It's a patient safety issue if they are not. Where multiple diagnostic reports are integrated into a single report, the interpretation for each needs to be associated with each as there is important clinical context (i.e. wouldn't want negative cytogenetics interpretation on a positive flow cytometry for a bone marrow biopsy for leukemia diagnosis)
Grahame Grieve (Jul 03 2020 at 04:01):
yes I am working on the cancer protocols, but I don't know yet know when I'll be able to publish it - the intent is there but waiting for some procedural issues to be resolved
David McKillop (Jul 07 2020 at 01:17):
A main item of the above (TL;DR) : "What's the reasoning for the cardinality of DiagnosticReport.code = [1..1]?"
This is particularly relevant for reports that have aggregate tests (e.g. UE, LFT, Mg, Urate etc) where a relaxed cardinality of [1..*] would accommodate them.
Last updated: Apr 12 2022 at 19:14 UTC
