Case study
Prior authorization, translated
We put a conformance gateway in front of an unmodified legacy payer and took it from 11 passing tests to 39 on the official Da Vinci PAS test suite, without changing a line of the payer itself.
- Standard
- Da Vinci PAS FHIR IG 2.0.1
- Regulation
- CMS-0057-F
- Verified with
- Inferno Da Vinci PAS Test Kit
- Work type
- Standfast internal research
The problem
CMS-0057-F requires payers to expose prior authorization through FHIR APIs built to the Da Vinci PAS implementation guide. The systems that actually make those authorization decisions are X12 systems, many of them decades old, and replacing them is not on the table.
So the useful question is not whether a payer can rewrite utilization management. It is whether a translation layer can put a conformant FHIR face on the system a payer already runs, and prove it against the same test suite a regulator would point at.
We built that layer against public reference implementations: HL7's Da Vinci prior authorization reference payer as the stand-in for the legacy system, and the Inferno test kit as the judge.
What the gateway does
Five jobs, each one a thing a real payer bridge has to handle.
Fails closed
Non-conformant requests are quarantined before the payer is ever contacted, and answered with both a FHIR OperationOutcome and an X12 rejection that names the failing rule.
Speaks X12
Every prior authorization exchange is rendered as an X12 278 request and response, with a 275 for supporting documentation, mapped segment by segment back to the FHIR elements they came from.
Corrects the response
The legacy payer's replies are brought up to profile conformance on the way out: review action codes, identifier systems, required elements. Every correction is listed, not silently applied.
Surfaces internal data
Member demographics, provider directory records, and documentation requests are pulled from payer systems the FHIR layer never exposed. This is what the mandate actually asks of payers: make existing data reachable.
Closes the loop
Pended decisions notify the requester, with the gateway repairing the notification the legacy system could not send correctly on its own.
One request moving through the gateway. Each stage reports its own result, so a failure is attributable to a step rather than to the system as a whole, and the layer selector at the top switches between the raw payer response, the corrected response, and the enriched response.
Results
Same payer, same test suite, same request bundles. The only variable between rows is how much of the gateway is switched on.
| Configuration | Pass | Fail | Errors |
|---|---|---|---|
| Reference payer alone | 11 | 25 | 16 |
| Gateway corrections only | 27 | 20 | 0 |
| Corrections plus simulated internal-systems data | 39 | 8 | 0 |
Inferno Da Vinci PAS Test Kit, server suite v2.0.1, run against the gateway in front of HL7's unmodified reference payer. The eight remaining failures are three findings plus five parent group rows that inherit them: two trace to a conflict inside PAS 2.0.1 itself, described below, and one is a deliberate trade in how the pended workflow is timed, since the notification tests and the inquiry tests want the same claim in opposite states.
Where the line is
The third row deserves its caveat stated plainly, because the distinction is the whole point of the architecture.
Corrections fix the format of what the payer already said. Nothing is invented. Enrichment adds data that lives in a payer's internal systems, member eligibility, provider directory, utilization management, but that its FHIR layer never exposed. In this build those systems are simulated by a configuration file. In a real deployment they are live integrations, and the data already exists inside the payer. That is precisely what the rule asks payers to make reachable.
The demo keeps the three layers visually distinct at the field level, so anyone reading a response can tell which values came from the payer, which were corrected, and which came from a simulated internal system. A board that reads as fully green without that boundary drawn next to it would be telling a story the artifact cannot support.
What we found in the standard
The remaining failures turned out not to be ours. Running strict, version-pinned validation surfaced places where PAS 2.0.1 contradicts itself: a profile requires an extension at a location that the same package's definition of that extension forbids. Any value fails validation, and omitting it fails the must-support check.
Each one is already logged with HL7 and corrected, but only in releases that come after 2.0.1, which is the version CMS-0057-F names. A payer building to the letter of the rule inherits them. Note that HL7 triaged the first as a validator behavior and the other two as guide corrections, which is a distinction worth having before an integration team spends a week deciding whose bug it is.
- FHIR-46543: validator rejects the communicatedDiagnosis extension where the profile slices it. Corrected in 2.1.0.
- FHIR-51464: context of use adjusted for Claim and ClaimResponse extensions. Corrected in 2.2.0.
- FHIR-53589: serviceLineNumber moved to the top level of CommunicationRequest. Corrected in 2.2.0.
We found these independently, from the published package and a strict validator, before locating the tickets. Knowing where a mandated version disagrees with itself is the kind of detail that decides whether an integration ships on schedule.
How we work, visible in the artifact
- Pin the version the regulation names, and hold every component to it.
- Prove conformance with the same public test suite a reviewer would run.
- Fail closed at the boundary, so bad data never reaches the system of record.
- Disclose every value the integration adds or changes, down to the field.
- Document what is simulated, what is real, and what the standard itself got wrong.
X12 renderings in this work are a non-normative educational subset of the public 005010X217 and X210 structures. X12's licensed element-level mappings are not reproduced.