FHIR Chat · Carequality - CARIN · patient empowerment

Stream: patient empowerment

Topic: Carequality - CARIN

---

Brendan Keeler (Mar 06 2020 at 21:04):

https://twitter.com/carinalliance/status/1236010834251468800?s=21

Get pumped

Brendan Keeler (Mar 06 2020 at 21:05):

@Ryan Howells :clap: :clap: :clap:

Michele Mottini (Mar 06 2020 at 22:59):

(deleted)

Dave deBronkart (Mar 07 2020 at 14:34):

Hey @Ryan Howells , I gotta say this announcement may be great in geekworld, but it's completely over the head of my friends and family. Can there be an "ordinary people" version of this please? (It's over MY head. The announcement is clearly impressed with itself, but je n'ai pas de clue WHY it's impressed with itself.)

Or, maybe it's not relevant yet - maybe it'll be years before it touches them or affects anything. But I find that as I show excitement about the data liberación FHIR will bring, they're starting to get curious about how it will affect them.

I suspect it wants at very least a "Why it matters" link, or some such.

Also, if this will have ANY effect on consumer ability to create their own solutions e.g. for the Patient Innovator fiesta at DevDays, those of us involved in that need to understand. cc @Rien Wertheim

What do you think?

Ryan Howells (Mar 07 2020 at 14:53):

Yes @Dave deBronkart it’s a bit geeky. Let me try and simplify.

As a result of this announcement, here are the options for patients to get their health info (and obviously these could be combined such as manual + digital):
1) Manual - Use right of access to access paper copies just like we do today.
2) Digital (Use any app) - Individual selects an app who have connected using FHIR to access their Argonaut + USCDI data. Privacy, Security, and Data sharing is governed by the apps terms and conditions.
3) NEW Digital (App contractual pathway) - App signs the Carequality framework which is a legally binding contract and must abide by their data sharing, privacy, and security requirements which will be built off the CARIN code of conduct. Apps who violate these provisions will be kicked off the Carequality network and may have other legal repercussions.

Does that help? Keep in mind all of these paths are voluntary. @Brendan Keeler anything you’d like to add? Or others?

Josh Mandel (Mar 07 2020 at 15:09):

My concern with number three is it puts an unreasonably high level of trust in these apps -- basically saying that an app has the technical ability to query for data about any patient it can think of (even if the appw doesn't have the legal right to do so).

Dave deBronkart (Mar 07 2020 at 15:16):

Josh Mandel said:

My concern with number three is it puts an unreasonably high level of trust in these apps -- basically saying that an app has the technical ability to query for data about any patient it can think of (even if the appw doesn't have the legal right to do so).

Tentatively (since I'm not smart enough to assess actual risk) that would be a major showstopper, if it is what it sounds like. But I might be misinterpreting.

It SOUNDS like the whole thing depends on obedience to the Code of Conduct, which some patient activists have been "snort-skeptical" about, because without an actual enforcement squad, there's still no protection against bad actors who say "SURE I'll be good!"

But as I say, for me that's an uninformed worry - what do others say?

Dave deBronkart (Mar 07 2020 at 15:17):

To be clear, this will all blow up in our faces at the first sign of Facebook-like malarkey.

Josh Mandel (Mar 07 2020 at 15:19):

To be clear, full trust in model number two also requires some belief in an app's code of conduct. It's just that individual patients need to make this decision for themselves (no data can flow without an individual patient "at the keyboard") -- but once a patient is there and says yes, of course an app could always still be lying about how it is going to use that patient's date.

Josh Mandel (Mar 07 2020 at 15:21):

On number three, the "idea" is that apps will be contractually required to use a third party "identity proofing" service, and only after the app is satisfied about the patient's identity should the app issue a query request to a care quality network.

Dave deBronkart (Mar 07 2020 at 15:21):

Thanks, @Josh Mandel - that's exactly the kind of "one step up from clueless" guidance I need.

So what is your concern, "puts an unreasonably high level of trust in these apps"?

Josh Mandel (Mar 07 2020 at 15:23):

My concern about number three is the flow of trust: it's not enough to contractually obligate the app developers to verify a patient's identity. The (carequality compatible) network allowing the app to connect should have some technical skin in the game so it can verify the patient's identity directly.

Dave deBronkart (Mar 07 2020 at 15:23):

And Ryan, you say the code of conduct is a "legally binding contract" - that reminds me too painfully of the HIPAA Right of Access, which is unenforceable by an individual. What enforcement of the contract (i.e. surveillance and punishment) can patient activists expect to see? That's gotta be costly to CARIN.

Josh Mandel (Mar 07 2020 at 15:27):

And my concerns are definitely solvable in a technical fashion (For example, passing along "verifiable claims" from an identity proofing service to an app user and then having the user present those claims to the network for verification. Or as another example, through a properly stacked arrangement of open ID connect interactions -- though obviously in this forum I'm trying to wave my hands technically without getting into any details.)

Dave deBronkart (Mar 07 2020 at 15:52):

Josh Mandel said:

The (carequality compatible) network allowing the app to connect should have some technical skin in the game so it can verify the patient's identity directly.

Is there a consumer-level example of what form "verify the patient's identity directly" might take?

And what "have some technical skin in the game" might look like, or just mean, as a metaphor?

(Note, that's an "is there" question - "Not really" is a valid answer, if depressing :-))

Josh Mandel (Mar 07 2020 at 15:59):

Regarding the consumer experience of identity verification: sure, today there are basically services that rely on in-person proofing (like passing your driver's license to the clerk at a clinic), and online services that rely on some combination of knowledge based authentication or uploading photos or videos of yourself alongside an existing credential, or verification of known facts about you like a phone number or an email address by making sure you can respond at those endpoints -- all kinds of interesting approaches.

Josh Mandel (Mar 07 2020 at 16:00):

Some of these in my opinion don't do a great job from the privacy perspective (For example I think the knowledge based authentication services wind up incentivizing data hoarding, because the more obscure facts that a company knows about you, the "better" they can quiz you to confirm your identity)

Josh Mandel (Mar 07 2020 at 16:02):

When I talk about the network having some skin in the game, what I mean is that the network should not take a consumer app's word when it comes to identity verification. The network or the organizations releasing data should be directly (automatically, seamlessly) reviewing identity claims and determining whether they meet requirements.

Brendan Keeler (Mar 07 2020 at 16:13):

Josh has fully articulated "the three paths".

Smart on FHIR patient authorized exchange is the safest but a non ideal experience for consumers who struggle with many portals.

For trusted exchange networks:

Simple Code of Conduct can and will be abused (or "misunderstood"). Commonwell does a good job with this model by requiring certain identity vendors like Experian, though.

Network with full or partial trust infrastructure "skin in the game" (i.e. centralized identity infrastructure) is ultimately good so they can easily audit. But more work for CARIN and Carequality

Josh Mandel (Mar 07 2020 at 16:19):

For Commonwell @Brendan Keeler , when an app uses a specific service like Experian, does Commonwell get to see the Experian results directly, or does it trust the app to vouch for the fact that it used Experian?

Josh Mandel (Mar 07 2020 at 16:19):

(this is leaving aside for the moment my general queasiness about knowledge-based identity proofing... I just want to understand the flow of trust)

Brendan Keeler (Mar 07 2020 at 16:20):

They're model 2 to my knowledge. Commonwell's access is only through certification up front and regular audits I believe but I can check.

Brendan Keeler (Mar 07 2020 at 16:21):

Yeah knowledge based proofing sucks but at least it's another path

Brendan Keeler (Mar 07 2020 at 16:22):

Biometrics still not a viable path so it's either patient auth or knowledge based proofing

Brendan Keeler (Mar 07 2020 at 16:22):

Or blind trust/legally blind trust

Brendan Keeler (Mar 07 2020 at 16:24):

Given that there already are consistently some really iffy edge cases on Carequality with today's single use case, a signed agreement and potential legal repercussions alone isn't enough IMO. So interested to see the exact agreement and structure.

Brendan Keeler (Mar 07 2020 at 16:24):

But ultimately like this collaboration bringing together a lot of the best people on one of the biggest industry problems.

Josh Mandel (Mar 07 2020 at 16:25):

Yeah I am all for discussion but I'm also wary of announcements and a lot of public promotion before there is a clear technical path in place and piloted in the real world.

Brendan Keeler (Mar 07 2020 at 16:27):

This line in particular is promising: "individual users who voluntarily create a person-centric digital identity credential to use that credential across all Carequality Framework participants."

Josh Mandel (Mar 07 2020 at 16:30):

If I'm reading that correctly, it is about sign in (authentication) Rather than about identity. It's very possible I'm not reading it correctly :-)

Dave deBronkart (Mar 07 2020 at 16:32):

Where might I go today to create such a credential?

Do I understand correctly that this is analogous to the things I see that ask which of the following addresses I’ve had in the past?

Josh Mandel (Mar 07 2020 at 16:33):

I assume they are just talking about public keys that you can generate on your PC or phone (For example, Android and iOS both have hardware security modules that let you generate credentials within apps, including even the web browser) or on a dedicated hardware device like https://www.yubico.com/ that connects to your PC or phone

Josh Mandel (Mar 07 2020 at 16:34):

https://webauthn.io/ has a demonstration of the APIs built into web browsers today, and will probably work from any recent device you try it on

Josh Mandel (Mar 07 2020 at 16:34):

But this is just about how you sign in -- not about how you tie your account back to some real world identity that an organization can use to decide which records to show you

Brendan Keeler (Mar 07 2020 at 16:48):

Yeah generation of a token is trivial. Generation of an identity proofed token and full use across the network, though...

Josh Mandel (Mar 07 2020 at 16:48):

But what is the proofing mechanism being proposed?

Brendan Keeler (Mar 07 2020 at 17:08):

A salient question

Michele Mottini (Mar 08 2020 at 23:04):

How do you connect an app to the carequality network? Are there specs somewhere??

Michele Mottini (Mar 08 2020 at 23:05):

A sandbox?

Bart Carlson (Mar 08 2020 at 23:23):

The first thing you have to do is sign up at https://carequality.org/

Michele Mottini (Mar 08 2020 at 23:58):

Sorry - how do I signup? Don't see anything obvious there

Bart Carlson (Mar 09 2020 at 04:07):

Michele, Go to https://carequality.org/contact-us/ and complete the form and put in a note in the comments field about what you would like. Someone will get back with you.

John Moehrke (Mar 09 2020 at 12:23):

carequality is not an enduser organization. It is a coordination organization of organzations. Each organization is strongly vetted before it is allowed into the network. There are rules of engagement... But once in, a SAML assertion from your organization is a token that is trustable as backed by that organization. I think they were looking to add a PHR as a participant, but don't know the status. @Didi Davis ? @Bill Mehegan ?

Michele Mottini (Mar 09 2020 at 12:27):

OK, thanks, posted

Michele Mottini (Mar 09 2020 at 12:28):

@John Moehrke so consumer apps CANNOT connect and get data from Carequality ?

John Moehrke (Mar 09 2020 at 12:32):

not that I know. but that is why I added Didi to the list. She will have an authorative answer.

Brendan Keeler (Mar 10 2020 at 05:28):

PHRs can participate

Brendan Keeler (Mar 10 2020 at 05:30):

Implementers are not required to respond to any queries except Treatment, so currently less than 100% of sites respond. But that should change with TEFCA and with this new collaboration

Josh Mandel (Mar 10 2020 at 15:14):

(To be clear: today a lot less than 100% of sites respond. My understanding is that within some of the largest Carequality-compliant networks, zero percent of sites respond to consumer access requests.)

Dave deBronkart (Mar 10 2020 at 20:28):

Josh Mandel said:

(To be clear: today a lot less than 100% of sites respond. My understanding is that within some of the largest Carequality-compliant networks, zero percent of sites respond to consumer access requests.)

HOLY W-T-H???

Do you agree with Brendan that with TEFCA and this new collaboration, that should change??

I mean, there's a lot at stake here! I'll say it again - these stories of patient impact are real and will continue to be! And we have more such stories coming soon. This is real, people.

https://www.youtube.com/watch?v=9SqohvPiCgY

Dave deBronkart (Mar 10 2020 at 20:30):

John Moehrke said:

not that I know. but that is why I added Didi to the list. She will have an authorative answer.

@Didi Davis help please? "What is reality," as Firesign Theater famously asked?

Bart Carlson (Mar 10 2020 at 21:04):

Based on our experience using the Carequality-compliant networks to date, the response for purposes of "treatment" access has been excellent! However, when it comes to queries for purposes of "patient" access, then Josh is absolutely correct. In some cases certain EHR vendors response rate for patient queries is zero percent. However, there are other EHR vendors who have health providers who are responding on a limited basis for patient queries. Obviously, we are hoping all of this will be changing in the oncoming months with the announcements yesterday by CMS and ONC.

Michele Mottini (Mar 10 2020 at 21:12):

As an app developer I do not understand what any of this means

Josh Mandel (Mar 10 2020 at 22:18):

@Michele Mottini which parts? I'm happy to share my take on things, but don't want to "talk down" to you. In any case, I've just posted https://gist.github.com/jmandel/f7a28b48f70f8c89317c19ad4e2ddc2d with my own perspective / explanation, if it helps.

Josh Mandel (Mar 10 2020 at 22:19):

Bottom line though: the query networks today send out demographics and a "purpose of use", asking "does anybody have data on a patient named Michele Mottini, gender male, from zip code _____? I'm asking for purposes of {treatment, individual-access, public-health, ...}"

Josh Mandel (Mar 10 2020 at 22:20):

And then nodes respond to the query based on the demographics provided and the information about purpose of use. Some nodes decline to answer any queries if the purpose of use is anything other than "treatment".

Dave deBronkart (Mar 10 2020 at 22:21):

Will that be illegal under the new rules ?

Josh Mandel (Mar 10 2020 at 22:24):

It's complicated. A blanked refusal would probably be information blocking, but setting a higher threshold for confidence in the user's identity might be OK...

Dave deBronkart (Mar 10 2020 at 22:25):

And to be clear, "some nodes decline to answer" is code for "have been programmed to disregard," right?

Josh Mandel (Mar 10 2020 at 22:25):

To be clear, uncertainty about identity is a real problem, unlike a lot of other excuses for not sharing data. The query network has no relationship with the individual, and providers haven't authenticated the individual, but they're still being asked to attain some level of certainty and then send out PHI.

Josh Mandel (Mar 10 2020 at 22:26):

Honestly from my perspective, the query networks just aren't a good architecture for disclosing PHI.

Josh Mandel (Mar 10 2020 at 22:26):

I don't see how providers are going to be confident enough to do it.

Josh Mandel (Mar 10 2020 at 22:27):

Not without some shared approach to identity management (that's part of my attraction to the DID + Verifiable Claims world).

Dave deBronkart (Mar 10 2020 at 22:29):

Thank you. @Virginia Lorenzi @Debi Willis this will be a big issue for us, it seems

Michele Mottini (Mar 10 2020 at 22:39):

Thanks @josh - that text help. So patient facing app could get data from the Carequality network but they have to become member of it first, correct? How does that happen? ..then once you become a member you 'send queries to the network' - how? and maybe you get an answer or maybe not ...how? ...and then according to the announcement there is (or there is going to be) some central authentication system (??) ... how does that work / will work? Isn't there docs somewhere where this is explained? Would seem pretty basic

Josh Mandel (Mar 10 2020 at 22:48):

I'm getting out of my depth here, but https://carequality.org/resources/ is the source of truth -- and for technical details about how queries are sent, https://s3.amazonaws.com/ceq-project/wp-content/uploads/2018/09/30162842/Implementation-Guide-v1.1-Effective-3-27-18.pdf (short answer: IHE XDS.b).

Dave deBronkart (Mar 10 2020 at 22:48):

Thank you. @Virginia Lorenzi @Debi Willis this will be a big issue for us, it seems

Josh Mandel (Mar 10 2020 at 22:48):

I think the goal of the announcement here is to try to do something better with respect to identity proofing; I'm not sure yet what is being proposed.

Brendan Keeler (Mar 11 2020 at 00:44):

This article may help: “Trust in healthcare integration” https://link.medium.com/0EAmquuQK4

Brendan Keeler (Mar 11 2020 at 00:46):

FHIR is very prevalent in patient authorization and a bit in edge interfacing but not in enterprise interoperability networks yet (nor does TEFCA encourage FHIR currently)

Ricky Bloomfield (Mar 11 2020 at 00:46):

This has been a great discussion. Based on some statements from @Ryan Howells (please weigh in!), my understanding is that the goal here is primarily to leverage the trust framework and agreements that Carequality has worked to put into place, but that the actual patient-centric access would continue via direct connections to health systems, i.e., it would not leverage the existing (primarily C-CDA-based) query network. The theoretical benefit would be that an app could register once and be accepted by everyone within the ecosystem. Same for identity - the same SMART auth would be used for each connection, but the possibility exists of a single trusted credential accepted by anyone in the network. I think there is a dearth of details here, and I'm reserving judgment, but that's my current (possibly uninformed) understanding.

Brendan Keeler (Mar 11 2020 at 00:47):

If that's the path forward, I'm digging it @Ricky Bloomfield

Josh Mandel (Mar 11 2020 at 00:48):

Huh. You're saying the agreement with Carequality wouldn't be using any of the Carequality framework network services or API capabilities?

Ricky Bloomfield (Mar 11 2020 at 00:49):

Yeah, that's my understanding. But hopefully @Ryan Howells will jump in here.

Dave deBronkart (Mar 11 2020 at 02:12):

I have a strong feeling that Ryan is a bit overwhelmed with prep for tomorrow's "explain it all" day.

Dave deBronkart (Mar 11 2020 at 02:41):

Josh Mandel said:

I don't think the #CuresRuleONC has anything to say about the project CARIN and Carequality are undertaking together.

I agree - I got sloppy so I'll go back and edit out the Keith inquiry. Bad dog.

Josh Mandel (Mar 11 2020 at 02:42):

Now you've got me editing my history too. By the end, we'll have deleted everything ;-)

Dave Cassel (Mar 11 2020 at 18:49):

Hello all, please bear with any Zulip faux pas, as I’m new to the app and this forum. I know many of the folks weighing in here, but for those who don’t know me, I’m Carequality’s Executive Director and collaborated with Ryan on the blog post that originated this thread.

I’ve proposed to Ryan that a webinar on Carequality and consumer-driven health information access would probably be helpful. I won’t be able to address every question raised here briefly, but I can confirm that @Ricky Bloomfield does have it basically right.

To (sort of) address the question from @Josh Mandel about the role for Carequality’s existing support for query-based document exchange via SOAP-based IHE profiles, we do plan to leverage our existing services and processes, while also adapting to the different environment involved with FHIR-based exchange. I recognize that might sound wishy-washy. Operating in a FHIR-based, app-driven environment realistically will require some differences from our existing operations, but we’ll nonetheless try to reinvent the wheel as few times as possible.

Michele Mottini (Mar 11 2020 at 18:57):

What about a specs document instead?

Dave Cassel (Mar 11 2020 at 19:03):

Our FHIR-based exchange guide is still in draft form, and in two parts. You can find the technically-oriented portion here: https://docs.google.com/document/d/1iOour1orfMpYS30L2AU2wajZRXl7p6YWlk5F61TcZ1M/edit?ts=5d920fe0 (not quite sure of protocol for hyperlinks here so putting it in as plain text).

The policy-oriented portion is here: https://docs.google.com/document/d/1e-6sjXxze0kIndJ-ZRYQw0sY6LYa8KxlhPc1Ao71OpQ/edit

We have workgroups meeting to fully flesh out these drafts, generally on a weekly basis. They are open to anyone who wishes to participate, and to join you can email us at admin@carequality.org.

You will see that the technical portion is not a "FHIR spec". For the actual resources being accessed, we will point to existing specs developed by FHIR accelerators (or anyone else who develops a useful and cogent spec for a resource that is needed).

Michele Mottini (Mar 11 2020 at 19:21):

Thanks!

Michele Mottini (Mar 11 2020 at 19:21):

It appears not to be finished yet, am I right?

Dave Cassel (Mar 11 2020 at 19:44):

That's right, definitely still a draft and incomplete. There are technical and policy workgroups that are meeting to flesh it out fully, and they are open to all who are interested in participating.

Note that you can also check out our existing Query-Based Document Exchange Implementation Guide, which is complete and has been in production use for a long time. As the discussion above noted, however, there are some challenges for consumer access in that model, that we're addressing in the FHIR context. I'm happy to talk with anyone on the consumer side about participating in the doc exchange model, but if you're new to Carequality, it will probably make sense in most cases to focus on FHIR. We are aiming to have the FHIR guide complete and formally adopted for production use by the end of this year.

Josh Mandel (Mar 11 2020 at 20:00):

But looking at the following, it seems like Carequality might actually offer a consumer-facing "sign in and authorize apps" feature?

image.png

Josh Mandel (Mar 11 2020 at 20:00):

In this diagram, is Carequality playing the role of "EHR Auth Server"? So apps would be issuing queries not in "god mode," but rather using tokens scoped to one specific patient?

Josh Mandel (Mar 11 2020 at 20:01):

For this to work, I think it means Carequality taking on the identity-matching problem centrally... or somehow establishing how identity attributes would be tied back to the signed-in user, when a query gets sent.

Josh Mandel (Mar 11 2020 at 20:02):

Or would apps be working per:
image.png

... where they just get "god-mode" system-level access? I'm unclear from the doc, which presents a few different paradigms of connectivity.

Ryan Howells (Mar 11 2020 at 20:10):

Yes, @Dave deBronkart is right. Between preparing for today and reading/summarizing the rules, there's a lot going on!

I would agree with @Ricky Bloomfield and @Dave Cassel on what they've said. I would also add it's still a work in progress. It's one of the reasons we tried to be very careful in our wording when we said "will work to develop". Our goal (like we did with Blue Button) is to notify the industry early who is working on these issues and where they can go to dive in (e.g., HL7, CARIN, Carequality, etc.).

It's important to note the approach that is in the current Carequality documentation may or may not be what we finalize together over the next few months for the consumer app side. As with Carequality's work, our identity work is also open to anyone who would like to join. Please email me at ryan.howells@leavittpartners.com and we'll get you inserted in our workgroups.

Ryan Howells (Mar 11 2020 at 20:16):

From an ID federation perspective, we've had to go outside of health care and often outside of the U.S. to look for policy and technical models that work. Here are a few we are looking at in terms of models we think we can leverage (likely parts of these, not all):
EU - https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/Legislation+in+a+nutshell
Canada - https://diacc.ca/
GA Tech trustmark (not currently operational) - https://trustmark.gtri.gatech.edu/
Kantara - https://kantarainitiative.org/trustoperations/800-63-3/
Safe Identity - https://makeidentitysafe.com/

Bill Mehegan (Mar 12 2020 at 11:22):

@Josh Mandel
The diagrams you are referencing, at this point, are sets of ideas we're still kicking the tires on with respect how to approach authorization/authentication. Especially on the (patient facing) app side. That is why you see multiple paradigms of connectivity. In addition to those diagrams in the Google doc, there's comments/discussions on the different approaches being proposed. These discussions are ongoing and as we continue to meet & have Connectathons, we're getting closer to having definitive language on how to approach these workflows.

Adding @Luis Maas @Dennis Patterson, who are members of the Carequality FHIR Workgroup(s), and may offer additional technical insights to the thread.

In either case, as @Dave Cassel noted above - the FHIR Workgroups are still active and definitely open to anyone who wishes to participate. Please reach out to me directly if you're interested.

Josh Mandel (Mar 12 2020 at 13:35):

For any CARIN / Carequality workgroup conversations, please do add me to the list @Bill Mehegan .

Didi Davis (Mar 12 2020 at 16:18):

John Moehrke said:

carequality is not an enduser organization. It is a coordination organization of organzations. Each organization is strongly vetted before it is allowed into the network. There are rules of engagement... But once in, a SAML assertion from your organization is a token that is trustable as backed by that organization. I think they were looking to add a PHR as a participant, but don't know the status. Didi Davis ? Bill Mehegan ?
```Thank you for reaching out John Moehrke and Josh Mandel. Dave Cassel and Bill Mehegan are the "Authoritative" best persons to reply to Carequality related discussions since they are Carequality staff. While I am a subject matter expert that supports Carequality, I am happy to see their responses. Great discussion and we look forward to seeing this deployed in the "Real World" so patients and their caregivers can benefit!

John Moehrke (Mar 12 2020 at 16:24):

Glad some discussions have helped get people up-to-speed. The main problem is as @Josh Mandel said is that user-as-the-patient is new to the network, and thus the trust chain has not yet been woven. There is a real concern that adding user-as-the-patient might be maliciously abused, thus we need to be very careful to assure that security and privacy are designed into the system at the start. This could initially be modeled after the provider organizations, in that an organization vouches for the tenacity of the identity provisioning, and as such takes responsibility for any false claims that THEY issue (SAML Assertion). These organizations would likely be PHR organizations, but could be proxy bridges eventually.

Josh Mandel (Mar 12 2020 at 17:31):

And this could also be modeled as a system that passes verified identity claims on into (and through) the network, so relying parties could review for themselves (rather than having to take the app at its word; If you have to take a consumer app at its word, that's what I call "god mode")

John Moehrke (Mar 12 2020 at 17:31):

YES. exactly

John Moehrke (Mar 12 2020 at 17:32):

but first the PHR organizations need to be recongnized as authorative at patient identity claims as users... and building that trust is hard

Josh Mandel (Mar 12 2020 at 17:33):

I think PHR organizations don't and shouldn't need to be authoritative -- they can let patients bring in claims from elsewhere. For example in http://github.com/microsoft-healthcare-madison/did-spike/ we showed how a patient can prove that they have access to an existing EHR portal somewhere (i.e., verify FHIR API access + verify phone number, all automatically) and then turn that into a verifiable credential that can be presented to other providers, or to a network.

Josh Mandel (Mar 12 2020 at 17:34):

(To be clear, that was a one-week proof of concept, but we validated the approach, and thought it was a promising direction.)

Abbie Watson (Mar 12 2020 at 17:47):

That's vaguely what we were doing with the FhirBlocks project, but without blockchain. The project was also exploring Yubikey, 2FA, and some other authentication schemes. The stumbling block we ran into was the assumption (not mine) that Epic would simply update its servers to accept a sovereign ID (or DID in Josh's example) just because our pilot project asked them to. Since Meteor on FHIR (now Node on FHIR) can work as a proxy server, we implemented some basic sovereign/DID key signature generation on our own servers to prove the concept. But yeah... I would also lean toward the notion that distributed algorithms (with or without blockchain) can solve the problem in an ad-hoc manner.

Josh Mandel (Mar 12 2020 at 17:48):

The neat thing is that a trusted third party can generate the sovreign ID for now, and if/when the EHR vendors see value, they can start doing so directly

John Moehrke (Mar 12 2020 at 17:51):

trusted third part is what I was refering to.. just simplified it into the PHR vendor scope. The important part is that the identity provisioning must be fully trustable. The session authentication (2FA, etc) is secondary. Both are important, but one can have a wonderful strong session authentication while having zero trustable identity provisioning. Hence why NIST 800-63 has broken these out into two different vectors, with a third vector on federation claims. --- again, we do not need to invent standards, NIST has already defined these.

Dave deBronkart (Mar 12 2020 at 18:33):

Josh Mandel said:

If you have to take a consumer app at its word, that's what I call "god mode")

I have a feeling I need to understand this very well (where "I" is a proxy for "anyone who thinks like me and cares but doesn't thoroughly understand this trust stuff".) Your linked page makes my antennas say "Uh-oh there's something important here and I don't really get it yet."

Joel Schneider (Mar 12 2020 at 20:18):

iddqd -- had to go look that up after seeing all this talk of god mode

Didi Davis (Mar 13 2020 at 18:18):

John Moehrke said:

carequality is not an enduser organization. It is a coordination organization of organzations. Each organization is strongly vetted before it is allowed into the network. There are rules of engagement... But once in, a SAML assertion from your organization is a token that is trustable as backed by that organization. I think they were looking to add a PHR as a participant, but don't know the status. Didi Davis ? Bill Mehegan ?

@Dave Cassel and @Bill Mehegan are the most qualified to answer Carequality related questions on this forum. But yes, Carequality provides a trust framework to interconnect networks. Carequality provides the essential elements to enable exchange of health related information. Carequality has defined the common rules of the road (policy and governance framework to empower trust); well-defined technical specifications (can point to existing standards from Argonaut, DaVinci, etc but are well defined in one implementation guide) and Operational support for a directory of participants, technical security tokens and other required services. The current use case in production is the Query Based Document Exchange Implementation Guide (exchanging 90+ Million documents per month), but there are Push Notifications and FHIR Implementation Guides in development. Lastly, there are PHR implementers on Carequality today. For instance, OneRecord http://onerecord.com/ is one such PHR network. All workgroups are open to all to participate, just send an email to admin@carequality.org. Hope this helps.

Josh Mandel (Mar 15 2020 at 13:48):

I talk about OneRecord and PHRs generally in my "god mode" post. It doesn't seem like the right integration model to me, because consumer apps aren't generally trustworthy and accountable the way providers and other converted entities are.

John Moehrke (Mar 16 2020 at 12:43):

From a Security/Privacy perspective, the fundamental difference between an EHR and a PHR with regards to "god mode" is that a PHR is accessing a patient record onbehalf of that patient, with the data accessible on that PHR only by that patient. Yes the patient can then provide access to others, but it is a assignment action by that patient. Where as an EHR or clinical application requesting access to data is going to incorporate the results into the EHR (or clinical application) where role-based-access-control will allow others to access it for Treatment, Payment, and Operations. Under the treatment purposeOfUse the hope is that it is constrained to legitimate relationship (care Team) with appropriate 'safety' exceptions, etc. The reason is that once data has been used by a practicing clinician within an organization, then that data is part of the legal medical record of that organization. That organization has obligations they must uphold around medical records retention and health safety. Thus when a Treatment PurposeOfUse is asserted, it is not going to be limited to the USER making the request, it is a request on behalf of the ORGANIZATION, and the retention expectation would be for the life of the medical record retention at that organization and the future access controlled by that organization policies. Thus a access control decision to release for Treatment (which should explicitly include Payment and Operations; but often these are implied), must be made based on the ORGANIZATION requesting, not the USER. The USER should be recorded in audit logs, as the triggering user. These are NOT bright lines, they should be more bright than they are. But this is how I get to an understanding that an authorized Treatment PurposeOfUse is onBehalf of the organization requesting; where a Patient Request is onBehalf of THAT patient, not the PHR agent. Yes the PHR agent does need to be trusted, but that trust should be in the hands of the Patient, not in the hands of the custodian making the access control decision to release data. (Note Research and PublicHealth PurposeOfUse are closer to EHR than they are PHR; but I expect them to be project specific within that broad purposeOfUse)

Josh Mandel (Mar 16 2020 at 15:53):

Yes the PHR agent does need to be trusted, but that trust should be in the hands of the Patient, not in the hands of the custodian making the access control decision to release data.

Agreed 100%, @John Moehrke . For me this is the key point.

Bart Carlson (Mar 16 2020 at 16:09):

I totally agree with Josh's point.

Dave deBronkart (Mar 16 2020 at 21:32):

This may be the central point of ALL discussions about trust, yes?

Josh Mandel said:

Yes the PHR agent does need to be trusted, but that trust should be in the hands of the Patient, not in the hands of the custodian making the access control decision to release data.

Agreed 100%, John Moehrke . For me this is the key point.

And a key point of argument arises when paternalists say (as they always do) "But patients don't know what they're getting themselves into," "Patients can be talked into things that they don't understand," etc. Yes?

(Obviously my view is "If that's a problem let's fix it - don't keep everyone tied up in the back in car seats.")

Josh Mandel (Mar 16 2020 at 21:46):

There's a twist though: usually when we talk about making sure these decisions are "not in the hands of the custodian making the access control decision" the goal is to ensure these custodians can't prevent patient access. Here, the angle is to ensure that these custodians don't enable access on just the app's say-so.

Dave deBronkart (Mar 16 2020 at 21:50):

Totally agree, Josh! But how on earth could an app (a potential violator) be considered a custodian? Maybe I missed important things in the mega-paragraphs back there.

To be clear, given Facebook's transgressions in privacy in their Groups feature, and their being "too big to discipline," I consider it a certainty that someday some app will try to do that. The gray market for scurrilously acquired data, for use by scurrilous resellers, is too likely to be attractive. So though I'm no expert on security, this is a big deal to me.

Josh Mandel (Mar 16 2020 at 21:51):

Current assumption is that Carequality will define a trust framework that treats apps sort of like hospitals. So a custodian would say something like...

• "If Fakename Hospital issues a query, about Dave deB, I'll trust it and respond with his data."
• "If the Fakename PHR issues a query, about Dave deB, I'll trust it and respond with his data."

Josh Mandel (Mar 16 2020 at 21:52):

The custodian here is the data holder that says "I'll trust it and respond" (e.g., a health system participating in the a Carequality-compliant network)

Michele Mottini (Mar 16 2020 at 22:01):

I consider it a certainty that someday some app will try to do that

Not much that can be done about that

Dave deBronkart (Mar 16 2020 at 22:06):

Michele Mottini said:

Not much that can be done about that

You mean about preventing it? That's my point. But if you mean not much can be done to DEAL with it, that's what we're talking about, right? What CAN be done about it?

Michele Mottini (Mar 16 2020 at 22:11):

No, it is not what we are talking about here, what Josh is saying (and everyone agrees I think) is that app should not be trusted to do queries for data about anyone, but only for a specific patient at a time based on authorization granted by that specific person (that is the model currently used to connect to individual providers using SMART-on-FHIR)

Michele Mottini (Mar 16 2020 at 22:14):

This model does nothing to prevent malicious apps - once they convince a patient to grant access they have the data, that's the unavoidable trade off of trusting the patients

John Moehrke (Mar 17 2020 at 14:41):

Ultimately a custodian has the duty to deny access unless there is a reason to release information. The role of access control decision is to consider all the context (user, app, consent, business rules, etc). This all starts with the prime vector of the Purpose for which data are being asked for. A patient user can't ask for data under Treatment, that should be denied. But a Patient must be allowed access if they ask under Patient Requested purpose. A payer can't ask for data under Patient Requested. etc... This purpose vector not the ONLY factor, but is the prime differentiator. The important part is that data must not be exposed unless there is authorized access, AND that same rule is used by the patient to get their own damn data.
Two articles I have written yesterday and today
Patient vs Treatment purposeOfUse -- https://healthcaresecprivacy.blogspot.com/2020/03/custodian-access-control-decision.html
Public Health -- https://healthcaresecprivacy.blogspot.com/2020/03/public-health-is-purposeofuse-pubhlth.html

Brendan Keeler (Mar 17 2020 at 14:45):

I think the underlying question is - What prevents bad actors from lying about those attributes when querying?

John Moehrke (Mar 17 2020 at 15:40):

reality is ... trust fabric, which is usually a chain... and we all know the weakest link in a chain is the problem... Which a well designed access control decision will consider the veracity of each security token. Which is the point of NIST 800-63 three types of Level Of Assurance.

Dave deBronkart (Mar 17 2020 at 15:40):

Brendan Keeler said:

I think the underlying question is - What prevents bad actors from lying about those attributes when querying?

And that's trust in a nutshell, ain't it!

Ryan Howells (Mar 17 2020 at 15:48):

John Moehrke said:

reality is ... trust fabric, which is usually a chain... and we all know the weakest link in a chain is the problem... Which a well designed access control decision will consider the veracity of each security token. Which is the point of NIST 800-63 three types of Level Of Assurance.

Agree @John Moehrke and great discussion. It's why NIST 800-63 and digital identity is so important to this discussion. We need to know for sure the request is coming from the unique individual (using FIDO2 could help tie it to a unique carbon life form) rather than a rogue app, a service, or someone acting on the individual's behalf without their permission.

Again, we see the goal as creating a set of contractual provisions that could be built into Carequality that also require technical certification from trusted third-parties (e.g., Kantara, SAFE, etc.). The combination of both could be the foundation for building contractual and technical trust in the ecosystem so a patient could voluntarily use their own credential to authenticate across multiple orgs.

John Moehrke (Mar 17 2020 at 15:54):

Dave deBronkart said:

Brendan Keeler said:

I think the underlying question is - What prevents bad actors from lying about those attributes when querying?

And that's trust in a nutshell, ain't it!

Trust, yes... but not blind trust. Well designed security will enable appropriate and authorized access while forbidding inappropriate unauthorized access.

Dave deBronkart (Mar 17 2020 at 16:19):

Very good; trust should never be blind. Can we make that an axiom? Must trust always be earned, with eyes kept wide open (aka not blind)?

Luis Maas (Mar 19 2020 at 20:02):

As one of the authors working on the Draft Carequality FHIR technical IG linked above by @Dave Cassel , I have found this thread very interesting and have a few comments to add for feedback.

1. The patient access use case goes well beyond simple federation of identity, because each digital identity also needs to be accurately matched to an actual patient in medical records. This is implicit in the issuance of patient portal credentials at a particular site, but not when the identity provider function is performed by a different party. There is also an interplay between identity proofing practices and patient matching. If patient matching is based upon trusted identity attributes linked to a credential (and nothing else), then the assurance level of the initial identity proofing sets an upper bound on the certainty that the user holding the credential is actually the subject of the matching patient record.
2. "God" mode is not the only approach being considered by Carequality. Authorization code flow is also part of the current draft. @Josh Mandel mentioned bringing in identity claims from elsewhere. This powerful concept expands access and obviates the need for site-by-site patient portal credentials. To this end, we are also considering UDAP Tiered OAuth, a workflow that is also included in the current draft of the CARIN BB IG. Tiered OAuth allows the user/app to indicate its preferred, trusted OIDC identity provider as part of OAuth 2.0 authorization code flow. Back-channel communication of verified identity attributes is used to increase security. The data holder can request only the information it needs to achieve the required matching confidence and the user/patient gets greater control over what attributes may be shared. If it makes sense for the use case, validation of identity attributes could also leverage privacy-preserving techniques to further enhance privacy. Since it builds on the authorization code flow, it also provides an opportunity for the data holder to interact with the user directly, not just for authorization purposes, but also when the identity cannot be resolved to a specific patient based on the available attributes.
3. Note that the trusted identity providers could be other data holders (e.g. providers or payers) on the network or standalone entities, as long as they follow the network policy. For example, a patient could use credentials from Hospital A and the client app of their choice to request data from Hospital C. They can even do this without sharing any identity information with the client app.
4. I agree that making any of these approaches (especially "god" mode) work for patient access use cases is dependent on, among other things, being able to trust the identity claims regarding the patient to be matched and the authority of the app to request the patient's data. Creating this trust requires both a policy framework that provides sufficient assurance that operational practices of the participants follow the rules and the technical capabilities to communicate the necessary identity attributes. Carequality is working on both.

Josh Mandel (Mar 19 2020 at 20:17):

Thanks Luis for the detailed and thoughtful response!

Dave deBronkart (Mar 20 2020 at 01:38):

Man, that's a webinar in a single Zulip message. Thanks.

In fact it would be fascinating to see all those words represented in illustrations. Brilliantly CLEAR illustrations, not contorted spaghetti. :slight_smile:

John Moehrke (Mar 20 2020 at 12:38):

excellent clarity by Lois, as I always find to be true... There is an augmentation of ( 2 ) where provisioning flows happen to bind a user provided identity to a healthcare organization patient identity. The common method of using postal mail with a secret code is likely to continue to be dominant, and has the advantage of being able to leverage postal mail fraud against any malicious use of the contents of the letter. postal fraud is one of the strongest fraud mechanisms USA has. The advantage of this is that the binding strength can be much higher than hoping to match personal traits, especially since personal traits are leaked all over the place.

John Moehrke (Mar 20 2020 at 12:42):

I am not sure I would agree with the clause in ( 2 ) where the identity holder can choose which subset of their personal traits are shared for identity verification. a malicious individual could use this to get as weak of a binding as possible.

The data holder can request only the information it needs to achieve the required matching confidence and the user/patient gets greater control over what attributes may be shared. If it makes sense for the use case, validation of identity attributes could also leverage privacy-preserving techniques to further enhance privacy.
I guess a data holder could set the bar very high, but then that defeats the feature being described as privacy preserving... privacy preserving seems unnecessary in light of the request for highly sensitive medical data that the data holder already has (presumably).

Brendan Keeler (Mar 24 2020 at 03:09):

Wow :clap::clap::clap:

---

Last updated: Apr 12 2022 at 19:14 UTC