MHR system support for multiple document authors (Composition.author 1..*)

[dtr-agency]

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

More than one author is required to support some document types, this is currently acknowledged for the Pathology Report (see eHealth Pathology Report My Health Record Conformance Profile v1.1) and Diagnostic Imaging Reports (see eHealth Diagnostic Imaging Report My Health Record Conformance Profile v1.1).

FHIR profiles and CDA templates are both capable of supporting multiple document authors but it is not clear if the My Health Record system can support (handle, store, retrieve, process) documents that include multiple document authors.

What it actually enables people to do

Resolving this issue would clarify the capabilities of the My Health Record and confirm the full usage of reports with multiple authors in the My Health Record.

How awesome would it be?

It would be great to have clarity on this issue - to know that reports with multiple authors were able to be processed appropriately in the My Health Record.

Workarounds

Current workaround are described in Pathology Report (see eHealth Pathology Report My Health Record Conformance Profile v1.1) and Diagnostic Imaging Reports (see eHealth Diagnostic Imaging Report My Health Record Conformance Profile v1.1).

Additional context

TBD

[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 Authors The document lists as a known issue that the MyHR profile may not support multiple authors of a diagnostic report. In radiology (and I strongly suspect in other diagnostic specialties), dual authorship is common in training contexts, and often a training requirement (for the trainee). Hence it is certain to be retained in Radiology Information Systems (RIS). Broader consultation will be required as to whether it would be feasible to reduce authorship to the senior author for MyHR purposes. A structure that allows multiple authorship would be strongly preferred (ideally, it would provide for both co-authorship and senior/junior authoring).

[dtr-agency]

For document conformance artefacts (CDA and FHIR) a document wrapper is used to handle and exchange clinical data as a 'Document'. Clinical data put together in this way can be persisted in document storage and management systems e.g. IHE XDS.

Taking the example of a diagnostic report, the Diagnostic Report document type will be used to support exchange of diagnostic reports using a document exchange mechanism to enclose a single diagnostic report in a single document wrapper.

The clinical document ‘is’ the diagnostic report, thus the values of data items present in attached diagnostic report that are also present in the structured data and the document wrapper (i.e. the ClinicalDocument) will be semantically equivalent.

The document wrapper will also contain unique technical data items necessary to manage the 'document' in a document storage and management system such as the MHR system.

Technical data items for document management systems These items are implementation-specific: instance identifiers, instance versioning, etc.:

1. These items will be discussed in terms of CDA. The CDA implementation guide will address those technical data items that are part of the clinical document instance
2. As yet a FHIR document exchange mechanism or document storage and management system isn't defined by the Agency. The FHIR implementation guide will not address these items (it will only address the logical clinical document bits).

Technical data items for document management systems Confirmed that guidance on the implementation requirements for relationships to other instances (e.g. obsoleting or superseding an older version or supplying a corrected later version) is not to be defined and handled by the implementation guide.

Utilising the new approach to conformance artefacts, Document wrapper templates and profiles have been split into two:

1. one CDA template and one FHIR profile that defines how these technical data items are required to work to exchange any conformant CDA clinical document in Australia (sits above P2P & MHR); this offers a single source of truth from which to have infrastructure / technical compliance to the Agencies definition of a CDA document in Australia
2. one CDA template and FHIR profile for the logical clinical document bits

Technical data item requirements:

• confidentialityCode - continue with standard treatment, using nullFlavor in CDA and prohibit in FHIR
• instance identifier - mandate for the document management system
• version number - mandate for the document management system
• language code - mandate "en-AU"
• document status: mandatory, with full code set allowed in the respective wireformats
  • e.g. in CDA: final, interim and withdrawn.
• specific document logical templates will likely not include withdrawn, as it is not a use case our documents support
• dateTime - mandate for the document management system continue with standard treatment
  • noted that CDA does not contain date time of CDA generation - it contains clinically relevant date time for the document (aka if the diagnostic report was issued 5 years ago, and was converted to CDA and uploaded yesterday, the ClinicalDocument.effectiveTime is from 5 years ago)
• title - mandate
• subject of document - continue standard treatment, mandatory and maximum of one
• author - continue with standard treatment in the technical sense, allow full CDA cardinality of mandatory and multiple.
• template for logical document will handle constraining to one and only one as appropriate for particular document types
  • continue to be silent on any other technical requirements such as realmCode / jurisdiction

The logical clinical document bits Along with the implementation-specific requirements necessary for a document management system there is also logical document that collates the logical data into a single coherent statement of meaning, establishes its own context such as the subject and author, and who attests to the document and divides the document up into a series of sections, each with their own narrative.

• type, subtype, and title
• subject
• authoring - author and authoring datetime
• attesting - attester and datetime
• custodian
• sections - section narrative
  • entries and use of emptiness structures or clinical assertions of absence