What Payer-to-Payer actually requires.

"Supports Payer-to-Payer" is not a description of anything

A member changes plans. The new payer needs the history the prior payer holds. Between those two sentences sits a workflow with a member-matching problem, a consent problem, an SSRF problem, a validation problem, an idempotency problem and a durability problem — each of which has to be decided one way or another before any data moves. Here is how Cloud Health Office decided them.

1. Coverage transition, inside one tenant

   The member and their prior-payer coverage come from Cloud Health Office's own data. A member belonging to another tenant is never initiated on. Where coverages with the target payer overlap, the exchange refuses rather than guesses which one it is about.

2. Endpoint resolution — from configuration, never from the caller

   A caller names a payer id. A resolver maps that id to endpoints held in trusted configuration. No request type in this surface accepts a URL, non-HTTPS entries are rejected, and the HTTP client does not follow redirects. That is the SSRF boundary, and it is a boundary because there is no code path through which a caller-supplied address can become a request target.

3. Consent, evaluated server-side before anything leaves

   Cloud Health Office asks its own consent registry whether the member authorized the Payer-to-Payer purpose specifically. This runs before any remote call, so an unauthorized member's identity is never disclosed to the other payer in the first place. A denial is terminal NotAuthorized, deliberately distinct from Failed: a member who has not authorized an exchange is not an error to retry.

4. Remote Patient/$member-match

   Cloud Health Office builds the request and interprets the answer; it does not re-run the peer's matching rules. No match and an ambiguous match are both terminal. Resolving an ambiguity by picking one would mean importing a stranger's record into a member's history.

5. Consent again, immediately before the export

   Consent is evaluated at the attempt, not carried forward from step three. A revocation that lands while the match is in flight stops the data request. A retry clears the recorded decision and asks again rather than reusing the answer it liked.

6. Member data export

   Issued only once exactly one member has resolved and consent has been re-confirmed as of that moment.

7. Validation of what came back

   The Bundle must parse, must carry exactly one Patient, and that Patient — along with every Patient/… reference in the package, relative or absolute — must be the member who matched. A package that disagrees with itself about who it is describing is refused.

8. Provenance, and an archive of what was actually sent

   The package is stamped with a Provenance naming the source payer, the exchange and the receipt time, and is archived as received — before Cloud Health Office rewrites any reference — so the archive answers "what did the payer actually send?" rather than "what did we make of it?".

9. Durable ingestion, and only then Completed

   The exchange reaches Completed only once the import commits. DataReceived exists as its own state precisely so that "retrieved but not stored" is a condition the system can be in and report. Retrieval alone never reads as success.

The state machine is explicit: Pending → Matching → Matched → RequestingData → DataReceived → Ingesting → Completed, with terminal NoMatch, Ambiguous, NotAuthorized and Failed.

What happens to the clinical resources after they arrive

Receiving a prior payer's Condition, Observation and Procedure is only half of a Payer-to-Payer implementation. Until there is somewhere to put them and a read path to serve them, they are validated, counted and archived — and honestly classified as unsupported.

Twelve FHIR R4 clinical types now have durable member-scoped storage and a standards-correct read path through both Patient Access and Provider Access: AllergyIntolerance, CarePlan, CareTeam, Condition, Device, DiagnosticReport, Goal, Immunization, MedicationDispense, MedicationRequest, Observation and Procedure.

One table, five consumers

The resource inventory is a single source of truth read by the SMART scope layer, the Provider Access authorization filter, the Payer-to-Payer import classification, the CapabilityStatement and the controller's route constraint — with structural tests pinning each of them to it.

That is not tidiness. A clinical type reachable through SMART but missing from the governed set would be readable by any provider holding a scope, attributed or not, consented or not. Taking both from one table removes the possibility rather than relying on a reviewer to notice. The same table decides what is ingested, so a type is ingested exactly when it is served.

The import store was promoted, not copied

The clinical serving store is the Payer-to-Payer import store, resolved through a second interface. There is no projection to fall behind the source, no dual write to reconcile, and no second place a resource could be stale in — and "which store did this come from?" still answers "the imported one". Clinical data therefore stays out of the authoritative member, enrollment, coverage and claim stores by construction.

Native and imported coexist rather than merge

Every served clinical resource today is imported from a payer; no Cloud Health Office component authors native clinical data. The origin axis exists so that when a native writer appears it coexists with imported data instead of overwriting it: two sources for the same clinical fact would be two resources rather than one silently merged one. Until then it is an unexercised seam, and it is described here as one.