Evidence you can execute.
Recent engineering work on CMS-0057-F, Payer-to-Payer, Da Vinci prior authorization and Provider Access security, published as technical evidence rather than as claims. Every status on this hub is generated from a test run at a named source revision, and every page ends with what has not been proven.
CMS-0057-F is the federal rule that requires Medicare Advantage, Medicaid, CHIP, and some exchange plans to offer FHIR APIs for patient access, provider access, payer-to-payer exchange, and prior authorization by January 1, 2027.
Every claim on this site should end at something you can run
Cloud Health Office publishes two kinds of executable evidence, and keeps them apart on purpose. One shows that the platform does what its own CMS-0057-F acceptance specification requires. The other shows that it can exchange standards-conformant requests and responses with Da Vinci software written by someone else. Both run on synthetic data, both name the source revision they were produced from, and neither is CMS certification.
PASSABLE / PARTIAL / GAP
on one side, Passed / Failed / Skipped on the other — so the two
results cannot be added together by accident. There is no single combined compliance score.
Internal acceptance evidence
Answers does Cloud Health Office implement the behaviour its acceptance specification requires? Twenty-one repository-defined scenarios run against the real services, and each is scored on two independent axes: Cloud Health Office as the backend, and integration with an external core.
External interoperability evidence
Answers can Cloud Health Office interoperate with an implementation it does not own? A separate harness starts a pinned HL7 Da Vinci reference implementation in a container and performs real FHIR and CDS Hooks exchanges against it. Nothing is mocked or replayed.
Evidence by workflow
Each page below explains one workflow the way an engineer who implemented it would: what the protocol exchange actually is, which decisions the implementation had to make, what is proven by an executable test, and what remains unproven.
CMS-0057-F implementation evidence
The scenario inventory, what Passable / Partial / Gap mean, and the live snapshot generated from the suite at a named commit.
Read the evidence → ArchitectureReplace vs Augment
Can a payer meet CMS-0057-F without replacing its core? What changes when Cloud Health Office sits in front of QNXT, Facets or HealthEdge — and how the evidence is scored differently in each mode.
Compare the patterns → Payer-to-PayerPayer-to-Payer implementation evidence
Coverage transition, consent, $member-match, export, validation, provenance, durable ingestion — and what happens to the clinical data afterwards.
CRD, DTR and PAS workflow evidence
How the three chain into one workflow, what $inquire is allowed to do, and what actually has to happen after a payer answers A4.
Da Vinci interoperability evidence
Real PAS, CRD and DTR exchanges against a pinned HL7 Da Vinci burden-reduction payer reference implementation — software Cloud Health Office did not write.
See what was exchanged → SecurityProvider Access security evidence
The four independent controls, the production external-issuer trust model, and why every refusal looks the same from outside.
Read the controls → Clinical dataUSCDI clinical exchange evidence
Twelve FHIR R4 clinical resource types, ingested from a prior payer and served through Patient and Provider Access — without overwriting anything Cloud Health Office owns.
Read the ingestion path → ThroughputMillion Claim Challenge
One million deterministic synthetic claims adjudicated on local Kubernetes, published with artifacts and with its limits stated.
Inspect the archive →The latest published CMS-0057-F acceptance evidence
Generated by CI from the acceptance suite, then committed to this repository against the exact revision it was produced from. Capability status is deliberately kept separate from raw test execution: a passing test that confirms a known gap is still reported as a Gap.
Loading the latest published CMS-0057-F acceptance evidence. It is generated in CI from the acceptance suite at a named source revision and committed to this repository, so the status shown here is the tested status rather than a claim typed into a page.
The Million Claim Challenge
Adjudication was validated at one million deterministic synthetic claims, and the honest limits are published alongside the numbers.
Adjudicated
at 1M
Messages
Delta
Million Claim Challenge: 1,000,000 deterministic synthetic claims on local Docker Desktop Kubernetes at 155.89 claims/sec, zero dead letters, with published artifacts. Every one of the 1,000,000 claims was verified terminal, with zero dead letters or pod restarts.
This is local engineering evidence, not a production-cloud capacity claim.
What this evidence is not
The point of publishing evidence is that a reader can tell where it stops. These limits apply to everything in this hub, and each page repeats the ones specific to it.
Limitations that apply across the hub
- This is implementation evidence, not CMS certification. No scenario status, and no interoperability result, constitutes certification by CMS, ONC, HL7 or anyone else.
- All test data is synthetic. No exchange described here has moved production member data.
- Passing every acceptance scenario is not complete CMS-0057-F compliance. The suite proves the scenarios this repository defines, at the revision it was run against.
- External interoperability is not production validation. It shows that a pinned reference implementation accepted Cloud Health Office's requests and that Cloud Health Office accepted its responses.
- No customer identity provider has been onboarded. The platform implements production external-issuer trust; that is a capability, not a statement that a particular payer's IdP is connected.
- QNXT, Facets and HealthEdge adapters are documented stubs in this repository. Integration with a specific core administration platform is engagement work, and it is scored on its own axis so it can never be read as product capability.
- Protocol interoperability is not payer rule parity. Two payers running different rule content can interoperate perfectly and still reach different coverage decisions.
Email the evidence summary to your architect.
The numbers and their limits are on this page. We can also send the full evidence packet.
On its way.
We reply within one business day. In the meantime, open the evidence archive →