Coverage Requirements Discovery (CRD) Testing

Coverage Requirements Discovery (CRD)Testing with Operon

Operon exposes CDS Hooks services for provider EHR systems so that prior-authorization requirements surface at order-entry or order-sign time. We orchestrate the underlying coverage and policy decision across the plan's UM and benefits systems and return a conformant CDS card.

Da Vinci CRD IG v2.0.1 / v2.1.0 / v2.2.1 concurrentAvailable for TestingLast Verified 2026-05-10
Capability Matrix

What You Can Test with Us

Operon's Coverage Requirements Discovery (CRD) capability surface vs Da Vinci CRD IG v2.0.1 / v2.1.0 / v2.2.1 concurrent. Verified 2026-05-10.

Operon Coverage Requirements Discovery (CRD) capability matrix vs Da Vinci CRD IG v2.0.1 / v2.1.0 / v2.2.1 concurrent
ResourceProfileReadSearchWriteNotes
order-selectDa Vinci CRD CDS HookYesNoNoFires as a clinician selects an order
order-signDa Vinci CRD CDS HookYesNoNoFires at order-sign time
appointment-bookDa Vinci CRD CDS HookYesNoNoFires at appointment booking
CDS CardDa Vinci CRD CardYesNoNoResponse from a hook invocation
Conformance Basis

Implementation Guide Conformance

Primary IG

Da Vinci CRD IG v2.0.1 / v2.1.0 / v2.2.1 concurrent ↗Last verified 2026-05-10

Companion IGs

Authentication

OAuth 2.0 client-credentials flow between provider EHR and the plan CDS service. CDS Hooks 1.0 + SMART discovery model.

Supported FHIR Operations

  • GET /cds-services
  • POST /cds-services/{service-id}

Operon publishes a CapabilityStatement aligned to Da Vinci CRD IG. The current version ships in the Operon CMS-0057-F Testing Spec; a hosted metadata endpoint follows in v2.

Testing Scenarios

Anchor Scenarios

The exact paths your testing partners hit. Each scenario maps to a concrete request shape, expected response, conformance checkpoints, and the readiness metric Operon emits.

Scenario 1

Pre-PA notification on order entry

Trigger
Provider EHR fires order-select for a service that may require PA
Request
POST /cds-services/{service-id} with hook payload (patient, practitioner, draft order)
Expected response
CDS Card recommending PA submission with the required data set
Conformance checkpoints
  • Da Vinci CRD card profile validity
  • PA-required signal accuracy
  • Service discovery includes the invoked hook
Readiness metric emitted
CRD signal accuracy

Scenario 2

DTR launch link in CRD card

Trigger
CDS Card on order-sign includes a DTR launch link
Request
POST /cds-services/{service-id} for order-sign hook
Expected response
CDS Card with link of type "smart" to launch DTR with pre-populated context
Conformance checkpoints
  • Link type "smart" present
  • SMART launch context resolves to a valid DTR Questionnaire
Readiness metric emitted
CRD-to-DTR handoff success rate

Scenario 3

Coverage-not-required signal

Trigger
Order does not require PA under current member coverage
Request
POST /cds-services/{service-id} for order-select hook
Expected response
CDS Card or empty response indicating no action required
Conformance checkpoints
  • Negative signal correctly returned
  • Member coverage lookup latency within budget
Readiness metric emitted
CRD signal accuracy
Sample Data

Sample Bundles

What's Provisioned

Six representative order scenarios spanning medical, pharmacy, and behavioral health categories. Each scenario covers a member in good standing and exercises both the 'PA required' and 'PA not required' decision paths.

Sample bundle excerpts are included in the Operon CMS-0057-F Testing Spec PDF. Full bundles are loaded into your sandbox tenant when your testing window is provisioned.

How It Works

How a Testing Window Works for Coverage Requirements Discovery (CRD)

Step 1

Intake

Submit org type, role, this API selection, target window, and system-of-record context.

Step 2

Sandbox Tenant + Kickoff

Provisioned within 2 business days; 60-minute joint kickoff confirms scenarios, conformance targets, and success criteria.

Step 3

Testing Window + Report

1 to 4 weeks of live testing with daily conformance and latency telemetry, ending in a public-reporting-ready conformance and readiness report.

What You Get

Measurement Output

End-of-Engagement Report

Per-scenario conformance vs the Da Vinci CRD IG, hook response latency distribution, CRD-to-DTR handoff verification, and a CDS Card profile validation report.

Readiness Metrics Emitted

  • CRD signal accuracy: Percent of CDS Card responses whose PA-required signal matches the plan UM policy for the order in question.
  • Hook response latency: p50 / p95 wall-clock time from CDS Hook invocation to CDS Card response.
  • CRD-to-DTR handoff success rate: Percent of CDS Cards with DTR launch links that resolve to a valid pre-populated Questionnaire.
Related APIs

The Other CMS-0057-F APIs

Da Vinci PDex Provider Access IG latest published

Provider Access API

Providers under attribution agreement pull clinical, claims, and encounter data via group-based bulk export.

View Provider Access API Details →

Da Vinci PDex Payer-to-Payer IG latest published

Payer-to-Payer API

Concurrent and prior payers exchange member historical data via $member-match and historical bundle handoff.

View Payer-to-Payer API Details →

Da Vinci PAS IG latest published

Prior Authorization API

Plans and providers submit, inquire, and act on PA decisions across UM vendors and internal review queues.

View Prior Authorization API Details →

Da Vinci DTR IG v2.0.1 / v2.1.0 / v2.2.0 concurrent (Standard + Adaptive)

Document Templates and Rules (DTR)

Plans expose payer-defined Questionnaires (Standard and Adaptive) that the provider EHR can launch from a CRD card, pre-populate from clinical data, and attach to the subsequent PA Claim.

View Document Templates and Rules (DTR) Details →
Ready to Test

Schedule a Coverage Requirements Discovery (CRD) Testing Window

30 minutes with our team. We'll ask about the systems you already run, where you are on the CMS-0057-F calendar, and what testing you need to ship.