CMS-0057-F implementation for US payers and the healthtech teams serving them. We assess your gaps, build the FHIR APIs and connect the systems behind them, from a first workstream to a stalled-build recovery. New to the rule? Start with CMS-0057-F requirements explained.
Bring your current challenge. No presentation or patient data needed.
Engineering you can inspect. Our open-source CRD, DTR & PAS serversTrusted by leading healthcare technology companies and global enterprises to deliver AI-powered solutions that transform patient care.
AI-powered personalized guide for menopause support
Patient engagement and communication platform
Clinic Management Platform for patients and Doctors
Clinic Management Platform for patients and Doctors
Digital Health Platform for medical professionals
Patient engagement and communication platform
Clinic Management Platform for patients and Doctors
Digital Health Platform for medical professionals
Escrow Management Platform for Developers and Banks
Corporate Wellness and Health Management Platform
Leading Medical Research and Healthcare Institution
Cancer care, research and education institution
Mobile commerce and affiliate technology platform
AI-powered personalized guide for menopause support
Patient engagement and communication platform
Clinic Management Platform for patients and Doctors
Clinic Management Platform for patients and Doctors
Digital Health Platform for medical professionals
Patient engagement and communication platform
Clinic Management Platform for patients and Doctors
Digital Health Platform for medical professionals
Escrow Management Platform for Developers and Banks
Corporate Wellness and Health Management Platform
Leading Medical Research and Healthcare Institution
Cancer care, research and education institution
Mobile commerce and affiliate technology platform
Nirmitee open source / Da Vinci
Three public, payer-side reference implementations for the prior-authorization journey. Built by Nirmitee in Go and .NET, for engineering teams to read, run, test against and build on.
Coverage Requirements Discovery
Surface payer coverage and documentation requirements inside the ordering workflow, using CDS Hooks.
Explore hook discovery, coverage responses and sample payer rules.
Documentation Templates and Rules
Serve questionnaires, CQL libraries and value sets that a DTR client can use to collect the required clinical evidence.
Explore questionnaire packages and adaptive questionnaire responses.
Prior Authorization Support
Exchange FHIR prior-authorization requests and responses, including submission, inquiry and pended-request notifications.
Explore Claim operations, response bundles and sample decision workflows.
Four standardised FHIR APIs, plus operational changes to how prior authorization decisions get made and reported. The rule applies to Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid and CHIP managed care plans, and QHP issuers on the federally facilitated exchanges.
A FHIR interface where a provider can discover what documentation you require, submit the request, and receive the response electronically. Da Vinci CRD, DTR and PAS are recommended implementation guides under the 2024 rule, not a substitute for reviewing its required standards.
Expanded to carry prior authorization status alongside claims, encounters and USCDI clinical data, refreshed no later than one business day after the information changes.
Bulk FHIR access so in-network providers can pull claims, encounter, clinical and prior authorization data for their attributed patients. Requires attribution logic and a working patient opt-out.
When a member changes plans, up to five years of claims, clinical and prior authorization history moves across. Requires patient opt-in and member matching against the previous payer.
Decision timeframes, denial reasons and API usage reporting have payer-specific applicability. The 72-hour / seven-calendar-day timeframes exclude FFE QHP issuers under this final rule.
Prior authorization metrics posted publicly, covering CY2025. Annually thereafter.
API requirements generally begin January 1, 2027, with payer-specific dates and rating- or plan-year provisions. Confirm the applicable date for your organization.
MIPS clinicians and hospitals begin attesting to the Electronic Prior Authorization measure.
Source: CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F). Compliance dates vary by plan type. Confirm applicability for your organization against the final rule. Read the CMS final-rule fact sheet → The 2024 rule excludes drug prior authorizations. CMS’s 2026 drug prior-authorization rule is a proposal, not a finalized requirement.
CMS-0057-F names health plans. But an API only works if the systems on both ends of it do. Three very different builds come out of the same rule.
You carry the obligation. The build is four conformant FHIR APIs sitting on top of claims, UM, eligibility, clinical and provider data that currently live in five different systems.
Scope: source-to-FHIR mapping, Da Vinci profile conformance, consent and opt-out flows, member matching, Inferno and Touchstone testing, and the metrics you're required to report.
Talk about this →Your users will consume supported payer APIs as they become available. Prior authorization status, payer-held clinical history and five years of prior-plan data become reachable through a standard interface, if your product can consume it.
Scope: multi-payer FHIR client architecture, CRD and DTR handled inside your existing workflow, per-payer variation, and the authorization layer.
Talk about this →Your payer clients have asked for CMS-0057-F on top of a roadmap that's already full.
Scope: an embedded FHIR pod that builds the API layer inside your product, under your brand, in your repository.
Talk about this →A FHIR layer can sit alongside your existing systems where their interfaces and data support the scope. Assess missing data, update frequency and upstream dependencies before deciding whether source changes are needed.
Nothing in band one gets replaced. If a system can be read from, it can be mapped.
Select the workstreams your environment needs. We agree the deliverables, dependencies and acceptance criteria before implementation begins.
Coverage Requirements Discovery over CDS Hooks, Documentation Templates and Rules with CQL-driven questionnaires, and Prior Authorization Support wrapping the X12 278/275 you already exchange.
CARIN Blue Button for claims and encounters, US Core for clinical, PDex for prior authorization status. The one-business-day refresh enforced in the pipeline, not in a runbook.
Bulk FHIR export with attribution logic, group management, and patient opt-out honoured at query time rather than reconciled afterwards.
$member-match implementation, opt-in capture, and a five-year historical pull that reconciles duplicate records instead of stacking them.
X12 278/275, HL7 v2, C-CDA, flat files and proprietary claims schemas mapped bidirectionally to FHIR R4. We maintain the Mirth Connect Cookbook in the open; this is the day job.
SMART on FHIR, OAuth 2.0, OIDC, mTLS and UDAP-aligned dynamic client registration. Consent capture, revocation and audit at the resource level.
Inferno and Touchstone wired into CI, so profile validation runs on every merge instead of the week before attestation.
Immutable audit logs carrying decision timestamps and consent events, plus the Patient Access usage metrics and public prior authorization metrics as queryable outputs.
AWS, Azure, GCP, on-prem or hybrid. Containerised, infrastructure-as-code, handed over with runbooks. Your accounts, your repository.
You get a gap analysis across all four API domains, a source-to-FHIR mapping inventory, a risk register, a sequenced plan with effort estimates, and a build-versus-buy recommendation. If buying is the right call for you, the assessment says so.
Discuss your readinessScope a delivery team across FHIR architecture, integration engineering and QA. Agree milestones, demonstration cadence, repository access and handover deliverables in the statement of work.
Book an implementation callWe audit what exists, keep what conforms, replace what doesn't, and get you to a testable endpoint. Most rescues start with a conformance run to establish what's actually true.
Discuss your existing buildYour estimate depends on the systems behind the APIs and the work your team has already completed. A readiness assessment turns those dependencies into a scope you can compare across vendors.
Which Patient Access, Provider Access, Payer-to-Payer and Prior Authorization workstreams need engineering? Claims, clinical, eligibility and utilization-management sources each add mapping, access and data-quality work. Existing interfaces and reusable mappings affect the estimate.
Compare the engineering scope with FHIR platform licensing, cloud infrastructure, identity services and ongoing operations. Confirm who owns configuration, member matching, consent, monitoring and incident response before comparing proposals.
Agree the API versions, test scenarios, environments and evidence needed for acceptance. Include source-system failures, access controls, data reconciliation and handover. Separate third-party security assessments and partner onboarding from the implementation estimate.
Ask for named deliverables, responsibility boundaries, dependencies, exclusions, milestone acceptance criteria and an estimate by workstream. Separate discovery, implementation, third-party charges and support so you can compare the total delivery and operating cost.
Request a scoped implementation discussion →Review relevant code and test evidence, the engineers who would do the work, and how they handle your source systems. Our CRD, DTR and PAS servers and their Inferno results are public, so you can read the work before the first call.
Review CRD, DTR and PAS engineering evidence →Prepare with the CMS-0057-F readiness assessment or implementation planning kit. For a narrower workstream, explore prior authorization integration and FHIR integration services.
Sequence the work around source-data readiness, security review and acceptance criteria. The assessment sets the estimate, the sequence and the acceptance criteria for each API.
Inventory the source systems, map claims, UM, clinical and eligibility data to FHIR resources, identify the gaps that need new data capture, and agree the deployment model.
Stand up the FHIR core, build the connectors, configure Da Vinci profiles, implement member matching, and wire consent and opt-out flows.
Inferno and Touchstone runs against every profile, end-to-end API testing, load testing, penetration testing and security review.
Production deployment, monitoring and alerting, audit log verification, and the documentation your compliance team needs on file.
Review changes to implementation guides against the applicable regulatory version and your deployed system. Agree testing and update scope before adopting a new version.
Compliance builds have a habit of becoming write-only: data goes in to satisfy an auditor and never comes back out. Built properly, this one is a queryable clinical and claims store that everything else can sit on.
Member portals, provider-facing tools and third-party integrations run off the same FHIR store and the same auth layer. No second integration project.
Conditions, encounters and medications already structured to US Core. Flatten to tables for HCC models and HEDIS measures against the compliance store directly.
Longitudinal records, including the history that arrives through Payer-to-Payer, feed care coordination, utilization management and population health without a new pipeline.
Structured FHIR is what ML pipelines want. Prior authorization auto-decisioning, predictive models, NLP over clinical notes, all against a single source.
The attribution and export machinery built for Provider Access is the same machinery value-based care reporting and network analytics need.
Reusable mappings, documented interfaces and automated tests give future work a starting point. New standards and exchange requirements still need their own scope, validation and implementation.
FHIR R4 architecture, Da Vinci profile work, X12 and HL7 mapping: the layers CMS-0057-F sits on. Much of it is in public repositories, so you can read the code before you talk to us.
Coverage Requirements Discovery over CDS Hooks, in Go and .NET. Passes every test in the Inferno CRD Server suites: 136 passed, 0 failed (v2.2.1) and 86 passed, 0 failed (v2.0.1).
Review the CRD server on GitHub →Prior Authorization Support with Claim submission, inquiry and pended-request notifications. Passes every test in the Inferno PAS Server suites: 84 of 84 (v2.2.1) and 68 of 68 (v2.0.1).
Review the PAS server on GitHub →Questionnaire packages, CQL libraries and adaptive questionnaires. Passes the Inferno DTR Payer Server suites apart from two Inferno test-kit issues (one open, one fixed upstream and awaiting deployment): 43 passed, 2 failed (v2.2.0) and 17 passed, 2 failed (v2.0.1).
Review the DTR server on GitHub →CMS runs no certification program for these APIs, so Inferno results are the conformance evidence. Each repository links its public Inferno sessions.
Inspect the FHIR R4 server, its documentation and commit history. It passes 47 of 47 ONC (g)(10) SMART App Launch tests (11 Jun 2026).
Review on GitHub →Explore integration examples and assess how channel mapping and operational patterns relate to your source systems.
Review on GitHub →We cover security controls, data handling, contractual requirements and assurance evidence in scoping, alongside API conformance.
Tell us what needs to work, what exists today and where you are blocked. We’ll discuss the relevant API workstreams and whether an assessment, implementation pod or build review fits.
Prefer to send context first? Use the form. Share a high-level summary only: no patient data, credentials or confidential documents.
Our team will review the requirements you shared.
Healthcare integration engineering, with explicit scope for FHIR mappings, implementation-guide validation and operational handover.
Security & standards
HL7® and FHIR® are registered trademarks of Health Level Seven International. CMS-0057-F is a regulation of the U.S. Centers for Medicare & Medicaid Services.
From our YouTube channel
Explore the workflows and decisions behind this service. Demonstrations and recorded discussions have the scope described in each video.
Explore the prior authorization rule and API workflows. Confirm current requirements with official sources.
