Da Vinci Payer Data Exchange
2.1.1 - STU 2.1

Da Vinci Payer Data Exchange, published by HL7 International / Financial Management. This guide is not an authorized publication; it is the continuous build for version 2.1.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-epdx/ and changes regularly. See the Directory of published versions

Plain Language Summary goes here

## Home

Official URL: http://hl7.org/fhir/us/davinci-pdex/ImplementationGuide/hl7.fhir.us.davinci-pdex | Version: 2.1.1
IG Standards status: Trial-use | Maturity Level: 2 | Computable Name: DaVinciPayerDataExchange
Copyright/Legal: Used by permission of HL7 International, all rights reserved Creative Commons License

This page has been updated to reflect the release of the CMS Prior Authorization Rule (CMS-0057) in 2024. The guide has also been updated to support the adoption of US Core 6.1.0, in addition to existing support for US Core 3.1.1 and support for US Core 7.0.0. This change is implemented to enable implementers to comply with both the CMS-0057 Rule and the ONC's HTI-1 rule that implements US Core 6.1.0 as the base standard of US Core as of January 1, 2026.

# In this PDex version

The PDex work group has made changes to the original version of the IG following the publication of the final CMS Interoperability and Patient Access Rule (CMS-9115) and the subsequent Advancing Interoperability and Improving Prior Authorization Rule (CMS-0057).

The STU 2.1 version of the IG incorporates changes to support the sharing of Prior Authorization information with members, providers and other payers. This is done through the profiling of the ExplanationOfBenefit resource. This version of the Implementation guide also introduces two Bulk APIs that enable the data available through the Patient Access API to also be made available to In-Network/Contracted Providers and other Health Plans through the Provider Access API and the Payer-to-Payer Bulk API.

CMS Guidance defines two sets of data to be made available by payers in the Patient Access API: Claims and Encounter Data and Clinical data. They provide links to specific implementations guides for the Patient Access API to provide guidance. Use of these implementation guides is not required but is recommended. If used these guides will provide information payers can employ to meet the requirements of the policies being finalized. The CARIN Consumer Directed Payer Data Exchange IG (CARIN IG for Blue Button®) defines how Claims and Encounter Data are to be provided; This Da Vinci Payer Data Exchange IG (PDex) and the US Core 3.1.1 IG, US Core 6.1.0 IG or US Core 7.0.0 IG define how Clinical Data is to be provided.

This version of the Implementation Guide introduces support for US Core 7.0.0 IG. Since the IG embraces US Core the support for US Core 7.0.0 is similar to the support for US Core 6.1.0 which required minimal changes to the PDex IG. Throughout this IG references to US Core 6.1.0 can also be interpreted as supporting US Core 7.0.0 which is expected to supercede US Core 6.1.0 in 2028.

### Continuing Standards Evolution

This IG recognizes that the healthcare industry is rapidly evolving methods, such as TEFCA, to enable the secure exchange of information between Providers and Payers and between payers. Incorporating prescriptive definitions for connecting, registering and authorizing access to the Provider Access or Payer-to-Payer API risks complicating the adoption of solutions that will enable secure exchange of data, at scale. Health Plans implementing the Da Vinci guides that address the CMS Prior Authorization Rule (Payer Data Exchange, Coverage Requirements Discovery, Documents templates and Rules and Prior Authorization Support) are urged to continue to engage with their respective work groups in order to be aware of ongoing developments and emergent implementation approaches, as the industry works to evolve methods that will enable adoption of these Interoperability Standards at scale. Developments are to be expected in the area of automated registration and access to the secure APIs documented in these IGs.

### Background

There are two parallel paths pursued by the CARIN Alliance (Creating Access to Real-time Information) and the Da Vinci Project related to providing health plan data to various stakeholders. CARIN Alliance approaches the issue primarily from a financial (claims) perspective, with some limited associated clinical data. The Da Vinci Project approaches the issue primarily from a clinical perspective and leaves financial data out of scope.

The CARIN Alliance focused on replicating the CMS Blue Button 2.0 solution directed at providing beneficiaries access to claims information for Medicare Fee For Service (FFS) in the form of a FHIR based ExplanationOfBenefit (EOB). The CARIN Alliance Consumer-Directed Payer Data Exchange (CARIN IG for Blue Button®) solution was intended to provide the same information based on commercial payer databases, at least for Medicare Advantage products. The CMS Interoperability and Patient Access Final Rule expanded the scope of a Blue Button 2.0 equivalent to include not just Medicare Advantage but also Medicaid HMO, CHIP HMO and QHP's in the federal marketplace.

The Da Vinci Payer Data Exchange (PDex) solution started with the goal of providing payer sourced information to providers in the form of FHIR resources consistent with US Core profiles for FHIR Release 4 (R4). The CMS Interoperability Final Rule directs covered payers (as noted above) to make Encounter and Clinical data available to members through an API (defined by the ONC 21st Century Cures Act Final Rule) for, at a minimum, information defined in USCDI release 1.1. Since PDex was already focused on making the same information available through a compliant API, Da Vinci expanded the scope of PDex to include not only payer to provider exchange at the request of the provider but also payer to third party application exchange at the request of the member.

In addition, the CMS Interoperability Final Rule requires a covered plan, at the member’s request, to make their information (as defined by USCDI release 1.1), at a minimum available to any other plan as directed by the member. This ability must exist for up to 5 years after the member leaves the plan. Da Vinci expanded the scope of the PDex Implementation Guide to support this exchange. This aspect of the CMS-9115 Interoperability and Patient Access Rule was never enforced. However, in the following Prior Authorization Rule (CMS-0057) CMS requires Payers to enable Payers to perform a Payer-to-Payer exchange of data for opted-in and matched members that have moved to a new plan from a regulated health plan.

At this point we have two solutions that provide an overlapping but different set of information for the members of a health plan. The first is the CARIN IG for Blue Button® which is focused on providing claims information, including the adjudication information, in the form of a FHIR ExplanationOfBenefit (EOB). The second solution is to provide all payer information related to the clinical condition and care of the patient using US Core profiles on FHIR R4 resources. In the latter case, USCDI information coming from claims is represented as US Core resources and includes, at a minimum: encounters, providers, organizations, locations, dates of service, diagnoses (conditions), procedures and observations. This information would also include clinical information from sources other than claims maintained by the payer, such as:

1. Laboratory results received via HL7 V2 ORU transactions,
2. Clinical data from HL7 consolidated CDAs,
3. Information derived from HL7 V2 ADT transactions,
4. Information received or extracted from immunization registries,
5. Information related to medication administration from pharmacy benefit managers in pharmacy networks,
6. FHIR resources, and any other source of clinical information related to the member.

Unlike the US Core 3.1.1 IG or US Core 6.1.0 IG, PDex provides guidance to payers on how to make the following information available via the Patient Access API:

1. Provenance appropriate for payer data exchange (extended US Core Provenance)
2. Dispensed medications (not covered in US Core 3.1.1)
3. Medical devices that are not implantable devices (not covered in US Core)
4. Common Payer Consumer Data Set (CPCDS) to US Core and PDex profiles to satisfy the requirement for exchange of USCDI V1 information
5. Clinical data received by payers (e.g., laboratory results) from multiple sources (e.g., claims, HL7 V2, CDA) to the appropriate FHIR US Core and PDex profile data elements.

This IG uses the same Member Health History "payload" for member-authorized exchange of information with other Health Plans, in network providers and with Third-Party Applications. It describes the interaction patterns that, when followed, allow the various parties involved in managing healthcare and payer data to more easily integrate and exchange data securely and effectively.

This IG covers the exchange of:

- Claims-based information via clinical FHIR profiles, namely US Core plus payer-specific profiles for Device and MedicationDispense
- Clinical Information (such as Lab Results, Allergies and Conditions)

In support of the Prior Authorization Rule (CMS-0057) This IG adds support for Prior Authorizations and the supporting clinical information used in reaching a decision. This information iis added to the Patient Access API and is also available to In-Network Providers and other Payers through the Provider Access and Payer-to-Payer Bulk APIs.

This IG covers the exchange of this information using US Core and Da Vinci Health Record Exchange (HRex) Profiles. This superset of clinical profiles forms the Health Plan Member's Health History.

This IG covers the exchange of a Member's Health History in the following scenarios:

- Provider requested Provider-Health Plan Exchange using CDS-Hooks and SMART-on-FHIR
- Member-authorized Health Plan to Health Plan exchange
- Member-authorized Health Plan to Third-Party Application exchange

The latter two scenarios are provided to meet the requirements identified in the CMS Interoperability Notice for Proposed Rule Making issued on February 11, 2019. To meet the requirements of the CMS Prior Authorization Rule this IG adds two new APIs:

- Provider Access Bulk API
- Payer-to-Payer Bulk API

There are items in this guide that are subject to update. This includes:

- Value Sets
- Code Systems
- Examples.

See the Table of Contents for more information.

### Mapping Adjudicated Claims, Encounter and Prior Authorization Information

The Data Mapping section addresses the mapping of Claims and Encounter data to Clinical profiles. Some US Core profiles correlate with data provided in the Consumer-Directed Payer Data Exchange (Blue Button 2.0) IG. The Data Mapping section provides tables to assist implementers in mapping between these IGs.

With the CMS Prior Authorization Rule (CMS-0057) recommending the series of Da Vinci Burden Reduction Implementation Guides (Coverage Requirements Discovery, Documents Templates and Rules and Prior Authorization Support) it is expected that Payers will receive more clinical data from Providers. Much of that data will be in structured form, as defined by the US Core Implementation Guide. The Payer-to-Payer Bulk API also requires the exchange of unstructured data that supports a Prior Authorization decision. Such data would be embedded in a DocumentReference resource for exchange. This is likely to result in Payers having far more clinical data to exchange wih Members, Providers and other Payers.

The IG will continue to be tested at connectathons and will continue to utilize commonly adopted standards (e.g., US Core profiles) that have been tested by other groups (e.g., Argonaut). USCDI concepts are encapsulated in US Core Profiles on FHIR Resources. The Code Systems, Value Sets and codings used in this IG are based on US Core Profiles. Regardless of the way in which payers store their administrative and clinical information they will need to map it appropriately to these profiles.

In addition, we are creating a supplemental guide to provide more examples of how to populate the resources that are being exchanged based on the nature of the source information (e.g., lab results via V2 transactions, CDA, or claims).

### Endpoint Discovery

Implementers of this IG SHOULD support the endpoint discovery mechanism defined in the HRex specification to allow discovery of the endpoints used in this IG - specifically the following:

- Patient Access API.
- Provider Access API.
- Payer-to-Payer API (single member and multiple members).

### Intellectual Property Considerations

This HL7 specification contains and references intellectual property owned by third parties ("Third Party IP"). Implementers and testers of this specification SHALL abide by the license requirements for each terminology content artifact utilized within a functioning implementation. Terminology licenses SHALL be obtained from the Third-Party IP owner for each code system and/or other specified artifact used. It is the sole responsibility of each organization deploying or testing this specification to ensure their implementations comply with licensing requirements of each Third-Party IP.

This publication includes IP covered under the following statements.

- All X12 products are subject to this IP policy, including published and draft works.X12 is the only organization authorized to grant permission for use of X12 products. Users of all X12 products should make sure that they understand the permissible uses, as well as the limitations on such usage, as outlined below.Additional IP information can be found here Send an email to ip@x12.org to request permission to reproduce X12 IP. Include your name, organization, title, address, city, state, zip, email, a detailed description of the Submitted Artifact, including the underlying or cited X12 Product, and a detailed description of the intended audience and planned distribution method for the Artifact.Additional information on X12 licensing program can be found here To purchase code list subscriptions call (425) 562-2245 or email admin@wpc-edi.com.
  Show Usage
  - X12 Claim Adjustment Reason Codes: PdexPriorAuthorization and X12ClaimAdjustmentReasonCodesCMSRemittanceAdviceRemarkCodes
- All X12 work products are copyrighted. Any use of any X12 work product must be compliant with US Copyright laws and X12 Intellectual Property policies.Please see https://x12.org/products/licensing-program
  Show Usage
  - X12 Service Type Codes: ExplanationOfBenefit/PDexPriorAuth1, PdexPriorAuthorization and PriorAuthServiceTypeCodes
- CMS maintains HIPPS. There are no known constraints on the use of HIPPS.
  Show Usage
  - Health Insurance Prospective Payment System (HIPPS): ExplanationOfBenefit/PDexPriorAuth1, PDexPAInstitutionalProcedureCodes, PDexPAInstitutionalProcedureCodesVS and PdexPriorAuthorization
- 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: AssociatedServers, AttestationProvisionTypeValueSet... Show 102 more, AttestationStatusValueSet, BulkMemberMatch, BulkMemberMatchDataExport, ContactPointAvailableTime, DaVinciPayerDataExchange, DispenseRefill, DynamicRegistration, EndpointAccessControlMechanism, EndpointPayloadTypeCS, EndpointPayloadTypeVS, EndpointRank, EndpointUsecase, ExplanationOfBenefit_Identifier, ExplanationOfBenefit_Patient, ExplanationOfBenefit_ServiceDate, ExplanationOfBenefit_Type, ExplanationOfBenefit_Use, FDANationalDrugCode, FhirIg, Group_Code, IdentifierStatus, LastFilters, LastTransmission, LastTypes, LevelOfServiceCode, MatchParameters, MemberOptOut, MemberProviderTreatmentRelationship, MembersOptedOut, MtlsBundle, MtlsEndpoint, MtlsObjectCodeCS, MtlsObjectTypeVS, MtlsOrganization, MtlsSignedObject, OptOutDetails, OptOutReason, OptOutReasonCodeSystem, OptOutReasonValueSet, OptOutScopeCodeSystem, OptOutScopeValueSet, OrgTypeCS, OrgTypeVS, PDexAdjudication, PDexAdjudicationCategoryDiscriminator, PDexAdjudicationDiscriminator, PDexIdentifierType, PDexMemberCharacteristicCode, PDexMemberMatchGroup, PDexMemberNoMatchGroup, PDexMultiMemberMatchRequestParameters, PDexMultiMemberMatchResponseParameters, PDexMultiMemberMatchResultVS, PDexPAInstitutionalProcedureCodes, PDexPAInstitutionalProcedureCodesVS, PDexPayerAdjudicationStatus, PDexPayerBenefitPaymentStatus, PDexProviderGroup, PDexProviderSharingConsent, PDexServerCapabilityStatement61, PDexSupportingInfoType, PDexSupportingInfoTypeCS, PdexDevice, PdexMedicationDispense, PdexMedicationDispensePatient, PdexMedicationDispenseStatus, PdexMemberAttributionCS, PdexMultiMemberMatchResultCS, PdexPayerAccessServerCapabilityStatement, PdexPriorAuthorization, PdexProviderAccessServerCapabilityStatement, PdexServerCapabilityStatement, PriorAuthServiceTypeCodes, PriorAuthorizationAmounts, PriorAuthorizationUtilization, PriorAuthorizationValueCodes, Provenance, ProvenanceAgentRoleType, ProvenanceAgentType, ProvenancePayerDataSource, ProvenancePayerSourceFormat, ProvenanceSourceFrom, ProviderMemberMatch, ProviderMemberMatchGroup, ProviderMemberNoMatchGroup, ProviderMultiMemberMatchRequestParameters, ProviderMultiMemberMatchResponseParameters, ProviderTreatmentAttestation, ReviewAction, ReviewActionCode, SecureExchangeArtifacts, TreatmentRelationshipDetails, TreatmentRelationshipTypeCodeSystem, TreatmentRelationshipTypeValueSet, TrustFramework, TrustFrameworkTypeCS, TrustFrameworkTypeVS, TrustProfileCS, VerificationStatus, WhenAdjudicated, X12278ReviewDecisionReasonCode and X12ClaimAdjustmentReasonCodesCMSRemittanceAdviceRemarkCodes
- These codes are excerpted from ASTM Standard, E1762-95(2013) - Standard Guide for Electronic Authentication of Health Care Information, Copyright by ASTM International, 100 Barr Harbor Drive, West Conshohocken, PA 19428. Copies of this standard are available through the ASTM Web Site at www.astm.org.
  Show Usage
  - Signature Type Codes: Bundle/example-mtls-endpoint-bundle
- This CodeSystem is not copyrighted.
  Show Usage
  - C4BB Adjudication Code System: PDexAdjudication, PDexAdjudicationCategoryDiscriminator and PdexPriorAuthorization
  - PDex Adjudication Discriminator: PDexAdjudicationCategoryDiscriminator and PdexPriorAuthorization
  - PDex Payer Adjudication Status: PDexPayerBenefitPaymentStatus
  - PDex Supporting Info Type: PDexSupportingInfoType
- This is an example set based on ASTM Standard, E1762-95 (2013) HL7 RoleClass OID 2.16.840.1.113883.5.110, HL7 Role Code 2.16.840.1.113883.5.111, HL7 ParticipationType OID: 2.16.840.1.113883.5.90, HL7 ParticipationFunction codes at OID: 2.16.840.1.113883.5.88, and HL7 Security and Privacy Domain Analysis Model roles classes.
  Show Usage
  - Contract Signer Type Codes: Bundle/1000000-1, Bundle/1000000-2, Bundle/1000000-3 and Provenance/1000017
- This material contains content from LOINC. LOINC is copyright © 1995-2020, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and is available at no cost under the license. LOINC® is a registered United States trademark of Regenstrief Institute, Inc.
  Show Usage
  - LOINC: Consent/provider-treatment-attestation-1, Consent/treatment-attestation-ex1... Show 6 more, Consent/treatment-attestation-ex2, DocumentReference/123456, DocumentReference/provider-attestation-doc-1, Parameters/provider-bulk-member-match-in, Parameters/provider-member-match-request-001 and ProviderTreatmentAttestation
- 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&reg; (SNOMED CT&reg;): Bundle/1000000-1, Bundle/1000000-2... Show 7 more, Bundle/1000000-3, Bundle/3000003, Device/543210, Encounter/6, Encounter/7, Encounter/8 and PdexDevice
- 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
  - Adjudication Value Codes: ExplanationOfBenefit/PDexPriorAuth1, PDexAdjudication and PdexPriorAuthorization
  - Claim Type Codes: ExplanationOfBenefit/PDexPriorAuth1
  - Condition Category Codes: Bundle/3000003
  - Condition Clinical Status Codes: Bundle/3000003
  - ConditionVerificationStatus: Bundle/3000003
  - Consent Action Codes: Consent/consent-2, Consent/no-consent-1, PDexProviderSharingConsent and Parameters/payer-multi-member-match-in
  - Consent Category Codes: Consent/provider-treatment-attestation-1, Consent/treatment-attestation-ex1... Show 5 more, Consent/treatment-attestation-ex2, DocumentReference/provider-attestation-doc-1, Parameters/provider-bulk-member-match-in, Parameters/provider-member-match-request-001 and ProviderTreatmentAttestation
  - Consent PolicyRule Codes: Consent/no-consent-1 and PDexProviderSharingConsent
  - Consent Scope Codes: Consent/consent-2, Consent/no-consent-1... Show 8 more, Consent/provider-treatment-attestation-1, Consent/treatment-attestation-ex1, Consent/treatment-attestation-ex2, PDexProviderSharingConsent, Parameters/payer-multi-member-match-in, Parameters/provider-bulk-member-match-in, Parameters/provider-member-match-request-001 and ProviderTreatmentAttestation
  - Coverage Class Codes: Coverage/CoverageLinkExample1, Coverage/CoverageMatchExample1... Show 5 more, Coverage/CoverageMatchExample2, Coverage/coverage-2, Parameters/payer-multi-member-match-in, Parameters/provider-bulk-member-match-in and Parameters/provider-member-match-request-001
  - DataAbsentReason: Bundle/example-mtls-endpoint-bundle, MtlsEndpoint... Show 4 more, PDexPAInstitutionalProcedureCodes, PDexPAInstitutionalProcedureCodesVS, Payer-Payer Exchange and PdexPriorAuthorization
  - Endpoint Connection Type: Bundle/example-mtls-endpoint-bundle, MtlsEndpoint and Payer-Payer Exchange
  - Example Diagnosis Type Codes: ExplanationOfBenefit/PDexPriorAuth1
  - Example Related Claim Relationship Codes: ExplanationOfBenefit/PDexPriorAuth1
  - Funds Reservation Codes: ExplanationOfBenefit/PDexPriorAuth1
  - Organization type: DiamondOnyxHealth
  - Process Priority Codes: ExplanationOfBenefit/PDexPriorAuth1 and PdexPriorAuthorization
  - Professional Credential Status: IdentifierStatus
  - SubscriberPolicyholder Relationship Codes: Coverage/883210, Coverage/Coverage1... Show 8 more, Coverage/CoverageLinkExample1, Coverage/CoverageMatchExample1, Coverage/CoverageMatchExample2, Coverage/coverage-2, Coverage/coverage-link-2, Parameters/payer-multi-member-match-in, Parameters/provider-bulk-member-match-in and Parameters/provider-member-match-request-001
  - identifierType: Bundle/1000000-1, Bundle/1000000-2... Show 28 more, Bundle/1000000-3, Coverage/883210, Coverage/Coverage1, Coverage/coverage-2, Coverage/coverage-link-2, Group/example-pdex-member-consent-constraint-group, Group/example-pdex-member-no-match-group, Matched Members, Parameters/payer-multi-member-match-in, Parameters/payer-multi-member-match-out, Parameters/provider-bulk-member-match-in, Parameters/provider-bulk-member-match-out, Parameters/provider-member-match-request-001, Patient/1, Patient/1-2, Patient/100, Patient/1001, Patient/2002, Patient/PatientMemberMatchExample1, Patient/PatientMemberMatchExample2, Patient/patient-2, Patient/payer-patient-1001, Patient/payer-patient-2002, Payer 1, Payer 2, Practitioner/4, Provider 1 and Provider 2
  - ActCode: Bundle/1000000-1, Bundle/1000000-2... Show 16 more, Bundle/1000000-3, Bundle/2000002, Bundle/3000002, Consent/consent-2, Consent/no-consent-1, Coverage/CoverageLinkExample1, Coverage/CoverageMatchExample1, Coverage/CoverageMatchExample2, Encounter/6, Encounter/7, Encounter/8, MedicationDispense/1000001, PDexProviderSharingConsent, Parameters/payer-multi-member-match-in, Parameters/provider-member-match-request-001 and PdexMedicationDispense
  - ActReason: Consent/provider-treatment-attestation-1, Consent/treatment-attestation-ex1... Show 5 more, Consent/treatment-attestation-ex2, Parameters/provider-bulk-member-match-in, Parameters/provider-member-match-request-001, Provenance/1000101 and ProviderTreatmentAttestation
  - DataOperation: Provenance/1000101
  - NullFlavor: Bundle/1000000-1, Bundle/1000000-2... Show 4 more, Bundle/1000000-3, Patient/1, Patient/1-2 and Patient/100
  - ParticipationType: Consent/consent-2, Consent/provider-treatment-attestation-1... Show 5 more, Consent/treatment-attestation-ex1, Consent/treatment-attestation-ex2, Parameters/payer-multi-member-match-in, Parameters/provider-bulk-member-match-in and Parameters/provider-member-match-request-001
  - RoleClass: Consent/provider-treatment-attestation-1 and Parameters/provider-bulk-member-match-in
- Used by permission of HL7 International, all rights reserved Creative Commons License
  Show Usage
  - US Core DocumentReferences Category Codes: DocumentReference/123456
  - US Core Provenance Participant Type Extension Codes: Bundle/1000000-1, Bundle/1000000-2... Show 8 more, Bundle/1000000-3, Bundle/3000002, Provenance, Provenance/1000001, Provenance/1000016, Provenance/1000017, Provenance/1000101 and ProvenanceAgentType
  - Endpoint Payload Types Code System: EndpointPayloadTypeVS
  - mTLS Object Type Code: MtlsObjectTypeVS, MtlsSignedObject and Payer-Payer Exchange
  - Organization Type: Acme of CT and OrgTypeVS
  - PDex Provider Access API Attribution Code System: Attributed List of Health Plan Members for Practitioner 1122334455., MemberOptOut... Show 7 more, MemberProviderTreatmentRelationship, PDexMemberMatchGroup, PDexMemberNoMatchGroup, PDexMultiMemberMatchResultVS, PDexProviderGroup, ProviderMemberMatchGroup and ProviderMemberNoMatchGroup
  - PDex Multi-Member Match Result Code System: Group/example-pdex-member-consent-constraint-group, Group/example-pdex-member-no-match-group... Show 11 more, Matched Members, MemberOptOut, MemberProviderTreatmentRelationship, PDexMemberMatchGroup, PDexMemberNoMatchGroup, PDexMultiMemberMatchResultVS, PDexProviderGroup, Parameters/payer-multi-member-match-out, Parameters/provider-bulk-member-match-out, ProviderMemberMatchGroup and ProviderMemberNoMatchGroup
  - Prior Authorization Values: ExplanationOfBenefit/PDexPriorAuth1, PdexPriorAuthorization and PriorAuthorizationAmounts
  - Provenance Roles: Provenance and ProvenanceAgentType
  - Provenance Payer Data Source Format: Bundle/1000000-1, Bundle/1000000-2... Show 13 more, Bundle/1000000-3, Bundle/3000002, Bundle/3000003, Provenance, Provenance/1000001, Provenance/1000002, Provenance/1000003, Provenance/1000004, Provenance/1000005, Provenance/1000006, Provenance/1000016, ProvenancePayerSourceFormat and ProvenanceSourceFrom
  - Trust FrameworkType Code System: TrustFramework and TrustFrameworkTypeVS
  - Opt-Out Reason: OptOutReason and OptOutReasonValueSet
  - Opt-Out Scope: MemberOptOut and OptOutScopeValueSet
  - Treatment Relationship Type: TreatmentRelationshipTypeValueSet

### Conventions

This implementation guide (IG) uses specific terminology to flag statements that have relevance for the evaluation of conformance with the guide:

SHALL indicates requirements that must be met to be conformant with the specification.

SHOULD indicates behaviors that are strongly recommended (and which may result in interoperability issues or sub-optimal behavior if not adhered to) but which do not, for this version of the specification, affect the determination of specification conformance.

MAY describes optional behaviors that are free to consider but where there is no recommendation for, or against, adoption.

#### MustSupport

For profiles defined in other IGs, the meaning of Must Support is established in the defining IG. Note that the Must Support requirements for this IG are modeled after the US Core Implementation Guide. For further information see the Must Support section in the Introduction page.

#### Security and Privacy

Security and Privacy are critically important when exchanging information. Please refer to the Security and Privacy page in this IG and the guidance it references in the Health Record Exchange (HRex) IG.

#### Patient/Subject Terminology

It is important to differentiate in the Implementation Guide between identifiers used by the Provider/EMR and those used by the Payer/Health Plan to identify the patient/subject/member.

For the purposes of this IG we will use the following terms:

- patient or subject id will be used to express the identifier used by the provider to identify a patient/subject.

- member id will be used to express the identifier used by the payer/health plan to identify an individual member. Health Plans may historically have referred to these individual members as:

  - Memberƒ
  - Subscriber
  - Beneficiary
  - Dependent
  - Group Member
  - Plan Member
  - Covered Party
  - Subject of Care.

### Dependencies

Implementation Guide | Version(s) | Reason
--- | --- | ---
Bulk Data Access IG | 2.0.0 | Imported by Da Vinci - Member Attribution (ATR) List (and potentially others)
CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) | 2.1.0 |
2.0.0 | Imported by Da Vinci Prior Authorization Support (PAS) FHIR IG (and potentially others)
Da Vinci - Coverage Requirements Discovery | 2.1.0 |
2.0.0 | Imported by Da Vinci Prior Authorization Support (PAS) FHIR IG (and potentially others)
Da Vinci - Documentation Templates and Rules | 2.1.0 | Imported by Da Vinci Clinical Data Exchange (CDex) (and potentially others)
Da Vinci - Member Attribution (ATR) List | 2.1.0 |
Da Vinci Clinical Data Exchange (CDex) | 2.1.0 | Imported by Da Vinci - Member Attribution (ATR) List (and potentially others)
Da Vinci Health Record Exchange (HRex) | 1.1.0 | Defines common conformance rules across all Da Vinci IGs, as well as additional constraints and profiles beyond U.S. Core
1.0.0 | Imported by Da Vinci - Coverage Requirements Discovery (and potentially others)
Da Vinci PDex Plan Net | 1.2.0 | Imported by Da Vinci - Member Attribution (ATR) List (and potentially others)
Da Vinci Prior Authorization Support (PAS) FHIR IG | 2.1.0 |
FHIR Extensions Pack | 5.2.0 | Imported by CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) (and potentially others)
5.1.0 | Imported by Da Vinci Health Record Exchange (HRex) (and potentially others)
1.0.0 | Imported by Da Vinci - Coverage Requirements Discovery (and potentially others)
FHIR R4 package : Core | 4.0.1 | Imported by US Core (and potentially others)
HL7 Terminology (THO) | 6.3.0 | Defines terminologies and coddesystems used in HIR IGs
6.2.0 | Imported by CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) (and potentially others)
6.1.0 | Imported by Da Vinci Health Record Exchange (HRex) (and potentially others)
5.5.0 | Imported by US Core (and potentially others)
5.3.0 | Imported by Da Vinci - Coverage Requirements Discovery (and potentially others)
5.0.0 | Imported by Subscriptions R5 Backport (and potentially others)
4.0.0 | Imported by Security for Scalable Registration, Authentication, and Authorization (and potentially others)
National Directory of Healthcare Providers & Services (NDH) | 1.0.0 |
Public Health Information Network Vocabulary Access and Distribution System (PHIN VADS) | 0.12.0 | Imported by US Core (and potentially others)
SMART App Launch | 2.1.0 | Imported by Da Vinci - Member Attribution (ATR) List (and potentially others)
2.0.0 | Imported by US Core (and potentially others)
Security for Scalable Registration, Authentication, and Authorization | 1.0.0 | Imported by National Directory of Healthcare Providers & Services (NDH) (and potentially others)
0.1.0 | Imported by Da Vinci Health Record Exchange (HRex) (and potentially others)
Structured Data Capture | 3.0.0 | Imported by US Core (and potentially others)
Subscriptions R5 Backport | 1.1.0 | Imported by Da Vinci Prior Authorization Support (PAS) FHIR IG (and potentially others)
US Core | 7.0.0 | Defines USCDI v4 EHR expectations on a range of resources that will be passed to and/or queried by CRD servers.
6.1.0 | Defines USCDI v3 EHR expectations on a range of resources that will be passed to and/or queried by CRD servers
3.1.1 | Defines USCDI v1 EHR expectations on a range of resources that will be passed to and/or queried by CRD servers.
Value Set Authority Center (VSAC) | 0.7.0 | Imported by CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) (and potentially others)
0.21.0 | Imported by CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) (and potentially others)
0.19.0 | Imported by Da Vinci Health Record Exchange (HRex) (and potentially others)
0.18.0 | Imported by US Core (and potentially others)
0.11.0 | Imported by Da Vinci - Coverage Requirements Discovery (and potentially others)

### Change History

A history of changes made since the publication of the STU1 version of the PDex IG is maintained in ChangeHistory.

### Project and Participants

See the Credits page for a list of contributors to the creation and maintenance of this Implementation Guide.

### FHIR Publisher

This IG was built with Sushi and the FHIR Publisher (v1.6.5 or greater).

Next Page: Overview