| Management | Review ANSI Anti-Trust Policy 
| |
|
| Announcements | Single meeting on Fridays from 1:00-2:00 PM ET (reduced to 1 hour) Join Zoom Meeting https://hl7-org.zoom.us/j/92482555863?pwd=TWQzVENNeStqeEpVTHdicGM2cGdMQT09 |
|
|
| 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. | |
|
| Da Vinci Listserv Refresh Da Vinci worked with HL7 to create listservs for the following use cases: - Burden Reduction (BR)
- Clinical Data Exchange (CDex)
- Member Attribution (ATR) List
- Notifications
- Patient Cost Transparency (PCT)
- Payer Data Exchange (PDex)
- Risk Adjustment (RA)
- Value Based Performance Reporting (VBPR)
We have pre-populated the listservs with group members. Please review your subscriptions HERE. You will need to log into your HL7 account. Expand Da Vinci Project in the menu on the right-hand side of the page to view the new listserv options. |
|
|
| CMS Advancing Interoperability and Improving Prior Authorization Processes Proposed Rule (CMS-0057-P) |
|
|
| 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) |
|
|
| PDex IG Tickets | Latest CI Build https://build.fhir.org/ig/HL7/davinci-epdx/PayerToPayerExchange.html
Unresolved:
| T
|
Key
|
Summary
|
Assignee
|
Reporter
|
P
|
Status
|
Resolution
|
Created
|
Updated
|
Due
|
| - Around five issues remain. Three related to endpoint resource and associated certificates.
- Bob and Mark met yesterday to discuss how to resolve the open questions and get to a point where we can publish the IG.
- RF: In looking at the FHIR spec for endpoint extensions. We know ONC moved FAST into an HL7 Accelerator and a lot of work being done in that space. How is this group coordinating with FAST activities?
- MS: Bob is deeply involved in National Directory. Bob and Mark have been reviewing a couple items.
- In previous build, having trouble referencing particular code systems. Turns out it was an incorrect link put into FHIR Shorthand. Now a new build published yesterday which resolved the link errors.
- While troubleshooting that issue, had a discussion around the endpoint resources. There is work to amalgamate the three National Directory IGs into a single NDH IG.
- We produced a reference implementation of a repository with bundles of resources. We created a repository with supporting documentation and examples of bundles with endpoint information resources. This created a model to load a dockerized HAPI server, load the bundles, and then query against the bundles to get the payer to payer endpoint information.
- If we look ahead to National Directory, need to be able to identify which endpoints are relevant to the payer data exchange workflow. In the future, with TEFCA/QHINs, there could be a scenario where plans aren't connecting directly but going through third parties (e.g., QHINs). How do we identify the endpoint records that are relevant to this workflow? Bob is taking this question to determine
- At moment, within endpoint bundle, there is a "name" that indicates that it's for payer to payer exchange, but not a recognizable value. Exploring whether there should be a field in the endpoint resource that allows the specification of this; something that allows people to actually search on that field and retrieve one or more records. We will update our examples and NDH will update their profiles to explain how this is done.
- Trying to coordinate and stay in sync.
- RF: That's helpful. A lot of essential activities taking place that need to be coordinated.
- MS: CMS is going to require provider APIs and payer to payer APIs, and expansion of patient access API with prior auth data. Many of these things require ability to discover where you need to go. Need to be able to discover the endpoints. What we have done to date with this repository, is to enable some level of payer to payer exchange, knowing it's only involving a couple hundred payers. But if we expand to all payers and providers, this is not scalable. There needs to be some sort of directory or discovery service to enable these APIs to be fully leveraged.
- SN: How is the problem solved in provider to provider scenario?
- MS: That's the questions - will this be supported by TEFCA or not. We are more focused on provider to payer and payer to provider in Da Vinci so we need to focus on how that gets addressed. Increasingly, there are exchanges that need to take place and a discovery element needs to be enabled to support secure transactions.
- MS: Bob and Mark also discussed how the trust framework will work. Bob working on workflow to address some of these concerns and may be able to incorporate into the IG to address questions around mechanics for establishing the secure transactions.
FHIR-40369
-
Getting issue details...
STATUS
- DM: If I'm a new payer and invoked against a previous payer. May be doing multiple exchanges for same member. Want to be able to update the resources in the new payer appropriately and reconcile them. With identifier, can do a conditional update. Some resources don't have identifiers so suggesting that we use an extension on resources that don't have identifiers.
- MS: Would you take the FHIR ID from the store and write it as an identifier in the record.
- DM: Yes, and need to capture it somewhere. For those that don't have an identifier element, we still need a place to put this so we can conditionally update those resources. Just making sure we are doing the same thing for those that don't have identifiers.
- LM: There are very few resources that don't have identifiers. Most common is binary, which can't have extensions. What you need is an ability to link that data up. You don't have to surface that linkage with identifier in order to have it in persistence layer.
- DM: Realizing that, I don't want to recommend this. Other concern, if you are doing it within the body of the resource and it is getting forwarded to another payer, there will potentially be weird extensions that people won't recognize.
- LM: Accumulation of extensions that you don't recognize is a normal part of using FHIR.
- MS: What we are expected to exchange would be claims without financials, and clinical (US Core 3.1.1.). Not sure there are any resources in US Core 3.1.1 that we are expected to exchange that don't have an identifier. Would it be reasonable to incorporate binary into a document reference?
- LM: When dealing with binary, it's going to be pointed to by something else that you are also exchanging.
- DM: Convinced that we can drop this.
- Marked the ticket not persuasive.
- RA: Why wouldn't MDM (Master Data Management) be available for a situation like that?
- DM: MDM is certainly a possibility but looking for options that don't require it as a necessity in our solution.
- MS: In the IG, we wouldn't be defining how implementers would use MDM in order to accomplish something. We are focused on the impact within the context of FHIR.
|
|
| Trust Framework | Resume discussion about Trust Framework (bottom of the hour) | - BG: Who signs the certs?
- MS: Waiting for Bob's overall flow, buy concept is that payer would go to an established CA, go through an identity verification process, they would be issued a certificate by that CA.
- BG: What I have heard, is there isn't a lot of desire by CAs to accept this amount of liability. Have any of the CAs stepped forward to say they are willing to issue certificates for this use case?
- MS: Haven't been part of these discussions but that is the proposal on the table at the moment. Talking about certificates issued by one of the major CAs so you can navigate through the certificate chain to determine that certificate is valid.
- BD: Got the impression that we were moving away from that. A payer would go to one of the acceptable CAs, get identify proofed, and get issued an mTLS cert and get issued a signing cert. The payer would construct the payer to payer bundle based on the standard we give them. They would include mTLS cert (public) in the bundle, and include the endpoint, contact information, etc. They would create/sign with their signing cert, the bundle. They would also include the public cert. They stick that whole thing in GitHub and when you pull it down, you can use the public cert to verify identify of organization, etc. You can also verify that mTLS cert was issued by the CA. That establishes the identify and that they have been identify proofed, etc.
- The trust framework issue is different. If part of it is a third party issuing proof that you are a member of the Trust Framework, then the third party will have to have a signing cert and sign whatever artifact says they are included in the Trust Framework. If self declaration, then you would sign the Trust Framework artifact, and include, and you declare you are conforming to Trust Framework. Both options should work just fine.
- MS: If one option is for payer to self attest to comply with the Trust Framework, thinking that's where we would need standard document; follows self attestation process that clients have been doing for CARIN Alliance.
- BD: Still exploring if we can just adopt the Trust Framework declaration for TEFCA for participation in QHIN. If we can, we just have to declare conformance to that.
- TL: Sounds like a reasonable process. Given that this new proposed rule is for 2026, we are still looking at UDAP. TEFCA will be doing some UDAP testing. UDAP/Security IG has sections for endorsements and certifications. This sounds like what we are talking about. Certifications are by a third party and endorsements are self attested.
- BD: Is this the general impression that the industry wants to look to UDAP for the answer and industry has time to implement it? Suggesting that we may want to come back and test at Connectathon that a UDAP approach may be acceptable to the industry. No intent to delay publication of STU2.
- MS: What we are saying, let's get STU2 published. We may then go into an STU update process. We may have to provide additional functionality in FHIR. We put provider API in as draft but nothing that describes how a provider gets connected and use the API.
- BD: Also need to address the attribution lists. We will have updates based on review of NPRM. And one of the things we can do is spend some time on UDAP and see where it is.
- TL: Is National Directory going to be secured by UDAP?
- BD: Looking at where we have to secure access using UDAP. On attestation side, there could be multiple applications attesting and the idea of a predefined list isn't going to be sufficient. Need a dynamic registration process for it.
- TL: The more we can lean on authorization/authentication frame works throughout the whole ecosystem, the better. There has been testing of UDAP for a while. Some EMR systems, we have been in there as a payer. In Sept during FAST conversation, looking at some way to standup an RI/Directory that can be used at Connectathons.
- BD: FAST will have that available for the May connectathon, which includes an RI to support UDAP/Security. The world has changed by having a three year implementation timeframe.
- TL: I think we should be leaning on that IG. We are readying a reference implementation of UDAP for both client and server; we may open source the client. The server depends on Okta (that's who we use). Joe Shook from Surescripts working on a .net reference implementation.
- BD: Let's be sure we bring those RIs to the May connectathon and start some serious testing to make sure its something we can rely on to support the needs that we have in payer to payer and other needs elsewhere.
- Bob/Mark needs to complete more documentation around mTLS and Trust Framework so we can start the process for publication.
|
|
| Implementer Support | Implementation Questions |
|
|
| Chat |
|
|
|
| Adjournment |
| |
|
