Framing the problem
HealthEdge's core administration platform is HealthRules Edge — named HealthRules Payer until HealthEdge renamed its portfolio on October 1, 2026. In the same announcement, GuidingCare became Clinical Edge, and HealthEdge introduced two delivery models: Enduring Edge (business process as a service) and Integration Edge (platform as a service). CMS-0057-F doesn't ask a HealthEdge plan to replace any of this. It asks for four FHIR APIs — Patient Access, Provider Access, Payer-to-Payer and Prior Authorization — live by the 2027 compliance date that applies to the payer type: January 1, 2027 for Medicare Advantage and state Medicaid/CHIP fee-for-service; the first rating period or plan year beginning on or after that date for Medicaid/CHIP managed care and QHP issuers (see the compliance timeline).
Hosting is the variable to settle first. HealthEdge's delivery models range from a platform the plan operates with HealthEdge to a full-service BPaaS partnership, and what a plan can reach — database access, service interfaces, scheduled extracts — depends on its hosting arrangement and contract. Where direct database access isn't available, the CMS-0057-F boundary has to be built from the interfaces and data feeds the plan is entitled to. Either way, the plan, not the vendor, stays accountable for the APIs.
Why the CMS APIs are not "expose the core database"
Pointing a FHIR façade straight at the core database is the tempting shortcut, and the one to avoid. The CMS APIs require conformant FHIR profiles (US Core, CARIN Blue Button, Da Vinci PDex and PAS), standard terminology, consent and opt-out enforcement, Provenance, and scoping rules (for example, leaving remittances and cost-sharing out of provider and payer-to-payer payloads). A raw database projection meets none of these reliably and ties your public API to an internal schema. The API should be a governed projection of core data, produced by an interoperability layer.
Where the core is vendor-hosted, this may be decided for you: the adapter works from vendor interfaces and extracts rather than database access, which makes the governed-projection model the natural fit.
Reference architecture
The adapter layer
For a HealthEdge plan, the adapter's jobs are:
- Read projection — claims, benefits and eligibility from HealthRules Edge; authorizations and clinical data from Clinical Edge; provider data from wherever the plan masters it. Expect a mix of real-time service calls and scheduled extracts, and plan for the five-year Payer-to-Payer history to come from the warehouse.
- Write/orchestration — a PAS request must reach the UM system of record, typically Clinical Edge, and return a decision. HealthEdge has described GuidingCare prior authorization as offering "FHIR-native APIs" (August 2025) without naming Da Vinci CRD, DTR or PAS, so confirm whether PAS can be accepted directly or needs a translation path. See CRD, DTR & PAS explained.
- Joining products — Patient Access needs coverage and claims from HealthRules Edge alongside PA status from Clinical Edge in one member view, keyed consistently across both.
- Terminology & consent — map plan codes to standard code sets; track Provider Access opt-out and Payer-to-Payer permission outside the core unless the plan has already built it.
API-by-API considerations
| API | Primary HealthEdge-side data | Adapter emphasis |
|---|---|---|
| Patient Access | Coverage and claims (HealthRules Edge); PA status (Clinical Edge) | Joining two products into one member view |
| Provider Access | Attributed members' claims, clinical data, PA | Attribution + opt-out enforcement |
| Payer-to-Payer | Up to 5 years of claims, encounters, PA | Feed coverage and timing under a hosted model |
| Prior Authorization | Clinical Edge UM rules and decisions | CRD/DTR rule content; the PAS path into Clinical Edge |
Build, overlay, or wait for the vendor
- Wait for a HealthEdge offering — reasonable only if HealthEdge publishes a complete four-API answer in time; with the 2027 compliance dates close, leave room for testing and partner onboarding.
- Build it internally — maximum control, highest effort, and the plan owns conformance; feasible where the plan has a FHIR team and reliable access to the feeds.
- Add a vendor-neutral interoperability layer — an overlay provides all four APIs in the plan's own cloud, independent of how the core is hosted, with the adapter built during onboarding against HealthEdge's interfaces.
A modern payer platform such as CloudHealthOffice can serve as either an interoperability layer integrated with HealthRules Edge or, depending on the implementation model, as part of the core backend itself. Either way, the backend stays an adapter concern behind a stable FHIR boundary.
Onboarding checklist
- Confirm the hosting model (vendor-hosted, Enduring Edge or Integration Edge) and which interfaces and extracts the plan is entitled to.
- Map which required data classes live in HealthRules Edge, Clinical Edge, provider data systems and the warehouse.
- Stand up the FHIR gateway + OAuth (SMART App Launch and Backend Services).
- Build the mapping/terminology layer to conformant US Core / CARIN / PDex / PAS profiles.
- Implement consent (Payer-to-Payer) and opt-out (Provider Access) enforcement.
- Wire the Prior Authorization API into Clinical Edge, directly or through a translation path.
- Add Provenance, audit logging, and the CMS prior authorization metrics you must report.
- Conformance-test each API before onboarding trading partners.