Appendix A

Appendix A - XD Metadata

The Metadata for Document Sharing (XD Metadata) is defined by IHE and serves to

provide context for the clinical information being exchanged
provide information about the type of clinical activity that resulted in the creation of the exchanged objects
assist with storing, organizing, and locating documents

A.1 XD Metadata Objects and Associations

The XD Metadata is organized in objects. The relationships of the objects with each other, the overall structure, and the unit of exchange, is the Submission Set. It contains Document Entries, Folders and Associations. Each of the underlying objects and structures (except for Slots) are identified by an id XML attribute, which must be either a globally unique identifier like an OID or UUID, or a symbolic identifier, unique within the submissions set.

A Document Entry represents a document, or content structure of a particular type, and a Folder is a logical collection of document entries.

Associations link a source to a target. Has Member associations describe a Contains type of relationship from source to target. Only a Submission Set or a Folder can be the source. A Submission Set is never a target. Associations from Folder to a Document Entry can be a target of a Has Member association themselves.

A.2 XD Metadata Components

The metadata for an object consists of several building blocks. The XD Metadata makes use mostly of Slots, Classifications and External Identifiers.

A.2.1 Slot

A Slot is a named string list that provides metadata for an object in a name/value list pair. The characteristics of a slot are:

Contains a name, and one or more values
Name is a string without spaces
Value is limited to 256 characters

Example:

<rim:Slot name="slotName">
     <rim:ValueList>
          <rim:Value>String, no longer than 256 characters</rim:Value>
     </rim:ValueList>
</rim:Slot>

A.2.2 Classification

Classifications are used to represent either coded information from a given terminology (e.g. submission set content type code), or a logical structure (e.g. submission set author). When a classification is used to represent a code from a given terminology, it contains the following components

classificationScheme – what kind of information is represented by the code (e.g. content type); a pre-defined UUID
nodeRepresentation – the actual code
Name – the display name of the code
codingScheme – a slot, designating the terminology

Example: content type code for the Submission Set, using LOINC code 57133-1

<!-- classificationScheme attribute defines this as a content type code -->
<Classification id="Class01" 
 objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" 
 classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
 classifiedObject="Submission01" 
 nodeRepresentation="57133-1">
     <Slot name="codingScheme">
          <ValueList>
               <!-- The OID describes LOINC as the source of the code -->
               <Value>2.16.840.1.113883.6.1</Value>
          </ValueList>
     </Slot>
     <Name>
          <!-- The human readable description of the code -->
          <LocalizedString value="Referral" />
     </Name>
</Classification>

A.2.3 External Identifier

External Identifiers are used to provide globally unique identifiers for the metadata objects and some of their attributes. They contain the following components:

identificationScheme – what kind of object is being identified (e.g. document unique ID); a pre-defined UUID
registryObject - what metadata object this identifier is related to (e.g. the submissions set, a specific document entry). The content of this XML attribute is the value of theid of that object.
value - the actual unique identifier
Name - a predefined symbolic name for the identifier

Example: Document unique ID

<ExternalIdentifier id="d951d9a3-bf18-4fd0-a2cc-a949b403b024" registryObject="Document01" 
 identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
 value="1.2.840.114350.1.13.328.1.7.8.688883.43394">
     <Name>
          <LocalizedString xml:lang="en-us" charset="UTF-8" value="XDSDocumentEntry.uniqueId" />
     </Name>
</ExternalIdentifier>

A.3 XD Metadata Attributes

The following sections describe all metadata attributes and provide context for their use. Please refer to section 6 for an overview of the implementation requirements for 360X.

A.3.1 Submission Set - the packing slip

Metadata Attribute	Purpose within 360x	360x Source	Value	Information
author	Represents the provider (person or institution) that authored the document.	R(*)	This attribute does not have a simple value but contains sub-attributes.	If present, according to the IHE framework, the authorPerson sub-attribute is required. According to the XDR and XDM specification, the authorTelecommunication is required and MUST represent the message sender. This guide requires that the authorTelecommunication be populated with the address by which subsequent communications are sent. In addition, the authorPerson OR authorInstitution MUST be populated.
intendedRecipient	Represents the provider (person OR institution) for which the referral is intended (Referral Recipient).	R	MUST contain a string of type XON\|XCN\|XTN of which the XTN portion being required. Max length is 256 characters.	MUST indicate the one and only one message receiver. While this attribute allows multiple values, support for additional recipients may vary and is not guaranteed to be supported.
patientId	The patientId as known to the recipient organization, which is used to match patients and/or referral content across disparate systems.	R(*)	Single Value with two components (Id Number and Assigning Authority). The required format is IdNumber^^^&OIDofAA&ISO.	Represents the primary subject of care whose longitudinal records is being reflected. MUST be identical to the Document Entry patientId. The patientId is typically the patientId as known to the recipient organization of the payload. This attribute is absolutely necessary for improving the ability to automate the workflow. Based on the complexity with this attribute, the contextual examples should be used to populate this value appropriately.
referenceIdList	The referralId (Order Number). MUST be present to uniquely identify 360x referral.	R(*)	Single Value. The value shall contain the referral ID and the Assigning Authority. For example: 201300001^^^1.2.3.4.5.6^urn:ihe:iti:xds:2013:referral	Uniquely identifies the referral in an attempt to "thread" the various communications necessary to close the loop.
contentTypeCode	Indicates this is a referral request, progress note, or summary.	R(*)	57133-LOINC code	The code specifying the type of clinical activity that resulted in placing these XDS Documents in this XDS-Submission Set. When available, implementations SHOULD draw from HITSP C80, version 2.0.1 table 2-144.
sourceId	Identifies the instance of the creating entity (i.e. source system) that contributed the SubmissionSet.	R	Single Value. OID.	Per the IHE specification, if a "broker" is involved or the system that constructs the message vs. generates the content, the sourceId shall be different from the entity that contributed the document(s). This implementation guide suggests keeping these identifiers equal regardless if a broker is involved.
entryUUID	A globally unique identifier primarily intended for internal document management purposes.	R	UUID	Must be a unique value internal to this transaction.
submissionTime	Point in time when the Submission Set was created.	R	UTC date/time YYYYMMDDhhmmss. Max length is 256 characters.	SHOULD be the value of the Date header.
uniqueId	Globally unique ID for the submission set assigned by the creating entity.	R	OID	SHOULD use a unique ID extracted from the content, if a single value can be determined. If not, implementations SHOULD use a UUID generated from the transaction. This value must be different than the uniqueId specified on the Document.
title	Subject of the message.	O	Text. MUST contain the substring "XDM/1.0/DDM+360x". Less than 256 characters.	Recommended to be the Subject of the message
comments	Not needed	O	Free form text. Unbounded max length.	Comments associated with the submission set. Use specific to XDS affinity domain
availabilityStatus	Not needed	O	If available, the value should always be "urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"	The lifecycle status of the submission set.
homeCommunityId	Not needed	O	64 character OID in URI syntax	A globally unique identifier for a community.
limitedMetadata	Indicates whether the submission set was created using the less rigorous requirements of metadata.	O	UUID

A.3.2 Document Entry - metadata object representing and describing the document or content (i.e. C-CDA or HL7)

Metadata Attribute	Purpose within 360x	360x Source	XDS Source	Minimal Metadata Source	Value	Information
author	Represents the provider (person or institution) that authored the document.	R2	R2	R2	This attribute does not have a simple value but contains sub-attributes. These sub-attributes include: authorInstitution, authorPerson, authorRole, authorSpecialty and authorTelecommunication.	If supplied, MUST indicate the document's author, which may be different from the message sender. At least an authorPerson, authorTelecommunication, or authorInstitution sub-attribute shall be present when the author attribute is included in the metadata. * This is only required when the document is a C-CDA.
availabilityStatus	Not needed	O	O	O	If available, the value should always be: "urn:oasis:names:tc:ebxml -regrep:StatusType:Approved"	The lifecycle status of the DocuentEntry. No mention in the Direct specs
classCode	Specifies the particular type of document (e.g. Consultation note, Subsequent evaluation note, etc. for C-CDAs).	R(*)	R	R2	Code. Single value.	SHOULD draw values from HITSP C80, version 2.0.1, table 2-144.
comments	Comments associated with the document.	O	O	O	Free form text. Unbounded max length.	No mention in the Direct specs
confidentialityCode	Code specifying the level of confidentiality of the document	O	R2	R2	Code. Multiple Values.	SHOULD draw values from HITSP C80, version 2.0.1, table 2-150. Implementations SHOULD NOT use codes that reveal the specific trigger causes of confidentiality (e.g., HIV).
creationTime	Represents the time the author created the document.	R(*)	R2	R2	UTC date/time YYYYMMDDhhmmss. Single Value. Max length of 256 characters.	MUST NOT use transaction-related dates/times, including the value of the RFC 5322 Date header. Implementers should look to use the header values for C-CDAs or the time in the messsage header for HL7.
entryUUID	A globally unique identifier used to identify and manage the document entry internally.	R	R	R	UUID. Unbounded max length.	Must be a unique value internal to this transaction.
eventCodeList	Represents the main clinical acts being documented.	O	O	O	Code. Multiple Values.	List of codes representing the main clinical acts being documented. No mention in the Direct specs. In some cases, the event is inherent in the typeCode. An event can further specialize the act inherent in the typeCode. When defining the value sets for eventCodes, they should not conflict with the values inherent in the classCode, practiceSettingCode or typeCode as such a conflict would create an ambiguous situation.
formatCode	Globally unique code specifying the format of the document.	R(*)	R2	R2	Code. Single Value. Any valid URN may be used as a formatCode.	SHOULD draw values from HITSP C80, version 2.0.1, table 2-152, when the specific listed codes apply
Hash	Hash key of the document which can be used to determine if the document has been altered.	O	R	O	Calculated with SHA1 algorithm. Single Value. Max length is 256 characters. The endcoding is the Lexical representation of hexBinary([0-9a-fA-F]). RFC 3174.	The value is coded as a case-insenstivite single value within an ebRIM Slot in the DocumentEntry. No mention in the Direct specs.
healthcareFacilityTypeCode	Represents the type of organizational setting of the clinical encounter during which the documented act occurred. The healthcareFacilityTypeCode shall be equivalent to or further specialize the value inherent in the typeCode.	O	R2	R2	Code. Single Value.	SHOULD draw values from HITSP C80, version 2.0.1, table 2-146. Implementations SHOULD populate mapped by configuration to sending organization.
homeCommunityId	Globally unique identifier for a community	O	O	O	OID. URN. Unbounded max length.	No mention in the Direct specs
languageCode	Specifies the human language of the character data in the document	O	R2	R2	Code. Single Value. Max length is 256 characters. The values of the attribute are language identifiers as described by the IETF (Internet Engineering Task Force) RFC 5646.	Coded identifiers as described by the IETF RFC 3066, conformant with IHE requirements.
legal Authenticator	Represents a participant within the authorInstitution who has legally authenticated or attested the document.	O	O	O	XCN (e.g., ^Welby^Marcus^^^Dr^MD). Single Value. Max length is 256 characters.	No mention in the Direct specs
limitedMetadata	Indicates whether the document entry was created using the less rigorous requirements of metadata	R	O	R	Single Value.	No mention in the Direct specs
mimeType	MIME type of the document.	R	R	R	String. Single Value. Unbounded max length.	The C-CDA MUST have a MIME type of text/xml. The HL7 document MUST have a MIME type of x-application/hl7-v2+er7
objectType	The type of DocumentEntry. For 360x purposes, the value will always be Stable	R	R	R	UUID. Max length is unbounded.	Expected value: urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1
patientId	The subject of care of the document. Shall match the value of the patientId attribute in the SubmissionSet	R2	R2	R2	Single Value. Contains an assigning authority domain id and an id from the assigning authority.	Formatted as a HL7 CX as described in ITI TF-3 Table 4.1-3 As a conditional value, the patientId is only expected to be set on return messages (those generated by the receiving provider). The patientId should always be equal to the value sent in the sourcePatientId of the original referral request.
practiceSettingCode	Specifies the clinical specialty where the act that resulted in the document was performed.	O	R2	R2	Code. Single value.	SHOULD draw from HITSP C80, version 2.0.1, table 2-149 which is a list of members of the value set in table 2-148. These are typically SNOMED CT codes vs. NUCC codes.
referenceIdList	The referral ID.	O	O	O	Supports multiple values but there should never be more than one value. Max length is 256 characters for each value.	This list is intended to contain internal and external CXi encoded identifiers. No mention in the Direct specs.
repositoryUniqueId	The globally unique identifier of the repository where the document is stored.	O	O	O	OID. Single Value. Max length is 64 characters.	The globally unique, immutable, identifier of the repository where the document is stored. No mention in the Direct specs
serviceStartTime	Represents the start time the service being documented took place.	O	R2	R2	UTC date/time YYYYMMDDhhmmss. Single Value. Max length is 256 characters.	This may be the same as the encounter time in case the service was delivered during an encounter. No mention in the Direct specs
serviceStopTime	Represents the stop time the service being documented took place.	O	R2	R2	UTC date/time YYYYMMDDhhmmss. Single Value. Max length is 256 characters. The serviceStartTime <= serviceStopTime.	This may be the same as the encounter time in case the service was delivered during an encounter. No mention in the Direct specs
Size	Size in bytes of the document	O	R	O	Integer. Single Value. Max length is 256 characters.	No mention in the Direct specs
sourcePatientId	Represents the subject of care medical record Identifier(e.g., PatientId) in the local patient Identifier Domain of the document source.	R2	R2	R2	Single Value. Shall contain zero or one value. Contains an assigning authority domain id and an id from the assigning authority. Max length is 256 characters.	Formatted as a HL7 CX as described in ITI TF-3 Table 4.1-3. This field is only required for the first communication by each side. Subsequent communications do not require this field to be populated.
sourcePatientInfo	Demographics information of the source patient at the time of submission.	O	R2	R2	Multiple Values. Max length is 256 characters for each value. Shall contain zero or one value list of demographic elements, where each element in the list is identified by fields from the HL7 PID segment	This information typically includes: patient first and last name, sex, and birth date. Formatted as defined in ITI TF-3 Table 4.1-5
Title	Title of the document	O	O	O	Free form text with max length of 128 characters.	The title is often supplemented with the classCode. Represented in ebXML as the "value" attribute of the LocalizedString element within the ebRIM Name structure. There can be only one ebRIM Name structure per DocumentEntry. No mention in the Direct specs.
typeCode	Specifies the precise kind of document.	R(*)	R2	R2	Code. Single value. Values should consist of: 34133-9, 11488-4, 34117-2, 18842-5, 11504-8, 28570-0, or 11506-3 for C-CDAs. 019, 041, S12, or S26 for HL7 documents.	SHOULD draw values from HITSP C80, version 2.0.1, table 2-144 and SHOULD be the same value as classCode.
uniqueId	The globally unique identifier assigned by the document creator to this document.	R	R	R	OID. Single value. Max length is 256 characters.	SHOULD use a unique ID extracted from the content, if a single such value can be determined. If not, implementations SHOULD use a UUID URN, generated for the transaction. This value MUST be different from the uniqueId specified on the Submission Set
URI	The URI for the document, which consists of a relative path in the XDM structure to the file.	R(*)	R	O	String. URI. Single value. Max length is 256 characters. RFC 2616..	No mention in the Direct specs

Space shortcuts

Page tree