BLOGS 
NEWSROOM 
CASE STUDIES 
WEBINARS 
PODCASTS 
ASSET HUB 
EVENT CALENDAR 
TL;DR
In April 2026, CMS proposed a rule reshaping custom EHR architecture with mandatory FHIR Implementation Guides for prior authorization, clinical decision support, and data exchange. The comment period closed mid-June, with the final rule expected in H2 2026. By January 2027, EHR builders and payer integrators must support specific FHIR IGs. Custom EHR developers face three options: build in-house, purchase pre-built accelerators, or implement in phases.
I. What CMS-0062-P Requires (and Why Now)
It’s 3pm on a Wednesday. You’re a CTO at a health-tech startup building a custom EHR for rural clinics. Your compliance team lands in your Slack: “The new CMS rule on prior auth. Do we support it?” You pull up the Federal Register. 91 FR 19890. April 14, 2026. 91 pages. FHIR acronyms stacked three deep. Deadlines. The question is simple: what exactly do you need to do, and when?
Here’s the shape of it.
CMS-0062-P (published April 14, 2026) extends the 2024 interoperability rule (CMS-0057-F) to cover pharmaceutical prior authorization. It applies to Medicare Advantage, state Medicaid FFS and managed care, CHIP, and QHP issuers on federally facilitated exchanges. The mandate is clear: payers must report API endpoints for five specific services to CMS, including a new Prior Authorization API, and they must enforce specific FHIR Implementation Guides that are currently “recommended” but will become required.
That’s the shift. Right now, payers implement FHIR IGs at their own pace. Your EHR can work with or without them, and things mostly still work. Under CMS-0062-P, that optional becomes mandatory. Not optional for payers. Mandatory for anyone building software that connects to payers.
The compliance window is phased. Based on the CMS-0057-F pattern, expect January 2027 for most APIs (Patient Access, Provider Directory, Provider Access, Payer-to-Payer). Prior auth drugs likely follow in January 2028. Manufacturers must report implementation status to CMS. Miss the deadline, civil monetary penalties apply.
Here’s why this matters now. The comment period closed June 15, 2026. That window is gone. But the final rule hasn’t shipped yet. It’s H2 2026, which means you have roughly six months from now to plan your build. Six months to decide: build FHIR IG support yourself, buy a pre-built stack, or phase it in?
II. Which FHIR Implementation Guides You Actually Need
The rule says “mandates specific FHIR Implementation Guides.” But which ones?
The da Vinci suite is evolving. CRD. DTR. PAS. CDS Hooks. They’re built on top of FHIR R4. They’re versioned. Version 2.0 of CRD is not backward-compatible with 1.1 in some spots. You could build to every version and every IG, but that’s nine months of work that doesn’t matter. Here’s what actually matters.
Prior Authorization APIs require two core FHIR IGs: CRD (Coverage Requirements Discovery) and PAS (Prior Authorization Support). These are proposed in CMS-0062-P as mandatory. CRD lets your EHR ask a payer upfront, “Does this patient need auth for this drug?” PAS lets your EHR send the authorization request and get a decision back. Both are da Vinci IGs. Both are moving toward FHIR R4 as the baseline.
Clinical Decision Support flows through da Vinci CDS Hooks. This one’s still emerging in the regulatory world, but it’s on the roadmap. CDS Hooks is a trigger mechanism, not an IG by itself. Think of it as the plumbing that fires an IG-based decision support rule.
Data Exchange is the foundation: USCDI v3 minimum (ONC HTI-1 final rule). That’s 94 data classes your EHR must expose via your Patient Access API. USCDI v3 certification requirements harden through 2026-2027.
The version strategy is critical. CMS typically mandates a baseline version plus N-1 backward compatibility. Example: if da Vinci CRD 2.1 is the baseline by January 2027, you’re building support for 2.1 and 2.0. You’re not supporting 1.x. Check the final rule (expected September-November 2026) for exact versioning.
And here’s the wrinkle: payer variation. Not all payers implement all IGs at launch. Expect 18-24 months where some payers are “CMS-required compliant,” others are early adopters on some IGs but not others. Your architecture has to handle partial IG support per payer. One payer supports CRD 2.1. Another supports CRD 2.0 and PAS 1.2. Your EHR queries for capabilities and adapts.
Related Read: FHIR Ready Architecture: How to Build for EHR Integration at Scale
III. Custom EHR Architecture: Building for Prior Authorization FHIR APIs
Here’s the workflow you’re building for.
Clinic staff log into your custom EHR. It’s 10:15 am. They’re entering an order for a new medication: Humira 40mg weekly for a patient with rheumatoid arthritis. The EHR has the patient’s insurance carrier on file (Blue Cross Blue Shield). Your system triggers CRD. What happens next is the core of CMS-0062-P.
Your EHR queries the payer’s CRD endpoint: “Patient XYZ, insurance ABC, drug Humira 40mg weekly, indication RA. Do you require prior auth?” The payer’s CRD server responds in FHIR format. The response includes decision logic: “Yes, auth required. We need: diagnosis confirmation, previous therapy history, and trial-of-other-drug documentation.”
If the payer also implements DTR (Documentation Templates and Rules), your next step is triggered automatically. DTR returns a form template: exact fields the payer needs, what they call them, validation rules for each field. Your EHR renders that template inline. The clinic staff fills it in. The form validates in real time.
Then PAS fires. Your EHR packages everything: patient demographics, clinical data, the completed form, supporting documents, your clinical justification for the drug choice. All wrapped in FHIR. Your EHR sends it to the payer’s PAS endpoint. The payer acknowledges receipt. Your system stores the request ID.
The decision comes back asynchronously. Approved. Denied. Pending (need more docs). The notification lands back in your EHR through a webhook or a polling mechanism. The clinic staff sees the result without leaving the workflow. No portal login. No hunting through email. No calling the payer. That’s the user experience CMS-0062-P is building toward.
Under the hood, that workflow requires three architectural layers.
Layer 1: The API integration layer. Your EHR speaks FHIR REST to payer endpoints. You handle HTTPS, OAuth 2.0 authentication, error handling, timeouts, and retries. You manage API versioning per payer. Some payers are on CRD 2.1; others are 2.0. Your code routes to the right implementation per payer.
Layer 2: The data mapping layer. Your EHR’s internal data model doesn’t match the FHIR specification exactly. You build transformations: EHR data → FHIR resources → payer semantics. You handle SNOMED CT, ICD-10, and NDC drug coding. You validate that clinical data flowing through is complete and correct.
Layer 3: The security and audit layer. HIPAA compliance is non-negotiable. All exchanges are encrypted in transit (HTTPS with modern TLS). Encrypted at rest. Signed with digital signatures. Logged for audit (who requested what, when, what was the result). Design for a 7-year audit retention.
I’ve watched three custom EHR builds attempt this in-house. The first two took 24+ weeks and had to rebuild the security layer twice. The third used a pre-built FHIR middleware and cut that to 12 weeks. The difference wasn’t engineering quality. It was time spent on problems that are already solved.
Get Your Custom EHR Ready for FHIR IG Mandates Now!
IV. Three Build-Path Decisions for Your Roadmap
You have roughly six months from now until the CMS-0062-P final rule to decide your build path. Six months to pick between three options.
PATH A: PRE-BUILT ACCELERATOR (8-12 weeks)
Use a pre-built FHIR IG stack connect health. It’s FHIR IG certified. Tested against 15+ payers in production. It handles CRD, DTR, and PAS across FHIR R4 and upcoming versions. When a new FHIR IG version ships, the vendor updates it. You don’t chase spec changes every quarter.
Timeline: 8-12 weeks (integration + testing, not building the layers from scratch)
Cost: $200K-500K (license fees + custom integration work)
Risk profile: Low — compliance risk is on the vendor
Pick this when: You need fast time-to-compliance. Your team’s strengths are clinical features, not interop plumbing.
PATH B: CUSTOM BUILD WITH EXTERNAL STACK (16-24 weeks)
Pick a FHIR middleware (Medplum, SmileCDR, Aidbox). FHIR-first platforms built to implement IG specs quickly. You build your EHR’s prior auth logic on top of their FHIR layer. You own the CRD decision engine. They own the FHIR spec compliance.
Timeline: 16-24 weeks (spec learning + design + integration + payer testing)
Cost: $500K-1.5M (middleware license $50-100K/year + custom development)
Risk profile: Medium you own the integration layer, vendor owns IG compliance
Pick this when you need workflow control. Your team has FHIR engineers. You don’t mind a vendor dependency for spec updates.
PATH C: IN-HOUSE BUILD, PHASED (24-36 weeks)
Build FHIR IG support in-house. January 2027: launch CRD only. January 2028, add PAS. It’s a phased approach because full prior auth support is complex, and you’re learning the spec as you build.
Timeline: 6 months for CRD (Jan 2027 go-live), then 6 months for full PAS suite
Cost: $1M-3M fully loaded (FHIR engineers + ongoing maintenance + spec-chasing)
Risk profile: High you own everything, including every IG version update
Pick this when: You have a deep FHIR team. Prior auth is your long-term competitive moat. You have budget runway for a multi-year program.
The decision tree is simple. Speed + budget: Path A. Control + engineering depth: Path B. Long-term platform: Path C.
Most builders I talk to underestimate Path C. In-house FHIR development sounds cheaper upfront. It’s not. By month 18, you’ve rewritten the auth decision engine twice, rebuilt security once, and you’re still not at parity with a vendor who had 30 customers before you started.
V. Common Pitfalls: What Custom EHR Builders Often Miss
I’ve sat through seven custom EHR prior auth implementations. The same stumbles come up.
PITFALL 1: API VERSIONING DRIFT
You build to da Vinci CRD v2.0. Six months later, v2.1 ships. It changes the decision tree format slightly. Not backward-compatible. Payer A updates to v2.1 on January 15, 2027. You don’t. January 16, their CRD endpoint rejects your v2.0 requests. Clinic staff get an error. You’re down until you patch.
Lesson: version your FHIR adapters. Build version-detection into your payer discovery. Test against 2+ versions in sandbox before production.
PITFALL 2: PATIENT CONSENT FLOWS AREN’T COVERED BY FHIR
The FHIR spec defines the data format. It doesn’t define the consent model. You still have to: (1) ask the patient for permission to share with the payer, (2) document that consent, (3) handle consent revocation, (4) audit it all. Most builders assume FHIR IG compliance covers it. It doesn’t.
Lesson: build a separate consent engine. You need a patient-facing form: “Is it okay if we send your clinical info to Blue Cross to check prior auth?” That’s not in the FHIR spec. You have to design it.
PITFALL 3: ERROR HANDLING AND FALLBACK WORKFLOWS
What happens when the payer’s CRD endpoint times out? What if PAS submission fails? Most builders don’t plan for this. Clinic staff hits “submit prior auth,” gets an error and is stuck. No fallback. No retry logic. No manual escalation path.
Lesson: design for failure. CRD times out? Show a manual auth entry form. PAS fails? Queue it for async retry + notify the clinic staff. Pay down? Route to a clinical escalation workflow. Build this into your MVP, not as a Phase 2.
PITFALL 4: USCDI V3 DATA COMPLETENESS
You implement CRD and PAS beautifully. But your EHR’s clinical data is incomplete on USCDI v3 fields. Maybe your problem list is sparse. Maybe medication entries lack dose/frequency. CRD decision logic depends on complete data. If the payer asks “what other therapies has the patient tried?” and your EHR has no medication history, the auth request fails.
Lesson: audit your USCDI v3 data completeness before prior auth workflows. Fix data quality first. Implement prior auth after.
PITFALL 5: ENCRYPTION AND AUDIT LOGGING UNDERESTIMATED
Most builders spend 1-2 weeks on security. It usually needs 3-4 weeks of dedicated work. If you miss this, you’re not HIPAA-compliant, and CMS will flag you.
Lesson: plan 25-30% of your FHIR build timeline for security and audit infrastructure. Build it first, not as an afterthought.
Related Read: Custom Software Development Services a Complete Guide
VI. Testing Your FHIR IG Implementation Against CMS-0062-P
Before you go live, compliance means real testing. Against real payer sandboxes.
Each major payer (UnitedHealth, Anthem, Aetna, Medicaid MCOs) runs a sandbox. You register, get test credentials, and run your CRD/DTR/PAS flows end-to-end. Expect 2-4 weeks per payer. You submit a CRD query, the payer sandbox returns a decision, and you verify your code parses it correctly. Submit a PAS request, verify the approval notification lands in your system.
After payer sandboxes: conformance testing. Da Vinci/Argonaut conformance test suites. Your implementation submits test payloads. The test suite validates that your FHIR resources are spec-compliant. They must pass before you claim CMS compliance.
Then volume and latency testing. Fire 100 CRD queries per second. Can your system handle it? CMS compliance includes SLA adherence: CRD response under 1 second, PAS decision within 7 days standard / 72 hours expedited. If you can’t hit those SLAs in testing, you won’t have in production.
Cross-payer interoperability testing is the piece most builders skip. One payer’s CRD implementation differs subtly from others. They interpret the FHIR spec slightly differently. Test against 3-5 major payers in sandbox, not just one.
Finally: audit logging and access control testing. Verify the audit log captured the prior auth exchange. Verify only authorized users can access patient data. Verify consent revocation is logged. Table stakes for HIPAA compliance.
VII. Timeline: From Now Through Compliance
It’s July 1, 2026. Here’s what’s ahead.
Now (July 2026): Comment period closed June 15. CMS is reviewing 900+ comments. Final rule is being drafted.
Final rule (September-November 2026): CMS publishes. It includes compliance dates, mandatory FHIR IGs and enforcement mechanisms.
January 2027: First compliance deadline (likely). Patient Access API + Payer-to-Payer API must be live. Most prior auth APIs shift to required status.
January 2028: Full prior auth API compliance likely (CRD + DTR + PAS for drug prior auth).
Your build timeline depends on your path:
Path A (pre-built accelerator): Start now. Integrate by October 2026. Three-month buffer before the January 2027 deadline. If integration runs 12 weeks smoothly, you’re done mid-November.
Path B (custom + external stack): Start now. Target integration by August 2026.
Tight. Three months to production is doable with a strong team, but there’s no buffer. You’re live by November, with two months of post-launch stability work.
Path C (in-house, phased): Start now for Phase 1 (CRD). January 2027, you launch CRD only. January 2028, you ship PAS. If you start in July and pick Path C, you’re on a tight timeline for Phase 1. CRD alone takes 16-20 weeks if you’re careful. That’s a late October, early November delivery. Two-month runway to find bugs before the January 2027 deadline. Tight.
Prepare Now Before the Compliance Clock Starts
CMS-0062-P may still be in the proposal stage, but waiting for the final rule before acting could leave custom EHR teams with little room for architecture changes, payer testing, security validation, and FHIR version updates. The priority now is to assess the current interoperability stack, identify gaps across CRD, PAS, USCDI v3, consent, and audit logging, and select a realistic build path based on available time, budget, and internal FHIR expertise.
Whether the organization chooses a pre-built accelerator, an external FHIR stack, or a phased in-house build, early planning will reduce compliance risk and prevent expensive rework later. The teams that start readiness assessments now will be better positioned to adapt when CMS confirms the final Implementation Guides, versions, and enforcement dates.
It’s proposed as of July 2026. The comment period closed June 15, 2026. CMS is reviewing comments. The final rule is expected in H2 2026 (September-November). Once final, compliance date clocks start. Most healthcare rules include 60-day implementation windows post-publication, so January 2027 likely becomes the first compliance date.
CMS-0062-P mandates CRD and PAS for prior authorization. DTR is triggered by CRD (if the payer uses it) but isn’t a separate mandate. CDS Hooks is emerging but not yet a hard requirement in CMS-0062-P. Start with CRD and PAS. Add others if payer partners need them.
FHIR R4 is stable and widely used. R5 is newer. CMS-0062-P and da Vinci IGs are built on R4. R5 adoption is years away. Build to R4. R5 is unnecessary.
Your requests fail. The payer’s CRD endpoint rejects v2.0 payloads. You get an OperationOutcome error. Clinic staff see errors in your EHR. You must patch and redeploy. This illustrates why version detection and multi-version support prove critical.
Sandbox testing takes 2-4 weeks per payer. Conformance testing takes 1-2 weeks. Volume/latency testing takes 1-2 weeks. Plan 6-8 weeks minimum for full testing. On tight timelines (Path A), run testing in parallel with integration work, with test and dev teams working simultaneously.
