When presented with a large stack of forms to complete upon arrival at the doctor’s office, most of us plow through and essentially skim the lengthy documents. Anticipating a decent wait before even going back into an exam room, the sooner we can finish the paperwork, the sooner we’re in the queue. Unfortunately, what is often buried in that paperwork are important aspects of consent and security that govern ePHI, including how the healthcare organization will or will not use and share data. As consumers become increasingly concerned about how their information is used, we often forget to give the same attention and weight to our medical information.
Today we’re going to look at a few aspects of consent as they pertain to healthcare interoperability to better understand the potential of aggregated patient data (for better) and the risk of limiting the scope of sharing (for worse).
HIEs Hinge On Strong Consent Modeling For Interoperability
Perhaps the two most vital (yet underplayed) aspects of cultivating a strong Health Information Exchange (HIE) are identity management and consent modeling. While an eMPI may solve the need for a normalized ID to de-dupe and consolidate patient records, there are less obvious tools to manage consent. The reason for this, we believe, is because there’s a lot of policy and operational implications when it comes to consent.
For example, the consent gathering and flagging process may look very different for a well-established healthcare community that is looking to interface across a relatively fixed roster of providers, versus a health organization that is seeking to aggregate ePHI with flexible use cases beyond the point of care (such as clinical trials, research, etc.).
When Not All ePHI Is Created Equal For Consent
The ability for a healthcare system to not only convey data sharing intentions for the purpose of obtaining consent but to also have the technical ability to effectively flag patient information — down to the type and nature, such as mental health or HIV/AIDS — will make or break how valuable an HIE will be (for care delivery, operational purposes, etc.).
If sharing is too granular and “locked down,” the potential for true Continuity of Care disappears given significant gaps in needed clinical data at the behest of a more stringent consent policy. However, blanket consent approaches may prove too liberal for certain connecting entities, patients, or organizations that may otherwise pursue interoperability. When the perception of liability is too rich, the willingness to bi-directionally exchange (not just push) data is at risk.
Change Management For Consent In Interoperable Solutions
Obtaining and implementing consent for data sharing across integrated EHRs and ancillary solutions is one thing, but health systems must consider how to deal with changes to consent that occur beyond Go-Live. This can present as a variety of use cases:
- Change in diagnosis (such as mental health) alters how data is stored, displayed, etc.
- New HIE end-user necessitates a change to the types of entities to which patients or organizations consent for sharing (such as pharma)
- The organization has changed consent default (from opt in to opt-out, for example)
- The patient has decided to change consent status (withdraw or share)
Each of these scenarios represents unique responses and procedures to ensure HIPAA requirements and patient wishes are observed. A breach at the HIE level can be catastrophic to a health community, so change management for consent must be anticipated and addressed for interoperability to thrive.
In A Nutshell: Patient Consent For Interoperability Cannot Be An Afterthought
There are certain aspects of integration efforts that can be iterated upon and changed as needed without impacting the core data models and approach. Consent, however, must be strategized from the very beginning to build a process that is secure, stable, and adaptable. Choosing a technology partner that understands the vital nature of consent handling and management for interoperability projects is key for overseeing integration across vendors, organizations, and governance requirements.