Patient Access API Testing

Patient Access APITesting with Operon

Operon aggregates member-facing data across UM, claims, member, and clinical systems, and exposes it as conformant FHIR responses to authorized member apps.

CARIN BB IG v2.0.0Available for TestingLast Verified 2026-05-10
Capability Matrix

What You Can Test with Us

Operon's Patient Access API capability surface vs CARIN BB IG v2.0.0. Verified 2026-05-10.

Operon Patient Access API capability matrix vs CARIN BB IG v2.0.0
ResourceProfileReadSearchWriteNotes
PatientUS Core PatientYesYesNo
CoverageCARIN BB CoverageYesYesNo
ExplanationOfBenefitCARIN BB EOB Inpatient/Outpatient/Pharmacy/ProfessionalYesYesNoMulti-system aggregation
EncounterUS Core EncounterYesYesNo
ConditionUS Core ConditionYesYesNo
MedicationRequestUS Core MedicationRequestYesYesNo
ObservationUS Core ObservationYesYesNo
AllergyIntoleranceUS Core AllergyIntoleranceYesYesNo
ProcedureUS Core ProcedureYesYesNo
DocumentReferenceUS Core DocumentReferenceYesYesNo
Conformance Basis

Implementation Guide Conformance

Primary IG

CARIN BB IG v2.0.0 ↗Last verified 2026-05-10

Companion IGs

Authentication

OAuth 2.0 with SMART-on-FHIR launch, member consent, scoped access tokens.

Supported FHIR Operations

  • GET /Patient/{id}
  • GET /Coverage?patient={id}
  • GET /ExplanationOfBenefit?patient={id}
  • GET /Encounter?patient={id}
  • GET /Condition?patient={id}
  • GET /MedicationRequest?patient={id}
  • GET /Observation?patient={id}
  • GET /AllergyIntolerance?patient={id}
  • GET /Procedure?patient={id}
  • GET /DocumentReference?patient={id}

Operon publishes a CapabilityStatement aligned to CARIN BB 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

Member onboarding refresh

Trigger
New member app authorization with full-history consent
Request
Bulk read of Patient + Coverage + last-24mo EOBs and clinical resources
Expected response
Bundle of CARIN BB + US Core resources, paginated
Conformance checkpoints
  • CARIN BB profile validation
  • US Core element coverage
  • Pagination link integrity
Readiness metric emitted
USCDI v3 element coverage

Scenario 2

24-month claims pull

Trigger
Authorized app requests historical EOBs
Request
GET ExplanationOfBenefit?patient={id}&_lastUpdated=ge{24mo-ago}
Expected response
Paginated EOB Bundle across underlying claims systems
Conformance checkpoints
  • Cross-system provenance present on every entry
  • CARIN BB EOB profile per claim type
Readiness metric emitted
Multi-system provenance %

Scenario 3

EOB delta since last sync

Trigger
App previously synced; requests delta
Request
GET ExplanationOfBenefit?patient={id}&_lastUpdated=gt{last-sync}
Expected response
Delta Bundle with stable IDs across systems
Conformance checkpoints
  • ID stability
  • _lastUpdated correctness
Readiness metric emitted
Response freshness

Scenario 4

Consent revocation

Trigger
Member revokes consent in member portal
Request
Subsequent app token-refresh attempt
Expected response
401 with conformant OAuth error
Conformance checkpoints
  • Token invalidation propagation
  • Audit trail on revocation
Readiness metric emitted
Consent-revocation propagation latency
Sample Data

Sample Bundles

What's Provisioned

Four representative members spanning Medicare Advantage, commercial, and Medicaid lines, each with 24 months of claims and clinical data sourced from at least two underlying systems.

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 Patient Access API

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 pass/fail vs CARIN BB and US Core, latency p50/p95/p99, error taxonomy aligned to FHIR OperationOutcome severity codes, and a USCDI v3 coverage report.

Readiness Metrics Emitted

  • Response freshness: Median age of returned data vs source-of-truth update time.
  • Multi-system provenance %: Share of responses where Operon attributes each resource to a specific underlying system.
  • USCDI v3 element coverage: Percent of USCDI v3 data classes/elements present in returned bundles per scenario.
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 CRD IG v2.0.1 / v2.1.0 / v2.2.1 concurrent

Coverage Requirements Discovery (CRD)

Plans expose CDS Hooks services so a provider EHR can surface prior-authorization requirements at order entry or order-sign time, before the claim is submitted.

View Coverage Requirements Discovery (CRD) 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 Patient Access API 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.