Da Vinci PAS Versions: 2.0.1, 2.1.0, 2.2.1 & CMS-0057-F

Introduction

CMS-0057-F has made prior authorization modernization a board-level and architecture-level issue for payers. The rule requires impacted payers to implement new interoperability and prior authorization API capabilities on the CMS timeline, with major API requirements generally beginning January 1, 2027.

For technical teams, however, the practical question is not just "Do we need a prior authorization API?" It is:

Which Da Vinci PAS version are we building and validating against?

That question matters. A FHIR payload can be valid FHIR R4 and still fail Da Vinci PAS validation if it does not conform to the selected PAS Implementation Guide package. PAS version selection affects Bundle profiles, Claim and ClaimResponse profiles, extensions, required fields, provider modeling, diagnosis modeling, and test results.

This article explains the relationship between CMS-0057-F and Da Vinci PAS, why PAS versions matter, and how payers should think about PAS 2.0.1, 2.1.0, and 2.2.1.

CMS-0057-F Is the Rule. Da Vinci PAS Is the Technical Guide.

CMS-0057-F is a federal rule. It defines obligations for impacted payers, including prior authorization API requirements and other interoperability responsibilities.

Da Vinci PAS, short for Prior Authorization Support, is an HL7 FHIR Implementation Guide. It defines how prior authorization requests and responses are represented using FHIR resources, profiles, extensions, and operations.

The simple distinction:

CMS-0057-F   = why payers must implement prior authorization APIs
Da Vinci PAS = how the FHIR prior authorization payload is structured

CMS does not publish a single JSON schema called "CMS-0057-F." Instead, CMS points implementers toward standards and implementation guides. For the Prior Authorization API, CMS's implementation-guide page lists FHIR R4, US Core, SMART, CRD, DTR, and Da Vinci PAS versions relevant to implementation.

As of June 2026, the CMS Prior Authorization API standards page lists Da Vinci PAS 2.0.1 and 2.1.0. HL7's current Da Vinci PAS publication page lists PAS 2.2.1 as the current published version.

That creates a real implementation question: should a payer target the CMS-listed versions, the latest HL7 publication, or multiple versions?

Why PAS Version Choice Matters

FHIR implementation guides are not just documentation. They define machine-testable expectations.

When a FHIR validator is loaded with a PAS package such as:

hl7.fhir.us.davinci-pas#2.0.1
hl7.fhir.us.davinci-pas#2.1.0
hl7.fhir.us.davinci-pas#2.2.1

the validator checks the generated FHIR against that specific version's profiles and constraints.

The selected PAS version can affect:

• whether the root Bundle declares the correct PAS request or response profile
• whether the focal resource is a Claim or ClaimResponse with the right profile
• whether providers are represented as Practitioner, PractitionerRole, or Organization
• whether diagnosis information is represented inline or by reference
• where PAS-specific extensions appear
• which extension URLs are valid
• whether Coverage, beneficiary, insurer, and service-line data satisfy profile requirements
• whether the response can be correlated to the original request

This is why "FHIR R4 output" is not enough. Prior authorization payloads need to be validated against the chosen PAS IG package.

PAS 2.0.1: The CMS Baseline Conversation

PAS 2.0.1 is important because CMS lists it for the Prior Authorization API. For many payer implementation conversations, especially those focused on CMS-0057-F readiness, PAS 2.0.1 is the safest starting point.

It is a practical baseline for organizations asking:

• What do we need for the CMS prior authorization API?
• What version should our first implementation target?
• What version should we use for early partner testing?
• What version should our X12 278 to FHIR PAS conversion validate against first?

For Redix customers, this is often the natural first target for version-specific mapping work. If a payer asks for a CMS-0057-F PAS implementation but does not name a specific PAS version, PAS 2.0.1 should be part of the conversation.

That does not mean every payer will stop at 2.0.1. It means 2.0.1 is a CMS-listed baseline that should not be ignored.

PAS 2.1.0: The CMS-Listed Newer Path

CMS also lists PAS 2.1.0 for the Prior Authorization API. That makes 2.1.0 important for payers who are already aligning with newer implementation-guide stacks or who need to coordinate PAS with related Da Vinci workflows such as CRD and DTR.

PAS 2.1.0 should be considered when:

• a payer or implementation partner names it explicitly
• a validation environment is configured for 2.1.0
• a payer is aligning prior authorization work with newer US Core or Da Vinci guide references
• an enterprise FHIR platform, API gateway, or EHR integration partner is already using a 2.1.0-based stack

The key point is operational: the mapping, validation package, and customer-facing documentation should all say the same version.

If the converter generates PAS 2.0.1-shaped output but the payer validates against PAS 2.1.0, the output may fail even if the underlying X12 parsing is correct.

PAS 2.2.1: The Current HL7 Publication

HL7's Da Vinci PAS page currently identifies PAS 2.2.1 as the current published version. That makes it important for organizations tracking the latest published PAS work.

However, latest HL7 publication and CMS-listed implementation references are not always the same thing. A payer may ask for CMS-0057-F readiness and expect PAS 2.0.1 or 2.1.0. Another payer may ask for the current HL7 PAS publication and expect 2.2.1.

PAS 2.2.1 is useful for:

• forward-looking platform planning
• understanding where PAS is evolving
• newer validation environments
• teams that want to align with the current HL7 publication rather than only the CMS-listed versions

But it should not be treated as the default CMS-0057-F target unless the customer, validator, or implementation program specifies it.

The safe phrase is:

Validate against the PAS version selected for the implementation.

Version Comparison

The table below summarizes the planning distinction. It is not a substitute for reading the release notes and profiles for each guide version.

The X12 278 Conversion Problem

Most payers already have X12 278 infrastructure. CMS-0057-F introduces FHIR prior authorization API expectations, but that does not make X12 disappear overnight.

In practice, payers need a transition layer:

X12 278 request   -> FHIR PAS request
FHIR PAS response -> X12 278 response
X12 278 response  -> FHIR PAS response

Scope note: Forward X12 278 to FHIR PAS conversion is validated and available; reverse FHIR PAS to X12 278 is scoped for private technical review or deployment evaluation.

Each direction has version consequences.

For example, an X12 278 request may contain enough data to create a generic FHIR R4 Claim, but not enough data to satisfy a strict PAS profile without additional mapping logic, synthesized defaults, or richer source transactions.

A strict PAS validator may require:

• PAS-specific Bundle profiles
• PAS-specific Claim and ClaimResponse profiles
• beneficiary, insurer, and coverage profiles
• PractitionerRole or Organization references in places where a generic FHIR conversion might use Practitioner
• service-line detail in Claim.item
• PAS item-level extensions
• traceable response-to-request correlation

That is the difference between "FHIR-like output" and "validated PAS output."

Redix Recommendation: Version-Specific Mappings

Do not treat PAS as one static target.

Redix recommends version-specific mappings and validation:

HIPAA_5010_278_to_PAS_2_0_1_FHIR_R4.ofd
HIPAA_5010_278_to_PAS_2_1_0_FHIR_R4.ofd
HIPAA_5010_278_to_PAS_2_2_1_FHIR_R4.ofd

HIPAA_5010_278RES_to_PAS_2_0_1_FHIR_R4.ofd
HIPAA_5010_278RES_to_PAS_2_1_0_FHIR_R4.ofd
HIPAA_5010_278RES_to_PAS_2_2_1_FHIR_R4.ofd

Each mapping should be validated against its matching IG package:

hl7.fhir.us.davinci-pas#2.0.1
hl7.fhir.us.davinci-pas#2.1.0
hl7.fhir.us.davinci-pas#2.2.1

The generated documentation should state:

• PAS version
• FHIR version
• validator used
• IG package version
• validation date
• known warnings, if any
• whether the output is PAS-conformant or PAS-profiled

The distinction matters: PAS-conformant means the output passes validation against the selected PAS IG package with no errors, while PAS-profiled means it declares and targets the PAS profiles but may still carry warnings or unresolved terminology bindings.

That discipline prevents a common implementation failure: building for one PAS version and validating against another.

What Should a Demo Page Show?

For a public PAS demo, simplicity matters.

The main demo should not force every visitor to understand PAS version history before trying the tool. A good default is:

Default: CMS-listed Da Vinci PAS version, starting with PAS 2.0.1

Then an advanced option can expose version selection:

PAS version:
- CMS baseline:         PAS 2.0.1
- CMS-listed newer path: PAS 2.1.0
- Latest HL7 published:  PAS 2.2.1

For marketing copy, avoid saying "supports all PAS versions" unless every version has a dedicated mapping and validation package. Better:

Redix supports version-aware X12 278 to FHIR PAS conversion. Because CMS and HL7 version references evolve, Redix treats PAS mappings as version-specific artifacts and validates generated FHIR against the selected Da Vinci PAS IG package.

How Redix Helps

Redix helps payers bridge X12 278 infrastructure and FHIR prior authorization APIs without pretending that every PAS version is the same.

The Redix approach:

• convert X12 278 request and response transactions to FHIR PAS structures
• evaluate reverse FHIR PAS to X12 278 conversion for downstream EDI systems through private technical review or deployment planning
• maintain version-specific mappings
• validate generated FHIR against the selected PAS IG package
• preserve traceability from source X12 segments to generated FHIR resources
• support deployment in environments where PHI must remain under payer control

For organizations preparing for CMS-0057-F, the most important question is not simply whether a converter can produce FHIR. The question is whether it can produce the right FHIR for the right PAS version, and prove it with validation evidence.

Key Takeaways

• CMS-0057-F is the regulatory driver; Da Vinci PAS is the technical FHIR implementation guide.
• CMS currently lists PAS 2.0.1 and 2.1.0 for the Prior Authorization API.
• HL7 currently publishes PAS 2.2.1 as the current version.
• A payload can be valid FHIR R4 and still fail PAS validation.
• PAS mappings should be version-specific, not generic.
• Every customer-facing sample should state the PAS version and validator package used.
• Redix recommends starting with CMS-listed PAS versions for CMS-0057-F work, while tracking the latest HL7 publication for forward-looking implementations.

Frequently Asked Questions

References

• CMS: Application Programming Interfaces and Relevant Standards and Implementation Guides
• CMS: Interoperability and Prior Authorization Final Rule (CMS-0057-F)
• HL7: Da Vinci Prior Authorization Support (PAS) FHIR IG
• Redix: X12 278 vs FHIR PAS - Why Payers Need Both
• Redix CMS PAS Compliance Suite