MOPA — Medical Oncology Prior Authorization - Local Development build (v0.1.1-snapshot-080926) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Home
This implementation guide defines the Medical Oncology Prior Authorization (MOPA) framework.
It is intentionally informative: it documents the oncology PA workflow, the gaps in Da Vinci
CRD/DTR/PAS and mCODE, and the upstream proposals needed to close those gaps.
A FHIR Accelerator Program implementation guide
extending Da Vinci CRD / DTR / PAS for oncology prior authorization
The Problem
Getting cancer treatment approved takes too long. For patients with breast cancer and other
oncology diagnoses, prior authorization is fragmented, slow, and disconnected from the clinical
evidence that guided the treatment decision. There is no shared, standards-based language for
oncology treatment decisions and no common way to move the right clinical data from the point of
care to the authorization system at the right moment.
The regulatory pressure is now direct. CMS-0062-P (April 2026) extends prior authorization
requirements to prescription drugs — including chemotherapeutics and anti-cancer agents.
The Framework
This IG defines a structured authorization exchange using the standard Da Vinci CRD workflow
where the payer CRD service uses FHIR authorization (when provided) to query the EHR for
required oncology patient context (diagnosis, staging, biomarkers, line of therapy) directly.
The workflow uses two CDS Hooks stages:
order-select (informational) — the CRD service evaluates approvability and returns
advisory cards before the provider signs the order
order-sign (final determination) — the CRD service returns the binding coverage
determination
For the upstream standards work items, see:
Scope
In scope:
- All oncology cancer types (solid tumors and hematologic malignancies)
- Anti-cancer regimen representation as a first-class FHIR artifact
- Standard Da Vinci CRD workflow for oncology — payer queries EHR FHIR API for required context
- Patient context data categories for oncology PA evaluation
- Use Case 1: Breast cancer prior authorization — the first concrete data requirements
implementation, serving as the template for other cancer types
Out of scope (this version):
- Coverage adjudication and benefit determination — whether a treatment is covered is a payer decision; this IG delivers the structured request, not the decision logic
- Post-denial workflows — appeals, grievances, and peer-to-peer review processes
- Regimen clinical equivalence and preference ranking — comparative effectiveness of treatment options is a clinical decision support concern outside authorization exchange
- Dose calculation and modification rules — weight-based dosing, renal/hepatic adjustments, and toxicity-driven modifications are out of scope
- Pharmacy benefit management (PBM) integration — specialty pharmacy routing, formulary lookups, and drug pricing are not addressed
- Radiation therapy and surgical procedure authorization — this version covers anti-cancer drug regimens only
- X12 transaction details — EDI mapping is delegated to Da Vinci PAS
- Clinical trial eligibility matching — protocol screening and trial enrollment are outside the authorization workflow modeled here
Stakeholders
| Stakeholder |
Benefit |
| Oncology Practice / Clinician |
Clinical guideline-aligned recommendations surface at the moment of ordering — structuring the treatment decision in a way that moves through authorization without friction |
| Cancer Patient |
Clinical guideline-appropriate treatment is authorized faster because the clinical evidence supporting the decision arrives at the payer in a structured, computable form |
| Health Plan / Payer |
Authorization requests carry the structured clinical evidence — diagnosis, staging, biomarkers, line of therapy — that coverage policy requires, enabling consistent, evidence-grounded determinations |
| EHR / Ordering System |
A single conformant integration delivers clinical guideline-aligned CDS and structured authorization requests across all payers and cancer types, replacing fragmented per-payer builds |
| Clinical Guideline Authority |
Computable regimen definitions flow directly from publication into clinical decision support and payer coverage evaluation — creating a traceable path from evidence to real-world treatment authorization |
Dependencies
| Implementation Guide |
Version |
Role |
| US Core |
7.0.0 |
Base US patient, practitioner, and clinical data profiles |
| mCODE |
4.0.0 |
Oncology clinical data foundation |
| Da Vinci CRD |
2.2.1 |
Coverage Requirements Discovery workflow backbone |
| Da Vinci DTR |
2.2.0 |
Documentation Templates and Rules |
| Da Vinci PAS |
2.2.1 |
Prior Authorization Support |
How to Read This Guide
- Background — Clinical problem, regulatory context, and gaps in existing standards
- Use Cases and Actors — The workflow, system actors, and actor responsibilities
- Da Vinci Gap Proposals — CRD, DTR, and PAS proposals derived from the gap analysis
- mCODE Gap Proposals — Data model proposals derived from the gap analysis
- Specification:
- Regimen Modeling — How anti-cancer regimens are represented as FHIR
PlanDefinition and RequestGroup
- CRD Workflow — How the payer CRD service queries the EHR FHIR API for oncology context
- Data Requirements — The oncology data categories queried during CRD evaluation
- Breast Cancer PA — Breast cancer-specific data requirements and gap analysis
- Conformance — Requirements for claiming conformance to this IG
- Artifacts — All profiles, extensions, value sets, and examples
This publication includes IP covered under the following statements.
- ISO maintains the copyright on the country codes, and controls its use carefully. For further details see the ISO 3166 web page: https://www.iso.org/iso-3166-country-codes.html
Show Usage
- ISO 3166-1 Codes for the representation of names of countries and their subdivisions — Part 1: Country code: AntiCancerRegimenPlanDefinition, AntiCancerRegimenRequestGroup... Show 14 more, DataRequirementLabel, LineOfTherapyRequestCategory, MOPAIG, OcpaCodesCS, OcpaCrdClientCapabilityStatement, OcpaCrdServiceCapabilityStatement, RegimenDaysOfCycle, RegimenDdACT, RegimenIntentVS, RegimenPHD, RegimenTH, TreatmentIntentRequestCategory, TreatmentLineCS and TreatmentLineVS
- This material contains content that is copyright of SNOMED International. Implementers of these specifications must have the appropriate SNOMED CT Affiliate license - for more information contact https://www.snomed.org/get-snomed or info@snomed.org.
Show Usage
- SNOMED Clinical Terms® (SNOMED CT®): Bundle/ExampleOrderSelectBundle, Bundle/ExampleOrderSignBundle... Show 10 more, Condition/MOPABreastCancerConditionExample, Condition/MOPAMetastaticBreastCancerConditionExample, RegimenDdACT, RegimenIntentVS, RegimenPHD, RegimenTH, RequestGroup/DDACTRegimenOrder, RequestGroup/PHDRegimenOrder, RequestGroup/THRegimenOrder and TreatmentIntentRequestCategory
- This material derives from the HL7 Terminology (THO). THO is copyright ©1989+ Health Level Seven International and is made available under the CC0 designation. For more licensing information see: https://terminology.hl7.org/license.html
Show Usage
- Using RxNorm codes of type SAB=RXNORM as this specification describes does not require a UMLS license. Access to the full set of RxNorm definitions, and/or additional use of other RxNorm structures and information requires a UMLS license. The use of RxNorm in this specification is pursuant to HL7's status as a licensee of the NLM UMLS. HL7's license does not convey the right to use RxNorm to any users of this specification; implementers must acquire a license to use RxNorm in their own right.
Show Usage