Appearance
3.5 Direct Message Packaging, Structured Payload, and Metadata Architecture
A MAP Transaction Instance is conveyed in one Direct message with exactly two MIME parts. MIME Part 1 carries the human-readable message body. MIME Part 2 carries exactly one Structured Package Payload containing exactly one SubmissionSet. The Structured Package Payload contains the information objects and supporting resources needed for the Shared Activity. Requirements for each representation are specified below and in the applicable Transaction Definition.
3.5.1 Independently Processable Workflow Unit
Each MAP Transaction Instance SHALL contain exactly one SubmissionSet representation and no more than one Workflow Activity Task, except where the applicable Transaction Definition requires a Task. It SHALL include exactly one primary information object and the other components required by the applicable Transaction Definition. The two MIME parts together constitute one independently processable Direct message.
For the FHIR metadata option, the current SubmissionSet SHALL be represented by the MAP SubmissionSet FHIR List profile defined in Appendix D, using List.mode=working. An identification-only List.mode=snapshot may be included as a separate information object only when specified by the applicable Transaction Definition.
3.5.2 SubmissionSet and Workflow Activity Task
The SubmissionSet is the authoritative package-level representation of the Shared Activity initiated by the Information Source in the current MAP Transaction Instance. SubmissionSet.purpose identifies that Shared Activity independently of whether a Workflow Activity Task is included. SubmissionSet.contentTypeCode classifies the principal information content. SubmissionSet.uniqueId identifies the logical Shared Activity and aligns with the designated Task.identifier when Task is present.
When a Workflow Activity Task is present, SubmissionSet and Task describe the same Shared Activity from complementary perspectives. Task.code SHALL be consistent with SubmissionSet.purpose, and the designated Task.identifier SHALL align with SubmissionSet.uniqueId. Patient and Context Instance identifiers repeated in the two representations SHALL be consistent.
| SubmissionSet | Workflow Activity Task | Common rule |
|---|---|---|
| contentTypeCode | Primary information object type | Default: SubmissionSet.contentTypeCode SHALL equal the Primary Information Object DocumentEntry.typeCode, including code and code system. Only an applicable UCTXDef MAY explicitly override this default, stating the alternative classification and processing implications. |
| uniqueId | designated Task.identifier, when Task is present | Same logical Workflow Activity Identifier; values SHALL match when Task is present. |
| purpose | Task.code | Same transaction identity. When Task is present, Task.code SHALL carry the same code and code system as SubmissionSet.purpose; purpose remains independently available without Task. |
| patient identity and matching metadata | Task.for (when Task is present) / information-object patient identity | Patient identity information intentionally duplicated across the workflow unit SHALL be consistent. SubmissionSet Patient Info provides the common package-level matching fallback defined in Section 3.6.1. |
| referenceIdList | Applicable Context Instance declarations | Package-level Context Instance identifiers SHALL be consistent with Task declarations when a Task is present and required by the Transaction Definition. |
SubmissionSet identifiers and membership SHALL follow applicable IHE semantics. MAP does not establish a separate SubmissionSet versioning, predecessor-linkage, or mandatory metadata-change Provenance lifecycle. For FHIR metadata, SubmissionSet.uniqueId maps to the IHE MHD List.identifier:uniqueId slice and SubmissionSet.entryUUID maps to List.identifier:entryUUID; neither is the FHIR logical resource identifier List.id. Membership is represented by the applicable IHE MHD List.entry references.
3.5.3 Workflow Activity Task
When included, the Workflow Activity Task provides a machine-processable expression of the sender’s requested activity, subject to the receiving endpoint’s declared capabilities, applicable transaction requirements, and processing policies. It identifies the Shared Activity, associates it with applicable Context Instance(s), carries transaction correlation when required, and conveys applicable Workflow Status instructions. These are workflow semantics rather than Direct transport controls. Inclusion of an optional Task does not itself require the receiving endpoint to implement Task interpretation or execution.
| Task concept | Common requirement |
|---|---|
| Workflow Activity identification | When present, Task.code SHALL carry the same transaction code and code system as SubmissionSet.purpose. The designated Task.identifier SHALL identify the same logical Workflow Activity as SubmissionSet.uniqueId. |
| Context Instance identifiers | Carries/correlates the Context Instances required by the Transaction Definition. The activity represented by the Task occurs in the context of those established Context Instances; the Task does not create a new Context Instance merely by referencing one. |
| Transaction correlation | Carries the identifiers needed to relate the Workflow Activity to an originating or otherwise related Transaction Instance when the Transaction Definition requires correlation. |
| structured payload acceptance reporting request | Task.input.type SHALL use DTCodeSystem code request-workflow-status with Task.input.valueBoolean. True requests successful structured payload acceptance reporting; false or absence does not suppress otherwise required failure reporting. |
| Workflow Status Update Endpoint | Task.input.type SHALL use DTCodeSystem code workflow-status-update-endpoint with Task.input.valueReference referencing an Endpoint resource. Eligible destinations and fallback are governed by the applicable reporting and capability rules. |
When a Workflow Activity Task is present, Task.code SHALL carry the same code and code system as SubmissionSet.purpose; the designated Task.identifier SHALL match SubmissionSet.uniqueId. Patient and Context identifiers repeated between the two representations SHALL be consistent.
When a Workflow Activity Task is present, workflow status instructions SHALL be carried in Task.input using DTCodeSystem codes request-workflow-status (valueBoolean) and workflow-status-update-endpoint (valueReference to an Endpoint resource). The former requests successful acceptance reporting when true; false or absence does not suppress independently required failure reporting. When TX8 reporting is required, an eligible Workflow Status Update Endpoint SHALL be resolved using the Task endpoints or the applicable no-Task fallback rule. SubmissionSet.uniqueId remains available for correlation. Task presence alone does not create a TX8 obligation.
An intermediary MAY act on the Workflow Activity Task only as permitted by the applicable Transaction Definition and declared capabilities. Updating a Task does not, by itself, establish a MAP-wide requirement to assign a new Task.id or create Provenance. Requirements for endpoint additions or reporting instructions belong in the applicable Transaction Definition.
No more than one Workflow Activity Task SHALL be carried per Transaction Instance. TX8 SHALL carry exactly one Workflow Activity Task. TX8-specific originating-package identification and snapshot requirements are specified in the send-workflow-status GenTXDef, rather than as general requirements of this section.
3.5.4 Structured Package Payload
The Structured Package Payload contains exactly one SubmissionSet metadata representation; zero or one Workflow Activity Task, subject to transaction-specific requirements; one primary information object; permitted secondary information objects; optional Provenance information; copies of the human-readable MIME Part 1 files; and supporting resources needed to resolve references.
| Component per workflow unit | Cardinality | Role in the structured payload |
|---|---|---|
| SubmissionSet representation | 1..1 | Metadata and membership representation: IHE SubmissionSet in METADATA.XML or FHIR List in the Collection Bundle. Organizes submitted information objects; its references do not imply physical nesting of their files. |
| Workflow Activity Task | 0..1; TX8 and transaction-specific requirements may require 1..1 | Machine-processable expression of the specific Workflow Activity being performed or requested, including applicable Context Instance associations, correlation information, and Workflow Status instructions. No more than one is associated with each independently processable workflow unit; TX8 requires exactly one. |
| Primary Data Object | 1..1 | Principal clinical, administrative, or workflow information object being exchanged to accomplish the Shared Activity. |
| Secondary Data Object(s) | 0..* | Additional information objects needed or useful for performing the Shared Activity. Zero or more may be included when permitted by the Transaction Definition. |
| Provenance Information | 0..* | Separate FHIR Collection Bundles, each containing 1..* independently attributable Provenance resources. Each bundle has its own metadata description and SubmissionSet membership. Required activities are specified by the Transaction Definition. |
| Human-Readable Representation(s) | 1 text/plain; 0..* text/html | Identical copies of the required text/plain file and every optional text/html alternative supplied in MIME Part 1. |
| Supporting resources | 0..* as needed | Identities and other resources needed to resolve references. Carried with the structured payload; not separate submitted information objects solely because they support a reference. |
These cardinalities apply per workflow unit. The Transaction Definition MAY constrain optional categories or specify their permitted repetition. XD and FHIR representations SHALL preserve the same information-object roles and semantics. Transaction Definition Section 3.1 SHALL show both the Direct message MIME structure and the nested structured payload composition.
CDA media type. For every information object that is a CDA document, DocumentEntry.mimeType SHALL be application/cda+xml, the IANA-registered CDA media type. This requirement applies to both primary and secondary CDA documents. The FHIR metadata representation SHALL carry the same media type in DocumentReference.content.attachment.contentType and the corresponding Binary.contentType, as specified in Appendix D. A CDA file remains XML regardless of the serialization selected for native FHIR resources.
The human-readable objects in the structured payload SHALL include the same human-readable files supplied in the outer MIME Part 1, as required by Section 3.8.4.
3.5.5 Resource References
Every resource reference and locator required to interpret the transmitted structured payload SHALL resolve to information carried in that structured payload. This includes matching a logical Reference.identifier to the corresponding carried information object where this guide specifies identifier-based targeting. Supporting files outside MIME Part 2, such as review reports or METADATA_EZ renderings, do not satisfy this requirement. Terminology and specification canonical URLs identify external definitions and are not references to exchanged information objects.
Supporting resources provide patient, author, requester, recipient, endpoint, or agent identities needed to interpret information objects. They do not receive separate DocumentEntries or DocumentReferences solely because they support a reference. Independently submitted information objects, including each Provenance Collection Bundle, SHALL receive their own metadata description and SubmissionSet membership.
XD resource references. Supporting native FHIR resources referenced by an included Workflow Activity Task SHALL be contained in that Task where required by the XD packaging representation. Contained references use #<contained-id> within the containing resource. Transaction-specific rules for TX8 Provenance target references belong in the send-workflow-status GenTXDef.
FHIR Collection references. For the FHIR metadata option, Task and supporting resources SHALL be represented as appropriate peer Bundle entries under Appendix D. Literal references SHALL resolve to carried resources. TX8-specific Provenance target-reference constraints are established by the send-workflow-status GenTXDef.
Contained snapshots SHALL preserve the clinical identifiers, demographics, and information needed to interpret their references. Contained resources SHALL NOT carry meta.versionId, meta.lastUpdated, or meta.security. Applicable security labels SHALL be preserved on the containing resource. Required source-version or temporal information SHALL be represented through permitted elements or carried Provenance; a separate review report does not substitute for required transmitted information.
3.5.6 Patient Identity and Context
For a MAP push transaction, patientId and sourcePatientId represent different patient-identifier perspectives. patientId SHALL be populated only when the Information Source knows the patient identifier appropriate to the Information Recipient or a mutually agreed exchange patient-identifier domain. The Information Source SHALL NOT copy its own local patient identifier into patientId merely because no recipient-known identifier is available. The Information Source local identifier belongs in DocumentEntry.sourcePatientId.
When all DocumentEntries in a SubmissionSet pertain to one patient, MAP SubmissionSet Patient Info SHALL be present. The extension SHALL use the same patient demographic representation and semantics defined for DocumentEntry.sourcePatientInfo. Patient Info SHALL be provided even when patientId is known, because it supplies an independent matching/checking fallback that can improve confidence in the Content Consumer patient match.
A patient identifier learned or resolved during transaction packaging MAY be represented in SubmissionSet.patientId and applicable DocumentEntry.patientId when it is known to be appropriate to the Information Recipient or agreed exchange domain. Packaging software SHALL NOT alter the underlying source ADT, CDA, or other clinical source object solely to inject that recipient-known patient identifier.
Example — a use-case transaction followed by TX8
a use-case transaction: Organization A sends an Outpatient Visit Notification to Organization B. For a use-case transaction, A is the Information Source and B is the Information Recipient. SubmissionSet.sourceId identifies A. DocumentEntry.sourcePatientId carries A’s locally known patient identifier. SubmissionSet.patientId and applicable DocumentEntry.patientId are populated only if A knows the patient identifier appropriate to B or the mutually agreed exchange domain. SubmissionSet Patient Info is present regardless, providing the demographic information B can use to match or confirm the patient.
TX8: Organization B subsequently sends Workflow Status back to Organization A. TX8 is a new Transaction Instance, so B is now the Information Source and A is the Information Recipient. SubmissionSet.sourceId therefore identifies B. If B successfully matched the patient, B’s locally known patient identifier may be represented as the sourcePatientId of TX8 information. patientId is populated only if B knows the identifier appropriate to A or the mutually agreed exchange domain. SubmissionSet Patient Info is again present. TX8 correlation to a use-case transaction preserves the relationship between the transactions without preserving the a use-case transaction actor-role assignments.
If B cannot match the patient, B SHALL NOT manufacture a local sourcePatientId. A failed TX8 may still carry the SubmissionSet Patient Info associated with the attempted match and report the applicable structured payload rejection outcome.
3.5.7 Context Instance Identification
ContextInstance TypeCodes have an Extensible binding to the DirectTrust Context TypeCode Value Set (DTContextTypeCodeVS), http://objects.directtrust.org/standards/terminology/ValueSet/DTContextTypeCodeVS, as specified in the SubmissionSet terminology binding table in Section 3.7.6. This binding applies to Context Instance type declarations in the Workflow Activity Task and corresponding XD or FHIR metadata. The type code identifies the kind of established Context Instance; the associated identifier identifies the particular instance.
The value set includes DirectTrust Context type codes and the IHE-defined accession, referral, order, DICOM Study Instance UID, and encounter identifier type URNs. In FHIR, the IHE types SHALL use urn:ietf:rfc:3986 as Coding.system and the complete IHE URN as Coding.code. DirectTrust types SHALL use the DirectTrust Context TypeCode CodeSystem canonical URI. The assigning authority or identifier namespace SHALL remain distinct from the type coding system. In XD CXi encoding, the complete type URN is carried in CXi.5.
IHE definitions are provided in ITI TF Volume 3, Table 4.2.3.1.7-2, with FHIR identifier mapping in ITI TF Volume 2, Appendix Z, Section Z.9.1.2. The IHE Study Instance UID type is urn:ihe:iti:xds:2016:studyInstanceUID; the encounter identifier type is urn:ihe:iti:xds:2015:encounterId.
3.5.8 Information Classification and Metadata Derivation
MAP SHALL distinguish SubmissionSet.purpose (Shared Activity), SubmissionSet.contentTypeCode (principal package content), DocumentEntry.classCode / DocumentReference.category (broad information-object classification), and DocumentEntry.typeCode / DocumentReference.type (specific information-object type). The applicable Transaction Definition SHALL identify the classifications and terminology required for its information objects.
The classification of a clinical document SHALL be grounded in the actual information object and applicable terminology. Appendix A and Chapter T provide supporting concepts and definitions; use case-specific display-label constraints are not established by this Framework section.
Document Status is distinct from structured payload workflow status and metadata availability. Apply Appendix E when interpreting CDA sdtc:statusCode, Composition.status, or DocumentReference.docStatus. A DocumentEntry availabilityStatus or DocumentReference.status value SHALL NOT substitute for the document’s clinical status; an accepted structured payload does not establish that its document is final.
Chapter T defines Document Type, Document Category, and Document Template/Profile. For clinical documents, DocumentEntry.typeCode and DocumentReference.type identify the specific Document Type. XD DocumentEntry.classCode permits 0..1 value, whereas FHIR DocumentReference.category permits 0..* values. The applicable Transaction Definition SHALL specify classification requirements, terminology, and which FHIR category, if any, corresponds to the XD classCode. Additional FHIR categories SHALL NOT be presumed to have XD counterparts.
Clinical and discovery semantics SHALL be obtained from the source object or deterministically resolved from an authoritative reference source. Packaging software SHALL NOT manufacture clinical semantics or use synthetic NONE, Not specified, or equivalent placeholder codes to satisfy coded metadata. When omission is permitted and a value cannot be established, the element is omitted; when a required value cannot be established, the condition is reported as a metadata error.
Bindings for authorRole, authorSpecialty, practiceSettingCode, and related coded metadata are specified in the metadata inventories and terminology tables below; their presence does not authorize fabrication of missing source information.
Metadata derivation SHOULD remain traceable. Implementations should be able to distinguish values extracted from the clinical source, values resolved from an authoritative provider/facility reference such as Endpoint Discovery, and values generated as packaging mechanics (for example hash, size, MIME type, or package identifiers).
3.5.9 Clinical Snapshot and Assembly Time
A document represents information applicable to a particular clinical encounter, event, or period. That clinical snapshot SHALL be preserved regardless of when the document is assembled or exchanged. Generating a document later does not authorize substitution of newer patient information for the information applicable to the snapshot.
For example, a discharge summary assembled one month after discharge shall report the weight applicable at discharge, rather than a weight recorded at a subsequent follow-up visit. Later corrections or additions, when included, SHALL be clearly identified and distinguished from the original snapshot.
For example, an EHR may generate a shareable representation of an existing document at the time of release. The representation SHALL preserve the original clinical snapshot and distinguish original document time from assembly and transaction times. Detailed CDA Assembler/Composer mappings are specified in the send-documents GenTXDef.
The clinical effective time, document creation time, representation assembly time, and transaction time are distinct concepts. Their source meaning and available precision SHALL be preserved. Detailed CDA ClinicalDocument/effectiveTime and Assembler/Composer mappings belong in the send-documents GenTXDef.
Event occurrence, recording, service start and end, and message creation times SHALL NOT be silently substituted for one another. Detailed HL7 V2 MSH-7, PV1-44, PV1-45, EVN-2, and EVN-6 mappings belong in the send-visit-notification GenTXDef.
When CDA represents an existing document in another format, ClinicalDocument/effectiveTime preserves the original document’s creation time. Assembly time SHALL NOT replace that time solely because a CDA representation was generated later.
3.5.10 XD Metadata Inventory and Terminology
These inventories cover every standard IHE SubmissionSet and DocumentEntry attribute, author subfields, and the MAP additions defined here. They apply to Direct/XDM file packaging; other XD transactions retain their own profile-specific requirements. R = required; RE = required when known/available (IHE R2); O = optional; C = required under the stated condition. Cardinalities are populated occurrences; conditional fields become mandatory when the row condition applies. A Transaction Definition may strengthen these requirements and specifies their application to Task, primary, Provenance, human-readable, and secondary objects.
The inventories describe metadata attributes, not arbitrary XML infrastructure properties or unrestricted local extensions. Author subfield cardinalities apply per author. sourcePatientInfo has one package-level demographic set encoded as multiple Slot values; DocumentEntry lists its individual demographic field values. XD patientId is a single identifier in the selected recipient/exchange domain; additional source identifiers belong in the promoted MAP sourcePatientId Slot.
Source references: IHE ITI TF Volume 3, Tables 4.2.3.2-1 and 4.2.3.3-1 (field definitions), Table 4.3.1-3 (XDM optionality), and Section 4.2.3.1.6 (extra metadata). https://profiles.ihe.net/ITI/TF/Volume3/ch-4.2.html and https://profiles.ihe.net/ITI/TF/Volume3/ch-4.3.html. RE expresses the required-if-known baseline; MAP conditional requirements are defined in these inventories; extension Slots are defined in Section 3.5.12 and Section 3.5.14.
3.5.11 SubmissionSet Metadata
The SubmissionSet inventory identifies the package-level fields used to describe the workflow unit, its participants, patient information, and context.
| Metadata field | Conf. | Cardinality | MAP extension | Meaning and population rule | XD encoding |
|---|---|---|---|---|---|
| entryUUID | R | 1..1 | No | Metadata entry identity; distinct from uniqueId. | @id |
| uniqueId | R | 1..1 | No | SubmissionSet Workflow Activity identifier; matches designated Task.identifier when Task is present. | ExternalIdentifier |
| sourceId | R | 1..1 | No | Organization Identity OID of the contributor of this SubmissionSet; apply the current transaction perspective. | ExternalIdentifier |
| submissionTime | R | 1..1 | No | Time the creating entity assembled the SubmissionSet; not clinical encounter time. | Slot: submissionTime |
| contentTypeCode | RE | 0..1 | No | Default SHALL equal the Primary Information Object DocumentEntry.typeCode (same code and system); only an explicit UCTXDef override may define a different classification and its processing implications. | Classification |
| purpose | R | 1..1 | Yes | Shared Activity; aligns with Task.code when Task is present and the common binding. | MAP Slot: urn:dt-org:dsm:map:purpose |
| patientId | C | 0..1 | No | Required when a recipient/exchange-domain patient identifier is known. Do not substitute the source local ID. | ExternalIdentifier |
| sourcePatientId | C | 0..* | Yes; promoted | For a single-patient package, include known Information Source patient IDs, with assigning authorities. | MAP Slot: urn:dt-org:dsm:map:sourcePatientId |
| sourcePatientInfo | C | 0..1 set | Yes; promoted | Required when all DocumentEntries concern one patient, even when patientId is known; preserve source demographic semantics. | MAP Slot: urn:dt-org:dsm:map:sourcePatientInfo |
| referenceIdList | C | 0..* | Yes; promoted | Include established Context identifiers required by the TX Definition; preserve CXi type and authority. | MAP Slot: urn:dt-org:dsm:map:referenceIdList |
| author | R | 1..1 | No | The SubmissionSet Author is the Information Source initiating the current MAP Transaction Instance and responsible for providing or releasing information in its possession for distribution. It need not have originally authored every member information object. A technical intermediary does not become SubmissionSet Author merely by packaging or transmitting on its behalf. | Author Classification |
| author.authorPerson | RE | 0..1 / author | No | Known individual author; XCN encoding. | Author Slot: authorPerson |
| author.authorInstitution | R | 1..1 / author | No | The organization acting as Information Source for the current transaction, encoded as XON. An individual may additionally act for this organization. | Author Slot: authorInstitution |
| author.authorRole | RE | 0..* / author | No | Known activity-specific author function; common binding. | Author Slot: authorRole |
| author.authorSpecialty | RE | 0..* / author | No | Known specialty; common binding. | Author Slot: authorSpecialty |
| author.authorTelecommunication | RE | 0..* / author | No | Known contact information, including Direct where applicable; XTN encoding. | Author Slot: authorTelecommunication |
| intendedRecipient | RE | 0..* | No | Intended organizations/persons; not automatically every transport intermediary. | Slot: intendedRecipient |
| title | O | 0..1 | No | Human-readable collection/workflow-unit title. | Name |
| comments | O | 0..1 | No | Additional package explanation. | Description |
| availabilityStatus | O | 0..1 | No | SubmissionSet status: Approved when supplied; distinct from workflow status or Task.status. | @status |
| homeCommunityId | O | 0..1 | No | Established community ID when relevant; not the source organization OID. | @home |
| limitedMetadata | O | 0..1 flag | No | Use only to indicate applicable metadata-limited treatment; not a generic missing-field flag. | Classification |
FHIR mapping. These tables specify XD metadata for MAP Direct/XDM packaging. Appendix D, FHIR Collection Bundle Packaging, defines the corresponding FHIR elements, IHE MHD extensions, and mappings for MAP extensions. Metadata semantics and transaction requirements remain consistent across representations.
FHIR SubmissionSet List profile. For the FHIR Metadata option, the current SubmissionSet for each workflow unit SHALL be represented by a FHIR R4 List conforming to the DirectTrust MAP SubmissionSet List StructureDefinition (http://objects.directtrust.org/standards/fhir/StructureDefinition/map-submissionset-list). This profile is based on FHIR R4 List and adopts selected IHE MHD elements and extensions; its use does not, by itself, assert conformance to the complete IHE MHD SubmissionSet or ITI-65 transaction profiles. TX8 originating-package identification snapshot is a separate information object governed by its dedicated snapshot profile and SHALL NOT be treated as the current SubmissionSet List. The formal relationship of this draft profile to IHE MHD remains under review as MAP-OI-001; no unresolved issue suspends currently stated requirements.
FHIR SubmissionSet source organization mapping. When FHIR metadata is selected, SubmissionSet.sourceId SHALL be represented by exactly one List-level extension with URL https://profiles.ihe.net/ITI/MHD/StructureDefinition/ihe-sourceId. Its valueIdentifier.value SHALL contain the established Organization Identity OID of the entity contributing the current SubmissionSet, expressed as urn:oid:<OID>. This uses the IHE MHD sourceId mapping; a separate MAP source-organization extension SHALL NOT substitute for it.
Author and source roles. List.source represents the author who or device that defined the List contents. In FHIR R4 its allowed reference targets are Practitioner, PractitionerRole, Patient and Device; it SHALL NOT directly reference an Organization. When the author organization is represented through the IHE mapping, the optional extension https://profiles.ihe.net/ITI/MHD/StructureDefinition/ihe-authorOrg SHALL be placed on List.source and carry a valueReference to the author Organization. The author organization and the contributing source identified by ihe-sourceId are distinct roles; their identities MAY coincide when the same organization actually performs both roles.
Transaction perspective. The ihe-sourceId value SHALL identify the source of the current MAP Transaction Instance. In TX8 it identifies the entity contributing the return Workflow Status SubmissionSet, rather than automatically copying the sourceId of the originating transaction. This mapping applies across the Transaction Definitions that use FHIR SubmissionSet metadata.
IHE mapping reference: Mobile access to Health Documents (MHD), SubmissionSet Minimal profile, https://profiles.ihe.net/ITI/MHD/StructureDefinition-IHE.MHD.Minimal.SubmissionSet.html, and sourceId example, https://profiles.ihe.net/ITI/MHD/List-ex-minimalSubmissionSet.json.html. These sources were reviewed in publication 4.2.5-comment, based on FHIR R4. Adoption of this sourceId mapping does not by itself assert conformance to every constraint of an MHD SubmissionSet profile.
FHIR identifier correspondence. SubmissionSet.uniqueId SHALL use the IHE MHD List.identifier:uniqueId slice and SubmissionSet.entryUUID SHALL use the IHE MHD List.identifier:entryUUID slice. Neither SHALL be substituted with List.id. The applicable IHE-defined identifier semantics SHALL be retained.
Membership and correlation. Each included DocumentEntry SHALL be linked to its SubmissionSet by a HasMember Association with SubmissionSetStatus Original. These are Association metadata, not additional SubmissionSet fields. When Task is present, its designated Task.identifier SHALL match SubmissionSet.uniqueId. Task-based originating/related transaction correlation applies when Task is included; this inventory does not establish an additional unqualified transactionInstanceId Slot.
3.5.12 SubmissionSet Extensions
MAP defines four SubmissionSet extension Slots: purpose, sourcePatientId, sourcePatientInfo, and referenceIdList. Their authoritative conformance and cardinalities are specified in Section 3.5.11. This section specifies extension semantics, XD encodings, FHIR representations, and terminology bindings without duplicating those cardinality requirements.
Extension inventory (exact, case-sensitive XD Slot names): purpose — urn:dt-org:dsm:map:purpose; sourcePatientId — urn:dt-org:dsm:map:sourcePatientId; sourcePatientInfo — urn:dt-org:dsm:map:sourcePatientInfo; referenceIdList — urn:dt-org:dsm:map:referenceIdList. Each extension Slot occurs at most once; permitted repeated values are carried within its ValueList. Slot names are metadata identifiers, not terminology codes.
Purpose. SubmissionSet.purpose identifies the Shared Activity independently of Task presence and is distinct from contentTypeCode. XD uses an IHE Coded String including activity code and CodeSystem OID. FHIR uses http://objects.directtrust.org/standards/fhir/StructureDefinition/map-submission-purpose. When Task is present, Task.code SHALL be consistent with purpose. TransactionTypesVS is the designated value set; the terminology table states Extensible, while the draft FHIR extension description states Required. Verify the StructureDefinition and reconcile binding strength before changing the normative binding; Extensible is the preferred direction, not yet a final binding change.
Source patient identifiers. The sourcePatientId extension carries identifiers known to the Information Source. XD SHALL use IHE CX encoding with assigning authority; multiple identifiers SHALL be values in one Slot ValueList. Identifiers SHALL NOT be manufactured solely to populate the extension. Source-local identifiers SHALL NOT be substituted for recipient-known or agreed exchange-domain SubmissionSet.patientId. The exact FHIR mapping remains subject to artifact verification.
Source patient information. The sourcePatientInfo extension carries demographic information known to the Information Source for the single patient associated with the SubmissionSet. XD SHALL use IHE sourcePatientInfo HL7 V2 PID-field encoding; multiple field values MAY be carried in one Slot ValueList. The extension MAY be populated even when patientId is present. It SHALL NOT represent multiple patients. The exact FHIR mapping remains subject to artifact verification.
Context Instance references. The referenceIdList extension carries identifiers of established Context Instances associated with the Shared Activity. XD SHALL use IHE CXi encoding preserving identifier, assigning authority, and Context TypeCode; multiple references MAY be values in one Slot ValueList. Identifiers SHALL NOT be manufactured solely to populate this extension. When Task carries the same Context Instances, identifiers SHALL be consistent. Context TypeCode SHALL conform to the Extensible DTContextTypeCodeVS binding in Section 3.5.7, retaining IHE-defined or DirectTrust-defined code system semantics. The exact FHIR mapping remains subject to artifact verification.
FHIR representation of MAP purpose. The current SubmissionSet List SHALL carry exactly one map-submission-purpose extension (http://objects.directtrust.org/standards/fhir/StructureDefinition/map-submission-purpose) with a CodeableConcept identifying the same Shared Activity as the XD SubmissionSet.purpose Slot. The binding strength declared by the current StructureDefinition requires verification against the Extensible binding in the SubmissionSet terminology table; no change to the normative binding is approved pending reconciliation. List.code SHALL identify the List as submissionset; the IHE ihe-designationType extension SHALL carry SubmissionSet.contentTypeCode, not purpose. When a Workflow Activity Task is included, Task.code SHALL carry the same transaction code and code system as the purpose extension. The MAP SubmissionSet List profile enforces the occurrence of the purpose, ihe-designationType, and ihe-sourceId extensions. Other MAP package-level patient and Context mappings remain subject to the definitions in Appendix D; the List profile does not authorize dropping required metadata.
The three promoted fields SHALL preserve the corresponding IHE DocumentEntry semantics and value encodings: sourcePatientId uses CX, sourcePatientInfo uses IHE sourcePatientInfo PID-field encoding, and referenceIdList uses CXi with the established Context TypeCode binding. Their promotion does not make them standard IHE SubmissionSet attributes. purpose SHALL carry the Shared Activity as an IHE Coded String (code with CodeSystem OID); the applicable terminology binding remains in the SubmissionSet terminology binding table in Section 3.7.6. Exact CodeSystem OID identification is required for that encoding; a ValueSet URI SHALL NOT be substituted. A receiver SHALL use these MAP fields according to this IG rather than assume that a generic IHE receiver processes extra metadata.
3.5.13 DocumentEntry Metadata
The DocumentEntry inventory identifies the metadata fields describing each included information object, its identity, classification, authorship, clinical times, and package location.
| Metadata field | Conf. | Cardinality | MAP extension | Meaning and population rule | XD encoding |
|---|---|---|---|---|---|
| entryUUID | R | 1..1 | No | Metadata entry identity; distinct from uniqueId. | @id |
| uniqueId | R | 1..1 | No | Artifact identity assigned by its creator; preserve an established identifier. | ExternalIdentifier |
| objectType | R | 1..1 | No | Stable DocumentEntry for a packaged file; UUID urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1. | @objectType |
| mimeType | R | 1..1 | No | Actual IANA media type of the described object. For every primary or secondary CDA document, SHALL be application/cda+xml. See Section 3.5.4 and Appendix D. | @mimeType |
| URI | R | 1..1 | No | Relative XDM package locator that resolves to the actual file. | Slot: URI |
| hash | R | 1..1 | No | SHA-1 hash of the exact packaged bytes. | Slot: hash |
| size | R | 1..1 | No | Byte count of the same packaged file. | Slot: size |
| title | O | 0..1 | No | Human-readable artifact title. | Name |
| comments | O | 0..1 | No | Additional explanation about the artifact. | Description |
| classCode | RE | 0..1 | No | Broad object classification; common binding or artifact-specific fixed value applies. Document Category alignment is governed by the declared exchange policy; see Chapter T. | Classification |
| typeCode | R | 1..1 | No | Specific information-object type; standard LOINC code or explicitly defined temporary code. SHALL NOT be omitted or replaced by a Shared Activity code. For clinical documents, this is Document Type as defined in Chapter T. | Classification |
| formatCode | RE | 0..1 | No | Established technical format/profile; omit when unknown. | Classification |
| confidentialityCode | RE | 0..* | No | Applicable security/privacy classifications; do not assume N universally. | Classification(s) |
| languageCode | RE | 0..1 | No | Known human language of the character content. | Slot: languageCode |
| creationTime | RE | 0..1 | No | CDA: Assembler/Composer time; effectiveTime fallback. HL7 V2: MSH-7. Preserve source meaning under Section 3.6.4. | Slot: creationTime |
| serviceStartTime | RE | 0..1 | No | Known start of the service documented by the artifact. | Slot: serviceStartTime |
| serviceStopTime | RE | 0..1 | No | Known end of that service. | Slot: serviceStopTime |
| eventCodeList | O | 0..* | No | Clinical acts/events documented by the artifact; not the MAP transaction code. | Classification(s) |
| healthcareFacilityTypeCode | RE | 0..1 | No | Facility type associated with the documented activity; common binding applies. | Classification |
| practiceSettingCode | RE | 0..1 | No | Clinical practice setting associated with the documented activity. | Classification |
| patientId | C | 0..1 | No | Required when the recipient/exchange patient ID is known; consistent with SubmissionSet.patientId. | ExternalIdentifier |
| sourcePatientId | RE | 0..1 | No | Patient ID in the local source domain of the described information. | Slot: sourcePatientId |
| sourcePatientInfo | RE | 0..* fields | No | Source patient demographics, using IHE PID-field encoding. | Slot: sourcePatientInfo |
| referenceIdList | C | 0..* | No | Context identifiers required for this artifact by the TX Definition; CXi encoding. | Slot: referenceIdList |
| author | RE | 0..* | No | Known human/device author of the artifact; distinguish package author from artifact author. | Author Classification |
| author.authorPerson | RE | 0..1 / author | No | Known individual author; XCN encoding. | Author Slot: authorPerson |
| author.authorInstitution | RE | 0..* / author | No | Known associated institution(s); XON encoding. | Author Slot: authorInstitution |
| author.authorRole | RE | 0..* / author | No | Known activity-specific author function; common binding. | Author Slot: authorRole |
| author.authorSpecialty | RE | 0..* / author | No | Known specialty; common binding. | Author Slot: authorSpecialty |
| author.authorTelecommunication | RE | 0..* / author | No | Known contact information, including Direct where applicable; XTN encoding. | Author Slot: authorTelecommunication |
| legalAuthenticator | O | 0..1 | No | Established artifact legal authenticator; do not infer attestation from packaging. | Slot: legalAuthenticator |
| availabilityStatus | O | 0..1 | No | DocumentEntry availability status when supplied; distinct from workflow status or Task.status. | @status |
| homeCommunityId | O | 0..1 | No | Established community ID when relevant; not the source organization OID. | @home |
| repositoryUniqueId | O | 0..1 | No | Established repository OID if relevant; do not invent one for a ZIP. | Slot: repositoryUniqueId |
| limitedMetadata | O | 0..1 flag | No | Use only to indicate applicable metadata-limited treatment; not a generic missing-field flag. | Classification |
FHIR mapping. These tables specify XD metadata for MAP Direct/XDM packaging. Appendix D, FHIR Collection Bundle Packaging, defines the corresponding FHIR elements, IHE MHD extensions, and mappings for MAP extensions. Metadata semantics and transaction requirements remain consistent across representations.
3.5.14 DocumentEntry Extensions
No DocumentEntry Extensions are defined in the MAP Framework.
3.5.15 Common Terminology Bindings
The terminology requirements in this section establish common rules for coded metadata used in MAP Transaction Instances. The applicable ValueSet, binding strength, and additional constraints for individual metadata elements are identified in Sections 3.5.16 and 3.5.17 and, where applicable, in the governing StructureDefinitions. An Extensible binding requires use of a code from the designated ValueSet when that ValueSet contains a concept appropriate to the information being represented. When no suitable concept is available, an appropriate code from another code system MAY be used, subject to the applicable Transaction Definition.
A fixed value requires the specified literal under the stated condition; it is a constraint designation in this Framework, not a FHIR terminology binding strength. A terminology binding governs the permitted coded values when an element is populated. It does not independently change the element’s cardinality or require population of an otherwise optional or conditional element. Canonical ValueSet URIs identify the bound value sets. The CodeSystem URI or OID identifies the terminology system of the selected code and SHALL be preserved in the applicable representation. A ValueSet URI SHALL NOT be substituted for a CodeSystem identifier. Identifiers, dates, free text, hashes, sizes, and URI fields retain their applicable datatype and derivation requirements and are not terminology bindings.
The terminology package provides the CodeSystems, ValueSets, and OID assignments used by this guide. Transaction Types, Task Input types, failure reasons, patient-change concepts, and DirectTrust Provenance activities use the consolidated DirectTrust CodeSystem (http://objects.directtrust.org/standards/terminology/CodeSystem/DTCodeSystem; OID 1.3.6.1.4.1.41179.4.1.1). Previously established DirectTrust CodeSystems, including Context TypeCodes, remain separate. Use the CodeSystem OID in XD coded strings and its canonical URI in FHIR Coding.system; a ValueSet identifier SHALL NOT substitute for either. The consolidated DirectTrust CodeSystem and separately maintained DirectTrust CodeSystems, including Context TypeCodes, SHALL remain distinguishable. Published terminology identifiers and OID assignments require verification against the authoritative terminology artifacts.
3.5.16 SubmissionSet Terminology
The following bindings apply to package-level metadata describing the Shared Activity, package classification, and applicable Context Instances.
| Metadata element | ValueSet or fixed value | Binding strength | Application rule |
|---|---|---|---|
| purpose | DirectTrust Transaction Types http://objects.directtrust.org/standards/terminology/ValueSet/TransactionTypesVS | Extensible | Identifies the Shared Activity independently of Task. When Task is present, Task.code SHALL carry the same transaction code and code system. The Transaction Definition specifies the activity code; it is not an information-object classification. Confirm that the map-submission-purpose StructureDefinition binding strength is consistent with this Extensible binding before publication. |
| contentTypeCode | LOINC Document Ontology http://loinc.org/vs/loinc-document-ontology | Extensible | By default match the Primary Information Object DocumentEntry.typeCode, including system. Explicit alternative permitted only in a UCTXDef. |
| referenceIdList Context Instance TypeCode | DirectTrust Context TypeCode Value Set http://objects.directtrust.org/standards/terminology/ValueSet/DTContextTypeCodeVS | Extensible | Identifies the kind of established Context Instance; the associated identifier identifies the instance. When Task is present, apply the same type semantics in the Task and corresponding metadata. The binding applies to the Context TypeCode, not to the Context Instance identifier. Preserve the assigning authority. |
| availabilityStatus | urn:oasis:names:tc:ebxml-regrep:StatusType:Approved | Fixed value | Applies to the XD SubmissionSet status. The FHIR representation preserves the corresponding package semantics using its defined mapping. The fixed value applies when this optional metadata element is populated, unless an applicable Transaction Definition specifies otherwise. |
3.5.17 DocumentEntry Terminology
The following bindings classify the included information objects and describe their authors, clinical settings, and context.
| Metadata element | ValueSet or fixed value | Binding strength | Application rule |
|---|---|---|---|
| classCode | LOINC Document Ontology http://loinc.org/vs/loinc-document-ontology | Extensible | Select the broader classification appropriate to the information object. Do not substitute a MAP transaction code for an information-object class. Document Category alignment is governed by the declared exchange policy; see Chapter T. XD DocumentEntry.classCode permits 0..1; FHIR DocumentReference.category permits 0..*. The applicable Transaction Definition SHALL specify which FHIR category, if any, corresponds to XD classCode; additional FHIR categories are not presumed to have XD counterparts. |
| typeCode | LOINC Document Ontology http://loinc.org/vs/loinc-document-ontology | Extensible | Select the specific type of information object. A Transaction Definition may establish a fixed code. Retain an explicitly defined DirectTrust temporary code where LOINC DO lacks the needed concept. For clinical documents, this is Document Type as defined in Chapter T. |
| formatCode | IHE FormatCode ValueSet http://ihe.net/fhir/ihe.formatcode.fhir/ValueSet/formatcode DirectTrust FormatCode ValueSet http://objects.directtrust.org/standards/terminology/ValueSet/DTFormatCodeVS | Extensible | Use a code for the actual technical format and applicable content profile. A code from either listed set is acceptable. Transaction Definitions specify applicable format codes for their artifacts. |
| languageCode | Common Languages http://hl7.org/fhir/ValueSet/languages | Extensible | Represent the actual language using the applicable BCP 47 language tag. Do not derive a fixed language solely from the use case. |
| authorSpecialty | NUCC Provider Taxonomy http://hl7.org/fhir/ValueSet/provider-taxonomy C80 Practice Setting Codes (SNOMED CT Medical Specialty) http://hl7.org/fhir/ValueSet/c80-practice-codes | Extensible | A code from either ValueSet is acceptable. Preserve the code system of each supplied specialty. Multiple applicable specialties may be carried. Author specialty identifies the professional specialty of the author; it is not interchangeable with practiceSettingCode or healthcareFacilityTypeCode. |
| practiceSettingCode | C80 Practice Setting Codes (SNOMED CT Medical Specialty) http://hl7.org/fhir/ValueSet/c80-practice-codes | Extensible | Describes the clinical practice setting associated with creation of the information. Preserve its distinction from author function and facility type. Practice setting describes the setting, not the author’s professional specialty or the facility type. |
| confidentialityCode | Confidentiality http://terminology.hl7.org/ValueSet/v3-Confidentiality | Extensible | Use the classification applicable to the source information. N is not a universal default; a use case may explicitly establish a fixed value where appropriate. |
| healthcareFacilityTypeCode | ServiceDeliveryLocationRoleType http://terminology.hl7.org/ValueSet/v3-ServiceDeliveryLocationRoleType Healthcare Service Location Type Combined http://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113762.1.4.1267.31 CMS Place of Service Codes http://terminology.hl7.org/ValueSet/CMSPlaceOfServiceCodes | Extensible | A code from any of these three ValueSets is acceptable. Describe the facility or service location applicable to the clinical activity; retain the selected code system. Facility type describes the facility or service location, not author specialty or practice setting. |
| referenceIdList Context Instance TypeCode | DirectTrust Context TypeCode Value Set http://objects.directtrust.org/standards/terminology/ValueSet/DTContextTypeCodeVS | Extensible | Use the common ContextInstance type binding. Applicable instance identifiers SHALL remain consistent with the Task and SubmissionSet declarations. The binding applies to Context TypeCode rather than the instance identifier; preserve the assigning authority. |
The LOINC Document Ontology binding applies to information-object classification, including non-CDA artifacts where the concept is appropriate. Temporary classification codes explicitly identified by a Transaction Definition remain permitted when the needed concept is not represented in LOINC DO. Terminology binding does not change the source-derivation rules or authorize fabricated clinical metadata.
MAP transactions exchange information using Direct. This section covers Direct message header metadata, MIME packaging, and message delivery reporting. Any XD edge processing is supporting implementation behavior, not a non-Direct MAP transaction. Delivery notifications and workflow status updates convey different outcomes.
3.5.18 Direct Header Metadata
The Direct message carries transport identifiers and delivery-notification controls. These fields describe the message transport and are distinct from the Workflow Activity identifier and workflow status instructions.
| Element | Common purpose |
|---|---|
| Message-ID | Identifies the individual Direct message and supports transport-level correlation, including MDNs. Distinct from the Transaction Instance / Workflow Activity Identifier. |
| Content-Type | Defines the multipart/mixed Direct message and MIME boundary. |
| Disposition-Notification-To | Identifies the return endpoint for requested Direct transport disposition notifications. |
| Disposition-Notification-Options | Requests/configures applicable Direct disposition-notification behavior. |
MAP adds the following message header metadata to support recognition, routing, and processing of the structured payload.
| MAP header | Cardinality | ValueSet or fixed value | Binding strength | Purpose and application rule |
|---|---|---|---|---|
| x-direct-metadata-payload-versionIdentifier | 1..1 | 1 | Fixed value | Framework version governing interpretation and processing. The fixed framework version is 1. |
| x-direct-metadataTypeCode | 1..1 | DirectTrust Metadata Type http://objects.directtrust.org/standards/terminology/ValueSet/MetadataTypeVS | Extensible | Early recognition/routing based on structured payload metadata representation. SHALL identify the metadata representation actually used for the transaction. The value SHALL follow the Extensible binding to MetadataTypeVS and SHALL be consistent with a metadata representation supported by the receiving endpoint. For XD metadata use urn:dt-org:dsm:map:SMTP+XD:1.0; for FHIR metadata use urn:dt-org:dsm:map:SMTP+FHIR:1.0. |
| x-direct-useCase | 1..1 | the applicable use-case IG | Fixed value | Early use-case-aware routing to the appropriate Content Consumer Processor. Identifies this use case. |
| x-direct-purposeOfUse | 0..* | TREATMENT | Fixed value | Broad network-level reporting/measurement of exchange purpose without Payload inspection. When purposeOfUse is populated for treatment exchange in this use case, use TREATMENT. The header remains optional; this fixed value does not assert treatment for an unrelated purpose. |
These MAP message metadata requirements are common to a use-case transaction-a TX8 whenever the transaction uses Direct messaging. Individual Transaction Definitions SHALL state only transaction-specific deviations or additional requirements. The Direct message header SHALL NOT use x-direct-workflow-status-requested. The request for structured payload acceptance reporting and the Workflow Status Update Endpoint(s) belong to the Workflow Activity Task. Disposition-Notification-To remains a transport-level return address for Direct disposition reporting and SHALL NOT be interpreted as a Workflow Status Update Endpoint.
3.5.19 MIME Packaging and Human-Readable Content
Every MAP Transaction conveyed through Direct messaging SHALL use an outer multipart/mixed message containing at least two MIME parts. MIME Part 1 SHALL be a multipart/alternative human-readable communication. It SHALL contain exactly one text/plain .txt file and MAY contain additional text/html .html alternatives presenting the same communication. The text/plain representation SHALL precede the optional alternatives within multipart/alternative.
MIME Part 2 SHALL contain the structured payload defined by the applicable Transaction Definition. The Transaction Definition specifies its transaction-specific information objects and packaging representation. These common human-readable preservation requirements apply whether structured payload metadata uses the XD or FHIR Metadata option.
The structured payload in MIME Part 2 SHALL contain copies of every human-readable file included in MIME Part 1: the required .txt file and every optional .html alternative supplied there. Each packaged copy SHALL have the same file content as its corresponding outer representation. A separately generated summary, a link to the outer MIME part, or a machine-processable source object does not satisfy this requirement. The package metadata SHALL identify the included human-readable objects using the selected metadata representation.
Some Content Consumers retain or pass onward only the structured payload and discard the other outer MIME parts. Including the same human-readable files inside the package preserves access to the communication when this occurs. Human readability SHALL therefore be preserved both in the outer message and within the structured payload; the optional status of an HTML alternative does not make its packaged copy optional once that alternative is supplied in MIME Part 1.
The grouped Sender Actor SHALL include and validate the required human-readable copies in the structured payload and construct the outer MIME parts with the same file content. These responsibilities MAY be divided between Content Creator and Message Sender according to the implementation. The applicable Transaction Definition specifies the human-readable content coverage and transaction-specific information objects.