Stream: implementers
Topic: Epic API Registration
Beltran Figueroa (May 04 2019 at 02:09):
Hey everyone, I've noticed that upon registering an app with Epic to obtain a client ID and secret for the first time, Epic requires compliance with ONC Health IT Certification Criteria, which include things like:
• You may not share the data collected by your App with any third party without notifying the healthcare organization where the data originated.
• Your app will provide FHIR API-based Access to any data you and your App collect or derive to your users.
• Development of your App must be documented and managed in a Quality Management System (QMS) and complaints and defects reported about your App must be managed in a complaint tracking system.
CMS' Promoting Interoperability Program Stage 3 requires that by 2019 eligible hospitals/providers:
• Fully implement API functionality, such that any application chosen by a patient would enable the patient to gain access to their individual health information provided the application is configured to meet the technical specifications of the API.
• May not prohibit patients from using any application, including third-party applications, which meet the technical
specifications of the API, including the security requirements of the API.
As far as I know, an app cannot gain access to an Epic-based EHR's API without registering first in Epic. I'm not an attorney, but requiring ONC Certification would make providers whose APIs depend on Epic for registration non-compliant because the criteria I listed at the beginning have nothing to do with the API's security or technical specifications.
Another thing that comes to mind is HIPAA's Privacy Rule, which requires a covered entity to provide the individual with access to its PHI in the form and format requested, if readily producible in that form and format. In this case, providers already have a perfectly functioning API capable of transmitting PHI, but Epic's ONC certification requirement could be seen as limiting the individual's right of access to it, which is illegal.
I would like to know what the FHIR community thinks about this, especially those of you who are developing consumer apps in the U.S. and are non-covered entities as defined by HIPAA.
Josh Mandel (May 04 2019 at 02:22):
I've always found this language puzzling, because it seems to assume that client applications would for some reason be exposing data as servers (i.e., Epic seems to be imposing on client apps the same obligations that ONC imposes on certified EHRs, which I find puzzling). I've personally clicked through the agreement in the past because it was the only way for me to get my own FHIR data from MyChart.
Grahame Grieve (May 04 2019 at 07:52):
@Michael Donnelly
Michael Donnelly (May 04 2019 at 08:36):
I'm not a lawyer, and I didn't work on that wording, so I can't give a detailed answer. I do know that:
- Epic is certified for Meaningful Use, so the certifiers (who've recertified several Epic versions since 2015) aren't concerned with Epic's interpretation of the rule.
- The developer of a client application has to attest to certain things when creating a client record for his or her app, but this isn't a registration process. The client record doesn't need to be approved, isn't reviewed by anyone from Epic (or anywhere else), and is automatically deployed to Epic's customers within hours of its creation.
- Epic's primary motivation for collecting information and attestations when a developer creates a client record is to do our best to protect patients' privacy while complying with regulations.
Again, I will not be able to debate the specifics of the language on open.epic, I'm just sharing the intent behind it.
Stefan Lang (May 04 2019 at 22:31):
(deleted)
Brendan Keeler (May 05 2019 at 17:21):
I for one find open.epic.com to be reasonable and straightforward, especially when compared with other vendors' processes and tools. There are definitely worse/more restrictive.
Last updated: Apr 12 2022 at 19:14 UTC
