Payer interoperability: exchange, prior authorisation and the rules that now bind both sides

Nationwide exchange under the Trusted Exchange Framework and Common Agreement, document query and retrieve, the interoperability and prior authorisation rule, payer feeds in both directions, and US Core content. Written for people who have to build against it, with the technical layer separated from the legal prerequisites the platform doesn’t hold.

1 Two problems that look like one

A payer-facing operations team has two jobs that people keep treating as one “interoperability” line item. One is getting a record from an organisation you have no relationship with, anywhere in the country. The other is moving authorisations, quality and claims with a payer you’re contracted to. Different rails, different rulebooks, and the second now has statutory deadlines.

This explainer covers both, and says which parts are wired. The wider US module pack is in Supporting the US health system.

2 Nationwide exchange, and what a QHIN is

The Trusted Exchange Framework and Common Agreement answers a problem the United States had for twenty years: hundreds of regional exchanges, each with its own contract, so reaching all of them meant signing all of them. TEFCA replaces that with one agreement, so a single connection reaches the network.

A Qualified Health Information Network is a designated network operator that has signed the Common Agreement with the Recognised Coordinating Entity. Think of it as a trunk road. Provider organisations rarely become one; they connect under one as a Participant, or under a Participant as a Subparticipant, with the terms flowing down the chain. The practical question is never “should we be a QHIN”. It’s “which QHIN sponsors us, and can our software answer what it sends”.

What the network sends is constrained by an Exchange Purpose. The Common Agreement defines six: treatment, payment, health care operations, public health, government benefits determination, and individual access services. Every request names one and the platform enforces them. An unknown purpose is refused, and so is one the deployment has switched off. Individual access services carries an identity floor, because the requester is the patient, so a request that doesn’t assert IAL2 assurance is refused. Each refusal writes an audit event.

3 Find the patient, then fetch the document

Nationwide exchange is two steps. Establish that the patient you’re asking about is the patient the other side holds, then ask what documents exist and fetch one. The platform implements the responder side of both.

A form on the exchange page runs the real responder against this deployment’s record store. Type a family name, a given name and a date of birth and it returns what a QHIN would get back, including nothing when the evidence is thin.

4 What software can hold, and what only a signature can

Participation in nationwide exchange isn’t a software capability. It’s a set of legal and commercial artefacts an organisation holds. commvita holds none of them, and the product says so on its own page.

The register can never report a legal row as met, because no code path sets one. A buyer reading “seven of ten technical requirements met, zero legal prerequisites held” knows what they’re buying and what their counsel and sponsoring QHIN still have to do.

Two behaviours follow. Without an approved certificate the UDAP metadata is served unsigned, with the reason in the response, and a QHIN will reject it. The initiator endpoint transmits only when a certificate and a QHIN endpoint both exist; otherwise it composes the request, audits it, and returns demo mode with the reason. It never reports a transmission that didn’t happen.

5 The interoperability and prior authorisation rule

CMS-0057-F turned prior authorisation from a business practice into a regulated one. It binds impacted payers, and it changes what a provider organisation should expect and be able to evidence.

The documentation templates and rules exchange is the part clinicians feel. The payer sends a questionnaire for the requested service. The platform answers it from the problem list, medications, lab results, vitals, assessments, diagnostics and provider directory, labelling each answer with its source. Fields it can’t answer are flagged missing or needing review, so the clinician works the four questions the record couldn’t settle instead of the thirty it could.

The ceiling, plainly: the prior authorisation page is a demonstrated control surface with a seeded-data banner. Behind it sits a real request store. Requests can be created, listed, filtered by status, payer or service type, fetched and withdrawn, and the summary computes average turnaround in hours from stored submission and decision times. What the platform doesn’t do is transmit. No payer connection, no X12 278, no FHIR prior authorisation client.

6 Feeds in both directions

Payer traffic isn’t one pipe. Claims and remittance come in. Quality submissions and risk notifications go out. Admission events sit in the middle, and they have the shortest useful half-life.

Claims ingestion is API-backed. Claims carry type, billed, allowed and paid amounts, status and denial reason, filterable by payer, status and type, with a summary giving total claims, billed, paid and the denial rate. A denial reason of “prior authorisation not obtained” sitting beside the prior authorisation queue is a join worth having in one place.

Going the other way, quality submissions are held as numerator, denominator and computed rate per measure with a status that moves to submitted, and readmission risk scores per patient carry a tier and a payer-notified flag. Both record a decision here. Neither sends anything, and I would rather say so than let a green tick imply otherwise.

The payer dashboard sits on top: attributed members, total cost of care per member per year against benchmark, thirty-day readmission rate, emergency utilisation per thousand, care gap rate, average risk score and coding completeness, with an alert list a named administrator acknowledges. Alerts carry a value and the threshold they crossed, so an alert is checkable. Two honest notes. The summary tiles come from an endpoint returning fixed figures, so treat those numbers as illustrative. The timeline is served over a fixed demonstration list instead of a live message feed; the receiver for real admission messages lives in the platform’s message engine and admission-feed modules, and joining the two is deployment work.

7 US Core, bulk export and the audit trail

The United States Core Data for Interoperability is the minimum data set an American exchange partner expects, and US Core is the set of FHIR profiles that carries it. Getting it wrong is the commonest reason a working integration fails conformance.

The precise position: the exchange endpoints above produce US Core content, so Patient/$match returns a US Core Patient and retrieved documents are FHIR R4 bundles in that form. The platform’s general FHIR R4 read interface is a different surface. It publishes a capability statement, serves six resources plus a patient everything operation, and declares UK Core profiles, because that’s the jurisdiction it was written for. Plan a US deployment as two surfaces with two profile sets, and size the mapping accordingly.

Bulk export needs bluntness. The bulk data page shows export jobs, history, subscriptions, scope and token security and analytics, and all of it’s seeded. There’s no bulk export operation in the platform. Population-scale extraction today is a per-resource read or a database-side extract, and a payer-scale export is build work.

Where it lives in commvita