The CMS trace repository keeps a FHIR record of the transactions that Smile CDR processes for the CMS interoperability APIs, such as Prior Authorization, Payer to Payer, Provider Access, and Patient Access requests. Each transaction log event is stored as a Communication resource, with one Binary resource for each request or response body. Payers can search these resources to audit API traffic, troubleshoot exchanges, and produce CMS reports.

The trace repository is built from standard Smile CDR modules:

A Transaction Log Broker module publishes the selected transaction log events to a topic on the Cluster Manager's message broker.
A Camel module consumes the topic with the broker consumer, and maps each event to a Communication resource with a JQ transformer.
A FHIR Storage module and a FHIR Endpoint module, the trace repository and trace endpoint, store the resulting resources and serve them to reporting clients.

The configuration of these modules is shared by all CMS APIs. Only the Transaction Log Broker's event filter and the JQ transformer that maps each event are specific to an API. See Configuration and JQ Transformers.

Data Flow

Publication: A Transaction Log Broker module publishes each matching transaction log event to its topic.
Consumption: A Camel route reads each event from the topic.
Mapping: The route applies the JQ transformer for the event, which returns a Communication resource and the original event. If the transformer fails, an error transformer returns a Communication that records the error instead.
Bundling: A shared JQ transformer wraps the Communication resource in a FHIR transaction Bundle, with one Binary resource for each request or response body in the event.
Storage: The route POSTs the Bundle to the trace endpoint, which stores the resources in the trace repository.

sequenceDiagram
    autonumber
    participant TxLog as Transaction Log Broker
    participant Broker as Message Broker Topic
    participant Camel as Camel Module
    participant Endpoint as Trace FHIR Endpoint
    participant Repo as Trace Repository

    TxLog->>Broker: Publish transaction log event
    Broker->>Camel: smile:clustermgr/broker consumes event
    Camel->>Camel: JQ transformer maps event to Communication
    Camel->>Camel: wrap-bundle.jq builds transaction Bundle (Communication + Binary)
    Camel->>Endpoint: POST Bundle with system user credentials
    Endpoint->>Repo: Store Communication and Binary resources
    Endpoint-->>Camel: 200 OK with transaction-response Bundle

Stored Resources

Each transaction log event produces the following resources:

Resource	Contents
`Communication`	One per event. Records the CMS API, the event type and subtype, the request and response times, the outcome, and the parties to the exchange. Its `payload` lists one attachment for each event step, which links to the step's `Binary` resource.
`Binary`	One per event step, for example `ENDPOINT_RECEIVE` and `ENDPOINT_REPLY`. Holds the request or response body of that step. When the Transaction Log Broker module does not publish bodies, the `Binary` resource holds an empty JSON object.

The Communication resources share the following conventions, so that clients can search the trace repository across all CMS APIs:

Element	System	Value
`meta.tag`	`https://smiledigitalhealth.com/communication/category`	The CMS API or workflow: `prior-auth`, `p2p`, `provider-access`, `member-attribution`, or `patientaccess`. A second tag with the code `error` marks a `Communication` created by an error transformer.
`identifier`	`https://smiledigitalhealth.com/communication/message-key`	The `transactionGuid` of the transaction log event.
`category.coding`	`https://smiledigitalhealth.com/communication/event-type`	The event type of the transaction log event, for example `FHIR_REQUEST`.
`category.coding`	`https://smiledigitalhealth.com/communication/event-sub-type`	The event subtype of the transaction log event, for example `FHIR_READ`.

For example, the following search returns up to 100 Prior Authorization traces sent since November 1, 2026, most recent first:

GET https://example.com/trace-fhir/Communication?_tag=https://smiledigitalhealth.com/communication/category|prior-auth&sent=ge2026-11-01&_sort=-sent&_count=100

Security

The trace repository holds the same PHI as the transactions it records, including request and response bodies when the Transaction Log Broker module publishes them. Restrict access to the message broker topics, the trace endpoint, and the trace repository's database accordingly. See Trace FHIR Endpoint.

CMS APIs Using the Trace Repository

Patient Access API: see Record Usage in the Trace Repository.

Configuration