2021-06-11 PDex Meeting

• 2021 CMS HL7® FHIR® Connectathon - July 20-22, 2021
  • Information and Registration here (it's free): http://www.hl7.org/events/cms/
  • Confluence page: CMS 2021 - 07 Connectathon 2

Rob and Bob discussion to clarify available values.  Rob - what is in the provider taxonomy for pharmacy are like retail: Clinics, mail order, compound, etc.   It seems to be more like "can I get it while I'm there or will I get it by mail?" info. Makes sense. 

Finalized (no one objected)

Recent Implementer Questions:

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

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

2. 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? Please let us know. Based on my understanding after reading the PDEX specification, I felt that Payers need to build a web portal for exchanging payer data. Is my understanding correct?

Short answer: we cannot answer today. Some context on the two schools of thought in discussion as of now: 

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

or

B - The member should go have to authenticate in the old plan 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?

3. Provenance: Let us say Payer A got a bundle of resources after doing Patient/$everything on a members data from Payer B. And the Bundle contains let us say 10 claims, 1 coverage, 25 observations, 3 conditions etc. all originated at Payer B. Then, we need to send one provenance record for the Bundle and one for each resource type inside the bundle. Is my understanding correct?

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

4. In case the Payer is just a transmitter of data from one payer to another, then do we need to create just one Transmitter Provenance record or one transmitter provenance record for each resource type inside bundle? Please explain provenance scenarios with some examples for clarity.

See #3.  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 #3 and #4:

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 - let's add this the the FAQ page: If you use $everything, you should get the provenance, if not, you can't do a reverse include, you would need to query them separately.  Payers should on a $everything include any existing provenance records. 

One final Question: On payer to payer exchange, what is the expected response time? Payer App would expect to be synchronous with the request.  If B2B (Payer to Payer), the pended regulation said within 24hours, but it's hard to answer until we know how we are going to solve it. 

2021 CMS HL7® FHIR® Connectathon Overview of Track

Implementer Support

Review FAQ Proposed Responses 

PDex IG Companion Guide List

PDex IG Companion Guide - Laboratory Reporting Resources

Latest draft CARIN CPCDS Mapping document: CARIN Mapping to FHIR interim 2020 0818 v2.xlsx

DRAFT - PDEX US Core Mapping from CPCDS source: ResourceMappingUSCoreCPCDS-2020-05-29-v26.xlsx

Find initial questions and corresponding answers shared from our colleagues at CMS here

• Links to Published IGs

• PDex STU 1.0.0
• Plan Net STU 1.0.0
• Formulary - STU 1.0.1

Implementer Resources

Da Vinci Implementer Support Page

Implementers can take advantage of tools: See the Reference links on the Payer Data Exchange (PDex) page to access links for Reference Implementations, sandboxes, test scripts, and more!

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

CMS Final Rule Questions and Answers log

ONC FAST National Healthcare Directory (including end points) solution page that includes links to everything (solution doc, Connectathon, HL7 workgroup, etc.): https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/National+Healthcare+Directory