Da Vinci PAS submissions are FHIR Bundles with specific structural requirements: the right profiles, the right resource relationships, the right value-set bindings, the right attachments. Bundles that violate any of these get rejected by the payer endpoint, often with cryptic error messages that the provider EHR team has to debug. Pre-production validation tools catch these issues before they reach the payer. Five tools cover the validation surface well in 2026. For Da Vinci implementation patterns coverage, these are the practical tools.
1. FHIR Validator (HL7 Reference)
The HL7-maintained FHIR Validator is the conformance baseline. It validates a FHIR resource (or Bundle) against the specified profiles, checks structural conformance, runs invariant constraints, and reports violations. The validator handles Da Vinci PAS Bundle profiles natively when the right IG packages are loaded.
The pattern is to integrate the validator into the EHR or provider-side build process: every PAS Bundle generated runs through validation before submission. Bundles that fail validation get fixed (or the generation logic gets fixed) rather than producing rejected submissions.
2. Inferno PAS Test Suite
Inferno's PAS-specific test suite tests submissions against a target PAS endpoint. The pattern is to run Inferno during pre-production testing, with the EHR-side submission logic targeting the payer's pre-prod PAS endpoint. The tests verify that both sides handle the spec correctly.
For payers and EHR vendors building PAS integrations, Inferno PAS tests are the explicit conformance gate before going live.
3. Firely Java Validator
The Firely Java Validator is a high-performance FHIR validator that integrates well with Java-based EHR and payer platforms. It supports all the standard FHIR profile and IG validation patterns, with performance suitable for inline validation (running validation at submission time without significant latency impact).
For Java-based stacks, Firely Java Validator often performs better than the HL7 reference validator at scale.
4. Smile CDR's Built-In Validation
Payers using Smile CDR as the PAS endpoint get profile validation built into the platform. Incoming Bundles are validated against Da Vinci PAS profiles automatically, with rejection responses that include specific constraint violations. The provider-side EHR team gets actionable error messages rather than generic 4xx responses.
The pattern fits the broader Smile CDR architecture. For payers running other platforms, the equivalent validation has to be wired up separately or sourced from third-party tools.
5. Custom Validation Pipelines for High-Volume Implementations
A pattern that wraps standard validators with implementation-specific checks. The standard validator handles FHIR and IG conformance; custom logic adds business rules (the payer's clinical criteria, formatting requirements specific to their UM system, attachment validation against their internal standards).
The pattern is necessary at production scale because spec conformance and operational acceptance are not the same thing. A Bundle that passes spec validation may still fail at the UM system if the clinical content does not meet the payer's review criteria. Validation pipelines catch the operational rejections before submission.
What PAS Validation Actually Has to Check
A comprehensive PAS validation pipeline checks: structural conformance (Bundle profile, required resources, resource relationships), value-set bindings (correct codes from required code systems), invariant constraints (FHIRPath expressions that must evaluate true), attachment integrity (referenced attachments exist and parse), and clinical-content adequacy (the documentation answers the questionnaire's questions).
Tools cover these dimensions at varying depths. The HL7 validator handles structural conformance well; clinical-content adequacy typically requires custom logic.
How Provider-Side EHR Teams Should Integrate Validation
The pattern that works for EHR teams building PAS integration is to validate at three points. At the DTR app boundary: validate the Bundle the DTR app produces. At the submission boundary: validate immediately before sending to the payer's PAS endpoint. At the response boundary: validate the response Bundle the payer returns.
This three-point validation catches issues at the earliest possible point in the workflow, reducing the rejection-and-rework cycles that frustrate clinicians.
For the broader Inferno conformance patterns that wrap PAS validation into the larger CMS-0057-F testing picture, the Top 5 Inferno conformance patterns for Da Vinci implementations covers the testing layer. For implementation mistakes specific to Da Vinci IGs that validation alone does not catch, the 5 Da Vinci IG implementation mistakes to avoid in 2026 covers the field-tested failure modes.