Open davidmckillop opened 3 years ago
Update: No further work has been done on this issue since March 2021.
It is unclear what the preferred content of Composition.category (document type) and Composition.type (document sub-type) is and whether a single code ("Study Report") or a valueset is to be used in Composition.category and what specificity is needed in Composition.type.
If more than one code is wanted in Composition.category (document type) then the Implementation Guide will need to ensure the content to the particular Composition.type (document sub-type) is relevant to the Composition.category.
Further discussion needs to happen to decide on the desired level of granularity in both Composition.category (document type) and Composition.type (document sub-type). This discussion will also decide on whether multiple Compositions are required with a fixed value for Composition.category i.e. one Composition for each type of diagnostic domain (pathology, diagnostic imaging or other diagnostics) or if there is to be one Composition with a valueset and logic for the associated Composition.type (document sub-type).
Overall Recommendations
Initial diagnostic report context of defining a set of terminology that supports MHR primary document classification, i.e. type code and class code, within a set of FHIR resources and RESTful operations.
The two value sets start as equivalent – as sub typing is enabled within each the classes the value set governing type codes (i.e. sub types) expands with each additional sub type supported.
This material would be bound as extensible to the ADHA Diagnostic Report Composition and ADHA Diagnostic Report DocumentReference, and would also form part of an updated set of CDA implementation materials supporting current and future services.
Suggested Title: Diagnostic Report Type Suggested URI: https://healthterminologies.gov.au/fhir/ValueSet/diagnostic-report-type-1 Suggested Description: The Diagnostic Report Class value set includes values that may be supported as a type code for a diagnostic report. Compose requirements:
code | system | Display |
---|---|---|
47045-0 | http://loinc.org | Diagnostic Study |
100.16957 | https://healthterminologies.gov.au/fhir/CodeSystem/nctis-data-components-1 | Diagnostic Imaging Report |
100.32001 | https://healthterminologies.gov.au/fhir/CodeSystem/nctis-data-components-1 | Pathology Report |
Suggested Title: Diagnostic Report Class Suggested URI: https://healthterminologies.gov.au/fhir/ValueSet/diagnostic-report-class-1 Suggested Description: The Diagnostic Report Class value set includes values that may be supported as a class code for a diagnostic report.
Compose requirements:
code | system | Display |
---|---|---|
47045-0 | http://loinc.org | Diagnostic Study |
100.16957 | https://healthterminologies.gov.au/fhir/CodeSystem/nctis-data-components-1 | Diagnostic Imaging Report |
100.32001 | https://healthterminologies.gov.au/fhir/CodeSystem/nctis-data-components-1 | Pathology Report |
Prerequisites
The issue
Change description
The Diagnostic Report FHIR IG is to represent the three main diagnostic streams of:
The "Other Diagnostic Report" profiles from Diagnostic Report 1.0.0 (R4) June 2020 are being used as the core content for the Clinical Document Categorisation Project being undertaken by the Agency.
However, we need to look at the overall terminology to be used when pathology and diagnostic imaging are incorporated into the Diagnostic Report FHIR IG. "Other diagnostics" will the first content of this specification. Note: Diagnostic imaging (DI) and pathology already have CDA IG specifications from 2014 that have enabled content to be uploaded to the My Health Record (MHR). Hence, this discussion relates to the incorporation of the new DI and pathology FHIR IG specifications which will then be used to create the updated CDA IG specifications. There will be breaking changes for the 2014 CDA IG DI and pathology specifications when the updated FHIR IG specifications are created.
It should be considered whether Composition.type is better supported as a value set including a set of diagnostic report types, or whether it has to be fixed to be a catch-all code and with the referenced diagnostic report provides the finer grain. There are implementation constraints on the use of document types in the Australian digital health ecosystem that in practice mean that the values in Composition.type are tightly controlled and rarely extended - this is likely to mean that either a fixed value or a value set of only a few gross document types are preferred with the current approach.
Objectives: 1) Create content for Composition.category and composition.type to differentiate the 3 main streams of diagnostic reports of DI, pathology and specialist and other diagnostics. 2) Enable the sub-types of "specialist and other diagnostics" to be used in the CDA IG for the MHR to differentiate this content and have it discoverable in the MHR.
Options: There are several options available, but it is worthy to start with the content from the 30th June 2020 Specification:
Note: The 30th June 2020 content used the default values for Composition.category and Composition.type as developing content for these elements was not considered during the project. The content for these elements was being left for further consideration when requirements were apparent.
Note: LOINC 47045-0 Study Report is considered to be too broad, so a new LOINC code for "Diagnostic Report" has been requested. However, feedback (21/7/2021) from Regenstrief (LOINC) on the creation of a new LOINC code for "Diagnostic Report": "Your request for Diagnostic study report was discussed at some length in our Document Ontology subcommittee meeting in May. Although your perspective that "Study report" would be inclusive of both diagnostic and procedure reports, it was felt that creating the new node would create confusion and overlapping meaning between certain terms. Members suggested that the subject matter of the report would often signal diagnostic versus procedure. So while understanding the issue, the preponderant suggestion was to use the existing term. " Hence in option 1 "the broader term "LOINC 47045-0 Study Report" will be used.
The FHIR IG will look like the following for Option 1.
Note: The binding strength will need to be determined. (extensible) can be problematic as it binds the user to use the content that in the value set which may not necessarily be suitable in the circumstances.
or would a combination of diagnostic "levels" be included Composition.category? Option 4:
Notes: 1) Option 1 is suited to there being one Composition profile across all 3 diagnostic streams. 2) Options 2-4 are suited to there being one Composition profile for each diagnostic stream.
Discussion on different report levels:
Note: Level 1 subsumes level 2, level 2 subsumes level 3, level 3 subsumes level 4.
Information to be gathered: 1) How to best define the levels/buckets - terminology? 2) How to define the relationship between the levels/buckets? 3) Set of codes available for each level/bucket? 4) What to do with "Other Diagnostics" as "Other" doesn't fit into an ontology?
What it actually enables people to do
Having appropriate content in Composition.category and Composition.type will give clarity on categorisation of diagnostic reports which will facilitate searchability and discoverability.
Mockups
N/A
How awesome would it be?
Having clarity on the content of Composition.category and Composition.type will enable implementers confidence in a standard approach for diagnostic report categoristation and users confidence in finding diagnostics reports when needed.
Workarounds
Particular groups/jurisdications may develop their of "standard" method for categorising diagnostic reports, but this may not be standard across all jurisdictions and would impair discoverability of diagnostic reports.
Additional context
TBD