Make your systems talk to each other — and to CMS-0057

• Patient data lives in three or more disconnected systems — EHR, billing, lab portal, imaging viewer — and nobody has the full picture.
• Your EHR doesn't support something you need — a device data feed, a custom field, a decision-support prompt at the point of care — and the vendor isn't going to build it for you.
• You're integrating with Epic or Cerner and need a SMART on FHIR app that opens with patient context already loaded, not a separate login.
• Standards like FHIR, CommonWell, Carequality exist on paper — but nobody has implemented them for your specific stack, especially if part of it is legacy.
• Someone on your team was told "we need CRD support" for CMS-0057 and started googling CDS Hooks an hour ago.

CMS-0057-F requires Medicare Advantage, Medicaid, CHIP and federal exchange plans to run prior authorization over FHIR APIs. Fax and phone don't go away — but from January 1, 2027 the API channel has to exist alongside them, under the same decision deadlines. If you build software for providers — RCM, DME, imaging, home health, telehealth, a smaller EHR — your clients will expect this in your product before then.

1. Jan 1, 2026 Already in force: decision deadlines — 7 calendar days standard, 72 hours expedited, with a specific reason for any denial (excludes QHP issuers on the federal exchanges) — and prior authorization metrics reporting, posted publicly by March 31 each year.
2. Apr 14, 2026 Separate rule extending the same requirements to drugs published. Proposed, not finalized.
3. Jan 1, 2027 The prior authorization API channel has to exist, under those same decision deadlines.
4. CY2027 → CY2028 Hospitals' separate electronic prior authorization measure under the Medicare Promoting Interoperability Program: optional bonus reporting for CY2027, required from CY2028.

Three specifications, one pipeline

1. Trigger — the clinician signs the order
2. 1 CRD Coverage Requirements Discovery

   At the moment a clinician places an order, their EHR asks the payer in real time whether it's covered, whether prior auth is required, what documentation is needed. The answer shows up as a card on screen.

   • EHR → your product → payer CDS Hooks order-sign request
   • payer → your product → EHR CRD card — prior authorization required
3. 2 DTR Documentation Templates and Rules

   If documentation is required, a SMART on FHIR app auto-fills what it can from the EHR; the clinician fills in the rest.

   • EHR → your product → payer SMART app launch, fetch the questionnaire the CRD card pointed at
   • EHR → your product → payer QuestionnaireResponse — pre-filled from US Core, clinician completes the rest
4. 3 PAS Prior Authorization Support

   The actual submission. The response comes back approved, denied with a reason, or pended, with a way to check status without another phone call.

   • your product → payer PAS Bundle → Claim/$submit
   • payer → your product Claim response

   • Approved Ready to proceed
   • Denied With a stated reason
   • Pended Awaiting documentation — poll for status instead of phoning

Each stage can be built and tested independently — you don't need all three live on day one to start reducing manual work. What implementing a client actually involves, request by request, is on the sandbox page.

If you only sell to hospitals, not payers

CMS-0057-F binds payers, not your product directly. But hospitals attesting under the Medicare Promoting Interoperability Program carry their own, separate electronic prior authorization reporting obligation — optional bonus reporting for the CY2027 EHR reporting period, required starting with CY2028. That measure is satisfied through certified EHR technology submitting prior authorization requests electronically via a PA API, which makes it a requirement on the software, not just on the hospital's internal process. For a hospital-facing product, the case for a working CRD/DTR/PAS client isn't only "your clients will ask" — for that measure, there's a reporting year attached to it.

These are fixed-scope stages, not a quote. The audit and the readiness assessment are fixed-fee at the scope shown, and the fee is credited toward implementation if you go ahead. Bigger estates and multi-product reviews get scoped first, then quoted. Implementation stages are quoted once scope is known — the durations above are what they typically take.