Coverage Requirements Discovery (CRD) and Payer Data Exchange (PDex) are two Da Vinci IGs that sometimes get confused in early CMS-0057-F planning conversations. They serve different workflows, target different consumers, and shape different vendor capabilities. Understanding which IG drives which workflow matters for vendor selection, integration architecture, and operational design. For more on Da Vinci IGs in practice coverage, this is the clarifying comparison.
What CRD Actually Does
Coverage Requirements Discovery is the order-time decision support IG. When a clinician initiates an order (medication, procedure, imaging, referral) inside the EHR, the EHR fires a CDS Hook to the payer's CRD service. The CRD service evaluates the order against the payer's coverage rules and returns a CDS card with information: is PA required, what documentation is needed, what comes next.
The consumer is the clinician at the moment of decision. The trigger is the EHR workflow event. The output is decision-support information rendered inline.
What PDex Actually Does
Payer Data Exchange is the clinical data exchange IG. When a consumer (member-facing app, provider EHR, receiving payer) wants the payer's clinical data about a member, the FHIR API exposes PDex-conformant resources. PDex profiles cover Condition, Observation, MedicationStatement, Procedure, AllergyIntolerance, and related clinical resources.
The consumer is any authorized FHIR consumer (members through SMART apps, providers through Provider Access, other payers through Payer-to-Payer). The trigger is a FHIR REST request. The output is structured clinical data.
The Workflow Boundary
CRD operates at the moment of clinical decision. PDex operates at the moment of data retrieval. They are not in conflict; they serve different parts of the larger CMS-0057-F surface.
A clinician ordering a procedure encounters CRD first (the CDS card tells them whether PA is required). The PA decision triggers DTR (rendering the payer's questionnaire) and PAS (submission). If clinical data from the payer is needed during the decision, the EHR can call PDex-conformant Patient Access endpoints. CRD is the trigger; PDex provides the data layer when needed.
Where the Confusion Comes From
Both IGs deal with payer-provider data exchange in some sense. Both reference shared HRex resources. Both can include Coverage resources. A vendor showcasing FHIR capabilities might describe their work as covering both CRD and PDex without making the workflow distinction clear.
The clarifying question: does the IG fire at the moment of a clinical event (CRD) or does the IG describe how data is requested and returned (PDex). Once that distinction lands, the rest is straightforward.
How Vendors Position These IGs
Vendors with strong CDS Hooks support tend to emphasize CRD. The CDS Hooks layer is the integration surface for CRD; vendors that build well on it can deliver CRD reliably.
Vendors with strong FHIR data platforms tend to emphasize PDex. The clinical resource profiles, the Patient Access infrastructure, and the broader FHIR data layer all benefit from PDex conformance.
A complete CMS-0057-F deployment requires both. Vendors that can demonstrate both strengths are stronger candidates than vendors strong in only one.
What Production Implementations Combine
Production CMS-0057-F deployments use both IGs together in specific patterns. CRD fires at order entry, triggering the ePA workflow. DTR renders the questionnaire. PAS handles submission. The PA decision flows back to Patient Access using PDex profiles (since the Patient Access representation is PDex-conformant for clinical context).
The two IGs are complementary across the workflow. A clinician's order produces both a CRD interaction (decision support) and downstream PDex data (the resulting clinical record that Patient Access exposes).
How HRex Fits Into Both
Both CRD and PDex reference Health Record Exchange (HRex) for foundation profiles and patterns. The Coverage profile that appears in both IGs is HRex-defined. The Patient profile that anchors both is HRex-aligned. Understanding HRex helps see how the two IGs share infrastructure even though they serve different workflows.
For HRex-specific use cases in payer implementations, the Top 5 Da Vinci HRex use cases for payer implementations covers the foundation layer. For the broader Da Vinci IG portfolio that includes both CRD and PDex among others, the Top 6 Da Vinci IGs every health plan should track in 2026 covers the priority list.