DiagnosticReport

[dt-r]

Upvote for inclusion of a Resource Profile of DiagnosticReport Resource in AU Core Release 1.

Comment if you think we need a different profile to AU Core DiagnosticReport, or if there is a need for an additional DiagnosticReport profile in AU Core.

AU Core DiagnosticReport profile would set minimum expectations for a DiagnosticReport resource to record, search, and fetch diagnostic reports associated with a patient.

AU Core DiagnosticReport should be based on the AU Base DiagnosticReport profile and identify the additional mandatory core elements, extensions, vocabularies and value sets that SHALL be present in the DiagnosticReport resource when conforming to this profile. It provides the floor for standards development for specific uses cases in an Australian context.

[xtfer]

This would imply the presence of Specimen and ImagingStudy, to be useful. Do they need to be added?

[mjosborne1]

Diagnostic report relies on the Accession Number profile: https://build.fhir.org/ig/hl7au/au-fhir-base/StructureDefinition-au-accessionnumber.html . In that profile, Accession Type is a CodableConcept required binding inherited from AU Base, the two values for which are ASCN : Accession Identifier and LACSN: A laboratory accession id.
I don't see the point of making these a required binding type, they are practically useless information without having types for other reports e.g. Diagnostic Imaging accession no, cardiology investigation accession number, lung function accession ....
In my mind LACSN is-a ASCN and hence they are interchangeable.
I would either make the type field useful or make it non-mandatory.

[dt-r]

This is an AU Base comment.

[mjosborne1]

I feel like we are missing a discussion forum (like this one) in AU Base. My only options are to mention it here, Zulip or log an issue in AU Base. I don't feel strongly enough about it for it to be an actual Issue, so I withdraw the comment.

[dt-r]

I think this question is best for Zulip. The AU Base authors and others can see the query around the Accession Identifier profile there and respond to answer your query.

[davidmckillop]

DiagnosticReport using a panel of Observations (as per EU) or not (as per US)

There has been an ongoing discussion in various Zulip threads about the representation of Observations in a DiagnosticReport i.e whether there should be a "grouper" Observation to represent a panel of Observations or not. Angus's diagram (5th June 2023 comment) from Usage of panel of Observations best illustrates the issue with the representation of a Full Blood Count (FBC) as an example:

HL7 EU have adopted option A where as the US favour option B.
There were a series of meetings with HL7 O&O in June and July refer to 7th June, 14th June. I'm sure there were 3 or 4 meetings, but that's all I could find the minutes for.
A lot was discussed at the meetings, including the ramifications of the 2 different options/models, but nothing was agreed about which option, or if any option, should be chosen.
HL7 O&O will be discussing Panel - Composition - DiagnosticReport in mid November, but that time could be used to discuss the response to the recently released HL7 EU Laboratory Report FHIR Implementation Guide ballot.

HL7 AU Base and HL7 AU Core have recommended grouping of Observations (option A) with the profile specific implementation guidance of:
When constructing a report for a study / panel:
the individual component examinations are referenced by that grouping Observation in Observation.hasMember and not directly referenced in DiagnosticReport.result
DiagnosticReport.code and the study / panel Observation Observation.code should be the same concept if the report contains only the results of that study / panel

This thread is to inform the AU community of the ongoing international discussions and if/when any further details are forthcoming Angus or I will update this thread.
However, in the meantime for those in the diagnostics space your input on HL7 AU Base and HL7 AU Core would be appreciated, and please feel free to provide feedback on the HL7 EU Laboratory Report FHIR Implementation Guide ballot.

[MattCordell]

I think both those patterns are valid... for different reasons in different circumstances.
(I note Observation supports a single, or a group too).
1st reason is aesthetics.
E.g. For a Full Blood Count, you might have the counts/indices in one section. And a second for the (optional) differential.
I've seen paper based FBCs based as both Option A or B.

2nd Reason is relating results. The U MC/S is a good example.
The micro "section" is probably aesthetics. But if two organisms are identified, the sensitivities should relate to each..
I think ,from memory, in v2, each organism is treated as a specimen, and reference by the different sensitivities.E.g. Organism1, Organism2.

I can see a few different ways we could do this, but an agreed, consistent approach would be good. Are there any existing examples @davidmckillop ? (ie. MCS results for 2+ organisms?)

[davidmckillop]

Hi @MattCordell - we're on the same page in that Observation supports both with different approaches being taken by different regions.

Re: representation of multiple organisms in a HL7 V2 microbiology report - that's dealt with by OBX-4 (sub-id) refer to example in section 4.4.2.4 OBX-4 Observation sub-ID (ST) 00572 of the Australian Diagnostics and Referral Messaging - Localisation of HL7 Version 2.4
(Note: the "regular" Confluence url for this standard localisation is no longer working; hence this "archive" url. Query part of the issues with the HL7 AU transition from HL7 AU Confluence to HL7 International infrastructure).

We haven't developed any specific multiple organism microbiology reports as yet, though it would follow the following pattern of:

Note: this is not a standard format, some sites will have less elements or major groups e.g. without the "Dipstick" content and some may have more elements.
Using the above pattern, option A would look like:

And option B would look like:

There's not a lot of difference between the two i.e only the additional grouper Observation (line 2 in option A) and the subsequent additional Observation in each row.

I agree that there are a few different ways that this could done, and an agreed, consistent approach would be good.

It will be useful to know any decisions that come from the HL7 International O&O meetings (scheduled for mid Nov) as this may provide guidance on how AU progress on this topic. However, if there isn't any international guidance forthcoming, then the HL7 AU community will need to decide on the best way forward which may be Option A, or Option B or living with both with guidance on how to use both or some other option.