Building the Canonical Auth Record: One Status Model Across X12, FHIR, and Portals

Strip away the transport standards and every CMS-0057-F obligation is a query against the same object. The public metrics report is an aggregate query over authorizations. The Patient Access API is a member-scoped query over authorizations. The Prior Authorization API's status responses, the Provider Access API's auth data, the 72-hour and 7-day compliance clocks — all of them presume that somewhere in your estate there is one trustworthy answer to "what is the state of this authorization, and how did it get there?"

Most payers cannot answer that with one query today. The 278 gateway has its view, the UM platform has another, the portal database a third, the delegate feeds a fourth, and the claims system holds the version that actually pays. The canonical authorization record is the architectural commitment to end that: one internal entity per authorization, one status model, with every channel translated into it at the edge. This essay is about how to design that entity so it survives contact with both rails.

The core design commitments

One status vocabulary, owned by you. Neither X12 nor FHIR should be your internal state model. The HCR action codes are a response vocabulary — A1 certified in total, A2 partial, A3 not certified, A4 pended, A6 modified, C cancelled, CT contact payer — and the Da Vinci PAS ClaimResponse expresses outcomes through its own adjudication and review-action codings. Both are wire dialects. Internally you want a small, closed set that reflects how authorizations actually behave, something like: received, pended-clinical, pended-admin, approved, partially-approved, denied, cancelled, expired, appealed, plus terminal markers for withdrawn and voided. Every state must be reachable by a defined transition, and every transition must record which channel caused it. The test of a good vocabulary is that a portal action, a 278 response, and a PAS response describing the same real-world event land on the same internal state.

Channel is metadata, not identity. The moment "portal auth" and "EDI auth" are different record types, you have committed to reconciliation jobs forever. An authorization is an authorization; origin_channel and per-event channel are attributes. This matters legally as well as architecturally: the CMS-0057-F denial-specificity and timeframe requirements apply regardless of how the request arrived, so any compliance logic keyed to channel-specific tables is a defect waiting for an auditor.

Reference-number discipline. The canonical record owns identifier generation. The certification number returned in a 278, the preAuthRef in a PAS ClaimResponse, the number the portal displays, and the value a provider later puts on an 837 claim must all be the same string or deterministically derivable from it. Delegate-issued numbers get mapped to canonical identity at ingestion, and the map is persisted — "probably the same auth" is not a join condition. The failure mode this prevents is quiet: claims that pend for manual matching, API lookups that return nothing, members who see two authorizations where one exists.

Clock timestamps as first-class fields. Compliance clocks are computed from events, so the events must be unambiguous. At minimum: request received (per channel, since a fax received Friday and keyed Monday is a Friday request), request complete (all information needed to decide), decision made, notification sent (per recipient, per channel). Store them as facts and derive elapsed-time and breach status; never store a computed "days remaining" that rots. The distinction between decision-made and notification-sent is not pedantry — the regulatory definitions of timeliness attach to different points in different programs, and you want to be able to report either without a schema change.

Translate at the edge, never in the core

The translation layer is where the architecture earns its keep. Inbound, a 278 response from a delegated UMO carrying A2 becomes a partially-approved event with the approved quantities normalized; a PAS ClaimResponse with a pended review action becomes pended-clinical with its requested-information details attached; a portal reviewer's "approve" click becomes the same approved event a 278 A1 would have produced. Outbound, the current canonical state is rendered into each dialect: the same partially-approved authorization presents as an A2 with modified units on the 278 rail and as the corresponding PAS outcome on the FHIR rail, carrying the same reference and dates.

Two rules keep this honest. First, mappings are data, not code scattered through integrations — versioned tables from each wire vocabulary to the canonical one, with effective dates, so you can answer "why did this A6 become partially-approved last March?" Second, lossy mappings must be explicit. The wire vocabularies are not isomorphic — the details behind a 278 pend and a PAS request-for-information differ in structure — so the canonical event should preserve the original code and payload alongside the normalized state. Translate for the workflow; retain for the audit. The full crosswalk has its own write-up in mapping HCR action codes to FHIR ClaimResponse.

Event history is the record; current state is a cache

The single most consequential schema decision: the authorization is an append-only sequence of events, and "current status" is a projection of that sequence. A concurrent-stay authorization may accumulate a dozen decisions — initial certification, three extensions, a level-of-care revision, a partial approval, an appeal — and questions arrive in both tenses. The UM queue asks "what is the state now?" The auditor asks "what was approved as of the March 12 service date?" The metrics pipeline asks "how long did the initial decision take, separately from the extensions?" A current-state-only model answers the first question and destroys the evidence for the other two. Event sourcing here is not architectural fashion; it is the difference between reconstructing an appeal timeline from data versus from screenshots.

The projection earns its keep on read paths — APIs and dashboards should not replay history per request — but it must be rebuildable from events alone. If projection and event log can disagree with no way to tell which is right, the event log was decoration.

What the canonical record feeds

The CMS metrics report. Every published element — approval and denial percentages, appeal outcomes, extension usage, average and median decision times — is a query over canonical events with documented definitions. When the numbers are challenged (they are public; someone will), the defense is the query plus the event log, not a spreadsheet lineage diagram. Delegated decisions flow in as events from delegate feeds and are indistinguishable in the aggregate, which is exactly what the rule expects.

The Patient Access API. From January 2027 the Patient Access API must expose prior authorization status and related details to members, updated as status changes. That is a member-scoped projection of the canonical record, filtered to the member's authorizations and rendered as FHIR. If a member sees a different status in their app than the provider sees on a 278 inquiry response, you did not build a canonical record; you built another channel. The same store, projected differently, also feeds the Provider Access and Payer-to-Payer APIs — four mandates, one entity.

The UM workflow itself. Least glamorous, most valuable: reviewers, intake staff, and delegates all operating on one record means the end of the swivel-chair reconciliation where staff re-key portal requests into the UM platform and paste decision text back. The dual-rail argument in X12 278 vs FHIR PAS lands here too — both rails are dialects over one workflow only if the workflow reads and writes one record.

Sequencing the build

Nobody stands this up greenfield. The pragmatic order: define the canonical vocabulary and identifier scheme first, on paper, with UM, claims, and compliance in the room — it is a semantics negotiation, not a technology choice. Then stand up the event store and start mirroring: existing systems keep operating while their changes flow in as events, which surfaces every mapping ambiguity and identifier collision while the stakes are low. Promote the canonical record to source of truth one consumer at a time — metrics pipeline first (it is read-only and deadline-driven), then the member and provider APIs, then the operational UM surfaces. The systems you cannot migrate keep their local state and become edge-translated channels like any other.

The canonical record is the rare compliance project that is also just good engineering: every mandate CMS-0057-F added, and the next one it has not written yet, is another projection of the same well-kept ledger.

Verify regulatory specifics against the CMS-0057-F rule text (89 FR 8758) and current CMS FAQs, and wire-format semantics against the X12 005010X217 TR3 and the current Da Vinci PAS implementation guide.