Four FHIR APIs, in production by January 1, 2027. Written for your CIO.
Vernier implements all four CMS-0057-F APIs against FHIR R4, US Core 6.1.0, CARIN Blue Button 2.0 and Da Vinci PDex and PAS, with 42 automated conformance assertions passing, and is ready for third-party validation. Plus FHIR Bulk Data export and the public prior-authorization metrics disclosure the rule also requires.
What CMS requires, and what bounds each one.
| API | Authorization model | Consent default | Bounded by |
|---|---|---|---|
| Patient Access | SMART on FHIR, authorization code with PKCE. The member authorizes each app. | — | Exactly one member |
| Provider Access | Client credentials. No request-time consent. | Member opt-out | Attribution, minus opt-outs |
| Payer-to-Payer | The member authorizes, naming a specific receiving payer. | Member opt-in | That authorization only |
| Prior Authorization | Client credentials for the provider organization (Da Vinci PAS). | — | Attribution |
The seven-day clock, not the endpoints.
CMS-0057-F shortened the standard prior-authorization decision window from fourteen calendar days to seven, with expedited decisions still due in 72 hours. That is the half of the rule that reorganizes a utilization-management department.
Vernier computes the determination due date from the shortened clock and carries it on every authorization resource. The report a plan actually needs is the one showing where it is about to miss: the queue of authorizations that will breach the clock this week, and who owns each one. The demo dataset deliberately includes breaches, because a dataset where every decision lands on time cannot demonstrate that report.
From January 1, 2027 the rule also requires plans to post prior-authorization metrics publicly, every year. Vernier publishes that disclosure from the same data the queue runs on.
Credibility, not features.
The prior-auth endpoint never denies
A submitted request is accepted and pended, with X12 review action A4 and the date a determination is due. Automated approval would be a convenience. Automated denial would be an adverse organization determination issued by software, which Medicare Advantage rules require to rest on individualized review by a qualified person.
Claims-derived diagnoses are marked unconfirmed
A payer holds claims, not a chart. Every condition is coded as an encounter diagnosis, never as a confirmed problem-list item, and every resource carries a Provenance saying it came from a claim, so a receiving clinician can tell payer-derived data from their own records.
Denial reasons are structured CARC codes
Not the word "DENIED." Given CARC 197, a member's app can say the authorization was absent. CMS-0057-F requires the specific reason.
Pharmacy fills map to MedicationDispense
A payer sees what was dispensed, not the prescriber's order, so the resource says so.
Out-of-compartment returns 404, not 403
Distinguishing "exists but forbidden" from "not found" is a member-enumeration oracle. The API does not confirm that a record it will not show you exists.
The compartment is a query, not a post-filter
The search layer throws if asked to run without an authorization compartment. A filter that gets skipped returns other people's data with a 200. A query that cannot be built fails loudly.
Eighty-some days is enough, if you start now.
A technical walkthrough for your CIO, compliance officer and UM director: the four endpoints, the consent model, the seven-day queue and the public metrics page.