Extract Prior Authorization Evidence From Clinical Notes Without Manual Chart Review
Prior authorization evidence rarely exists in one place.
A payer may require documentation of a qualifying diagnosis, failed treatment, symptom severity, prior procedures, laboratory results, imaging findings, or medical-necessity rationale. That information can be distributed across structured EHR resources, progress notes, diagnostic reports, scanned documents, and historical treatment records.
The technical challenge is therefore not simply using AI to summarize a clinical note. The real challenge is connecting payer-specific documentation requirements to the right clinical evidence, preserving its source, validating its context, and presenting it for targeted human verification.
HL7 Da Vinci’s Documentation Templates and Rules (DTR) implementation guide provides a standards-based mechanism for expressing documentation requirements computably and supports extracting existing EHR information for review or confirmation. However, general-purpose extraction of nuanced evidence from free-text clinical notes remains an application-layer NLP/AI problem rather than a capability provided automatically by DTR.
This distinction is critical when designing a production-grade prior authorization workflow.
What Is Prior Authorization Evidence Extraction?
Prior authorization evidence extraction is the process of identifying information in structured and unstructured clinical data that can address a specific payer documentation requirement.
For example, a payer may require evidence that a patient:
- Has a qualifying diagnosis
- Has persistent or clinically significant symptoms
- Tried a specified conservative treatment
- Failed or did not adequately respond to previous treatment
- Has supporting laboratory or imaging findings
- Meets a treatment-duration requirement
- Has a documented medical-necessity rationale
- Has a current treatment plan supporting the requested service
The evidence may be distributed across multiple resources.
A Condition may contain the diagnosis. An Observation may contain a relevant measurement. A DiagnosticReport may contain imaging findings. A Procedure may show prior treatment. A DocumentReference may point to a progress note containing the clinician’s narrative explanation.
US Core v9.0.0 specifically identifies DocumentReference and DiagnosticReport as mechanisms for exchanging clinical notes and reports. DocumentReference is appropriate for broader narrative documents such as progress and discharge notes, while DiagnosticReport can represent coded results and narrative reports.
The goal is therefore not to create another clinical summary.
It is to create a traceable chain: Authorization requirement → candidate evidence → clinical context → source document → human verification → submission
Why Manual Chart Searching Becomes the Bottleneck
A conventional workflow often looks like this:
PA request
↓
Staff opens patient chart
↓
Searches encounters and notes
↓
Reviews treatment history
↓
Finds supporting evidence
↓
Copies relevant information
↓
Locates supporting documents
↓
Attaches documentation
↓
Submits authorization
This workflow becomes difficult when evidence is fragmented.
A progress note may contain treatment failure. A radiology report may contain the objective finding. A medication record may establish previous therapy. A separate document may contain the medical-necessity rationale.
US Core acknowledges this variability. Clinical notes can exist as text, XHTML, PDF, CDA, scanned documents, and other representations. DocumentReference and DiagnosticReport function partly as indexing mechanisms that allow clients to locate the underlying content.
The opportunity is therefore not to eliminate clinical oversight. It is to eliminate the repetitive searching, copying, and locating that occurs before clinical staff can make a decision.
The Standards Architecture Behind the Workflow
A production implementation should not treat AI as the prior authorization architecture.
The standards layer and evidence-extraction layer have different responsibilities. A useful architecture is:
Coverage requirements
↓
CRD
↓
Documentation requirements
↓
DTR
↓
Structured EHR retrieval
+
Clinical document retrieval
↓
NLP / evidence extraction layer
↓
Context + temporal validation
↓
Evidence-to-requirement mapping
↓
Source / provenance capture
↓
Human verification
↓
PAS / CDex / payer workflow
The major components are Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), Prior Authorization Support (PAS), and Clinical Data Exchange (CDex). They should not be treated as interchangeable technologies.
CRD: Determine What the Payer Requires
Da Vinci CRD is intended to help determine whether a service is covered, whether prior authorization is required, and whether additional information needs to be gathered.
The current CRD specification makes an important architectural distinction: CRD servers should query data necessary for their coverage determination when that data is available in the EHR. CRD explicitly states that it is not appropriate to rely exclusively on DTR for data retrieval; DTR is intended for data retrieval requiring human intervention or review.
This means the workflow should not be modeled as: CRD → DTR → AI reads everything
Instead:
CRD determines applicable requirements → available EHR data is retrieved → DTR handles documentation requiring interaction/review → an application-level evidence engine can process narrative documentation where structured data alone is insufficient.
That separation prevents overloading DTR with capabilities it was not designed to provide.
DTR: Make Documentation Requirements Computable
DTR provides a mechanism for payers to express documentation requirements in a computable form. It uses:
- FHIR Questionnaires
- Clinical Quality Language (CQL)
- Value sets
- Existing EHR data
- Patient-specific QuestionnaireResponse
DTR can automatically extract existing EHR information for review or confirmation and adjust which information is requested based on data already available. It can operate through SMART on FHIR applications or functionality embedded in the EHR.
For example, a requirement could conceptually be: Requirement:
Evidence of failed conservative therapy
Required information:
– Treatment type
– Treatment duration
– Treatment status
– Response to treatment
– Supporting documentation
– Documentation date
The important distinction is that DTR provides the computable documentation framework. An NLP/AI component may be added to identify evidence buried in narrative text that cannot be reliably populated from structured resources alone.
Step 1: Convert the PA Requirement Into an Evidence Model
Do not begin with a generic instruction such as: Summarize this patient’s chart.
That produces information, not authorization evidence. Instead, represent each payer requirement as a structured evidence model. For example:
| { “requirement”: “failed_conservative_therapy”, “evidence”: { “treatment”: null, “duration”: null, “response”: null, “status”: null, “source”: null } } |
This changes the extraction problem from: “What is important in this chart?”
To: “What documented information satisfies this specific requirement?”
That distinction significantly reduces irrelevant extraction and makes validation measurable.
Step 2: Retrieve Structured and Narrative EHR Data
The evidence engine should retrieve only the clinical data relevant to the authorization requirement. For clinical notes, US Core provides a standard FHIR search pattern:
| GET [base]/DocumentReference?patient=[id]&category=clinical-note |
For radiology reports, a client can use:
| GET [base]/DiagnosticReport?patient=[id]&category=http://loinc.org|LP29684-5 |
These are examples from the current US Core Clinical Notes guidance. But a production implementation should not assume that every EHR stores narrative content in exactly the same way.
A DocumentReference may point to:
- Plain text
- XHTML
- CDA
- Scanned documents
- Other document content
DiagnosticReport.presentedForm can similarly represent the narrative report. US Core specifically notes variability in how scanned and narrative-only reports are represented across systems. This is why document ingestion must be treated as an integration problem, not merely an LLM input problem.
Step 3: Extract Candidate Evidence From Clinical Notes
After retrieving the relevant documents, an NLP/AI layer can identify candidate evidence. For example:
| { “requirement”: “failed_conservative_therapy”, “evidence”: “Patient completed 8 weeks of physical therapy with minimal improvement.”, “source”: { “resourceType”: “DocumentReference”, “id”: “12345” }, “section”: “Assessment and Plan”, “date”: “2026-08-14”, “status”: “candidate” } |
The JSON format is illustrative. The important architectural requirement is source linkage. The extraction system should not return only:
Failed physical therapy.
It should return:
Evidence
↓
Original source
↓
Documentation date
↓
Clinical section
↓
Requirement addressed
This makes the output auditable and allows a reviewer to verify the statement against the source.
Step 4: Apply Clinical Context, Negation, and Temporal Reasoning
Keyword matching is not sufficient for clinical evidence extraction.
Consider: “Patient denies previous physical therapy.”
Versus: “Patient completed eight weeks of physical therapy without improvement.”
Both contain “physical therapy,” but they mean completely different things. The extraction layer should therefore evaluate:
Assertion
- Present
- Absent
- Suspected
- Ruled out
- Denied
Temporal state
- Current
- Historical
- Planned
- Completed
- Discontinued
Subject
- Patient
- Family member
- Other individual
Treatment status
- Recommended
- Started
- Completed
- Failed
- Discontinued
Evidence source
- Structured FHIR resource
- Clinical note
- Diagnostic report
- External document
- Scanned document
For example:
Entity: Physical therapy
Status: Completed
Duration: 8 weeks
Response: Minimal improvement
Temporal state: Historical
Source: Progress Note
Documentation date: 2026-08-14
This is why a healthcare evidence-extraction system requires more than keyword search or unconstrained text generation.
Step 5: Connect Evidence to the Requested Service
Finding evidence is not enough. The system must determine whether that evidence is relevant to the service being authorized. A useful relationship model is:
Requested Service
↓
Clinical Indication
↓
Diagnosis
↓
Symptoms / Findings
↓
Previous Treatment
↓
Treatment Response
↓
Supporting Documentation
For example:
ServiceRequest
↓
Knee procedure
↓
Osteoarthritis
↓
Persistent pain
↓
Physical therapy attempted
↓
Minimal improvement
↓
Progress note + imaging report
FHIR ServiceRequest can represent requested services and reference supporting clinical information where appropriate. PAS also defines mechanisms for transmitting supporting information associated with prior authorization requests.
The system should therefore answer:
Which evidence supports this authorization requirement for this specific requested service?
—not simply: What information exists in the patient’s chart?
Step 6: Never Infer Missing Clinical Evidence
This is one of the most important safeguards. Suppose the clinical note says: “Patient has tried multiple medications.” The system should not transform that into: “Patient failed two first-line medications for 12 weeks.” unless those facts are explicitly documented elsewhere. The evidence engine should distinguish:
- Explicit evidence
- Structured evidence
- Inferred evidence
- Missing evidence
- Conflicting evidence
For prior authorization, missing evidence should remain missing.
If a payer requirement cannot be supported by available documentation, the workflow should surface that gap rather than generate a plausible-looking answer.
This is particularly important when using generative AI because fluent language can conceal unsupported inference.
Step 7: Preserve Source and Provenance
Every candidate evidence item should retain enough information to trace it back to its clinical source. A practical application-level evidence record can include:
Requirement
Evidence statement
Source resource type
Source resource ID
Author
Documentation date
Note section
Evidence span
Extraction timestamp
Extraction/model version
Verification status
Reviewer
Not every field above is a mandatory US Core Provenance field. Rather, this is an application-level evidence-lineage model that complements FHIR Provenance and audit requirements.
The objective is simple: PA requirement → extracted evidence → original clinical source
A reviewer should be able to move through that chain without manually searching the entire patient chart.
Step 8: Keep Human Verification in the Workflow
The objective should be to eliminate manual chart searching, not clinical accountability.
A production interface could present:
Requirement:
Failed conservative therapy
Candidate evidence:
“Patient completed 8 weeks of physical therapy with minimal improvement.”
Source:
Progress Note
08/14/2026
Assessment & Plan
[Accept] [Reject] [View Source]
The reviewer verifies the candidate evidence and can immediately open the source.
This approach is consistent with the broader direction of current CMS workflows. Under the WISeR Model, CMS requires human clinical review for non-affirmations; enhanced technology supports the workflow but does not replace the required clinical review. CMS also specifies supporting documentation such as recent visit notes, relevant laboratory or imaging results, medical-necessity rationale, prior treatment history, and current treatment plans, as applicable to the requested service.
The evidence-extraction system should therefore be designed as decision support for documentation retrieval, not an autonomous medical-necessity adjudicator.
Step 9: Package and Exchange the Verified Evidence
After verification, the system can pass the appropriate information to the downstream authorization workflow. Da Vinci PAS provides the FHIR-based prior authorization exchange workflow. The current PAS 2.2.1 implementation guide is based on FHIR R4 and defines the technical requirements around the PA submission process.
DocumentReference can also represent supporting documents, including clinical notes and scanned documents, within PAS workflows.
Da Vinci CDex provides additional mechanisms for exchanging clinical data and attachments for use cases including prior authorization. Its guidance includes attachment workflows using FHIR questionnaires and QuestionnaireResponses. The implementation should therefore distinguish between:
Evidence extraction
and
Evidence exchange.
The first is an application/informatics problem. The second is governed by interoperability standards and payer-specific workflows.
FHIR Does Not Mean X12 278 Disappears
A production prior authorization architecture should not assume that FHIR replaces every existing transaction standard.
CMS’s final interoperability and prior authorization rule requires impacted payers to implement a FHIR-based Prior Authorization API, with compliance dates generally delayed to January 1, 2027. CMS has also issued enforcement discretion allowing covered entities implementing the specified FHIR Prior Authorization API to use an all-FHIR approach without HIPAA enforcement action for not using X12 278 in that FHIR process.
However, CMS explicitly states that the regulatory X12 278 requirement remains in place and that the enforcement discretion applies specifically to covered entities using the qualifying FHIR-based PA API.
Therefore, an enterprise architecture may need to accommodate:
Clinical systems
↓
FHIR / HL7 / documents
↓
Evidence extraction
↓
Verified PA evidence
↓
FHIR PA API / PAS
+
X12 278 where applicable
+
CDex / document exchange
The exact transaction path depends on the payer, workflow, and applicable requirements.
A Production-Grade Architecture
The complete solution should look more like an evidence-orchestration platform than a standalone AI model:
The key design principle is separation of concerns.
- CRD determines coverage requirements.
- DTR makes documentation requirements computable and supports information gathering/review.
- FHIR and document interfaces retrieve clinical information.
- NLP/AI identifies candidate evidence from narrative content.
- Validation checks context and consistency.
- Provenance preserves source lineage.
- Human reviewers verify the evidence.
- PAS/CDex and applicable transaction mechanisms handle downstream exchange.
How to Validate the Evidence-Extraction System
A production system should not be evaluated only on whether an LLM produces readable output.
Build a representative validation dataset containing:
- PA requirements
- Source clinical documents
- Expert-validated evidence spans
- Positive and negative examples
- Historical and current treatments
- Negated statements
- Conflicting documentation
- Missing evidence
- Multiple supporting documents
Then measure:
Evidence Precision
How often is extracted evidence actually relevant to the requirement?
Evidence Recall
How often does the system find evidence that is actually present?
Requirement Completeness
Did the system identify enough evidence to address the requirement?
Source Accuracy
Does every extracted statement point to the correct source?
Temporal Accuracy
Did the system distinguish historical treatment from current treatment?
Reviewer Acceptance
How often do qualified reviewers accept the candidate evidence?
False-Negative Rate
How often does the system miss evidence that matters to the authorization?
The goal should not be a single model-accuracy number. The goal is a measurable evidence pipeline in which errors can be identified at retrieval, extraction, mapping, validation, or submission stages.
The Engineering Challenges That Actually Matter
The difficult part of this problem is not calling an LLM API. The difficult part is making this chain reliable:
payer requirement → correct clinical data → correct document → correct evidence → correct context → correct source → human verification → correct authorization package
Healthcare environments introduce additional complexity:
- EHR-specific FHIR implementations
- Different note formats
- Scanned documents
- PDF and CDA attachments
- Inconsistent terminology
- Duplicate documentation
- Historical versus current treatment
- Missing evidence
- Conflicting notes
- Payer-specific requirements
- Authentication and authorization
- PHI security
- Auditability
- Model and rules versioning
- Human-review workflows
That is why this should be treated as an interoperability and clinical-data engineering problem with an AI component, rather than as an LLM project.
What a Healthcare Organization Should Build
A practical implementation can be divided into five layers.
1. Interoperability Layer
- FHIR R4
- US Core
- SMART on FHIR where applicable
- HL7 v2 interfaces for legacy systems
- DocumentReference
- DiagnosticReport
- Condition
- Observation
- Procedure
- ServiceRequest
2. Documentation Layer
- DTR
- FHIR Questionnaire
- CQL
- QuestionnaireResponse
- Payer-specific documentation requirements
3. Evidence Layer
- Clinical document ingestion
- OCR where required
- NLP extraction
- Terminology normalization
- Negation detection
- Temporal reasoning
- Evidence-span identification
- Requirement-to-evidence mapping
4. Governance Layer
- Provenance
- Audit logging
- Access controls
- PHI protection
- Human verification
- Model/rule versioning
- Error monitoring
- Validation datasets
5. Authorization Exchange Layer
- Da Vinci PAS
- Da Vinci CDex
- FHIR-based payer APIs
- X12 278 where applicable
- Payer-specific portals or other supported channels where required
This architecture prevents the common mistake of treating the AI model as the entire solution.
Final Takeaway
The practical objective is not:
“Use AI to decide whether a patient qualifies for prior authorization.” It is:
“Use computable payer requirements and healthcare interoperability standards to identify what evidence is needed, retrieve relevant clinical information, extract candidate evidence from narrative documentation, preserve its source, validate its context, and present it for targeted human verification.”
That distinction makes the solution safer, more interoperable, and more realistic for enterprise healthcare environments.
DTR provides the computable documentation framework. CRD addresses coverage and documentation requirements. US Core provides standardized access patterns for clinical notes and reports. NLP/AI can operate as an additional evidence-extraction layer for narrative content. PAS and CDex provide mechanisms for downstream authorization and clinical-document exchange.
The result is not a black-box “AI prior authorization system.”
It is a traceable evidence pipeline that can reduce manual chart searching while keeping the clinical source, verification step, and interoperability workflow intact.
How CapMinds Can Help
Prior authorization evidence extraction sits at the intersection of FHIR interoperability, EHR integration, clinical-document processing, healthcare workflow engineering, and AI.
Getting one layer working is relatively straightforward; making the complete evidence chain reliable across real EHR and payer environments is the harder engineering problem.
CapMinds can help healthcare organizations design and implement that architecture, from FHIR and HL7 integration and clinical-document retrieval to evidence-processing workflows, interoperability mapping, and downstream prior authorization integration.
Whether the requirement is connecting an existing EHR to a FHIR-based workflow, extracting evidence from heterogeneous clinical documentation, or designing a standards-based PA evidence pipeline, the implementation needs to account for both the healthcare data model and the operational workflow around it.
Talk to CapMinds about designing a production-ready prior authorization evidence workflow.
