Live CMS-0057-F Readiness Scorecard

Continuous, methodology-anchored readiness grades for major US payers — refreshed daily, not annually.

Last updated: awaiting first scan

How this is different from a snapshot scorecard

Other published scorecards capture a single point in time and then age out. Tessara probes each entity daily and re-grades automatically when payers fix their endpoints. The whole point of Tessara is continuous conformance — this scorecard is that promise made observable.

Methodology in detail ↓

Why does my grade look wrong?

We probe public endpoints against a pinned IG. If you believe our finding is in error, send us the details — we'll re-probe within 5 business days.

Challenge findings

Claim ownership of your entity page

Compliance lead at one of the entities below? Get verified contact + early notice of grade changes.

Claim entity

Methodology

What we probe

v1 probes the Provider Directory API /metadata endpoint per entity. Provider Directory is the only payer FHIR API CMS-9115-F (42 CFR 422.119(b)) requires to be publicly accessible without authentication. Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs require per-patient or per-provider OAuth and are scored as "auth-walled, not assessable from public probe" in v1. v2 will add credentialed probing.

Implementation Guide pin

v1 IG: HL7 FHIR Da Vinci PDex Plan Net STU 1.1.0 (US Provider Directory). IG version is visible above and changes trigger a full re-grade.

Grade scale

  • A — 0 findings of any severity
  • B — 1-2 findings, none CRITICAL or HIGH
  • C — 3-5 findings, none CRITICAL; at most 1 HIGH
  • D — 6-10 findings OR more than 1 HIGH
  • F — Any CRITICAL OR more than 10 findings
  • U — Endpoint not publicly discoverable (itself a CMS-9115-F finding)
  • E — Probe error (transient; auto-retried)

INFO findings are reported on the entity page (transparency) but do not lower the grade. We never penalize structural extensions on top of the spec.

Conservatism

  1. Grade is never lowered by transient errors. Three consecutive successful probes are required before lowering a grade from a higher historical grade.
  2. Grade upgrades happen on the first clean probe — when a payer fixes an endpoint, the scorecard reflects that on the next cycle.
  3. No subjective quality assessment. Grades derive from objective drift findings only.
  4. Methodology is reproducible. Anyone with the IG, the entity URL, and tessara probe can verify the finding count.

Public data only

All data on this scorecard is derived from probing publicly accessible API endpoints required by CMS-9115-F (42 CFR 422.119(b), 42 CFR 431.60(b)) and CMS-0057-F (89 FR 8758). Tessara does not access authenticated payer data or member PHI. Tessara retains structural metadata only — no payload data is stored (a patent constraint of the architecture).

Source code + spec

The probe orchestrator is in cmd/scorecard/ in the open-source Tessara repository. The full v1 spec lives at docs/playbook/scorecard/SPEC.md .