2023-03-31 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 

Upcoming Conference Call Adjustments

• March 31st: Shortened call - start at 1:30 PM ET
• April 7th: Shortened call -  start at 1:30 PM ET
• April 14th: Normal call - start at 1:00 pm ET; Plan Net discussion second half of the call
• April 21st: Cancelled due to HIMSS
• April 28th: Normal call - start at 1:00 pm ET; Connectathon Kick-off
• May 5th: Cancelled due to Connectathon travel
• May 12th: Cancelled due to WGM

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

• • April 14th 

Shortened call while waiting for input. Holding that call at 1:30 PM ET allows for those participating in FAST to join. 

Plan Net questions will be addressed in the April 14th call.

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

• Federal Register (officially published 12/13/22)
• Fact Sheet
• Comment period closed 3/13/23
• Da Vinci Comment Response Posted: Da Vinci (under Industry Statements & Updates)

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 (comment period extended to 4/22/23)
• Da Vinci Comment Response Posted: Da Vinci (under Industry Statements & Updates)

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

• 2023 - 05 Connectathon 33
• 2023 - 05 Da Vinci Payer Data Exchange (PDex) and Formulary
• PDex Track Kick-off on April 28th at 1:00 pm ET

HL7 Working Group Meeting, 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. WGM+ Agenda now available! 

Register here before Saturday, April 15th to take advantage of the early bird rate.

MS: There was a CARIN Alliance meeting yesterday. Under the prior auth proposed rule there is a requirement for a provider API capability to publish claims and encounter data without the financials. The Patient Access API has been pretty widely adopted because of the CMS Interoperability Rule. There are hundreds of millions of claim records that have been created because we now have close to 7 years of data that needs to be maintained for each member. If we don't design it correctly, there is risk of duplication of data in order to produce the data in a new profile. Or it could require a lot of complex processing in the orchestration layer to filter out the necessary data. The CARIN Alliance group has been working through some ideas and I wanted to relay the ideas back to you. 

Explored using the summary view. It doesn't work due to the way the base resource is configured.

There is a base COB profile and the CARIN BB IG created an abstract EOB resource which has multiple profiles for institutional, professional, vision, dental. One option we are looking at is an additional set of profiles defined (currently called) EOB Non-Financial. That removes the amount and total fields that are used to publish an EOB. What we are proposing would effectively delete those fields from the profile and then there would be the existing profiles that have all of the data and both of these are derived from the abstract profile. The reason we can't just do a one on top of the other inheritance is that if we constrain down the non-financial profile to remove the amount and total fields then we can't unconstrain that in any profile that is derived from that. So we will effectively have to have two parallel sets of profiles. From an implementer's perspective, you could effectively have an API endpoint that would access the non-financial profiles and another endpoint that could be accessing the full profile. The team didn't want the amount fields to be optional because that could have led to less data being available to the member.

CS: We're trying not to make any changes that would break the existing profile.

MS: We want to test a Connectathon. Can we load the data effectively for an abstract profile and then pull off two different views?

BD: How does the API single endpoint decide what you have access to?

MS: That would be down to the resources or scopes or  you could implement as two different access points. Want it to be enforceable from the server side, not relying on the client side being obedient.

CS: Practically speaking, how are implementers doing this? They have 3 APIs. How are they making them available?

MS: At the moment they haven't had to. There is only the member view. In the next revision, we need to address bulk FHIR for multiple patients.

BD: Conceptually we can constrain a scope on a token to only be the non-financial. Has anybody done it?

MS: You can do it using SMART on FHIR STU2 set of scopes. There is the ability to effectively define the equivalent of the search parameter so that you could constrain to a profile.

BD: You'll never get both profiles.

MS: No, that wouldn't make sense. You only get one or the other.

RA: What is the adoption for the SMART STU2 scopes look like so far?

MS: I don't have any visibility into that.

MS: Thinking about it more, if you used API endpoints as a method of control, you wouldn't need SMART on FHIR STU2 because on the base URL you could have your capability statement that could constrain to the profile. I believe you could have a non-financial access point and a full access point.

BD: Can we have an access token that constrains to a capability statement? I believe we can. In which case, don't bother with the profile, do it with the capability statement. If I constrain my token to a capability statement, I already constrained it to a profile.

CS: The capability statement is specific to an endpoint. 

MS: You would still have the resources defined in your scopes that are available through that endpoint.