XDM and XDR Vocabulary Bindings and Terminology Guidance

Guidance supplied in the Metadata and Payloads Framework acts as an overlay to further constrain the guidance already provided within XDR and XDM for Direct Secure Messaging Specification.

Vocabulary binding specifications apply to metadata for XD, Context IG, and FHIR metadata content types. Mappings between XD metadata concepts specified below and FHIR metadata content types are provided in Appendix 7.3 FHIR over Direct Metadata and Payload Guidance and Mapping Instructions Mappings between XD metadata and Context IG metadata are deferred while the re-write of the Context IG is under development.

SubmissionSet Metadata

The IHE specification describes the SubmissionSet object as the set of metadata that is common to all DocumentEntry objects it contains. The XDR and XDM for Direct Secure Messaging Specification defines the requirements within Direct for the various elements of the SubmissionSet metadata object. The Metadata and Payloads Framework does not further constrain those element cardinality requirements. The cardinality column in the table below is provided for convenience and is not considered the source of truth. The Metadata and Payloads Framework provides more explicit vocabulary binding expectations to align with standards like HL7 C-CDA and HL7 US Core and to clarify options for non-medical use cases such as social care, legal, administrative etc.

The SubmissionSet acts as a structure that organizes the one to many attached object(s) contained within it.

Metadata Element	Cardinality	Vocabulary Binding Strength	ValueSet (or Fixed Value)
author	1..*	n/a	The authorTelecommunication component (Section 6.2.2 of the XDR and XDM for Direct Secure Messaging Specification) SHALL contain the Direct address as it is or would be present in the SMTP MAIL FROM command. For the entire structure is in the HIE Specification Note, this author element does not necessarily contain the same author information as contained in the author element of all the DocumentEntry components. This metadata element answers the question, “Who compiled this set of documents?” not, “Who is the author of each document being sent?” Often times, the entity sending the message also is the entity compiling the set of documents.
submissionTime	1..1	n/a	In case of transformations from Internet Message Format (RFC 5322 ), implementations SHOULD use the value of the date header, the IHE definition notwithstanding.
contentTypeCode	1..1	Extensible	This often is a LOINC Document Ontology Code, but if the needed concept is not present in this value set (all codes from the LOINC DO codeSystem), codes from other codeSystems can be used as well. A derivative IG defines the allowable set of codes to be used in the field and defines the mapping between each specified contentTypeCodes and a code from the DirectTrust SERV_DESC Endpoint Use Case.
uniqueId	1..1	n/a	No additional constraints. The globally unique identifier for the SubmissionSet assigned by the entity that contributed the SubmissionSet.
title	0..1	n/a	This attribute MAY be used to convey the subject field of a wrapped RFC 5322 message.
intendedRecipient	0..*	n/a	No additional constraints. The telecommunication component SHALL contain the Direct address as it is, or would be, present in the SMTP RCPT TO command.
patientId	0..*	n/a	No additional constraints. This is populated by the message sender. It uses a patient identifier known to the receiver. The exact mechanism of how the sender obtains this knowledge is outside the scope of this framework. Options for gaining this knowledge include: Use of a record locator service Query the Intended Recipient Organization via Carequality and get the associated patient identifier NamingSystem uses HomeCommunityID OID Identifier is the returned identifier for the matched Pt. AssigningAuthority is the name of this Organization as published in the Carequality Directory. Subscriptions need more guidance in general (a good future use case for M&P), but suffice it to say that the subscription information would specify these three values for the patient at the Intended Recipient Organization (Subscription Holder) Naming System Naming System Identifier Assigning Authority
sourcePatientId	0..*		No additional constraints. This is populated by the message sender. It uses a patient identifier known to the sender.
sourcePatientInfo	0..1
referenceIdList	0..1	Extensible	[0..*] This attribute allows for the sending of additional context instance identifiers (e.g. accession numbers, encounter ID, referral ID, visit ID, etc.) that provide enhanced information for this transaction, allowing a set of transactions to be related to a single visit or referral, for example. https://hl7.org/fhir/valueset-identifier-type.html
limitedMetadata	0..1	n/a	No additional constraints.
Slot/@name	0..*		The SubmissionSet may contain any number of custom attributes as described in the IHE ITI Volume 2 specification in Section 4.2.3.1.6 Extra Metadata Attributes. Custom attributes defined in other DirectTrust Implementation Guides shall use a name containing a URN in the format urn:dt-org:<igNAME>.<other>.<pertinent>.<information> where the other pertinent information is determined by each IG. Implementation guides defined by other Standards Organizations SHALL use names that are different from urn:dt-org.
entryUUID	1..*		No additional constraints. Each entryUUID attribute is a globally unique identifier primarily intended for internal document management purposes. The UUID of each DocumentEntry is represented in a SubmissionSet.entryUUID.

Examples of identifiers that can be used in the referenceIdList

URN	Context Type
urn:ihe:iti:xds:2013:accession	This code shall be used when the identifier is an accession number. It shall contain: The accession number, and for accession values that are not globally unique, the Assigning Authority shall be included. For example when the accession number has a value of "2013001" and the assigning authority is "1.2.3.4.5.6" then the CXi value is 2013001^^^&1.2.3.4.5.6&ISO^urn:ihe:iti:xds:2013:accession
urn:ihe:iti:xds:2013:referral	Referral number and assigning authority shall be present. For example: 201300001^^^&1.2.3.4.5.6&ISO^urn:ihe:iti:xds:2013:referral
urn:ihe:iti:xds:2013:order	Order number and assigning authority shall be present. For example: 134467653^^^&1.2.3.4.5.42.1&ISO^urn:ihe:iti:xds:2013:order
urn:ihe:iti:xds:2013:studyInstanceUID	This code shall be used when the identifier is a DICOM Study Instance UID. CXi.1 shall contain the value of Study Instance UID. Only the CXi.1 and CXi.5 components shall be present. For example when the Study Instance UID has a value of "1.2.3.45.678" then the CXi value is 1.2.3.45.678^^^^urn:ihe:iti:xds:2016:studyInstanceUID
urn:ihe:iti:xds:2013:encounterId	Encounter identifier (also known as visit number) and assigning authority shall be present. For example: 245348841^^^&1.2.840.113619.6.197&ISO^urn:ihe:iti:xds:2015:encounterId