Care Documents

The scope of this guidance is the storage of metadata for documents related to the care of individual patients as part of their individual health care records.

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 Location, Organization 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 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:

Note that not all of these resource types are explicit in the model above. Where alternative resource types may fulfil the particular role, the diagram illustrates the one that is preferred or most commonly used. At the current phase the document roles of author, authenticator, committer and senior responsible clinician can all be fulfilled by alternative resource types as specified in the applicable resource profile. The same resource instance may perform multiple roles in relation to the same document.

FHIR Resources

Device

In the case of autogenerated documents, a Device resource instance may be referenced as the document author.

DocumentReference

A DocumentReference resource is the equivalent of a Welsh Care Records Service supersession set. As such it can have many versions with the same wcrsSupersessionSetId identifier, but each with a different wcrsDocumentId identifier. Earlier versions can be retrieved as a version history. As part of the document metadata, the document reference contains “attachment” details which should include at least the applicable mime-type and a pointer to the URL where the document is stored (or the data binary prior to document storage).

A DocumentReference resource may be related to other distinct DocumentReference resources, for example where one document is an approval slip that “signs” another document, or where a document presenting a clinical summary at a consultation “replaces” the distinct clinical summary document from the prior consultation.

Each DocumentReference resource should have a meta.source element that identifies the source system using its application identifier (OID). To support seamless searching across new and legacy data in the short to medium term, meta.tag instances can be used to store searchable document attributes.

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. The patient may also perform the role of document committer or author.

Practitioner

The Practitioner resource carries details of the individual staff member, irrespective of their job role. A Practitioner resource instance can be involved as author, authenticator, committer or senior responsible clinician.

PractitionerRole

Ideally the staff involved with the document as author, authenticator, committer or senior responsible clinician 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:

RelatedPerson

A RelatedPerson resource may be referenced in the role of document committer or author.

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, and to support continued acces to the data in the transition phase, these document attributes will be stored as meta.tag elements. Each will have a .system value that uniquely identifies the .display value within the tag. For reasons of continuuity, the system value will be constructed using the same approach as the SOLR software that continues to contribute to the transition architecture. For example:

  • For SetSequenceNumber, .system = "seqno"
  • For document attribute DocumentSubType, .system = "docattr_documentsubtype".

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.

This is the preferred approach for the submission of documents to the NHS Wales Care Documents Service.

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 based on an event that is not represented as an Encounter resource.

This scenario is not supported for the submission of documents to the NHS Wales Care Documents Service.

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 including an earlier document referenced from the third example:

Encounter

The following example illustrates how a minimally populated Encounter resource can be used to convey the event-related document metadata such as event date and time, event organisation, event site, event location and senior reponsible clinician:

DocumentReference Bundles

The following examples represent DocumentReference resources as message bundles:

Provenance

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


Care Document Versions

How versioning works in WCRS

In the Welsh Care Records Service (WCRS), each new version of a document was represented as a separate record with its own unique wcrsDocumentId. These records were linked together only through a shared wcrsSupersessionSetId, which identified the supersession set to which all versions belonged. This way earlier versions of a record could be retrieved by locating the same suppersession set id.

How versioning works in FHIR

In FHIR all the versions of a document will be under the same DocumentReference resource. All versions are expressed as history versions of the same FHIR resource, not as separate resources.

  • The FHIR resource ID remains constant accross all versions.
  • Each update creates a new _history version of that same resource.

Document-version-handling

Document Error Workflow

There are occasions where a document is considered to be invalid. Such documents cannot be deleted as they may have been seen and acted upon. For end applications there may be a need to display these documents differently and to restrict related processing. In these cases the document will be clearly marked with a status of "entered-in-error". The storage of data associated with the error worklow will depend upon the applicable error process as covered in the sub-sections below.

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.

Guidance on the use of FHIR resources and elements to support the misfiling workflow and appropriate retrieval of affected documents will be provided at a future release.

Revocation workflow

Revocation is a single step process to flag the document as revoked. A document can be revoked for a variety of reasons, such as that it is no longer valid. For example a “Do not attempt resuscitation” instruction may be actively revoked by the patient.

Guidance on the use of FHIR resources and elements to support the revocation workflow and appropriate retrieval of affected documents will be provided at a future release.