Electronic prior authorization is not a single transaction. It is a connected workflow: discover whether authorization or documentation is required, assemble the right clinical evidence, submit the request, and track the response. The HL7 Da Vinci CRD, DTR, and PAS implementation guides support different parts of that journey.

The short version: CRD discovers, DTR documents, PAS submits

Coverage Requirements Discovery (CRD) helps a clinical system ask for coverage guidance while a care team is planning an order, appointment, or other service. The response can indicate whether a service is covered, whether prior authorization may be required, and whether more information is needed.

Documentation Templates and Rules (DTR) supports the structured collection of information needed to satisfy payer documentation requirements. It can guide users through questions and retrieve available data while preserving a review step for information that needs human confirmation.

Prior Authorization Support (PAS) defines FHIR-based content and operations used to exchange prior authorization requests and responses. It packages the request and supporting information so payer and provider systems can communicate in a more consistent way.

A practical FHIR prior authorization workflow

A useful implementation starts before submission. When a clinician selects a service, medication, or procedure, the system needs enough patient, coverage, and order context to identify the relevant payer requirements. That is the discovery stage.

Next, the workflow should compare the available chart evidence with those requirements. It can reuse structured data such as diagnoses, medications, observations, procedures, and reports, while clearly separating machine-found evidence from facts that still require review. Missing items become specific tasks instead of a generic request for more information.

Finally, the system assembles the authorization request and its supporting information. The PAS specification describes how FHIR profiles and terminology artifacts structure that exchange, including references from the request to supporting resources.

  • Discover the patient, plan, order, and applicable coverage rules.
  • Match existing clinical evidence to each documentation criterion.
  • Ask only for information that is missing or requires confirmation.
  • Package the request, attachments, and traceable evidence for submission.
  • Track responses and route pended or incomplete cases to the right work queue.

Where a policy graph adds value

FHIR makes the exchange interoperable, but an organization still needs to translate payer policy language into computable, maintainable criteria. A policy graph can connect plans, policies, codes, diagnoses, therapies, prerequisites, evidence, and effective dates. That creates a bridge between a policy document and the patient-specific workflow.

The graph should keep the source citation and policy version attached to each criterion. Reviewers can then see why a field was requested, which evidence was matched, and what changed when a payer updated a policy.

Implementation questions to answer early

Standards conformance is only one part of production readiness. Teams also need to define source ownership, patient matching, authorization boundaries, security controls, exception handling, audit trails, and the human review points that prevent an automated suggestion from becoming an unsupported clinical assertion.

  • Which system is authoritative for coverage, order, and clinical evidence data?
  • How will the workflow identify the correct payer policy and effective version?
  • Which evidence can be reused automatically, and which evidence needs user confirmation?
  • How are attachments, questionnaire responses, and non-FHIR documents represented?
  • What happens when a payer is unavailable or returns an ambiguous response?

Start with a narrow, measurable workflow

A focused pilot is usually more informative than a broad platform rollout. Choose one service line, payer set, or high-volume procedure. Measure time spent gathering documentation, first-pass completeness, avoidable pends, turnaround time, and manual touches. Those measures reveal whether the workflow is reducing burden instead of simply moving it to another screen.

FHIR prior authorization works best when interoperability and operations are designed together. CRD, DTR, and PAS provide the exchange patterns; policy intelligence and workflow automation turn those patterns into day-to-day value.

Primary references