Stream: social
Topic: CMS-9123-P Comment - Community Feedback Requested
Josh Lamb (Dec 23 2020 at 14:40):
Hello, I am finding that a member-centric model may be advantageous for several reasons when compared to a member facilitated peer-to-peer healthcare data exchange network. I am attempting to gather community feedback to help improve the comment. It seems that there is an opportunity to reduce waste and to empower the patient. I am also open to someone finding errors with my logic or any assumptions I have made.
Feel free to provide feedback, good or bad, here:
https://docs.google.com/document/d/1yU-4ur5TBxU1RQXwCJi19xNk6LAahTVOTM2Ap4068PU/edit?usp=sharing
@Dave deBronkart FYI if interested in this from a patient empowerment perspective. I could use assistance making this material less dense.
John Moehrke (Dec 23 2020 at 14:45):
my overall is ... this is not a competition, both are needed. patient must be given ability to be empowered, while other patients choose to enable the infrastructure to do it for them. Some patients want to have their hands deep in the details, others expect the system works and don't want to touch. People are complex, healthcare is complex, ... both are needed.
Josh Lamb (Dec 23 2020 at 15:02):
Hey, thanks @John Moehrke . I agree that we do need to support business to business connections and often times we need data from another source to help out the patient/member. I take no issue with this.
My points are very technical but basically, if you are exchanging data on behalf of the member, you run into all sorts of issues if you try and cut the patient out of the transfer. This is because of deep identity and trust issues that are present in cross-system communications in healthcare. These issues can be addressed, mostly, but for a member/patient facilitated use case it just does not make sense to try and cut the patient out of the transaction.
John Moehrke (Dec 23 2020 at 15:07):
you use a blunt word "cut the patient out". I was much more careful to include the patient as part of the authorization "patient choose to enable the infrastructure". There are a set of Privacy Principles that I hold everyone to. Not just consent, but transparency, correction, etc. I insist on Privacy Principles, I just don't think that the patient must be the carrier of the data.
see https://healthcaresecprivacy.blogspot.com/2019/10/nationwide-health-information-exchange.html
Josh Lamb (Dec 23 2020 at 15:12):
Sorry, I mean they are cut out of the transaction in the sense that the system releasing their data never had that user input credentials or authorize against their identity management system. They were also not included in the data transfer between parties. They did initiate the request though, correct.
The patient does not need to be the carrier of the data. It just helps address the identity and trust issues I am seeing. I have detailed how you can get another person's PHI from another system using the current proposal. Using current infrastructure, we would have to invest heavily in every impacted healthcare data source to be able to support this and it seems we would still be left with security issues and an inferior dataset. I think CMS estimated the cost to each plan at 1-2 million. There are about 300 plans, plus I have not heard anyone mention the cost to providers. If we can allow the application development ecosystem fill these roles I think we all win. App developers can take advantage of an economy of scale that a single data source could never reach.
John Moehrke (Dec 23 2020 at 15:58):
That works for the subset of patients that WANT to do the work... these are an important population... but there is another subset of the patients that do NOT want to do this work. How big these subsets are, I don't care... they both exist is what I care about.
John Moehrke (Dec 23 2020 at 16:11):
Identity credentials is not a silver bullet. It works in banking, because a failure to authenticate simply means that money flows later than now. No harm is done... Where as in healthcare a failure to authenticate is quite common, due to the fact that patients need healthcare when they are NOT healthy. A failure here is much more harmful, delays cause pain (prevent pain from being addressed as soon as possible), and can cause far worse than pain including long-term damage or death.
I am all for a national Identifier.. I have been pushing for it for decades. It would be very helpful for safety. I believe it is critical to ENABLE Privacy, and it makes me angry that the public statement against it is presented as "Privacy" problem. The real reason we don't have a national identifier is because it takes away rich demographics that are valuable in data mining. a national identifier is just that, and identifier. Not authentication. As an identifier the queries do not need to be using rich demographics, things that change as people marry and move around. Thus a match is binary. A failure to match, causes an exception processing that likely takes a long time and involves people that are audited. A positive match brings positive linkage to Privacy preferences and consents.
Not to say that the identifier can't also enable authenticated identity assertions that have greater usefulness... (my bank number is just a number, but when I use my ATM card, the card is challenged with the pin and produces a assertion token. Totally distributed. Two different functions useful in their own ways.
John Moehrke (Dec 23 2020 at 16:13):
The main failure of existing implementations is that there is no support for the "Transparency" Privacy Principle.... The patient has the right to see ALL the uses of their data, not just "accounting of disclosures". THAT would address your concern
see https://healthcaresecprivacy.blogspot.com/2015/04/privacy-principles.html
Josh Lamb (Dec 23 2020 at 16:14):
The amount of patient work is the same. In the member/patient facilitied peer-to-peer model, the patient must have a FHIR app (or use a payer created FHIR app on their portal) to send a request to their current payer's FHIR server, which will initiate the payer-to-payer transfer. The work required by the patient will not be reduced by this process, since they still need an app and portal credentials. The patient is also asked to provide identity informatino that is impossible to authorize access to, e.g. a member id for another system.
I also think the way that people interact with the technology will change overtime. It will become more natural to use technology to interface with healthcare. There should be no work for the patient / member in a mature ecosystem. When I signup for a member portal I could also opt-into a personal data exchange cloud if I wanted to, as an example. I could enroll in health services that meet my needs, just by opting in. There are better ways to solve churn and lost portal credentials.
Josh Lamb (Dec 23 2020 at 16:17):
Based upon discussions it does not seem we can implement this. Even if we did manage to get this setup for every payer and provider it seems we will create wide security holes. I am also struggling to find the extra value this member facilitated peer-to-peer exchange gives anyone.
Dave deBronkart (Dec 23 2020 at 23:23):
I'm fascinated by this but it's a rough time of year to wade through it all. It's likely to be Saturday at the earliest, maybe next week, before I can absorb.
I agree with @John Moehrke that both populations exist. The disengaged / "I have no problem so stop bothering me" contingent showed up in Meaningful Use as the severe difficulty reported by providers across America in getting patients to log in to the portal. I suspect that was only one factor but it's quite real - most of my own friends just look at me weird when I talk about portals!
But oh, the ones who do engage - often because of severe conditions - nobody has any right to keep them away.
Dave deBronkart (Dec 23 2020 at 23:30):
A bigger concern for me is the rumors I've heard (which I've been unable to investigate) that some are suggesting insurance companies should be the SOLE OR PRIMARY aggregators of my health data. NO, NO, NO. They have shown repeatedly (as an industry, not every company in every instance) that their goals are in no way aligned with patients, which means it would be a catastrophic design error to put them in any position of control over our data.
Now, if insurers will show purity of heart by providing superb clean highly usable views of all our data, fully accessible to us for sharing with others, and speedy resolution of Patient Requests for Corrections, then that might be a different story.
cc @Virginia Lorenzi @Debi Willis
Dave deBronkart (Dec 23 2020 at 23:33):
p.s. As I discussed with @Josh Lamb last week re insurance (and he readily agreed), DON'T CALL THEM PAYERS. Calling them payers indicates EXACTLY the misalignment of their interests and ours. For one thing, patients know that too often they're NOT payers - they're deniers or disqualifiers. (Every single surprise medical bill is by definition an example!)
For another thing - and this is the crux, culturally - they are only "payers" in an industry-centric view, where lobbyists and policy people are designing and monitoring the money flow. Totally orthogonal to this is whether the patient's medical needs are being addressed.
Josh Lamb (Dec 23 2020 at 23:34):
Hey Thanks @Dave deBronkart . The decision to use a patient-centric exchange network vs a member facilitated peer-to-peer network will not have any impact on the effort required by the patient. Once patient's can begin to interact in a meaningful way with their data they will become more engaged anyway. For example, I know that when I go to a new doctor it can feel like starting a new care journey, from scratch. If we can get the patients their (damn) data, they can forward the data to the provider or at least have it available to help the discussions. But again, I think patient engagement is an an apples and oranges discussion when related to how healthcare data should be exchanged. To me the obvious choice is that the patient should mediate all exchanges, outside of business-to-business relationships (end users are business associates or covered entities).
Josh Lamb (Dec 23 2020 at 23:36):
Looking forward, I imagine that each time you see a provider or sign up for insurance you will also be connecting a data source to your personal record. You can then control how these connections talk to each other. If you want to be a disengaged patient you can take the "default" configuration or just opt-out.
As a community we should be aware that policy decisions can be influenced by those that are offering solutions. This can create a conflict of interest, real or perceived. When challenging a decision or seeking feedback we cannot let the party that has a vested interest make all of the decisions. For example, even with engineers i trust, a code review is always required. A lack of checks and balances in a community like this will hold everyone back. So in this vein, we need multiple sectors, who will have conflicting interests collaborating in an open environment for any of this to work.
The solutions built upon false premises are begging for disruption anyway.
Lloyd McKenzie (Dec 24 2020 at 02:21):
"Once patient's can begin to interact in a meaningful way with their data they will become more engaged anyway" - that's true for some, but definitely not true for all. There will be a lot of patients who will not want to be engaged at all - but will still expect their data to flow from payer to payer.
Lloyd McKenzie (Dec 24 2020 at 02:22):
(at least when it's necessary for them to avoid extra hoops)
Josh Lamb (Dec 24 2020 at 02:39):
Sorry Lloyd, you are correct. I have personally asked my friends (younger crowd) and they do not care about health data, member portals, or anything like that at all. No matter how sexy we make the technology it will be background noise for some people. Regardless of the member's/patient's personal philosophy, I do not think we should associate member/patient engagement with the decision to use a peer-to-peer model vs a patient-centric model. The member has to engage to allow data to be transferred on their behalf, e.g. opt-into peer-to-peer exchanges. This will always be true since the application end users we are servicing are not business associates and we can not treat the payer-to-payer and payer-to-provider exchanges as business-to-business connections (we cannot trust our end users to declare access rights, sorry patients/members of other plans/systems!).
David Pyke (Dec 24 2020 at 14:48):
The issue is, we have established Trust Frameworks in place like Carequality and CommonWell. They facilitate the exchange, set identity proofing requirements, set security and authorization requirements and don't require the patient to be forced to authorize every exchange. Health plan providers haven't signed up to these because there's been no requirement, before now, to do so. Setting an app or patient portal or other intermediary to aggregate all the data sounds like a great idea but that requires a very intuitive understanding of the interface, a willingness to be the gatekeeper of their own data and trust framework that does it all.
David Pyke (Dec 24 2020 at 14:50):
Currently, the peer-to-peer frameworks are set up and working. TEFCA is on the horizon, Carequality now has a FHIR infrastructure set up and is putting it in testing. All that is necessary is that CMS and ONC push organizations on these networks and get data flowing. While I want patients to have far more rights for their data and to be able to access their data as simply as a provider can, trying to get them in the middle of all information exchanges is moving in the wrong direction. Data should flow, not wait for a patient to click OK on their phone.
Brendan Keeler (Dec 24 2020 at 16:06):
I agree with David here. A pure B2B network is complementary, not mutually exclusive, to patient/member exchange.
Josh Lamb (Dec 24 2020 at 16:12):
Thanks @David Pyke , good to hear other takes on this. I will include a section addressing these points.
I think there is a misconception that a member-centric model will require the member to engage more than a peer-to-peer model. We have to engage the member/patient to initiate/authorize all payer-to-X transactions. The process will always involve collecting prior plan identifiers from the member/patient while they are logged into their current member portal (or have active access token). In payer-to-payer the intent is to retrieve historical data and have it collect in one place. This seems to reduce the need for long lived connections (or transfers that occur without patient/member engagement). In a member-centric model, the same effort/engagement would have created a long lived data source.
On the payer-to-provider side, we have more of a direct need for long lived communications from a payer to a provider. This process will begin via member/patient opt in. In a member-centric model, the opt-in process would be achieved by adding the provider as a data source. The advantage of this method is the member/patient will also gain full access to the provider's other data/functionality. A long lived offline access token will easily enable long lived connections.
If we want to make things even easier, We could also consider automatically linking to personal health data cloud when people get portal access too. This may be represented as an opt-in option to have data automatically sync to a health data cloud platform. This could also be done nearly automatically via an opt-in option as part of the portal creation. This would allow for data to flow as needed between holders with no patient/member engagement.
Josh Lamb (Dec 24 2020 at 16:14):
@Brendan Keeler I am considering the transactions performed between dataholders in payer-to-payer and payer-to-provider as peer-to-peer exchanges. The end users of the applications will not be business associates (or use our identity management solution). I have no issues with business-to-business exchanges, we do these to support operations already.
Debi Willis (Dec 24 2020 at 17:44):
I think another important point is what @Dave deBronkart addressed... incorrect data in charts. As a patient and caregiver who has been impacted by incorrect data shared between entities, I would like to be notified when data is shared between orgs... with a link to review the data for accuracy. I know this is a big wish, but I thought I would throw it out there. It is really great to see interoperability expand. AND it is really scary to know that incorrect data can be shared so quickly without me seeing it. If I "opt in" for sharing, I would want to also "opt in" for reviewing what was sent. Perhaps not all patients would want that. But I would feel better (and more willing to share) if I got a link to review the data that was shared. This would allow me to ask for a correction when I see bad data has been shared.
Josh Lamb (Dec 24 2020 at 18:23):
I will include this in the community comment. Thanks!
Lloyd McKenzie (Dec 24 2020 at 19:30):
In theory, the patient wouldn't need to be involved at all. The new payer can (with provider permission) access certain past patient data - potentially including prior coverage information. The new payer can then contact the original payer to execute the transfer. According to CMS, such transfers are considered covered under continuity of care and do not require explicit patient authorization. (At least that's my 3rd-hand understanding.)
Dave deBronkart (Dec 24 2020 at 19:35):
I wonder if there's a market, for patients and families like you, for a tool that maintains a "single source of truth that WE have vetted," and compares it against a cc of other transmissions in transit. Like, as engaged as @Morgan Gleason and her mom are, if they could monitor all transfers of her data, it would be fascinating to see how often the transfers are spotless.
I hope that makes sense.
An essential issue from the lean & quality movements is "quality at the source." Every flaw in anything causes waste ("muda" in lean terms) and over a period of time, what people evolve to is ensuring accuracy in the first place, including active prevention of wrong stuff getting in.
So I like Debi's thoughts on this.
John Moehrke (Dec 24 2020 at 19:52):
Yes, there are solutions that take input from many locations (and thus data formats), and harmonize into a unified perspective. This concept has been written up in IHE as the Implementation Guide mXDE. It includes Provenance for everything back to all the sources that each piece of data was derived and how it was manipulated.
The results are offered to clients through the core set of FHIR Resources (observations, allergies, medications, immunizations, etc)
My webinars on that are https://healthcaresecprivacy.blogspot.com/2018/09/webinars-on-mhd-and-mxde-available-from.html
John Moehrke (Dec 24 2020 at 19:53):
I understand that there is an endpoint on the CommonWell network that does this... I forgot who provides it
John Moehrke (Dec 24 2020 at 19:53):
I think there are multiple vendors that offer it. @Tone Southerland @Keith Boone
Josh Lamb (Dec 24 2020 at 20:50):
Lloyd McKenzie said:
In theory, the patient wouldn't need to be involved at all. The new payer can (with provider permission) access certain past patient data - potentially including prior coverage information. The new payer can then contact the original payer to execute the transfer. According to CMS, such transfers are considered covered under continuity of care and do not require explicit patient authorization. (At least that's my 3rd-hand understanding.)
Thanks Lloyd. This is a good point. I will address this in the community comment. I will demonstrate how data source integrations on behalf of a patient/member can be bundled into the portal creation process. I have several ideas for how this will work.
It is also striking me how absolutely valuable and powerful an application will be once it can interface with all of your data holders. Even have all the data in one place is a huge win but I think this is jist the tip of the iceberg.
I just want to make sure work is occurring in the right areas so we are not all wasting time and money and taking extra time to deliver interoperability. By this I mean that application code created on top of a partial data source is throwaway code. If we can get a complete picture we can start building out interactive use cases that are meaningful, like prior authorizations and continuity of care. An application developed on top of the patients data is not throw away and it can service all patients. I feel like we are segmenting the market and the only people who are winning are the vendors.
Josh Lamb (Dec 25 2020 at 19:39):
@Dave deBronkart and @Debi Willis , I hope the following passage is okay with everyone:
"Some commenters have also also pointed out how empowering a patient-centric design can be for the “E” patient populations. These “E” patients are equipped, enabled, empowered, and engaged. For the types of patients that are highly engaged, a member-centric model is highly preferred. This model will allow the patient a chance to verify the accuracy of all health data. This will allow the patient important opportunities to assist healthcare providers maintain the accuracy of the patient’s medical chart. The member-centric design will also enable the “E” patient to tightly control what information is released, when information is released, and where the information will go. As many patient advocates point out, the patient’s ability to improve medical data cannot be overlooked. A peer-to-peer model, which skips the patient, will make it much more difficult for patients to help with their own care. To quote e-Patient Dave, “Let Patients Help!”
As another “E” patient advocate mentioned, they would like to be notified when their data is shared. In a member facilitated peer-to-peer model this would require even more expensive infrastructure to support. A member-centric model will allow the “E” patient maximum control because they will be mediating all transactions (automatically or manually). "
Debi Willis (Dec 28 2020 at 17:45):
Thanks @Josh Lamb. I think this looks good.
To underscore a reason for my desire to know what is being shared between health orgs....I am the POA for my 92 year old mom with Alzheimer's. I know her medical history and her medication list. I go with her to the doctor and confirm them in person. A few months ago, after confirming my mom's medications before a surgery (in person), I called to check on my mom again after surgery. The nurse told me she was on her way to give mom her meds. I asked what meds she was administering. She listed the meds she was about to give mom...a list of meds that had been discontinued 2 years prior because of side effects were in her hand and she was on her way to mom's room. I asked her where she got that old discontinued list. She said it was pulled in from a prior health org in another state. I explained that was old data and i did not want mom taking those drugs. Even though I was there in person before her surgery to give the clinic the updated list of mom's meds...they were overruling my information with old data from another system. I don't believe this is a rare occasion. If I would have received an email letting me know that information was being pulled from a old clinic in another state, i could have called and stopped the process earlier. (They had already given her at least one dose of the meds before i found out.)
Josh Lamb (Dec 29 2020 at 02:12):
Hi Debi,
Thanks for this input. This is a powerful example why patients can make a huge impact if they can access their data. The data enabled you to intervene remotely it seems (without physically picking up her medicines or administering them).
I am considering now how different engagement levels may dictate they types of applications and approach to health exchanges a patient may use. A disengaged patient would need maximum automation and seamless opt-ins. An E patient though would probably decline the automatic Opt-in to use a personal repository.
Very interesting! Thanks for these great points!
Dave deBronkart (Dec 29 2020 at 13:03):
@Josh Lamb and all, I'm just beginning to emerge from time off - this is a lot to catch up on but I'll see what I can do.
Some first quick hits:
- +100 to @Lloyd McKenzie re not all patients will want to engage. Some people are lazy but others just want to be taken care of - "It's your JOB to take care of me!!"
- Especially, not all patients (especially declining elders) have a skilled, vigilant @Debi Willis or Grace Cordovano or @Amy Gleason (Morgan's mom) looking after them.
- But when patients (in the inclusive sense, ie with caregivers) DO want to be involved, there is no moral justification for blocking their access to information. IMO when harm arises because an access attempt was blocked, there should be legal consequences.
I therefore believe that we, the system designers bear responsibility for baking into the system as much capacity as possible for catching errors as they fly past, which includes an easily accessible "inspection port," so to speak.
We in the #patient empowerment workgroup have said repeatedly, and will say forever: clinicians can only achieve to the top of their potential if the data in their hands is accurate; and it's unreasonable to add the burden of data perfection to clinicians' workload. Let patients help.
Here's an analogy: your cupboard might contain a rotted fig, full of bacteria, which nobody has seen in forever. When copies of that cupboard start circulating, it's a problem.
Josh Lamb (Dec 29 2020 at 14:30):
Hi @Dave deBronkart , great points. Creating systems that can best meet the needs of a wide variety of patients is challenging. Hearing real world examples is helpful. Thanks!
These examples are making it clear why enrollment into an exchange needs to as easy as possible. The E patients will be easier to help, since they are willing to use any tools available. The disengaged patients must have the tools glued to their hands (for lack of a better metaphor).
In the future, it seems that personal health data clouds will provide the most seamless experience possible for a disengaged patients. This would just require an ability to "opt-in" when a portal is created/accessed and a good way to perform identity proofing. Identity proofing initiatives are currently underway and will be needed for all efforts that enable exchange of information outside of a business-to-business relationship.
Dave deBronkart (Dec 29 2020 at 14:31):
Here's an example from the early days of my own near-fatal cancer case. Note, this isn't even an egregious data error - it's a simple granularity problem.
At the time, only one treatment ever cured kidney cancer. Success rates were low, and 4% of patients died of side effects. Rules to qualify were strict.
One of the ways Boston's Beth Israel Deaconess renal cell program helped save my life is that they invited me in to the tumor board discussion of my case. There, reading my problem list, a Fellow said "But he has migraines" - a disqualifier.
"No," I said: "I have ophthalmic migraines, not migraine headaches." The problem list in that home-grown system wasn't granular enough to distinguish. As it happens, I did get the treatment, did almost die of side effects, did survive - but heaven help me if I'd been disqualified because of an honest misreading of clumsy data in a clunky old system.
Dave deBronkart (Dec 29 2020 at 14:36):
Josh Lamb said:
These examples are making it clear why enrollment into an exchange needs to as easy as possible. The E patients will be easier to help, since they are willing to use any tools available. The disengaged patients must have the tools glued to their hands (for lack of a better metaphor).
It's useful to think of credit card statements. 1-2 generations ago, when bank records were first computerized, it was not uncommon to find mistakes - erroneous charges or fraud. I don't remember all the details in the decades since, but today we're in a world where many people may ignore their statements as long as everything seems okay ... but careful people do scrutinize, and when they find a mistake, the bank is REQUIRED to have well defined processes and timelines to get them resolved.
There's a "famous quotes" line somewhere that says vaguely this: The fact that some people don't care about something has absolutely no effect on how to handle the people who do. That's certainly the case with health data.
Debi Willis (Dec 29 2020 at 15:23):
@Dave deBronkart, I love your word pictures :grinning:
Debi Willis (Dec 29 2020 at 15:33):
To follow your credit card example @Dave deBronkart , I have a text or email sent to me every time there is a transaction on my credit card or my mom's credit card. This allows me to quickly know if an unauthorized person is using the credit cards. I did have to opt in for that...even indicating if i want text or email. Not everyone opts in, but i really appreciated the ability to do that. An "opt-in" function on notification of the sharing my health data (or mom's health data) would be very useful. I may even be willing to change healthcare providers if they had it available and my current provider did not. (Our entire family changed health systems when FHIR was available and our old provider decided they did not want to implement patient access via FHIR API.)
Josh Lamb (Dec 29 2020 at 16:36):
Yes, I agree with @Debi Willis that the credit card example is a great way to frame the progression of technology and how people will interact with that technology. As you mention @Dave deBronkart , there will be formal processes put into place to help ensure that error can be addressed in a known way.
I would love to develop a non-profit personal health cloud and begin automatic integrations with the data providers. The applications that could be housed on top of these personal health clouds would be EXTREMELY powerful. The quibbling over who will own all of this data needs to be put to rest! Let the patients have it!
Thanks again for these great discussions! I have learned so much from this community and hope to make an impact.
Dave deBronkart (Dec 30 2020 at 13:14):
Debi Willis said:
An "opt-in" function on notification of the sharing my health data (or mom's health data) would be very useful.
Very yes! Very yes! I wonder if it's too late to get that into Cures 2!
(I've never said "very yes" in my life - it's a new visceral reaction. Love it!)
@Josh Lamb you might weave that idea into the conversation in your response, even if it's not directly relevant.
(Our entire family changed health systems when FHIR was available and our old provider decided they did not want to implement patient access via FHIR API.)
How long ago was that? And did you tell the administrative people why they were losing your business?
Under the Final Rule, they'll have no choice now, right?
Dave deBronkart (Dec 30 2020 at 13:19):
Josh Lamb said:
Thanks again for these great discussions! I have learned so much from this community and hope to make an impact.
Does that mean you're leaving us? :smile:
Josh Lamb (Dec 30 2020 at 18:55):
@Dave deBronkart , No I am not! I certainly appreciate the wisdom though.
It seems that the comment's persistence on helping patients and "patient-centric" designs was creating the wrong impression for some folks. Essentially the comment is arguing that existing patient-centric exchanges should be enhanced, improved, and the ecosystem should rally around this design (a patient-centric one).
The community comment is here if link was lost and should be more readable/clear now (constructive feedback still welcome):
https://docs.google.com/document/d/1yU-4ur5TBxU1RQXwCJi19xNk6LAahTVOTM2Ap4068PU
John Moehrke (Dec 30 2020 at 19:45):
yes, it is not a technical problem... it is a need to define these careplans and how everyone interacts with them. The technical communicatinos pathways are not the problem. Policy and Will is the problem
Josh Lamb (Jan 03 2021 at 23:16):
Hi, @John Moehrke,
I created the following image to demonstrate that patient-directed exchanges will help align policy, and will.
Thanks again for this input!
John Moehrke (Jan 04 2021 at 13:15):
I like the other one I saw on LinkedIn that you created. This one is not explicitly saying the data actually flows thru the patient, I believe you are speaking about control flow. But there will be misunderstandings by significant readership that this is endorsing the case where the patient is the network, not just the controller.
Dave deBronkart (Jan 04 2021 at 13:19):
Hi @Josh Lamb and all - now begins the dreaded annual period of dragging myself out of the holidays and back into being useful! (More or less, ahem) Much to catch up on.
Yes, let's see the other diagram @John Moehrke just mentioned. The one you posted here is a little puzzling to me - it says data delivered directly to patients but it seems to go through two other layers. Seems to me this might need a different topography with flow arrows heading in multiple paths, each enabled by FHIR APIs. Yes?
p.s. I envy your diagram skills and/or tools!
John Moehrke (Jan 04 2021 at 13:28):
This is the linkedin thread I saw https://www.linkedin.com/feed/update/urn:li:activity:6751692815345954816/?commentUrn=urn%3Ali%3Acomment%3A(activity%3A6751616339200221184%2C6751692738237865984)
This proposes an aggregator that knows all... A personally directed aggregator, yes... but I fear this too will be misunderstood to be asking for a nationwide aggregator that does the aggregation regardless of if the patient has authorized it too... Even with patient consent for uses, this is still a privacy violation. I know this is a business model.
Some diagrams are helpful, but all diagrams are flawed. Well meaning diagrams can be read by like minded people the same way as intended. But they all can be taken out of context and read to mean something totally different.
Kevin Mayfield (Jan 04 2021 at 14:16):
Have been building an aggregator for my wellness data (mostly from fitness app api's) - it did fit with the pattern on the right.
It's refreshing how the majority have open API's which aren't difficult to connect to. However my illness (health) data would be a different matter. Wondered if the wellness data might be something that opens up doors in the long term?
Josh Lamb (Jan 04 2021 at 14:16):
Thanks @John Moehrke and @Dave deBronkart ,
@Dave deBronkart you are correct. Data producers deliver data directly to patients, but the data producers do not have to create smartphone apps or build connections using this model.
To @John Moehrke's point, people may not see the same things when looking at a diagram. The comment suggests that long term, data producers could publish data to a publically owned (public utility) personal health cloud service. Patients who do not have smartphones or the internet still need to participate in health data exchanges. The data needs to be available when a patient needs to engage. Interacting with the data or releasing the data will be under the control of the patient.
The diagrams, and the supporting text, is still available here:
https://docs.google.com/document/d/1yU-4ur5TBxU1RQXwCJi19xNk6LAahTVOTM2Ap4068PU
John Moehrke (Jan 04 2021 at 14:22):
A PHR is commonly used solution as a personally directed aggregator. This might be cloud, personal desktop, or phone based.
A treatment specific service used by the patient's clinicians might also serve this purpose. These might be hosted by the HIE (IHE has an Implementation Guide on this kind - mXDE), these might be hosted as part of the EHR within a treating organization (common feature of the big EHRs), or might be a service used by your Primary Clinician.
The critical for me is that these don't aggregate until the patient has authorized them to do so. This is more privacy principled. But this does make the data less useful for non-treatment purposes, such as machine learning. Hence why it is problematic in the eyes of businesses that are looking to cash in on these cashed aggregations.
Josh Lamb (Jan 04 2021 at 14:27):
@John Moehrke , I imagine a system with data pushed to it through business-level integrations with the personal cloud utility. A patient must activate the data. Data added to this repository would need to be identity proofed. Identity proofing will be necessary regardless of the approach taken.
The utility cloud's primary points are we should not let businesses compete for the future of all healthcare data. This competition causes interests to fall out of alignment.
Derek Ritz (Jan 04 2021 at 17:24):
John Moehrke said:
The critical for me is that these don't aggregate until the patient has authorized them to do so. This is more privacy principled. But this does make the data less useful for non-treatment purposes, such as machine learning. Hence why it is problematic in the eyes of businesses that are looking to cash in on these cashed aggregations.
In jurisdictions that have implemented universal health coverage (UHC), and where these jurisdictions have invested in health data sharing infrastructure for the purpose of supporting care delivery, an implied-consent model is common. Basically... unless a patient opts out of disclosing their data, it is shared by default. Also... it is common to not be able to opt out of data collection (as this is needed for payment transaction processing, for mandatory disease-reporting, and for health system management and analytics (using aggregated or de-identified data).
Dave deBronkart (Jan 04 2021 at 17:58):
John Moehrke said:
This is the linkedin thread I saw https://www.linkedin.com/feed/update/urn:li:activity:6751692815345954816/?commentUrn=urn%3Ali%3Acomment%3A(activity%3A6751616339200221184%2C6751692738237865984)
FWIW this diagram from that thread is pretty much what I had in mind! Incomplete, as you say ("All models/diagrams are flawed, some are useful") but this one conveys what I meant.
image.png
Interesting work, @Josh Lamb !
Josh Lamb (Jan 04 2021 at 18:31):
Do not ask how long the diagrams took to create @Dave deBronkart but the tool I used is Lucidchart.
Dave deBronkart (Jan 04 2021 at 18:40):
Josh Lamb said:
Do not ask how long the diagrams took to create Dave deBronkart but the tool I used is Lucidchart.
Dude. :smile: One of the aphorisms in my book is "Clarity is power," and the time you put into those graphics is a terrific illustration: by making the structure of your thoughts clear and accessible, you empower us to get your point. So thanks.
Dave deBronkart (Jan 04 2021 at 18:42):
(This "clarity is power" thing is so important for the future of healthcare! In my hundreds of speaking events I often heard learned physicians express worry about poor "health literacy" among the public. It irked me, because you cannot discuss "literacy" without discussing the clarity of what's being presented. My first blog post about this was almost 10 years ago.)
John Moehrke (Jan 04 2021 at 18:48):
@Derek Ritz I don't disagree that this is done. I would not even disagree that it is important for Treatment purposes. No question that when one presents for treatment one is implicitly agreeing to the use of their data for that treatment. Payment is similar although differently authorized. The slippery slope that I am warning against is where the aggregation is used for purposes beyond treatment/payment, such as data mining to produce clinical products (the Henrietta Lacks of data abuse).
Josh Lamb (Jan 04 2021 at 18:48):
Clarity seems especially important in consensus building. A clear message, without ill intent, can help get people on the same page. People are also busy and a picture can help save time.
Derek Ritz (Jan 05 2021 at 15:44):
Thanks, @John Moehrke, for the thoughtful response. I'm especially grateful for the introduction to HeLa... I had no idea of this very interesting story. Regarding the issues of PHI autonomy and control... I think it is important to distinguish between publicly funded data analytics that leverage publicly funded health informatics infrastructure versus private sector initiatives that "steal" PHI and use it for purely self-serving, commercial purposes. The slope is fundamentally less slippery in the context of universal health coverage programmes that look to create large, de-identified data sets that may be leveraged as (and further contribute to) global public goods. Some very important initiatives are being progressed within this context, including work by WHO towards a global learning health system. We should want to encourage and support this important and noble work. I also believe there is domestic work by CDC in the same vein -- towards a learning health system for the USA.
Josh Lamb (Jan 06 2021 at 00:01):
This is a great point @Derek Ritz . It is irresponsible to not consider population health capabilities. I wish we had more time for the comment!
Josh Lamb (Jan 09 2021 at 20:07):
@Dave deBronkart and folks, do you have any feedback on this diagram (will be used to demonstrate that the aggregator role is versatile).
Personal-Health-Cloud.PNG
image.png
Josh Lamb (Jan 10 2021 at 22:08):
and one more, based upon questions received: Activate-Personal-Health-Cloud.PNG
Josh Mandel (Jan 11 2021 at 00:28):
Can you explain how the following works:
--- how/where is information flowing, and what are the preconditions?
Josh Lamb (Jan 11 2021 at 00:35):
Hi @Josh Mandel, great question.
The policy comment includes a few suggestions to address the need for data to flow, even for patients that do not engage. Absent a healthcare SSO, the policy comment describes a CMS sponsored health data aggregator. This aggregator would be a free public utility with data pumped to it from all approved data producers.
Identity proofing would need to be installed on top of this repository to enable interaction (shown in the other diagram).
Some additional information about the long term suggestion for a utility cloud can be found here (in the Long Term Suggestion portion):
https://drive.google.com/file/d/1mZgK-Dnf9XcT9Nj9ba8RoN0WRwOqdKIX/view?usp=sharing
Do you think this logic makes sense? The point was mostly to demonstrate the versatility and demonstrate how patient access seems to be the most stable model. There are numerous ways to invest in improving patient access. It was a bit of a chance to suggest an option.
regarding your exact questions:
How/when: A data producer would need to be given a mechanism to easily provide patient access API data (perhaps a bulk export and updates). An API or blockchain is also an option.
Preconditions: This would probably be an implementation detail. But based upon what I have seen CMS do in the past, they would need to establish a timeframe for data to become available (e.g. 24 hours from date of service).
Josh Mandel (Jan 11 2021 at 00:40):
I mean, there's a lot of potentially feasible architectures, and what you describe here is among them. But what you're describing is not something that currently exists; I think from a regulatory perspective, the key motivations should be 1) promote adoption of existing technology that works, and 2) highlight unsolved problems and encourage industry to develop solutions.
Josh Mandel (Jan 11 2021 at 00:42):
Positing a central repository of health data where everyone pushes content, and where by default information flows without a consumer having to take any proactive steps... that's quite a tall order. (For example, it would create an immense new target for attackers.)
Josh Lamb (Jan 11 2021 at 00:42):
You are correct. I have a comment here discussing how I think this should be approached from a policy perspective (last comment): https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Payer-to-payer.20and.20Payer-to-provider.20connections
The idea is to provide a simple way to redefine the 3 APIs. The technical decision behind the SMART scope that is used in connections should not have a huge impact on policymakers.
John Moehrke (Jan 11 2021 at 13:48):
note that depending on the technical solution, the identity binding often happens before the consent (your step 2 and step 3). The model you do have is not invalid, just that it is only the case where the patient is the carrier of the data. That is to say in the cases where the patient authorizes but does not carry the data (e.g. the current nationwide exchanges using XD* and FHIR) the identity binding is first. That is to say knowing which subject (patient) that data belongs to is critical to knowing which consent applies to rules of use. I would not say that these must be switched, just somehow it should be clear that 2 and 3 are needed before 4 can happen; and that 3 can sometimes come before 2.
Josh Lamb (Jan 11 2021 at 15:59):
Thanks, John. Selecting an example of a long-term way to improve health data access has created a slippery slope. I wanted to highlight long-term possibilities for improvement, but I think it was not appropriate within a policy comment. The model could be swapped out with at least 4 other equally good approaches.
Regarding patient data that is not owned by the patient, I can imagine scenarios where patient data that a patient would never have access to. This may be psychiatric notes, for example. This data can still flow between data holders using patient-centered connections (post, put, get endpoints of patient access API). The personal health cloud can contain data that a patient does not have access to, in theory. Only business-to-business applications would be allowed to move this data.
Similar to the trust issues we see with member facilitated B2B connections, there are also trust issues when using a consumer application to communicate data needed for business processes. The authorization method (patient scope) can be combined with a B2B developed and trusted app to avoid both types of trust issues.
Josh Lamb (Jan 11 2021 at 22:04):
(deleted)
Dave deBronkart (Jan 12 2021 at 00:00):
@Josh Lamb I'm just getting back on Zulip after the weekend. The diagram looks pretty :smile: but I'm not able to grok the entire context well enough to evaluate the diagram off-the-cuff ... sorry!
Dave deBronkart (Jan 12 2021 at 00:01):
Regarding the types of patients - I have a feeling there's something worth chewing on but I really needed to land on this Saturday, when you posted it. Sorry!
Josh Lamb (Jan 12 2021 at 00:11):
Thanks, @Dave deBronkart, The last diagram was too technical. I removed it.
The way patients interact with health data (or don't) impacts the usefulness of a given approach. A smartphone app will not help people without smartphones. Low-engagement patients will need a more advanced solution. E-patients are easy, they do everything themselves.
This may help make the point more clear (or I need a different design):
Patient-Engagement.PNG
John Moehrke (Jan 12 2021 at 13:28):
On the topic of data about the patient that they don't control... I would cast this very differently. The data is about the patient subject. full stop. The fact that there are some scenarios where government does the authorizing of accessibility is simply a policy. That is to say that there is still a "control" point. It is simply that the "agent" moving the controls is not the patient themselves but an authorized "other". That other might be a spouse, parent, child, guardian, or government. But there is still a control point, and there is still a need for a go/no-go. There is no need to express that in some governments, this is done excessively and others where the government never does this. You are working with high level concepts.
Brendan Keeler (Jan 12 2021 at 14:42):
It seems the CMS ignored the comments and bulldozed to the next phase
Dave deBronkart (Jan 12 2021 at 14:47):
Brendan Keeler said:
It seems the CMS ignored the comments and bulldozed to the next phase
What did you see, @Brendan Keeler , that I didn't yet?
Brendan Keeler (Jan 12 2021 at 15:12):
https://twitter.com/HITpolicywonk/status/1347552129175728128?s=20
Really @CMSGov you read 1600 comments, wrote a final reg that took into account all of the comments, had other agencies review & provide comments, got OGC to approve, & submitted to OMB in what amounts to a day and a half? Way to disregard the fed process to ensure public input.
- Genevieve Morris (@HITpolicywonk) Josh Lamb (Jan 12 2021 at 15:24):
Thanks for sharing @Brendan Keeler .
Every single person I asked said something similar will occur. There is an administration change occurring, and it is political.
Plus the trade groups were not in agreement which caused most of the comments to contradict. The only unifying message was, we need more time.
This comment would have done much better if it addressed that a patient-centered connection can be created using a B2B app.
The community and workgroups also need to get on same page, which will not occur due to conflicting interests on this topic.
Hopefully the policy makers can take this input into future rules.
Josh Lamb (Jan 12 2021 at 15:38):
I agree @John Moehrke, I was explaining it poorly but there is a need for businesses to communicate data in a trusted way between eachother. In these scenarios, the transaction will only be allowed of both parties can trust the exchange.
A consumer facing application, that is only protected by the FTC, would not be able to provide these assurances.
For the time being, I do not think we need to create any B2B apps for interoperability, but I can imagine several use cases.
John Moehrke (Jan 12 2021 at 16:00):
it is seeming that healthcare Interop is becoming (for various reason) a more expansive thing than ever before. That is to say 50 years ago, your data was mostly only needed by your home-town doctor. But today we are move mobile people, we move homes more, we vacation more, etc.. and we tend to be flexible enough to seek care at specialty clinics... and there are more opportunity to treat chronic conditions leading to positive aging... and we are realizing that public-health is an important vector that we need everyone to participate in... THUS the idea that healthcare "trust domains" can be a "local" thing is not scaling. That is something that I think @Josh Lamb is trying to express, but I don't think is quite as clear. The effect is that the systems that protect, control, and monitor the flow of data for a given subject (patient) has a need now that has not existed before. This is why the view needs to be patient centric. But this is also why we need to move away from the historic models that controls the data only at the custodian of the data. That model might scale, from the custodians perspective; but it does not scale from the patients perspective. Especially when the patient has received care at 100 or 1000 sites. as that 100-1000 sites problem, means the patient themselves needs to manage 100-1000 custodian based privacy policies. Where the privacy policies are simple YES/NO; this might not be a problem.. but where the patient has ANY deviation (and we are humans) this becomes unmanageable.... thus until one sits as a patient, one doesn't see the problem.
Josh Lamb (Jan 12 2021 at 16:59):
@John Moehrke, this is 100% what I am trying to say. Thank you for summarising the need in this way.
The current restrictions benefit custodians, not patients. Patient access is the key to free-flowing data.
John Moehrke (Jan 12 2021 at 17:19):
note that the phrase "current restrictions benefit custodians" is implying that the custodians are working to keep the benefit only for themselves. I am not saying that some are not doing that, surely there are... but rather to point that without a better solution, the custodians are FORCED to act this way. Many read the federal laws and find no room for doing anything else, while others read federal laws and see no way the current system is allowed. Many custodians are indeed protecting their business interests, seen today as 'information blocking'. But there are MANY healthcare organizations and vendors that are trying really hard to externalize these control points.
I don't see this changing without federal government taking leadership.. but to do that is against hundreds of years of leaving these kinds of policies to the states.... Hence why I think the new reality is so important to recognize as a legitimate reason for the federal government to take leadership. This is not to say that they must centralized, they should NOT. But they need to unify policy spaces. We need a unified patient identity. We need a unified patient control. We need a unified patient privacy principles. This does not mean that there is only one policy, but rather that there is a clear and agreed way that all the states/regions/organizations policies work together. It is these edges of policies touching policies that cause the biggest problem.
Josh Lamb (Jan 12 2021 at 17:31):
I agree that we need a policy or intervention to unify efforts. I thought the Patient Access API in the first interop policy was a great step. The latest proposed rule seems to take a step backwards. Unfortunately, the comment was ignored, and it was rushed (despite about 200 hours of work).
Josh Lamb (Jan 12 2021 at 17:47):
I should have said data segregation instead of "current-restrictions." Even within a health system, data may not flow freely due to IP, proprietary data models, and consent purposes.
Direct patient access breaks down these barriers, and the patient can mediate everything from there.
John Moehrke (Jan 12 2021 at 17:52):
I think that is a nice idea, I don't think it solves the problem... and will only work where the patient takes the initiative. There is a very vocal group that WILL take the initiative, but a much much bigger group that will NOT. We can't solve only for those that will take the initiative.. Yet, we definitely need to support their needs as that is one of the Privacy Principles. We need ALL the Privacy Principles addressed, not just one. https://healthcaresecprivacy.blogspot.com/2015/04/privacy-principles.html
Josh Lamb (Jan 12 2021 at 19:12):
The concepts are comprehensive. I am not trying to omit things. Rather I am just trying to focus on the lever. The in-depth information you are sharing needs to be part of the process. I have found that sharing too many details was creating additional opportunities for things to be misunderstood.
The things that I am focusing on are:
1.) endpoint discovery
2.) patient access
3.) Single credentials for patient access (point of care activation)
Dave deBronkart (Jan 12 2021 at 19:45):
Brendan Keeler said:
https://twitter.com/HITpolicywonk/status/1347552129175728128?s=20
(She corrected herself a moment later - 250 comments not 1600 - but the point stands)
Josh Lamb (Jan 12 2021 at 22:30):
We can achieve the same result by modifying the technical guidance created by the workgroups. PDex is not yet finalized (yet being included as required in rule). There may be a chance to propose a minor but substantial change to how we authorize access.
Instead of providing identifiers through a member matching mechanism (TBD), I propose that a user will provide credentials directly into the third-party portal for all member-facilitated B2B exchanges. This is the same process we see today for consumer-facing applications, but the consumer will be interfacing with a business application.
This change sounds minor, but it allows B2B exchanges to occur under Patient Access, which is really important. The 27-page policy comment was attempting to drive this one point home. But victory is allusive!
An image summary of the change is here:
HIPAA-Member-Facilitated-Transactions.PNG
@John Moehrke does this seem like a good approach to you? Thanks again for the earlier feedback.
Josh Lamb (Jan 14 2021 at 06:03):
Was able to get some professional feedback, here is the result:
Member-Facilitated-B2B-Exchange-Alternative.PNG
Josh Mandel (Jan 14 2021 at 15:27):
I'm not sure how to read this diagram. Are the first three rows designed to be alternatives? Or does the first row flow into the second row in a sequential process, and then into the third?
Josh Lamb (Jan 14 2021 at 16:09):
Great feedback, @Josh Mandel. I have replaced the above image with an updated version. If it is not immediately clear how to read this, let me know!
Josh Lamb (Jan 14 2021 at 16:12):
It is supposed to read in three phases.
1.) data producers get things ready.
2.) the patient engages by providing credentials
3.) The B2B app shares data.
Josh Mandel (Jan 14 2021 at 17:51):
I'm still struggling. Is the "B2B Application" in row 1 the same as "B2B Trusted Application" in row 3? It'd be nice if there was a connection, or a single box if so. I'm overall just having trouble figuring out who all the actors are, with different clip art in each row, etc. I'm sorry this isn't super constructive; basically this diagram is just confusing me, so I'm not sure what to suggest to improve it, but if others aren't confused, I'm probably not your target audience anyway :)
Josh Lamb (Jan 14 2021 at 17:54):
No, this is good. I want to hear the hard truths. If it's not useful, I would like to know.
I am attempting to summarize the "ask" into an infographic. It may be too much for me to try and communicate.
Basically, there is a current proposal for how to handle payer-to-payer exchanges. The only difference between the current proposal and this proposal is that the individual using a Payer/Provider B2B app will use the standalone launch patient flow to authorize directly against the IMS of the other data producer.
It is probably one of those things where if you think about something too much you can no longer talk to people about it in a normal way :-(
Josh Lamb (Jan 14 2021 at 18:48):
If this one does not work I will need a completely new design: Consumer-Facilitated-B2B-Exchange.PNG
Josh Mandel (Jan 14 2021 at 18:48):
Since you're writing a "Change summary" -- maybe what would help is a "before the change" and "after the change" diagram, showing any structural differences?
Josh Lamb (Jan 14 2021 at 18:51):
This is a good idea. I will have to think about making it concise, but this is what I am missing, I think.
David Pyke (Jan 14 2021 at 19:24):
THis is getting to the point where is should probably move to it's own channel.
Dave deBronkart (Jan 15 2021 at 12:36):
And what might that channel be?
@Josh Lamb I can tell I'm instinctively interested, but I can't even tell (readily) what's going on. That probably supports the point made by @Josh Mandel that it's not clear enough to achieve anything. (Honestly I've presumed that it must be a technically accurate map of a really complicated process, which is not inconceivable in health IT!)
In the spirit of Josh's suggestion I'd be willing to step back with you this weekend for a broader look at what this is all about, and work forward from there.
Josh Lamb (Jan 15 2021 at 16:52):
@Dave deBronkart, I will take you up on the offer for help.
Doubt it is any clearer now, but here is the latest version, including an attempt to contrast the proposal against the current designs, as Josh suggested. Since it is not clear, the infographic attempts to explain how Payer Access API and Provider Access API requirements can be met without creating any new APIs or modifying CMS policy. Instead, we just need a minor modification to the PDex IG.
Consumer-Directed.PNG
Dave deBronkart (Jan 16 2021 at 00:51):
I want to start over with understanding what we're trying to communicate and why .... Bring a sandwich maybe :smile:
Dave deBronkart (Jan 16 2021 at 00:53):
It may be that we need to START with the narrative in the fine print on your sidebar, and make this a series of not-fine-print slides, then build this graphic as some story unfolds. Right now it's a great big gestalt sitting on my head and straining my neck muscles :smile:
Josh Lamb (Jan 16 2021 at 14:46):
Good call @Dave deBronkart, As it turns out, explaining this to smart tech experts like @Josh Mandel is trivial.
This idea will not survive unless I can make the intentions clear to a diverse audience. As such, I appreciate any feedback you are willing to share, Dave.
Here is a summary:
We have an opportunity to rapidly accelerate health data exchanges, reduce waste, and improve Patient Access. We can achieve these benefits through a small technical correction to the DaVinci PDex Implementation Guide (IG). PDex IG defines how payers and providers must share patient information during consumer-facilitated business-to-business transactions. The PDex IG is not finalized. There is still time to provide technical feedback and suggestions.
This proposal allows every Payer and Provider owned application to PULL information from existing Patient Access API connections and PUSH data in a format that conforms to the DaVinci B2B IG. The existing PDex IG requires data producers to PULL data from two new B2B sources, e.g., Payer Access API and Provider Access API. Instead of segmenting the patient's data and creating new connections, we can leverage existing Patient Access to PULL data.
A consumer-facing application that is connected to many healthcare data providers is powerful. This type of application can be created by the public or private sectors and deployed within existing Payer and Provider portals. In order for an application to participate in B2B transactions, it must be owned by a Payer or Provider (to enable HIPAA protections). A member or patient would interface with the application within an existing portal session.
Here is the exciting part: if the application exposed within a payer or provider portal already has access to consumer connections, the application will function as a consumer-directed B2B highway. This is an essential step toward allowing health data to flow freely.
In other words, if aggregator applications like Apple Health or CommonHealth provided a mechanism for a patient/member to link their consumer application login with a payer/provider-hosted application, we have just created an alternative for a universal healthcare Single-Sign-On (SSO).
As mentioned earlier, there is still time to provide technical feedback and suggestions to IG leads like @Viet Nguyen and @Mark Scrimshire.
The infographic illustrates an approach to support B2B communications through consumer-directed exchanges (Patient Access API). Focus on Patient Access removes the need for two new B2B health data exchanges. Existing consumer-directed exchanges can be used to communicate data using patient connections.
The current guidance and CMS policy allow for automatic opt-ins. These automatic opt-ins are laying the groundwork for an exchange network that removes the patient. The current PDex guidance is also burdensome for smaller plans to implement, as evidenced by the many exclusions made for state-based Medicaid/CHIP plans.
The latest attempt to improve the graphic is here:
Consumer-Directed-B2B.PNG
Josh Lamb (Jan 16 2021 at 16:46):
@David Pyke we can move this thread, not everyone needs to help this unfold. I have been unable to adequately discuss these technical issues with the implementer community or with DaVinci. This discussion is not promoting a product or service and only seeks to find consensus. That is why I am sharing this on Social. If someone can help me work with the correct people I will not feel the need to continue seeking assistance.
Additionally, I have concerns about conflicts of interest within the workgroups. A discussion in an open forum may help to illuminate these issues with the community.
David Pyke (Jan 17 2021 at 17:49):
I would suggest moving this to the Patient Empowerment stream. They have a large number of experts and others can join.
Josh Lamb (Jan 17 2021 at 17:54):
Thanks @David Pyke. There are patient empowerment aspects of this, and that group seems most likely to support an idea that is not backed by a product.
I have created a new stream to track this topic here: https://chat.fhir.org/#narrow/stream/179262-patient-empowerment/topic/Coordinate.20HIE.20Efforts.20With.20Patient.20Empowerment.20Group
Last updated: Apr 12 2022 at 19:14 UTC
