STU 3 Ballot

This page is part of the FHIR Specification (v1.6.0: STU 3 Ballot 4). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

2.37.11 XDS profile for Document Reference

2.37.11.1 Scope and Usage

The XDS profile describes in detail how the DocumentReference and DocumentManifest resources are used in the context of XDS. The two resources may be used as a facade to an existing XDS server, such as is used for the IHE MHD specification, or it can be used the other way around, where the XDS functionality is implemented using a FHIR based server as the storage mechanism.

2.37.11.2 Background and Context

The FHIR DocumentReference and DocumentManifest resources are based on the functionality defined by XDS, but they differ from XDS in some significant ways:

  • SubmissionSet = DocumentManifest, and DocumentEntry = DocumentReference. These renamings are appropriate in the wider context of how these resources are used in FHIR.
  • There is no direct association between a transaction and a DocumentManifest in FHIR, however a transaction may be used to ensure consistent commits.
  • Patient, Author and Authenticator are represented using standard Patient and Practitioner resources.
  • The functionality expressed through the XDSFolder resource is implemented using the List resource, or by tags.
  • Some XDS specific fields that are not generally applicable do not have matching elements in the DocumentReference resource, and are implemented as FHIR extensions.

2.37.11.2.1 Mapping Notes

The formal mappings are found below, but this section provides some additional description to help understand the relationships between the XDS transaction and the FHIR resources.

Patient The following attributes of patient are all found in the Patient resource:
  • patientId: Patient.identifier. The patientId has a use of "official"
  • sourcePatientId: Patient.identifier. The sourcePatientId has a use of "usual"
  • PatientInfo: Various properties as appropriate in the Patient resource
Author The following attributes of author are all found in the Practitioner resource:
  • authorInstitution: Practitioner.organization (and possibly Organization.identifier and Organization.name in a target Organization resource)
  • authorPerson: Practitioner.identifier and Practitioner.name
  • authorRole: Practitioner.role
  • authorSpecialty: Practitioner.specialty
  • authorTelecommunication: Practitioner.telecom
LegalAuthenticator In XDS, policy is that there is a "legal authenticator", and this is represented in the DocumentReference.authenticator element (it has a more general meaning so it's not so restrictive outside the XDS use case)
Identifiers The different identifiers go in different places, depending on the nature of the identifier:
  • entryUUID: Logical Id of the DocumentReference/DocumentManifest resource
  • uniqueId: DocumentReference.masterIdentier - the identifier of the document itself
  • homeCommunityId & repositoryUniqueId: These data items are not needed in a FHIR context because the document reference is directly available. If it's still needed for XDS service calls, use a service parameter by the name same name. Where the homeCommunityId is needed in a manifest, an extension is defined (http://hl7.org/fhir/StructureDefinition/xdshomeCommunityId, which contains a uri).
Availability Status

Approved (available for patient care): DocumentReference/Manifest.status = current

Deprecated (obsolete): DocumentReference/Manifest.status = superseded
Comments The information that currently is found in the comments slot is placed in the equivalent resource narrative (for human consumption)
Folders There is no direct equivalent between to XDS folders in FHIR. Workflow associated with a document reference may be managed using Tags, or documents can be explicitly grouped using the List resource.

2.37.11.2.2 Handling Updates

The RESTful API allows updates to the DocumentReference/DocumentManifest resources that the document repository is built on.

In the context of XDS, servers SHALL ensure that the masterIdentifier element of a DocumentReference is never changed after the resource is created. When a new document is created, a new DocumentReference SHALL be created. The server SHOULD ensure that the supersedes element is correctly populated, along with the status of any existing documents that are being superseded. It MAY choose to do this by requiring the clients to perform this operation, or by simply performing the operation itself.

When used with XDS, updates to the document reference resource are only performed to correct the details associated with the document description - other identifiers, context, location, etc. The document itself, the hash value, etc., SHOULD never change. Servers MAY choose to maintain the repository of resources so that there is only one DocumentReference for each original document (unique masterIdentifiers), but doing so will require some way of resolving conflicting claims around the document metadata from different submitters.

In order to implement the XDS profile, a server SHALL keep a full version history of DocumentReference, DocumentManifest, Patient, and Practitioner resources. This allows for audit investigations, and also replication using standard pub/sub arrangements.

2.37.11.3 Content

Profiles:
XDSDocumentReferenceXDSDocumentEntry
XDSDocumentManifestSubmissionSet
Examples:
XDS example

XDS example