What is Da Vinci Project? (HL7 Da Vinci Project)

Prior authorization (PAS — Prior Authorization Support IG). One of the highest-impact Da Vinci use cases. The PAS IG defines how a provider’s EHR submits a prior authorization request to a payer via FHIR API — replacing the phone calls, fax forms, and payer web portals that currently consume hours of staff time per request. The payer returns a decision (approved, denied, pend) electronically. CMS’s Prior Authorization Final Rule references Da Vinci PAS as the implementation standard for electronic prior auth.

Coverage requirements discovery (CRD IG). Before a provider orders a service, the CRD IG enables the EHR to query the payer in real time: “Does this patient’s plan cover this service? Is prior auth required? Are there documentation requirements?” The payer responds with coverage information surfaced through CDS Hooks — clinical decision support cards that appear within the EHR ordering workflow. This prevents unnecessary prior auth submissions and catches coverage issues before the service is performed.

Documentation templates and rules (DTR IG). When prior authorization or other documentation is required, the DTR IG enables the payer to send the provider a FHIR Questionnaire — a structured form that specifies exactly what documentation the payer needs. The EHR auto-populates the form with data already in the patient’s record, the provider completes any remaining fields, and the completed form is submitted with the prior auth request. This replaces the back-and-forth of “we need more information” denials.

Member attribution (ATR IG). In value-based care arrangements, payers attribute specific patients to provider organizations for quality and cost accountability. The ATR IG defines how payers share member attribution lists with providers via FHIR — enabling providers to know which patients they’re accountable for and manage their care proactively.

Quality measure reporting (DEQM IG). The Data Exchange for Quality Measures IG defines how clinical quality measure data flows between providers and payers using FHIR. Instead of generating QRDA documents and submitting them through legacy channels, providers can report measure data through FHIR APIs — enabling more frequent, more granular quality reporting.

Risk adjustment (RA IG). The Risk Adjustment IG defines how payers and providers exchange risk adjustment data — diagnosis codes and supporting documentation that determine capitation rates in Medicare Advantage and other risk-based payment models.

Payer data exchange (PDex IG). The Payer Data Exchange IG defines how payers share clinical and claims data with providers and with other payers. This supports the CMS Provider Access API requirement (payers sharing data with in-network providers) and the Payer-to-Payer exchange requirement (payers sharing data when patients switch plans).

Start with the IGs CMS mandates. Not all Da Vinci IGs carry equal regulatory urgency. Focus first on PAS (prior authorization), CRD (coverage requirements discovery), and PDex (payer data exchange) — these are the IGs referenced in CMS rules with defined compliance deadlines. Other IGs (DEQM, ATR, RA) are valuable but have different timelines.

EHR vendor readiness varies. Da Vinci adoption requires EHR vendors to implement CDS Hooks, FHIR Questionnaire rendering (for DTR), and FHIR-based prior auth submission. Major EHR vendors are at different stages of Da Vinci readiness. Assess your EHR vendor’s Da Vinci implementation timeline and participate in pilot programs where available.

Payer API availability is uneven. Even as CMS mandates approach, payer readiness for Da Vinci-based APIs varies widely. Large national payers are further along than regional plans. Your implementation plan should account for a transition period where some payers support Da Vinci APIs while others still require legacy prior auth and coverage verification methods.

Testing with the Da Vinci Reference Implementations. HL7 provides reference implementations and test servers for Da Vinci IGs. Use these for development and conformance testing before connecting to production payer or provider systems. The Da Vinci community also runs connectathons — multi-vendor testing events where payers, providers, and EHR vendors test interoperability together.

Workflow redesign, not just API implementation. Da Vinci changes workflows — real-time coverage discovery replaces pre-service phone calls, automated prior auth replaces manual submission, and FHIR-based quality reporting replaces batch QRDA generation. The technology implementation must be accompanied by workflow redesign, staff training, and change management.

HIPAA and security. Da Vinci API exchanges involve protected health information — patient diagnoses, procedures, medications, and coverage details. All Da Vinci API implementations must meet HIPAA Security Rule requirements for encryption, access controls, and audit logging. Business Associate Agreements must be in place between exchanging parties.