CMS is forcing the workflow into the open, but transparency deadlines do not create decision provenance by themselves
CMS's January 17, 2024 final rule made the timing concrete, and the operational dates are now close enough to change engineering behavior. Impacted payers generally had to begin meeting certain process requirements on January 1, 2026, while the API development and enhancement requirements generally begin on January 1, 2027. The fact sheet also makes the control surface more explicit: expedited prior-authorization decisions must return within 72 hours, standard decisions within seven calendar days, denied requests need a specific reason beginning in 2026, and prior-authorization metrics must be posted publicly. Those are important transparency moves, but they do not prove which documentation bundle, policy version, or reviewer produced the decision. If an enterprise can expose the clock and the denial reason but still cannot reconstruct the evidence set behind that outcome, it has improved transport and reporting without actually creating decision provenance.
CRD and PAS make discovery and submission more machine-readable, which raises the bar for record lineage rather than lowering it
The HL7 Da Vinci guides show why the missing layer matters. Coverage Requirements Discovery (CRD) is designed to surface payer coverage requirements inside provider software at the point of care, where treatment and ordering decisions happen. Prior Authorization Support (PAS) is designed to support direct submission of prior-authorization requests from EHR systems using a standardized path. That is a real interoperability gain. It also means the workflow is now machine-readable earlier and end-to-end. Once discovery and submission are structured, every recommendation, documentation request, approval, denial, and resubmission needs to be tied to the exact patient context, policy state, and supporting clinical record that generated it. Otherwise the organization has made the exchange faster while leaving the most consequential question informal: what exactly was the system looking at when it moved the case forward?
Publish one prior-authorization decision-provenance map before broader AI rollout
The practical artifact is one decision-provenance map per prior-authorization workflow. Name the triggering service line and payer path. Name the source of the discovered requirements, the documentation package assembled, the versioned patient and policy records consulted, the reviewer role allowed to approve or deny, the denial-reason taxonomy, the turnaround clock, the resubmission path, and the retained evidence package. In other words: do not stop at a FHIR integration diagram. Publish the operating contract that proves how a case moved. That is where healthcare AI becomes production-grade. It is also where a healthcare software team can tell the difference between a workflow that is merely interoperable and one that is defensible under review, appeal, audit, and operational pressure.
Key takeaways
- FHIR prior-authorization transport is necessary, but it does not replace decision provenance.
- Specific denial reasons, turnaround clocks, and public metrics increase the need for versioned evidence and named reviewer authority.
- One decision-provenance map per prior-authorization workflow is a better readiness test than another generic AI-in-healthcare roadmap.
Related surfaces
- Healthcare practice — Inspect the LockedIn Labs healthcare software delivery posture across prior authorization, claims, identity, FHIR exchange, and governed AI.
- Trust center — Review the public control posture behind approval gates, evidence capture, and runtime governance.
- ControlFrame — See the adjacent audit-evidence surface when the healthcare workflow also needs continuously current proof.
- Contact LockedIn Labs — Discuss one prior-authorization workflow where FHIR transport exists but reviewer authority and denial evidence are still informal.