FHIR Chat · Payer-to-payer and Payer-to-provider connections · implementers

Stream: implementers

Topic: Payer-to-payer and Payer-to-provider connections

Josh Lamb (Dec 15 2020 at 15:06):

Hello,

I believe I am missing a key bit of information to fully understand how the payer-to-payer or payer-to-provider connections will function once the CMS/ONC interoperability rules are implemented.

For payer-to-payer, here is my understanding: A patient will contact their current plan to request information from their prior plan. The patient would need to provide their prior plan's coverage information, including member id, to the current plan. This information will be forwarded to the old plan and used to help identify the patient in the old system. Once the information is received by the new plan, the new plan will store this information on behalf of the patient.

Based upon what I said above, it seems that each data holder will need to develop an application, register that application with every other data holder, and then this payer-to-payer/payer-to-provider exchange network could function. Until these connections are built I am not seeing how this will work. Even in a world with automatic registration, the sheer volume of connections is staggering. Am I missing a key component that makes this process a lot easier than it currently seems to me?

The converse approach, which does not require every single data holder to connect with every other single data holder, is to have a patient store all information on their device and share it as needed. I am still learning, but the legwork to build out the network (connections/registrations/endpoint awareness) for all data holders seemed best approached as infrastructure.

Thanks!

Lloyd McKenzie (Dec 15 2020 at 15:16):

@Robert Dieterle

Josh Lamb (Dec 15 2020 at 15:25):

@Ryan Howells , I am not sure if I missed this topic in any of the community meetings.

Michele Mottini (Dec 15 2020 at 15:27):

The payer-to-payer should use PDex (http://hl7.org/fhir/us/davinci-pdex/2019Jun/) that in my understanding is not based on patient mediated authorization, payers have direct business-to-business connections and pass along the identifying info of the member - so there is no app registration, but there still the need to establish a trusted connection between each payer

Josh Lamb (Dec 15 2020 at 15:28):

It is not the case that everyone has a trusted connection or a business-to-business connection with everyone else, especially to support a new use case.

In this case, I would think the suggested approach would be to use SMART on FHIR standalone app launch with the launch/user scope. Permission management on provider side sounds 'fun' too haha.

These thought processes are why I wanted to step back and make such I am not missing some key components.

Cooper Thompson (Dec 15 2020 at 16:23):

@Michele Mottini does PDex support Bulk FHIR (I skimmed it and saw no references)? The new CMS rule specifically references Bulk FHIR, and I don't understand how that will deal with the authorization.

We are proposing the following if a patient enrolls during a specified annual open
enrollment period, or, for a payer that does not have such an enrollment period, during the first
calendar quarter of each year. If such a patient opts-in to having their new payer obtain the
applicable data from their previous payer at this specified time, we are proposing to require that
impacted new payers request such data from the previous payers via the Payer-to-Payer API
using the HL7 FHIR Bulk Data Access (Flat FHIR) specification within one week of the end of
the enrollment period or the first calendar quarter of each year. The previous payer, if an
impacted payer, would be required to respond to this request within one business day of
receiving the request.

Josh Lamb (Dec 15 2020 at 16:34):

@Cooper Thompson , bulk data API is particularly attractive for APIs that expose static, public information. In this case you would not have authorization.

If you want to use authorization, you should be able to use any of the SMART contexts for this.

Michele Mottini (Dec 15 2020 at 16:39):

It is the data for a single patient, so bulk data really does not make sense
(Bulk data itself should use backed services authorization, as explicitly called out in the specs)

Cooper Thompson (Dec 15 2020 at 17:27):

@Josh Lamb Bulk FHIR is very much usable for dynamic, non-public information, however it's use assumes there is a 1) a trust relationship between the client and server and 2) an agreed roster. The reason I'm confused about the Bulk FHIR for sharing member data between payers it that you don't really have either #1 or #2.

Cooper Thompson (Dec 15 2020 at 17:27):

@Michele Mottini The content I quoted is from CMS, not myself. So if you disagree with the CMS proposal, a comment on the regulation may be in order...

Josh Lamb (Dec 15 2020 at 17:53):

@Cooper Thompson , thanks for posting this. This only conflates my original question, as now we are supporting the same number of connections, but using a bulk API as well. The only way I could wrap my head around supporting that number of connections to a FHIR server would be to use an Open Auth method, like SMART.

It sure would be nice to allow a trusted application, that has already done the leg work of building all the connections, to publish information as needed to either payers or providers. This would limit the number of connections drastically. This would also prevent the health insurance companies from becoming a gatekeep for a patient's data. I imagine that people who get care without insurance want to see their full healthcare data picture too.

Cooper Thompson (Dec 15 2020 at 17:58):

Yes - I agree - things are either confusing (if we are misunderstanding), or hard (if we need to do the many-to-many client registration and roster management) with the current CMS proposed rule. The Lego blocks don't seem to fit together to build the thing they want.

Cooper Thompson (Dec 15 2020 at 18:00):

Though they did seek comment on how to operationalize their suggestion...

Michele Mottini (Dec 15 2020 at 18:27):

@Cooper Thompson I don't know how to do that. Bulk data _does not support_ exporting for a single patient - it is either all patients or all patients in a group

Josh Lamb (Dec 15 2020 at 18:29):

I assumed if you have an access token, the _export would be modified to be specific to the scoped patient or to what is allowed by user. This would be an opaque implementation detail. They just know they can export they data, for specific types, that they have access too.

Josh Mandel (Dec 15 2020 at 20:23):

It is not the case that everyone has a trusted connection or a business-to-business connection with everyone else, especially to support a new use case.

This is well put @Josh Lamb, and I agree. The CMS payer-to-payer requirements basically expects a new set of trust and data flows to emerge to meet these requirements, on my reading. I believe this is what PDEX is designed to help with, but as far as I'm aware there's no (or not much?) real-world experience with it, and the "scaling" problem (for trust + data) is still-to-be-addressed. (That said, it's very similar to the scaling problem that Health Information Networks are trying to solve, and maybe it's OK to leave it out of band for a while?)

Josh Mandel (Dec 15 2020 at 20:24):

The Lego blocks don't seem to fit together to build the thing they want.

Agreed @Cooper Thompson ; again, I think CMS has basically tried to lay out functional requirements where there aren't well-tested specs to meet them yet. Sometimes that's a good way to spur development (or maturation/testing), of course.

Josh Lamb (Dec 15 2020 at 20:49):

Is there an opportunity for a private sector collaboration to help meet these use cases? I understand that aggregator applications are not under the control of CMS, but I believe we are all trying to work toward the same thing. It seems to make the most sense. Maybe CMS can define the criteria for how an application would need to function to meet these use cases. The applications, and IGs could emerge later. The intent would be to always keep everything member/patient facilitated. This would mean patient scope in an OAuth context. The complexities around maintaining permissions to support payer or provider use cases is mindboggling. Additionally, I feel that this approach is the most empowering toward the patient/member.

I am not up to speed with the long term goals of the health exchanges, but if we are also working toward a model where we push all data to a cloud, that would also address the same issues.

Josh Mandel (Dec 15 2020 at 21:28):

The intent would be to always keep everything member/patient facilitated. This would mean patient scope in an OAuth context.

I was with you until this line. On my reading, Payer1->Patient data exchange works this way (and SMART provides a well-tested technical framework... with some well-understood warts). But Payer1->Payer2 exchange is called out as a distinct capability with different deadlines, which to me suggests that that just having Payer2 build a SMART app and having the patient mediate the connection to Payer1 wouldn't fit the definition of "Payer1->Payer2 exchange." I'd _love_ to be wrong about this, BTW.

Lloyd McKenzie (Dec 15 2020 at 21:35):

According to CMS, there's no requirement for patient mediation - payers are allowed to connect directly without patient involvement. However, a solution that involves patient intermediation is certainly still possible.

Josh Lamb (Dec 15 2020 at 21:38):

You are correct, and I should have said that user scope would still be adequate for some use cases, it is just hard to enforce for all connections without a universal identity provider (doctor from system x may be authorized but I do not know who that doctor is). I am trying my best to imagine different ways that we could effectively facilitate a payer-to-payer(or payer-to-X) transfer, while only ever interfacing with the patient/member.

I am also approaching this from the perspective that any payer-to-payer connections or payer-to-provider connections would need created, and have permissions defined.

Paul Church (Dec 15 2020 at 22:04):

I thought it was pretty clear that they are envisioning SMART auth + bulk data, direct payer-to-payer transfer that does not go through the patient. The patient gives their new payer some kind of token and a FHIR endpoint for the old payer.

There are no well-tested specs for this but I don't see it as a big problem. There's not really an app involved, it's just a bulk data client.

Josh Lamb (Dec 15 2020 at 22:09):

I am not seeing how using bulk data makes this simpler or more complex from a permission / connections perspective. Can you give an example of what you are thinking?

Paul Church (Dec 15 2020 at 22:14):

The API and scopes involved are extremely narrow - give me everything you have on this patient. There's no ongoing permission for access over time, it's a one-off transfer.

Cooper Thompson (Dec 15 2020 at 22:16):

But is every payer going to have a client ID registration with every other payer? And will the Bulk FHIR calls be single-patient to make use of the token you describe? And how will that token be granted? The rule mentions "opt in", but doesn't say anything about tokens.

Josh Lamb (Dec 15 2020 at 22:20):

@Paul Church With the current 1/1/2021 implementation everything from a payer system for the interoperability rules is member directed. This is nice because we will know who our members are. With these new rules we are getting into the realm of creating trusted connections and identities for third parties. I am basically proposing that for this to work, everyone would at least need to use an identity and authorization method that we can all agree upon. Otherwise this becomes untenable. This ruling must be applied by each impacted payer, which can be burdensome for smaller plan, e.g. a state based Medicaid plan. What we currently have available are aggregator applications, who are putting in some serious legwork to understand the various IG profiles and to connect with all of the data holders. I think we should leverage their work while reducing waste.

Paul Church (Dec 15 2020 at 22:26):

I hadn't really given this much thought, it just seems like a minor modification on what we have already. If they use aggregators instead, do you need to find an aggregator that has a relationship with both your old and new payer?

Josh Lamb (Dec 15 2020 at 22:30):

Yes, I have downloaded a few of the aggregator applications. They seem to be focusing on building out these connections. @Ricky Bloomfield or someone else who knows more can confirm. I have also read the mission statement of the Common Project and CommonHealth. Their intent seems to build this infrastructure as a non-profit.

Josh Mandel (Dec 15 2020 at 22:55):

I wonder if @JP Pollak can comment from the perspective of the Commons Project. This would certainly be news to me!

Josh Mandel (Dec 15 2020 at 22:56):

I agree that there is a massive identity problem to solve if you want to enable business to business flow about a consumer without involving the consumer in the loop.

JP Pollak (Dec 16 2020 at 01:26):

Thanks Josh, and Josh.

The broader mission of The Commons Project is certainly consistent with the person-centric view of this flow, to the extent that the flow is intended to benefit the person as well as the payer. ;)

While the Payer 1 -> Person -> Payer 2 flow is not a use case we’re focused on, I have spoken with several payers who have expressed interest in connecting their Android app to CommonHealth to do just this. And obviously more broadly [Various data sources] -> Person -> Payer.

From our perspective, if a payer app is a good actor and properly discloses data use and purpose to the user, I think we’d be happy to support this in the way that we support any third party app connection. I will note there are some specific potential challenges related to consent to share data in this scenario, particularly if there are incentives involved.

Of course, we have zero production integrations with payers as data sources live today, so that part is academic until we build out those connections. :)

Josh Mandel (Dec 16 2020 at 01:42):

To be clear though here, The Commons Project is not building out Payer->Payer workflows that skip patient-controlled apps (i.e., the approach is to keep things consistent with the SMART patient access story and avoid these deep identity challenges).

JP Pollak (Dec 16 2020 at 01:46):

correct!

Josh Lamb (Dec 16 2020 at 01:49):

Makes sense. Thanks for the input @JP Pollak.

In a future world where CommonHealth has registered with payer fhir implementations, I believe that applications, that we choose to trust, could meet this use case, without any extra work from CommonHealth. In my mind the aggregator app is providing the plumbing that enables the ecosystem to solve issues like this in an adaptive way.

Josh Mandel (Dec 16 2020 at 03:45):

I agree @Josh Lamb (and totally think this is a good way to go) though I'm still struggling to see how this meets CMS intent for "payer to payer" exchange.

Josh Lamb (Dec 16 2020 at 04:01):

A primary intent of payer-to-payer is to allow a patient/member to have a single location to retrieve all of their historical claims/clinical data. This is facilitated through a member directed exchange of data, from payer-to-payer. The end result is that a patient will receive the data from their current payer, and their prior payers, through the patient access api.

The current payer-to-payer use case fails, in addition to the reasons we gave above, because a payer would never receive all clinical data for a patient. Payers will already be exposing the clinical data they maintain for a patient/member through the patient access API. The patient/member should not lose access to any data when retrieving it from multiple sources vs having the data be continuously rolled over between payers. In either event, the transfer must be member initiated.

Based upon my understanding, all payer-to-payer and payer-to-provider exchange of sensitive data is for the benefit of the patient/member. The current use cases could be satisfied as follows (someone let me know if I am missing any):

• 1/1/2022 - Payer to payer exchange of claims/clinical data: An application registers with all payers. A patient would then connect the application to all historical data sources. There is no new information about a member/patient generated as a direct result of the payer-to-payer aspect of this rule so the patient would have access to all information, in one place.
• Proposed - Documentation Requirements for Prior Auths: Could be a public static API and should not present any challenges
• Proposed - Ability to check status of Prior Auths: This would be member directed. If the member / patient wanted to, they could have the application of their choice, that is registered with both payer and provider, intermediate this transfer (or just have patient tell the provider the status).
• Proposed - Ability to communicate roster to providers: This use case could be met if all of the patients relevant to the provider have connected to the provider. The provider would have a one to many connection relationship, with the patients, that is facilitated through member directed exchange through applications (member/patient opt in)
• Seeking Comment - Ability to more easily transfer prior authorizations between payers. (Not an expert, just my hot take) For payers that create B2B relationships and trusted connections would be able to use the PDex IG. Without the B2B relationship, maybe we could also meet this requirement by beefing up the CARIN BB claims API. This could involve defining how to represent prior authorizations in a uniform way, that 'everyone' agrees to honor. The transfer of this information to a payer could be facilitated by the patient/member.

Brendan Keeler (Dec 16 2020 at 06:44):

Patient auth is certainly a possible vehicle.

However, I was assuming the CMS assumed an industry group similar to (or perhaps even the same as) Carequality would provide the trust framework.

There are 22000 nodes on the Carequality network, with a similar structure of exchange, albeit not yet FHIR. It works well enough as a network of networks.

There are around 7000 ISPs in the US. The internet works well as a network of networks.

There are around 1000 payers nationwide...

Josh Lamb (Dec 16 2020 at 07:11):

Each node in the system you describe is calling out to a single aggregator, I assume. It also seems that this network is enabled through uniform use of identities. Eg, a patient/provider can flow through this system because they have a consistent identity.

Communications become more complex when each data source is part of a different network (Josh in your system is not Josh in my system). We also have no existing trust or business relationship to support these new connections. In the current model, the 1000 souces you listed must be aware of the other 999 sources, to enable full interoperability. Especially when dealing with systems that have not yet agreed to use cross system compatible means of identification and authorization.

To your point, if a network like this was already in place, universally, I could see this as an alternative.

Josh Lamb (Dec 16 2020 at 14:05):

@Pat Taylor , @Jason Teeple, @Jason Teeple , @Amol Vyas , @Saul Kravitz are we missing something or is payer-to-payer, in its current state, not implementable? If so, should we consider a new option that facilitate everything via members device (only member directed connections)?

Brendan Keeler (Dec 16 2020 at 15:26):

Both your assumptions are incorrect. The centralized directory maintains endpoints Identity is fully decentralized and maintained at the node level

Brendan Keeler (Dec 16 2020 at 15:28):

The payer to payer situation is just a simpler version of carequality. Few nodes and fewer transitions between nodes.

Brendan Keeler (Dec 16 2020 at 15:30):

@Dave Cassel this thread might be interesting

Josh Lamb (Dec 16 2020 at 15:40):

If I receive care at node 1 will my patientId (or an identifier) be the same as the patientId I receive from node2? If not, how will you match my records from these systems?

Would I have an identity in node1 that is is also understood in node2? What about authorization rules? If not, same question.

Are their trusted connections and/or business agreements between the nodes?

I was trying to guess, poorly, that the Carequality network may be able to support the interactions that it supports because it does not have the same limitations that our current system has.

I also think the intent of the rule is to enable the patient to have a fuller view of their medical data, rather than to beef up B2B communications. The data consumed through payer-to-payer would be for the sole benefit of the patient. It seems like introducing the new payer into the process is adding extra steps with no benefit to the member, since the member is required to provide credentials anyway (name, memberid, etc). This also positions payers as gatekeepers of the data. It seems cleaner if both parties sent the data to the individual they trust, their member.

John Moehrke (Dec 16 2020 at 16:07):

it is both... enable patients to do what they need to do, and enable B2B to do what they need to do. Some patients want and can actively engage. Some patients do NOT want to engage. Both are needed. Both are already enabled in the nationwide exchanges today for Treatment and Patient access. Attaching the Payers is good next step (CMS and VA are already there)

Josh Lamb (Dec 16 2020 at 16:14):

We do build out B2B connections as needed. I am not sure what new value this adds.

Mark Scrimshire (Dec 16 2020 at 16:49):

I am just catching up on this thread so forgive me if I haven't absorbed everything. But let me start with some of the assumptions that have been made around PDex and Payer-to-Payer exchange to see if that helps this discussion.
PDex did not address the endpoint discovery and credentialing of payer access to other payer endpoints.
I believe this is something that could be addressed through some FAST initiatives (if they are FAST enough... :.) sorry - couldn't resist!)
The CAQH Endpoint Discovery initiative seems to be moving oil the right direction. If it is coupled with certificates that utilize UDAP to perform trusted Dynamic registration we have the start of a solution for discovery. The issuing of certificates then becomes largely a policy/Trust issue between payers.
PDex addressed the first step of Payer-to-Payer by defining a member-match operation that would enable payers to utilize patient demographics and coverage information to determine a unique match. This is something payers do everyday, or they wouldn't be able to settle claims. PDex did not try to define HOW payers accomplish the match, just to provide the inputs and specified an output from a unique match.
The result of a unique match should return a Unique member id for the payer (and most likely an access token) that would enable the requesting payer to access the Patient Access API to access USCore/PDex profiles for the specific patient.
This all pre-supposes that: 1) The member at the requesting plan has provided the prior coverage information. 2) The payer has access to an endpoint directory that can identify the FHIR endpoint for the $member-match based on the coverage plan details.
Would the member portal or plan url found on many voergage cards be a good value to search an endpoint directory on?
PDex also did not prevent the use of Bulk FHIR . We see that as something the industry might move towards as Payer-to-payer exchange expands. Could payers support a /Patient/{id}/$everything operation that could gather all information for a patient. Could that optionally be returned as ndjson?
We attempted to define the $member-match transaction so that payer-to-payer could be handled via alternate exchange mechanisms that payers may have in use.
One area I think we do need to consider is how a plan can validate an access request sent via a payer on behalf of a member. There are some edge cases that could be problematical. For example. How does a plan enable a parent to request Data on behalf of a minor. And how do the plans determine that the requesting parent is authorized to have access to the Childs data. This can be an issue in the case of divorced parents.
When I think about Payer-to-Payer exchange the problem comprises three parts. 1) the Interaction - this is what we attempted to address with PDex using $Member-Match (which is now in the HRex IG since it is planned to be used across multiple IGs). 2) Discovery - How do I find the right endpoint to be able to perform the required interaction. and 3) Policy/Contract - How will plans enable access to a trusted plan once the endpoint is identified.
$member-match is not trying to define the follow -on exchange of data. It simply determines if a payer is able to find a unique match for a member and if so how to reference the member in their system. Individual IGs will then handle the data queries based upon the use cases they are supporting. This was successfully proven when PCDE and PDex both used $member-match to support different data exchange use cases.

Josh Lamb (Dec 16 2020 at 16:58):

@Mark Scrimshire , well said. I appreciate your clarifications. It seems that these pieces were purposely omitted from PDex and these industry wide problems have not yet been solved.

Mark Scrimshire (Dec 16 2020 at 17:06):

@Josh Lamb I'm glad it helped. We are going to publication with an STU1 of PDex. It is important that the IG gets published. Then I think in Q1/Q2 of 2021 we need to focus in on refining Payer-to-Payer in PDex for an STU2 publication for the middle of the year. That would imply we move quickly in Q1 - immediately after the Connectathon in January to develop PDex requirements to be able to ballot at the end of the quarter. Does that make sense?

Josh Lamb (Dec 16 2020 at 17:15):

Yes, this makes sense. It seems that regardless of what happens, the PDex IG will be critical for supporting B2B use cases. My points are specific to the patient directed aspects of the ruling that require payers to create new connections. A payer could, for example, produce USCDI compliant resources using the PDex IG. But as you said, not all details of these interactions are covered in PDex, allowing it to remain flexible.

In the absence of a trusted connection and a B2B relationship, the only entity we can really trust is the member/patient (using an application they trust), with our current infrastructure.

Pat Taylor (Dec 16 2020 at 18:39):

@Josh Lamb @Jason Teeple @Amol Vyas adding @Mark Scrimshire @Robert Dieterle

Jason Teeple (Dec 16 2020 at 20:06):

We need to have an implementers call specific to Payer to Payer. @Robert Dieterle and @Mark Scrimshire does it make sense to dedicate a PDEX call to discussing this topic? As payers start to transition to 2022 work, think we will see more questions. Better to get a discussion and flow going sooner than later.

Mark Scrimshire (Dec 17 2020 at 02:26):

I think we need to go with a model where the requesting payer gains a consent from the member. The advantage of having the requesting payer request consent from the member is that the solution works for members that left a payer a while ago - because payers may have archived their digital credentials. The other challenge is where the source payer does not have a member portal and therefore may not have a method for members to authenticate and authorize sharing.

Mark Scrimshire (Dec 17 2020 at 02:35):

@Jason Teeple I think we should get through the Connectathon in January and then focus on Payer-to-Payer

Josh Lamb (Dec 17 2020 at 05:38):

@Mark Scrimshire , I am not familiar with everything that is supported through the DaVinci payer-to-payer and payer-to-provider use cases. A consent model may be great for some of these use cases, or even to help support the 'opt-in' aspect for the patient registry portion of the proposed rule.

I understand that we are currently trying to support many use cases with interoperability initiatives and not every use case is mandatory. The points here are specific to the CMS requirements for payer-to-payer and payer-to-provider (1/1/2022 rule and the prior-authorization proposed rule). I mention this in case anyone may conflate the various payer-to-payer use cases.

To @Jason Teeple's point, maybe we should discuss, as a community of implementers, before the comment period ends. I believe we have found an opportunity to address technical issues with the prior 1/1/2022 payer-to-payer data exchange, and an opportunity to propose a new solution that will benefit all parties, especially the patient/member.

We currently do not have a system in place to enable trusted connections between all data holders in healthcare. The only entity that everyone in healthcare can currently communicate with, in a secure way, is the patient/member. I also find the ecosystem that was developed by the aggregator applications valuable, as it can enable many different forms of communication, all directed by the patient. It does not seem that we considered using aggregator applications, and the infrastructure they are developing before.

I posted earlier how the 1/1/2022 use cases and the proposed use cases may be met without creating any new connections. I believe we are creating undue burden on the payers with this rule, since the supporting infrastructure is not in place, and I also believe we can deliver a better solution, that is more consistent with how the healthcare data ecosystem functions.

David Pyke (Dec 17 2020 at 17:24):

@Mark Scrimshire The FHIR Consent resources exists for this purpose. IF you'd like, we can have a discussion about what issues you see that could be better handled by Consent.

Josh Lamb (Dec 17 2020 at 20:49):

Are we suggesting that including a FHIR endpoint to accept consent resources will help solve the identity and trust issues?

An approach involving automatic registration without the ability to apply universal identity/authorization rules will cause security risks. Since the applications that are interfacing with our FHIR APIs are not protected by business to business agreements and we do not have a way to determine what PHI the actor is authorized to access we have scenarios where someone can request another person's PHI.

This is based upon the assumption that a user/patient scoped SMART token will need to be included with B2B requests. In either event, the user/patient will not be a recognized entity in all systems (since we are missing a universal identity provider and authorization rules). For those that wanted to create a formal B2B relationship, they can develop a trust framework and authorization policy that is understood by both systems.

Am I off the mark here?

Vassil Peytchev (Dec 17 2020 at 20:55):

Take a look at udap.org - as far as I can tell, this is being proposed as a solution by the FAST initiative, and it might be coming to Da Vinci as a project.

Josh Lamb (Dec 17 2020 at 20:58):

Thanks for calling out UDAP, when I mention automatic registration (trusted connections) this is what I was referencing.

UDAP solves the issues of trusted applications (good actors) and endpoint discovery (trusted endpoints). It does not solve the issues of cross system identity and authorization. Once these issues are addressed we can begin to accept virtual consent in a trusted way from any system in healthcare.

Someone chime in if UDAP has solved identity / authorization for healthcare.

Vassil Peytchev (Dec 17 2020 at 21:11):

You are correct, UDAP is about automating trusted connections. The Identity proposals of FAST are here: https://oncprojectracking.healthit.gov/wiki/display/TechLabSC/Identity+Proposed+Solutions

Josh Lamb (Dec 17 2020 at 21:12):

Using a patient-centric view, and considering the intent of the CMS rules, I cannot understand the push for everyone to adopt all of these complex, and seemingly dangerous, new processes so quickly.

Vassil Peytchev (Dec 17 2020 at 21:14):

That is a valid perspective to convey regarding the proposed regulations...

Josh Mandel (Dec 17 2020 at 21:20):

(For what it's worth @Josh Lamb I provided very similar feedback as an "invited expert" to the ONC's FAST task force. I did not get the impression folks were really open to this feedback.)

Michele Mottini (Dec 17 2020 at 21:37):

It does not seem that we considered using aggregator applications, and the infrastructure they are developing before.

Patient app are completely unregulated, CMS cannot really create regulations that rely on them (even if technically it would make much more sense than the current 'and then everyone will connect with everyone else' approach)

Josh Lamb (Dec 17 2020 at 21:45):

With the current patient access API, none of this will function without applications, like careevolution. These applications are outside of the control of CMS and outside of the control of B2B relationships. Since they are patient centric this ecosystem is able to function. Once you being transferring data about a patient, without directly including the patient, you run into the issues I am trying to describe.

Michele Mottini (Dec 17 2020 at 21:54):

I completely agree with you about the issues of what's being proposed: not gonna work.

I was trying to explain why I think CMS cannot go down the route of 'and to share data between payers or providers go via a patient app'

Josh Mandel (Dec 17 2020 at 22:04):

I think I agree with your perspective overall @Michele Mottini . I would quibble slightly with:

Patient app are completely unregulated, CMS cannot really create regulations that rely on them

1) In general, patient apps are regulated by FTC rules at least, and 2) patient apps offered by a payer for the purpose of data collection, for instance, can be covered by HIPAA. So I think CMS could coherently define a framework on this basis.

Brendan Keeler (Dec 18 2020 at 01:04):

Going to be a broken record and say that a large scale B2B exchange with a single trust agreement and decentralized identity is 100% a solved problem. Carequality is doing this to the tune of billions of exchanges between tens of thousands of provider organizations, with a planned change from legacy standards to UDAP and FHIR based exchange starting to roll out

Patients are unreliable actors in exchange in that they have varying technical capability, access, and expertise. Having a solid B2B network is complementary to a solid patient authenticated exchange.

Patient auth is one very valid approach but saying B2B isn't possible is simply ignoring the examples already present healthcare technology.

Josh Lamb (Dec 18 2020 at 01:27):

What is the solution that will work for everyone? I asked a few questions about Carequality earlier that may help make sense of the solution you are proposing.

From an implementation perspective I have pointed out several things that are not in place to support full system to system communications in healthcare. I believe you are saying that implementing universal solution to identity and authorization is already solved by Carequality? This approach should be adopted by everyone too?

I would also hesitate to call the patient an unreliable actor. The technology should do the heavy lifting, at the patients discretion. Simply downloading an application and agreeing to the terms of use should enable a lot to occur. As the ecosystem develops it will become more natural to use applications to assist in healthcare.

Who exactly are these B2B use cases that are emerging going to benefit? The stated goal is to give the patient access to their full medical history.

To answer my own questions, Carequality is enabled by the following (from their site):
Common rules of the road:
In order for the varied participants to trust each other with health information, everyone needs to have a legal obligation to abide by the same rules.

Well-defined technical specifications:
Shared rules are not enough; clear standards must be laid out in an implementation guide that all implementers can follow.

A participant directory:
To connect using the common standards, systems must know the addresses and roles of each participant.

It sounds like Carequality was able to address the Business to Business / Trusted Connection aspects by having everyone adhere to a contractual agreement.

Regarding identity / authorization: Since Carequality is enforcing standards (identifiers or ways to consistently resolve to an identifier) and using a directory containing roles (ability for all participants to authorize) this type of a setup can function. These three components are not in place for the entire ecosystem.

David Pyke (Dec 18 2020 at 14:50):

Carequality is only mandating the use of pre-created patient credentials that have been created by the data holder (portal creds). For professionals, they need IAL2 proofing to access through the CQ network.

David Pyke (Dec 18 2020 at 14:51):

For complete details, @Luis Maas is the person most knowledgeable.

Josh Lamb (Dec 18 2020 at 18:00):

Thanks for outlining the specific implementation steps that the patient / providers would take.

It is my understanding that requiring a pre-created set of patient credentials would be illegal. We have not even been able to enforce the universal use of identifiers (or how to resolve them). Attempts for universal identifiers always seem to get locked up: https://healthitsecurity.com/news/senate-bill-maintains-funding-ban-on-unique-patient-identifier.

I understand that we can employ healthcare IT vendors to help solve these issues, but any approach that is taken should be developed through a community based consensus building process. It is becoming clear that not everyone was fully aware of the true implications of opening up payer-to-payer/payer-to-provider communications. We all seem to agree that we can meet the technical challenges of the payer-to-payer using a patient centric model. I also have ethical concerns about removing the patient from the center of data transfers and creating a reliance on health insurance companies to deliver important medical data.

Would impacted members of the community consider leaving a comment on the proposed rule? The comment can ask that we create a better way to meet the payer-to-payer use cases. We can ask that the 1/1/2022 requirements be met through the patient access API and an aggregator application. This enables communications to remain member directed and also allows all parties to talk to the individual they trust, their member. I believe we can also meet the proposed rule use cases with minimal effort by directing all communications to our members, rather than through a peer to peer network.

David Pyke (Dec 18 2020 at 18:22):

I wasn't talking about universal credentials. They network will use the credentials for a provider that were provided by that provider. While a universal patient ID would make life easier, there isn't any drive to create one due to the perceived privacy problems in the general population.

Josh Lamb (Dec 18 2020 at 19:11):

I have worked through a mental exercise of creating an application that has trusted connections with every other source. The two issues are with identity and authorization. My thought exercise is below, I hope this can be helpful.

Regarding identity: when systems are talking with each other the primary means of sending the identity of the application user is by using OAuth. Since the current healthcare system will have a unique identity within each system, additional effort is required to match the identities between systems. This is similar to how I have a Gmail identity and a Yahoo identity. Both of these identities are describing the same person, but from a systems perspective I have multiple identities. In the absence of an identity token a similar effect could be achieved by communicating patient demographics and identifiers through a trusted connection (UDAP). Assuming that the system receiving a PHI request can trust the identity information of the system requesting PHI, the system fulfilling the data request may perform a patient match operation to help workaround the lack of a universal identity. This allows both systems to associate an identity in their system with the request, if the match is successful.

Regarding authorization: now that we have partially solved identity, we can begin to think about authorizing access to PHI for the identity. In payer-to-X, the system requesting PHI from another system will not have a way to validate the access rights to the information being requested. This would require both systems to have a common understanding of application user's role/access rights. Since the party that is requesting PHI will have no way of knowing what is allowed, they will need to rely upon the system that is providing data to validate access rights to the PHI. The entity providing PHI will also need to trust that the application user is making an honest request. The system attempting to validate access to their PHI must be able to associate the received identity information with a role in their system via a lookup operation. Once an identity and the associated permissions/restrictions is determined, the data sender will be able to apply authorization rules.

When you get into scenarios that allow a provider/clinician/administrator to access data, it becomes much more complex. The identity matching operation must also take into account NPI, TIN/LOCATION, specialty, position on care team, and etc. Just because a provider has access to a patient at one location does not mean they have access to that patients data from all sources. This needs to be patient directed.

The example I gave above is my best attempt at making a payer-to-X exchange of data function, with current capabilities. I even assumed that we managed to get UDAP implemented across the board and it still seems like an impossible task. I hope this can make it clear why peer to peer connections in healthcare would be impossible without first developing consensus, and universally implementing solutions around identity and authorization. And as I said before, I struggle to see how this peer to peer infrastructure is better than a member/patient centric approach.

If we can meet all of the use cases, improve security, empower the patient, help the ecosystem, and eliminate waste it seems we should pursue this. I understand B2B connections are useful, but I cannot understand the need to make these connections mandatory to support patient directed use cases.

Josh Lamb (Dec 19 2020 at 22:13):

Here is an outline of the points I am considering for a formal comment. I am looking for community feedback (let me know if I should move this):

The 1/1/2022 payer-to-payer and the prior auth proposed rules cannot be implemented securely by payers until a few key pieces of infrastructure are in place. There are at least three healthcare infrastructure challenges and some procedure issues that preclude the creation of a healthcare peer-to-peer network. Currently the payer community can only securely communicate healthcare data through business-to-business connections and directly to our members/patients.

The payer implementer community does not posses a uniform understanding of the specific implementation details for payer-to-payer and payer-to-provider connections and transfer of data. Technical issues were overlooked or understated. We are rushing to implement industry wide changes with no clear benefit to our patients/members, the primary individual this rule is intended to benefit. Furthermore, I believe the community has made a mistake by removing the member/patient from the center of healthcare data transfers. The data transferred for the interoperability use cases is for the benefit of the member/patient. We are introducing unnecessary complexity, introducing security vulnerabilities, increasing implementation costs, and delivering an inferior product to our patients/members.

The technical issues are as follows:

1.) There is a better solution
The solutions proposed for payer-to-payer and payer-to-provider are needlessly complex. We did not seem to consider using the application development ecosystem to help solve some of the industry-wide problems impacting the member directed exchange of healthcare data between healthcare data holders. Using an application, like Apple Health or Common Health, will enable you to have access to all your healthcare information in a single location.

A patient centric approach is vastly more secure than the proposals made to facilitate payer-to-payer exchanges of data. I have not yet heard discussions about how we plan to support payer-to-provider, but I am confident it will be even more challenging than setting up a payer-to-payer, member facilitated, exchange network.

The payer-to-payer use cases for 1/1/2022 can be met with minimal effort by the application developer community and the payers and with no additional effort from the member/patient. The primary objective of the 1/1/2022 payer-to-payer use case is to allow a patient/member to have a single place to access all of their healthcare data. This use case is met by connecting an aggregator application to all data sources. Introducing payers into the mix, to aggregate payer data, does not simplify the process for patients/members.

The current suggested approach, where members get their historical data via a payer-to-payer and payer-to-provider exchange network, necessitates the following:
• creation of complex trust and endpoint discovery frameworks
• industry wide-consensus on how to identify and validate access to healthcare data
• the creation of FHIR applications by every healthcare data holder (this is in addition to the FHIR servers we will all be exposing)
• Limiting the patient’s/member's ability to choose, at a granular level, what information to share between payers/providers
• Receiving data in non-FHIR formats from prior payers, which will prevent true interoperability
• Building out infrastructure that is only accessible through an insurance provider

We can meet the payer-to-payer use cases without creating any new payer-to-payer or payer-to-provider connections. The advantage of this approach is that it allows all healthcare data holders to use existing connections to communicate with the only entity in healthcare that everyone has already agreed to trust, our patients/members. This approach also places the patient/member at the center of all healthcare data transactions, both in a literal and figurative sense. Additionally, this approach is widely supported by industry leaders like Apple Health and Common Health, both of which seem well situated to add support for Payer-to-Patient and Patient-to-Payer/Provider flows. This approach is also superior because it allows application developers to focus on writing code, instead of building out and maintaining thousands of connections.

2.) Endpoint Discovery and Trusted Connections
Payer-to-payer and payer-to-provider will require peer-to-peer trusted communications. Each payer will need to be aware of all other trusted endpoint’s and be able to associate a member request with one of these trusted endpoints. This obstacle is being addressed through efforts such as UDAP (Unified Data Access Profiles).

A trust framework, like UDAP, will solve the issues of endpoint discovery and trusted connections, but this approach has not been universally agreed upon in healthcare. Once consensus is formed, a considerable nationwide lift will be required to implement UDAP for all impacted healthcare data sources. Manual processes and case-by-case application vetting can be used instead of an automated process like UDAP. The number of connections and maintenance costs associated with a manual approach will be untenable however.

Peer-to-peer connections also necessitate that each payer/provider creates an application and registers that application with every other impacted healthcare data holder. The payer will also have every other data holder registering an application with the payer. This web of connections assumes a lot of trust and, if poorly implemented, seems to introduce significant security risks. These risks would be in addition to the risks outlined below.

3.) Consistent Identifiers Across Systems
The identifiers we use to track entities in healthcare data are not consistent across systems. For example, the patient identifier I am given at one health system will not be the same as the one I am given at another health system. This is because each system defines their own identifiers. The industry has not yet agreed upon a consistent approach. This will probably not be addressed soon. It is currently illegal to require the use of a universal patient identifier in all systems.

In payer-to-payer, the leading proposal to solve the identifier issue is to have a plan’s current enrollee provide their prior plans member Id. This member Id, when combined with the member’s demographic data, should enable the prior plan to locate an identifier in their system that will correspond with the person who is requesting data. This proposal may work in most cases, but it has not yet been universally agreed upon as a solution, and this solution is specific to a single use case. We would need to develop another solution to define a cross-system compatible way of identifying a healthcare provider. This will be more complex because a single provider may have multiple identities, each with different access rights.

4.) Ability to Authorize Access
For a system to protect sensitive data the system will need to know who is requesting the information. This will allow the system to determine if the application user making the request has access to the requested data. In system-to-system communications, like we see in payer-to-payer and payer-to-provider, all connected systems will need to know what access rights an actor in one system may have in another system. Authorization also presupposes the existence of trusted connections, endpoint awareness for all data holders and applications, and an agreed upon understanding of how to identify the requestor. I am not aware of any efforts to enable cross-system data access awareness.

In the absence of a consistent way to validate access rights in a cross-system compatible way security vulnerabilities could be created. The burden of authorization will be placed on the payer who is providing the data. The system requesting data could fabricate identity information and effectively have access to any PHI in the sending system, if they can provide enough identity information to enable a demographics match. A malicious application user could also easily request data that they do not have access to by manipulating the request data. Given the hundreds of data sources we are adding it seems likely that at least one of the sources will introduce a vulnerability.

As stated before, business-to-business communications, in this current model, require significant trust. This is because we are creating a system where one actor can declare that they possess an identity in another system, and the other system is required to trust this assertion. A malicious application or end user could easily take advantage of this by providing identity and demographic information that will allow them access to the information they are trying to steal. Since applications can register directly with data holders and the use of a trust framework is not required, it seems that a malicious actor could create an application and manually register that application with a healthcare data holder. We are currently prohibited from blocking an application from accessing our API unless we can demonstrate a security risk to our system. This gap seems the most dangerous.

A patient centric model is more secure because the system that is providing sensitive data is also the system that is issuing the identity and validating access rights. This process will eliminate the trust issues associated with a third-party created identity. The data holder will also be able to utilize existing identity management security processes, e.g. multi-factor authentication.

Paul Church (Dec 19 2020 at 22:32):

@Josh Lamb did this post get cut off at the end?

Josh Lamb (Dec 19 2020 at 22:36):

Yes, thanks Paul, I hit the character limit apparently haha.

Here is what was cut off:

Suggestions to Meet Use Cases

We can meet the specific components of the 1/1/2022 payer-to-payer and the Prior Authorization proposed rule, without requiring the creation of full healthcare peer-to-peer connections:

• 1/1/2022 - Payer to payer exchange of claims/clinical data: This use case can be met through the existence of aggregator applications. These applications have been building the connections that will enable a single application to connect to multiple sources. A patient/member would meet this use case by connecting the application of their choice to all historical data sources. There is no new information about a member/patient generated as a direct result of the payer-to-payer aspect of this rule so the patient would have access to all information, in one place. This approach is also superior because it will result in a more complete medical history. A member who relied on payer-to-payer data exchange to pull clinical data would only have a small fraction of the available clinical data. The data a member can access from provider sources will be more complete than the subset of clinical data that a payer may maintain for the patient/member.

• Proposed - Documentation Requirements for Prior Auths: This does not seem like it will be protected/confidential information. If so, it can be exposed through a public api, which will remove the trust and authorization issues present in current payer-to-payer designs.

• Proposed - Ability to check status of Prior Auths: A member would use an application of their choice to directly search the prior authorization status. The status could then be sent directly to the provider or communicated to the provider by the patient. This will require the creation of a new FHIR implementation guide, and this can be included as part of the patient access API.

• Proposed - Ability to communicate roster to providers: This use case could be met if all the patients relevant to the provider have connected to the provider. The provider would have a one to many connection relationship that is enabled by the patients that have connected with the provider. Patients that choose to connect to the provider will be able to send data to the provider, essentially building a roster that patients had to opt into (member/patient opt in)

• Seeking Comment - Ability to more easily transfer prior authorizations between payers: (Not an expert, just my hot take) Maybe we could also meet this requirement by beefing up the CARIN Blue Button Claims API to include a prior authorization indicator, e.g. a prior authorization number that is tied to a specific procedure code. It seems that this would just require industry consensus and inclusion into an implementation guide. The exchange of this data would be member facilitated, by using an application that is connected to both the old and new payer.

Here is an image to summarize how the current payer-to-payer and payer-to-provider use cases could be met without creating a peer-to-peer network:
image.png

Here is another image that summarizes how payer-to-payer and payer-to-provider exchange networks will increase complexity, with no clear benefit to the patient/member:
image.png

Michele Mottini (Dec 20 2020 at 03:38):

Yes, totally good points. I'd suggest to split the objections to what is in the current regulation from the proposed solution of using patient access

Michele Mottini (Dec 20 2020 at 03:39):

Thanks

Josh Lamb (Dec 22 2020 at 16:30):

Potential-Technical-Arguments-for-CMS-Comment.pdf

Feel free to circulate this. I am still looking for community feedback. Technical feedback is needed as well.

Michele Mottini (Dec 22 2020 at 19:46):

@Ryan Howells ^ this is something Carin could be interested in

Josh Lamb (Dec 22 2020 at 19:47):

Thanks @Michele Mottini , I have reached out and they are reviewing.

Ryan Howells (Dec 22 2020 at 20:29):

Hi @Josh Lamb and @Michele Mottini: Josh L. did send over the proposal and I read through it today. Many of his thoughts are similar to ideas we've had in CARIN. In fact, informally I have heard a number of good ideas from the CARIN community about how we might be able to tackle payer-to-payer using a member-centric approach. But, we've been hesitant though to wade into these waters because @Mark Scrimshire @Viet Nguyen @Jocelyn Keegan @Robert Dieterle and the DaVinci team have been focused on payer-to-payer and we've been busy with the CARIN IG for BB. We (CARIN) would welcome the opportunity to discuss the different options DaVinci has considered along with your proposed approach with the DaVinci team (along with others in the HL7 community who are on this thread) as a combined group early next year. Ultimately though, I would defer to @Mark Scrimshire and their team as to when or if they'd like to have that discussion as a combined group given their continued leadership on this topic. Happy to chat further live.

Michele Mottini (Dec 22 2020 at 20:35):

Thanks Ryan

Josh Lamb (Dec 22 2020 at 20:41):

Hi @Ryan Howells , the comment period ends on the 4th. It would be good to incorporate their perspectives and feedback.

Josh Lamb (Dec 22 2020 at 22:21):

Based upon what I am seeing, even if all of the required steps to setup a payer-to-payer and payer-to-provider exchange network were successful there would still be several gaps in security. Rather than trying to add more solutions into the mix, it may be better to step back and question if the model we are working toward is sustainable. Outside of policy development and IG creation it does not seem the actual community has begun payer-to-X development work yet.

I would also want to know the exact reasons why we are removing the patient from these transactions. I have heard a few reasons so far, but they do not seem to hold water. From an implementer perspective, if there is even a chance that we can achieve a more secure outcome, at a lower cost, all while delivering a better product, I think it would be unwise to ignore it as an option. As I said before, gathering feedback is critical since we have a limited time before the comment period ends. The implementation costs of payer-to-payer seem extravagant (based upon my understanding). In the spirit of interoperability, consensus building, and public sharing of information I think some information to support or invalidate my analysis would benefit everyone. I welcome anyone to jump in to correct my understanding! I just want to know what we are all getting into. I hope we can address issues as a community, since the I in FHIR stands for interoperability after all...

Josh Lamb (Dec 23 2020 at 14:36):

Here is a Google doc version. Anyone interested in leaving feedback can put a comment on this document. I would love to hear from the payer community, provider community, and app community, as it seems we are all affected. https://docs.google.com/document/d/1yU-4ur5TBxU1RQXwCJi19xNk6LAahTVOTM2Ap4068PU/edit?usp=sharing

Josh Lamb (Dec 24 2020 at 02:45):

Happy holidays @Ryan Howells, we should consider the consensus process and be sure that we keep checks and balances in place. Different sectors are collaborating. Even if everyone is acting on their best intentions, we do not want to have the perception of a conflict of interest. So for this reason, we should have others, in addition to those who are vested in payer-to-payer, leave feedback. Sorry, I know this is a difficult topic (and sorry for being a pain in the bum!).

Josh Lamb (Dec 24 2020 at 21:27):

Another comment I want to leave is specific to how patient-centric vs peer-to-peer will impact the development ecosystem. The end result of all of this is to get the most complete medical picture and to share that information in a way that best serves the patient's needs. The code that is written on top of a complete patient concept is extremely valuable. The more complete we can get this single picture the more valuable it will become. The economy of scale for developing against the patient is two-fold. By combining all data sources at the patient you will get the most complete picture. Additionally, when all data sources converge on the patient then application developers will have a much larger user base to develop against that is using a common dataset (Cigna Users + Epic Users + etc).

I cannot make cool apps if they can only interface with a single EHR or Payer, and each data source has a different data set. Instead I want to write code against a patient, and their connections. That way we will always be building upon this same concept and we will begin to eliminate the throwaway work that is currently occurring on top of partial data sources. When I was at a prior position, working to run measure calculations for ~1000 health systems, we always wanted a complete medical chart. The issue was that even if we combined all of the data, no single health system, NPI, TIN, etc. could access the complete record. This information would need to be authorized and released by the patient. Since we did not have a relationship with the patient the idea couldn't go anywhere.

Josh Lamb (Dec 30 2020 at 16:52):

Hi @Brendan Keeler and @David Pyke , thanks again for pointing out other health data exchange networks, like Carequality. This research was interesting!

It does not seem that payers are included in Carequality's network. There is an example of a CMS bluebutton member facilitated payer to payer exchange, which seems like a closer fit to the payer to payer descriptions given by CMS.

The primary difference with a national healthcare peer to peer healthcare system, with only one payer (CMS), and the proposed system is that the number of connections multiply which requires the trust frameworks, endpoint discovery mechanisms, identity proofing, and role awareness initiatives we see in current designs. CMS bluebutton is is able to avoid all of these issues by having a universal identifier and by just being CMS. When you are as large as CMS you are essentially an aggregator (when viewed in context of current ecosystem). Some large payers may be able to combine their networks (BCBSA could do this I imagine) into something fierce. But that is terrifying and counterproductive for everyone.

Brendan Keeler (Dec 30 2020 at 17:38):

(deleted)

Brendan Keeler (Dec 30 2020 at 17:39):

Hey Josh, payers are certainly allowed on Carequality's framework. Given that historically it has been aimed at Treatment purpose of use, there has not been adoption for Payment or other purposes of use, but the existing directory and trust framework is easily scalable. I don't see any barriers to payer-to-payer exchange.

Brendan Keeler (Dec 30 2020 at 17:41):

Carequality has a single endpoint directory, a single trust framework, and entirely decentralized identity management.

Brendan Keeler (Dec 30 2020 at 17:42):

If the goal of the regulation is to create a B2B network of payers, Carequality is a great model for how to do this. If the goal is to give the member/consumer access and the ability to direct (B2C2B), then your proposal seems correct.

Brendan Keeler (Dec 30 2020 at 17:42):

The problems of connections multiplying, decentralized identity, etc are already solved problems, at a larger scale than any payer to payer network would be.

Brendan Keeler (Dec 30 2020 at 17:43):

Happy to have a conversation sometime to discuss in more detail

John Moehrke (Dec 30 2020 at 18:38):

There has been payer use on these networks from the start. SSA uses it for workforce claims.... so getting the other payers onto this network would be getting them up to speed with our slow government.
careQuality, CommonWell, and eHealthExchange are ALL ready for payers and patients. They are specified to allow these specific types of PurposeOfUse. What is missing is the will of 'some' the custodian participants on these networks to respond when a partner indicates they are using the payer or patient purposeOfUse. So it is policy, not technology or a specification problem.

Josh Lamb (Dec 30 2020 at 18:41):

@John Moehrke and @Brendan Keeler I do not see the documentation describing payer to payer exchanges with Carequality (outside of what I listed earlier: trusted apps, users, connections, and role awareness, from their own site). Can someone share a link please? I would be interested in the relationship between payer nodes (and application end users) and their role awareness, and how member identifiers are trusted between payer nodes.

The current proposal is only addressing new information exchanges, that will require an opt-in from a patient/member and I agree this seem to be a better fit for B2C2B (Ill use this now haha).

They are also establishing groundwork (unofficially) for a B2B network, which the community comment is also arguing can be met using facilitator (patient/member/provider) established connections (when opt-in is required) or through existing B2B connections. An application sitting outside of data sources, with a strong identity concept to unify things, is very powerful.

Josh Lamb (Jan 11 2021 at 00:18):

I have a simple way to summarize the requested change. Let me know if this makes sense.

Provider Access API is redefined to mean a Provider Hosted API that can accept data about a patient. In technical terms, this would be the PUT endpoint of their existing Patient Access API. The PUT endpoints would function based upon FHIR IGs (need created), and the application used would directly mediate the transfer of data between data holders. The application can be a business application to allow the HIPAA protections to continue.

Payer Access API will have a similar definition, but it is hosted by payers.

Patient Access API is redefined to indicate all outbound communications about a patient. In technical terms, we can authorize this access in many ways, but the universal solution that already exists is the launch/patient SMART flow, with patient scope.

Member facilitated use cases can be met using the patient-centric connection and payer/provider trusted applications. The application will directly mediate transfer, and the actual movement of data will occur within an application created by a Payer or Provider. This seems to address the HIPAA issues that were omitted in the officially submitted comment.

In effect, this gives us everything in the current policy, as currently stated, with some minor technical clarifications to language (which products numerous positive results and saves the healthcare system a ton of $$ and throw-away work).

Is it too late to provide clarification? It seems the process will take time, and research is part of the policy maker's due diligence.

Last updated: Apr 12 2022 at 19:14 UTC