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

Single meeting on Fridays from 1:00-2:00 PM ET (reduced to 1 hour)

Zoom Meeting https://hl7-org.zoom.us/j/92482555863?pwd=TWQzVENNeStqeEpVTHdicGM2cGdMQT09 

NEW! PDex Directory/Plan Net discussions will occur during the 2nd meeting of each month (last half of this call). Upcoming discussions:

• • March 10th
  • April 14th 

Da Vinci is formalizing dedicated time for Plan Net discussions. Next week, we will discuss Plan Net topics (implementer support questions and issue tickets) during the second half of the call. 

May Ballot Cycle 

• Take part in the formation of consensus groups for the HL7 May Ballot Cycle! 
• Da Vinci Risk Adjustment Implementation Guide is included
• To participate in voting, you must join the consensus group by March 30, 2023
• Commenting and voting will take place March 31 – May 1, 2023

Need help navigating? Review the HL7 Balloting Resources for Da Vinci Newcomers

Upcoming HL7 Meetings, New Orleans, Louisiana

• HL7 FHIR Connectathon, May 6-7, 2023
• HL7 Working Group Meetings, May 8-12, 2023

New WGM+: These sessions at the May Working Group Meeting will help augment the typical standards development work happening in HL7's Working Groups and broaden the audience of those who wish to participate. Our theme for the meeting is policy as a driver of interoperability.

CMS Advancing Interoperability and Improving Prior Authorization Processes Proposed Rule (CMS-0057-P)

• Federal Register (published 12/13/22)
• Fact Sheet
• Comment period closes 3/13/2023

Administrative Simplification: Adoption of Standards for Health Care Attachments Transactions and Electronic Signatures, and Modification to Referral Certification and Authorization Transaction Standard Proposed Rule (CMS-0053-P)

• Federal Register (published on 12/21/22)
• Comments due 3/21/23

PDex Future Enhancements Page  

Find it under Da Vinci / Da Vinci Use Cases / Payer Data Exchange (PDex/Formulary/PlanNet) / Payer Data Exchange (PDex)/ PDex Supporting Materials

• We are actively thinking about what we need to do to make sure that PDex guides meet the requirements of our members and the industry. 
• As we close out PDex STU2 ballot cycle we want to open up for STU2 update to augment the guides, we have created a Future Enhancements page in Confluence to support gathering of requirements. 
• This Confluence page is to capture high level concepts that may eventually evolve into one or more Jira issue tickets. 

• CT: Questions about relationship between organizations and endpoints. Scenario where you have a payer that has multiple lines of business, in multiple states, and serving data out of base FHIR server. My assumption is, as a client application wanting to connect with a server, I would register once with that organization. But how to model endpoints for various lines of businesses. If you think through member driven process, and a member opts in at enrollment to transfer data and providing former insurers name, would we want them to provide overall organization or would we be asking for specific health plan? 
• MS: With patient access API today, they will have one API serving 30 different plans. What you would have - you would have organization record for each plan that would point to an endpoint record. One endpoint record for all of those plans that may be using the same endpoint. So you may have 30 orgs pointing to one endpoint record. Managing organization in endpoint resource may point to a vendor or the payer itself, separately from individual plans. Then, you could search on a plan to find their endpoint. You understand who is managing the endpoint and the endpoint reference to PDex RI; allows you to find operation; endpoint resource would have dynamic registration endpoint. But will only be possible if mTLS in place. 
• CT: You're saying there is a way to query for all the individual endpoints from the base URL for all those lines of business. Based on model you are describing, there is one endpoint record with base URL, and we would go to base URL to discover. 
• MS: Can you construct a query called rev.include to search for specific endpoints for plans - the logic would be that you would have organization record for each plan that points to endpoint that they are using to serve up their data for payer to payer. Working on with NDH to define extensions that define PDex payer to payer as a use case within an IG to find the capability statement which gives us access to registration, etc. 
• DV: As I'm understanding, the problem is, you have a domain that supports multiple payers. IF all you know is the domain, how do you discover the payers individual endpoints underneath that. If you had an endpoint resource that says this is endpoint A, the URL wouldn't be the domain name.
• MS: If you are implementing a unique endpoint for a plan, if each plan has separate entry points, then you would have an organization record for the plan pointing to that endpoint. If configured in a way where you have one PDex endpoint supporting multiple plans, you have one base URI for that IGs APIs, then you have one endpoint record for multiple organization records pointing to that resource. 
• DV: Then you query to make some determination?
• MS: If you were searching via the endpoints, you would ask for all endpoints for payer to payer use case and do rev.include to see which organization records reference that plan ID is xyz. 
• DV: Either way, you still have the URL to go to. No way to say, because organization is plan X, you modify the endpoint URL in this manner.
• MS: If you have unique endpoint for each plan, you have a unique endpoint record. 
• DV: And if you have a shared endpoint, it's still the same. What does it matter if one or many.
• MS: The endpoint resource in directory, for this plan, what's the full URL you go to get to PDex use case. If you have United.com/plan1/PDex, that's the entry point for PDex IG for that particular plan. The next plan has a different URL, that would be two different endpoint resources. It depends on how implementers implement their APIs. If United implemented so that there is one API for all of your plans, member match coming in will give info about plan, member number, etc. without additional parameters by requestor, you can basically ID down to individual member and run as one API.
• DV: If I have 1800 organizations, i have 1800 plans, I have to look at plan data that member selected? 
• CT: Based on working with some customers (scale of 20-30), how they implemented patient access APIs, each line of business has own endpoint. If you make request, you have to do to specific plan identifier. It's what prompts my question. Is there a model that everyone is using? 
• MS: We can provide examples but don't think we want to mandate, one plan/one URL. If you give me a member number, I can identify what plan they are part of. We don't want to stop that. It depends on how plan puts APIs in effect and then publish how they get discovered. 
• TL: I think we should provide some guidance on this. 
• MS: Ultimately, you want someone to find the plan, identify what URL they go to to query data for the plan. That is what we are trying to represent. We can give examples, but don't think we mandate it's a 1:1 plan to URL. It ties an implementer's hands. 
• JH: What is use case to query data by plan versus by patient? 
• MS: We have a member match function - if I'm a new plan, I get some information from the member for their old plan. Think about what's on the card. That's the data that allows the new plan to find the old plan. We don't have a national ID for plans. Therefore, you search on that plan to find where's the endpoint - you can search on organization record, get the endpoint profile that it references and look up details on how to connect to plan to find the resource. If you have a payer and they have multiple plans but being serviced by same API endpoints, then they have 40 organization records, all referencing the same endpoint resource. If payer decides they want unique endpoint per plan, they can do that too. You don't want us to mandate that there is only one way to do this. 
• CT: The challenge is, you have this heterogeneous approach and it impacts what you collect from end user who is making the request. 
• MS: At the end of the day, you ask what was your plan. Plans are starting to put URL on cards. Need a way to identify plan and member data. That's what we are trying to enable. 
• TL: Since talking about what's on the card, is it similar to calling them up. Are there different 800 numbers for every plan? Or is there one number and the payer knows where to go to get specific plan info. 
• MS: The problem is, the new plan only has information from the member's card. As a plan, in order to be discovered, is there something like the customer service number that is unique to the plan or a URL. Or is it plan name? If the plan name, can it be searched on? 
• CT: Related question - reviewing HRex profiles for what gets submitted to member match. Only see two required fields (name and birth date). 
• MS: HRex went with patient demographic, because if you try to use US Core, you can provide more information on the card. You as the new plan, don't have all the information in terms of system values, etc. that old plan would have. You can't produce a valid patient record You can only pick up information like name, DoB, gender, member ID or subscriber ID, plan/group number off the card. 
• CT: I had assumption that member ID would be primary matching value.
• MS: Some plans use subscriber ID. Same number for the husband and wife. So can't be used to ID actual individual patient. Varies from plan to plan. 

PDex IG Companion Guide List

PDex IG Companion Guide - Laboratory Reporting Resources

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

For questions, reach out to us on Zulip:

• PDex: https://chat.fhir.org/#narrow/stream/235286-Da-Vinci.20PDex/topic/Implementers
• Plan Net: https://chat.fhir.org/#narrow/stream/229922-Da.2BVinci.2BPDex.2BPlan-Net
• Formulary: https://chat.fhir.org/#narrow/stream/197730-Da-Vinci.20PDex.20Drug.20Formulary

Formulary - Searching by DrugName.docx

Recording of Formulary Tickets for STU 1.1.0 Overview

Karen Barbeau

Diederik Muylwyk

IQVIA

Tulsi