Diagnostic Reports: can and should a single DiagnosticReport aggregate multiple panels/tests groups?

[davidmckillop]

Prerequisites

• [x] I have searched open and closed issues to make sure it isn't already requested or reported
• [x] I have written a descriptive issue title

The issue

Description

There are structural limitations in the base FHIR DiagnosticReport resource that limit support of reporting to a single DiagnosticReport resource per orderable test/study/panel:

1. a code with a cardinality of 1..1.
2. a presentedForm with a cardincality of 0..*, where the definition is: "Rich text representation of the entire result as issued by the diagnostic service. Multiple formats are allowed but they SHALL be semantically equivalent."

This leaves the question on how to support the common scenario of a report that aggregates one or more orderable tests / examinations, e.g

• reporting a full blood count (FBC) and an erythrocyte sedimentation rate (ESR)
• reporting shoulder examination MRI and x-ray

Question raised with Int Orders and Observations WG:

Is the intention in the structure of the DiagnosticReport resource to semantically limit a single DiagnosticReport instance to reporting on a single orderable? See https://chat.fhir.org/#narrow/stream/179256-Orders-and.20Observation.20WG/topic/Query.20intent.20of.20DiagnosticReport.20resource

Solution options in order of preference:

1. Cardinality of DiagnosticReport.code to be 1..*
2. Create and use an extension that can carry the additional codes when a DiagnosticReport reports on more than one study / panel
   • core extension preferrably
   • AU extension if core is not possible
3. Include some means to indicate this is a DiagnosticReport that aggregates mulitple studies (likely by using a DiagnosticReport.category) - this is a supplemental option not a solution in and of itself
4. Agree to structure results in such a way that ...

What it actually enables people to do

TBD

Common scenarios

Diagnostic Imaging:

A shoulder examination with 2 MRI's and 2 X-rays could be reported using the following structure:

• each MRI and x-ray in a separate DiagnosticReport (hence 4 DiagnosticReport), or
• a single DiagnosticReport reporting the four imaging examinations, or
• some combination of the above

Pathology:

A full blood count (FBC) and an erythrocyte sedimentation rate (ESR) which are commonly ordered together, could be reported using the following structure:

• separate DiagnosticReports for FBC and ESR with the attachment in both DiagnosticReports resources, or
• in a single DiagnosticReport (potentially with a DiagnosticReport.code of "General Haematology" or just FBC)

The test groups/panels of urea and electrolytes (UE's) are commonly requested and reported with liver function tests (LFT's) could be structured as

• a DiagnosticReport for the UE's and a separate DiagnosticReport for the LFT's

  • if that UE's & LFT's are reported on the same report/pdf this would mean the same attachment would be referenced in both DiagnosticReport resource

• one DiagnosticReport that reports on the multiple test groups/panels.

  • This would enable all the content of the attachment to be reported in a single DiagnosticReport resource
  • If a broad DiagnosticReport.code (eg General Chemistry) was used to cover the tests/panels being grouped the meaning of the code at the DiagnosticReport becomes "diluted"

How desirable is it for the content of DiagnosticReport.code to relate to the content of that report? e.g.:

DiagnosticReport.code closely related 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

DiagnsoticReport.code with broad code applicable to different but similar contents, 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

How awesome would it be?

Essentially awesome - determining this fundamental structural approach is required in order to consistently exchange diagnostic reports that are more than just attachments.

Workarounds

There are multiple means of working around the limitations in the structure - most are not desirable if we can eventuate a change to the cardinality of DiagnosticReport.code in the base FHIR resource.

1. A single study/panel per DiagnosticReport - DiagnosticReports are aggregated by a grouping resource of List / Composition / MessageHeader / ...
2. A single study/panel per DiagnosticReport that are aggregated by an 'aggregating' header DiagnosticReport using HL7 diagnosticReport-extends
3. Use a generic code in DiagnosticReport.code that is broad enough to cover both
4. Supply a free text list of the studies / panels in DiagnoticReport.code
5. Select only one of the test studies / panels to be named in the DiagnosticReport.code
6. Create and use an extension that can carry the additional codes to be used when a DiagnosticReport reports on more than one study / panel
7. Use an agreed code to indicate that the report is a multi study/panel report - each study/panel code would be in Observation.code (linked via DiagnosticReport.result) but not in the DiagnosticReport resource

Additional context

In HL7 V2.x multiple OBR segments are aggregated by the message.

There has been some discussion on the FHIR Zulip community chat channel - a log in is required, but these are easily obtained via application:

1. DiagnosticReport for Labs thread started 12th Feb 2019
2. Diagnostic report for lab results thread started 5th May 2017
3. DiagnosticReport.code - broader granularity or an extension thread started 25th June 2020
4. Query intent of DiagnosticReport resource thread started 13th July 2020

Related discussions on DiagnosticReport and Composition:

1. DiagnosticReport Discussion thread started 14th October 2020
2. DiagnosticReport - Composition/Bundle boundaries

[dtr-agency]

Questions

1. Can and should a single DiagnosticReport resource aggregate multiple panels/test groups?

2. How desirable is it for the content of DiagnosticReport.code to relate to the content of that report? (see above for common scenarios)

[davidmckillop]

RCPA working on a related issue

Coincidently the RCPA in their PITUS 18-20 project have working group 5 working on “Report Standardisation will develop policy for results flagging and for the grouping of tests in pathology reports.” For the grouping of tests in pathology reports, the working group have been grappling with the term and the content, used with aggregated results e.g. General Chemistry for UE, Glu, LFT, Ca, Mg, General Haematology for FBC, ESR and query including Monospot and malarial screening. Some terms are easier to get agreement on than others; however there are many such report groupings where it is difficult to get agreement of what grouping of tests should be aggregated and the name for the aggregated group.
Although, agreement will be arrived with a number of report groupings, there will be many where this work will be ongoing and may not reach an agreement. The RCPA have placed Australia ahead of the pack with standardisation set of codes for pathology requesting and reporting – available from the RCPA downloads page. If these codes were used more widely by the pathology providers it would greatly streamline the electronic viewing of results from different providers and if multiple codes could be issued per report, then the need for a report grouping name is reduced.

[davidmckillop]

Summarising main issues

1) There’s a clash between the electronic world, the paper world and how people view reports: The electronic world strives to make reporting as granular as possible where each reporting panel is reported in its own diagnostic report. The paper world i.e. pdf reports which may be represented on a screen, aggregates reporting panels e.g. UE, LFT, Ca, Mg, Glu, into one report, which is what clinicians are used to and would be easier to scan than having to go in and out of 5 screens, in the case of UE, LFT, Ca, Mg, Glu. Although, the presence of the physical printed report will reduce with time, the format where relevant results from the one episode are aggregated into one quickly viewed screen, is a format that promotes clinical efficiency and will need to be retained.

2) Mapping between HL7 v2 OBR segment and FHIR Diagnostic Report: According to DiagnosticReport HL7 v2 Mapping the resource DiagnosticReport maps to HL7 v2 OBR segment and DiagnosticReport.code maps to OBR-4 “Universal Service Identifier” where both are mandatory with a cardinality of [1..1].
Hence, when dealing with multiple results codes/panels that are present in the DiagnosticReport.presentedForm the value of DiagnosticReport.code becomes more generic to accommodate the reporting pdf as multiple individual reported panels cannot be accommodated in the one code e.g. General Chemistry.
In Australia there is agreement on the reporting codes – refer to the RCPA downloads where as there isn’t agreement yet on report grouping names and content - refer to “RCPA working on a related issue (above)”.
If multiple reporting codes were able to be used there would be better alignment between systems and improved searching on codes in DiagnosticReport.code, where code is [1..*].

3) Issue is no different in HL7 V2 Some of the feedback via Zulip is “what happens in v2” and as the FHIR DiagnosticReport maps to the v2 OBR segment, the issues are the same. There isn’t any guidance in the v2 documentation, so the issue is treated in a number of ways, including:

• Have a single OBR with OBR-4 with “General Chemistry”
• Have multiple OBR’s and under each OBR is the same pdf report in the final OBX.
• Have multiple OBR’s with no display OBX and have a separate OBR with “display segment” or “General Chemistry”
• Other options devised. These options have been in use so long that they are just viewed as the “normal”.

4) Allowing multiple ServiceRequests but only one reporting code: The FHIR DiagnosticReport allows for multiple orderable test codes by having the element basedOn with a cardinality of [0..*]; however only one code can be reported i.e. DaignsoticReport.code with cardinality of [1..1].

5) Allowing multiple categories but only one reporting code: The FHIR DiagnosticReport allows for multiple categories by having the element category with a cardinality of [0..*]; however only one code can be reported i.e. DaignsoticReport.code with cardinality of [1..1]. This may be to accommodate different scope of the same test eg Laboratory (LAB), Microbiology (MB), and Mycology (MYC) which may be used to represent a single test result of "Fungal culture m/c/s". However, if the intent is to allow >1 category e.g. Hematology (HM) and Chemistry (CH), then this would seem at odds with having a cardinality of [1..1] for DiagnosticReport.code, unless a very broad value was used for DiagnosticReport.code e.g. "Pathology", which doesn't seem useful.

[davidmckillop]

Created FHIR Jira ticket 28446 "Request of have DiagnosticReport.code [1..*]".

[davidmckillop]

The following comment was submitted in a personal email from Dr Nick Ferris (Radiologist) on the 31/8/2020 as part of his personal review/feedback of the FHIR Diagnostic Report FHIR Implementation Guide . Dr Ferris's feedback is published here with his permission.

Multiple procedures in One report Because request – report reconciliation is a key quality and safety requirement, this issue needs to be considered in the development of profiles for both requesting and reporting. At an atomic level, each episode consists of one or more diagnostic procedures. Some combinations of these are recognised as single procedures in their own right by systems such as the MBS (eg CT chest, abdomen, and pelvis – which contains three potentially separate procedures). While the standard procedure catalogue could be designed to include umbrella terms for commonly combined procedures such as CT chest, abdomen and pelvis, a strategy is also required for non-standard combinations of tests that are quite often requested for patients who have presented with multiple complaints, or a condition requiring multi-focal assessment. While it appears logical to require “one procedure, one report”, referring clinicians may be more inclined to think along the lines of “one episode, one report”. Current reporting practice for such requests varies with individuals and the nature of the combined tests – sometimes a single integrated report is more efficient and clear, sometimes a report itemised by procedure will be more appropriate. Perhaps the use of a category for ‘combined procedures’, with sub-fields for the number of procedures and for the individual procedures, would be best, with links from each procedure subfield to the relevant itemised report, or to the integrated whole, as appropriate.