It is imperative that we support the interoperability components of Meaningful Use Stage 3. The promise of reform to justify our massive investment in MU must be supported by broad, patient-centered interoperability mandates so that “data follows the patient”. The Stage 3 API requirement will be the centerpiece of interoperability because only patient-directed exchange can solve the challenges of patient matching and governance as described in the recent General Accounting Office report.
The Stage 3 API requirement will serve both patients and providers by enabling patients to delegate access to their records on the API to anyone, including apps, providers, and other EHRs. The vision for how this will happen is taking place in two workgroups: the OpenID Foundation Health Relationship Trust (HEART) and ONC’s API Task Force.
How this will work is the subject of a HEART use-case titled Elderly Mom with Family Caregiver. Based on the Kantara User Managed Access (UMA) and the HL7 FHIR standards, HEART profiles for healthcare are the foundation for broad interoperability and improved cybersecurity.
The HEART use-case demonstrates the following in the Meaningful Use setting:
1. An elder visits a new primary care provider (PCP) and introduces her daughter as caregiver and custodian
2. The custodian is given access to the EHR patient portal with the MU3 API
3. The custodian enters an email address to enable the EHR to discover the location of mom’s UMA Authorization Server
4. The custodian is presented a HIPAA Release of Information form and clicks OK.
5. The EHR now has access to mom’s PHR and her Medicare account through BlueButton on FHIR.
-
Now, as mom’s PCP uses the EHR she can see the out-of-pocket costs based on mom’s actual co-pays and the Authorization Server can notify the daughter of updates to mom’s MU Common Clinical Data Set, her PHR, and her Medicare claims.
The highlights above, entering an email address and approving a HIPAA release are the essence of the HEART user experience. This is patient-directed exchange, where modern Internet and secure cryptographic protocols allow the patient to tell her various providers the address of her Authorization Server. The health information exchange Authorization Server could be anywhere, including a personal HIE of One or built-in to a PHR. The legal basis for allowing the patient to specify the Authorization Server is the HIPAA “patient right of access” as described in this 2013 memo from the Office for Civil Rights.
The MU3 API and HEART patient-directed exchange solve a number of difficult interoperability challenges as described in the GAO report. Patient matching is no longer a problem when the patient herself is linking provider and payer APIs to the same Authorization Server account. Governance of trust relationships across providers, state lines, family caregivers, and PHRs is no longer an issue because data flows under the HIPAA patient right of access. Information blocking is eliminated because the HEART standards allow data to flow directly from EHR-to-EHR without the loss of provenance, delay, and cost of a detour through a PHR or health information exchange database. Security is much improved because the HEART protocols use modern public-key cryptography and because the patient is notified of access to their APIs by the Authorization Server.
ONC head Karen DeSalvo recently announced that interoperability would advance significantly in 2016 and skeptics wondered how a decade of interoperability challenges could end so quickly. The answer could be a new approach based on patient-directed exchange under the HIPAA patient right of access. This is what the Stage 3 API is all about. You can add a comment through December 15, then join the HEART workgroup and get on board.
Categories: Uncategorized
…and here is a typical paragraph from the Certification Companion Guides
“• Security:
o Our intention is to encourage dynamic registration (e.g., OAuth 2.0 Connect Dynamic
Client Registration Protocol) and strongly believe that registration should not be used as a means to block information sharing via APIs. That is, applications should not be required to pre-register (or be approved in advance) with the provider or their Health IT Module developer before being allowed to access the API. Under the 2015 Edition privacy and security (P&S) certification framework, health IT certified to the API criteria must support an application connecting to the API.”
There’s nothing I see in the Guides that suggests “known entities” or “communities of trust” are required to meet the security requirements.
Hi Mark!
The Stage 3 regulations https://www.federalregister.gov/articles/2015/10/16/2015-25595/medicare-and-medicaid-programs-electronic-health-record-incentive-program-stage-3-and-modifications include this guidance:
“Providers 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.”
I would interpret this to mean that even a FHIR app with a self-signed certificate would be acceptable for BlueButton on FHIR access. After all, regular BlueButton doesn’t require “known entities” or “communities of trust” and the information blocking that go along with these. These “communities of trust” are unnecessary with modern protocols such as HEART where each patient account is secured by a different cryptographic key.
I am a big believer in putting the patient (or their nominee) at the center. As you point out patient matching is far easier when the subject being matched is doing the matching.
The CMS BlueButtonOnFHIR project is designed to enable a consumer/patient/beneficiary to connect their data to the applications and services that they trust. The project will make the information that Medicare publishes as BlueButton text for a beneficiary available in structured format based on HL7 FHIR Resources. This will enable easier data reuse.
While CMS publishes claims information the model that is being established can easily be extended by other organizations to publish other FHIR Profiles, such as clinical data from EMRs.
As part of BlueButtonOnFHIR I am also proposing a “Pre-Oauth Entity Trust” (POET) API that can leverage the emerging HealthCare communities of Trust, such as NATE and DirectTrust to ensure that the Organizations that want to connect to CMS are known entities. You can find out more at https://github.com/ekivemark/poet
A Code-a-Thon is being planned for April 1-2, 2016 at HHS in Washington, DC. The objective is to bring together people working on FHIR and the BlueButtonOnFHIR team aims to have a prototype of the API available to developers for the event. Learn more at http://healthca.mp/onfhir