- A standards-based prior authorisation front door without replacing core claims systems
- Every request traceable from submission to decision with a recorded reason
- Clear routing between automated checks and clinical reviewers
- Metrics reporting built on the same event stream as operations
Anonymised composite. Client names, identifying details and confidential figures are withheld; public facts are cited in the references.
The situation
A regional health payer handled prior authorisation the way much of the industry still does: faxes, phone calls and a provider portal, feeding a utilisation management system that sat beside the core claims platform. Providers waited, reviewers re-keyed information, and nobody could easily answer how long decisions took or why requests were pended.
The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) changed the timetable. It requires impacted payers to implement a prior authorisation API, with API compliance dates from January 2027, and to publicly report prior authorisation metrics1. Replacing the claims and utilisation management systems in that window was not realistic, so the question became how to put a standards-based front door on them.
What had to be true
- Standards, not a bespoke API, so provider EHR vendors could integrate once.
- No rip-and-replace: the existing systems remain the systems of record.
- Every decision traceable, with a reason a provider could act on.
- Humans for clinical judgement: automation handles completeness and clear-cut rules; reviewers handle the rest.
- Metrics by construction, not by quarterly spreadsheet.
Architecture
The design followed the three HL7 Da Vinci guides that work together for prior authorisation: Coverage Requirements Discovery, Documentation Templates and Rules, and Prior Authorization Support.
CRD uses CDS Hooks so the payer can return coverage requirements inside the provider's ordering workflow2. DTR lets payer documentation rules run in the provider context so the required information is gathered up front3. PAS carries the request as a bundle built around a Claim resource, aligned to the X12 278 transaction, and is designed to be used together with CRD and DTR4.
The data flow, end to end
- DiscoverOrder signed in the EHR triggers a CRD call; response says whether authorisation and documentation are needed
- DocumentDTR gathers required information, pre-filled from the record where possible
- SubmitPAS bundle received, validated and mapped to an internal work item
- CheckRules engine checks eligibility, completeness and clear-cut policy criteria
- ReviewAnything needing clinical judgement goes to a reviewer queue with the evidence attached
- RespondDecision and reason returned via PAS; every state change published as an event
Status inquiries used the same decision record, so a provider checking on a pended request saw exactly what a reviewer saw, and the answer never depended on which internal system happened to hold the case.
A deeper walkthrough of the rule and the APIs is in CMS-0057 prior authorisation APIs.
The hard part: translating policy into rules people trust
The FHIR plumbing was well specified. Medical policy was not. Coverage criteria lived in documents written for human reviewers, and turning them into DTR questionnaires and rules required:
- A policy backlog ranked by request volume, so the most common services were automated first.
- Clinical owners for every rule, with versioning so a decision could be traced to the policy text in force at the time.
- A firm boundary: rules could approve or route to review, but a denial on clinical grounds always went through a reviewer.
- Specific, actionable reasons in every pended or denied response, rather than generic codes.
An API that returns "pended" faster is not an improvement. The value is in returning the right question to the provider at the moment they can still answer it.
How the engagement ran
- Signs order
- Completes DTR form
- Receives decision and reason
- Returns requirements
- Validates and checks rules
- Publishes events
- Receives routed case
- Decides with evidence
- Records reason
- Rule requirements mapped
- Current workflow and systems
- Highest-volume services
- PAS endpoint and mapping
- Decision record and events
- Partner testing
- CRD responses
- DTR questionnaires
- Rules for top services
- Metrics reporting
- Policy change process
- Runbooks and hand-off
For the security model of provider-facing apps, see SMART on FHIR authorisation; for the event backbone, change data capture and event streams.
Key decisions and trade-offs
| Decision | Alternative | Why |
|---|---|---|
| Da Vinci CRD, DTR and PAS | Proprietary REST API | EHR vendors integrate once across payers |
| Façade over existing systems | Replace utilisation management | Meets the timetable without core system risk |
| Versioned, owned rules | Rules embedded in code | Policy changes are auditable and owned by clinicians |
| Clinical denials always reviewed | Full automation | Keeps clinical judgement with qualified people |
| Metrics from the event stream | Periodic reporting extracts | Published numbers match operational reality |
What I'd do again, and differently
Again: start with the decision record and event stream, because everything else (reporting, audit, provider status checks) hangs off it. Differently: bring provider-side EHR partners into testing earlier. Real Claim bundles from real ordering workflows surface mapping gaps that synthetic tests never do.
If you are planning for CMS-0057-F, the healthcare data architecture page describes how I run these engagements, or analyse your challenge and bring the result to a call.
- 1CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) fact sheetCenters for Medicare & Medicaid Services · 17 Jan 2024
- 2Da Vinci Coverage Requirements Discovery (CRD) IGHL7 International
- 3Da Vinci Documentation Templates and Rules (DTR) IGHL7 International
- 4Da Vinci Prior Authorization Support (PAS) IG: backgroundHL7 International