Da Vinci Payer Data Exchange
2.1.1 - STU 2.1
Da Vinci Payer Data Exchange
2.1.1 - STU 2.1
Da Vinci Payer Data Exchange, published by HL7 International / Financial Management. This guide is not an authorized publication; it is the continuous build for version 2.1.1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/davinci-epdx/ and changes regularly. See the Directory of published versions
| Page standards status: Informative |
This page consolidates all conformance statements that are included in the narrative of the Implementation Guide.
| Id | Expectation | Conditional? | Rule |
|---|---|---|---|
| SHALL SHOULD MAY SHALL NOT | Yes No Any | ||
| §1 | SHALL | pdex-32: *SHALL** be used to express a member's demographic information. | |
| §2 | MAY | pdex-58: - 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-59: - 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 | SHOULD | pdex-77: Health Plans SHOULD accept and retain Provenance records received with data based on Member-authorized Payer-to-Payer exchange. | |
| §5 | SHOULD | pdex-78: Health Plans SHOULD accept and retain Provenance records received with data from sources other than Member-authorized Payer-to-Payer exchange. | |
| §6 | SHOULD | pdex-79: 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. | |
| §7 | SHOULD | pdex-80: A Provenance resource SHOULD be provided with each member-related resource provided by the Health Plan's FHIR API when requested, such as via the _RevInclude parameter. | |
| §8 | SHALL | pdex-95: For querying and reading PDex and US Core Profiles, Must Support on any profile data element SHALL be interpreted as follows: | |
| §9 | MAY | pdex-186: 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-01 | SHALL | The Da Vinci PDex MedicationDispense profile SHALL be used to record a member's prescription drug claims when sharing data using | |
| §pdex-02 | SHOULD | When a Health Plan forwards information as a FHIR Resource it SHOULD create related Provenance record(s) to reflect the original source. | |
| §pdex-03 | SHOULD | A Provenance resource SHOULD be provided with each member-related resource provided by the Health Plan's FHIR API. | |
| §pdex-05 | SHOULD | Provenance.recorded value SHOULD be the date/time when the data is received by the payer. | |
| §pdex-06 | SHOULD | The Pdex Provenance record SHOULD be populated with the following essential fields (Must Support or Cardinality greater than 0..*) as follows: | |
| §pdex-07 | 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-08 | SHALL | The Health Plan SHALL accept and maintain Provenance information associated with information received from contributing entities. | |
| §pdex-09 | SHALL | The Health Plan SHALL add Provenance record(s) as necessary to document relevant actions taken as the current custodian of the information. | |
| §pdex-10 | SHALL | Provenance information SHALL be available for any information requested by an external entity as part of exchanges conformant to this implementation guide. | |
| §pdex-11 | 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-12 | SHOULD | The updated Provenance record SHOULD be passed on to any downstream entity that requests Provenance information for the records they request. | |
| §pdex-13 | SHOULD | The Health Plan SHOULD store the Provenance information and maintain the correlation or links to the records the Provenance Record is documenting. | |
| §pdex-14 | 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-15 | SHOULD | The updated Provenance record SHOULD be passed on to any downstream entity requesting the associated records. | |
| §pdex-16 | 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-17 | SHOULD | The updated Provenance record SHOULD be passed on to any downstream entity requesting the associated records. | |
| §pdex-18 | SHALL | SHALL be used to record them. | |
| §pdex-19 | 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-20 | SHALL | Where a Health Plan has access to Information about the CareTeam for a member they SHALL make the information available using the | |
| §pdex-21 | MAY | For discrete procedures or encounters it MAY not be appropriate to create a CareTeam record from the claims information. | |
| §pdex-22 | 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-23 | 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-24 | SHALL | The Health Plan SHALL use the | |
| §pdex-25 | 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-26 | SHALL | Where a Health Plan has information about devices used by the Member that information SHALL be published using the | |
| §pdex-27 | SHALL | It identifies which core elements, extensions, vocabularies and value sets SHALL be present in the resource when using this profile. | |
| §pdex-28 | SHALL | SHALL be used to record location/facility-specific information. | |
| §pdex-29 | SHALL | Where a Health Plan has access to Medication information, they SHALL make the information available using the | |
| §pdex-30 | SHALL | Where a Health Plan has access to Prescription information, they SHALL make the information available using the | |
| §pdex-31 | SHOULD | SHOULD use the | |
| §pdex-33 | SHALL | The code MB SHALL be used to identify the member identifier. | |
| §pdex-34 | SHALL | SHALL be used to record information about Practitioners. | |
| §pdex-35 | SHALL | SHALL be used to record information about the roles that practitioners take in providing services to their patients. | |
| §pdex-36 | SHALL | SHALL be used to record a member's health events. | |
| §pdex-37 | SHALL | In all other cases a payer SHALL create a PDex Provenance profile that identifies their role as a "Transmitter" of the information. | |
| §pdex-38 | 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-39 | 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-40 | 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-41 | 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-42 | 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-43 | 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-44 | 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-45 | 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-46 | 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-47 | 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-48 | 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-49 | 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-50 | 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-51 | 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-52 | 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-53 | 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-54 | SHALL | Sharing of Member health information via PDex SHALL use the CDS Hooks specification. | |
| §pdex-55 | SHALL | Connection to health plan systems SHALL be supported via the following hook: | |
| §pdex-56 | 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-57 | SHOULD | PDex supports three common scenarios where CDS Hooks SHOULD be used: | |
| §pdex-60 | 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-61 | MAY | Examples of preset search query parameters MAY include, but are not limited to: | |
| §pdex-62 | MAY | Any valid FHIR search query for a Patient MAY be constructed by the Provider. | |
| §pdex-63 | 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-64 | SHOULD | As a minimum, search of FHIR Resources SHOULD support the following query parameters where appropriate for a Resource Type: | |
| §pdex-65 | MAY | Health plans and clients MAY support additional hooks, additional card patterns, additional resources, additional extensions, etc. | |
| §pdex-66 | 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 AI 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-67 | MAY | This MAY be used by a member portal, or consumer app to communicate an opt-out from Provider Access sharing. | |
| §pdex-68 | MAY | Coverage.identifier MAY include a member identifier in the Coverage resource. | |
| §pdex-69 | SHOULD | Health Plans SHOULD map claims and clinical information for a member to US Core v3.1.1, US Core v6.1.0 or US Core v7.0.0FHIR Resources based on R4. | |
| §pdex-70 | 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-72 | 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-toPayer 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-73 | SHALL | If a field is marked as required (cardinality n.., where n>0) the Health Plan SHALL populate the field. | |
| §pdex-74 | 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-75 | 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-76 | SHALL | If a field is marked as MUST SUPPORT the receiver SHALL be able to consume it without generating an error. | |
| §pdex-81 | 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-82 | SHALL | Implementers and testers of this specification SHALL abide by the license requirements for each terminology content artifact utilized within a functioning implementation. | |
| §pdex-83 | SHALL | Terminology licenses SHALL be obtained from the Third-Party IP owner for each code system and/or other specified artifact used. | |
| §pdex-84 | SHALL | SHALL indicates requirements that must be met to be conformant with the specification. | |
| §pdex-85 | 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-86 | MAY | MAY describes optional behaviors that are free to consider but where there is no recommendation for, or against, adoption. | |
| §pdex-87 | 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-88 | SHALL | A Member SHALL also be able to use APIs to share information with Third Party Applications. | |
| §pdex-89 | SHALL | Therefore, for profiles and APIs identified in this IG, the FHIR R4 version SHALL be used. | |
| §pdex-90 | 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-91 | SHALL | All resources available via a FHIR API endpoint SHALL be declared in a FHIR CapabilityStatement. | |
| §pdex-92 | SHALL | The Read and Search Operations SHALL be supported for the FHIR Profiles covered in this payload section. | |
| §pdex-93 | MAY | The V-Read and History operations MAY be supported. | |
| §pdex-94 | 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-96 | 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-97 | 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-98 | SHOULD | In other words PDex Requestors SHOULD be capable of displaying the data elements for human use or storing it for other purposes. | |
| §pdex-99 | 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-100 | 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-101 | 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-102 | SHALL | PDex Requestors SHALL be able to process resource instances containing data elements asserting missing information. | |
| §pdex-103 | SHOULD | A Health Plan's Pharmacy Network SHOULD be expressed using the same FHIR profiles used for the Healthcare Network Directory. | |
| §pdex-104 | 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-105 | SHALL | The member SHALL authenticate using credentials they have been issued by, or accepted by the Health Plan. | |
| §pdex-106 | 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-107 | 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-108 | SHALL | After successfully authorizing an application an Access Token and Optional Refresh Token SHALL be returned to the requesting application. | |
| §pdex-109 | 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-110 | MAY | The application owner MAY be: | |
| §pdex-111 | SHALL | NOTE: exportType parameter SHALL be populated with a value for all PDex implementations of the $Davinci-data-export-operation. | |
| §pdex-112 | SHALL | All data exchanged by Health Plans using the interactions covered in this IG SHALL be transformed to FHIR R4 resources. | |
| §pdex-113 | MAY | Health Plans MAY have both data from clinical and claims sources that they store in their Systems of Record. | |
| §pdex-114 | SHALL | The member SHALL authenticate using credentials that have been issued by or are recognized and accepted by the Health Plan. | |
| §pdex-115 | 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-116 | 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-117 | SHALL | Health Plans SHALL incorporate provenance records that they receive as part of any exchange of FHIR data. | |
| §pdex-118 | 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-119 | SHALL | Health Plans SHALL provide Provenance records that, at a minimum, indicate that they are playing the role of Transmitter of the data in any PDex information exchange. | |
| §pdex-120 | SHOULD | In the case of historical data, the Health Plan SHOULD identify the author, source and source format of the data. | |
| §pdex-121 | SHALL | Bulk Payer-to-Payer exchange SHALL be accomplished by the use of the | |
| §pdex-122 | SHALL | health plans SHALL limit the data exchanged to data with a service date no | |
| §pdex-123 | SHALL | SHALL be limited to current/active Prior Authorizations in addition to Prior | |
| §pdex-124 | SHALL | SHALL be included in the API response. | |
| §pdex-125 | SHALL | Prior Authorizations exchanged via the Payer-to-Payer Exchange API SHALL include | |
| §pdex-126 | SHALL | The supporting data SHALL include unstructured data used in the prior | |
| §pdex-127 | SHALL | The data available to be returned by the Bulk Payer-to-Payer Exchange API SHALL | |
| §pdex-128 | SHALL | (or New) health plan SHALL request permission (i.e., consent) from the Member | |
| §pdex-129 | SHALL | Payer-to-Payer (single Member) Exchange), SHALL exchange the same data. | |
| §pdex-130 | SHALL | The following data SHALL be exchanged with | |
| §pdex-131 | MAY | The following information MAY be exchanged with the prior plan for a member: | |
| §pdex-132 | SHALL | The requesting Payer SHALL obtain an access token in accordance with the | |
| §pdex-133 | SHALL | SHALL be required to access the secured bulk-member-match operation endpoint. | |
| §pdex-134 | SHALL | SHALL be supplied as a parameter.part element in the | |
| §pdex-135 | MAY | Optionally the new health plan MAY include the following element in the parameter.part | |
| §pdex-136 | SHALL | The PDex multi-member-match and the subsequent davinci-data-export operations SHALL be submitted using a HTTP POST. | |
| §pdex-137 | SHALL | The HTTP Header SHALL include: | |
| §pdex-138 | SHALL | The PDex multi-member-match operation SHALL be performed as an | |
| §pdex-139 | SHALL | Implementers SHALL follow the guidance provided in the Bulk Data Status Request section | |
| §pdex-140 | 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-141 | SHALL | The following decision tree illustrates how the Consent determination SHALL be made. | |
| §pdex-142 | SHALL | Consent SHALL be evaluated at the time of the data request to ensure that the Member | |
| §pdex-143 | SHALL | Implementers SHALL support the standard search parameters for group that are specified in the base | |
| §pdex-144 | SHOULD | Prior Authorization Rule (CMS-0057) the data available through the API SHOULD include: | |
| §pdex-145 | SHALL | - SHALL be issued with OAuth2.0/SMART-On-FHIR client credentials that enable access to /Group/{id}. | |
| §pdex-146 | SHALL | - SHALL be permitted to SEARCH /Group. | |
| §pdex-147 | SHALL | The search function and the bundle contents returned SHALL be restricted to the {ids} that are associated with theRequesting/New Payer. | |
| §pdex-148 | MAY | - MAY be associated with more than one PDex Member Match group list. | |
| §pdex-149 | SHALL | - SHALL be permitted to GET /Group/{id} for any PDex Member Match Group list they are associated with. | |
| §pdex-150 | SHALL | - SHALL be permitted to call $davinci-data-export operation for any /Group/{id} they are associated with. | |
| §pdex-151 | SHALL | - SHALL be permitted to retrieve data with a service date within 5 years of the date of the request for information. | |
| §pdex-152 | SHOULD | enables granular resource requests the operation SHOULD be used with two scenarios: | |
| §pdex-153 | SHALL | The Data Export operation SHALL check the consent status for each member | |
| §pdex-154 | SHALL | Data that SHALL be available via the API includes: | |
| §pdex-155 | SHALL | Claims and clinical data SHALL be limited to records with a service date | |
| §pdex-156 | SHALL | Prior Authorizations SHALL be limited to Active/Current Prior Authorizations and | |
| §pdex-157 | SHALL | For Payer-to-Payer Bulk Exchange the exportType field SHALL have the following value: | |
| §pdex-158 | SHALL | request date SHALL be returned via the API. | |
| §pdex-159 | SHOULD | The _since parameter SHOULD be used for resource | |
| §pdex-160 | MAY | It is expected that Payers MAY | |
| §pdex-161 | MAY | Subsequent requests MAY then use _since to limit data to information that is new. | |
| §pdex-162 | SHALL | the date/time SHALL be overridden and set to five years before the transaction | |
| §pdex-163 | MAY | The _until parameter MAY be used less frequently. | |
| §pdex-164 | MAY | The _type parameter MAY be used to restrict the resources retrieved by the | |
| §pdex-165 | SHALL | If this parameter is not used all available resources SHALL be returned | |
| §pdex-166 | MAY | The _typeFilter parameter MAY be used to further restrict the resources | |
| §pdex-167 | SHALL | The _typeFilter, if used, SHALL comprise one, or more, valid FHIR | |
| §pdex-168 | SHALL | supported by the relevant profiles from the PDex, US Core or CARIN Blue Button IGs SHALL | |
| §pdex-169 | SHOULD | Implementers SHOULD implement OAuth 2.0 access management in accordance with | |
| §pdex-170 | SHALL | Requests with requiresAccessToken=true SHALL be protected the same way as | |
| §pdex-171 | MAY | A server MAY additionally restrict Bulk Data | |
| §pdex-172 | SHALL | Health plans SHALL limit the data returned to | |
| §pdex-173 | SHALL | Clients SHALL require OAuth client credentials to enable secure access to read | |
| §pdex-174 | SHALL | SHALL be required to access the Group resources and the Bulk export operation. | |
| §pdex-175 | SHALL | Access and Refresh Tokens SHALL be issued to support the client requesting and | |
| §pdex-176 | MAY | Payers MAY choose to implement Payer-to-Payer Exchange for a single member by following the content provided in this section of the IG. | |
| §pdex-177 | 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-178 | MAY | MAY be used to exchange data for a SINGLE member. | |
| §pdex-179 | MAY | Payer-to-Payer exchange for a single member MAY be accomplished by three methods. | |
| §pdex-180 | SHOULD | Clients wishing to retrieve data SHOULD consult | |
| §pdex-181 | 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-182 | SHALL | Health Plans SHALL support the $member-match operation. | |
| §pdex-183 | SHALL NOT SHALL | Patient ID SHALL NOT be returned in the $member-match response and a 422 status code SHALL be | |
| §pdex-184 | MAY | The receiving payer MAY store the Consent record for the member. | |
| §pdex-185 | SHALL NOT SHALL | Patient ID SHALL NOT be returned in the $member-match response and a 422 status code SHALL be | |
| §pdex-187 | SHALL | Health Plan SHALL utilize the access token returned from the Member Access step to | |
| §pdex-188 | SHALL | Each of the above data retrieval methods SHALL support the retrieval of the profiles and resources identified in the table below. | |
| §pdex-189 | SHALL | Health Plans SHALL support search of a member's clinical data to each USCDI/US Core clinical resource, | |
| §pdex-190 | SHALL | Health Plans SHALL support the use of the $everything operation. | |
| §pdex-191 | SHALL | As noted in the previous section, $everything SHALL limit the data retrieved to that which the | |
| §pdex-192 | SHOULD | The server SHOULD filter the ExplanationOfBenefit resource to include only PDex Prior Authorization | |
| §pdex-193 | SHOULD | Payer-to-Payer Data Exchange SHOULD support the use of Bulk FHIR methods, as defined in the HL7 FHIR | |
| §pdex-195 | SHALL | The FHIR Server SHALL constrain the data returned from the server to a requester based upon the access | |
| §pdex-196 | SHALL | Prior Authorization records, and not EOB Claims, the FHIR Server SHALL filter the data accordingly. | |
| §pdex-197 | SHOULD | The Authorization Server SHOULD use the Subject ID, confirms that consent for the | |
| §pdex-198 | SHALL | All resources and operations available via a FHIR API endpoint SHALL be declared in a FHIR CapabilityStatement. | |
| §pdex-199 | SHOULD | Support for this option by Health Plan systems SHOULD be provided. | |
| §pdex-200 | SHOULD | The SMART on FHIR app provided as a link from the returned CDS Hook SHOULD enable a clinician to | |
| §pdex-201 | SHOULD | All requesters (e.g., EHRs) SHOULD store provenance associated with any data exchanged as part of this IG if | |
| §pdex-202 | SHALL | The member SHALL authenticate using | |
| §pdex-203 | MAY | While authenticated to the application or service, the member MAY connect to the (source) Health Plan's | |
| §pdex-204 | SHALL | SHALL be presented with an Authorization screen that enables them to approve the sharing of information with | |
| §pdex-205 | SHALL | The Authorization process, in accordance with applicable privacy policy, SHALL provide a mechanism to | |
| §pdex-206 | SHALL | After successfully authorizing an application an Access Token and Optional Refresh Token SHALL be | |
| §pdex-207 | SHALL | The scopes of the access token SHALL be restricted to the authorizing Member's information and the scopes approved. | |
| §pdex-208 | SHALL | Any subsequent Access Token issued based on the Refresh Token SHALL be restricted (at least) to the same | |
| §pdex-209 | SHALL | The requesting application SHALL use the access token to access the Health Plan's secure FHIR API to download | |
| §pdex-210 | SHOULD | Clients wishing to retrieve data SHOULD consult the Data Provider's Server Capability Statement to | |
| §pdex-211 | SHOULD | Payers SHOULD: | |
| §pdex-212 | MAY | Payers MAY choose to exchange unstructured data with Patients and Providers, via their respective APIs, | |
| §pdex-213 | 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-214a | MAY | Rather than creating large, dynamic lists of members associated with a provider the health plan MAY maintain two types of lists: | |
| §pdex-214b | MAY | These lists MAY be created using a FHIR Group resource, or implementers MAY choose to use a legacy application and API to provide Member Opt-Out decisions or Treatment Relationship determinations. | |
| §pdex-215 | SHALL | The member Opt-out list, if not determined by a response from a legacy system or API, SHALL be a Group resource conforming to the Member Opt-Out Group Profile and managed by the Health Plan that SHALL contain all members that have chosen to opt-out of Provider Access API Data Sharing. | |
| §pdex-216 | SHALL | If a member revokes their opt-out choice their Identifier(s) SHALL be removed from the Member Opt-Out List. | |
| §pdex-217 | MAY | The Member-Provider TRL MAY be determined by referencing a legacy syystem or API. | |
| §pdex-218 | 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-219 | SHALL | The providers SHALL be represented as the cohort, or subjects in the list (as group members). | |
| §pdex-220 | 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-221 | MAY | The payer MAY apply their own rules for determining a Treatment Relationship. | |
| §pdex-222 | SHALL | The Member Opt-Out List and the Member-Provider TRLs SHALL be used, unless the payer is utilizing existing systems or APIs to determine Opt-Out or Treatment Relationship, as part of a Provider-Member-Match Operation. | |
| §pdex-223 | SHOULD | - The payer SHOULD determine whether the provider is in-network, or has an appropriate contractual relationship. | |
| §pdex-224 | SHALL | - Each member request SHALL contain: | |
| §pdex-225 | SHALL | - The CoverageToMatch SHALL contain the Member's coverage information. | |
| §pdex-226 | SHALL | - The Treatment attestation SHALL be submitted as a Consent resource conforming to the Provider Treatment Attestation Profile in each member request. | |
| §pdex-227 | SHALL | - The health plan SHALL evaluate the request and determine: | |
| §pdex-228 | SHALL | - When the member data passes these checks, the member SHALL be added to a Member-Provider Treatment Relationship Group resource conforming to the matched members response. | |
| §pdex-229 | SHALL | The Group Id of the matched group SHALL be returned to the Provider upon completion of the operation. | |
| §pdex-230 | 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-231 | MAY | Alternatively, the provider MAY perform a new Provider-mMember-Match operation to receive a new Matched Member Group. | |
| §pdex-232 | MAY | - The matched group resource MAY be a short-lived group. | |
| §pdex-233 | 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-234 | SHALL | - Providers SHALL be able to search and retrieve the contents of the Matched Member Group resource. | |
| §pdex-235 | 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-236 | 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-237 | MAY | Health plans MAY choose to include organizations or locations in a Member-Proider TRL. | |
| §pdex-238 | SHALL | A health plan member SHALL be entitled to Opt-Out from their data being shared via the Provider Access API. | |
| §pdex-239 | MAY | PDex defines a consent profile that MAY be used to enable a member to deny sharing via the Provider Access API. | |
| §pdex-240 | SHALL | A member SHALL be able to update their preference | |
| §pdex-241 | SHALL | When a member Opts-Out of sharing, their Member Id SHALL be added to the Member Opt-Out List Group resource, or the API that answers the Opted-Out member query. | |
| §pdex-242 | SHALL | If a member revokes their Opt-Out their Member Id SHALL be removed from the Member Opt-Out List or equivalent API response. | |
| §pdex-243 | MAY | Health Plans MAY implement the pdex-provider-consent to enable a member to express their sharing preference. | |
| §pdex-244 | SHALL | If a Treatment Relationship is established, the member's data SHALL be available to a Provider through the member's inclusion in the Member-Provider Treatment Relationship Group that is used to request a $davinci-data-export operation. | |
| §pdex-245 | SHALL | Members SHALL have the ability to opt-out of data sharing with providers. | |
| §pdex-246 | MAY | - MAY use claims data as a source to identify existing Treatment Relationships. | |
| §pdex-247 | MAY | - MAY utilize their own rules for determining a Treatment Relationship between members and Providers. | |
| §pdex-248 | 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-249 | SHOULD | SHOULD be supported: | |
| §pdex-250 | SHALL | Access SHALL be controlled using client credentials that are compliant with SMART-On-FHIR. | |
| §pdex-251 | SHOULD | Access SHOULD be restricted to Providers with a contractual relationship with a Payer. | |
| §pdex-252 | SHALL | The $davinci-data-export operations SHALL be submitted using a HTTPS POST. | |
| §pdex-253 | SHALL | The HTTPS Header SHALL include: | |
| §pdex-254 | SHALL | The Payer SHALL be responsible for managing and maintaining the Treatment Relationship between | |
| §pdex-255 | SHALL | The payer SHALL take account of members that have chosen to Opt-Out of | |
| §pdex-256 | SHALL | Those Opted-Out members SHALL be included in a Member Opted-Out List. | |
| §pdex-257 | SHOULD | Prior Authorization Rule (CMS-0057) the data available through the API SHOULD include: | |
| §pdex-258 | SHALL | - SHALL be issued with OAuth2.0/SMART-On-FHIR client credentials that enable access to /Group/{id}. | |
| §pdex-259 | SHALL | - SHALL be permitted to GET /Group/{id} for the Matched Member Group list created by the Provider Member-Match operation. | |
| §pdex-260 | 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-261 | MAY | Data MAY be constrained by: | |
| §pdex-262 | SHALL | The Data Export operation SHALL check the consent status for each member at the time of execution. | |
| §pdex-263 | SHALL | If the patient parameter is not provided data SHALL be retrieved for all members | |
| §pdex-264 | SHALL | If the patient parameter is provided the operation SHALL ignore references | |
| §pdex-265 | SHALL | The exportType parameter SHALL have one of the following values: | |
| §pdex-266 | SHALL | The hl7.fhir.us.davinci-pdex#provider-delta option SHALL be used when the provider is | |
| §pdex-267 | SHALL | The hl7.fhir.us.davinci-pdex#provider-download option SHALL be used when the provider is | |
| §pdex-268 | SHOULD | The hl7.fhir.us.davinci-pdex#provider-snapshot value SHOULD be used when a provider | |
| §pdex-269 | SHALL | These values SHALL | |
| §pdex-270 | SHOULD | The _since parameter SHOULD be used for resource requests when the full history is not | |
| §pdex-271 | MAY | It is expected that providers MAY first request data for members without | |
| §pdex-272 | MAY | Subsequent requests MAY then use _since | |
| §pdex-273 | MAY | The _until parameter MAY be used less frequently. | |
| §pdex-274 | MAY | The _type parameter MAY be used to restrict the resources retrieved by the Provider. | |
| §pdex-275 | SHALL | parameter is not used all available resources SHALL be returned by the Payer, subject to | |
| §pdex-276 | SHALL | When _type is used the export operation SHALL record the content of the _type parameter in the | |
| §pdex-277 | SHALL | lastTransmitted SHALL be recorded with either the Date/Time of the Export Transaction | |
| §pdex-278 | MAY | The _typeFilter parameter MAY be used to further restrict the resources retrieved by the | |
| §pdex-279 | SHALL | used, SHALL comprise one, or more, valid FHIR search queries for the respective resource | |
| §pdex-280 | SHALL | When _typeFilter is used the export operation SHALL record the content of the _typeFilter | |
| §pdex-281 | SHALL | lastTransmitted SHALL be recorded with either the Date/Time of the Export Transaction | |
| §pdex-282 | SHALL | supported by the relevant profiles from the PDex, US Core or CARIN Blue Button IGs SHALL | |
| §pdex-283 | SHOULD | Implementers SHOULD implement OAuth 2.0 access management in accordance with the SMART Backend Services | |
| §pdex-284 | SHALL | Output File Requests with requiresAccessToken=true SHALL be protected the same way the Bulk Data Kick-off Request, | |
| §pdex-285 | MAY | A server MAY | |
| §pdex-286 | SHALL | Health plans SHALL limit the data returned to | |
| §pdex-287 | SHALL | Clients SHALL require OAuth client credentials to enable secure access to read and search the Group | |
| §pdex-288 | SHALL | Access Tokens SHALL be required to access the Group | |
| §pdex-289 | SHOULD | Access and Refresh Tokens SHOULD be issued to support | |
| §pdex-290 | MAY | regulation or other agreements, the data MAY be configured to include financial data (including Allowed and | |
| §pdex-291 | MAY | Health plans MAY choose to construct alternative or additional Attribution | |
| §pdex-292 | SHALL | Health Plans SHALL implement the pdex-provider-consent to enable a member to express their sharing preference. | |
| §pdex-293 | SHALL | Members SHALL have the ability to opt-out of data sharing with providers. | |
| §pdex-294 | SHOULD | Attribution Lists SHOULD be | |
| §pdex-295 | MAY | A health plan MAY adopt their own methodology for managing and maintaining | |
| §pdex-296 | MAY | - MAY use claims data as a source to identify existing treatment relationships. | |
| §pdex-297 | MAY | - MAY utilize their own rules for determining the attribution of members to Providers. | |
| §pdex-298 | 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-299 | SHALL | Attribution lists SHALL be searchable via a secure RESTful API. | |
| §pdex-300 | SHOULD | SHOULD be supported: | |
| §pdex-301 | SHALL | Access SHALL be controlled using client credentials that are compliant with SMART-On-FHIR. | |
| §pdex-302 | SHOULD | Access SHOULD be restricted to Providers with a contractual relationship with a Payer. | |
| §pdex-303 | SHALL | The $davinci-data-export operations SHALL be submitted using a HTTP POST. | |
| §pdex-304 | SHALL | The HTTP Header SHALL include: | |
| §pdex-305 | SHALL | The Payer SHALL be responsible for managing and maintaining the attribution list that assigns | |
| §pdex-306 | SHALL | The payer SHALL take account of members that have chosen to Opt-out of | |
| §pdex-307 | SHALL | Those opted-out members SHALL be omitted from the Provider | |
| §pdex-308 | MAY | The Payer MAY choose to maintain a separate Group resource for a Provider | |
| §pdex-309 | MAY | A provider MAY have more than one list. | |
| §pdex-310 | SHALL | The PDexProviderGroup profile SHALL be used to record the | |
| §pdex-311 | MAY | By recording this quantity it MAY help providers reconcile their attribution lists | |
| §pdex-312 | SHOULD | elements SHOULD consider implementing their own independent data tracking capabilities to | |
| §pdex-313 | SHALL | These extensions SHALL be updated by the $davinci-data-export PDex Use Case Operation. | |
| §pdex-314 | SHALL | Implementers SHALL support the standard search parameters for group that are specified in the base | |
| §pdex-315 | SHOULD | Prior Authorization Rule (CMS-0057) the data available through the API SHOULD include: | |
| §pdex-316 | SHALL | - SHALL be issued with OAuth2.0/SMART-On-FHIR client credentials that enable access to /Group/{id}. | |
| §pdex-317 | SHALL | - SHALL be permitted to SEARCH /Group. | |
| §pdex-318 | 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-319 | MAY | - MAY be associated with more than one attribution group list. | |
| §pdex-320 | SHALL | - SHALL be permitted to GET /Group/{id} for any Attribution Group list they are associated with. | |
| §pdex-321 | SHALL | - SHALL be permitted to call $davinci-data-export operation for any /Group/{id} they are associated with. | |
| §pdex-322 | SHALL | The Data Export operation SHALL check the consent status for each member at the time | |
| §pdex-323 | SHALL | If the patient parameter is not provided data SHALL be retrieved for all members | |
| §pdex-324 | SHALL | If the patient parameter is provided the operation SHALL ignore references | |
| §pdex-325 | SHALL | The exportType parameter SHALL have one of the following values: | |
| §pdex-326 | SHALL | The hl7.fhir.us.davinci-pdex#provider-delta option SHALL be used when the provider is | |
| §pdex-327 | SHALL | The hl7.fhir.us.davinci-pdex#provider-download option SHALL be used when the provider is | |
| §pdex-328 | SHOULD | The hl7.fhir.us.davinci-pdex#provider-snapshot value SHOULD be used when a provider | |
| §pdex-329 | SHALL | These values SHALL | |
| §pdex-330 | SHOULD | The _since parameter SHOULD be used for resource requests when the full history is not | |
| §pdex-331 | MAY | It is expected that providers MAY first request data for members without | |
| §pdex-332 | MAY | Subsequent requests MAY then use _since | |
| §pdex-333 | MAY | The _until parameter MAY be used less frequently. | |
| §pdex-334 | MAY | The _type parameter MAY be used to restrict the resources retrieved by the Provider. | |
| §pdex-335 | SHALL | parameter is not used all available resources SHALL be returned by the Payer, subject to | |
| §pdex-336 | SHALL | When _type is used the export operation SHALL record the content of the _type parameter in the | |
| §pdex-337 | SHALL | lastTransmitted SHALL be recorded with either the Date/Time of the Export Transaction | |
| §pdex-338 | MAY | The _typeFilter parameter MAY be used to further restrict the resources retrieved by the | |
| §pdex-339 | SHALL | used, SHALL comprise one, or more, valid FHIR search queries for the respective resource | |
| §pdex-340 | SHALL | When _typeFilter is used the export operation SHALL record the content of the _typeFilter | |
| §pdex-341 | SHALL | lastTransmitted SHALL be recorded with either the Date/Time of the Export Transaction | |
| §pdex-342 | SHALL | supported by the relevant profiles from the PDex, US Core or CARIN Blue Button IGs SHALL | |
| §pdex-343 | SHOULD | Implementers SHOULD implement OAuth 2.0 access management in accordance with the SMART Backend Services | |
| §pdex-344 | SHALL | Output File Requests with requiresAccessToken=true SHALL be protected the same way the Bulk Data Kick-off Request, | |
| §pdex-345 | MAY | A server MAY | |
| §pdex-346 | SHALL | Health plans SHALL limit the data returned to | |
| §pdex-347 | SHALL | Clients SHALL require OAuth client credentials to enable secure access to read and search the Group | |
| §pdex-348 | SHALL | Access Tokens SHALL be required to access the Group | |
| §pdex-349 | SHOULD | Access and Refresh Tokens SHOULD be issued to support | |
| §pdex-350 | MAY | When providers are building a health history for a new patient the information they are interested in MAY include: | |
| §pdex-351 | MAY | For example, as part of an event or episode of care the provider MAY be interested in the following types of data: | |
| §pdex-352 | SHALL | These types of data SHALL be mapped to FHIR clinical resources as follows: | |
| §pdex-353 | SHOULD | A payer SHOULD provide the most recent version of the Patient, Practitioner, Organization and Location resources. | |
| §pdex-354 | MAY | A payer MAY choose to support FHIR resource data versioning in their API including Patient, Practitioner, Organization and Location resources. | |
| §pdex-355 | 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-356 | 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. |
IG © 2024+ HL7 International / Financial Management. Package hl7.fhir.us.davinci-pdex#2.1.1 based on FHIR 4.0.1. Generated 2026-02-03
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change