Narrative Conformance

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.2.0 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

Page standards status: Trial-use

Previous Page - Introduction

This page consolidates all conformance statements that are included in the narrative of the Implementation Guide.

Id Expectation Rule

SHOULD
SHALL
MAY
SHOULD NOT
SHALL NOT

§1 SHALL pdex-35: *SHALL** be used to express a member's demographic information.

§2 MAY pdex-63: - The returned information MAY include a link to a SMART-on-FHIR App to enable selection of resources by the Clinician that will be written to the Clinician’s EMR system

§3 MAY pdex-64: - The information card MAY include a link to launch the SMART-on-FHIR App using the appContext to enable the Clinician to query information about their patient using the Health Plan’s FHIR API.

§4 SHALL
SHOULD pdex-168 listed essentially the same payload as "SHALL be available" but mentioned only US Core 3.1.1, which had the effect of imposing a hard requirement on US Core 3.1.1. Per CMS-0057 the Payer-to-Payer payload is mandatory, so the SHALL strength is correct and the SHOULD was wrong. Resolved by collapsing the two into a single canonical conformance expectation:

§5 MAY pdex-386 to descriptive MAY language: "Where a payer elects to exchange any of the data types listed above, the table below identifies the FHIR R4 / US Core profile that the payer MAY use for each", with an explicit follow-up sentence stating that the page is informative, that nothing in the table adds normative obligations beyond those imposed by the relevant regulation or by the operation-specific pages of this IG, and that listing data types outside regulatory scope is purely illustrative. The

§6 SHOULD pdex-05 (PDex Provenance, "A Provenance resource SHOULD be provided with each member-related resource…") and

§7 SHALL
SHOULD pdex-241a (payers SHALL support v2 for the CMS-0057 Provider Access API obligation; in-network providers/EHRs SHOULD use v2) and

§8 MAY pdex-326 (v1) to MAY to match

§9 SHALL pdex-127 to make the per-exchange / per-bundle scope explicit: "For each PDex information exchange, the Health Plan SHALL provide at least one Provenance resource naming the Health Plan as the Transmitter of the data — i.e., a Provenance whose agent[].type includes a Transmitter entry and whose agent.who references the Health Plan's Organization, with target[] referencing the resources transmitted in the exchange. This is an exchange-level (per-bundle) obligation: a single Transmitter Provenance per exchange satisfies

§10 SHALL pdex-127 (per-exchange SHALL) and

§11 SHALL pdex-127 (per-exchange SHALL) and ^§10

§12 SHALL pdex-210 immediately above it, which states that each of the three retrieval methods (individual queries / $patient-everything / Bulk FHIR) SHALL support the same profiles and resources. The accompanying _type example list compounded the error by omitting ExplanationOfBenefit entirely. Resolved by (i) rewording

§13 SHALL pdex-132 itself as the response-content requirement: "In both the Provider Access API and the Payer-to-Payer API, any Prior Authorization whose status has changed in the previous 12 months (measured from the date of the request) SHALL be included in the API response." A trailing sentence notes that

§14 SHALL pdex-133 now reads "Active and pending Prior Authorizations exchanged via the Payer-to-Payer Exchange API SHALL include the related clinical documentation and forms used in support of the prior authorization decision";

§15 SHALL NOT 7.5.2.1 (Cross-Referencing Match Results with Submitted Members) — and the parallel FSH ^comment on Group.contained for both PDexMemberMatchGroup and PDexMemberNoMatchGroup: the absolute "Responders SHALL NOT abridge, modify, or substitute the submitted Patient resource" at

§16 MAY 7.5.5.1.4 (_typeFilter): the submitter asked whether the MAY in

§17 MAY pdex-180 is now restricted to the requester's choice (a requesting Payer MAY include _typeFilter); new

§18 SHALL
SHOULD
MAY 7.5.2 — "Bulk Member Match with Consent"): the responder SHALL include the Group resources as Group ndjson files in the async completion manifest (matching the current STU 2.2.0 format that fits the FHIR R4 Asynchronous Request Pattern naturally), and MAY additionally include a Parameters ndjson file (with manifest output[] "type": "Parameters") containing a PDexMultiMemberMatchResponseParameters-conformant Parameters resource that wraps the same Group resources, so a single response can serve both STU 2.1.0-style requesters and STU 2.2.0-style requesters from one responder. A new "Backwards-compatible Parameters envelope (optional)" subsection records the trade-off and instructs requesters that consume both formats to SHOULD prefer the Group ndjson files. The OperationDefinition is unchanged (it already declares no inline out parameters because the output is delivered via the async manifest). The parallel "Operation Definition" paragraph at

§19 SHALL
MAY pdex-138 (Out: line) is also updated. Modification — Level A cross-operation alignment. Because implementers are converging Payer-to-Payer foundations into Provider Access deployments, the same Group-ndjson-SHALL + Parameters-ndjson-MAY allowance has been extended to the Provider Access v2 $provider-member-match operation (new

§20 SHALL pdex-252 rewritten to remove the contradictory "SHALL be used, unless …" pattern; payers using legacy systems are explicitly conformant. (v)

§21 SHOULD pdex-84: Health Plans SHOULD accept and retain Provenance records received with data based on Member-authorized Payer-to-Payer exchange.

§22 SHOULD pdex-85: Health Plans SHOULD accept and retain Provenance records received with data from sources other than Member-authorized Payer-to-Payer exchange.

§23 SHOULD pdex-86: When a Health Plan forwards information as a FHIR Resource it SHOULD create related Provenance record(s) to reflect the original source of the data.

§24 SHALL pdex-102: For querying and reading PDex and US Core Profiles, Must Support on any profile data element SHALL be interpreted as follows:

§25 SHALL Where a requester supplies an out-of-range date-of-service filter via _typeFilter, the responder SHALL still apply the

§26 SHALL NOT
MAY A client that wishes to retrieve only a subset (for example, only Prior Authorization records, or only claims) MAY narrow the response by supplying the _type parameter or by filtering client-side after retrieval. The server SHALL NOT silently exclude claim ExplanationOfBenefit records from the response unless the requester is not permitted to access them under

§27 SHOULD pdex-241: The Provider-Member-Match operation **SHOULD** be submitted as a first step.

§28 SHOULD pdex-241: The Provider-Member-Match operation **SHOULD** be submitted as a first step. ^§27

§pdex-01 SHOULD perform this match operation multiple times and SHOULD only be granted access to data for the matched

§pdex-02 SHALL The Da Vinci PDex MedicationDispense profile SHALL be used to record a member's prescription drug claims when sharing data using

§pdex-03 SHOULD to exchange data the US Core MedicationDispense profile SHOULD be used.

§pdex-04 SHOULD When a Health Plan forwards information as a FHIR Resource it SHOULD create related Provenance record(s) to reflect the original source.

§pdex-05 SHOULD A Provenance resource describing the upstream origin (Author or Source) SHOULD be provided with each member-related resource provided by the Health Plan's FHIR API.

§pdex-06 SHOULD This SHOULD be used to:

§pdex-07 SHOULD Provenance.recorded value SHOULD be the date/time when the data is received by the payer.

§pdex-08 SHOULD The Pdex Provenance record SHOULD be populated with the following essential fields (Must Support or Cardinality greater than 0..*) as follows:

§pdex-09 SHOULD SHOULD be written to a FHIR server and the records assigned new FHIR IDs with references being re-written to maintain referential integrity.

§pdex-10 SHALL The Health Plan SHALL accept and maintain Provenance information associated with information received from contributing entities.

§pdex-11 SHALL The Health Plan SHALL add Provenance record(s) as necessary to document relevant actions taken as the current custodian of the information.

§pdex-12 SHALL Provenance information SHALL be available for any information requested by an external entity as part of exchanges conformant to this implementation guide.

§pdex-13 SHALL This guide SHALL define extensions to the provenance value sets as required to document the provenance of the information exchange.

§pdex-14 SHOULD The Health Plan SHOULD create a Provenance Record documenting the source of the records, the identity of the health plan and the action taken to become the custodian of the data.

§pdex-15 SHOULD The updated Provenance record SHOULD be passed on to any downstream entity that requests Provenance information for the records they request.

§pdex-16 SHOULD The Health Plan SHOULD store the Provenance information and maintain the correlation or links to the records the Provenance Record is documenting.

§pdex-17 SHOULD The Health Plan SHOULD update the Provenance records to add information covering the identity of the health plan and the action taken to become the custodian of the data.

§pdex-18 SHOULD The updated Provenance record SHOULD be passed on to any downstream entity requesting the associated records.

§pdex-19 SHOULD The Health Plan SHOULD create a Provenance Record documenting the source of the records, the identity of the health plan and the action taken to transform the data to FHIR Clinical Resources.

§pdex-20 SHOULD The updated Provenance record SHOULD be passed on to any downstream entity requesting the associated records.

§pdex-21 SHALL SHALL be used to record them.

§pdex-22 SHALL Where a Health Plan has access to Care Plan information for a member, they SHALL make the information available using the US Core CarePlan resource.

§pdex-23 SHALL Where a Health Plan has access to Information about the CareTeam for a member they SHALL make the information available using the

§pdex-24 MAY For discrete procedures or encounters it MAY not be appropriate to create a CareTeam record from the claims information.

§pdex-25 SHALL Where a Health Plan has access to Laboratory Results and other diagnostic information, they SHALL make the information available using the US Core DiagnosticReport for Laboratory Results Reporting resource.

§pdex-26 SHALL Where a Health Plan has access to clinical notes and associated diagnostic information, they SHALL make the information available using the US Core DiagnosticReport for Report and Note Exchange resource.

§pdex-27 SHALL The Health Plan SHALL use the

§pdex-28 SHALL Where a Health Plan has access to structured and coded Immunization information for a member, the health plan SHALL present the information using the

§pdex-29 SHALL Where a Health Plan has information about devices used by the Member that information SHALL be published using the

§pdex-30 SHALL It identifies which core elements, extensions, vocabularies and value sets SHALL be present in the resource when using this profile.

§pdex-31 SHALL SHALL be used to record location/facility-specific information.

§pdex-32 SHALL Where a Health Plan has access to Medication information, they SHALL make the information available using the

§pdex-33 SHALL Where a Health Plan has access to Prescription information, they SHALL make the information available using the

§pdex-34 SHOULD SHOULD use the

§pdex-36 SHALL The code MB SHALL be used to identify the member identifier.

§pdex-37 SHALL SHALL be used to record information about Practitioners.

§pdex-38 SHALL SHALL be used to record information about the roles that practitioners take in providing services to their patients.

§pdex-39 SHALL SHALL be used to record a member's health events.

§pdex-40 SHOULD Note: Procedure records SHOULD only be created from ExplanationOfBenefit or CPCDS resources for items that are clinical procedures.

§pdex-41 SHOULD NOT Medications, facility charges and supplies SHOULD NOT be created as procedure records.

§pdex-42 SHALL In all other cases a payer SHALL create a PDex Provenance profile that identifies their role as a "Transmitter" of the information.

§pdex-43 MAY This IG uses a combination of CDS-Hooks and SMART-on-FHIR to enable Providers to issue a query to a Health Plan and to retrieve information about their patient (the Health Plan member) that they MAY review and choose to commit to the patient record in their EMR.

§pdex-44 SHALL When interacting with EMR systems that support FHIR R4 the SMART App SHALL evaluate the EMR System's CapabilityStatement that the implementation has deemed relevant to this SMART-on-FHIR application to determine which of the records selected by the Provider can be written to the EMR via the FHIR API.

§pdex-45 SHOULD Where the EMR's FHIR API does not enable the SMART App to write a resource via the API, the SMART App SHOULD write the records that it is permitted to write to the API.

§pdex-46 SHOULD The remaining selected records SHOULD be retained in the EMR in the most appropriate form to allow the provider access to the information when needed.

§pdex-47 SHALL The Payer's CDS Hooks service SHALL handle the content in the JSON hooks payload, regardless of version of FHIR used for incorporated resources.

§pdex-48 SHALL The health plan's CDS Hooks service SHALL provide access to FHIR R4 resources based on Profiles identified in the US Core, Da Vinci PDex and HRex IGs.

§pdex-49 MAY The SMART-on-FHIR App that MAY be called from the returned CDS Hooks card will not translate R4 profiles to earlier versions of FHIR.

§pdex-50 SHALL When interacting with EMR systems that support FHIR R4 the SMART App SHALL evaluate the EMR System's CapabilityStatement to determine which of the records selected by the Provider can be written to the EMR via the FHIR API.

§pdex-51 SHALL The remaining selected records SHALL be compiled into a FHIR bundle, a PDF SHALL be created to provide a human-readable version of the bundle and both documents SHALL be attached as a DocumentReference and committed to the patient's record.

§pdex-52 SHALL Where an EMR providing an R4 API prevents the attaching of a FHIR bundle to a DocumentReference the SMART APP SHALL attempt to write the selected records based upon the options listed below for graceful write degradation.

§pdex-53 SHALL When interacting with EMR systems that support FHIR versions prior to FHIR R4 the SMART App SHALL, where permitted by the target EMR, create a DocumentReference and encapsulate a PDF, human-readable version of the records being committed, together with a document bundle that encapsulates the FHIR resources from the health plan that the provider has selected to commit to the patient's record.

§pdex-54 SHALL Where the EMR does not support the attachment of FHIR Bundles to a DocumentReference record the SMART App SHALL create a human-readable PDF version of the selected resources then attach this document to the DocumentReference and commit to the patient's record.

§pdex-55 SHALL Where the EMR does not support the attachment of PDF Documents to a DocumentReference record the SMART App SHALL create an HTML or XHTML document that contains the selected resources then attach this document to the DocumentReference and commit to the patient's record.

§pdex-56 SHALL Where the EMR does not support the attachment of HTML/XHTML documents to a DocumentReference record the SMART App SHALL create a human-readable ASCII text version of the selected resources then attach this to the DocumentReference and commit to the patient's record.

§pdex-57 SHOULD Subscriber Id or Member Id, if available, SHOULD be taken from the Patient's Coverage record, or be manually entered by the Provider via the SMART-on-FHIR App.

§pdex-58 SHOULD If the Member Id is not available, the Subscriber ID and the patient information from the Coverage.beneficiary element SHOULD be used to uniquely identify the member.

§pdex-59 SHALL Sharing of Member health information via PDex SHALL use the CDS Hooks specification.

§pdex-60 SHALL Connection to health plan systems SHALL be supported via the following hook:

§pdex-61 SHOULD
MAY Any identifiers associated with the coverage for the patient (which may include patient demographics) SHOULD be obtained from the FHIR Coverage record for the patient, or MAY be entered manually by the provider via the SMART-on-FHIR App.

§pdex-62 SHOULD PDex supports three common scenarios where CDS Hooks SHOULD be used:

§pdex-65 MAY The SMART-on-FHIR App MAY be configured with default FHIR search queries that can be set by the Clinician, or their organization.

§pdex-66 MAY Examples of preset search query parameters MAY include, but are not limited to:

§pdex-67 MAY Any valid FHIR search query for a Patient MAY be constructed by the Provider.

§pdex-68 SHALL As a minimum, the Health Plan's FHIR API SHALL limit returned results to the records that are related to the Patient/Member that is the subject of the Provider query.

§pdex-69 SHOULD As a minimum, search of FHIR Resources SHOULD support the following query parameters where appropriate for a Resource Type:

§pdex-70 MAY Health plans and clients MAY support additional hooks, additional card patterns, additional resources, additional extensions, etc.

§pdex-71 MAY While it is expected that health plans MAY implement their own processes and communication methods to track and act upon a member opting out of Provider Access API data sharing, the following profile is provided as an example of a Consent resource that could be used to express a member opt-out.

§pdex-72 MAY This MAY be used by a member portal, or consumer app to communicate an opt-out from Provider Access sharing.

§pdex-73 MAY Coverage.identifier MAY include a member identifier in the Coverage resource.

§pdex-74 SHALL Health Plans SHALL map clinical information for a member to US Core v3.1.1, US Core v6.1.0 or US Core v7.0.0 FHIR Resources based on R4.

§pdex-75 SHALL Health Plans SHALL map claims and encounter data to the non-financial ExplanationOfBenefit BASIS profiles defined in the CARIN Consumer Directed Payer Data Exchange IG.

§pdex-76 SHALL Health Plans SHALL map prior authorization information to the PDex Prior Authorization profile.

§pdex-77 MAY As those profiles mature and achieve adoption, they MAY be offered up to US Realm for incorporation into a future version of US Core.

§pdex-78 SHALL Where a US Core 3.1.1. FHIR R4, US Core 6.1.0. FHIR R4 or US Core 7.0.0. FHIR R4 Resource is not defined for clinical data, Health Plans SHALL map to FHIR Profiles defined in this IG, or the Da Vinci HRex IG.

§pdex-79 SHOULD Oral and vision information are considered part of the Health Plan record for a specific member and, when it is available, SHOULD be included in the Payer-to-Payer and Provider Access exchanges described in this IG, using the BASIS profiles defined in the CARIN Consumer Directed Payer Data Exchange IG (CARIN IG for Blue Button®).

§pdex-80 SHALL If a field is marked as required (cardinality n.., where n>0) the Health Plan SHALL populate the field.

§pdex-81 SHALL For a field specified as MUST SUPPORT and the cardinality is 0.., the Health Plan SHALL be capable of populating the field and do so if the relevant data exists.

§pdex-82 SHALL Where a field contains sub-field elements that are marked as MUST SUPPORT but the parent element has a cardinality of 0..n, where n is 1 or greater, the health plan SHALL provide data for the MUST SUPPORT sub-elements, only if it is providing data for the parent element.

§pdex-83 SHALL If a field is marked as MUST SUPPORT the receiver SHALL be able to consume it without generating an error.

§pdex-87 SHOULD A Provenance resource describing the upstream origin (Author or Source) of each member-related resource SHOULD be provided with that resource when the Health Plan's FHIR API serves it — particularly when the requester adds the _revinclude=Provenance:target parameter to a search query.

§pdex-88 SHOULD 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:

§pdex-89 SHALL Implementers and testers of this specification SHALL abide by the license requirements for each terminology content artifact utilized within a functioning implementation.

§pdex-90 SHALL Terminology licenses SHALL be obtained from the Third-Party IP owner for each code system and/or other specified artifact used.

§pdex-91 SHALL SHALL indicates requirements that must be met to be conformant with the specification.

§pdex-92 SHOULD 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.

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

§pdex-94 SHALL The CMS Interoperability and Patient Access Rule requires that a member new to a health plan SHALL be able to request that their information be passed from their old health plan to their new health plan.

§pdex-95 SHALL A Member SHALL also be able to use APIs to share information with Third Party Applications.

§pdex-96 SHALL Therefore, for profiles and APIs identified in this IG, the FHIR R4 version SHALL be used.

§pdex-97 SHOULD The FHIR Resources that comprise the Member Clinical and Claims-derived history, otherwise referred to as the "Member Health History" SHOULD include the following profiles where payers have data to support the use of those profiles:

§pdex-98 SHALL All resources available via a FHIR API endpoint SHALL be declared in a FHIR CapabilityStatement.

§pdex-99 SHALL The Read and Search Operations SHALL be supported for the FHIR Profiles covered in this payload section.

§pdex-100 MAY The V-Read and History operations MAY be supported.

§pdex-101 SHALL
SHOULD
MAY This implementation guide uses specific terminology such as SHALL, SHOULD, MAY to flag statements that have relevance for the evaluation of conformance with the guide.

§pdex-103 SHALL PDex Responders SHALL be capable of populating all data elements as part of the query results as specified by the PDex and US Core Server Capability Statement.

§pdex-104 SHALL PDex Requestors SHALL be capable of processing resource instances containing the data elements without generating an error or causing the application to fail.

§pdex-105 SHOULD In other words PDex Requestors SHOULD be capable of displaying the data elements for human use or storing it for other purposes.

§pdex-106 SHALL NOT In situations where information on a particular data element is not present and the reason for absence is unknown, PDex Responders SHALL NOT include the data elements in the resource instance returned as part of the query results.

§pdex-107 SHALL When querying PDex Responders, PDex Requestors SHALL interpret missing data elements within resource instances as data not present in the PDex Responder’s system.

§pdex-108 SHALL In situations where information on a particular data element is missing and the PDex Responder knows the precise reason for the absence of data, PDex Responders SHALL send the reason for the missing information using values (such as nullFlavors) from the value set where they exist or using the dataAbsentReason extension.

§pdex-109 SHALL PDex Requestors SHALL be able to process resource instances containing data elements asserting missing information.

§pdex-110 SHOULD A Health Plan's Pharmacy Network SHOULD be expressed using the same FHIR profiles used for the Healthcare Network Directory.

§pdex-111 SHALL When a Member is authorizing sharing of the Member Health History with another Health Plan, or a Third Party Application, via the OAuth 2.0 protocol the Health Plan that is operating the API SHALL offer the Member an option to allow the sharing of sensitive information, such as behavioral health data, resulting in the data being shared excluding sensitive data that is covered by state and/or federal regulations.

§pdex-112 SHALL The member SHALL authenticate using credentials they have been issued by, or accepted by the Health Plan.

§pdex-113 SHALL After authenticating the Member SHALL be presented with an Authorization process that enables them to approve the sharing of information with the Third Party, or new Health Plan, Application that has client application credentials registered with the Health Plan.

§pdex-114 SHALL The Authorization process SHALL provide the ability for the authorized representative to designate a third-party application that will have access to all information permitted by current state and federal regulations.

§pdex-115 SHALL After successfully authorizing an application an Access Token and Optional Refresh Token SHALL be returned to the requesting application.

§pdex-116 SHALL The requesting application SHALL use the access token to access the Health Plan's secure FHIR API to download the information that the Member is allowed to access.

§pdex-117 MAY The application owner MAY be:

§pdex-118 SHALL NOTE: exportType parameter SHALL be populated with a value for all PDex implementations of the $Davinci-data-export-operation.

§pdex-119 SHALL All data exchanged by Health Plans using the interactions covered in this IG SHALL be transformed to FHIR R4 resources.

§pdex-120 MAY Health Plans MAY have both data from clinical and claims sources that they store in their Systems of Record.

§pdex-121 SHOULD Payers SHOULD look at the data they maintain and ensure that information relevant to the member’s care and treatment over time is accurately represented – in this way, it may not be appropriate to include a single data element only once across multiple events.

§pdex-122 SHALL The member SHALL authenticate using credentials that have been issued by or are recognized and accepted by the Health Plan.

§pdex-123 SHALL After authenticating the Member SHALL be presented with an Authorization screen that enables them to approve the sharing of information with the Third Party, or new Health Plan Application that has client application credentials registered with the Health Plan.

§pdex-124 SHALL The use of the Bulk FHIR specification for transmission of member data SHALL honor jurisdictional and personal privacy restrictions that are relevant to a member's health record.

§pdex-125 SHOULD Health Plans SHOULD accept and retain provenance records that they receive as part of any exchange of FHIR data.

§pdex-126 SHOULD Where a FHIR Provenance resource is not provided, such as when data is received from other non-FHIR sources, the Health Plan SHOULD create FHIR Provenance record(s) to identify the source of the information being exchanged.

§pdex-127 SHALL For each PDex information exchange, the Health Plan SHALL provide at least one Provenance resource naming the Health Plan as the Transmitter of the data — i.e., a Provenance whose agent[].type includes a Transmitter entry and whose agent.who references the Health Plan's Organization, with target[] referencing the resources transmitted in the exchange.

§pdex-128 SHOULD In the case of historical data, the Health Plan SHOULD identify the author, source and source format of the data.

§pdex-129 SHALL Bulk Payer-to-Payer exchange SHALL be accomplished using the asynchronous bulk-data delivery semantics defined in the HL7 FHIR Bulk Data Access Implementation Guide STU2 (2.0.0) — that is, operation kick-off via HTTP POST, status polling per the FHIR R4 Asynchronous Request Pattern, and a completion manifest referencing one or more NDJSON output files.

§pdex-130 SHALL
MAY Accordingly, a requesting health plan SHALL request data covering at least the 5-year window before the date of the request, and a responding health plan SHALL be capable of returning at least the past 5 years of in-scope data so that requestors can meet that obligation. A requestor MAY request, and a responder MAY return, data with a date of service older than 5 years.

§pdex-131 SHALL Prior Authorizations SHALL be limited to current/active Prior Authorizations in addition to Prior Authorizations that have changed status within the last year, as of the date of request for information.

§pdex-132 SHALL In both the Provider Access API and the Payer-to-Payer API, any Prior Authorization whose status has changed in the previous 12 months (measured from the date of the request) SHALL be included in the API response.

§pdex-133 SHALL Active and pending Prior Authorizations exchanged via the Payer-to-Payer Exchange API SHALL include the related clinical documentation and forms used in support of the prior authorization decision.

§pdex-134 SHALL The supporting documentation SHALL include both structured and unstructured documentation — for example, clinical notes, lab reports, imaging interpretations, signed administrative forms, and other attachments — that was used in the prior authorization determination.

§pdex-135 SHALL The data available to be returned by the Bulk Payer-to-Payer Exchange API SHALL

§pdex-136 SHALL This operation SHALL run asynchronously and upon completion returns Group resources categorizing members as matched, non-matched, or consent-constrained.

§pdex-137 SHALL Both operations follow the FHIR Asynchronous Request Pattern: each kick-off request returns an HTTP 202 Accepted response with a Content-Location header pointing to a status endpoint that clients SHALL poll to retrieve the completed result.

§pdex-138 SHALL The requesting (or New) health plan SHALL request permission (i.e., consent) from the Member to retrieve the data from their prior plan.

§pdex-138a MAY To ease the transition for requesters that have already implemented the STU 2.1.0 envelope, a STU 2.2.0 responder MAY additionally include a Parameters ndjson file in the async completion manifest (alongside the Group ndjson files) containing a PDexMultiMemberMatchResponseParameters-conformant Parameters resource that wraps the same Group resources.

§pdex-138b SHOULD When both ndjson formats are present, requesters SHOULD prefer the Group ndjson files.

§pdex-139 SHALL The Bulk Payer-to-Payer Exchange described in this section and the Payer-to-Payer (single Member) Exchange SHALL exchange the same data set;

§pdex-140 SHALL The following data SHALL be exchanged with

§pdex-141 MAY The following information MAY be exchanged with the prior plan for a member:

§pdex-142 SHALL The requesting Payer SHALL obtain an access token in accordance with the

§pdex-143 SHALL SHALL be required to access the secured bulk-member-match operation endpoint.

§pdex-144 SHALL SHALL be supplied as a parameter.part element in the

§pdex-145 MAY Optionally the new health plan MAY include the following element in the parameter.part

§pdex-146 SHALL The PDex $multi-member-match operation SHALL be submitted using a HTTP POST.

§pdex-147 SHALL The HTTP Header SHALL include:

§pdex-148 SHALL The $multi-member-match operation SHALL be performed asynchronously, following the Asynchronous Request Pattern defined in FHIR R4.

§pdex-149 SHALL Implementers SHALL follow the guidance provided in the Bulk Data Status Request section of the Async Request Pattern.pdex-139a: The subsequent $davinci-data-export operation SHALL also be submitted using a HTTP POST and SHALL be performed as an asynchronous Bulk Data export, per the FHIR Bulk Data Access IG.

§pdex-150 SHALL The contained Patient resource SHALL be the Patient resource submitted by the requester in the MemberBundle input parameter, preserving the original resource id, all identifier elements, and all demographic elements (name, birthDate, gender, address, telecom, communication, and any other Patient elements supplied by the requester) so that the requester can unambiguously correlate each match result back to the member they submitted.

§pdex-151 SHALL NOT Responders SHALL NOT modify, abridge, or substitute the submitted Patient resource's id, identifier, or demographic elements.

§pdex-151a SHALL Where the submitted Patient resource carries any of those base-FHIR-prohibited elements, the responder SHALL remove them when copying the resource into the response Group's Group.contained[], so the contained Patient is base-FHIR-conformant.

§pdex-153 SHALL In this case the responder SHALL also include the submitted CoverageToMatch resource as a contained Coverage in the Group and populate the matchedCoverage (or nonMatchedCoverage) extension on member.entity to reference it.

§pdex-154 SHALL The Bulk Member Match Operation SHALL evaluate the consent request for each member and determine whether the request for only Non-Sensitive data, as determined by federal and state regulations that apply to the data holder, can be complied with.

§pdex-154a SHALL Consent evaluation SHALL be performed independently for each submitted member.

§pdex-154c SHALL NOT
MAY A responder SHALL NOT include consent-error detail (for example, "Consent expired on 2026-04-15") in the ConsentConstrainedMembers Group itself, since the Group conveys the consent-constrained outcome categorically; per-member operational diagnostics MAY be returned out-of-band (operator logs, support channels) per the responder's policy.

§pdex-155 SHALL The following decision tree illustrates how the Consent determination SHALL be made.

§pdex-156 SHALL Consent SHALL be evaluated at the time of the data request to ensure that the Member

§pdex-157 SHALL Implementers SHALL support the Group search parameters enumerated in the PDex Server CapabilityStatement (and its US Core 6.1.0 variant, pdex-server-6-1) for the Group resource — at minimum identifier and characteristic — both of which are declared with SHALL support expectations there.

§pdex-158 SHALL the data available through the Payer-to-Payer Bulk API SHALL include:

§pdex-159 SHALL - SHALL be issued with OAuth2.0/SMART-On-FHIR client credentials that enable access to /Group/{id}.

§pdex-160 SHALL - SHALL be permitted to SEARCH /Group.

§pdex-161 SHALL The search function and the bundle contents returned SHALL be restricted to the {ids} that are associated with theRequesting/New Payer.

§pdex-162 MAY - MAY be associated with more than one PDex Member Match group list.

§pdex-163 SHALL - SHALL be permitted to GET /Group/{id} for any PDex Member Match Group list they are associated with.

§pdex-164 SHALL - SHALL be permitted to call $davinci-data-export operation for any /Group/{id} they are associated with.

§pdex-165 SHALL
MAY - SHALL be permitted to retrieve data with a date of service within at least the 5 years before the date of the request for information; a responding health plan MAY permit retrieval of older data.

§pdex-166 SHOULD enables granular resource requests the operation SHOULD be used with two scenarios:

§pdex-167 SHALL The Data Export operation SHALL check the consent status for each member

§pdex-168 SHALL The data that SHALL be available via the Payer-to-Payer Bulk API is enumerated above in

§pdex-169 SHALL
MAY Claims and clinical data exchanged to satisfy the requesting plan's obligation under 42 CFR 422.121(b)(4)(ii) SHALL include records with a date of service within the 5 years before the request; records older than 5 years MAY also be returned at the responding health plan's discretion.

§pdex-170 SHALL Prior Authorizations SHALL be limited to Active/Current Prior Authorizations and

§pdex-171 SHALL For Payer-to-Payer Bulk Exchange the exportType field SHALL have the following value:

§pdex-172 SHALL For Payer-to-Payer Exchange, a responding health plan SHALL be capable of returning all in-scope data with a date of service within the 5 years before the request date, in order to support the requesting plan's obligation under 42 CFR 422.121(b)(4)(ii).

§pdex-173 SHOULD The _since parameter SHOULD be used for resource requests when the full history is not required and the goal is to retrieve only resources that have been added or updated on the source since a previous export — i.e., for incremental / "run-off" retrievals.

§pdex-174 MAY It is expected that Payers MAY first request data for members without limiting the request using the _since parameter.

§pdex-175 MAY Subsequent requests MAY then use _since to limit data to information that is new on the source.

§pdex-177 MAY The _until parameter MAY be used less frequently.

§pdex-178 MAY The _type parameter MAY be used to restrict the resources retrieved by the

§pdex-179 SHALL If this parameter is not used all available resources SHALL be returned

§pdex-180 MAY A requesting Payer MAY include the _typeFilter parameter in a $davinci-data-export kick-off request to further restrict the resources retrieved (for example, to only retrieve Observations of a certain type).

§pdex-180b SHOULD Requesting Payers SHOULD consult the responding Payer's CapabilityStatement (or out-of-band documentation) to determine whether _typeFilter is supported before relying on it.

§pdex-180c SHALL A responding Payer that supports _typeFilter SHALL filter the exported resources per the supplied search query, as required by the Bulk Data Access IG.

§pdex-180d SHALL NOT
SHALL A responding Payer that does not support _typeFilter, or does not support the specific search parameter named in the requester's filter, SHALL behave per the Bulk Data Access IG — typically by returning an OperationOutcome so the requester can resubmit without the unsupported filter; responders SHALL NOT silently ignore an unsupported _typeFilter and emit unfiltered data.

§pdex-181 SHALL The _typeFilter value, when supplied, SHALL comprise one or more valid FHIR search queries for the respective resource being filtered.

§pdex-182 SHALL supported by the relevant profiles from the PDex, US Core or CARIN Blue Button IGs SHALL

§pdex-183 SHOULD Implementers SHOULD implement OAuth 2.0 access management in accordance with

§pdex-184 SHALL Requests with requiresAccessToken=true SHALL be protected the same way as

§pdex-185 MAY A server MAY additionally restrict Bulk Data

§pdex-186 SHALL Health plans SHALL limit the data returned to

§pdex-187 SHALL Clients SHALL require OAuth client credentials to enable secure access to read

§pdex-188 SHALL SHALL be required to access the Group resources and the Bulk export operation.

§pdex-189 SHALL Access and Refresh Tokens SHALL be issued to support the client requesting and

§pdex-190 SHOULD Exchange SHOULD be registered in accordance with the approach defined in the

§pdex-191 SHALL A Payer that implements Payer-to-Payer Exchange for a single member — for example, to support legacy CMS-9115-style member-initiated payer-to-payer requests or any other use case for which single-member exchange is more appropriate than multi-member bulk exchange — SHALL do so by following the content provided in this section of the IG.

§pdex-192 SHALL Payers SHALL implement the Bulk Payer-to-Payer Exchange detailed in this IG on the Payer-to-Payer Bulk Exchange page to exchange information for multiple members.

§pdex-193 MAY MAY be used to exchange data for a SINGLE member.

§pdex-194 MAY Payer-to-Payer exchange for a single member MAY be accomplished by three methods.

§pdex-195 SHOULD Clients wishing to retrieve data SHOULD consult

§pdex-196 SHALL Each retrieval method for a single member SHALL be preceded by the use of the following interaction to match a member and provide consent:

§pdex-197 SHALL Health Plans SHALL support the $member-match operation.

§pdex-198 SHOULD A MemberId (Patient FHIR ID) SHOULD also be returned where available.

§pdex-199 SHALL
SHOULD When a member is successfully matched and consent can be complied with, the responding payer SHALL return a MemberIdentifier and SHOULD also return a MemberId (Patient FHIR ID) in the $member-match response.

§pdex-200 SHALL Implementers SHALL be prepared to handle $member-match responses that contain only a MemberIdentifier, or both a MemberIdentifier and a MemberId.

§pdex-201 SHOULD When a MemberId (Patient FHIR ID) is present in the response it SHOULD be used as the subject for the subsequent OAuth2.0 access token request.

§pdex-202 SHOULD Where only a MemberIdentifier is returned, the Authorization Server SHOULD resolve the business identifier to a Patient FHIR ID to scope the access token.

§pdex-203 SHALL NOT
SHALL Patient ID SHALL NOT be returned in the $member-match response and a 422 status code SHALL be

§pdex-204 MAY The receiving payer MAY store the Consent record for the member.

§pdex-205 SHOULD If a Consent is provided by an Authorized Representative, the person's demographic details SHOULD be included as

§pdex-206 SHOULD Representative SHOULD be identified as an actor with an appropriate SecurityRoleType, such as "DPOWATT",

§pdex-207 SHALL NOT
SHALL If the receiving payer matches to a unique member but is unable to comply with the consent request, a Patient ID SHALL NOT be returned in the $member-match response and a 422 status code SHALL be

§pdex-208 MAY When a member chooses to grant consent for a health plan to retrieve their health data from a prior health plan the proposed period of consent MAY be:

§pdex-209 SHALL Health Plan SHALL utilize the access token returned from the Member Access step to

§pdex-210 SHALL Each of the above data retrieval methods SHALL support the retrieval of the profiles and resources identified in the table below.

§pdex-211 SHALL Health Plans SHALL support search of a member's clinical data to each USCDI/US Core clinical resource,

§pdex-212 SHALL Health Plans SHALL support the use of the $everything operation.

§pdex-213 SHALL As noted in the previous section, $everything SHALL limit the data retrieved to that which the requester is permitted to access.

§pdex-214 SHALL The data returned by $everything for the requesting payer SHALL include the same set of resources and profiles as any other in-scope retrieval method (see

§pdex-215 SHOULD Payer-to-Payer Data Exchange SHOULD support the use of Bulk FHIR methods, as defined in the HL7 FHIR

§pdex-216 SHOULD The request/retrieval of data SHOULD use the FHIR Bulk Data Patient Level Export and theBulk Data Export Operation Request Flow.

§pdex-217 SHOULD The Patient Export Operation for Payer-to-Payer exchange SHOULD be constrained to the resources and profiles that the requester is permitted to access, such as the profiles identified in the table in the Data Retrieval Methods section of this page.

§pdex-218 SHALL The FHIR Server SHALL constrain the data returned from the server to a requester based upon the access permissions of the requester.

§pdex-219 SHALL For example, if a requester queries for ExplanationOfBenefit resources but they are only allowed to see Prior Authorization records, and not EOB Claims, the FHIR Server SHALL filter the data accordingly.

§pdex-220 SHOULD A public key SHOULD also be provided by the Trust Framework that is overseeing the Payer-to-Payer exchange process.

§pdex-221 SHOULD Where the organization is both the payer and the managing organization there SHOULD still be two Organization records created.

§pdex-222 SHOULD Where a MemberId (Patient FHIR ID) is returned from $member-match, it SHOULD be submitted to the Access Token Endpoint in the JWT sub claim.

§pdex-223 SHOULD The Authorization Server SHOULD use the Subject ID, confirm that consent for the Requesting Payer to access the Matched Member is still valid, and issue an access token scoped to that specific Patient FHIR ID, bounding any subsequent FHIR API request accordingly.

§pdex-224 SHOULD Where only a MemberIdentifier is returned, the Authorization Server SHOULD resolve the business identifier to a Patient FHIR ID to scope the access token appropriately.

§pdex-225 SHALL All resources and operations available via a FHIR API endpoint SHALL be declared in a FHIR CapabilityStatement.

§pdex-226 SHOULD for another member of the health plan, they SHOULD provide appropriate credentials to enable the exchange

§pdex-227 SHOULD Support for this option by Health Plan systems SHOULD be provided.

§pdex-228 SHOULD The SMART on FHIR app provided as a link from the returned CDS Hook SHOULD enable a clinician to

§pdex-229 SHOULD All requesters (e.g., EHRs) SHOULD store provenance associated with any data exchanged as part of this IG if

§pdex-230 SHALL The member SHALL authenticate using

§pdex-231 MAY While authenticated to the application or service, the member MAY connect to the (source) Health Plan's

§pdex-232 SHALL SHALL be presented with an Authorization screen that enables them to approve the sharing of information with

§pdex-233 SHALL The Authorization process, in accordance with applicable privacy policy, SHALL provide a mechanism to

§pdex-234 SHALL After successfully authorizing an application an Access Token and Optional Refresh Token SHALL be

§pdex-235 SHALL The scopes of the access token SHALL be restricted to the authorizing Member's information and the scopes approved.

§pdex-236 SHALL Any subsequent Access Token issued based on the Refresh Token SHALL be restricted (at least) to the same

§pdex-237 SHALL The requesting application SHALL use the access token to access the Health Plan's secure FHIR API to download

§pdex-238 SHOULD Clients wishing to retrieve data SHOULD consult the Data Provider's Server Capability Statement to

§pdex-239 SHOULD Payers SHOULD:

§pdex-240 MAY Payers MAY choose to exchange unstructured data with Patients and Providers, via their respective APIs,

§pdex-241a SHALL
SHOULD For the CMS-0057 Provider Access API obligation, payers SHALL support the v2 (Attestation) workflow described in the rest of this page, and providers/EHRs supporting in-network access to a payer's CMS-mandated Provider Access API SHOULD use the v2 workflow.

§pdex-241b SHOULD
MAY A provider/EHR that operates under both an in-network arrangement and a VBC contract with the same payer SHOULD use v2 (Attestation) for the CMS-mandated Provider Access exchange and MAY use v1 (Attribution) for VBC-driven data flows (for example, the financial-data exchanges described under

§pdex-242 MAY Although the CMS Prior Authorization Rule (CMS-0057) requires regulated plans to provide a bulk API that releases Clinical, Prior Authorization and Claims and Encounter data (without the financial data), where permitted by regulation or other agreements, the data MAY be configured to include financial data (including Allowed and

§pdex-243 MAY Rather than creating large, dynamic lists of members associated with a provider the health plan MAY maintain two types of lists:

§pdex-245 SHALL A payer SHALL be able to determine, at the time a $provider-member-match request is processed, whether each candidate member has opted out of Provider Access API data sharing.

§pdex-246 SHALL when an opt-out is revoked, the corresponding member entry SHALL be removed from whatever opt-out tracking mechanism the payer maintains (for payers using the FHIR Group pattern, that means removing the member's entry from the Group resource).

§pdex-247 MAY The Member-Provider TRL MAY be determined by referencing a legacy syystem or API.

§pdex-248 SHALL Where a payer chooses to use FHIR Group resources to manage the Treatment Relationship the Payer SHALL create a Member-Treatment Group conforming to the Member-Provider Treatment Relationship Group Profile that has the member as the "key" to the list (via a characteristic containing the Patient ID).

§pdex-249 SHALL The providers SHALL be represented as the cohort, or subjects in the list (as group members).

§pdex-250 SHALL This list SHALL then be used during a Provider-Member-Match operation to determine if the provider is permitted to retrieve data about the member.

§pdex-251 MAY The payer MAY apply their own rules for determining a Treatment Relationship.

§pdex-252 SHALL The payer SHALL apply opt-out and treatment-relationship determinations during a Provider-Member-Match Operation, using whatever mechanism is appropriate to the payer's environment (legacy system, vendor product, internal API, FHIR Group resources, or any combination).

§pdex-253 SHOULD - The payer SHOULD determine whether the provider is in-network, or has an appropriate contractual relationship.

§pdex-254 SHOULD - The payer SHOULD extract the rendering provider's NPI from the subject_id field of the UDAP B2B Authorization Extension Object (hl7-b2b) in the access token and verify it against the payer's provider directory before processing the $provider-member-match request.

§pdex-255 SHALL - Each member request SHALL contain:

§pdex-256 SHALL - The CoverageToMatch SHALL contain the Member's coverage information.

§pdex-257 SHALL - The Treatment attestation SHALL be submitted as a Consent resource conforming to the Provider Treatment Attestation Profile in each member request.

§pdex-258 SHALL - The health plan SHALL evaluate the request and determine:

§pdex-259 SHALL - When the member data passes these checks, the member SHALL be returned in the matched members response Group, which conforms to the Provider Member Match Group profile.

§pdex-260 SHALL The Group Id of the matched group SHALL be returned to the Provider upon completion of the operation.

§pdex-261 SHALL - Members who fail any check SHALL be returned in one of the response Group resources, distinguished by Group profile, subject to the privacy default below:

§pdex-261a SHOULD Where the payer determines that distinguishing 'opted out' from 'not matched' in the response would itself constitute a disclosure the member did not authorize (whether under applicable state privacy law, the member's stated preference, or the payer's privacy policy), the payer SHOULD suppress the ConsentConstrainedMembers Group and instead include the affected members in the NonMatchedMembers Group.

§pdex-262 SHALL - The provider SHALL use the Matched Group Id to make subsequent $davinci-data-export operation requests to retrieve data for all, or a subset, of members.

§pdex-263 MAY - Alternatively, the provider MAY perform a new Provider-Member-Match operation to receive a new Matched Member Group.

§pdex-264 MAY - The matched group resource MAY be a short-lived group.

§pdex-265 SHOULD - Implementer feedback is sought on whether requests for less than 10 members SHOULD be handled as an interactive request, with larger bulk requests being processed as an asynchronous process.

§pdex-266 SHALL - Providers SHALL be able to search and retrieve the contents of the Matched Member Group resource.

§pdex-267 SHALL - Providers SHALL assume that the Matched Group is short-lived and subsequent requests for member data SHALL be initiated by performing a member match operation to retrieve an updated Matched Group List.

§pdex-268 SHOULD When a health plan is using FHIR Groups to manage Treatment relationships they SHOULD create Member-Provider TRLs using the NPI data for the Rendering Provider.

§pdex-269 MAY Health plans MAY choose to include organizations or locations in a Member-Provider TRL.

§pdex-270 SHALL A health plan member SHALL be entitled to Opt-Out from their data being shared via the Provider Access API.

§pdex-271 MAY PDex defines a consent profile that MAY be used to enable a member to deny sharing via the Provider Access API.

§pdex-272 SHALL A member SHALL be able to update their preference

§pdex-273 SHALL When a member Opts-Out of sharing, the payer's opt-out tracking mechanism SHALL be updated so that subsequent $provider-member-match evaluations recognize the opt-out.

§pdex-274 SHALL If a member revokes their Opt-Out, the same mechanism SHALL be updated to remove the opt-out — i.e., the member's identifier is removed from the Member Opt-Out Group, or the legacy/internal API ceases to report the member as opted out.

§pdex-275 MAY Health Plans MAY implement the pdex-provider-consent profile to enable a member to express their data-sharing preference for the Provider Access API.

§pdex-276 SHALL If a Treatment Relationship is established and the member has not opted out, the member SHALL be returned in the matched members response Group, which conforms to the Provider Member Match Group profile.

§pdex-277 SHALL Members SHALL have the ability to opt-out of data sharing with providers.

§pdex-278 MAY - MAY use claims data as a source to identify existing Treatment Relationships.

§pdex-279 MAY - MAY utilize their own rules for determining a Treatment Relationship between members and Providers.

§pdex-280 MAY - MAY use the Coverage Requirements Discovery IG's appointment-book and encounter-start CDS Hooks as a means to determine impending treatment relationships.

§pdex-281 SHOULD SHOULD be supported:

§pdex-282 SHALL Access SHALL be controlled using client credentials that are compliant with SMART-On-FHIR.

§pdex-283 SHOULD Access SHOULD be restricted to Providers with a contractual relationship with a Payer.

§pdex-284 SHALL The $davinci-data-export operations SHALL be submitted using a HTTPS POST.

§pdex-285 SHALL The HTTPS Header SHALL include:

§pdex-286 SHALL The Payer SHALL be responsible for managing and maintaining the Treatment Relationship between

§pdex-287 SHALL The payer SHALL take account of members that have chosen to Opt-Out of

§pdex-288 SHALL Those Opted-Out members SHALL be included in a Member Opted-Out List.

§pdex-288a SHALL A responder SHALL include one or more Group ndjson files in the async completion manifest containing the matched / non-matched / consent-constrained Group resources (per the Provider Member Match Group, Provider Member No Match Group, and Member Opt-Out Group profiles), subject to the privacy default in

§pdex-289 SHOULD Prior Authorization Rule (CMS-0057) the data available through the API SHOULD include:

§pdex-290 SHALL - SHALL be issued with OAuth2.0/SMART-On-FHIR client credentials that enable access to /Group/{id}.

§pdex-291 SHALL - SHALL be permitted to GET /Group/{id} for the Matched Member Group list created by the Provider Member-Match operation.

§pdex-292 SHALL - SHALL be permitted to call $davinci-data-export operation for the /Group/{id} they received in the response to the Provider Member-Match operation.

§pdex-293 MAY Data MAY be constrained by:

§pdex-294 SHALL The Data Export operation SHALL check the consent status for each member at the time of execution.

§pdex-295 SHALL If the patient parameter is not provided data SHALL be retrieved for all members

§pdex-296 SHALL If the patient parameter is provided the operation SHALL ignore references

§pdex-297 SHALL The exportType parameter SHALL have one of the following values:

§pdex-298 SHALL The hl7.fhir.us.davinci-pdex#provider-delta option SHALL be used when the provider is

§pdex-299 SHALL When using provider-delta the provider client SHALL supply the _since parameter to scope the request to resources updated since their last retrieval.

§pdex-300 SHALL The hl7.fhir.us.davinci-pdex#provider-download option SHALL be used when the provider is

§pdex-301 SHOULD The hl7.fhir.us.davinci-pdex#provider-snapshot value SHOULD be used when a provider

§pdex-302 SHOULD Implementers SHOULD maintain an internal audit trail to record which export operations were executed and by which client.

§pdex-303 SHOULD The _since parameter SHOULD be used for resource requests when the full history is not

§pdex-304 MAY It is expected that providers MAY first request data for members without

§pdex-305 MAY Subsequent requests MAY then use _since

§pdex-306 MAY The _until parameter MAY be used less frequently.

§pdex-307 MAY The _type parameter MAY be used to restrict the resources retrieved by the Provider.

§pdex-308 SHALL parameter is not used all available resources SHALL be returned by the Payer, subject to

§pdex-309 MAY The _typeFilter parameter MAY be used to further restrict the resources retrieved by the

§pdex-310 SHALL used, SHALL comprise one, or more, valid FHIR search queries for the respective resource

§pdex-311 SHALL supported by the relevant profiles from the PDex, US Core or CARIN Blue Button IGs SHALL

§pdex-312 SHOULD Implementers SHOULD implement OAuth 2.0 access management in accordance with the SMART Backend Services

§pdex-313 SHALL Output File Requests with requiresAccessToken=true SHALL be protected the same way the Bulk Data Kick-off Request,

§pdex-314 MAY A server MAY

§pdex-315 SHALL Health plans SHALL limit the data returned to

§pdex-316 SHALL Clients SHALL require OAuth client credentials to enable secure access to read and search the Group

§pdex-317 SHALL Access Tokens SHALL be required to access the Group

§pdex-318 SHOULD Access and Refresh Tokens SHOULD be issued to support

§pdex-319 SHOULD Exchange SHOULD be registered in accordance with the approach defined in the

§pdex-320 SHOULD When the protocols detailed in the above UDAP Security IG's Business to Business section are used, the subject_id in the B2B Authorization Extension Object (Key Name: "hl7-b2b") SHOULD contain the NPI of the rendering provider on whose behalf member data is being requested.

§pdex-321 MAY For requests covering more than a single rendering provider (e.g., an organization-level request), the subject_id MAY be the FHIR Id of the Group being requested.

§pdex-322 SHOULD The payer SHOULD validate the NPI supplied in the subject_id against their provider directory to confirm the provider is known, active, and has an in-network or contractual relationship before issuing an access token or processing a $provider-member-match request.

§pdex-323 MAY regulation or other agreements, the data MAY be configured to include financial data (including Allowed and

§pdex-324 MAY Health plans MAY choose to construct alternative or additional Attribution

§pdex-325 SHOULD A member SHOULD also be able to update their preference

§pdex-326 MAY Health Plans MAY implement the pdex-provider-consent profile to enable a member to express their data-sharing preference for the Provider Access API.

§pdex-327 SHALL Members SHALL have the ability to opt-out of data sharing with providers.

§pdex-328 SHOULD Attribution Lists SHOULD be

§pdex-329 MAY A health plan MAY adopt their own methodology for managing and maintaining

§pdex-330 MAY - MAY use claims data as a source to identify existing treatment relationships.

§pdex-331 MAY - MAY utilize their own rules for determining the attribution of members to Providers.

§pdex-332 SHOULD - SHOULD use the Coverage Requirements Discovery IG's appointment-book and encounter-start CDS Hooks as a means to determine impending treatment relationships.

§pdex-333 SHALL Attribution lists SHALL be searchable via a secure RESTful API.

§pdex-334 SHOULD attribution lists SHOULD be scoped to the appropriate Organization, Facility, Provider or their

§pdex-335 SHOULD SHOULD be supported:

§pdex-336 SHALL Access SHALL be controlled using client credentials that are compliant with SMART-On-FHIR.

§pdex-337 SHOULD Access SHOULD be restricted to Providers with a contractual relationship with a Payer.

§pdex-338 SHALL The $davinci-data-export operations SHALL be submitted using a HTTP POST.

§pdex-339 SHALL The HTTP Header SHALL include:

§pdex-340 SHALL The $davinci-data-export operation SHALL be performed asynchronously, following the Asynchronous Request Pattern defined in FHIR R4.

§pdex-341 SHALL Implementers SHALL follow the Bulk Data Status Request guidance for polling behavior.

§pdex-342 SHALL The Payer SHALL be responsible for managing and maintaining the attribution list that assigns

§pdex-343 SHALL The payer SHALL take account of members that have chosen to Opt-out of

§pdex-344 SHALL Those opted-out members SHALL be omitted from the Provider

§pdex-345 MAY The Payer MAY choose to maintain a separate Group resource for a Provider

§pdex-346 MAY A provider MAY have more than one list.

§pdex-347 SHALL The PDexProviderGroup profile SHALL be used to record the

§pdex-348 MAY By recording this quantity it MAY help providers reconcile their attribution lists

§pdex-349 SHOULD Implementers SHOULD maintain an internal audit trail to record which export operations were executed, by which client, and for which members.

§pdex-350 SHALL Implementers SHALL support the Group search parameters enumerated in the PDex Server CapabilityStatement (and its US Core 6.1.0 variant, pdex-server-6-1) for the Group resource — at minimum identifier and characteristic — both of which are declared with SHALL support expectations there.

§pdex-351 SHOULD Prior Authorization Rule (CMS-0057) the data available through the API SHOULD include:

§pdex-352 SHALL - SHALL be issued with OAuth2.0/SMART-On-FHIR client credentials that enable access to /Group/{id}.

§pdex-353 SHALL - SHALL be permitted to SEARCH /Group.

§pdex-354 SHALL The search function and the bundle contents returned SHALL be restricted to the {ids} that are associated with the Provider Representative's account.

§pdex-355 MAY - MAY be associated with more than one attribution group list.

§pdex-356 SHALL - SHALL be permitted to GET /Group/{id} for any Attribution Group list they are associated with.

§pdex-357 SHALL - SHALL be permitted to call $davinci-data-export operation for any /Group/{id} they are associated with.

§pdex-358 SHALL The Data Export operation SHALL check the consent status for each member at the time

§pdex-359 SHALL If the patient parameter is not provided data SHALL be retrieved for all members

§pdex-360 SHALL If the patient parameter is provided the operation SHALL ignore references

§pdex-361 SHALL The exportType parameter SHALL have one of the following values:

§pdex-362 SHALL The hl7.fhir.us.davinci-pdex#provider-delta option SHALL be used when the provider is

§pdex-363 SHALL When using provider-delta the provider client SHALL supply the _since parameter to scope the request to resources updated since their last retrieval.

§pdex-364 SHALL The hl7.fhir.us.davinci-pdex#provider-download option SHALL be used when the provider is

§pdex-365 SHOULD The hl7.fhir.us.davinci-pdex#provider-snapshot value SHOULD be used when a provider

§pdex-366 SHOULD Implementers SHOULD maintain an internal audit trail to record which export operations were executed and by which client.

§pdex-367 SHOULD The _since parameter SHOULD be used for resource requests when the full history is not

§pdex-368 MAY It is expected that providers MAY first request data for members without

§pdex-369 MAY Subsequent requests MAY then use _since

§pdex-370 MAY The _until parameter MAY be used less frequently.

§pdex-371 MAY The _type parameter MAY be used to restrict the resources retrieved by the Provider.

§pdex-372 SHALL parameter is not used all available resources SHALL be returned by the Payer, subject to

§pdex-373 MAY The _typeFilter parameter MAY be used to further restrict the resources retrieved by the

§pdex-374 SHALL used, SHALL comprise one, or more, valid FHIR search queries for the respective resource

§pdex-375 SHALL supported by the relevant profiles from the PDex, US Core or CARIN Blue Button IGs SHALL

§pdex-376 SHOULD Implementers SHOULD implement OAuth 2.0 access management in accordance with the SMART Backend Services

§pdex-377 SHALL Output File Requests with requiresAccessToken=true SHALL be protected the same way the Bulk Data Kick-off Request,

§pdex-378 MAY A server MAY

§pdex-379 SHALL Health plans SHALL limit the data returned to

§pdex-380 SHALL Clients SHALL require OAuth client credentials to enable secure access to read and search the Group

§pdex-381 SHALL Access Tokens SHALL be required to access the Group

§pdex-382 SHOULD Access and Refresh Tokens SHOULD be issued to support

§pdex-383 SHOULD Exchange SHOULD be registered in accordance with the approach defined in the

§pdex-384 MAY When providers are building a health history for a new patient the information they are interested in MAY include:

§pdex-385 MAY For example, as part of an event or episode of care the provider MAY be interested in the following types of data:

§pdex-386 MAY Where a payer elects to exchange any of the data types listed above, the table below identifies the FHIR R4 / US Core profile that the payer MAY use for each.

§pdex-387 SHOULD A payer SHOULD provide the most recent version of the Patient, Practitioner, Organization and Location resources.

§pdex-388 MAY A payer MAY choose to support FHIR resource data versioning in their API including Patient, Practitioner, Organization and Location resources.

§pdex-389 SHOULD In such cases resources SHOULD follow the vread guidance in the HTTP section of the FHIR specification.

§pdex-390 SHALL If a payer chooses to support FHIR resource data versioning of related resource references, the referring resource SHALL use the vread format of reference:

§pdex-391 MAY In this scenario the Clinician that reviews the Member History is only interested in information in the Member record since their last visit and MAY want to exclude information from their own organization, since that information will already be recorded in their EMR system.

§pdex-394 SHALL SHALL support searching for code for a Group.

§pdex-395 SHALL Payers SHALL make available pending and active prior authorization decisions and related clinical documentation and forms for items and services, not including prescription drugs, including the date the prior authorization was approved, the date the authorization ends, as well as the units and services approved and those used to date, no later than one (1) business day after a provider initiates a prior authorization for the beneficiary or there is a change of status for the prior authorization.

§pdex-396 SHALL SHALL support searching for code for a Group.

§pdex-397 SHALL This operation SHALL be performed asynchronously following the FHIR Asynchronous Request Pattern.

§pdex-398 SHALL Input parameters SHALL conform to the PDex Multi-Member Match Request profile.

§pdex-399 SHALL Output parameters SHALL conform to the PDex Multi-Member Match Response profile.

§pdex-400 SHALL Input parameters SHALL conform to the Provider $multi-member-match Request profile.

§pdex-401 SHALL Output parameters SHALL conform to the Provider $multi-member-match Response profile.

Id	Expectation	Rule
§1	SHALL	pdex-35: SHALL* be used to express a member's demographic information.
§2	MAY	pdex-63: - The returned information MAY include a link to a SMART-on-FHIR App to enable selection of resources by the Clinician that will be written to the Clinician’s EMR system
§3	MAY	pdex-64: - The information card MAY include a link to launch the SMART-on-FHIR App using the appContext to enable the Clinician to query information about their patient using the Health Plan’s FHIR API.
§4	SHALL SHOULD	pdex-168 listed essentially the same payload as "SHALL be available" but mentioned only US Core 3.1.1, which had the effect of imposing a hard requirement on US Core 3.1.1. Per CMS-0057 the Payer-to-Payer payload is mandatory, so the SHALL strength is correct and the SHOULD was wrong. Resolved by collapsing the two into a single canonical conformance expectation:
§5	MAY	pdex-386 to descriptive MAY language: "Where a payer elects to exchange any of the data types listed above, the table below identifies the FHIR R4 / US Core profile that the payer MAY use for each", with an explicit follow-up sentence stating that the page is informative, that nothing in the table adds normative obligations beyond those imposed by the relevant regulation or by the operation-specific pages of this IG, and that listing data types outside regulatory scope is purely illustrative. The
§6	SHOULD	pdex-05 (PDex Provenance, "A Provenance resource SHOULD be provided with each member-related resource…") and
§7	SHALL SHOULD	pdex-241a (payers SHALL support v2 for the CMS-0057 Provider Access API obligation; in-network providers/EHRs SHOULD use v2) and
§8	MAY	pdex-326 (v1) to MAY to match
§9	SHALL	pdex-127 to make the per-exchange / per-bundle scope explicit: "For each PDex information exchange, the Health Plan SHALL provide at least one `Provenance` resource naming the Health Plan as the Transmitter of the data — i.e., a `Provenance` whose `agent[].type` includes a `Transmitter` entry and whose `agent.who` references the Health Plan's `Organization`, with `target[]` referencing the resources transmitted in the exchange. This is an exchange-level (per-bundle) obligation: a single Transmitter Provenance per exchange satisfies
§10	SHALL	pdex-127 (per-exchange SHALL) and
§11	SHALL	pdex-127 (per-exchange SHALL) and ^§10
§12	SHALL	pdex-210 immediately above it, which states that each of the three retrieval methods (individual queries / `$patient-everything` / Bulk FHIR) SHALL support the same profiles and resources. The accompanying `_type` example list compounded the error by omitting `ExplanationOfBenefit` entirely. Resolved by (i) rewording
§13	SHALL	pdex-132 itself as the response-content requirement: "In both the Provider Access API and the Payer-to-Payer API, any Prior Authorization whose status has changed in the previous 12 months (measured from the date of the request) SHALL be included in the API response." A trailing sentence notes that
§14	SHALL	pdex-133 now reads "Active and pending Prior Authorizations exchanged via the Payer-to-Payer Exchange API SHALL include the related clinical documentation and forms used in support of the prior authorization decision";
§15	SHALL NOT	7.5.2.1 (Cross-Referencing Match Results with Submitted Members) — and the parallel FSH `^comment` on `Group.contained` for both `PDexMemberMatchGroup` and `PDexMemberNoMatchGroup`: the absolute "Responders SHALL NOT abridge, modify, or substitute the submitted Patient resource" at
§16	MAY	7.5.5.1.4 (`_typeFilter`): the submitter asked whether the MAY in
§17	MAY	pdex-180 is now restricted to the requester's choice (a requesting Payer MAY include `_typeFilter`); new
§18	SHALL SHOULD MAY	7.5.2 — "Bulk Member Match with Consent"): the responder SHALL include the Group resources as Group ndjson files in the async completion manifest (matching the current STU 2.2.0 format that fits the FHIR R4 Asynchronous Request Pattern naturally), and MAY additionally include a `Parameters` ndjson file (with manifest `output[]` `"type": "Parameters"`) containing a `PDexMultiMemberMatchResponseParameters`-conformant Parameters resource that wraps the same Group resources, so a single response can serve both STU 2.1.0-style requesters and STU 2.2.0-style requesters from one responder. A new "Backwards-compatible Parameters envelope (optional)" subsection records the trade-off and instructs requesters that consume both formats to SHOULD prefer the Group ndjson files. The OperationDefinition is unchanged (it already declares no inline out parameters because the output is delivered via the async manifest). The parallel "Operation Definition" paragraph at
§19	SHALL MAY	pdex-138 (Out: line) is also updated. Modification — Level A cross-operation alignment. Because implementers are converging Payer-to-Payer foundations into Provider Access deployments, the same Group-ndjson-SHALL + Parameters-ndjson-MAY allowance has been extended to the Provider Access v2 `$provider-member-match` operation (new
§20	SHALL	pdex-252 rewritten to remove the contradictory "SHALL be used, unless …" pattern; payers using legacy systems are explicitly conformant. (v)
§21	SHOULD	pdex-84: Health Plans SHOULD accept and retain Provenance records received with data based on Member-authorized Payer-to-Payer exchange.
§22	SHOULD	pdex-85: Health Plans SHOULD accept and retain Provenance records received with data from sources other than Member-authorized Payer-to-Payer exchange.
§23	SHOULD	pdex-86: When a Health Plan forwards information as a FHIR Resource it SHOULD create related Provenance record(s) to reflect the original source of the data.
§24	SHALL	pdex-102: For querying and reading PDex and US Core Profiles, Must Support on any profile data element SHALL be interpreted as follows:
§25	SHALL	Where a requester supplies an out-of-range date-of-service filter via `_typeFilter`, the responder SHALL still apply the
§26	SHALL NOT MAY	A client that wishes to retrieve only a subset (for example, only Prior Authorization records, or only claims) MAY narrow the response by supplying the `_type` parameter or by filtering client-side after retrieval. The server SHALL NOT silently exclude claim `ExplanationOfBenefit` records from the response unless the requester is not permitted to access them under
§27	SHOULD	pdex-241: The Provider-Member-Match operation SHOULD be submitted as a first step.
§28	SHOULD	pdex-241: The Provider-Member-Match operation SHOULD be submitted as a first step. ^§27
§pdex-01	SHOULD	perform this match operation multiple times and SHOULD only be granted access to data for the matched
§pdex-02	SHALL	The Da Vinci PDex MedicationDispense profile SHALL be used to record a member's prescription drug claims when sharing data using
§pdex-03	SHOULD	to exchange data the US Core MedicationDispense profile SHOULD be used.
§pdex-04	SHOULD	When a Health Plan forwards information as a FHIR Resource it SHOULD create related Provenance record(s) to reflect the original source.
§pdex-05	SHOULD	A Provenance resource describing the upstream origin (Author or Source) SHOULD be provided with each member-related resource provided by the Health Plan's FHIR API.
§pdex-06	SHOULD	This SHOULD be used to:
§pdex-07	SHOULD	Provenance.recorded value SHOULD be the date/time when the data is received by the payer.
§pdex-08	SHOULD	The Pdex Provenance record SHOULD be populated with the following essential fields (Must Support or Cardinality greater than 0..*) as follows:
§pdex-09	SHOULD	SHOULD be written to a FHIR server and the records assigned new FHIR IDs with references being re-written to maintain referential integrity.
§pdex-10	SHALL	The Health Plan SHALL accept and maintain Provenance information associated with information received from contributing entities.
§pdex-11	SHALL	The Health Plan SHALL add Provenance record(s) as necessary to document relevant actions taken as the current custodian of the information.
§pdex-12	SHALL	Provenance information SHALL be available for any information requested by an external entity as part of exchanges conformant to this implementation guide.
§pdex-13	SHALL	This guide SHALL define extensions to the provenance value sets as required to document the provenance of the information exchange.
§pdex-14	SHOULD	The Health Plan SHOULD create a Provenance Record documenting the source of the records, the identity of the health plan and the action taken to become the custodian of the data.
§pdex-15	SHOULD	The updated Provenance record SHOULD be passed on to any downstream entity that requests Provenance information for the records they request.
§pdex-16	SHOULD	The Health Plan SHOULD store the Provenance information and maintain the correlation or links to the records the Provenance Record is documenting.
§pdex-17	SHOULD	The Health Plan SHOULD update the Provenance records to add information covering the identity of the health plan and the action taken to become the custodian of the data.
§pdex-18	SHOULD	The updated Provenance record SHOULD be passed on to any downstream entity requesting the associated records.
§pdex-19	SHOULD	The Health Plan SHOULD create a Provenance Record documenting the source of the records, the identity of the health plan and the action taken to transform the data to FHIR Clinical Resources.
§pdex-20	SHOULD	The updated Provenance record SHOULD be passed on to any downstream entity requesting the associated records.
§pdex-21	SHALL	SHALL be used to record them.
§pdex-22	SHALL	Where a Health Plan has access to Care Plan information for a member, they SHALL make the information available using the US Core CarePlan resource.
§pdex-23	SHALL	Where a Health Plan has access to Information about the CareTeam for a member they SHALL make the information available using the
§pdex-24	MAY	For discrete procedures or encounters it MAY not be appropriate to create a CareTeam record from the claims information.
§pdex-25	SHALL	Where a Health Plan has access to Laboratory Results and other diagnostic information, they SHALL make the information available using the US Core DiagnosticReport for Laboratory Results Reporting resource.
§pdex-26	SHALL	Where a Health Plan has access to clinical notes and associated diagnostic information, they SHALL make the information available using the US Core DiagnosticReport for Report and Note Exchange resource.
§pdex-27	SHALL	The Health Plan SHALL use the
§pdex-28	SHALL	Where a Health Plan has access to structured and coded Immunization information for a member, the health plan SHALL present the information using the
§pdex-29	SHALL	Where a Health Plan has information about devices used by the Member that information SHALL be published using the
§pdex-30	SHALL	It identifies which core elements, extensions, vocabularies and value sets SHALL be present in the resource when using this profile.
§pdex-31	SHALL	SHALL be used to record location/facility-specific information.
§pdex-32	SHALL	Where a Health Plan has access to Medication information, they SHALL make the information available using the
§pdex-33	SHALL	Where a Health Plan has access to Prescription information, they SHALL make the information available using the
§pdex-34	SHOULD	SHOULD use the
§pdex-36	SHALL	The code MB SHALL be used to identify the member identifier.
§pdex-37	SHALL	SHALL be used to record information about Practitioners.
§pdex-38	SHALL	SHALL be used to record information about the roles that practitioners take in providing services to their patients.
§pdex-39	SHALL	SHALL be used to record a member's health events.
§pdex-40	SHOULD	Note: Procedure records SHOULD only be created from ExplanationOfBenefit or CPCDS resources for items that are clinical procedures.
§pdex-41	SHOULD NOT	Medications, facility charges and supplies SHOULD NOT be created as procedure records.
§pdex-42	SHALL	In all other cases a payer SHALL create a PDex Provenance profile that identifies their role as a "Transmitter" of the information.
§pdex-43	MAY	This IG uses a combination of CDS-Hooks and SMART-on-FHIR to enable Providers to issue a query to a Health Plan and to retrieve information about their patient (the Health Plan member) that they MAY review and choose to commit to the patient record in their EMR.
§pdex-44	SHALL	When interacting with EMR systems that support FHIR R4 the SMART App SHALL evaluate the EMR System's CapabilityStatement that the implementation has deemed relevant to this SMART-on-FHIR application to determine which of the records selected by the Provider can be written to the EMR via the FHIR API.
§pdex-45	SHOULD	Where the EMR's FHIR API does not enable the SMART App to write a resource via the API, the SMART App SHOULD write the records that it is permitted to write to the API.
§pdex-46	SHOULD	The remaining selected records SHOULD be retained in the EMR in the most appropriate form to allow the provider access to the information when needed.
§pdex-47	SHALL	The Payer's CDS Hooks service SHALL handle the content in the JSON hooks payload, regardless of version of FHIR used for incorporated resources.
§pdex-48	SHALL	The health plan's CDS Hooks service SHALL provide access to FHIR R4 resources based on Profiles identified in the US Core, Da Vinci PDex and HRex IGs.
§pdex-49	MAY	The SMART-on-FHIR App that MAY be called from the returned CDS Hooks card will not translate R4 profiles to earlier versions of FHIR.
§pdex-50	SHALL	When interacting with EMR systems that support FHIR R4 the SMART App SHALL evaluate the EMR System's CapabilityStatement to determine which of the records selected by the Provider can be written to the EMR via the FHIR API.
§pdex-51	SHALL	The remaining selected records SHALL be compiled into a FHIR bundle, a PDF SHALL be created to provide a human-readable version of the bundle and both documents SHALL be attached as a DocumentReference and committed to the patient's record.
§pdex-52	SHALL	Where an EMR providing an R4 API prevents the attaching of a FHIR bundle to a DocumentReference the SMART APP SHALL attempt to write the selected records based upon the options listed below for graceful write degradation.
§pdex-53	SHALL	When interacting with EMR systems that support FHIR versions prior to FHIR R4 the SMART App SHALL, where permitted by the target EMR, create a DocumentReference and encapsulate a PDF, human-readable version of the records being committed, together with a document bundle that encapsulates the FHIR resources from the health plan that the provider has selected to commit to the patient's record.
§pdex-54	SHALL	Where the EMR does not support the attachment of FHIR Bundles to a DocumentReference record the SMART App SHALL create a human-readable PDF version of the selected resources then attach this document to the DocumentReference and commit to the patient's record.
§pdex-55	SHALL	Where the EMR does not support the attachment of PDF Documents to a DocumentReference record the SMART App SHALL create an HTML or XHTML document that contains the selected resources then attach this document to the DocumentReference and commit to the patient's record.
§pdex-56	SHALL	Where the EMR does not support the attachment of HTML/XHTML documents to a DocumentReference record the SMART App SHALL create a human-readable ASCII text version of the selected resources then attach this to the DocumentReference and commit to the patient's record.
§pdex-57	SHOULD	Subscriber Id or Member Id, if available, SHOULD be taken from the Patient's Coverage record, or be manually entered by the Provider via the SMART-on-FHIR App.
§pdex-58	SHOULD	If the Member Id is not available, the Subscriber ID and the patient information from the Coverage.beneficiary element SHOULD be used to uniquely identify the member.
§pdex-59	SHALL	Sharing of Member health information via PDex SHALL use the CDS Hooks specification.
§pdex-60	SHALL	Connection to health plan systems SHALL be supported via the following hook:
§pdex-61	SHOULD MAY	Any identifiers associated with the coverage for the patient (which may include patient demographics) SHOULD be obtained from the FHIR Coverage record for the patient, or MAY be entered manually by the provider via the SMART-on-FHIR App.
§pdex-62	SHOULD	PDex supports three common scenarios where CDS Hooks SHOULD be used:
§pdex-65	MAY	The SMART-on-FHIR App MAY be configured with default FHIR search queries that can be set by the Clinician, or their organization.
§pdex-66	MAY	Examples of preset search query parameters MAY include, but are not limited to:
§pdex-67	MAY	Any valid FHIR search query for a Patient MAY be constructed by the Provider.
§pdex-68	SHALL	As a minimum, the Health Plan's FHIR API SHALL limit returned results to the records that are related to the Patient/Member that is the subject of the Provider query.
§pdex-69	SHOULD	As a minimum, search of FHIR Resources SHOULD support the following query parameters where appropriate for a Resource Type:
§pdex-70	MAY	Health plans and clients MAY support additional hooks, additional card patterns, additional resources, additional extensions, etc.
§pdex-71	MAY	While it is expected that health plans MAY implement their own processes and communication methods to track and act upon a member opting out of Provider Access API data sharing, the following profile is provided as an example of a Consent resource that could be used to express a member opt-out.
§pdex-72	MAY	This MAY be used by a member portal, or consumer app to communicate an opt-out from Provider Access sharing.
§pdex-73	MAY	Coverage.identifier MAY include a member identifier in the Coverage resource.
§pdex-74	SHALL	Health Plans SHALL map clinical information for a member to US Core v3.1.1, US Core v6.1.0 or US Core v7.0.0 FHIR Resources based on R4.
§pdex-75	SHALL	Health Plans SHALL map claims and encounter data to the non-financial ExplanationOfBenefit BASIS profiles defined in the CARIN Consumer Directed Payer Data Exchange IG.
§pdex-76	SHALL	Health Plans SHALL map prior authorization information to the PDex Prior Authorization profile.
§pdex-77	MAY	As those profiles mature and achieve adoption, they MAY be offered up to US Realm for incorporation into a future version of US Core.
§pdex-78	SHALL	Where a US Core 3.1.1. FHIR R4, US Core 6.1.0. FHIR R4 or US Core 7.0.0. FHIR R4 Resource is not defined for clinical data, Health Plans SHALL map to FHIR Profiles defined in this IG, or the Da Vinci HRex IG.
§pdex-79	SHOULD	Oral and vision information are considered part of the Health Plan record for a specific member and, when it is available, SHOULD be included in the Payer-to-Payer and Provider Access exchanges described in this IG, using the BASIS profiles defined in the CARIN Consumer Directed Payer Data Exchange IG (CARIN IG for Blue Button®).
§pdex-80	SHALL	If a field is marked as required (cardinality n.., where n>0) the Health Plan SHALL populate the field.
§pdex-81	SHALL	For a field specified as MUST SUPPORT and the cardinality is 0.., the Health Plan SHALL be capable of populating the field and do so if the relevant data exists.
§pdex-82	SHALL	Where a field contains sub-field elements that are marked as MUST SUPPORT but the parent element has a cardinality of 0..n, where n is 1 or greater, the health plan SHALL provide data for the MUST SUPPORT sub-elements, only if it is providing data for the parent element.
§pdex-83	SHALL	If a field is marked as MUST SUPPORT the receiver SHALL be able to consume it without generating an error.
§pdex-87	SHOULD	A Provenance resource describing the upstream origin (Author or Source) of each member-related resource SHOULD be provided with that resource when the Health Plan's FHIR API serves it — particularly when the requester adds the `_revinclude=Provenance:target` parameter to a search query.
§pdex-88	SHOULD	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:
§pdex-89	SHALL	Implementers and testers of this specification SHALL abide by the license requirements for each terminology content artifact utilized within a functioning implementation.
§pdex-90	SHALL	Terminology licenses SHALL be obtained from the Third-Party IP owner for each code system and/or other specified artifact used.
§pdex-91	SHALL	SHALL indicates requirements that must be met to be conformant with the specification.
§pdex-92	SHOULD	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.
§pdex-93	MAY	MAY describes optional behaviors that are free to consider but where there is no recommendation for, or against, adoption.
§pdex-94	SHALL	The CMS Interoperability and Patient Access Rule requires that a member new to a health plan SHALL be able to request that their information be passed from their old health plan to their new health plan.
§pdex-95	SHALL	A Member SHALL also be able to use APIs to share information with Third Party Applications.
§pdex-96	SHALL	Therefore, for profiles and APIs identified in this IG, the FHIR R4 version SHALL be used.
§pdex-97	SHOULD	The FHIR Resources that comprise the Member Clinical and Claims-derived history, otherwise referred to as the "Member Health History" SHOULD include the following profiles where payers have data to support the use of those profiles:
§pdex-98	SHALL	All resources available via a FHIR API endpoint SHALL be declared in a FHIR CapabilityStatement.
§pdex-99	SHALL	The Read and Search Operations SHALL be supported for the FHIR Profiles covered in this payload section.
§pdex-100	MAY	The V-Read and History operations MAY be supported.
§pdex-101	SHALL SHOULD MAY	This implementation guide uses specific terminology such as SHALL, SHOULD, MAY to flag statements that have relevance for the evaluation of conformance with the guide.
§pdex-103	SHALL	PDex Responders SHALL be capable of populating all data elements as part of the query results as specified by the PDex and US Core Server Capability Statement.
§pdex-104	SHALL	PDex Requestors SHALL be capable of processing resource instances containing the data elements without generating an error or causing the application to fail.
§pdex-105	SHOULD	In other words PDex Requestors SHOULD be capable of displaying the data elements for human use or storing it for other purposes.
§pdex-106	SHALL NOT	In situations where information on a particular data element is not present and the reason for absence is unknown, PDex Responders SHALL NOT include the data elements in the resource instance returned as part of the query results.
§pdex-107	SHALL	When querying PDex Responders, PDex Requestors SHALL interpret missing data elements within resource instances as data not present in the PDex Responder’s system.
§pdex-108	SHALL	In situations where information on a particular data element is missing and the PDex Responder knows the precise reason for the absence of data, PDex Responders SHALL send the reason for the missing information using values (such as nullFlavors) from the value set where they exist or using the dataAbsentReason extension.
§pdex-109	SHALL	PDex Requestors SHALL be able to process resource instances containing data elements asserting missing information.
§pdex-110	SHOULD	A Health Plan's Pharmacy Network SHOULD be expressed using the same FHIR profiles used for the Healthcare Network Directory.
§pdex-111	SHALL	When a Member is authorizing sharing of the Member Health History with another Health Plan, or a Third Party Application, via the OAuth 2.0 protocol the Health Plan that is operating the API SHALL offer the Member an option to allow the sharing of sensitive information, such as behavioral health data, resulting in the data being shared excluding sensitive data that is covered by state and/or federal regulations.
§pdex-112	SHALL	The member SHALL authenticate using credentials they have been issued by, or accepted by the Health Plan.
§pdex-113	SHALL	After authenticating the Member SHALL be presented with an Authorization process that enables them to approve the sharing of information with the Third Party, or new Health Plan, Application that has client application credentials registered with the Health Plan.
§pdex-114	SHALL	The Authorization process SHALL provide the ability for the authorized representative to designate a third-party application that will have access to all information permitted by current state and federal regulations.
§pdex-115	SHALL	After successfully authorizing an application an Access Token and Optional Refresh Token SHALL be returned to the requesting application.
§pdex-116	SHALL	The requesting application SHALL use the access token to access the Health Plan's secure FHIR API to download the information that the Member is allowed to access.
§pdex-117	MAY	The application owner MAY be:
§pdex-118	SHALL	NOTE: exportType parameter SHALL be populated with a value for all PDex implementations of the $Davinci-data-export-operation.
§pdex-119	SHALL	All data exchanged by Health Plans using the interactions covered in this IG SHALL be transformed to FHIR R4 resources.
§pdex-120	MAY	Health Plans MAY have both data from clinical and claims sources that they store in their Systems of Record.
§pdex-121	SHOULD	Payers SHOULD look at the data they maintain and ensure that information relevant to the member’s care and treatment over time is accurately represented – in this way, it may not be appropriate to include a single data element only once across multiple events.
§pdex-122	SHALL	The member SHALL authenticate using credentials that have been issued by or are recognized and accepted by the Health Plan.
§pdex-123	SHALL	After authenticating the Member SHALL be presented with an Authorization screen that enables them to approve the sharing of information with the Third Party, or new Health Plan Application that has client application credentials registered with the Health Plan.
§pdex-124	SHALL	The use of the Bulk FHIR specification for transmission of member data SHALL honor jurisdictional and personal privacy restrictions that are relevant to a member's health record.
§pdex-125	SHOULD	Health Plans SHOULD accept and retain provenance records that they receive as part of any exchange of FHIR data.
§pdex-126	SHOULD	Where a FHIR Provenance resource is not provided, such as when data is received from other non-FHIR sources, the Health Plan SHOULD create FHIR Provenance record(s) to identify the source of the information being exchanged.
§pdex-127	SHALL	For each PDex information exchange, the Health Plan SHALL provide at least one `Provenance` resource naming the Health Plan as the Transmitter of the data — i.e., a `Provenance` whose `agent[].type` includes a `Transmitter` entry and whose `agent.who` references the Health Plan's `Organization`, with `target[]` referencing the resources transmitted in the exchange.
§pdex-128	SHOULD	In the case of historical data, the Health Plan SHOULD identify the author, source and source format of the data.
§pdex-129	SHALL	Bulk Payer-to-Payer exchange SHALL be accomplished using the asynchronous bulk-data delivery semantics defined in the HL7 FHIR Bulk Data Access Implementation Guide STU2 (2.0.0) — that is, operation kick-off via HTTP POST, status polling per the FHIR R4 Asynchronous Request Pattern, and a completion manifest referencing one or more NDJSON output files.
§pdex-130	SHALL MAY	Accordingly, a requesting health plan SHALL request data covering at least the 5-year window before the date of the request, and a responding health plan SHALL be capable of returning at least the past 5 years of in-scope data so that requestors can meet that obligation. A requestor MAY request, and a responder MAY return, data with a date of service older than 5 years.
§pdex-131	SHALL	Prior Authorizations SHALL be limited to current/active Prior Authorizations in addition to Prior Authorizations that have changed status within the last year, as of the date of request for information.
§pdex-132	SHALL	In both the Provider Access API and the Payer-to-Payer API, any Prior Authorization whose status has changed in the previous 12 months (measured from the date of the request) SHALL be included in the API response.
§pdex-133	SHALL	Active and pending Prior Authorizations exchanged via the Payer-to-Payer Exchange API SHALL include the related clinical documentation and forms used in support of the prior authorization decision.
§pdex-134	SHALL	The supporting documentation SHALL include both structured and unstructured documentation — for example, clinical notes, lab reports, imaging interpretations, signed administrative forms, and other attachments — that was used in the prior authorization determination.
§pdex-135	SHALL	The data available to be returned by the Bulk Payer-to-Payer Exchange API SHALL
§pdex-136	SHALL	This operation SHALL run asynchronously and upon completion returns Group resources categorizing members as matched, non-matched, or consent-constrained.
§pdex-137	SHALL	Both operations follow the FHIR Asynchronous Request Pattern: each kick-off request returns an HTTP 202 Accepted response with a `Content-Location` header pointing to a status endpoint that clients SHALL poll to retrieve the completed result.
§pdex-138	SHALL	The requesting (or New) health plan SHALL request permission (i.e., consent) from the Member to retrieve the data from their prior plan.
§pdex-138a	MAY	To ease the transition for requesters that have already implemented the STU 2.1.0 envelope, a STU 2.2.0 responder MAY additionally include a `Parameters` ndjson file in the async completion manifest (alongside the Group ndjson files) containing a `PDexMultiMemberMatchResponseParameters`-conformant Parameters resource that wraps the same Group resources.
§pdex-138b	SHOULD	When both ndjson formats are present, requesters SHOULD prefer the Group ndjson files.
§pdex-139	SHALL	The Bulk Payer-to-Payer Exchange described in this section and the Payer-to-Payer (single Member) Exchange SHALL exchange the same data set;
§pdex-140	SHALL	The following data SHALL be exchanged with
§pdex-141	MAY	The following information MAY be exchanged with the prior plan for a member:
§pdex-142	SHALL	The requesting Payer SHALL obtain an access token in accordance with the
§pdex-143	SHALL	SHALL be required to access the secured bulk-member-match operation endpoint.
§pdex-144	SHALL	SHALL be supplied as a parameter.part element in the
§pdex-145	MAY	Optionally the new health plan MAY include the following element in the parameter.part
§pdex-146	SHALL	The PDex $multi-member-match operation SHALL be submitted using a HTTP POST.
§pdex-147	SHALL	The HTTP Header SHALL include:
§pdex-148	SHALL	The $multi-member-match operation SHALL be performed asynchronously, following the Asynchronous Request Pattern defined in FHIR R4.
§pdex-149	SHALL	Implementers SHALL follow the guidance provided in the Bulk Data Status Request section of the Async Request Pattern.pdex-139a: The subsequent $davinci-data-export operation SHALL also be submitted using a HTTP POST and SHALL be performed as an asynchronous Bulk Data export, per the FHIR Bulk Data Access IG.
§pdex-150	SHALL	The contained Patient resource SHALL be the Patient resource submitted by the requester in the MemberBundle input parameter, preserving the original resource `id`, all `identifier` elements, and all demographic elements (`name`, `birthDate`, `gender`, `address`, `telecom`, `communication`, and any other Patient elements supplied by the requester) so that the requester can unambiguously correlate each match result back to the member they submitted.
§pdex-151	SHALL NOT	Responders SHALL NOT modify, abridge, or substitute the submitted Patient resource's `id`, `identifier`, or demographic elements.
§pdex-151a	SHALL	Where the submitted Patient resource carries any of those base-FHIR-prohibited elements, the responder SHALL remove them when copying the resource into the response Group's `Group.contained[]`, so the contained Patient is base-FHIR-conformant.
§pdex-153	SHALL	In this case the responder SHALL also include the submitted `CoverageToMatch` resource as a contained Coverage in the Group and populate the `matchedCoverage` (or `nonMatchedCoverage`) extension on `member.entity` to reference it.
§pdex-154	SHALL	The Bulk Member Match Operation SHALL evaluate the consent request for each member and determine whether the request for only Non-Sensitive data, as determined by federal and state regulations that apply to the data holder, can be complied with.
§pdex-154a	SHALL	Consent evaluation SHALL be performed independently for each submitted member.
§pdex-154c	SHALL NOT MAY	A responder SHALL NOT include consent-error detail (for example, "Consent expired on 2026-04-15") in the `ConsentConstrainedMembers` Group itself, since the Group conveys the consent-constrained outcome categorically; per-member operational diagnostics MAY be returned out-of-band (operator logs, support channels) per the responder's policy.
§pdex-155	SHALL	The following decision tree illustrates how the Consent determination SHALL be made.
§pdex-156	SHALL	Consent SHALL be evaluated at the time of the data request to ensure that the Member
§pdex-157	SHALL	Implementers SHALL support the `Group` search parameters enumerated in the PDex Server CapabilityStatement (and its US Core 6.1.0 variant, pdex-server-6-1) for the `Group` resource — at minimum `identifier` and `characteristic` — both of which are declared with SHALL support expectations there.
§pdex-158	SHALL	the data available through the Payer-to-Payer Bulk API SHALL include:
§pdex-159	SHALL	- SHALL be issued with OAuth2.0/SMART-On-FHIR client credentials that enable access to /Group/{id}.
§pdex-160	SHALL	- SHALL be permitted to SEARCH /Group.
§pdex-161	SHALL	The search function and the bundle contents returned SHALL be restricted to the {ids} that are associated with theRequesting/New Payer.
§pdex-162	MAY	- MAY be associated with more than one PDex Member Match group list.
§pdex-163	SHALL	- SHALL be permitted to GET /Group/{id} for any PDex Member Match Group list they are associated with.
§pdex-164	SHALL	- SHALL be permitted to call $davinci-data-export operation for any /Group/{id} they are associated with.
§pdex-165	SHALL MAY	- SHALL be permitted to retrieve data with a date of service within at least the 5 years before the date of the request for information; a responding health plan MAY permit retrieval of older data.
§pdex-166	SHOULD	enables granular resource requests the operation SHOULD be used with two scenarios:
§pdex-167	SHALL	The Data Export operation SHALL check the consent status for each member
§pdex-168	SHALL	The data that SHALL be available via the Payer-to-Payer Bulk API is enumerated above in
§pdex-169	SHALL MAY	Claims and clinical data exchanged to satisfy the requesting plan's obligation under 42 CFR 422.121(b)(4)(ii) SHALL include records with a date of service within the 5 years before the request; records older than 5 years MAY also be returned at the responding health plan's discretion.
§pdex-170	SHALL	Prior Authorizations SHALL be limited to Active/Current Prior Authorizations and
§pdex-171	SHALL	For Payer-to-Payer Bulk Exchange the exportType field SHALL have the following value:
§pdex-172	SHALL	For Payer-to-Payer Exchange, a responding health plan SHALL be capable of returning all in-scope data with a date of service within the 5 years before the request date, in order to support the requesting plan's obligation under 42 CFR 422.121(b)(4)(ii).
§pdex-173	SHOULD	The `_since` parameter SHOULD be used for resource requests when the full history is not required and the goal is to retrieve only resources that have been added or updated on the source since a previous export — i.e., for incremental / "run-off" retrievals.
§pdex-174	MAY	It is expected that Payers MAY first request data for members without limiting the request using the `_since` parameter.
§pdex-175	MAY	Subsequent requests MAY then use `_since` to limit data to information that is new on the source.
§pdex-177	MAY	The _until parameter MAY be used less frequently.
§pdex-178	MAY	The _type parameter MAY be used to restrict the resources retrieved by the
§pdex-179	SHALL	If this parameter is not used all available resources SHALL be returned
§pdex-180	MAY	A requesting Payer MAY include the `_typeFilter` parameter in a `$davinci-data-export` kick-off request to further restrict the resources retrieved (for example, to only retrieve Observations of a certain type).
§pdex-180b	SHOULD	Requesting Payers SHOULD consult the responding Payer's CapabilityStatement (or out-of-band documentation) to determine whether `_typeFilter` is supported before relying on it.
§pdex-180c	SHALL	A responding Payer that supports `_typeFilter` SHALL filter the exported resources per the supplied search query, as required by the Bulk Data Access IG.
§pdex-180d	SHALL NOT SHALL	A responding Payer that does not support `_typeFilter`, or does not support the specific search parameter named in the requester's filter, SHALL behave per the Bulk Data Access IG — typically by returning an `OperationOutcome` so the requester can resubmit without the unsupported filter; responders SHALL NOT silently ignore an unsupported `_typeFilter` and emit unfiltered data.
§pdex-181	SHALL	The `_typeFilter` value, when supplied, SHALL comprise one or more valid FHIR search queries for the respective resource being filtered.
§pdex-182	SHALL	supported by the relevant profiles from the PDex, US Core or CARIN Blue Button IGs SHALL
§pdex-183	SHOULD	Implementers SHOULD implement OAuth 2.0 access management in accordance with
§pdex-184	SHALL	Requests with requiresAccessToken=true SHALL be protected the same way as
§pdex-185	MAY	A server MAY additionally restrict Bulk Data
§pdex-186	SHALL	Health plans SHALL limit the data returned to
§pdex-187	SHALL	Clients SHALL require OAuth client credentials to enable secure access to read
§pdex-188	SHALL	SHALL be required to access the Group resources and the Bulk export operation.
§pdex-189	SHALL	Access and Refresh Tokens SHALL be issued to support the client requesting and
§pdex-190	SHOULD	Exchange SHOULD be registered in accordance with the approach defined in the
§pdex-191	SHALL	A Payer that implements Payer-to-Payer Exchange for a single member — for example, to support legacy CMS-9115-style member-initiated payer-to-payer requests or any other use case for which single-member exchange is more appropriate than multi-member bulk exchange — SHALL do so by following the content provided in this section of the IG.
§pdex-192	SHALL	Payers SHALL implement the Bulk Payer-to-Payer Exchange detailed in this IG on the Payer-to-Payer Bulk Exchange page to exchange information for multiple members.
§pdex-193	MAY	MAY be used to exchange data for a SINGLE member.
§pdex-194	MAY	Payer-to-Payer exchange for a single member MAY be accomplished by three methods.
§pdex-195	SHOULD	Clients wishing to retrieve data SHOULD consult
§pdex-196	SHALL	Each retrieval method for a single member SHALL be preceded by the use of the following interaction to match a member and provide consent:
§pdex-197	SHALL	Health Plans SHALL support the $member-match operation.
§pdex-198	SHOULD	A `MemberId` (Patient FHIR ID) SHOULD also be returned where available.
§pdex-199	SHALL SHOULD	When a member is successfully matched and consent can be complied with, the responding payer SHALL return a `MemberIdentifier` and SHOULD also return a `MemberId` (Patient FHIR ID) in the $member-match response.
§pdex-200	SHALL	Implementers SHALL be prepared to handle $member-match responses that contain only a `MemberIdentifier`, or both a `MemberIdentifier` and a `MemberId`.
§pdex-201	SHOULD	When a `MemberId` (Patient FHIR ID) is present in the response it SHOULD be used as the subject for the subsequent OAuth2.0 access token request.
§pdex-202	SHOULD	Where only a `MemberIdentifier` is returned, the Authorization Server SHOULD resolve the business identifier to a Patient FHIR ID to scope the access token.
§pdex-203	SHALL NOT SHALL	Patient ID SHALL NOT be returned in the $member-match response and a 422 status code SHALL be
§pdex-204	MAY	The receiving payer MAY store the Consent record for the member.
§pdex-205	SHOULD	If a Consent is provided by an Authorized Representative, the person's demographic details SHOULD be included as
§pdex-206	SHOULD	Representative SHOULD be identified as an actor with an appropriate SecurityRoleType, such as "DPOWATT",
§pdex-207	SHALL NOT SHALL	If the receiving payer matches to a unique member but is unable to comply with the consent request, a Patient ID SHALL NOT be returned in the $member-match response and a 422 status code SHALL be
§pdex-208	MAY	When a member chooses to grant consent for a health plan to retrieve their health data from a prior health plan the proposed period of consent MAY be:
§pdex-209	SHALL	Health Plan SHALL utilize the access token returned from the Member Access step to
§pdex-210	SHALL	Each of the above data retrieval methods SHALL support the retrieval of the profiles and resources identified in the table below.
§pdex-211	SHALL	Health Plans SHALL support search of a member's clinical data to each USCDI/US Core clinical resource,
§pdex-212	SHALL	Health Plans SHALL support the use of the $everything operation.
§pdex-213	SHALL	As noted in the previous section, $everything SHALL limit the data retrieved to that which the requester is permitted to access.
§pdex-214	SHALL	The data returned by `$everything` for the requesting payer SHALL include the same set of resources and profiles as any other in-scope retrieval method (see
§pdex-215	SHOULD	Payer-to-Payer Data Exchange SHOULD support the use of Bulk FHIR methods, as defined in the HL7 FHIR
§pdex-216	SHOULD	The request/retrieval of data SHOULD use the FHIR Bulk Data Patient Level Export and theBulk Data Export Operation Request Flow.
§pdex-217	SHOULD	The Patient Export Operation for Payer-to-Payer exchange SHOULD be constrained to the resources and profiles that the requester is permitted to access, such as the profiles identified in the table in the Data Retrieval Methods section of this page.
§pdex-218	SHALL	The FHIR Server SHALL constrain the data returned from the server to a requester based upon the access permissions of the requester.
§pdex-219	SHALL	For example, if a requester queries for ExplanationOfBenefit resources but they are only allowed to see Prior Authorization records, and not EOB Claims, the FHIR Server SHALL filter the data accordingly.
§pdex-220	SHOULD	A public key SHOULD also be provided by the Trust Framework that is overseeing the Payer-to-Payer exchange process.
§pdex-221	SHOULD	Where the organization is both the payer and the managing organization there SHOULD still be two Organization records created.
§pdex-222	SHOULD	Where a `MemberId` (Patient FHIR ID) is returned from $member-match, it SHOULD be submitted to the Access Token Endpoint in the JWT `sub` claim.
§pdex-223	SHOULD	The Authorization Server SHOULD use the Subject ID, confirm that consent for the Requesting Payer to access the Matched Member is still valid, and issue an access token scoped to that specific Patient FHIR ID, bounding any subsequent FHIR API request accordingly.
§pdex-224	SHOULD	Where only a `MemberIdentifier` is returned, the Authorization Server SHOULD resolve the business identifier to a Patient FHIR ID to scope the access token appropriately.
§pdex-225	SHALL	All resources and operations available via a FHIR API endpoint SHALL be declared in a FHIR CapabilityStatement.
§pdex-226	SHOULD	for another member of the health plan, they SHOULD provide appropriate credentials to enable the exchange
§pdex-227	SHOULD	Support for this option by Health Plan systems SHOULD be provided.
§pdex-228	SHOULD	The SMART on FHIR app provided as a link from the returned CDS Hook SHOULD enable a clinician to
§pdex-229	SHOULD	All requesters (e.g., EHRs) SHOULD store provenance associated with any data exchanged as part of this IG if
§pdex-230	SHALL	The member SHALL authenticate using
§pdex-231	MAY	While authenticated to the application or service, the member MAY connect to the (source) Health Plan's
§pdex-232	SHALL	SHALL be presented with an Authorization screen that enables them to approve the sharing of information with
§pdex-233	SHALL	The Authorization process, in accordance with applicable privacy policy, SHALL provide a mechanism to
§pdex-234	SHALL	After successfully authorizing an application an Access Token and Optional Refresh Token SHALL be
§pdex-235	SHALL	The scopes of the access token SHALL be restricted to the authorizing Member's information and the scopes approved.
§pdex-236	SHALL	Any subsequent Access Token issued based on the Refresh Token SHALL be restricted (at least) to the same
§pdex-237	SHALL	The requesting application SHALL use the access token to access the Health Plan's secure FHIR API to download
§pdex-238	SHOULD	Clients wishing to retrieve data SHOULD consult the Data Provider's Server Capability Statement to
§pdex-239	SHOULD	Payers SHOULD:
§pdex-240	MAY	Payers MAY choose to exchange unstructured data with Patients and Providers, via their respective APIs,
§pdex-241a	SHALL SHOULD	For the CMS-0057 Provider Access API obligation, payers SHALL support the v2 (Attestation) workflow described in the rest of this page, and providers/EHRs supporting in-network access to a payer's CMS-mandated Provider Access API SHOULD use the v2 workflow.
§pdex-241b	SHOULD MAY	A provider/EHR that operates under both an in-network arrangement and a VBC contract with the same payer SHOULD use v2 (Attestation) for the CMS-mandated Provider Access exchange and MAY use v1 (Attribution) for VBC-driven data flows (for example, the financial-data exchanges described under
§pdex-242	MAY	Although the CMS Prior Authorization Rule (CMS-0057) requires regulated plans to provide a bulk API that releases Clinical, Prior Authorization and Claims and Encounter data (without the financial data), where permitted by regulation or other agreements, the data MAY be configured to include financial data (including Allowed and
§pdex-243	MAY	Rather than creating large, dynamic lists of members associated with a provider the health plan MAY maintain two types of lists:
§pdex-245	SHALL	A payer SHALL be able to determine, at the time a `$provider-member-match` request is processed, whether each candidate member has opted out of Provider Access API data sharing.
§pdex-246	SHALL	when an opt-out is revoked, the corresponding member entry SHALL be removed from whatever opt-out tracking mechanism the payer maintains (for payers using the FHIR Group pattern, that means removing the member's entry from the Group resource).
§pdex-247	MAY	The Member-Provider TRL MAY be determined by referencing a legacy syystem or API.
§pdex-248	SHALL	Where a payer chooses to use FHIR Group resources to manage the Treatment Relationship the Payer SHALL create a Member-Treatment Group conforming to the Member-Provider Treatment Relationship Group Profile that has the member as the "key" to the list (via a characteristic containing the Patient ID).
§pdex-249	SHALL	The providers SHALL be represented as the cohort, or subjects in the list (as group members).
§pdex-250	SHALL	This list SHALL then be used during a Provider-Member-Match operation to determine if the provider is permitted to retrieve data about the member.
§pdex-251	MAY	The payer MAY apply their own rules for determining a Treatment Relationship.
§pdex-252	SHALL	The payer SHALL apply opt-out and treatment-relationship determinations during a Provider-Member-Match Operation, using whatever mechanism is appropriate to the payer's environment (legacy system, vendor product, internal API, FHIR Group resources, or any combination).
§pdex-253	SHOULD	- The payer SHOULD determine whether the provider is in-network, or has an appropriate contractual relationship.
§pdex-254	SHOULD	- The payer SHOULD extract the rendering provider's NPI from the `subject_id` field of the UDAP B2B Authorization Extension Object (`hl7-b2b`) in the access token and verify it against the payer's provider directory before processing the $provider-member-match request.
§pdex-255	SHALL	- Each member request SHALL contain:
§pdex-256	SHALL	- The CoverageToMatch SHALL contain the Member's coverage information.
§pdex-257	SHALL	- The Treatment attestation SHALL be submitted as a Consent resource conforming to the Provider Treatment Attestation Profile in each member request.
§pdex-258	SHALL	- The health plan SHALL evaluate the request and determine:
§pdex-259	SHALL	- When the member data passes these checks, the member SHALL be returned in the matched members response Group, which conforms to the Provider Member Match Group profile.
§pdex-260	SHALL	The Group Id of the matched group SHALL be returned to the Provider upon completion of the operation.
§pdex-261	SHALL	- Members who fail any check SHALL be returned in one of the response Group resources, distinguished by Group profile, subject to the privacy default below:
§pdex-261a	SHOULD	Where the payer determines that distinguishing 'opted out' from 'not matched' in the response would itself constitute a disclosure the member did not authorize (whether under applicable state privacy law, the member's stated preference, or the payer's privacy policy), the payer SHOULD suppress the `ConsentConstrainedMembers` Group and instead include the affected members in the `NonMatchedMembers` Group.
§pdex-262	SHALL	- The provider SHALL use the Matched Group Id to make subsequent $davinci-data-export operation requests to retrieve data for all, or a subset, of members.
§pdex-263	MAY	- Alternatively, the provider MAY perform a new Provider-Member-Match operation to receive a new Matched Member Group.
§pdex-264	MAY	- The matched group resource MAY be a short-lived group.
§pdex-265	SHOULD	- Implementer feedback is sought on whether requests for less than 10 members SHOULD be handled as an interactive request, with larger bulk requests being processed as an asynchronous process.
§pdex-266	SHALL	- Providers SHALL be able to search and retrieve the contents of the Matched Member Group resource.
§pdex-267	SHALL	- Providers SHALL assume that the Matched Group is short-lived and subsequent requests for member data SHALL be initiated by performing a member match operation to retrieve an updated Matched Group List.
§pdex-268	SHOULD	When a health plan is using FHIR Groups to manage Treatment relationships they SHOULD create Member-Provider TRLs using the NPI data for the Rendering Provider.
§pdex-269	MAY	Health plans MAY choose to include organizations or locations in a Member-Provider TRL.
§pdex-270	SHALL	A health plan member SHALL be entitled to Opt-Out from their data being shared via the Provider Access API.
§pdex-271	MAY	PDex defines a consent profile that MAY be used to enable a member to deny sharing via the Provider Access API.
§pdex-272	SHALL	A member SHALL be able to update their preference
§pdex-273	SHALL	When a member Opts-Out of sharing, the payer's opt-out tracking mechanism SHALL be updated so that subsequent `$provider-member-match` evaluations recognize the opt-out.
§pdex-274	SHALL	If a member revokes their Opt-Out, the same mechanism SHALL be updated to remove the opt-out — i.e., the member's identifier is removed from the Member Opt-Out Group, or the legacy/internal API ceases to report the member as opted out.
§pdex-275	MAY	Health Plans MAY implement the pdex-provider-consent profile to enable a member to express their data-sharing preference for the Provider Access API.
§pdex-276	SHALL	If a Treatment Relationship is established and the member has not opted out, the member SHALL be returned in the matched members response Group, which conforms to the Provider Member Match Group profile.
§pdex-277	SHALL	Members SHALL have the ability to opt-out of data sharing with providers.
§pdex-278	MAY	- MAY use claims data as a source to identify existing Treatment Relationships.
§pdex-279	MAY	- MAY utilize their own rules for determining a Treatment Relationship between members and Providers.
§pdex-280	MAY	- MAY use the Coverage Requirements Discovery IG's appointment-book and encounter-start CDS Hooks as a means to determine impending treatment relationships.
§pdex-281	SHOULD	SHOULD be supported:
§pdex-282	SHALL	Access SHALL be controlled using client credentials that are compliant with SMART-On-FHIR.
§pdex-283	SHOULD	Access SHOULD be restricted to Providers with a contractual relationship with a Payer.
§pdex-284	SHALL	The $davinci-data-export operations SHALL be submitted using a HTTPS POST.
§pdex-285	SHALL	The HTTPS Header SHALL include:
§pdex-286	SHALL	The Payer SHALL be responsible for managing and maintaining the Treatment Relationship between
§pdex-287	SHALL	The payer SHALL take account of members that have chosen to Opt-Out of
§pdex-288	SHALL	Those Opted-Out members SHALL be included in a Member Opted-Out List.
§pdex-288a	SHALL	A responder SHALL include one or more `Group` ndjson files in the async completion manifest containing the matched / non-matched / consent-constrained Group resources (per the Provider Member Match Group, Provider Member No Match Group, and Member Opt-Out Group profiles), subject to the privacy default in
§pdex-289	SHOULD	Prior Authorization Rule (CMS-0057) the data available through the API SHOULD include:
§pdex-290	SHALL	- SHALL be issued with OAuth2.0/SMART-On-FHIR client credentials that enable access to /Group/{id}.
§pdex-291	SHALL	- SHALL be permitted to GET /Group/{id} for the Matched Member Group list created by the Provider Member-Match operation.
§pdex-292	SHALL	- SHALL be permitted to call $davinci-data-export operation for the /Group/{id} they received in the response to the Provider Member-Match operation.
§pdex-293	MAY	Data MAY be constrained by:
§pdex-294	SHALL	The Data Export operation SHALL check the consent status for each member at the time of execution.
§pdex-295	SHALL	If the patient parameter is not provided data SHALL be retrieved for all members
§pdex-296	SHALL	If the patient parameter is provided the operation SHALL ignore references
§pdex-297	SHALL	The exportType parameter SHALL have one of the following values:
§pdex-298	SHALL	The hl7.fhir.us.davinci-pdex#provider-delta option SHALL be used when the provider is
§pdex-299	SHALL	When using provider-delta the provider client SHALL supply the `_since` parameter to scope the request to resources updated since their last retrieval.
§pdex-300	SHALL	The hl7.fhir.us.davinci-pdex#provider-download option SHALL be used when the provider is
§pdex-301	SHOULD	The hl7.fhir.us.davinci-pdex#provider-snapshot value SHOULD be used when a provider
§pdex-302	SHOULD	Implementers SHOULD maintain an internal audit trail to record which export operations were executed and by which client.
§pdex-303	SHOULD	The _since parameter SHOULD be used for resource requests when the full history is not
§pdex-304	MAY	It is expected that providers MAY first request data for members without
§pdex-305	MAY	Subsequent requests MAY then use _since
§pdex-306	MAY	The _until parameter MAY be used less frequently.
§pdex-307	MAY	The _type parameter MAY be used to restrict the resources retrieved by the Provider.
§pdex-308	SHALL	parameter is not used all available resources SHALL be returned by the Payer, subject to
§pdex-309	MAY	The _typeFilter parameter MAY be used to further restrict the resources retrieved by the
§pdex-310	SHALL	used, SHALL comprise one, or more, valid FHIR search queries for the respective resource
§pdex-311	SHALL	supported by the relevant profiles from the PDex, US Core or CARIN Blue Button IGs SHALL
§pdex-312	SHOULD	Implementers SHOULD implement OAuth 2.0 access management in accordance with the SMART Backend Services
§pdex-313	SHALL	Output File Requests with requiresAccessToken=true SHALL be protected the same way the Bulk Data Kick-off Request,
§pdex-314	MAY	A server MAY
§pdex-315	SHALL	Health plans SHALL limit the data returned to
§pdex-316	SHALL	Clients SHALL require OAuth client credentials to enable secure access to read and search the Group
§pdex-317	SHALL	Access Tokens SHALL be required to access the Group
§pdex-318	SHOULD	Access and Refresh Tokens SHOULD be issued to support
§pdex-319	SHOULD	Exchange SHOULD be registered in accordance with the approach defined in the
§pdex-320	SHOULD	When the protocols detailed in the above UDAP Security IG's Business to Business section are used, the `subject_id` in the B2B Authorization Extension Object (Key Name: `"hl7-b2b"`) SHOULD contain the NPI of the rendering provider on whose behalf member data is being requested.
§pdex-321	MAY	For requests covering more than a single rendering provider (e.g., an organization-level request), the `subject_id` MAY be the FHIR Id of the Group being requested.
§pdex-322	SHOULD	The payer SHOULD validate the NPI supplied in the `subject_id` against their provider directory to confirm the provider is known, active, and has an in-network or contractual relationship before issuing an access token or processing a `$provider-member-match` request.
§pdex-323	MAY	regulation or other agreements, the data MAY be configured to include financial data (including Allowed and
§pdex-324	MAY	Health plans MAY choose to construct alternative or additional Attribution
§pdex-325	SHOULD	A member SHOULD also be able to update their preference
§pdex-326	MAY	Health Plans MAY implement the pdex-provider-consent profile to enable a member to express their data-sharing preference for the Provider Access API.
§pdex-327	SHALL	Members SHALL have the ability to opt-out of data sharing with providers.
§pdex-328	SHOULD	Attribution Lists SHOULD be
§pdex-329	MAY	A health plan MAY adopt their own methodology for managing and maintaining
§pdex-330	MAY	- MAY use claims data as a source to identify existing treatment relationships.
§pdex-331	MAY	- MAY utilize their own rules for determining the attribution of members to Providers.
§pdex-332	SHOULD	- SHOULD use the Coverage Requirements Discovery IG's appointment-book and encounter-start CDS Hooks as a means to determine impending treatment relationships.
§pdex-333	SHALL	Attribution lists SHALL be searchable via a secure RESTful API.
§pdex-334	SHOULD	attribution lists SHOULD be scoped to the appropriate Organization, Facility, Provider or their
§pdex-335	SHOULD	SHOULD be supported:
§pdex-336	SHALL	Access SHALL be controlled using client credentials that are compliant with SMART-On-FHIR.
§pdex-337	SHOULD	Access SHOULD be restricted to Providers with a contractual relationship with a Payer.
§pdex-338	SHALL	The $davinci-data-export operations SHALL be submitted using a HTTP POST.
§pdex-339	SHALL	The HTTP Header SHALL include:
§pdex-340	SHALL	The $davinci-data-export operation SHALL be performed asynchronously, following the Asynchronous Request Pattern defined in FHIR R4.
§pdex-341	SHALL	Implementers SHALL follow the Bulk Data Status Request guidance for polling behavior.
§pdex-342	SHALL	The Payer SHALL be responsible for managing and maintaining the attribution list that assigns
§pdex-343	SHALL	The payer SHALL take account of members that have chosen to Opt-out of
§pdex-344	SHALL	Those opted-out members SHALL be omitted from the Provider
§pdex-345	MAY	The Payer MAY choose to maintain a separate Group resource for a Provider
§pdex-346	MAY	A provider MAY have more than one list.
§pdex-347	SHALL	The PDexProviderGroup profile SHALL be used to record the
§pdex-348	MAY	By recording this quantity it MAY help providers reconcile their attribution lists
§pdex-349	SHOULD	Implementers SHOULD maintain an internal audit trail to record which export operations were executed, by which client, and for which members.
§pdex-350	SHALL	Implementers SHALL support the `Group` search parameters enumerated in the PDex Server CapabilityStatement (and its US Core 6.1.0 variant, pdex-server-6-1) for the `Group` resource — at minimum `identifier` and `characteristic` — both of which are declared with SHALL support expectations there.
§pdex-351	SHOULD	Prior Authorization Rule (CMS-0057) the data available through the API SHOULD include:
§pdex-352	SHALL	- SHALL be issued with OAuth2.0/SMART-On-FHIR client credentials that enable access to /Group/{id}.
§pdex-353	SHALL	- SHALL be permitted to SEARCH /Group.
§pdex-354	SHALL	The search function and the bundle contents returned SHALL be restricted to the {ids} that are associated with the Provider Representative's account.
§pdex-355	MAY	- MAY be associated with more than one attribution group list.
§pdex-356	SHALL	- SHALL be permitted to GET /Group/{id} for any Attribution Group list they are associated with.
§pdex-357	SHALL	- SHALL be permitted to call $davinci-data-export operation for any /Group/{id} they are associated with.
§pdex-358	SHALL	The Data Export operation SHALL check the consent status for each member at the time
§pdex-359	SHALL	If the patient parameter is not provided data SHALL be retrieved for all members
§pdex-360	SHALL	If the patient parameter is provided the operation SHALL ignore references
§pdex-361	SHALL	The exportType parameter SHALL have one of the following values:
§pdex-362	SHALL	The hl7.fhir.us.davinci-pdex#provider-delta option SHALL be used when the provider is
§pdex-363	SHALL	When using provider-delta the provider client SHALL supply the `_since` parameter to scope the request to resources updated since their last retrieval.
§pdex-364	SHALL	The hl7.fhir.us.davinci-pdex#provider-download option SHALL be used when the provider is
§pdex-365	SHOULD	The hl7.fhir.us.davinci-pdex#provider-snapshot value SHOULD be used when a provider
§pdex-366	SHOULD	Implementers SHOULD maintain an internal audit trail to record which export operations were executed and by which client.
§pdex-367	SHOULD	The _since parameter SHOULD be used for resource requests when the full history is not
§pdex-368	MAY	It is expected that providers MAY first request data for members without
§pdex-369	MAY	Subsequent requests MAY then use _since
§pdex-370	MAY	The _until parameter MAY be used less frequently.
§pdex-371	MAY	The _type parameter MAY be used to restrict the resources retrieved by the Provider.
§pdex-372	SHALL	parameter is not used all available resources SHALL be returned by the Payer, subject to
§pdex-373	MAY	The _typeFilter parameter MAY be used to further restrict the resources retrieved by the
§pdex-374	SHALL	used, SHALL comprise one, or more, valid FHIR search queries for the respective resource
§pdex-375	SHALL	supported by the relevant profiles from the PDex, US Core or CARIN Blue Button IGs SHALL
§pdex-376	SHOULD	Implementers SHOULD implement OAuth 2.0 access management in accordance with the SMART Backend Services
§pdex-377	SHALL	Output File Requests with requiresAccessToken=true SHALL be protected the same way the Bulk Data Kick-off Request,
§pdex-378	MAY	A server MAY
§pdex-379	SHALL	Health plans SHALL limit the data returned to
§pdex-380	SHALL	Clients SHALL require OAuth client credentials to enable secure access to read and search the Group
§pdex-381	SHALL	Access Tokens SHALL be required to access the Group
§pdex-382	SHOULD	Access and Refresh Tokens SHOULD be issued to support
§pdex-383	SHOULD	Exchange SHOULD be registered in accordance with the approach defined in the
§pdex-384	MAY	When providers are building a health history for a new patient the information they are interested in MAY include:
§pdex-385	MAY	For example, as part of an event or episode of care the provider MAY be interested in the following types of data:
§pdex-386	MAY	Where a payer elects to exchange any of the data types listed above, the table below identifies the FHIR R4 / US Core profile that the payer MAY use for each.
§pdex-387	SHOULD	A payer SHOULD provide the most recent version of the Patient, Practitioner, Organization and Location resources.
§pdex-388	MAY	A payer MAY choose to support FHIR resource data versioning in their API including Patient, Practitioner, Organization and Location resources.
§pdex-389	SHOULD	In such cases resources SHOULD follow the vread guidance in the HTTP section of the FHIR specification.
§pdex-390	SHALL	If a payer chooses to support FHIR resource data versioning of related resource references, the referring resource SHALL use the vread format of reference:
§pdex-391	MAY	In this scenario the Clinician that reviews the Member History is only interested in information in the Member record since their last visit and MAY want to exclude information from their own organization, since that information will already be recorded in their EMR system.
§pdex-394	SHALL	SHALL support searching for code for a Group.
§pdex-395	SHALL	Payers SHALL make available pending and active prior authorization decisions and related clinical documentation and forms for items and services, not including prescription drugs, including the date the prior authorization was approved, the date the authorization ends, as well as the units and services approved and those used to date, no later than one (1) business day after a provider initiates a prior authorization for the beneficiary or there is a change of status for the prior authorization.
§pdex-396	SHALL	SHALL support searching for code for a Group.
§pdex-397	SHALL	This operation SHALL be performed asynchronously following the FHIR Asynchronous Request Pattern.
§pdex-398	SHALL	Input parameters SHALL conform to the PDex Multi-Member Match Request profile.
§pdex-399	SHALL	Output parameters SHALL conform to the PDex Multi-Member Match Response profile.
§pdex-400	SHALL	Input parameters SHALL conform to the Provider $multi-member-match Request profile.
§pdex-401	SHALL	Output parameters SHALL conform to the Provider $multi-member-match Response profile.

Next Page: Implementation Guide