Da Vinci CRD, DTR and PAS are HL7 FHIR implementation guides that automate prior authorization inside clinical workflows. Coverage Requirements Discovery tells providers when authorization is needed, Documentation Templates and Rules gathers required documentation, and Prior Authorization Support submits requests electronically. CMS recommends these guides for the Prior Authorization API due January 2027.
Prior authorization has relied on faxes, portals and phone calls for decades. The Da Vinci guides replace much of that with standards-based exchanges triggered from the EHR, and CMS rules now push payers toward electronic prior authorization by 2027. For implementation teams, the challenge is understanding how three guides fit together and what each side must build. Taction Software builds FHIR integrations across 200+ healthcare projects since 2013, and this guide explains CRD, DTR and PAS for payer and provider engineering teams.
How CRD, DTR and PAS Work Together
The three guides form a sequence that mirrors the prior authorization process. CRD runs when a clinician orders a service, checking coverage and whether authorization is required. DTR then collects documentation the payer needs, prepopulating answers from the EHR. PAS submits the authorization request and returns decisions. Each guide can be implemented separately, but value comes from connecting all three in real workflows. The six points below explain how the pieces fit, and our prior authorization automation services build end-to-end implementations for payers and providers. Plan them as one program.
CRD Starts in the Workflow
Coverage Requirements Discovery is triggered by events in the EHR, such as ordering a service or scheduling an appointment. The payer returns information about coverage, documentation and authorization requirements while the clinician is still working, rather than days later. Timing matters.
DTR Gathers Documentation
When documentation is required, Documentation Templates and Rules presents payer questionnaires and automatically fills answers using data from the patient record. Clinicians or staff review and complete remaining items, producing structured documentation the payer can process consistently. Rework drops. Quality improves.
PAS Submits Requests
Prior Authorization Support sends the authorization request, including DTR documentation, to the payer electronically using FHIR. The payer returns a decision or pending status, and providers can receive updates as requests progress without checking portals or calling payer staff. Delays shrink.
Payer and Provider Roles
Payers implement CRD services, DTR questionnaire content and PAS endpoints. Providers, usually through their EHR vendors, implement CRD clients, DTR applications or native support, and PAS submission. Both sides must test together to achieve working end-to-end exchanges. Coordination is essential.
Regulatory Drivers
CMS requires impacted payers to implement a Prior Authorization API by January 1, 2027, and recommends the Da Vinci guides. Our guide to the CMS prior authorization rule explains broader requirements and timelines for payers. Deadlines are approaching quickly. Plan accordingly.
Provider Incentives
CMS also added an electronic prior authorization measure to provider incentive programs, encouraging hospitals and clinicians to request authorizations electronically through certified systems. Provider adoption matters, because payer APIs deliver value only when provider systems actually use them. Adoption drives value.
Coverage Requirements Discovery in Depth
CRD brings payer coverage rules into the moment a clinician makes a decision. It uses CDS Hooks, a standard for invoking external decision support from EHR workflows, so payers return guidance as cards within the clinician’s screen. Well-designed CRD services reduce authorization surprises, help clinicians choose covered alternatives and indicate when DTR or PAS steps are needed. The six components below explain CRD implementation, and our CDS Hooks glossary entry explains the underlying decision support standard in more detail. Clinicians feel its impact first, so design and performance deserve particular care.
CDS Hooks Triggers
CRD responds to hooks such as order selection, order signing, appointment booking and encounter events. Each hook sends context to the payer’s CRD service, which determines coverage requirements for the specific order, patient and plan in real time. Speed matters.
Coverage Rules Engine
Payers need a rules engine expressing coverage and authorization policies in machine-readable form. Translating policies from documents into executable rules is often the largest CRD effort, requiring collaboration between clinical policy, operations and engineering teams. Policies become testable. Ownership must be clear.
Response Cards
CRD returns cards describing coverage status, authorization requirements, documentation needs and links to DTR. Cards must be concise and actionable, because clinicians ignore lengthy or irrelevant messages, which undermines the value of the entire integration. Less is more. Test with clinicians.
Coverage Information Extensions
CRD can return coverage information that EHRs store with orders, indicating whether authorization is needed and whether documentation applies. Stored coverage information supports later workflow steps and reduces repeated checks for the same order. Workflows stay connected. Duplication drops. Efficiency grows.
Data Prefetch
CRD services can request relevant patient data, such as conditions and coverage, through prefetch templates. Efficient prefetch reduces round trips and response times, which matter because clinicians expect decision support to appear almost instantly during ordering. Latency drops. Design carefully.
Performance Requirements
CRD responses must be fast enough not to slow clinical workflows. Payers should design services for low latency, with caching, scalable infrastructure and monitoring, because slow responses lead EHRs and clinicians to bypass or disable the integration entirely. Monitor continuously.
Documentation Templates and Rules in Depth
DTR eliminates much of the manual documentation work behind prior authorization. Payers publish questionnaires describing the information they need, along with logic that extracts answers from EHR data automatically. Providers see prepopulated forms, complete any missing items and attach results to authorization requests. Good DTR content saves significant staff and clinician time while improving documentation completeness. The six components below explain DTR implementation, and our smart on FHIR app development work builds the applications that often deliver DTR inside EHR workflows. Content quality determines success. Invest in content. Plan staffing.
FHIR Questionnaires
Payers express documentation requirements as FHIR Questionnaire resources, defining questions, answer types and conditional logic. Well-structured questionnaires capture exactly what payers need, avoiding the vague or redundant questions common in traditional paper and portal forms. Clarity helps reviewers. Design them carefully.
CQL Prepopulation Logic
Clinical Quality Language expressions extract answers from patient data, such as diagnoses, medications and test results, prepopulating questionnaires automatically. Accurate CQL reduces manual entry dramatically, but requires careful testing against real EHR data patterns and coding variations. Testing matters. Edge cases matter.
SMART App or Native Support
DTR can run as a SMART on FHIR application launched from the EHR or be supported natively by the EHR. Either approach must present questionnaires clearly within clinical workflows and handle responses securely and reliably. Usability decides adoption. Choose deliberately.
Questionnaire Responses
Completed documentation becomes a QuestionnaireResponse, which is attached to the authorization request submitted through PAS. Structured responses let payers process documentation automatically, speeding decisions and reducing back-and-forth requests for additional information. Reviewers receive consistent, complete information for every request. Speed improves.
Content Management
Payers must maintain questionnaires and CQL as policies change, with version control, testing and publishing processes. Content management is an ongoing operational responsibility, not a one-time build, and requires clinical policy experts working alongside technical content developers. Plan staffing. Governance helps.
Adaptive Forms
Adaptive questionnaires change based on earlier answers, asking only relevant follow-up questions. They reduce burden on clinicians and staff, but require careful design and testing to ensure logic remains correct as clinical policies and payer requirements evolve. Clinicians appreciate them.
Prior Authorization Support in Depth
PAS handles the actual submission of authorization requests and the return of decisions. It packages request details and DTR documentation into a FHIR bundle, submits it to the payer and returns a response indicating approval, denial or pending review. PAS also supports status updates, so providers learn about decisions without polling portals. The six components below explain PAS implementation, and our AI agent for clinical authorization work shows how automation can complement standards-based submission for staff handling complex cases. Reliability matters most here. Errors here delay care. Test thoroughly. Plan well.
Claim-Based Request Bundles
PAS represents authorization requests using FHIR Claim resources within bundles that include patient, coverage, provider and service details, plus supporting documentation. Correct bundle construction is essential, because payers reject incomplete or malformed requests automatically. Validation helps. Test every edge case.
Submission and Response
Providers submit bundles to the payer’s PAS endpoint, which returns a ClaimResponse indicating the decision or pending status. Immediate decisions are possible for straightforward requests, dramatically reducing turnaround compared with traditional fax and portal submissions. Patients wait less. Staff notice quickly.
Pended Requests and Updates
Requests needing clinical review return pending status. PAS supports mechanisms for providers to receive updates when decisions are made, using subscriptions or inquiry operations, so staff no longer need to call payers or check portals repeatedly. Staff time is saved.
X12 278 Considerations
HIPAA historically required the X12 278 standard for authorization transactions, and PAS was designed to work with intermediaries that convert between FHIR and X12. HHS has announced enforcement discretion relevant to FHIR-based submissions, so confirm current requirements with counsel. Plan ahead.
Denial Reasons
Payers must provide specific reasons for denials under CMS rules. PAS responses should include clear, structured denial reasons, helping providers understand decisions, correct documentation and decide whether to resubmit or appeal without lengthy phone conversations. Appeals become simpler. Transparency helps.
Status Tracking and Reporting
Both payers and providers should track request volumes, turnaround times, approval rates and pended durations. CMS requires payers to publicly report certain prior authorization metrics, so tracking data accurately supports compliance as well as operational improvement. Trends guide improvements. Reporting stays accurate.
Implementation Roadmap for Payers and Providers
Implementing CRD, DTR and PAS requires coordinated work across policy, content, engineering and partner testing. Payers carry the heaviest burden, because they must translate policies into rules and questionnaires, then expose services at scale. Providers depend largely on EHR vendor support but must configure, test and adopt workflows. Starting with high-volume services delivers value fastest. The six steps below outline an implementation roadmap, and our CMS interoperability rule compliance service supports related payer API work due by the same deadline. Momentum matters. Each step has clear owners and measurable outputs.
Step 1: Prioritize Services
Identify high-volume services that require authorization, such as imaging, specialty drugs administered in clinics and common procedures. Starting with these services concentrates effort where electronic prior authorization delivers the greatest administrative savings for payers and providers. Data guides choices. Savings arrive sooner.
Step 2: Translate Policies
Convert coverage and documentation policies for priority services into machine-readable rules and questionnaires. Clinical policy experts and content developers must work together closely, because ambiguous policies become obvious, and must be clarified, during translation into executable logic. Policies improve too.
Step 3: Build Services and Endpoints
Implement CRD services, publish DTR content and build PAS endpoints with authentication, logging and monitoring. Reuse existing FHIR infrastructure where possible, and design for performance, because CRD in particular must respond quickly during clinical workflows. Security is built in. Testing continues.
Step 4: Integrate Back-Office Systems
Connect PAS to utilization management platforms, so electronic requests flow into existing review workflows and decisions flow back automatically. Without back-office integration, electronic submissions simply create new manual queues for review staff. Reviewers keep familiar tools while electronic requests arrive automatically.
Step 5: Test With Provider Partners
Test end-to-end with EHR vendors and provider organizations, using realistic orders and documentation. Partner testing reveals interoperability issues, performance problems and usability concerns that internal testing alone cannot uncover before production launch. Early testing reduces launch risk significantly. Partners build trust.
Step 6: Expand and Measure
Expand to additional services, measure turnaround, automation rates and staff effort, and refine rules and questionnaires based on results. Continuous improvement turns compliance projects into lasting operational gains for payers and providers alike. Results justify expansion. Leadership sees progress. Gains compound.
Implementation Cost and Services
CRD, DTR and PAS implementation costs depend on the number of services covered, existing FHIR infrastructure, rules engine maturity and back-office integration complexity. Our work is billed at a blended rate of $50 per hour, and the ranges below are planning figures, not quotes. Rules engine licenses, FHIR platform fees and intermediary fees are separate. The six options below describe how payers and providers engage us, and you can hire AI prior authorization developers when internal teams need additional capacity before the 2027 deadline. Scope is agreed first. Plan early.
Readiness Assessment: $3,000 to $10,000
A readiness assessment covering policies, infrastructure, utilization management systems and partner readiness typically takes 60 to 200 hours. It produces a prioritized implementation plan for CRD, DTR and PAS aligned with the January 2027 deadline. Findings are prioritized. Timelines become clear.
CRD Service Build: $15,000 to $60,000
Building a CRD service with CDS Hooks endpoints, coverage rules for priority services, prefetch and monitoring typically takes 300 to 1,200 hours, depending on rules complexity and the number of services and plans covered. Performance testing is included. Rules are documented.
DTR Content Development: $10,000 to $50,000
Developing questionnaires and CQL prepopulation logic for priority services typically takes 200 to 1,000 hours. Content complexity varies widely by service, and testing against real EHR data patterns accounts for significant effort. Clinical review is built in. Reuse helps later.
PAS Endpoint and Integration: $20,000 to $80,000
Implementing PAS endpoints, bundle validation, status updates and integration with utilization management systems typically takes 400 to 1,600 hours, depending on back-office systems and intermediary requirements. Monitoring, logging and partner testing are included, and reuse of existing FHIR infrastructure lowers effort.
Provider-Side Implementation: $6,000 to $24,000
For providers and health technology companies, configuring EHR support, DTR applications and PAS submission workflows typically takes 120 to 480 hours per integration scope, with reuse lowering effort across additional payers. Workflow training is included. Adoption follows. Costs fall later.
Ongoing Content and Support: $1,000 to $4,000 Per Month
After launch, retainers covering 20 to 80 hours per month maintain rules, questionnaires and endpoints as policies, guides and regulations change, keeping implementations accurate and compliant over time. Scope is reviewed quarterly, and urgent policy changes are prioritized promptly. Compliance stays current.
Why Choose Taction for Da Vinci Implementation
Da Vinci implementations require engineers who understand FHIR, CDS Hooks, SMART applications, clinical logic and payer operations together. Gaps in any area stall projects or produce integrations providers will not use. Our team brings that combined expertise, drawing on 200+ healthcare projects since 2013 and ISO 27001 certified processes. We sign Business Associate Agreements before accessing PHI. The six points below explain what working with us on CRD, DTR and PAS looks like in practice for payers, provider organizations and health technology companies preparing for electronic prior authorization. Expertise matters.
End-to-End FHIR Expertise
Our engineers build FHIR servers, CDS Hooks services, SMART applications and integration pipelines. That breadth lets us implement all three guides coherently, rather than handing off pieces between specialists who understand only one part of the workflow. Handoffs disappear. Results improve.
Clinical Logic Experience
Translating policies into CQL and questionnaires requires understanding clinical concepts and terminology. Our team works with clinical policy experts to produce logic that reflects policy intent accurately and performs reliably against real-world EHR data. Accuracy builds trust. Clinicians trust results.
Revenue Cycle Background
For Voyant Health, we built revenue cycle automation covering eligibility and records workflows. The Voyant Health case study shows the operational understanding we bring to authorization projects. That project’s delivery discipline and workflow knowledge carry directly into prior authorization implementations.
Back-Office Integration
We connect standards-based endpoints to utilization management, claims and care management systems, so electronic requests flow into existing operations. Integration is what turns electronic prior authorization from a compliance checkbox into real administrative savings. Savings become real. Queues stay unified.
Both Sides of the Exchange
We work with payers and providers, so we understand what each side needs from the other. That perspective helps us design implementations that work in end-to-end testing rather than meeting specifications in isolation. Testing goes smoother. Partners align faster. Launches go smoothly.
You Own the Implementation
Code, rules, questionnaires, configurations and documentation belong to you. We hand everything over in documented form, so your teams can maintain implementations internally or continue working with us through ongoing support. No lock-in applies. Handover is complete. Teams stay independent.
Frequently Asked Questions
These are the questions payer interoperability leaders, utilization management teams, EHR product managers and provider IT teams ask most often about CRD, DTR and PAS, whether they are planning implementation, preparing content or testing with partners ahead of 2027. The answers are short on purpose and are not legal advice, so confirm requirements against current CMS rules and HHS guidance. If your question depends on your systems or services, a short call with our team will help. For terminology, see our Da Vinci Project glossary entry. Ask anything. Confirm specifics.
What Do CRD, DTR and PAS Stand For?
CRD stands for Coverage Requirements Discovery, DTR for Documentation Templates and Rules, and PAS for Prior Authorization Support. They are HL7 Da Vinci FHIR implementation guides that together automate prior authorization from ordering through decision. They work best together. Learn all three.
Are the Da Vinci Guides Required by CMS?
CMS requires impacted payers to implement a FHIR-based Prior Authorization API by January 1, 2027, and recommends the Da Vinci CRD, DTR and PAS guides. Following recommended guides improves consistency and interoperability with provider systems. Confirm specifics. Plan accordingly. Start soon.
Do Providers Need to Build Anything?
Most providers rely on EHR vendors for CRD, DTR and PAS support, but must configure, test and adopt workflows. Health technology companies and organizations with custom systems may need their own implementations to participate in electronic prior authorization. Ask vendors early.
How Does PAS Relate to X12 278?
PAS was designed to work with intermediaries converting FHIR requests to X12 278 transactions, which HIPAA historically required. HHS has announced enforcement discretion relevant to FHIR-based submissions, so confirm current requirements with counsel before finalizing architecture. Plan carefully. Monitor guidance.
Which Services Should We Start With?
Start with high-volume services requiring authorization, such as advanced imaging and common procedures. These services deliver the greatest administrative savings and generate experience that makes expanding to additional services faster and less risky. Expand gradually. Measure results. Start focused. Grow steadily.
How Much Does Implementation Cost?
At our $50 blended hourly rate, a readiness assessment typically costs $3,000 to $10,000, while payer implementations across CRD, DTR and PAS commonly range from $45,000 to $190,000, depending on services and back-office integration. Fees are separate. Scope decides. Fees vary.
Tell Us About Your Prior Authorization Plans
Share whether you are a payer or provider, your priority services, current systems and timeline. In a 30-minute call we will outline your path to CRD, DTR and PAS readiness. Book a free consultation. There is no commitment. It is free.