Da Vinci PAS Explained for Ambulatory Practices

Executive Summary

For ambulatory specialty practices, understanding what Da Vinci PAS does, and what it leaves for the practice to solve, changes how to evaluate vendor readiness and where to invest in internal workflow capability before January 2027. Da Vinci PAS, or Prior Authorization Support, is the HL7 FHIR implementation guide that defines how prior authorization requests and responses are exchanged electronically between provider EHR systems and payer authorization systems. Developed through the Da Vinci Project, a collaboration sponsored by HL7 International, it works in sequence with two companion guides: Coverage Requirements Discovery (CRD), which determines whether authorization is required, and Documentation Templates and Rules (DTR), which retrieves payer-specific documentation requirements. Together, the three guides create an end-to-end electronic prior authorization workflow embedded in the clinical ordering process. The practices that benefit most from this framework will be those that arrive at the 2027 compliance environment with their upstream coverage intelligence layer already in place.

What This Means for Your Practice

The operational shift Da Vinci PAS enables is significant, but it does not arrive automatically with a compliance deadline. Understanding the framework leads directly to three actionable priorities for any ambulatory specialty practice managing prior authorization volume today.

Ask your EHR vendor for a specific readiness roadmap, not a general FHIR commitment. Which payers have they completed CRD, DTR, and PAS connectivity with? What is the timeline for the payers that represent the majority of your authorization volume? A vendor whose FHIR roadmap covers large national payers but not the regional Medicare Advantage plans that drive most of your authorizations has not solved your problem. Ask for a payer-specific connectivity list, and ask when it will be updated.

Audit where your authorization workflow actually breaks. Da Vinci PAS automates the submission channel. It does not determine what gets submitted. If your current process depends on staff judgment to identify which procedures require authorization, which payer rules apply, and what documentation a specific payer expects, the faster submission channel accelerates a workflow that still begins with a manual decision. Identify that decision point in your current process before evaluating vendor solutions.

Build the coverage intelligence layer upstream of the submission workflow. Real-time PA requirement determination per CPT code and payer, accurate documentation assembly, and denial management with autonomous appeals are the functions that determine whether an electronic submission produces an approval or a denial. These are practice-side responsibilities. Da Vinci PAS is a channel. Coverage intelligence is what the channel carries.

These three priorities hold regardless of where your EHR vendor is in their Da Vinci implementation roadmap. They also become the basis for the vendor conversations that will determine how well your practice positions for the January 2027 compliance environment. The rest of this piece explains the technical framework that makes those priorities concrete.

What the Da Vinci Project Is and Why It Exists

Conor wrote recently about what CMS-0057-F means for specialty practices at the operational level. One thread worth pulling further is the technical framework sitting underneath that regulation, because understanding what Da Vinci PAS actually does changes how you evaluate your vendors' readiness and what you need to have in place before their build matters.

The Da Vinci Project is an initiative sponsored by HL7 International that brings together U.S. payers, providers, and health IT technology vendors to develop FHIR-based implementation guides for high-priority healthcare data exchange use cases. It is not a software product or a government program. It is a structured standards development effort that produces the implementation guides CMS references in regulatory mandates like CMS-0057-F.

The project's prior authorization work falls under the Da Vinci Burden Reduction Initiative, which targets the administrative friction that consumes an estimated $23,000 per physician per year in prior authorization costs alone. The three implementation guides that address prior authorization, CRD, DTR, and PAS, are collectively designed to move authorization from a manual, staff-dependent process to one embedded directly in the EHR's clinical workflow.

Prior authorization currently lives outside clinical workflow. A physician orders a procedure. Separately, someone on the administrative team identifies that the procedure requires authorization, initiates a parallel process to determine what the payer requires, assembles documentation, and submits through a portal or fax. Da Vinci's framework is designed to collapse that separation, making authorization a real-time, workflow-integrated step rather than a disconnected administrative task. The structural gap that created this separation in the first place is examined in The Missing Layer in Your Revenue Cycle Technology Stack.

The Three Implementation Guides: CRD, DTR, and PAS

The Da Vinci prior authorization framework is a sequence of three implementation guides, each addressing a distinct phase of the authorization process. Understanding them individually is necessary to understand what the framework does as a whole.

Coverage Requirements Discovery (CRD) is the entry point. When a clinician places an order in the EHR, a procedure, a referral, a medication, the CRD service queries the payer in real time to determine whether prior authorization is required for that specific service under that patient's specific plan. The query happens within the ordering workflow, before the order is finalized. The CRD response tells the clinician and the administrative team: authorization required, authorization not required, or additional information needed. This is the determination step that currently happens manually, often hours or days after the order is placed, if it is caught at all.

Documentation Templates and Rules (DTR) follows CRD when authorization is required. It retrieves the payer's specific documentation requirements for the ordered service : which clinical criteria apply, which fields must be completed, which supporting documents must accompany the request. DTR surfaces those requirements within the EHR, allowing documentation to be assembled from existing clinical data where possible, and prompting the clinician for any additional information that is needed. This is the documentation assembly step that currently requires staff to navigate payer portals, interpret requirement documents, and manually compile supporting materials.

Prior Authorization Support (PAS) is the submission and response layer. Once the authorization request is assembled through CRD and DTR, PAS handles the electronic submission to the payer and returns the payer's determination, approved, denied, or pended for additional review, back into the EHR. The goal, where payer systems support it, is a real-time response that flows directly into the clinical workflow.

Three guides, three phases, one continuous workflow. The sequence matters because each guide's output is the next guide's input. CRD without DTR and PAS is awareness without action. DTR without PAS is preparation without submission. PAS without CRD and DTR is a faster channel carrying incomplete information.

How the Workflow Sequence Actually Works

In practice, the CRD, DTR, PAS sequence functions as follows.

A physician orders a colonoscopy for a patient with Medicare Advantage coverage. As the order is entered into the EHR, the CRD service queries the patient's Medicare Advantage plan and returns a response in real time, within the ordering workflow: prior authorization required for this procedure under this plan. The clinician and the billing team see this determination before the patient leaves the scheduling call.

DTR then retrieves the specific documentation requirements for this payer and this procedure. It surfaces a questionnaire within the EHR, drawing answers from existing clinical documentation where available, diagnosis codes, prior procedure history, relevant clinical notes, and prompting for any additional fields that cannot be auto-populated. The completed documentation package is assembled without a staff member logging into a payer portal to locate requirements manually.

PAS submits the completed request electronically to the payer and returns the determination. Where the payer's system supports real-time processing, the authorization decision arrives within the ordering encounter. Where the payer pends the request for additional clinical review, PAS tracks the outstanding request and surfaces status updates within the EHR as they become available.

What currently requires a separate administrative workflow, an average of 22 minutes of staff time per authorization, and a wait period that may extend across multiple business days becomes a continuous, workflow-integrated sequence initiated at the point of ordering and resolved without a parallel administrative process running alongside it.

The Intermediary Model: FHIR, X12, and the Black Box

One aspect of Da Vinci PAS worth understanding clearly is how it handles the gap between FHIR-based submission and the X12 278 transaction format that payers have historically used for prior authorization.

HIPAA requires prior authorization transactions between providers and payers to use the X12 278 standard. Da Vinci PAS is built on FHIR R4. When a practice submits a prior authorization request through PAS, the EHR sends a FHIR-formatted bundle to an intermediary endpoint, a clearinghouse, a health IT vendor, or the payer's own system. The intermediary converts the FHIR request into an X12 278 transaction and routes it to the payer. The payer's response travels the reverse path: X12 to intermediary, converted to FHIR, returned to the EHR. From the practice's perspective, the X12 conversion happens in what the Da Vinci specification itself describes as a "black box," meaning the submitting system requires no visibility into the translation layer.

Under enforcement discretion issued alongside CMS-0057-F, covered payers operating FHIR-based Prior Authorization APIs may exchange FHIR bundles directly with providers without X12 conversion. As more payers build compliant Prior Authorization APIs by the January 2027 deadline, the intermediary translation step will become less necessary for covered payer relationships. For the foreseeable future, the intermediary model remains the practical path for most prior authorization submissions.

The Da Vinci PAS Value Equation

The framework's efficiency gain is real, but it depends on the quality of what flows through the automated channel.

The Da Vinci PAS Value Equation:

Authorization Efficiency = (Submission Automation × Documentation Accuracy) / Workflow Touchpoints

Workflow Touchpoints = Staff determinations + Manual documentation assembly + Portal submissions + Phone follow-up cycles

Da Vinci PAS, when fully implemented, reduces three of the four variables in the denominator: manual documentation assembly, portal submissions, and phone follow-up cycles. Industry implementation data from payers active in the Da Vinci framework suggests that real-time prior authorization responses are achievable for up to 80% of authorization requests through FHIR-based workflows — a meaningful compression of the phone follow-up cycle that currently accounts for a significant share of the 14 staff hours consumed per physician per week.

The first variable, staff determinations, is what the framework does not address. When a practice's internal process still depends on a staff member deciding which procedures require authorization, which payer rules apply, and what documentation is likely to satisfy the payer's medical necessity criteria, the automation of the submission channel accelerates a workflow that still begins with a manual judgment call. The denominator shrinks. It does not approach zero.

Documentation accuracy, the numerator's second variable, is equally important. A faster submission channel carrying incomplete or misaligned documentation still produces a denial. The intelligence that ensures documentation is complete and correctly targeted to the payer's specific criteria is a prerequisite for PAS to deliver its intended efficiency.

A practice needs both: the FHIR-based channel that Da Vinci PAS provides and the coverage intelligence layer that ensures the channel carries content that produces approvals rather than denials.

What Real-Time Authorization Means in Practice

The most consequential operational shift Da Vinci PAS enables is the movement of prior authorization from a reactive administrative task to a proactive clinical workflow step.

Under the current model, authorization is managed after the clinical decision. A procedure is ordered, a patient is scheduled, and the authorization process begins in parallel, and often in competition, with the clinical workflow. Delays in that parallel process create delays in scheduling, procedure timelines, and patient care. The authorization bottleneck surfaces as a scheduling problem because that is where it becomes visible, even though it originates upstream at the coverage intelligence layer.

Under Da Vinci PAS, authorization begins at the point of ordering. The CRD response tells the practice whether authorization is required before the patient is scheduled. The DTR documentation is assembled from clinical data that already exists in the EHR. The PAS submission goes out the same day the order is placed. For payers whose systems support real-time responses, the determination arrives before the scheduling conversation is complete.

That compression has measurable implications for specialty practices with high procedural volume. Reduced time between clinical decision and authorization approval shortens the gap between scheduling and procedure delivery. Fewer authorization-related scheduling delays mean better utilization of clinical capacity. Faster determinations on denied requests mean earlier appeal initiation, and earlier appeals have meaningfully higher overturn rates. The operational case for closing this gap is detailed in How Specialty Practices Eliminate Prior Authorization Delays.

What Da Vinci PAS Does Not Solve

The framework automates the exchange of prior authorization information between provider and payer systems. It does not determine what that information should be.

Da Vinci PAS does not interpret payer coverage policies or identify which CPT codes trigger authorization requirements under which plans. It does not assemble documentation that does not already exist in structured form within the EHR. It does not manage the appeal process when a determination comes back as a denial.

Those functions — coverage requirement determination, documentation intelligence, and denial management — are the coverage intelligence layer that sits upstream of the submission workflow. Da Vinci PAS is the channel. Coverage Intelligence is what ensures the channel carries the right content.

A practice that implements Da Vinci PAS without the upstream intelligence layer will find that the CRD step surfaces authorization requirements accurately, but the DTR documentation step still requires manual staff intervention to complete, because the clinical data needed to answer the payer's questions is not structured or accessible in the way DTR expects. The submission will be electronic. The preparation will still be manual. The denial rate will reflect the quality of preparation, not the speed of submission.

This distinction defines where vendor investment is necessary versus where internal workflow investment is necessary. EHR vendors build PAS connectivity. Practices build coverage intelligence. Treating a compliant EHR as the solution to the prior authorization problem conflates the transmission layer with the intelligence layer. The upstream causes of authorization failure are examined in The Coverage Lifecycle: Where Healthcare Revenue Actually Breaks.

The Vendor Readiness Question — and Where Manta Fits

With the January 2027 deadline established by CMS-0057-F for payer API implementation, the practical question for ambulatory practices is whether their specific EHR vendor and their specific payers have completed the connectivity that makes Da Vinci PAS available for their patient population.

Several questions are worth putting directly to EHR vendors now.

• Which payers have you completed CRD connectivity with, and what is your timeline for the payers that account for the majority of our authorization volume? CRD coverage is uneven. A vendor may have FHIR connectivity with a handful of large national payers and limited connectivity with regional Medicare Advantage plans that represent a substantial share of a specialty practice's authorization requests.
• At what point in the clinical workflow does the CRD response surface? A CRD integration that returns authorization requirements after the order is finalized provides less operational value than one that returns them at the point of ordering, because the window for workflow-integrated documentation assembly has already closed.
• How does your system handle pended requests and denial responses from PAS? The value of real-time submission is diminished if pended requests and denial determinations do not flow back into the EHR with the same visibility as approvals. Ask for a demonstration of the full response cycle, not just the submission step.

The ONC's Inferno Da Vinci PAS Test Kit provides an open-source framework for testing FHIR prior authorization implementations — a useful reference point when evaluating whether a vendor's stated PAS compliance has been independently verified.

Manta's Coverage Intelligence platform is designed to bridge the gap that vendor PAS connectivity alone does not close. Determining PA requirements per CPT code and payer, assembling accurate documentation before submission, and managing denials with autonomous appeals are the functions that determine whether the electronic channel produces approvals. Manta operates upstream of the submission workflow, ensuring that when the Da Vinci PAS channel is available, what travels through it is complete, accurate, and payer-specific. For specialty practices evaluating their readiness for the 2027 environment, that upstream layer is where the conversation starts.

How Coverage Intelligence Completes the Picture

Da Vinci PAS defines how authorization information moves between systems. Coverage Intelligence determines what that information should be and ensures it is accurate, complete, and correctly targeted before it moves.

The two are sequential, not alternative approaches. The FHIR-based channel that Da Vinci PAS provides and the coverage intelligence layer that ensures the channel carries content that produces approvals are both necessary. For the vocabulary and operational framework that defines that layer, see Manta's Coverage Intelligence glossary.

The practices that benefit most from Da Vinci PAS implementation are those that arrive at the 2027 compliance environment with the upstream intelligence layer already in place. For them, the electronic submission channel is an accelerant — it compresses a workflow that is already producing accurate, complete prior authorization requests. For practices that arrive without it, the channel is faster but the output is unchanged: incomplete submissions, preventable denials, and the manual follow-up cycle that the framework was designed to eliminate.

‍