Stream: patient empowerment
Topic: patient app registration-who's misinformed at the ONC Forum?
Isaac Vetter (Aug 11 2020 at 20:10):
@John Moehrke , @Ryan Howells - yesterday and today, in two different ONC Tech Forum sessions, you both, independently stated that either health system or EHR vendor approval was always or typically a requirement for a patient to authorize an app to access their common clinical data. John, you clarified in response to my question that there were exceptions to this.
Around 2015, at Epic, we deployed the technology to allow an app developer to (manually) register an app and for a patient to use that app with no vetting, and automatically within 12 hours. Every organization using Epic to certify for MU3 has this functionality turned on; most for many years. Again, here's the list. Again, as designed there is no app store validation, nor health system review.
Am I misinformed? Are health systems using Epic vetting patient apps? Is Epic alone in not vetting? If so, is it still accurate to state or imply that a vetting process is always required?
I'm concerned that my point of view is out of touch with the state of patient apps -- it's definitely different from yours. Could you inform me, please?
Jenni Syed (Aug 11 2020 at 20:24):
We (Cerner) currently have the provider ask us to enable the app at a site, but this is something we are changing. We do not require any "vetting" or "validation" of patient apps.
Jenni Syed (Aug 11 2020 at 20:26):
We've also had app devs reach out about specific sites to be enabled themselves
Dave deBronkart (Aug 11 2020 at 20:27):
And here we discover that Zulip converts animated GIFs to PNGs. Well, you know what an eager spectator looks like when munching popcorn...
image.png
Michele Mottini (Aug 11 2020 at 20:44):
eClinicalWorks and NextGen have no provider vetting as well (they can have the API completely disabled though)
Michele Mottini (Aug 11 2020 at 20:45):
Allscripts has no provider vetting as well (but you don't know the end points)
John Moehrke (Aug 11 2020 at 20:53):
I have no knowledge. I was just playing my role as a moderator... Allowing my panelists to shine...
John Moehrke (Aug 11 2020 at 20:54):
@Dave deBronkart I think you might be the best to answer the question. We have three EHR vendors that have said they fundimentally allow patients to bring ANY app to the patient specific API... so, what is the Patient Experience?
John Moehrke (Aug 11 2020 at 20:55):
I presume that there was already broad support for patient provisioned apps, as regulation is now demanding it and regulation demands don't tend to kick in until there is some already able to be conformant.
Dave deBronkart (Aug 11 2020 at 20:55):
You're reading my mind: I'll do a social media outreach and see what people say in response. After this meeting I'll draft a quick post.
John Moehrke (Aug 11 2020 at 20:55):
so now... I sit and munch popcorn awaiting the reality
Brendan Keeler (Aug 11 2020 at 21:00):
My exprience has been in line with Michele's.
Epic is no vetting (aside from out-of-band/non-dynamic app reg) and easily accessible endpoint list.
Other EHR vendors either have a less accessible endpoint list and/or provider vetting.
@Isaac Vetter with the switch from open.epic.com to fhir.epic.com, is this still the case for patient apps? When there was uscdi.epic.com vs open.epic.com, the divide in process was clear (open access for patient apps, lightweight approval for USCDI). Now, less so.
Isaac Vetter (Aug 11 2020 at 21:07):
First, John, Ryan -- I apologize for coming off as antagonistic -- that's really not my intent (although I did get a bit passionate, in my spare bedroom cum home office cum echo chamber of one, during your sessions!) Without expertise in this space, I'd have learned over the past two days that vetting is a requirement for a patient app. I absolutely, really, want to know if that's true! Similarly, I want you (and our community) to know if it's not.
Michele Mottini (Aug 11 2020 at 21:08):
And to be clear: yes, we registered our app at open.epic.com, it was never vetted and it can connect to all Epic listed providers
Isaac Vetter (Aug 11 2020 at 21:22):
Hey @Brendan Keeler - yeah, great question. The majority of feedback we got was that the different sites were confusing (especially when you throw in App Orchard). We're still working at unifying open.epic.com and fhir.epic.com to make it feel like they're the same thing. Note that DSTU2 CCDS patient app registration/deployment/management is still occurring on open.epic.com. We do intend to migrate this to the fhir.epic.com site, at which point all the same functionality will still be present (no vetting for patient apps).
Brendan Keeler (Aug 11 2020 at 22:08):
Yeah I saw the open.epic.com stuff was still up but definitely points to FHIR.epic.com as the future. Given the latter is a bit light on patient app details (how registration will work, which APIs are available for patient apps, etc) I wasn't sure if it indicated a switch to more APIs available for patient apps, but a vetting process (or provider approval step)
Brendan Keeler (Aug 11 2020 at 22:08):
Thanks for the clarification
Ryan Howells (Aug 12 2020 at 00:02):
Hey @Isaac Vetter. Thanks for the great set of questions! I didn't take it the wrong way at all. Vetting is not a 'requirement' for a patient app, but some apps do feel as though they are 'getting vetted' by some EHR vendors because of the difficulty they are still having in getting connected. Let me explain. . .
First, as I mentioned to @Janet Campbell (Epic) a year or two ago at an ONC event in some random hotel hallway, our app community has been united and effusive in our praise for Epic's app registration approach. We've made clear publicly, multiple times we wish more folks would follow a similar approach. In fact on our website, you can read our ONC comments which outlines on p.13 an app registration process that largely resembles what you guys are doing. https://www.carinalliance.com/wp-content/uploads/2019/06/CARIN_ONC-CURES-Information-Blocking-Comment-FINAL.pdf Maybe I can send a few payers your way so you can explain to them how you set-up your registration process. ;) As was discussed in the thread above, eCW and NextGen also deserve praise for their approaches.
In my comments today, I was trying to explain (not well, obviously) there isn't a consistent approach for how consumer-facing apps register when you look across all of the EHR vendors. Meditech, Athena, and Allscripts are almost there but it's not a streamlined approach. As @Jenni Syed mentioned Cerner isn't there yet, but they did provide a verbal commitment to us even before the final rule came out their desire to change. The challenge apps face with Cerner is the apps need to ask each provider their permission for Cerner to turn on their end point which is one of the reasons a FHIR SPOC would be helpful. I'm sure the ONC final rule will help in that discussion. GE is very hard. The app community feels like they are are using a very custom approach. For the other smaller EHRs, many of them don't yet have an online registration process and/or there are a few examples where the authentication flow isn't working well. Then, there's the issue of providers who don't have a portal. . . . which is still an issue that exists out there.
Look, we know everyone is trying their best and wants to do the right thing. It will take some time and certainly won't happen overnight but I do believe the EHR vendors as a whole are actively moving in the right direction. Now, we need to explain to the 900+ CMS payers and 57 states and territories why they can't 'vet' a consumer-facing app. I'm expecting that to be a much more difficult conversation. . . we are always open to having some help!
John Moehrke (Aug 12 2020 at 00:12):
@Isaac Vetter I felt no harm. I love it. I tried to get you on the panel. I think the Payers are the newbe that needs advice.
Debi Willis (Aug 12 2020 at 01:09):
We found many different flavors and workflows around how easy it is for patients to use any app of their choice. We work with all the big EHR players and the process spans from “very easy” for Epic, eCW, and NextGen to “very hard” with (formerly) GE and impossible with Athena. The difficulty is mostly on the app developer side to jump through all the hoops and gather all the different types of information for the more difficult EHR vendors. It’s still very very difficult for patients to get access to their data using the app of their choice if their app is not connected to the clinic. We try to help them by explaining how to request the health org connect with us. And we also reach out to the health org if we can figure out who to contact. There’s a big black hole there. Sometimes the health org simply doesn’t respond to the patient. Most of the time they don’t respond to us. Sometimes their response is “We are already connected to Apple and we don’t want to connect to any other application.” I think it’s getting better. Or maybe we are just getting better at doing back flips over multiple hurdles while trying to help the patients that reach out to us. It’s an Olympic exercise. And also a real labor of love. We know how important it is for patients to be able to gather and aggregate their data into one place where they can see and understand it all. Sometimes it’s a matter of life or death. And that’s worth the effort it takes to keep moving forward to make this an easier process. I really do think the EHR vendors are trying hard to make this happen. We are so much further today than we were two and three years ago. And two or three years from now, things will be much better also.
Dave deBronkart (Aug 12 2020 at 01:16):
Well! After Debi's response, are the waters clearer, so that there's no need to send out a public appeal?
Another possibility would be to summarize and blog the above (with plenty of verbatims), and ask people to respond with their experiences. Shall we? I'll need a fact-checker or some such, from this thread, to make sure I'm asking the right things.
I'm hoping that whatever we end up learning, ONC buddy @Steve Posnack will help spread the word as appropriate.
Debi Willis (Aug 12 2020 at 03:38):
@Dave deBronkart , I’m happy to help in anyway I can. I sent a grid earlier to Ryan Howells to identify how the different EHRs handle onboarding an app and the hoops we sometimes need to jump through for some of them. I’ll send that to you and then we can schedule some time to chat on the phone. I would love to congratulate the ones that are doing a great job and encourage the laggers to work with the FHIR community to come up with better workflows. I believe there are many patients who choose providers partially based on how easy it is to get their information from them. Solving this problem will be a win for everyone.
Jennifer Blumenthal (Aug 12 2020 at 13:49):
Hi @Ryan Howells ,
Here is our general experience for open developer environments. The problem is essentially endpoint discovery and whitelisting. Please note that not all vendors are included below. However, OneRecord is patiently waiting for ALL endpoints to be published by ALL vendors with no whitelisting :)
Epic: You get a single set of creds (client ID and secret) to connect to all Epic sites. All endpoints published. ( This is the easiest method for patient-facing apps.)
Cerner: You get a single set of creds (client ID and secret) to connect to all Cerner sites (like Epic) BUT whitelisting is required.
eCW: You get a single set of creds (client ID and secret) to connect to all eCW sites (Like Cerner) BUT whitelisting is required.
Allscripts: You get different creds (client ID and secret) for each client to connect to Allscripts sites AND whitelisting is required.
Meditech: You get different creds (client ID and secret) for each client to connect to Meditech sites (like Allscripts) AND whitelisting is required.
NextGen: You get different creds (client ID and secret) for each client to connect to NextGen sites AND whitelisting is required.
Athena: To date does not support 3 Legged OAUTH
Ultimately you are going to see some sort of configuration that follows the patterns above and as @Debi Willis said "it’s an Olympic exercise" to find the right stakeholder to get whitelisted...even at the patient request.
cc: @Steve Posnack and @Dave deBronkart
Josh Mandel (Aug 12 2020 at 13:53):
I think this is clear to everyone here, but for the record: "whitelisting" presents basically an impossible barrier in its current form. At least if you are a developer with no specific relationship to the organizations that need to whitelist you. In most cases you can't even figure out the right point of contact. if you can find a point of contact, either it is a worthless administrative exercise because they have no choice but to add you to the whitelist; or the organization practices some kind of vetting by refusing to add you to the whitelist.
Jennifer Blumenthal (Aug 12 2020 at 13:55):
I second @Josh Mandel comment above. This is the best description of production environments today.
John Moehrke (Aug 12 2020 at 14:16):
so it is not a technical problem, it is a policy problem... which is why regulation is the tool to unlock that policy... Hence why we now have clarification that the patient MUST be allowed to bring third party apps. It is no longer a policy choice the Provider and Payer organizations can chose.
Jenni Syed (Aug 12 2020 at 14:18):
Yes, we understand the challenges, and have been working over on doing a major overhaul of our ecosystem and sandbox this year in order to get to more of a denylist instead of an enablelist for patient apps.
John Moehrke (Aug 12 2020 at 14:18):
The interesting lesson-we-need-to-learn, is why has Providers using Epic more readily been open. There must be some lesson we can use. Some way they present this to their Provider organiations that makes it "easy" to have open arms.
John Moehrke (Aug 12 2020 at 14:19):
is a Deny list available in all the platforms? (like the move to Permit/Deny terminology)
John Moehrke (Aug 12 2020 at 15:13):
could someone look at the FHIR Security and Privacy page; and recommend some new text that would explain the current approach? I suspect that these pages are not leading the audience to the right understanding of openness. At least, I am looking for improvements.
Cooper Thompson (Aug 12 2020 at 15:22):
Honestly, I don't think the folks that make policy decisions on open vs. not open spend any time at all looking at the FHIR spec. Let alone the Security and Privacy page.
John Moehrke (Aug 12 2020 at 15:35):
fair... but I am always looking to make it better
John Moehrke (Aug 12 2020 at 15:37):
Just noticing https://www.hl7.org/events/fhir/implementation/2020/
Good opportunity to channel this openness message.
Debi Willis (Aug 12 2020 at 16:54):
I don't think it is entirely a policy problem. It is a workflow problem. Perhaps a better way might be to say it is a lack of enforcing the part of the policy that ensures there are no barriers to patients getting their data "without special effort". We are moving in the right direction (and thrilled to hear from EHR vendors who are going to change the process to make it easier). When a patient uses a FHIR app to get their data, that app is representing the patient who wants access to their data. A barrier to the app developer is also a barrier to the patient. I don't think some EHR vendors really understood it that way. But, in a patient's view...that is the case.
Josh Mandel (Aug 12 2020 at 18:39):
Agreed Debi; the right technical defaults make the (practical) policy problem disappear.
Brendan Keeler (Aug 13 2020 at 23:58):
UCSF should refocus Interopselect around patient auth connectivity experiences
Brendan Keeler (Aug 13 2020 at 23:59):
For what it's worth, I imagine a variety of patient apps using a data aggregator like Apple, 1up or Human API in between for value add services, so we may be overstating the issue a bit, assuming those get whitelisted
Last updated: Apr 12 2022 at 19:14 UTC
