Stream: social
Topic: Epic's CEO is urging hospital customers to oppose rules [..]
Dave deBronkart (Jan 23 2020 at 16:56):
Many people are messaging me on this busy day to get my comments on Judy Faulkner's letter to her hospital customers urging that data not be shared. I don't have time to blog so I tweeted this and a few more:
https://twitter.com/ePatientDave/status/1220387893669179393
Everyone's asking me what I think of Faulkner's disgraceful, disingenuous, fake-paternal letter. Today's a busy work / conference / travel day but this is it in one image. https://twitter.com/MightyCasey/status/1042157140801212416
- Dave deBronkart (@ePatientDave) Dave deBronkart (Jan 23 2020 at 21:27):
This seems to be a good "fact vs fiction" blog post about Faulkner's letter, from Darena Solutions, who I'd never heard of.
https://www.darenasolutions.com/blog/epics-letter-to-hhs-facts-vs-fiction
Vassil Peytchev (Jan 23 2020 at 21:43):
Just to clarify, step 4 in the 7-step process described in the article does not exist in this form in the proposed rule. The EHR is not allowed to impose any requirements on the app chosen by the patient, much less to "approve" it...
Michele Mottini (Jan 23 2020 at 22:30):
Yep, not so factual facts
Grahame Grieve (Jan 24 2020 at 21:03):
step 4 exists in reality in practice - the app must be registered per smart on fhir. The rule says that there's no choice about it, but in practice, that choice exists and is a blocking step for many apps
Dave deBronkart (Jan 24 2020 at 22:01):
The rule says that there's no choice about it, but in practice, that choice exists and is a blocking step for many apps
But this is a PROPOSED rule, yes?
For those who want to be careful about slippery loopholes, this seems to be an important point, so I'll ask "as if stupid" questions.
- Desana's post says this 7-step process is "How this is supposed to work." It doesn't say whether this is "supposed to work" in the proposed rule or today. Which?
- @Vassil Peytchev says step 4 doesn't exist in the proposed rule: "patient downloads a third-party app that is approved by the EHR to connect to the API."
- @Grahame Grieve says "The rule says that there's no choice about it, but in practice, that choice exists "
Am I correct in thinking this is confusing? And which is the "choice / no-choice" aspect - approval by the EHR?
Michele Mottini (Jan 24 2020 at 23:17):
Yes, step 4 exists in reality - but it should not really exist, and it does _not exists for providers using Epic_, Epic being the only vendor that does not require additional steps to access their API
Michele Mottini (Jan 24 2020 at 23:18):
The choice / no choice is approval of the app by the provider (health system)
Michele Mottini (Jan 24 2020 at 23:19):
The rules that are currently in effect say that if a patient want to access his / her data with app X the health system should connect that app
Michele Mottini (Jan 24 2020 at 23:19):
But in practice that does not happen
Grahame Grieve (Jan 24 2020 at 23:29):
It does _not exists for providers using Epic_
I believe that this is not strictly true - institutions using Epic can black list apps, while institutions using Cerner have to white list apps. In either case, they can't be bothered
Michele Mottini (Jan 24 2020 at 23:32):
Yes, they can blacklist, but by default they work (for Epic). For everyone else they have to be white-listed (and in some case registered) manually
dsh (Jan 24 2020 at 23:53):
This may be true for Patient centric app, where the end user Patient has access to their own data, but for Practitioner centric apps the registration & approval is pretty onerous both technically and financially (very expensive for startups).
Tillmann Int-Veen (Jan 25 2020 at 10:07):
Incredible!
Yunwei Wang (Jan 25 2020 at 17:34):
Yes, step 4 exists in reality - but it should not really exist, and it does _not exists for providers using Epic_, Epic being the only vendor that does not require additional steps to access their API
That is not exactly true for 3rd party app. Epic AppOrchard has 3rd party app approval process. Though not very complicated, a 3rd party app does need approved by Epic AppOrchard in order to be listed and pushed to providers' system.
Michele Mottini (Jan 25 2020 at 18:03):
We are talking about approval by the provider
Michele Mottini (Jan 25 2020 at 18:04):
and you don’t need app orchard for patient apps
Dave deBronkart (Jan 26 2020 at 17:51):
Just for the record, my beloved experts, this is thoroughly confusing, so for anyone who's interested in FUD, this is a happy place.
For me, well, I'm not sure which wall to brace myself against as I try to push forcefully for good decisions.
Adam Flinton (Jan 27 2020 at 08:38):
Authentication vs authorization is a fun area. Oauth is just the start as in the uk we then have roles the person is acting in (e.g. person logged in as admin may not be able to get data same person logged in as clinician may) etc.etc. Does the person then have the specific perms for that actual record etc.etc.etc. This then ties into the NHS RBAC codes & if the person has a smartcard inserted etc.etc. We found nothing off the shelf that would do what we wanted & have had to assemble from existing pieces to even come close.
Grahame Grieve (Jan 29 2020 at 20:41):
from Adrian Gropper's comments on this:
My pleas to the SMART and HL7 designers to enable patient-directed access were and still are quietly ignored
That's not my understanding. Adrian asked us to enforce it, not enable it. Enforcing things is ONC business, not HL7 business, so we did ignore it (well, we did explain...).
If there's something we're not to 'enable' it that we should in the standards, I don't know what it is. But I'd like to know....
Grahame Grieve (Jan 29 2020 at 20:41):
source: https://thehealthcareblog.com/blog/2020/01/29/strategic-interests-and-the-onc-annual-meeting/
Virginia Lorenzi (Jan 30 2020 at 01:18):
Ok I will bite. There is nothing in SMART on FHIR that requires an EHR to be what is interacted with. You just have to be a server that follows the smart profiles. Putting it on top of EHRs was their main use case but it could go on top of a lab system or on top of a patient's own server, a patient registry servr or a mobile device's server etc.
Grahame Grieve (Feb 02 2020 at 23:09):
HIPAA covered entities. You aren’t one if you don’t bill electronically
from https://histalk2.com/2020/02/02/monday-morning-update-2-3-20/
I did not know that
Michael Donnelly (Feb 03 2020 at 23:41):
Just for the record, my beloved experts, this is thoroughly confusing, so for anyone who's interested in FUD, this is a happy place.
A lot of the confusion, I believe, is that some people are talking about apps that will be used by a patient and other people are talking about apps that will be used by a clinician. Meaningful Use stage 3 had rules about the apps a patient uses to get access to his or her own data - which I believe is what you're particularly interested in, @Dave deBronkart.
@Michele Mottini is correct above; when the developer of a patient-facing app wants that app to work with Epic, there's nothing that Epic or any org using Epic (in the US) needs to do to make it work.
- The app developer (who could be the patient themself) goes to https://open.epic.com and creates a record for the app.
- Epic doesn't do anything.
- Health care orgs using epic don't do anything.
- An automatic job runs at the health care provider every few hours and downloads all the new client records.
- The app works.
@Grahame Grieve is also correct that the provider can blacklist apps and is also correct that they don't frequently proactively block applications.
Michael Donnelly (Feb 03 2020 at 23:47):
To be even more concise, in Epic there is no vendor or provider approval process. Making an app available to patients is entirely in the app developer's control.
The only person who needs to approve a patient-facing app to get that patient's data from Epic is the patient him- or herself.
Brendan Keeler (Feb 04 2020 at 04:40):
Can confirm that, which is what made the initial letter, posting on the main site, and subsequent media response a little frustrating.
Epic is quite honestly doing quite well (leading) compared to other vendors between the three headed approach of open.epic.com, USCDI.epic.com, and App Orchard (as well as an extremely robust catalogue of traditional interfaces), but general external sentiment and goodwill is a little tainted by the messaging and associated perception.
Last updated: Apr 12 2022 at 19:14 UTC
