4.1 Abstract Metadata Model

The metadata used in Document Sharing profiles is characterized by three types of objects and two types of Associations. In Figure 4.1-1, the three objects types and two Association types are depicted using UML to show their relationships. The three object types are:

• SubmissionSet – metadata describing a collection of Folders, DocumentEntries, and Associations submitted together.
• Folder – metadata describing a collection of related DocumentEntries.
• DocumentEntry – metadata describing a Document.

The two Association types are:

• HasMember – represents membership of an object in a collection. The four variations of HasMember are described in Section 4.1.2.
• Relationship – represents a relationship (such as a transform) between two Documents (represented by DocumentEntries). The Relationship associations are described in Section 4.1.2.

4.1.1 Metadata Object Types

There are three metadata object types supported by the Document Sharing metadata, as seen in Figure 4.1-1:

• SubmissionSet
• Folder
• DocumentEntry

4.1.1.1 SubmissionSet

The SubmissionSet can be thought of as the packing slip of a postal package. The details of the submission of DocumentEntries, Folders, and Associations are captured in the SubmissionSet object. The creating entity of each submission must group the DocumentEntries, Folders and Associations into a unique SubmissionSet. The Document Sharing profiles ensure that the documents are treated as a unit for submission purposes – either all of the documents arrive at their destination, or none of them do. An example of the use of a Submission Set is packaging all documents related to a care episode at the end of the hospital stay. The EHR system can submit the package. If the submission fails, none of the documents made it to their destination, and a retry is possible.

SubmissionsSets, once submitted, are a permanent record of the collection of submitted content. DocumentEntries may be bundled into a SubmissionSet by a human, machine, or process. For example, a laboratory machine might automatically submit results associated with a given lab order when they are ready, rather than waiting for a human to bundle them. SubmissionSets may contain DocumentEntries for multiple patients, but there are specific limitations on how this is done.

A SubmissionSet shall be the source of at least one Association of type SS-FD HasMember, SS-HM HasMember, and/or SS-DE HasMember.

4.1.1.2 Folder

Folder is a logical collection of DocumentEntries that are related in some way, such as to a clinical use case. A Folder is an arbitrary grouping relationship. Folders may be updated by multiple SubmissionSets sent from multiple departments that are submitting their DocumentEntry objects at different times. For example, a Folder may be used to collect the DocumentEntry objects for the patient’s documents that relate to an exam event, such as the exam request and prior results as well as the eventual exam results. As the exam results become available, the DocumentEntry objects can be added to the Folder for the exam records.

All DocumentEntries in a Folder shall be for the same patient.

The metadata structure discussed in this volume only specifies how to describe a Folder, and imposes no requirements for when or how a Folder should be used. Additional detail on when and how to use a Folder may be described in IHE profiles.

4.1.1.3 DocumentEntry

DocumentEntry is a metadata object representing a document. This metadata object does not contain the contents of the document; instead it contains attributes describing the document.

Details on how documents and metadata are managed depend on the requirements in a particular Document Sharing Profile.

For example, in XDS, a Stable DocumentEntry is the logical representation in the Registry of the Document that the Source submitted to a Repository. An entire document’s contents can constitute several megabytes, but can be described in a few kilobytes of metadata. The DocumentEntry metadata that describes the document are sufficient for the purposes of storing, organizing and locating documents for retrieval. Submitting a Stable DocumentEntry to a Registry in lieu of submitting the document creates a separation of concerns, allowing the Registry to specialize in indexing, while the Repository manages document storage.

There are two DocumentEntry Types: Stable DocumentEntry and On-Demand DocumentEntry. The following sections describe these types in detail.

4.1.1.3.1 Stable DocumentEntry

A Stable DocumentEntry contains metadata about an already created document available for retrieval. Each Stable DocumentEntry represents a single document. This document is stable because the contents have been effectively combined in the exact representation that will be returned in a Retrieve Document Set. A Stable DocumentEntry is an XDSDocument Entry with objectType equal to the UUID for Stable (see Section 4.2.5.2 for the UUID) and availabilityStatus equal to Approved or Deprecated. All metadata fields contain valid values.

The uniqueID metadata attribute of a Stable DocumentEntry identifies the specific document associated with the entry. It is used in a retrieve request to identify which specific document should be retrieved.

If the document returned on a retrieve request is CDA, it will have in the ClinicalDocument/id field in the HL7 CDA R2 document header the same value as the value of the DocumentEntry uniqueId.

4.1.1.3.2 On-Demand DocumentEntry

An On-Demand Document Entry provides a unique identifier which can be used to create an on-demand document which collects the latest, most recent available information at the time of retrieval. On-Demand Document Entries never reflect actual document content, but rather the potential for a document with the characteristics described in the metadata of the entry. An On-Demand DocumentEntry has objectType equal to the UUID for On-Demand (see Section 4.2.5.2 for the UUID) and availabilityStatus equal to Approved or Deprecated. An On-Demand Document Entry may be replaced and deprecated. If an On-Demand Document Entry is deprecated, the retrieval of that uniqueID may not have the most recent information and should return an error.

The uniqueID associated with an On-Demand Document Entry will never represent an actual document. A retrieve request specifying an On-Demand Document Entry uniqueID will return content identified by a uniqueID different than the specified uniqueID.

Every On-Demand Document Entry with the same uniqueID will refer to the same potential content. Actual content depends on the time of retrieval. The On-Demand Document Entry uniqueID is valid for as long as the entry has availabilityStatus equal to Approved. The holder of the uniqueID may re-use it in a retrieve request to get the latest information, without the need for an additional query.

When a retrieve request is received specifying an On-Demand Document Entry uniqueID, the responder may choose to persist the document generated as a result and allow the requestor future access to the metadata and document. This capability is declared through the Persistence of Retrieved Documents Option on the On-Demand Document Source and Responding Gateway Actors. The persistence refers not only to the saving of the content for re-use, but more specifically, to the ability of the requester to use retrieve to access that exact, possibly now historic, content and use a query to get metadata about the content.

Unless otherwise specified in a transaction, On-Demand DocumentEntry objects shall not be included in the transaction.

4.1.2 Association Types

Associations represent a link from the source object to a target object. Association objects describe all aspects of this link including references to source and target objects, the specific variant or name of the Association, and status and version information.

There are two types of Associations: HasMember and Relationship.

4.1.2.1 HasMember

This type defines a membership relationship between two objects. There are four variants of the HasMember Association depending on the types of the source and target object, see Figure 4.1-1.

SS-FD HasMember: An association from a SubmissionSet to a Folder identifies the Folder as a member of that SubmissionSet. It identifies the Submission Set that contained the initial creation of the Folder.

FD-DE HasMember: An association from a Folder to a DocumentEntry identifies that DocumentEntry as a member of that Folder. Folders have a many-to-many relationship to DocumentEntries (i.e., one folder may be linked to many DocumentEntries, and one DocumentEntry may be linked to many folders).

SS-HM HasMember: An association from a SubmissionSet to a FD-DE HasMember Association identifies that FD-DE HasMember as a member of that SubmissionSet. This makes it possible to identify the Submission Set in which the link between the Folder and the DocumentEntry was created.

SS-DE HasMember: An association from a SubmissionSet to a DocumentEntry identifies the DocumentEntry as a member of that SubmissionSet. The association between the SubmissionSet and the DocumentEntry provides information about the submission of the Documents. With this association of a DocumentEntry, you can find the Submission Set and know when the document was submitted, who the author of the submission was, and other information contained in the attributes of that SubmissionSet.

4.1.2.2 Relationship

This type defines an association between two DocumentEntry objects. There are five variants based on the type of relationship between the DocumentEntry objects.

Replace: indicates the replacement of a previous document with a new document.

Transform: indicates the transformation of a previous document into a new document.

Append: indicates a new document that appends to the contents of a previous document.

Transform and Replace: indicates a transformed replacement of a previous document with a new document.

Signs: indicates a new document is a signature for a previous document, as in new document signs previous document.

4.1.3 Metadata Attributes

Each metadata object holds attributes used for a variety of purposes. This section outlines the variety of purposes metadata attributes serve as well as a general description of each attribute. Detail about the coding of attributes is described in Section 4.2.3.

4.1.3.1 The Purpose of Metadata Attributes (Informative)

Metadata attributes can be categorized according to specific document-handling purposes. Each metadata attribute typically has more than one purpose, although some have only one. Metadata in the Document Sharing profiles has one or more of these purposes.

• Patient Identity – Attributes that describe the subject of the document. This includes patient Id, patient name, and other demographics.

• Provenance – Attributes that describe where the document comes from. These items are highly influenced by medical records regulations. This includes human author, identification of system that authored, the organization that authored, predecessor documents, successor documents, and the pathway that the document took.

• Security & Privacy – Attributes that are used by Privacy and Security rules to appropriately control the document. These values enable conformance to Privacy and Security regulations. These characteristics would be those referenced in Privacy or Security rules. These characteristics would also be used to protect against security risks to confidentiality, integrity, and availability.

• Descriptive – Attributes that are used to describe the clinical value, so they are expressly healthcare-specific. These values are critical for query models and enable workflows in all exchange models. The number of attributes in this category is kept to minimum so the metadata does not simply duplicate the document, and to keep disclosure risk to a minimum. Thus, the metadata attribute values tend to be from a small set of codes. Because this category is close to the clinical values it tends to have few mandatory attributes, allowing policy to choose to not populate. For healthcare documents, this is typically very closely associated with the clinical workflows but also must recognize other uses of healthcare documents such as quality reporting, public health reporting, authorized clinical research, patient access, etc.

• Object Lifecycle – Attributes that describe the current lifecycle state of the document including relationships to other documents. This would include classic lifecycle states of created, published, replaced, transformed, and deprecated.

• Exchange - Attributes that enable the transfer of the document for both push type transfers, and pull type transfers. These attributes are used for low-level automated processing of the document. These attributes are not the workflow routing, but rather the administrative overhead necessary to make the transfer. This includes the document unique Id, location, size, MIME types, and document format.

All metadata attributes describe the document and are not a replacement for the document. Not all metadata attributes are always required; indeed, some metadata attributes would be used only for specific uses. Care has been taken to limit the metadata to the minimum metadata attributes necessary to achieve the goal. Each metadata element was assessed for risks posed by exposing it as metadata. All metadata attributes are defined to assure that when the element is needed that it be consistently assigned and processed.

4.1.3.2 DocumentEntry Metadata Attributes

Table 4.1.3.2-1 provides a conceptual view of the metadata attributes associated with a DocumentEntry object. The table describes each attribute and provides a mapping between the attribute and the purposes that attribute is designed to support. The full DocumentEntry metadata attribute definition, including data type and coding is in Section 4.2.3.2.

Table 4.1.3.2-1: DocumentEntry Metadata Attribute Definition

DocumentEntry Metadata Attribute	Description	Patient identity	Provenance	Security & Privacy	Descriptive	Object Lifecycle	Exchange
author	The humans and/or machines that authored the document. This attribute contains the sub-attributes: authorInstitution, authorPerson, authorRole, authorSpecialty and authorTelecommunication.		X	X	X		X
availabilityStatus	The lifecycle status of the DocumentEntry			X		X
classCode	The code specifying the high-level use classification of the document type (e.g., Report, Summary, Images, Treatment Plan, Patient Preferences, Workflow).			X	X
comments	Comments associated with the document.				X
confidentialityCode	The code specifying the level of confidentiality of the document.			X
creationTime	The time the author created the document.		X	X	X	X
entryUUID	A globally unique identifier used to manage the entry.			X	X	X	X
eventCodeList	This list of codes represents the main clinical acts, such as a colonoscopy or an appendectomy, being documented.			X	X
formatCode	The code specifying the detailed technical format of the document.				X		X
hash	The hash of the contents of the document.			X
healthcareFacility TypeCode	This code represents the type of organizational setting of the clinical encounter during which the documented act occurred.		X	X	X
homeCommunityId	A globally unique identifier for a community.						X
languageCode	Specifies the human language of character data in the document.				X
legalAuthenticator	Represents a participant within an authorInstitution who has legally authenticated or attested the document.		X	X		X
limitedMetadata	Indicates whether the DocumentEntry was created using the less rigorous requirements of metadata as defined for the Metadata-Limited Document Source.		X		X	X	X
mimeType	MIME type of the document.				X		X
objectType	The type of DocumentEntry (e.g., On-Demand DocumentEntry).						X
patientId	The patientId represents the subject of care of the document.	X		X	X
practiceSettingCode	The code specifying the clinical specialty where the act that resulted in the document was performed (e.g., Family Practice, Laboratory, Radiology).		X	X	X
referenceIdList	A list of identifiers related to the document		X	X		X
repositoryUniqueId	The globally unique identifier of the repository where the document can be accessed.			X			X
serviceStartTime	The start time of the service being documented.			X	X
serviceStopTime	The stop time of the service being documented.			X	X
size	Size in bytes of the document.			X			X
sourcePatientId	The sourcePatientId represents the subject of care’s medical record identifier (e.g., Patient Id) in the local patient identifier domain of the creating entity.	X	X	X
sourcePatientInfo	This attribute contains demographic information of the source patient to whose medical record this document belongs.	X	X
title	The title of the document.				X
typeCode	The code specifying the precise type of document from the user perspective (e.g., LOINC code).				X
uniqueId	Globally unique identifier assigned to the document by its creator.			X			X
URI	The URI for the document.						X

4.1.3.3 SubmissionSet Metadata Attributes

Table 4.1.3.3-1 provides a conceptual view of the metadata attributes associated with a SubmissionSet object. The table describes each attribute and provides a mapping between the attribute and the purposes that attribute is designed to support. The full SubmissionSet metadata attribute definition, including data type and coding is in Section 4.2.3.3.

Table 4.1.3.3-1: SubmissionSet Metadata Attribute Definition

SubmissionSet Metadata Attribute	Description	Patient identity	Provenance	Security & Privacy	Descriptive	Object Lifecycle	Exchange
author	The humans and/or machines that authored the SubmissionSet. This attribute contains the sub-attributes: authorInstitution, authorPerson, authorRole, authorSpecialty, authorTelecommunication.		X	X	X
availabilityStatus	The lifecycle status of the SubmissionSet.				X	X
comments	Comments associated with the SubmissionSet.				X
contentTypeCode	The code specifying the type of clinical activity that resulted in placing the associated content in the SubmissionSet.		X	X	X
entryUUID	A globally unique identifier used to manage the entry.			X	X		X
homeCommunityId	A globally unique identifier for a community.						X
intendedRecipient	The organizations or persons for whom the SubmissionSet is intended.			X			X
limitedMetadata	A flag that the associated SubmissionSet was created using the less rigorous metadata requirements as defined for the Metadata-Limited Document Source.		X		X	X	X
patientId	The patientId represents the primary subject of care of the SubmissionSet.	X		X	X
sourceId	Identifier of the entity that contributed the SubmissionSet.		X	X	X
submissionTime	Point in time at the creating entity when the SubmissionSet was created.			X	X	X
title	The title of the SubmissionSet.				X
uniqueId	Globally unique identifier for the SubmissionSet assigned by the creating entity.			X			X

4.1.3.4 Folder Metadata Attributes

Table 4.1.3.4-1 provides a conceptual view of the metadata attributes associated with a Folder object. The table describes each attribute and provides a mapping between the attribute and the purposes that attribute is designed to support. The full Folder metadata attribute definition, including data type and coding is in Section 4.2.3.4.

Table 4.1.3.4-1: Folder Metadata Attribute Definition

Folder Metadata Attribute	Description	Patient identity	Provenance	Security & Privacy	Descriptive	Object Lifecycle	Exchange
availabilityStatus	The lifecycle status of the Folder.			X	X	X
codeList	The set of codes specifying the type of clinical activities that resulted in placing DocumentEntry objects in the Folder.		X	X	X
comments	Comments associated with the Folder.				X
entryUUID	A globally unique identifier used to manage the entry.			X	X		X
homeCommunityId	A globally unique identifier for a community.						X
lastUpdateTime	Most recent point in time that the Folder has been modified.			X		X
limitedMetadata	A flag that the associated Folder was created using the less rigorous metadata requirements as defined for the Metadata-Limited Document Source.		X		X	X	X
patientId	The patientId represents the primary subject of care of the Folder.	X		X	X
title	The title of the Folder.				X
uniqueId	Globally unique identifier for the Folder.			X			X

4.1.4 Submission Request

A Submission Request is a collection of metadata transferred between one Document Sharing Actor and another. A Submission Request shall contain:

1. One SubmissionSet object
2. At least one of the following:
   1. One or more DocumentEntry objects
   2. One or more Folder objects
   3. One or more FD-DE HasMember Associations
3. For each object in (2), one HasMember Association linking the SubmissionSet in (1) to that object.
4. Zero or more Relationship Associations

All objects included in a Submission Request shall refer to the same patient, whether the patientId attributes are populated or not. All populated patientId attributes in a Submission Request shall be the same.

Individual transactions or profiles may impose restrictions on the content.