Documents

Data Model Overview

The metadata associated with patient care documents will be stored as a dedicated DocumentReference resource and, where appropriate, as a linked Encounter resource specific to the documented event. Many aspects of the metadata will be achieved through referencing of pre-existing administrative entities such as Device, Organisation and PractitionerRole. The creation or update of a DocumentReference instance will be associated with one or more Provenance resource instances, targeting the specific version of the DocumentReference instance.

The diagram below provides an overview of the required FHIR resources and how they can be interconnected to support a range of document metadata use cases. It shows that there are multiple places in which key event metadata such as Event site and Event location may be stored, dependent upon the specific use case. See the dedicated clinical scenario guidance for recommendations on the tailoring of the data model for different circumstances.

The FHIR data model consists of the following resources:

FHIR Resources

Device

The source system that provided the document details will be represented as a Device resource instance.

DocumentReference

Each DocumentReference resource instance represents a distinct document. In addition to information about the document, the DocumentReference provides a URL to the location from which the document can be retrieved. For those familiar with the Welsh Care Records Service, the DocumentReference instance represents the document supersession set.

Encounter

The documented event may be represented as an Encounter resource instance. In this case applications may access the referenced Encounter to retrieve the event details including document metadata such as event site and event organisation.

Location

There are two roles that may be fulfilled by a location, as represented by a Location resource instance. The first is the event site, and the second a more specific event location. For example the event location may be a specific ward within a hospital identified as the event site.

Organization

There are two roles that may be fulfilled by an organisation, as represented by an Organization resource instance. The first is the custodian organisation: the health board responsible for the document, which relates to one of their patients. The second role is as the event organisation i.e. the health board that provided care via the documented event.

Patient

Documents will typically have a subject that is a Patient resource instance.

PractitionerRole

Ideally the staff involved with the document as author, attester or committer can be referenced via a PractitionerRole resource instance. This facilitates access to richer contextual data than if the Practitioner resource is directly referenced.

Provenance

The Provenance resource provides an audit trail of when a specific document version was committed and by whom. If patient demographics are also submitted, these are captured in an additional Provenance instance that specifically captures demographics as recorded, to support retrospective analysis. See the dedicated guidance page for clarification of the purpose and use of the Provenance resource:

Supporting Legacy Metadata

Legacy care documents may have associated metadata that are not explicitly covered by the formal content of the DocumentReference or its related resources. In order to avoid data loss on migration, a complex extension has been included called documentAttribute. To mitigate against uncontrolled proliferation of document metadata, the attribute name code has been locked down to known attribute names from the Welsh Care Records Service that are not addressed in more formal ways.


Clinical Scenarios / Examples

Encounter-based Document

Overview

This scenario addresses the use of FHIR resources to fulfil the metadata requirements for a document that is based on an event represented as an Encounter resource. An example might be an outpatient clinic attendance.

Implementation Guidance

In this case, the document metadata specific to the documented event belong to the Encounter resource, so the recommendation would be to avoid storing them within the Document Reference resource instance as this would be data duplication:

  • Event Date and Time
  • Event Organisation
  • Event Site
  • Event Location
  • Event Senior Responsible Clinician

Logical Model

The diagram below shows how the FHIR resources work together to provide the event and other metadata for a document that fits this clinical scenario.
Document-metadata-encounter-based

Event-based Document

Overview

This scenario addresses the use of FHIR resources to fulfil the metadata requirements for a document that is based on an event that is not represented as an Encounter resource. An example might be a historic outpatient clinic attendance.

Implementation Guidance

In this case, the document metadata specific to the documented event must be explicit within the DocumentReference resource instance. The recommendation is to use the relevant sub-elements of the DocumentReference.context backbone element to capture the following event metadata:

  • Event Date and Time
  • Event Organisation
  • Event Site
  • Event Location
  • Event Senior Responsible Clinician

Logical Model

The diagram below shows how the FHIR resources work together to provide the event and other metadata for a document that fits this clinical scenario.
Document-metadata-event-based

Document not Event-based

Overview

This scenario addresses the use of FHIR resources to fulfil the metadata requirements for a document that is pertinent to the clinical record but not based on a clinical event. An example might be a statement of medical insurance cover.

Implementation Guidance

In this case, the following metadata items can be omitted:

  • Event Date and Time
  • Event Organisation
  • Event Site
  • Event Location
  • Event Senior Responsible Clinician

Logical Model

The diagram below shows how the FHIR resources work together to provide the metadata for a document that fits this clinical scenario. The model is simplified to omit the event metadata.
Document-metadata-not-event-based

Examples

DocumentReference

The following examples represent DocumentReference resources for the three scenarios outlined in the preceding sections:

Provenance

The following examples represent Provenance resource instances for a newly created DocumentReference for which patient demographics were provided:


Document Error Workflow

The DocumentReference resource provides explicit support for two distinct error workflows - misfiling and revocation. In both cases the documents cannot be removed from the patient record as they may have been seen and acted upon. For end applications there may be a need to display the documents differently and to restrict related processing.

Misfiling workflow

Misfiling is a two step process followed when a user identifies that a document has been added to the wrong patient record. In the first step the user proposes that the document is misfiled. The second step is for a user to review and accept or reject the misfile proposal. The workflow and the recommended use of status and dedicated error-related elements at each stage are illustrated below.
Document-misfile-workflow

The following examples represent a document that is valid and the same document after it has been misfiled:

Revocation workflow

Revocation is a single step process to flag the document as revoked. A document can be revoked for a variety of reason, such as that it is no longer valid. For example a “Do not attempt resuscitation” instruction may be actively revoked by the patient. The use of status and dedicated error-related elements in the case of revocation is illustrated below.
Document-revocation-workflow