A few weeks ago a post by David McCallie discussed the ongoing efforts and challenges toward achieving health information interoperability. McCallie presented a list of “sufficient conditions for interoperability” and argued that “Congress should accordingly define the ‘what’ and let the U.S. health care stakeholders define and achieve the ‘how.'”
Engaging the patient-consumer in the interoperability design around the EHR interface can speed interoperability and reduce the burden of regulation. A convergence of patient, physician, and institutional strategies for interoperability around the JASON Public API (application programming interface) can reduce the risk of congressional intrusion in complex technical standards.
The U.S. healthcare stakeholders include patients and individual physicians. Unfortunately, these two stakeholder groups are seldom represented in technical standards organizations and, more importantly, have almost no purchasing power when it comes to electronic health records or health information technology. This contributes to the slow rate of progress and has created significant frustration among both patients and physicians.
The Public API addressed by the JASON Task Force is compatible with both institutional and patient-directed interoperability. At HIMSS-15, a group led by the Veterans Administration, the Office of National Coordinator (HHS-ONC), and Patient Privacy Rights demonstrated “Privacy on FHIR” . We showed how a single FHIR API could bridge the interoperability requirements for institutional health information exchange, exchange of sensitive health data covered by 42CFR Part 2, exchange of data with patient-controlled apps, and even with patient wearables.
Let’s review McCallie’s list (in italics) from the perspective of patient-driven interoperability as we began to show in Privacy on FHIR:
I believe that the sufficient conditions for interoperability include the following:
*A business process must exist for which standardization is needed. As Arien Malec put it recently, ‘SDOs don’t create standards de novo. They standardize working practices.’
The business process for patient engagement already exists as the patient engagement component via a patient or beneficiary portal. Almost every HIPAA and non-HIPAA health service provider already offers an online patient portal. This includes key stakeholders such as health insurance payers that figure prominently in most healthcare transactions.
*A proven standard then needs to be developed, via an iterative process that involves repeated real-world testing and validation.
The standards that control user authentication and authorization for access to an interface are the same regardless of the nature of the information in a modern Web interface. The key standard associated with FHIR is called OAuth2 has been widely adopted by some of the largest companies on the Internet and is already adopted by healthcare HL7-FHIR standards organization. Once authentication and authorization are interoperable, the health data representation standards can be any combination of legacy and new with the assurance that one way or another, the message will get through.
*A group of healthcare entities must choose to deploy and use the standard, in service of some business purpose. The business purpose may include satisfying regulatory requirements, or meeting market pressures, or both.
Business drivers and Meaningful Use mandates for patient engagement have already provided the incentives for healthcare entities to adopt the FHIR/OAuth standard for interoperability under certain circumstances. The only question now is the scope of the FHIR/OAuth standard relative to other information sharing standards such as Direct or CommonWell or the bulk transfers over legacy interfaces. Think of patient-directed interoperability as “the lowest common denominator” for getting information from anywhere to anywhere.
*A ‘network architecture’ must be defined that provides for the identity, trust, and security frameworks necessary for data sharing in the complex world of healthcare.
The patient’s right of access under HIPAA combined with the now ubiquitous patient portal provides a network architecture that completely specifies identity, trust, and security in a way that is compatible with the FHIR/OAuth standard. The engagement of patients in setting up FHIR-based interoperability not only avoids unreliable and expensive patient ID matching problems but it also provides a significant “safe harbor” to the institution in terms of consent and security decisions. In some cases, patient-driven interoperability across a Public API can also prevent mass data breaches by using separate encryption for each and every patient.
*A ‘business architecture’ must exist that manages the contractual and legal arrangements necessary for healthcare data sharing to occur.
The patient’s right of access under HIPAA is common to all HIPAA Covered Entities including payers as well as providers and it is uniform across states and even across 42CFR Part 2 sensitive data restrictions. When the patient authorizes interoperability by directly linking two provider interfaces, no further contractual requirement is needed and the information can flow automatically from then on until the authorization expires or is revoked.
*A governance mechanism with sufficient authority over the participants must ensure that the network and business frameworks are followed.
The well-known interoperability maxim: “be strict on what you send out and permissive on what you accept” reduces the scope of governance that is needed. Patient-driven interoperability is compatible with other governance mechanisms such as CommonWell or Direct with each institution free to decide if they will accept other standards besides the patient-directed ones.
*And almost no healthcare standard can be deployed in isolation, so all of the ancillary infrastructure (such as directory services, certificate authorities, and certification tests) must be organized and deployed in support of the standard.
The beauty of patient-driven interoperability is that ancillary infrastructure is helpful but not mandatory. As with auto-pay transactions with your bank, directory services are not required and certificate authorities are already in place. Certification tests would still be needed but the the Internet provides ample examples of open tests and self-asserted certification that would bypass most of the delays associated with legacy methods.
Efforts to standardize the JASON Public API are currently ongoing in two parallel groups called Argonaut and HEART Although some of us are members of both groups, our efforts are not yet fully harmonized. A patient-directed, “Privacy on FHIR” approach could be used to harmonize the work of these two groups and potentially reduce the scope for Congressional action in support of interoperability.
If you believe that patient-directed interoperability can accelerate our quest for a learning healthcare system and benchmark the new era of precision medicine, then please join the HEART Working Group mail list and our weekly calls at 4PM EST. Your participation is essential to making patient-driven interoperability a reality this year.
No comments:
Post a Comment