Meaningful Use 3 is requiring health systems to provide API level access to applications authorized by patients. Most health systems and vendors are choosing FHIR® as the vehicle for that API, but many of those health systems upgrading their EMRs are unaware of these capabilities. Of those who are familiar with the features, some are concerned about what this means for their data security while others are embracing this change as an opportunity to create patient centric applications.
Most health systems that are going live with MU3 are on EPIC, though Cerner and others will be soon to follow. 1upHealth is working with providers to test their EPIC upgrades against our patient app covering various perspectives--from those who are wary about data security to those who upgraded just to enable this API. In all cases, we believe the best tech tests before launching. So we will test your epic install on our platform and patient app for FREE :). If you're interested, contact us at firstname.lastname@example.org
Currently, about 25 health systems are live on EPIC with FHIR API capabilities. Some of those health systems have reached out to us already to test. However, we're integrated with all of them and can get data given patient authorization. That's what became possible via MU3. For patient apps, the trigger to gain access to data is via patient choice, and therefore legally requires no HIPAA (though 1upHealth is HIPAA compliant and uses all the precautions to store data securely). Security is as important as ever, there's no way for us to gain access to a patient's data without their password protected approval.
Data is just as secure as it was before on your health system. There is now one additional avenue with which patients can share their data with an application. That's basically the only change. Health systems may be confused about the lack of BAA in this case, because, traditionally, data from health system to application is supported via a BAA. But in this case the patient is authorizing access. Patient consented sharing never required a BAA. For example 1upHealth supports all EPIC systems without a BAA between any of our supported systems. This doc on the HHS site does a good job about detailing our use case as a non-covered-entity PHR which is gaining disclosure to PHI via an individual's authorization (Read after page 7 section PHRS NOT OFFERED BY HIPAA COVERED ENTITIES). This section below contains some legalese around patient consented apps.
"Some PHRs fall outside the scope of the Privacy Rule because they are not offered by covered entities... Although some of these PHRs may advertise that they are “HIPAA-compliant,” the Privacy Rule does not apply to or protect the health information within these PHRs. These PHRs are governed by the privacy policies and practices of the entities offering or administering the PHRs, as well as by any other applicable laws. ... The Privacy Rule permits a covered entity to disclose an individual’s PHI to a third party with the individual’s written authorization. See 45 C.F.R. § 164.508. Thus, in cases where the entity offering the PHR is able to or has agreed to input information directly into the PHR for the individual, a covered entity is permitted to disclose PHI about the individual directly to the entity administering the PHR if the covered entity has a written authorization from the individual for the disclosure."
We're here to help. Testing your MU3 Compliant EMR before going live can help assuage concerns about the patient directed flow of health data. You can use your experience to educate patients on which apps can be trusted. You can also begin prototyping FHIR apps of your own that can consume data from the patient side or internally with full access to your patients data. Testing is obviously good for us too, as it validates our data integration with your health system. If you want help with any of this, drop us a line at email@example.com.