2021-02-26 PDex Meeting

Learn More here, Registration Link Coming Soon.

Background: Formulary IG was written originally to support an open Access API and the shopping experience.  The Rule came out to focus Formulary behind Patient Access API and for a specific Patient.  

So, thinking about the scenarios for the Patient Access API per patient request example: 

Member Auth. - the payer that is putting all these data out through one end point (as part of the CMS Rule) - this is the base URL.  This is showing the complete picture, this isn't saying that the Formulary is dependent on Claims and Clinical data. We are assuming the formulary provided is the one that the patient is on.  (there should only be one.) 

If the patient is searching for a drug that is not part of their plan, they it would return a "not found" response here. 

The other example for shopping: 

Is there a requirement to show group plan as well as individual plans? Group plans are specific to group sponsor... Group plans should not be part of the shopping experience since a patient cannot subscribe to it yet? 

• How do we constrain the plans that are returned? (i.e. filter out the group plans that are not available if they aren't part of the organization?)

Formulary is on Rx Norm.  

Do you envision aligning with the DS for P approach? 

Acknowledgement of consent of edge to edge. 

Jason from EverNorth - "Consent" may not be the right word - this is more of an authorization process?

Exchange the way it happened between the two parties is a consent resource. 

Path for authorization could start at the old or new payer. 

Server-to-server communications this is covered entity to covered entity 

Discussion on what the right pattern to use is.

Recommendation to discuss further on the Architecture call next week with implementers. Michael Gould will add to that agenda. (Da Vinci internal meeting) will elaborate on the conversation there. 

Questions to be reviewed and responded to, 

1. My understanding is that CMS regulated Payers need to implement just the Payer to Payer exchange at the member request and Payer to third party application exchange at the member request interactions by the beginning of Jan 1^st 2022 to meet the CMS Payer to Payer exchange mandate. Is my understanding correct? And Payer to Provider interaction is out of scope for Jan 1^st 2022 CMS Mandate. Please confirm.
2. Please let me know, 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.
3. It is mentioned in the IG that whenever a member moves from old health plan to a new health plan, the new health plan shall invoke a $member-match operation on the old health plan fhir server. Is the $member-match an open API operation on health plan Fhir server? In other words, can new health plan call $member-match operation on the old health plan without any authentication and authorization? Please confirm.
   1. If it is indeed open, would that not cause major security issues as anybody can get the coverage information from Health Plans by issuing $member-match on the fhirserver.
4. How does providers and payers know the FHIR servers end points for data exchange?
5. 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.
6. 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?
7. I understand that $everything shall be supported by the FHir server for exchange. Does Fhir Server’s Bulk Import and Bulk Export APIs also a requirement for implementation of this specification?
8. The Pdex IG is in currently in STU(Standard for Trial use) stage. What is the timeline for Pdex IG to become mature to be used for production implementations?

From Chat:  Hello Everyone! For Payer to Payer Exchange and for Inbound Data Payer is obligated to accept from Payer B. We anticipate the data from Payer B that will be in non-FHIR format, like Excel File, PDF etc, How can we connect with Other External Payers (Payer-B) have a basic idea for type of non-FHIR data they plan to send to Payer A.

Are we obligated to accept non-fhir content?  See CMS Final Rule Questions and Answers log the first few responses 1002-1004 may be helpful. 

PDex IG Links and Updates

PDex Supplemental Guides

PDex IG Companion Guide - Laboratory Reporting Resources

NPRM that cites membermatch: https://www.cms.gov/newsroom/fact-sheets/reducing-provider-and-patient-burden-improving-prior-authorization-processes-and-promoting-patients

Note recent announcement impacting changes to HIPAA regulations that we support an old plan sharing information with new plan at patients request.   

FAQ Review Cont. and Implementer Support

Latest draft CARIN CPCDS Mapping document: CARIN Mapping to FHIR interim 2020 0513.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