AuDigitalHealth / ci-fhir-r4

Working drafts of HL7™ FHIR® Release 4 (R4) artefacts authored and maintained by the Informatics Architecture team at the Australian Digital Health Agency.
Other
14 stars 3 forks source link

Diagnostic Report: Composition.category and Composition.type #113

Open davidmckillop opened 3 years ago

davidmckillop commented 3 years ago

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:

30th June 2020 Specification   Profile Composition.type Composition.category
Diagnostic Imaging 100.16957 “Diagnostic Imaging Report” Default core set of DocumentClassValueSet (example)
Pathology 100.32001 – Pathology Report Default core set of DocumentClassValueSet (example)
Other Diagnostic Report Default core set FHIRDocumentTypeCodes (preferred) Default core set of DocumentClassValueSet (example)

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.

Work in progress CDC content Profile Composition.type (Document sub-type) Composition.category (Document type)
Other Diagnostic Report To be determined; but will request an intermediate set that would match DiagnostiReport.code LOINC 47045-0  Study Report

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.

Option 1:  Profile Composition.type (Document sub-type) Composition.category (Document type)
Diagnostic Imaging 18748-4  Diagnostic imaging study LOINC 47045-0 Study Report
Pathology 11526-1 Pathology Study LOINC 47045-0 Study Report
Other Diagnostic Report To be determined LOINC 47045-0 Study Report
Or would it be more like where category is high level and type is a grouper ie Service Section codes? Option 2:  Profile Composition.type (Document sub-type) Composition.category (Document type)
Diagnostic Imaging Same as DR.category DiagnosticServiceSectionCodes (Binding strength to be determined) though a better set has been requested from industry 18748-4  Diagnostic imaging study
Pathology Same as DiagnosticReport.category ie https://www.healthterminologies.gov.au/integration/R4/fhir/ValueSet/pathology-diagnostic-service-category-1  (Binding strength to be determined) 11526-1 Pathology Study
Other Diagnostic Report Value set of the specific reporting codes CDC value set to be determined

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 where category is high level and type is specific low level ie more granular: Option 3:  Profile Composition.type (Document sub-type) Composition.category (Document type)
Diagnostic Imaging Specific reportable code eg Abdominal ultrasound 18748-4  Diagnostic imaging study
Pathology Specific reportable code eg Full blood count 11526-1 Pathology Study
Other Diagnostic Report Specific reportable code eg Echocardiogram CDC value set to be determined

or would a combination of diagnostic "levels" be included Composition.category? Option 4:

 Profile Composition.type (Document sub-type) Composition.category (Document type)
Diagnostic Imaging Specific reportable code eg Abdominal ultrasound Value set including “Diagnostic Report”, 18748-4  Diagnostic imaging study, plus content that equates to modality (reports) or suitable value set from RANZCR.
Pathology Specific reportable code eg Full blood count Value set including “Diagnostic Report”, 11526-1 Pathology Study, plus content that equates to the service section ID reports.
Other Diagnostic Report Specific reportable code eg Echocardiogram Value set including “Diagnostic Report”, plus a CDC content representing the CDC sub-types.

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:

Level/Bucket Name Description How to define the level/bucket (terminology) Where does the level/bucket align with the XDS conent or FHIR report structure (e.g. XDS sets; Composition.type; Composition.category; DR.category; DR.code; Obs.code; Obs.category)
1 Diagnostic Report Encompasses all diagnostic reports (diagnostic imaging, pathology and specialist and other diagnostics)    
2 Main streams of diagnostics There are 3 main streams of diagnostic reports – diagnostic imaging, pathology and specialist and other diagnostics    
3 Sub categories of each diagnostic stream   Pathology= https://www.healthterminologies.gov.au/integration/R4/fhir/ValueSet/pathology-diagnostic-service-category-1 ; DI = ?? Modality or DiagnosticServiceSectionCodes; Other = ??  
4 Individual requests      
         

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

davidmckillop commented 2 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).

dtr-agency commented 2 years ago

Overall Recommendations

  1. Maintain a narrow set of classCodes possible depending on MHR system service requirements, in order of preference:
    1. Do not add a new classCode – only subtype pathology and imaging
    2. Add the parent concept for diagnostic report. This parent code for use where an originating system does not want to categorise as pathology or imaging
      • Support three usage scenarios – generic (aka core), specialised for pathology, specialised for imaging
      • Future defined scenarios (i.e. Opthamology) can specialise pathology, or imaging, or the generic if needed or can just be made available as an option for use
    3. Identify a large set of diagnostic subdomains (by specialty) and allow those as classCode – majority of subtypes will overlap at least two
  2. Widest set of subtypes (typeCodes) possible, in order of preference:
    1. Define requirements for validity – do not predefine a fixed set of values
    2. Define a very large set of fixed values at a meaningful level of granularity associated with each classCode
    3. Define a small set of standard fixed values at a meaningful level of granularity associated with each classCode
  3. Improve categorisation by enabling the additional XDS attributes:
    • authorSpecialty
    • eventCodeList
  4. Improve categorisation by redefining practice setting code and facility type code for healthcare provider and consumer audience
  5. Design and develop the payload categorisation options in the forthcoming specifications in line with peak body and international standard recommendations
dtr-agency commented 1 year ago

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
dtr-agency commented 1 year ago

Proposed value sets reviewed by Agency Terminology and Informatics Architecture. To be progressed as FTR-1615 and FTR-1616. This content is now approved and will be closed when published via the National Terminology Service.