FHIR Prior Authorization Architecture Pack: CRD, DTR, PAS Sequence Diagrams and Readiness Checklist
FHIR prior authorization is not one API call. A production workflow must coordinate coverage discovery, payer documentation rules, clinical data retrieval, authorization submission, payer responses, pending decisions, and requests for additional information.
The HL7 Da Vinci Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR), and Prior Authorization Support (PAS) implementation guides divide these responsibilities across connected FHIR workflows.
Under CMS-0057-F, impacted payers generally must implement Prior Authorization APIs beginning January 1, 2027. These APIs must support determining whether prior authorization applies, identifying documentation requirements, submitting requests, and communicating approval, denial with a specific reason, or requests for more information. The final rule’s prior authorization provisions discussed here apply to medical items and services excluding drugs.
For architects, EHR vendors, payers, and health IT teams, the challenge is therefore not simply implementing FHIR. It is making CRD → DTR → PAS operate as one reliable authorization lifecycle.
What Is a FHIR Prior Authorization Architecture Pack?
A FHIR prior authorization architecture pack is a practical design blueprint for connecting the systems and workflows involved in electronic prior authorization.
It should define boundaries between:
- EHR and clinical workflows
- payer coverage services
- CDS Hooks
- FHIR endpoints
- Questionnaire and CQL processing
- authorization transaction services
- supporting documentation
- identity and authorization
- transaction state
- error handling and monitoring
At a high level: CRD asks: Does the requested service have coverage, documentation, or prior authorization requirements?
DTR asks: What information does the payer require, and what can be populated from available clinical data?
PAS asks: How is the authorization submitted, returned, and tracked?
The architecture matters because a technically valid FHIR request can still fail operationally if the wrong payer is selected, required clinical context is missing, documentation cannot be populated, or a pended authorization has no reliable update mechanism.
Why Version Strategy Matters for 2027 Readiness
Versioning deserves explicit architectural treatment.
The original CMS-0057-F fact sheet strongly encouraged CRD 2.0.1, DTR 2.0.0, and PAS 2.0.1.
CMS’s current implementation resources now list CRD, DTR, and PAS 2.0.1 and 2.1.0 as relevant implementation-guide versions and allow impacted payers to use qualifying updated ONC-approved versions when doing so does not disrupt API access.
The standards have continued to advance. ONC has now adopted, on behalf of HHS:
- CRD 2.2.1 – STU 2.2
- DTR 2.2.0 – STU 2.2
- PAS 2.2.1 – STU 2.2
Where these replace versions previously adopted by ONC, the newer standards take effect with the FY2027 IPPS final rule on October 1, 2026.
This does not mean CMS-0057-F was retroactively rewritten to mandate only the 2.2x guides. It means production implementations should use version-aware endpoint and capability management rather than assuming every payer, EHR, intermediary, and testing environment will move versions simultaneously.
CRD Architecture: Discover Coverage Requirements in the Workflow
CRD uses CDS Hooks to insert payer coverage guidance into clinical workflows.
A simplified sequence looks like this:
CRD 2.2.1 identifies six hooks:
- appointment-book
- encounter-start
- encounter-discharge
- order-dispatch
- order-select
- Order-sign
The specification classifies appointment-book, order-sign, and order-dispatch as primary hooks, while order-select, encounter-start, and encounter-discharge are supporting hooks.
Systems that order products or services covered by CRD-supported request types must support order-sign for the order types they support.
CRD clients must also determine the correct payer CRD service for each request.
That makes payer resolution and clinical context critical. Patient, Coverage, requested service, practitioner, organization, location, and encounter data may all influence the result.
An HTTP-successful CRD call is therefore not necessarily a functionally successful coverage discovery.
DTR Architecture: Build the Required Documentation
When additional documentation is required, DTR provides the structured data-collection workflow.
The DTR $questionnaire-package operation can return one or more collection Bundles containing a Questionnaire, an associated QuestionnaireResponse, and dependencies such as Library and ValueSet resources needed to process the questionnaire.
DTR can also support adaptive questionnaires through $next-question. Instead of presenting every question at once, the payer service can progressively determine the next questions based on information already collected.
DTR 2.2.0 specifies performance expectations for adaptive workflows: initial $next-question responses are expected within five seconds, while subsequent calls against the same QuestionnaireResponse within 60 minutes are expected within one second; conformant implementations must meet those timing expectations at least 90% of the time.
Pre-population should not be mistaken for automatic clinical attestation. Users can adjust information populated by the payer or local population logic.
Production DTR testing should therefore cover:
- Questionnaire version resolution
- FHIR data mappings
- CQL execution
- terminology bindings
- missing-data behavior
- adaptive-question flow
- prepopulation accuracy
- clinician review
- provenance and traceability
PAS Architecture: Submit and Manage the Authorization
PAS provides the transaction layer for submitting prior authorization requests.
FHIR uses Claim and ClaimResponse for multiple financial workflows, including prior authorization. PAS distinguishes the prior authorization use through the Claim content and profiles.
A simplified sequence is:
The request is submitted as a FHIR Bundle to:
[base]/Claim/$submit
The operation accepts a PAS prior authorization Bundle and returns either a response Bundle containing the PAS ClaimResponse and related resources or an OperationOutcome.
The current PAS specification states that the interaction SHOULD occur synchronously within a maximum of 15 seconds, including network transmission time from the user’s initiation through presentation of the response.
But 15 seconds is not the payer’s regulatory deadline for making every authorization decision.
If the payer cannot complete adjudication immediately, one or more authorization items can be returned as pended.
Pended Requests Require State Management
A prior authorization is a stateful business transaction, not simply an HTTP request.
PAS requires a subscription-based mechanism for clients to receive updates on pended authorizations. Claim Inquiry is also available, but the specification warns against using inquiry as the primary mechanism while waiting for the final result because an inquiry response may omit information such as additional-information requests.
The application therefore needs to differentiate states such as:
This state model should exist independently of HTTP status codes.
Handling Requests for Additional Information
“More information required” should also not be modeled as a simple terminal authorization status.
PAS uses its Task profile with the Da Vinci Clinical Data Exchange (CDex) workflow for additional documentation. The Task can represent requests for specific attachments or payer questionnaires and provides the information needed to submit documentation through $submit-attachment.
The PAS specification recommends that payers obtain as much required information as possible through the initial DTR process and use subsequent additional-information workflows when later review identifies something that could not reasonably have been collected earlier.
End-to-End CRD, DTR, and PAS Architecture
The complete lifecycle can be represented as:
The most important architecture decision is maintaining transaction correlation across the entire lifecycle.
CRD activity, DTR QuestionnaireResponse, PAS request, payer identifiers, additional-information Tasks, attachments, retries, and final responses should be traceable to the same authorization workflow.
Do You Still Need X12 278?
Not in every FHIR Prior Authorization API architecture.
HIPAA’s X12 278 requirement still exists in regulation. However, HHS has announced enforcement discretion for HIPAA covered entities implementing and using the FHIR Prior Authorization API described by CMS-0057-F. Covered entities can therefore choose an all-FHIR approach without X12 278 within that API process without HIPAA Administrative Simplification enforcement action for that choice.
CMS also states that X12 278 alone cannot satisfy the Prior Authorization API requirements because it does not provide all of the required coverage and documentation-discovery capabilities.
PAS itself continues to describe FHIR-to-X12 processing but now acknowledges that, because of enforcement discretion, payer systems may instead process FHIR transactions directly.
Therefore, architecture should explicitly determine whether each integration path is:
FHIR → Payer
Or:
FHIR → PAS / Intermediary → X12 → Payer
That decision depends on payer infrastructure, trading-partner relationships, and the regulatory context.
FHIR Prior Authorization Readiness Checklist
Standards and Version Governance
- CRD, DTR, and PAS responsibilities are clearly separated.
- The three workflows are orchestrated as one authorization lifecycle.
- CRD 2.2.1, DTR 2.2.0, and PAS 2.2.1 are included in the forward version roadmap.
- Older payer and certification versions can be supported where necessary.
- Endpoint capabilities and supported IG versions are configuration-driven.
- FHIR-only versus FHIR-to-X12 processing is documented.
CRD
- CDS Hooks align with real ordering, scheduling, and encounter workflows.
- Order-sign support is implemented where required.
- Correct payer endpoint resolution is validated.
- Patient, Coverage, provider, organization, location, and service context are available.
- CRD failures return actionable workflow behavior rather than silent errors.
DTR
- $questionnaire-package processing is supported.
- Questionnaire and QuestionnaireResponse profiles are validated.
- Library, ValueSet, and CQL dependencies are managed.
- Adaptive $next-question behavior is tested where applicable.
- Pre-populated answers remain reviewable and editable.
- Missing clinical data has defined handling.
PAS and Transaction State
- PAS Bundles are validated before submission.
- Approved, denied, and pended states are modeled separately.
- Subscription-based updates are supported for pended requests.
- Additional-information workflows support PAS Task/CDex behavior.
- Retries, timeouts, modification, cancellation, and duplicate submissions are handled.
- Correlation identifiers connect all authorization artifacts.
Security and Operations
- Applicable SMART/OAuth authorization and trust controls are validated.
- PHI-safe application logging is enforced.
- Audit trails preserve authorization lifecycle events.
- Negative and timeout scenarios are tested.
- Payer/EHR bilateral and end-to-end testing is completed.
- Operational telemetry captures latency, pending duration, denial reasons, documentation requests, retries, and failures.
Do Not Treat Inferno Passing as Production Readiness
Inferno currently supports PAS 2.0.1 and 2.2.1 and CRD 2.0.1 and 2.2.1. Its hosted DTR test kit currently targets DTR 2.0.1. All three listed Da Vinci prior authorization test kits are presently marked as low maturity.
Inferno is therefore valuable for conformance testing, but a passing result should not be treated as proof that a complete production authorization workflow is ready.
Production validation should also cover payer-specific connectivity, workflow sequencing, authorization state, questionnaire behavior, security, data quality, retries, user experience, and operational failure recovery.
Build a Production-Ready FHIR Prior Authorization Architecture with CapMinds
FHIR validation is only one layer of electronic prior authorization readiness.
CRD must operate at the right point in the clinical workflow. DTR needs reliable access to payer rules and clinical data. PAS requires transaction-state management, pending-response handling, documentation exchange, payer routing, security, testing, and production observability.
CapMinds FHIR and healthcare interoperability services help healthcare organizations design and implement electronic prior authorization across EHR, payer, clearinghouse, and digital health environments.
Our teams can support:
- CRD and CDS Hooks integration
- DTR architecture and questionnaire workflows
- PAS implementation and transaction-state management
- FHIR resource and terminology mapping
- Payer endpoint and version strategy
- FHIR-to-X12 interoperability where required
- CDex attachment workflows
- SMART and API security architecture
- Conformance and end-to-end testing
- Production monitoring and workflow validation
