2023-02-10 Payer Data Exchange (PDex/Formulary/PlanNet) Implementer Support Meeting

Review ANSI Anti-Trust Policy

Planning Da Vinci IG Implementation Testing?

Learn More here: Open Testing Tools - Build and Validate with Touchstone

The Touchstone Support team and Da Vinci Test Script authors are available to answer questions and provide support with testing Da Vinci Test Scripts in Touchstone.  Please don't hesitate to reach out to Touchstone_Support@AEGIS.net.

• No updates on progress to IG this week - still working on the outstanding National Directory tickets.
• SN: Health plan to health plan flow - if using an intermediary, I send FHIR message from payer to intermediary; and intermediary sends to receiving health plan. How is identity passed to receiving health plan? 
• RF: Think about what FAST Accelerator has done - may be worth while to think about that IG as well. 
• MS: Stepping back - some of the discussions on NPRM calls, there is recognition that we need to identify functional requirements coming out of the proposed rule and ultimately the final rule. And there may need to be additional capabilities baked into the existing IGs to meet various requirements. For example, we have provider API as draft in latest CI build of PDex. But this allows for partitioner to query payer for API but no access controls - obviously a gap. Payer to payer, we built the flow on the basis of one payer connecting to another and agreeing to be in some common trust framework. It hasn't been designed around using a third party as a relay, but at the same time, there are many plans that outsourced API capabilities to business partners that are acting on their behalf. So there may be options with intermediaries to relay the messages on behalf of originating plan. 
• SN: Explains the business process but most interested in identification side. I'm a provider and contracted with company A to handle my FHIR services. I send a request to a health plan through this FHIR service to request information on a patient. Does the identification have to be from the business partner or does that business partner need to identify Dr. Stanley as the requestor. 
• MS: On the provider API, that could be part of the stuff we deal with. How will a provider actually get access to these secure APIs. It's likely that a provider has a direct contract with the payer and may have access credentials through a provider portal. But what happens to providers that may not be in network but may still need to check for a prior authorization. Or get info for a patient before they treat. How might there be a trigger around an apt booking to identify an impending treatment relationship. A lot to sort out. Have to identify the functional requirements that need to be delivered for the industry.
• SN: So, answer is it is being looked at but still to be determined. 
• MS: Also the TEFCA pieces to take into account. Will be a lot of follow on activities. Which is why we want to finalize this STU2 version and then open PDex up for STU update to take into account any changes. 
• JH: Can you clarify the publishing and STU update? How does that work with the final rule comment period in March and how can it effect CMS' reaction - they need to update their current view of STU1. 
• MS: Proposed rule today references STU1 for PDex. But this didn't have anything for payer to payer and provider API. Even though we may say, we are still trying to resolve some items, there is a substantial amount of work done that could benefit from publication (e.g., member match, etc.). If we get this published, they can recommend STU2. Then we tune PDex to the needs of the proposed and final rule. 
• SN: Also a matter of timing, once proposed rule comment period ends, no requirement for timing of final rule. 
• MS: In the proposed rule, CMS says that they expect plans will need at least 30 months to implement requirements of the final rule. So, it suggests that CMS thinking may be that they need to be publishing this final rule within 3 months after the proposed rule comment period. 
• SN: There is a relationship between implementation date and publication of the standard to be implemented. 
• MS: CMS recognizes the need to do this quickly (whether 3 or 6 month) - they need to give the industry something to aim for in terms of implementation. 
• JH: Find it interesting that CMS webinar - they illuded to being flexible but didn't say how they will do it. If playing the odds, let's get STU2 published. We all know there are issues with STU2 but let's get it out there.
• MS: Ideally, we want to use National Directory and UDAP, but when we put this out for ballot, we didn't have these options. Making the change would be major and force us back to ballot. 
• RF: We have to remember what the industry has gone through with HIPAA. Everything is moving much more swiftly than it ever used to. Some of these final rules, we will have to be flexible with versioning IGs rather than writing a whole new rule. 
• MS: That is the advantage of CMS saying you will use FHIR R4 and then recommending versions of IGs so we can move forward. Payer to payer exchange where its member mediated, really side steps issues. Member is in the middle and they are trying to make the connection. We have two covered entities trying to accomplish sharing information under direction of the member. Need to agree that we are going to do this in a consistent / standardized manner using agreed upon practices. And who is the entity that will administer that trust. 
• JH: If you used UDAP and one actor is client and other is the server - UDAP provides permission grants as part of handshake that are very specific. The challenge is we have a bunch of payers implementing UDAP to meet patient access API components and we are asking them to spin up this other concept using a generic trust framework. 
• MS: We just didn't have a standard to point to at the time. Welcome input from payers implementing UDAP - is it scalable to implement with other payers. How is the acceptability of that solution changed? 
• EZ: Evernorth has Tom Loomis - can bring him here to discuss UDAP and our experience. 
• MS: Would be great and if anyone else - Ron at CVS. Were involved in architecture discussion that made this decision. Payers need to determine if we should revisit this and how we go forward. 
• MS: I can also reach out to Luis - author of Security IG to discuss how it may be utilized in PDex scenario. May be helpful to understand how to address what we want to do. 
• Will add as a topic for a future agenda - understand how UDAP can meet trust framework requirements. 

Adjourned at 1:41 PM ET

Source code is here: https://github.com/HL7/davinci-epdx

Payer-Payer Trust outline: Payer-Payer Trust V3.docx

Mark Scrimshire

Corey Spears

Charlie Provenzano

David Hill (Dave)

Lloyd McKenzie

Robert Dieterle

Susan Langford

Daniel Venton 

Jeff Brown 

Christopher Gracon

Alex Kontur

Chris Johnson 

Ezequiel Morales 

Mark Neumuth 

Damian Smith