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.
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
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
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. This engineering overview is not a legal determination of applicability.
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 readinessA FHIR architect, integration engineers and QA working as one pod. Two-week sprints, a working demo at the end of each, and code in your repository from day one. No black box, no handover cliff.
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 buildSequence the work around source-data readiness, security review and acceptance criteria. An assessment establishes a project estimate; this pathway is not a deadline or compliance guarantee.
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.
Inspect the implementation, documentation and commit history to evaluate its relevance to your architecture. A public repository is not a payer compliance certification.
Review on GitHub →Explore integration examples and assess how channel mapping and operational patterns relate to your source systems.
Review on GitHub →Discuss applicable security controls, data handling, contractual requirements and available assurance evidence during scoping. API conformance is one part of organizational compliance.
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. Nirmitee.io is not affiliated with, or endorsed by, HL7 International or CMS.
