Build vs. Buy for the Four Mandated APIs: A Decision Framework for the January 2027 Deadline

By January 1, 2027, impacted payers under CMS-0057-F must operate four FHIR API capabilities: a Prior Authorization API, a Provider Access API, a Payer-to-Payer API, and prior-auth enhancements to the existing Patient Access API. That's the compliance framing. The engineering framing is more useful: you are being required to stand up one FHIR data platform and one FHIR workflow integration, and the build-vs-buy calculus is different for each.

This article gives you a decision framework — not a vendor recommendation — organized around what the four APIs actually have in common, where they differ, and which parts of the work are undifferentiated versus strategic.

First, see the four APIs as two problems

Three of the four are data-serving APIs. Patient Access (enhanced), Provider Access, and Payer-to-Payer all answer the same underlying question — give me this member's claims, encounters, clinical data, and prior authorizations — for three different audiences (the member's apps, in-network providers with a treatment relationship, and other payers), with three different consent and access-control models (member-authorized apps via SMART on FHIR; attribution plus opt-out; opt-in plus enrollment-and- quarterly cadence). Same data pipeline, three doors.

The fourth is a workflow API. The Prior Authorization API doesn't just serve data — it participates in a live operational process. It must say whether a service needs authorization, enumerate documentation requirements, accept a request, and return a decision with specific denial reasons when adverse. CMS recommends the Da Vinci CRD/DTR/PAS guides for it, and unlike the other three, it plugs directly into your UM system's intake, routing, and adjudication — which means its integration cost dominates its platform cost. (It also has to coexist with the X12 278 rail; see why you need both rails.)

Any build-vs-buy analysis that treats "the four APIs" as one homogeneous purchase will misprice the fourth one.

The layer cake: what's commodity, what's yours

Work the decision layer by layer rather than API by API.

Layer 1 — FHIR platform plumbing: buy. FHIR servers, resource validation, US Core profiles, SMART on FHIR authorization, token management, consent gating, developer portals, conformance testing. This layer is undifferentiated across every payer in the country, it's where certified vendors have already made their mistakes on someone else's budget, and regulators' expectations (and reference implementations) are written against it. Building it yourself in 2026 buys you nothing except the ability to make novel errors. The realistic exceptions: payers that already operate a mature FHIR platform from the Patient Access era and are genuinely extending, not starting.

Layer 2 — the data layer: build (with help), because it's yours. Every API in the set is only as good as the member-level data behind it: claims and encounters mapped to USCDI classes, and — the CMS-0057-specific part — a clean, consolidated view of prior authorization data with consistent status vocabulary and reference numbers across your UM platform, delegates, and claims system. No vendor knows where your authorizations live, which delegate's status model means what, or why the same authorization has three reference formats. This is the long pole of the entire program, it has no regulatory deadline of its own, and it is the piece that makes or breaks all four APIs simultaneously. If you concentrate internal engineering anywhere, concentrate it here.

Layer 3 — UM workflow integration: build the edges, buy the bridge. For the Prior Authorization API specifically: CRD needs your PA-requirements rules exposed queryably (which forces overdue governance of your PA code lists); DTR needs payer-authored questionnaires and prepopulation logic per service category (a clinical-content investment no platform vendor can do for you); PAS needs bidirectional integration with UM intake and determination workflows. FHIR-to-X12 translation itself is increasingly commodity — clearinghouses and platforms sell it — but the semantic mapping decisions must be owned in-house, because they define your canonical model.

The questions that actually decide it

How real is your internal FHIR bench? Not "we have good engineers" — specifically, engineers who have shipped US Core / Da Vinci implementations. If the honest count is zero or one, platform building is off the table, and even heavy customization of a bought platform is risky.

What did your Patient Access implementation teach you? Payers that bought a Patient Access solution in 2021 and barely touched it since should assume that vendor relationship needs re-evaluation under the heavier 2027 requirements — API usage metrics reporting began in 2026, and prior auth data raises the data-quality bar. Payers that ran it well have a head start and a known-quantity vendor.

How fragmented is your authorization data? Count the systems where an authorization can be created or updated (UM platform, delegated vendors, claims system overrides, legacy portals). Below three, your data layer is a project; above five, it's a program — and it, not vendor selection, is your critical path to January 2027.

What does your UM platform vendor actually have? Many UM platforms now ship CRD/DTR/PAS modules of varying maturity. A genuinely capable module can collapse Layer 3 dramatically. Diligence it like infrastructure: demand live-production references, not roadmap slides — at this point in the cycle, "generally available next quarter" is a schedule risk you can't absorb.

Multi-line complexity? If you operate MA, Medicaid, and Marketplace products, requirements differ by line (QHP timeframe carve-outs, state Medicaid contract layers). Configurable-per-program beats hard-coded — a question to ask vendors and your own architects with equal severity.

Questions that belong in every RFP

Whatever the sourcing decision, these belong verbatim in vendor diligence:

• Which Da Vinci implementation guide versions do you support in production today, at which named customers, and what is your policy when the guides version again?
• Where does authorization state live in your architecture — and can you operate statelessly against our system of record, with no nightly sync?
• How do you handle the X12 278 rail: native translation, clearinghouse partnership, or "not our problem"? Show the mapping tables.
• What are your conformance-testing artifacts, and will you commit to delivery dates defined by passing them — with remedies?
• How is per-program configuration handled (MA vs. Medicaid vs. QHP differences), and what does adding a state contract's custom rules cost?

Vendors comfortable with these questions exist; vendors who answer them with roadmap language are telling you where your January 2027 risk lives.

A defensible default, and its failure modes

For a mid-market payer without a standing interoperability team, the defensible default is: one platform vendor for Layers 1 and the PAS/CRD /DTR scaffolding; internal (or SI-assisted) ownership of Layer 2; UM platform integration for Layer 3, using the UM vendor's modules where they demonstrably work in production.

Its failure modes are predictable. Watch for: the compliance-silo pattern, where the bought platform keeps its own authorization state and drifts from your UM truth (make "single system of record" a contractual architecture requirement); vendor roadmap slippage eating your testing window (contract for conformance-tested delivery dates with real remedies); and the data layer silently becoming "phase two" because it lacks a deadline (it is the deadline — every API demo against dirty data is a demo, not progress).

Build versus buy is the wrong binary. The right question is: which layers are undifferentiated compliance infrastructure, and which layer encodes how your organization actually manages care? Buy the first kind. Own the second — because after 2027, the payers that own their authorization data model will be the ones that can automate on top of it.