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:

• Device
• DocumentReference
• Encounter
• Location
• Organization
• Patient
• Practitioner
• PractitionerRole
• Provenance
• RelatedPerson
  
  

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 represents a distinct document and its version history, equivalent to a "supersession set" (see the Care Document Versions section below). 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). 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.

A DocumentReference resource may be related to other distinct DocumentReference resources, for example where one document is an approval slip that “signs” another document.

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:

• Provenance Guidance

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 continuity, 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.

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.

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.

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 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.

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:

• Example Document Reference - Encounter-based
• Example Document Reference - Event-based
• Example Document Reference - Not event-based
• Example Document Reference - Expired Insurance Cover

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:

• Example Encounter - Documented Event (Diabetes Consultation)

DocumentReference Bundles

The following examples represent DocumentReference resources as message bundles:

• Example Message Bundle - Care Document Submit (Minimal Required CDR Data)

Provenance

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

• Example Provenance for DocumentReference creation
• Example Provenance for demographics as recorded with care document

Care Document Versions

Historically, the Welsh Care Records Service (WCRS) has served as the all-Wales repository for clinical documents. This role is being phased out under a planned migration of care documents and functionality into the FHIR-based Care Data Repository. The approaches taken to document version handing are different between WCRS and FHIR. This section explains the differences, and the approach taken to minimise disruption for client applications.

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 DocumentId. These records were linked together only through a shared DocumentSupersessionSetId, which identified the supersession set to which all versions belonged. A SetSequenceNumber on each document record clarified the order of document versions within the supersession set for easy identification of the latest, and to make explicit the save sequence order of prior versions. Some applications have needed to use and store and use their own identifiers and a business version to support local processing. These are known as external supersession identifiers and follow a common structure that uniquely identifies the issuing authority and the document. In summary:

• The DocumentSupersessionSetId remains constant across all versions.
• Each document version record has a unique DocumentId and a SetSequenceNumber to clarify the order of document versions.
• All document versions of a supersession set could be retrieved using the common DocumentSupersessionSetId.
• Local supersession set identifiers are supported via composite identifier ExternalSupersessionId, structured as [issuing authority]|[identifier].

How versioning works in FHIR

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

• The FHIR resource ID remains constant across all versions.
• Each update creates a new _history version of that same resource.
• All document versions of a supersession set could be retrieved by querying the specific resource id for its history.

The differences are illustrated in the figure below:

Minimising disruption during transition

For new FHIR-compliant applications submitting and retrieving care documents, the FHIR id and version history will fulfil the needs for retrieval and sequence identification. Many existing applications, however, are dependent up the current combination of identifiers as used in WCRS. This situation is expected to persist over a number of years. The following steps have been taken to support processing during the transition to a FHIR-based application landscape for care documents:

• The new Care Documents Service will continue to generate supersession set identifiers and document identifiers for submitted documents, following the pattern used by WCRS.
• The DataStandardsWales-DocumentReference profile has dedicated identifier slices (and associated naming systems) for documentId, supersessionSetId and externalSupersessionSetId.
• The externalSupersessionSetId slice uses a similar approach to the WCRS ExternalSupersessionId, but substitutes the pipe separator beween issuing authority and identifier with a tilde, because pipe is a reserved character for FHIR processing.
• SetSequenceNumber is supported by a meta tag with .system = "seqno".
• The business version to supplement the externalSupersessionSetId can be captured using extension versionR5.

Document Error Workflow

There are occasions where a document is judged 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 current version of the document will be amended to provide the information required for end systems to recognise, mark and handle these documents appropriately.

The storage of status data and metadata associated with the error workflow 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 requests that the document should be misfiled. The second step is for a user to review and accept or reject the misfile.

The key metadata associated with misfiling are who (the user), when (the timestamp) and why (reason text at each step of the workflow). These details are stored in a Task resource with a code of “review-document-misfile” and an intent of “proposal”. The code and intent elements are fixed values throughout the misfile workflow.

At Step 1 the new Task has a status of “requested “ and the other metadata are captured in the Task as follows:

• focus is the applicable DocumentReference
• requester is the user that requested the misfile
• authoredOn is the timestamp applicable to the misfile request submission
• note contains the free text misfile reason (with user and timestamp)

The current document version is untrustworthy at this stage, so it carries a new meta tag of “errorstatus” with the display value “Potentially misfiled”. This tag can be used for marking of untrustworthy documents in accordance with applicable policy.

At Step 2 a reviewer decides whether to accept or reject the misfile request. In either case the task is updated as follows:

• status is set as “completed”
• lastModified is the timestamp applicable to the misfile review submission
• owner is the user that reviewed the misfile
• output is added with type “misfile-review-outcome”

In the case that the misfile is accepted

• the output.value is set to “accepted”
• an additional note instance contains the free text misfile accepted reason (with user and timestamp)
• the “errorstatus” meta tag on the DocumentReference is updated to a display value of “Misfiled”
• the status of the DocumentReference is updated to “entered-in-error”

In the case that the misfile is rejected

• the output.value is set to “rejected”
• an additional note instance contains the free text misfile rejected reason (with user and timestamp)
• the “errorstatus” meta tag is removed from the DocumentReference

The FHIR model changes resulting from the workflow steps are illustrated below:

The associated Provenance records for the creation, update and deprecation of the DocumentReference and Task resources are for audit purposes only.

Revocation

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 patient may wish to revoke a documented “Do not attempt resuscitation” instruction.

In the case of revocation, there is no workflow to manage via a Task resource. The act of revocation results in an update of the DocumentReference status to “entered-in-error” and the population of the meta tag “errorstatus” with the display value “Revoked”. In this case the who, when and why metadata are available in the related Provenance record, which has an activity code of “deprecate” to indicate that the record has become invalid or untrustworthy. A free text reason for revocation can be stored in the reason.text element of the Provenance record. The use of Provenance for typical revocation use cases is illustrated in the figure below: