Health Record Exchange (HRex) is the Da Vinci foundation IG that other Da Vinci IGs build on. Most payer implementations engage with HRex through the IGs that reference it (PDex, PAS, CRD) rather than directly. But HRex shapes how those IGs work, and understanding the HRex use cases helps explain why certain patterns appear across the Da Vinci portfolio. Five HRex use cases worth understanding for payer implementations. For the Da Vinci ecosystem hub coverage, these are the foundation-layer patterns.
1. Coverage Resource Profile Across IGs
The Coverage resource is one of the most consistently-used HRex profiles across Da Vinci IGs. CRD uses it for coverage-context information. PDex uses it for the active coverage details. PAS uses it as part of the submission Bundle. Payer-to-Payer uses it during Member Match and the actual data transfer.
The HRex Coverage profile defines a baseline that the other IGs extend or constrain. Payer implementations that get the HRex Coverage profile right have a consistent foundation across multiple IGs.
2. Patient Resource Cross-IG Alignment
Patient is another HRex foundation profile that other IGs build on. The HRex Patient definition specifies identifier patterns, demographic data structure, and links to Coverage. PDex Patient inherits from HRex Patient. PAS Patient does too. The cross-IG consistency depends on the HRex foundation.
Payer implementations that diverge from the HRex Patient profile produce IG-specific Patient representations that complicate the data layer. Implementations that align with HRex produce consistent Patient resources across all CMS-0057-F APIs.
3. Provider and Organization Resource Foundation
HRex defines Practitioner, PractitionerRole, and Organization profiles that the provider-directory and clinical-content IGs build on. PDex Plan Net (the Provider Directory layer) extends these profiles. PAS references them when capturing the requesting provider.
The HRex foundation matters because provider identity has to be consistent across CMS-0057-F APIs. A provider appearing in the Patient Access claims should match the provider in the Provider Directory and the provider in PAS submissions.
4. Task Resource for Workflow Tracking
Da Vinci IGs use the FHIR Task resource extensively for tracking workflow state. CRD interactions can produce Tasks. PAS submissions create Tasks. The PA decision lifecycle is often tracked through Task status transitions. HRex provides the Task profile baseline.
Payer implementations that use Task consistently across the workflow have unified state tracking and audit trails. Implementations that ignore Task or use it inconsistently end up with custom state-tracking logic that diverges from the Da Vinci patterns.
5. Provenance for Audit Across Cross-Vendor Data Flows
HRex includes Provenance profile patterns for tracking the origin and transformation of FHIR resources. When data flows from a payer's source system into the FHIR store, then out to a Patient Access consumer, then potentially into another payer through Payer-to-Payer Data Exchange, the Provenance chain documents the journey.
For audit defensibility under CMS-0057-F regulatory scrutiny, Provenance is the resource that answers "where did this data come from and what happened to it." Production-grade implementations use Provenance liberally; minimal implementations skip it and struggle when audit questions arise.
How HRex Affects Payer Implementation Strategy
The pattern that emerges from these five use cases: HRex is the layer that determines how consistently the higher Da Vinci IGs work together. Payer implementations that understand HRex (and design their data layer to align with HRex foundations) get cross-IG consistency. Implementations that treat each higher IG independently produce internal inconsistencies that surface during integration testing.
For payer engineering teams, the practical advice is to read the HRex IG even though most implementation work targets the higher IGs. Understanding the foundation prevents foundation-level inconsistencies.
How HRex Evolves and What That Means for Implementations
HRex versions follow the standard HL7 STU progression. New versions sometimes add profile elements, sometimes refine value-set bindings, sometimes adjust invariants. Payer implementations that track HRex changes ahead of their adoption in higher IGs have time to plan; implementations that wait for the higher IG to surface HRex changes encounter them as integration surprises.
For the broader Da Vinci IG portfolio that builds on HRex, the Top 6 Da Vinci IGs every health plan should track in 2026 covers the priority list. For the specific CRD-vs-PDex workflow distinction that HRex foundation supports, the Da Vinci CRD vs PDex comparison covers the workflow boundary.