2023-02-03 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.

Feel free to reach out on Zulip or through Touchstone Support if you have questions. 

• Close to finalizing PDex STU2 for publication. 
• If additional issues are identified as part of our review of the Prior Authorization Proposed Rule or implementation, can always consider an STU update.
• It is important to get this IG published soon so CMS could potentially recommend this version of the IG. 
• A few things to resolve in coordination with the FAST National Directory workgroup. They are in the process of consolidating National Directory IGs into an uber IG (called NDH).
• The tickets related to clarifying endpoint resources - should be referring back to the National Directory IG, specifically the format of public certificates. As soon as that information is clarified, should be able to update https://jira.hl7.org/browse/FHIR-40236, https://jira.hl7.org/browse/FHIR-38698, and https://jira.hl7.org/browse/FHIR-38697.
•  Information on what Mark was able to do this week: 
• Mark moved the test repository used for Connectathon to the HL7 Da Vinci GitHub account: https://github.com/hl7-davinci and https://github.com/HL7-DaVinci/pdex-payer-payer (Payer-to-Payer mTLS Discovery)
• Mark will add these reference from the payer-to-payer page. 
• Mark reviewed an Example Endpoint
• DV: You said that top value was the server certification - DCRP Server Registration Certificate?
• MS: No, there are two certificates 1) mTLS endpoint; 2) trust framework
• DV: If this endpoint registration has public certificate that you will find, what if it's not the right information? What if I have a public certificate in here but the one I retrieve is not the exact certificate. Is that a problem?
• MS: The client is also including a certificate for the bundle they are submitting so both derived from same top level entity.
• DV: Not sure that will fly. MS Azure implements mine for me and I'm not going to buy another certificate for this scenario. 
• MS: What we are trying to do - if you are setting up mTLS within your own organization, you can have a server certificate that implements that TLS capability. What mTLS is saying, I've generated server and client certificate that come from same root. 
• DV: But they don't have to come from same root to be validated. If I have gathered a server certificate and client certificate signed by CA. I'm supposed to put this client certificate in this bhundle  to talk to my server? 
• MS: You are putting server cert; not the client cert.
• DV: How does client get my certificate? 
• MS: They will have to go to one of the CAs
• DV: It has to be THE CA that is the server certificate. Does that mean there is only one CA so that everyone can get their client certificates? 
• MS: The CAs that have been discussed for this, there were three well known names. It may require that server has certificate from each of them. 
• DV: I can't have three different server certificates for one endpoint. Part of the problem is trying to bind client and server certificate being signed by same CA. I think this is a limitation. Server certificate needs to be trusted. Server has to say, we only trust server certificates by this organization. The server will say, give me any client certificate you have, and if you can prove, the server will go out and ask if it knows this client certificate. Understand the need for the certificate to be signed. 
• MS: The other side of this is how these certificates are tied into the trust framework. 
• DV: If I put this certificate in the bundle, is it the only that can be used for server identity?
• BD: If you put in the bundle, you have clarified that this is the one that you are using. 
• DV: That's my point, why even put it there. If I go buy a GoDaddy Certificate today and security group says I need to change it to Norton later. I have to go back and put a public version of the new certificate in the bundle and update the bundle? Whereas if I put in my endpoint, its there in one place an in one place always.
• BD: The intent of the directory is to be the one place. 
• DV: I can look at public cert in national directory and decide, yes, I trust that CA. Why would I do that?
• BD: Wouldn't you always do that so that you trust the certificate?
• DV: I will test whether I trust the certificate on the website, no matter whether or not it's in the directory. I'm always going to test the endpoint. If I looked at directory and saw that this certificate was signed by an entity to never trust, maybe i wouldn't go to that endpoint. My trust situation is up to me. Even if I say I'm going to trust this endpoint, I'm still going to do the same check. 
• BD:  A lot of what we are putting in directory could be treated the same way. If you do query on directory and get back five different endpoints, you can use that set of data to filter down to one. Much of this is up to you to use. If you find some of it is irrelevant, fine. I doubt we will drop them but you don't have to use them.
• DV: If I hit an endpoint and get a valid and trusted certificate but different than what is in the directory bundle, then should it be terminated or received. 
• BD: Will depend on your standards of practice. We will never dictate whether or not you should connect.

Adjourned at 1:55 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