3.1 Transaction Definition Architecture

This section establishes the rules for documenting a transaction consistently. The eight-section template provides a stable reading and review structure for both GenTXDefs and UCTXDefs. It does not prescribe the order in which an AI assistant must develop their contents.

A Generalized Transaction Definition (GenTXDef) specifies reusable requirements for a Direct-based Shared Activity. A Use Case Transaction Definition (UCTXDef) selects and specializes an applicable GenTXDef or defines a new use case transaction where no reusable definition fits.

3.1.1 Standard Transaction Definition Structure

Every GenTXDef and UCTXDef SHALL retain the eight top-level sections below in the stated order. Each section serves a distinct purpose; the detailed subordinate headings and transaction-specific content are supplied in the applicable TXDef template and authoring guidance rather than enumerated here.

Section	Standard heading	Purpose
1	Transaction Overview — WHY	Identifies the Shared Activity, purpose, scope, transaction identity, and relationship to the Framework and applicable GenTXDef.
2	Transaction-Specific Processing — WHAT IS SPECIAL	Specifies processing rules, exceptions, or anomaly qualifications particular to this Shared Activity beyond common Framework requirements.
3	Direct Message and Structured Payload Requirements — WHAT	Defines the information to be exchanged, the Workflow Activity Task when applicable, human-readable content, Provenance requirements, and transaction-specific message requirements.
4	XD Metadata Guidance — HOW	Provides the transaction’s XD metadata guidance and is always populated as the source for metadata representation requirements.
5	FHIR Metadata Guidance — HOW	Documents the FHIR metadata guidance generated by the AI assistant from Section 4 using the XD-to-FHIR Metadata Mapping Appendix; mapping gaps require review.
6	Context IG Guidance	Reserved as TBD pending republication of the Context IG; no current Context IG obligations are inferred.
7	Technical Actor Functional Requirements — WHICH TECHINCAL ROLE DOES WHAT	Assigns normative functional requirements to the grouped Sender Actor and Receiver Actor, including applicable Provenance responsibilities.
8	Relevant Examples	Illustrates applicable requirements and representations without replacing normative requirements or relying on versioned example filenames.

When a section has no additional transaction-specific requirements, it SHALL remain present and indicate that the applicable common requirements apply without modification. When a concept is not applicable, the section SHALL remain present and say “Intentionally blank — Not Applicable.” Section 6 is the exception: it SHALL remain a TBD placeholder pending republication of the Context IG.

The published eight-section order is designed for consistent reading and navigation. AI assistants MAY develop and reconcile content in a different sequence to respect dependencies. In particular, Section 4 XD Metadata Guidance is provided first, and Section 5 FHIR Metadata Guidance is generated by applying the XD-to-FHIR Metadata Mapping Appendix. Actor requirements and transaction-specific processing are reconciled with the information requirements before publication.

Common Framework requirements remain applicable even when they are not repeated in a TXDef. UCTXDefs specialize compatible GenTXDefs by adding specificity while retaining unmodified inherited requirements. The standard structure supports both reuse and later evaluation of newly defined UCTXDefs for possible RTC generalization under applicable governance.