Appearance
3.5 Workflow Unit and Structured Payload Architecture
Each workflow unit comprises a SubmissionSet representation, an optional Workflow Activity Task (unless required by the applicable Transaction Definition), and the information objects needed to perform the requested activity, carried together in a structured payload. This section establishes their nesting and cardinalities and the completeness and reference-resolution requirements needed for independent processing.
Inside Out Information Model
Information → Classification → Context → Provenance → Human Readability → Workflow Activity → Structured Payload → Direct message
This model begins with the information to be shared, establishes its classification, Context, and Provenance, and preserves human readability. When present, the Workflow Activity Task provides a machine-processable expression of the requested Shared Activity. The structured payload organizes these components, and the Direct message transports it. DocumentEntry identifiers identify metadata entries; their order does not determine the explanatory order of a Transaction Definition.
Independently Processable Workflow Unit
Each independently processable workflow unit SHALL have exactly one SubmissionSet representation and zero or one Workflow Activity Task, unless the applicable Transaction Definition requires exactly one Task. It SHALL contain the information objects required by its Transaction Definition. An IHE XDM package MAY carry 1..* SubmissionSets, each representing a separate workflow unit. The FHIR Collection Bundle representation SHALL carry the corresponding SubmissionSet List resource(s), information objects, and supporting resources as described in Appendix D. Requirements for each workflow unit apply independently.
For the FHIR Metadata option, the current SubmissionSet List SHALL conform to the MAP SubmissionSet List profile identified in Section 3.7.2. This requirement applies independently of whether the workflow unit contains a Workflow Activity Task. The List indexes the submitted information objects through references to their DocumentReference resources; supporting resources do not become submitted information objects solely because they appear in the Bundle.
SubmissionSet and Its Relationship to the Task
The SubmissionSet is the authoritative package-level representation of the transaction being performed. SubmissionSet.purpose identifies the Shared Activity independently of whether a Workflow Activity Task is included. SubmissionSet.contentTypeCode classifies the principal content of the structured payload and establishes expectations for its constituent DocumentEntry.typeCode values. Each DocumentEntry.typeCode classifies its corresponding information object. The applicable Transaction Definition specifies required and permitted information-object types and cardinalities; contentTypeCode is not a complete manifest and does not require every DocumentEntry to use the same typeCode. The SubmissionSet also carries package-level patient, Context Instance, correlation, source, and other metadata and organizes membership in the associated structured payload.
When a Workflow Activity Task is present, the SubmissionSet and Task describe the same Workflow Activity from complementary package-level and machine-processable perspectives. Task.code SHALL carry the same transaction code and code system as SubmissionSet.purpose. Their intentionally duplicated semantics SHALL remain aligned as follows:
| SubmissionSet | Workflow Activity Task | Common rule |
|---|---|---|
| contentTypeCode | Primary information object type | Package-content classification. Establishes expectations for constituent DocumentEntry.typeCode values; unless a Transaction Definition states otherwise, use the principal DocumentEntry.typeCode. The Transaction Definition governs other expected types and cardinalities. |
| 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. |
Within a continuing Transaction Instance, SubmissionSet.uniqueId and the corresponding List business identifier SHALL remain unchanged and aligned. When a Workflow Activity Task is present, its designated Task.identifier SHALL match that business identifier and remain unchanged within the continuing Transaction Instance. An intermediary revising the structured payload SHALL assign a new SubmissionSet.entryUUID or List.id to the updated metadata representation, preserve that shared business identifier, and update package membership and affected references. Adding Provenance or revising representation identifiers alone SHALL NOT be treated as initiation of a new logical Task or Shared Activity. Appendix B.12 explains these identity layers.
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 | Indicates whether structured payload acceptance reporting is requested. Absence of the request does not suppress permitted or required Workflow Status reporting. |
| Workflow Status Update Endpoint | R, 1..* for originating transactions that use TX8 reporting. One or more Direct endpoints designated to receive TX8 Workflow Status for the originating Transaction Instance. |
When a Workflow Activity Task is present, Task.code SHALL carry the same transaction code and code system as SubmissionSet.purpose and apply the TransactionTypesVS Extensible binding in Section 3.7.6. Context Instance type declarations SHALL apply the Extensible binding in Section 3.6.2. Each Transaction Definition identifies its transaction code and any explicit use-case or transaction-specific fixed values. An endpoint supporting an originating transaction MAY process an otherwise conformant package without interpreting or executing an optional Task, unless that Task processing is explicitly required by the applicable Transaction Definition and within the endpoint’s declared capabilities. The presence of an unsupported optional Task SHALL NOT by itself constitute a processing anomaly or rejection reason.
When a Workflow Activity Task is present and TX8 reporting is applicable, workflow status instructions SHALL be carried in that Task rather than Direct transport headers, and the Task SHALL carry the information needed to correlate a subsequent TX8 report with the originating Transaction Instance. When Task is absent and TX8 reporting is required, destination resolution SHALL follow Section 3.9.7; the originating SubmissionSet business identifier SHALL remain available for correlation. Task presence alone does not establish a TX8 reporting obligation, and support for an originating transaction does not imply TX8 send or receive support.
An intermediary that adds a Workflow Status Update Endpoint MAY carry an updated representation of the same logical Workflow Activity Task. The updated representation SHALL have a new Task.id while preserving the designated Task.identifier, the requested Shared Activity, existing endpoint instructions, and other transaction information that remains applicable. References and metadata describing the updated Task SHALL resolve to the carried representation; unchanged information objects MAY be retained. The intermediary SHALL add Provenance for its update without modifying another actor’s assertions. This package-representation rule does not prescribe changing a FHIR server resource’s id during an ordinary server-managed update.
No more than one Workflow Activity Task SHALL be carried per workflow unit. TX8 SHALL carry exactly one Workflow Activity Task. TX8’s primary information object SHALL be a minimal identification snapshot of the originating SubmissionSet/List being reported on. TX8’s own report SubmissionSet/List and Workflow Activity Task are separate objects. A second Workflow Activity Task SHALL NOT be added.
Structured Payload Contents
The structured payload contains its SubmissionSet metadata representation, any included Workflow Activity Task, primary information object, permitted secondary information objects, Provenance information objects, human-readable files, and any supporting resources required to resolve references. Its SubmissionSet organizes the submitted information objects through metadata and membership relationships; it does not physically contain every file or Bundle entry.
| 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 2.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.
Structured Payload Completeness and 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 the Workflow Activity Task SHALL be contained in that Task. References to those contained resources SHALL use #<contained-id> within the same containing resource. References between contained resources are permitted within that same root; nested containment and references into another resource’s contained resources SHALL NOT be used. DocumentEntry.URI SHALL locate the packaged information object using the applicable XDM relative file URI. A FHIR literal Reference SHALL identify a FHIR resource; a relative filename locating a CDA or other non-FHIR object SHALL NOT be treated as a FHIR resource reference. TX8 Provenance targets SHALL use the logical identifier rule in Section 3.9.4.
FHIR Collection references. For the FHIR Metadata option, when a Task is included, the Task and its supporting resources SHALL be separate peer Bundle entries, according to Appendix D. Literal references SHALL resolve to the carried resources they identify. The XD containment rule does not apply to this FHIR Collection representation. TX8 Provenance assertions within a separate Provenance Collection Bundle SHALL identify their target using Reference.identifier as specified in Section 3.9.4; consumers SHALL NOT depend on an implicit search outward through enclosing Bundles.
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.