DowncodedFour Health Systems Stopped Retyping Orders Into Payer Portals
On August 17 four health systems and three payers went live on the real-time prior authorization check that Medicare Advantage, Medicaid and marketplace plans all have to support by January 1. The specification behind it is free to read, it names the exact answers a payer can give at order entry, and one of those answers lets an authorization number ride straight to your 837.
Your EHR vendor reads a specification you probably do not, and one sentence in it quietly outlaws the way most practices check prior authorization.
"CRD clients SHALL NOT require transcription of order, appointment, or other data into a separate interface distinct from regular provider workflow."
That is conformance language. A system that makes your staff retype an order into a payer portal does not conform.
On August 17, seven organizations started behaving as though somebody would check.
Who Turned It On
Ochsner Health, Froedtert ThedaCare Health, Denver Health, and Summit Health went live with real-time prior authorization requirement checks inside Epic, against UnitedHealthcare, Network Health, and Aetna. Epic says sixteen more payers are in testing.
What got replaced is worth naming, because every revenue-cycle department in the country maintains its own version. In Epic's own description, health systems "had to rely on their own lists of insurer requirements, lists that are time-consuming to maintain and can cause delays when they become out of date."
You know that list. Somebody owns it, it lives in a shared drive or a payer-matrix tab, and it is wrong somewhere right now.
Melissa Woods, Ochsner's assistant vice president of revenue cycle and financial clearance, described the go-live as turning "a traditionally manual, time-consuming process into a streamlined experience." The federal deadline these seven beat is January 1, 2027, which was 137 days away on the day they went live and is 102 days away today.
What the Payer Is Allowed to Say Back
Here is the part worth stealing.
The standard underneath this is the Da Vinci Coverage Requirements Discovery implementation guide, version 2.2.1, published March 27 under a CC0 license at hl7.org. No login, no sales call.
It fires at six points in the workflow: appointment-book, encounter-start, encounter-discharge, order-dispatch, order-select, and order-sign. So the answer can land when the order is selected, before anyone signs anything.
And the answers are enumerated. The published code system carries 24 concepts, and eight of them are the ones your team argues about:
covered,not-covered,conditional,indeterminateon the coverage questionno-auth,auth-needed,performpa,satisfiedon the authorization question
Two of those deserve a second look.
performpa means authorization is needed, "however such prior authoriation must be initiated by the performing (rather than ordering) provider." The misspelling is in the published source.
That one code settles the oldest argument in referral management, and it settles it inside the order, at the moment the order is placed.
satisfied means authorization would normally be required and the conditions "have already been evaluated and therefore prior authorization can be bypassed."
Now, the piece that reaches your 837. The spec carries a field called satisfied-pa-id, and says that value "can be used as an X12 prior authorization number." That works because of guidance letter GL-2024-02, issued February 28, 2024 by the National Standards Group, which states that HIPAA enforcement action "will not be taken against HIPAA covered entities that choose not to use the X12 278 standard as part of an electronic FHIR prior authorization process."
An authorization number can be born at order entry and ride to the claim without a 278 ever existing.
What the Portal Was Actually Costing
The 2024 CAQH Index prices this transaction by mode, and the shape of it explains why the portal era ran as long as it did (chart below).
A medical prior authorization run by phone, mail, fax, or email costs the health plan $3.41 and the provider $12.88.
Move it to a web portal and the plan's cost falls to five cents. The provider's falls to $8.93.
At that point the plan's remaining savings opportunity is $0.00, by the Index's own accounting. The provider is holding $3.55 of unclaimed savings that only a real API pays out.
Time runs the same way: 24 minutes manual, 16 in a portal, 10 fully electronic.
Which brings the honest caveat, and it is a real one.
Even fully electronic, prior authorization is still the most expensive and the slowest transaction in the Index, $5.38 and 10 minutes of provider time against $2.00 and 4 minutes for an eligibility check (second chart). The requirement lookup is the floor of this problem.
Final Thoughts
CMS named this specification in the rule itself. In the preamble to CMS-0057-F, the agency writes that "a provider may use the HL7 FHIR Da Vinci Coverage Requirements Discovery (CRD) IG, which is the part of the Prior Authorization API that allows a provider to query whether a payer requires prior authorization before they will cover a specific item or service for a specific patient."
The obligation lands at 42 CFR 422.122(b) for Medicare Advantage, and at 431.61(b) and 457.732(b) for Medicaid and CHIP. Beginning January 1, 2027, the API has to be populated with the plan's list of covered items and services that require prior authorization, and has to identify all documentation the plan requires for approval.
All of it is public. The spec is free, the code list is free, the rule text is free, and the cost tables are free.
What is not free is the year your team spends maintaining a requirements list that a payer is about to be obligated to publish. Seven organizations decided 137 days early that they were finished doing that, and everyone else has 102 days to make the same call.
Thanks for reading.