Da Vinci PDex for Patient Access API Frequently Asked Questions (FAQs)

There is variability among payers to identify members with membermatch vs. member credentialing.  How does a plan ask a new member for information, if they already have a digital ID for a member?

Payer issues digital credentials, they assumed that everyone does the same thing. Until there is a universal ID, there is still a need for member match. - Member would go to their old plan, use those credentials at the old plan to authorize the sharing of their data. (this is a valid method for a member mediated exchange where the member is requesting a prior plan to share their information with another plan)

For a member directed exchange (as covered in the PDex IG and in the Burden Reduction Proposed rule) the process is different

• Member Match was designed to enable member-directed, rather than member-mediated exchange.
• New plan gathers member information regarding their old plan (payer, plan, member/subscriber id).
• The defined operation accepts member demographics (patient resource) and two coverage records (new plan and old plan).  It performs a deterministic match on the coverage information and any verification the plan requires on the demographic information.  If there is no match or multiple matches, the old plan returns an error. If there is one match, the old plan returns an identifier for that member (that crosses contracts) in the patient.identifer.  The new plan uses this identifier to request information from the old plan.
• We think that member credentialing is out of scope for us to respond to, use member match.   
• The standard defines Member Match.  To comply, If the Final Rule is adopted, they will be required to do member match.  Whatever you do on top of that, is up to you.  
• Member Match was designed to accommodate certain important requirements: 1. Since members can request their data from a payer up to 5 years after they dis-enroll the likelihood is that if the member had a digital account it would probably have been deactivated. 2. Member Match also deals with scenarios where a payer does not provide a member portal or digital credentials for their members. Since the match is performed using coverage details and member demographics a digital account is not required.

How does one plan find another plan to exchange the information?

The approach in FAST to have a national plan end point Directory.  Beyond that, work with a partner, agree to share it.   Timeframe: CAQH - Q2/Q3 2021 (estimated).

1) Requester recommends changing the constraint on usdf-PlanID-extension attribute in FormularyDrug to non-mandatory.

2) Currently, the same FormularyDrug profile will repeat for every CoveragePlan. The solution is to use the existing reference to FormularyDrug within CoveragePlan to maintain the "1 CoveragePlan <--> many FormularyDrug" relationship.

1) We are not considering changing the usdf-PlanID-extension attribute to non-mandatory, it is used for formulary search starting with the List.

2) We are considering changing the cardinality of usdf-PlanID-extension in the FormularyDrug Profile from 1..1 to 1..*. However, there are considerations regarding associating the appropriate formulary with the member's plan.  This will take more research before we commit to a solution. 

How to navigate the combination of the data across clinical, claims, encounters, formulary, and directory data

1) Any link to PDex Plan Net should use NPI or TaxID (any exceptions should either return multiple providers/organizations or none)

2) The link to formulary is based on plan ID and RxNorm

3) The links between claims and clinical data should be based on member ID or subscriber ID plus demographics.

Further discussion is needed to find a recommended approach when using internal identifiers to link information in multiple FHIR servers (or façade implementations)

If all information is provided through a single FHIR Server Instance, then all returned information shall use common identifiers for the individual. 

Summary: It is acceptable to have two entries for two separate directories in capability statements - one pointing to pharmacies and one pointing to the provider entry points.

• Need a standard way to find both end points and for clients to find both at run time, want to avoid trying to direct the request.  
• The rule allows for more than one end point. The requirement is that the API endpoints are discoverable. 
• Other Implementers are having an instructional webpage to help people know where to go. 
• Setup a proxy with an interface with third party developers that is publicly available (note: there is no way to distinguish queries intended for pharmacy and non-pharmacy content).
• Having two endpoints, one for providers and one for pharmacies makes it an implementation challenge for the apps utilizing the APIs.
• Splitting Provider and Pharmacy directories to separate endpoints is consistent with how may health plans organize their business with Pharmacy Benefit Managers handling prescription-related workflows and publishing the associated Patient Access APIs related to member prescriptions. 
• Discoverability of endpoints will either be posted by payers to be discoverable by search engines, or may be available through a FAST-compliant directory.

There is currently no plan to distinguish pharmacy vs non-pharmacy content via the search interface (except for HealthcareService), but perhaps a tracker should be created to ensure that this is considered?

Who should implement the CDS Hook services in case of Payer to Provider interaction? Would that be implemented at Provider end or at Payer end.

The Hooks service would be implemented at the Payer end to respond to a provider query about a member.

The Payer's Provider Access API is not a requirement of the CMS Interoperability and Patient Access Final Rule. However, it is a requirement of the Proposed Burden Reduction Rule. The PDex implementation Guide along with CARIN BB along with PDex Formulary are cited as part of this Rule. 

How is Payer to third party application exchange different from CMS Patient Access Final rule, where it says 3^rd Party apps should be able to view the health data maintained in Fhir servers. Please elaborate on Payer to third party application exchange interaction.

Payer data exchange to a member-authorized Third-Party App is the primary focus of the CMS Interoperability and Patient Access Final Rule. This is member-authorized exchange using the SMART-on-FHIR App Launch Framework.

The Rule requires Payers to implement an API that is consistent with the ONC 21st Century Cures Act. It does not specifically require viewing of data held in a FHIR server. 

Is the data exchange between Payer, providers and third party application for just one patient health data or it could also be a population of patients data?

Payer data exchange to a member-authorized Third-Party App is the primary focus of the CMS Interoperability and Patient Access Final Rule and supports access for a single member only and NOT a population of members.

The Burden Reduction Proposed Rule requires payers to make member information available to the provider based upon an attribution list (a list of payer's members with treatment relationships with a particular provider) maintained by the payer. It also allows query for a single shared member.

Bulk data

I understand that $everything shall be supported by the FHIR server for exchange. Are a Fhir Server’s Bulk Import and Bulk Export APIs also a requirement for implementation of this specification?

The CMS Interoperability and Patient Access Rule does not require an API or Bulk Data for exchange of information from an old payer to another payer. In the Burden Reduction Proposed Rule there is a requirement for the use of the Payer Data Exchange IG. Any requirement for Bulk Data is unclear. 

Patient/[id]/$everything is a requirement in the PDex IG when used to implement Payer-to-Payer exchange. Bulk data is not a requirement of the PDex IG or either of the CMS Rules.

The need for ‘ongoing updates’ for the dual enrollees.  If a member has a plan at Payer A and Payer B, we spoke about the need to send ongoing updates of member clinical data as a part of the payer to payer rule and the members request may not be a one time data transfer.  Is this specifically noted in the IG anywhere?

The CMS Interoperability rule does not require any exchange for concurrent payers.  It only requires that a previous payer “send” the members USCDI information (e.g. PDex) to another payer on member request for up to 5 years after the member leaves the covered plan.  

The Pended Burden Reduction Rule does require ongoing updates for dual enrollees, if opted in, and specifies using PDex, CARIN Blue Button (without financials) and PDex Formulary to facilitate the exchange.

While the need for continuing updates was not addressed in the IG, one way to approach this is as follows (assuming use of Member-Match operation):

• Payer A obtains authorization/consent from new member to contact Payer B and exchange their health information to support concurrent coverage.  
• Payer B performs member match and with successful match returns token and member id to Payer A to enable the query of clinical APIs for initial download of records.
• Payer A includes in the member-match request a token and unique id for their new member that has consented to the exchange. The token will not become active until Payer B confirms a shared member and returned an access token as a result of successful member-match request from Payer A.
• Payer A and Payer B request initial data from each other. 
• Payer A and Payer B repeats process on an appropriate frequency (weekly?) for new data only. e.g. search with since _lastUpdated parameter.

While the member has to opt-in to enable the exchange it is unclear whether the opt-in can be time limited to anything less than the duration of the plan. i.e., for 12 months. However, the member can presumably exercise their opt-out option at any time.

Directory

URLs

End Points

B2B2C

(need to clean up) In the B2B2C scenario, e.g. A PBM working with Payer clients, for a third party mobile add, we are sending some reference urls that we have and are sharing with clients (Payers) that they have to resolve or can they send that directly to the third party that is calling? Pagination - they are doing it.  They are putting their URL and the page number.  Do we give that the the third party mobile app (not authenticated with the PBM)  - Can you provide guidance on how they would resolve the url?

• Does the client have to resolve or how do we streamline, when doing the pagination?

If a payer is proxying services from business partners it is incumbent on the proxying party to ensure that references to urls, for example to related links in a bundle such as to the next page, resolve correctly. 

It is beyond the scope of the IG and this FAQ to define how the parties involved should implement a solution to ensure correct resolution of resources referred to by data served up by business partners.

There are two types of Provenance.

1. Payer provides Provenance to indicate that they are only acting as a transmitter of records.
2. When data is exchanged and a _revInclude request is made the FHIR Server will generate a "Transmitter" type Provenance record.
   
   Determine if it is possible to restrict queries on Provenance to only be accessible via a _revinclude and not be accessible directly.

In relation to the question Provenance is intended to fulfill option 2 rather than perform the role of an audit log.

A) In parsing the PDEX IG "SHALL" requirements related to Provenance (as a payer implementing the IG).

• In addition to the search. _RevInclude interaction, is the expectation that a client application should be able to query a bundle/resource and then return to the FHIR server n days later and get the provenance for that bundle/resource using the bundle/resource reference?
• The timestamp that's captured in the recorded field should always be the Date/Time that the payer received the information or created the bundle -- is that correct?

B) Is the intent of the "transmitter" Provenance scenario to:
1) create effectively an audit log in the FHIR server of each time an app requested and received a resource?
OR
2) capture that the payer is acting as a transmitter for a resource that they received at x time, and be able to pass that context on to any app that requests that resource?

A) If the Provenance record is for the bundle resource it will record the date/time when the bundle was created.

If the Provenance record is for an individual  resource received by the payer from the original data source the date/time Provenance.recorded for the individual resource is the date/time the source information was received by the payer.

B) Transmitter provenance would be created for a bundle since it creates a unique id for the bundle. The purpose of the Transmitter Provenance record is to capture the payer acting as a transmitter and the Provenance.recorded dateTime will be the date/time when the Transmitter generated the bundle.

For individual resources the source format in Provenance is  provided to identify how the data was acquired (if known).

Testing is required to determine if it is possible for servers to restrict queries on Provenance to only be accessible via a _revinclude and not to be accessible directly.

where does the $member-match operation come into play in the CMS mandate?

Is it required for the Patient Access API or does it really come into play for Payer-to-Payer? 

The $member-match operation is used in Payer-to-Payer exchange to deterministically identify a common member.

The Patient Access API has an authentication and authorization step that will identify the member that is requesting their data, or whose data is being requested by a personal representative.  Therefore $member-match is not required.

This is another example where straight translation of the QHP formulary into FHIR didn't really work well. Ideally, the network cited here would provide a reference to a Network instance in a provider directory.

For the near term (prior to any technical correction): we recommend filling it with something. The suggested value to enter is "Not applicable"

Making it optional is arguably a breaking change (for the client).

The available selections for CopayOption and CoinsuranceOption don't seem to fit if the Medicaid Plan has a deductible of $0. All of these would mislead the member if there is no deductible:
after-deductible
before-deductible
no-charge
no-charge-after-deductible

Should we use "after-deductible" for now?

Added "Charge" and "Not applicable" to the copay option.

Added "Charge" and "Not applicable"  to Coinsurance option.

JIRA 32178 addresses the Charge option.

David Hill to add additional ticket number.

For zero deductible you would add Copay of "Not applicable" and Coinsurance of "No charge".

Plan Net

Directory

Endpoints

What is the purpose of the Endpoint Resource?

Plan Net

Directory

Count 

Mix

What is the best way for a pharmacy directory to provide number of pharmacies in the network, and mix (specifically the type of pharmacy, such as “retail pharmacy”), as stated in the regulation?

The number and mix of pharmacies can be computed by a client using the query interface.
There isn't a special operation that returns these values, but the query interface enables a client to determine these values. Pharmacies are represented by Location instances that are linked via OrganizationAffiliation instances to Networks. Pharmacy types are represented by specialty codes from the NUCC Provider taxonomy. So, a query to retrieve all pharmacy locations in a network, and then count the number of Locations returned.

Also see clarification of regulation on this topic here: CMS Final Rule Questions and Answers log #9001.

The ability to query is seen as something that can be performed by a developer through the query interface. The value to members is in identifying the pharmacies nearest to the member and not necessarily seeing the absolute number of pharmacies of a given type.

For Jan 2022, as part of Payer Data Exchange CMS mandate, do Payers need to support PDEX Drug Formulary and PDEX Plan NET specifications.   

There is no requirement to exchange the PDex Formulary as part of the mandate for Jan 2022, it is specific to USCDI data.  PDex Plan-Net is an open API.  

From Payers stand point of view, do we need to build a web portal or a 3^rd party app so that a member directed payer data exchange can happen? 

Based on my understanding after reading the PDEX specification, I felt that Payers need to build a web portal for exchanging payer data. 

No. There is no need to construct a separate web portal. However, Payers may choose to integrate the request to fetch data into an existing member portal, or enrollment workflow.

There are currently two schools of thought regarding the approach to achieve Payer-to-payer data exchange: 

A - this is part of a member-directed b2b transaction, so should be able to use business to business relationships and member-match for the information which they want to exchange info.

or

B - The member should have to authenticate in the old plan as part of a member-mediated exchange to consent to have their data shared with the new plan. Treat it like a payer app to authenticate.  

There are pros and cons to each approach: HIPAA and consent, scope and realistic, burden to patient - If no portal, what is the process?

Questions have been submitted to CMS and OCR. We are awaiting responses.

Unclear from question Payer A vs. Payer B as new or old.  We walk the workflow. 

For 1/1/2022 you only need USCDI to comply with reg. and you will get a transmission of who sent the bundle (not the origin). e.g. Origin might be "I got this observation from St. J's Hospital in a CDA." That could be included in the bundle. If you want to package it up to a new payer. 

If you know the orgin (St. J) you'll want to include a provenance record showing the source of the information as St. J.  You'll also want to include the transmitter info if you are getting the data from a previous payer and passing it to a new payer.  So, in that likely scenario, provenance records would be for each:

• You as a transmitter 
• Prior Payer as a transmitter
• St. J - the origin 

Note:  If I make a request to Patient/$everything, it may not come with provenance, unless they ask for it.  If payers want to protect themselves they should be asking for the provenance records as well - see notes below on this and we will also add more FAQ language to advise. 

Note: The /Patient/{id}/$everything operation specified in PDex may not support the _revInclude query parameter since it is an operation and not a regular GET request. If access is provided to the Clinical USCDI resources a user can query using the various clinical resources and use  _revInclude to request the associated Provenance resources.

See 022 above.  The provenance record relates to everything in the bundle. Provenance can have multiple targets.  You could get many that apply for one resource or many resources. Rule for provenance is that it's one provenance for the event.  

It's unlikely that a payer is only transmitting the records from the prior payer to the next payer, that implies that the current payer would have 0 activity for a year for the payer.  More likely, you've had info from yourself and from the prior payer.  Transmitter will be you, but the details of each of the records will be where it came from and should be passed along in provenance as well. 

You'll provide provenance for the bundle and you'll provide provenance for all the other sources you have data from.  

Discussion related to 022 and 023:

If the Payer does a $everything, does it include the already created provenance for a particular resource?  Unknown. 

You have to do a _reverseInclude of provenance to get it...

Definition of $patient everything is a little loose, it does say they "should" include provenance.  

$patienteverything is not actually a search. 

Expectation of USCORE is that you'd return the last organization that touched it. If you have provenance for the record that you are including everything for, you should include it.  

IG does require a provenance for the bundle that says "Hi, I'm Payer x and I'm the transmitter" also... all should read the IG and we will provide FAQ guidance here. 

Summary: If you use $everything, you should get the provenance by defining all of the resources required in the _type input parameter, if not, you can't do a _reverseInclude, you would need to query each resource separately.  Payers should on a $everything include any existing provenance records. 

 Payer App would expect to be synchronous with the request.  If B2B (Payer to Payer), the pended Burden Reduction regulation said the timing should be "within 24hours".

It's hard to answer definitively until we know how we are going to solve it.

I read that Payers can receive Non-Fhir data such as CSV, delimited, fax documents, emails etc. from other payers as part of payer exchange. Are payers obligated to ingest or import these Non-Fhir Data into their FHIR servers? Or should they just store them(non-fhir documents) in a separate server so that the same can shipped to other Payers when they ask for it. How should this part of regulation be handled by Payer. Please advise.

Should $member-match operation take member consent as a parameter? If so, what will be passed as a consent to $member-match operation. The current $member-match operation described at https://confluence.hl7.org/display/DVP/HL7+Da+Vinci+PDex+%24member-match does not take consent information as a parameter.

Do we need to implement/cover both member directed exchange and member mediated exchange scenarios of Payer data exchange mandate.

In case of both member directed exchange and member mediated exchange, is the member consent stored in both New payer and Old Payer health plans? How do the consent carried forward from New Payer to Old Payer or Vice versa?

With Member-mediated exchange the Consent would occur in the Old Payer's API interaction. 

With Member-directed exchange and the $member-match operation the Consent would be originated at the New Payer and incorporated as an element of the Transaction. It would therefore be available to both New and Old Payer.

Excerpts from FHIR EOB Resource copied to draft response: https://www.hl7.org/fhir/explanationofbenefit.html

The ExplanationOfBenefit (EOB) resource combines key information from a Claim, a ClaimResponse and optional Account information to inform a patient of the goods and services rendered by a provider and the settlement made under the patient's coverage in respect of that Claim. 

Typically the EOB is only used to convey Claim (use=claim) and the associated ClaimResponse information to patients or subscribers. It may also be used to convey consolidated predetermination and preauthorization request and response information to patients or subscribers.