It’s only been a week since the DirectTrust/Civitas conference came to an end, but it feels so long ago. I can think of a handful of times in the past where I experienced this strange elongation of time, and it consistently occurs after I’ve gone through something substantial in my life. Looking back at the experience I had at the conference, from the amazing Unconference sessions on Sunday to the open and inviting discussions I cherished with wonderful folks that I hadn’t met previously, to the vast amount of knowledge and ideas shared in the carefully planned sessions… yeah, I think it fits the criteria for being something substantial.
I was impacted in so many different ways from understanding the perspectives of various folks from different viewpoints throughout our Health IT ecosystem that I couldn’t possibly summarize everything in a blog post of a manageable size. However, there did seem to be a few salient points that came up time and again in a way that seems to “thread the needle” through many of the conversations. I’ve chosen three of those salient points to reflect on below.
Making Standards Useful to Those That Interact With Them The Most
First and foremost, the topic I heard come up frequently was the difficulty in making standards useful in such a way that they solve the problem they intended to solve when they were created. I think many of us feel the standards that exist today are largely adequate to address interoperability, aside from some iterating that would improve their utility. In fact, during the Unconference session on Sunday, the group of folks I had the pleasure of conversing with all concluded that the standards we have are largely adequate, but we need to improve the interoperability between standards (a sort of “interoperability2“) such that we can all communicate with one another, even if we speak different languages. The group also discussed outlining the causes of why standards often don’t seem to be used to their full utility as a sort of root cause analysis. From there, we could observe ways to measure and even incentivize standards adoption in a way that is in fact useful to everyone.
Stated succinctly, the pieces that appear to be paramount to translation from a standard to a highly productive system that incorporates standards can be divided into three components:
- the standard itself,
- unique user experience innovations, and
- education, such that the standard is adequately adopted and achieves its intended objective.
Innovation and Education
The standards already exist, and while they may not be perfect, they are an area that requires the least amount of improvement. This leaves us with the remaining two components: 1) technology innovation and user experience that goes beyond “checking the box” to ensure the standard is being met and 2) marketing and communication to aid in the adoption of standards because many standards in HIT benefit from a network effect, which hinges on adoption level. Kathryn Ayers Wickenhauser moderated an excellent session on this topic that is worth viewing if you missed it in-person called “Education and Communication as a Catalyst for Technology Adoption.”
An improvement in those two areas can provide a valuable feedback loop for enhancing the standard at a later time. Without question, as a standard gets adopted and wrestled with, the warts and shortcomings of the standard begin to rear their head. Once identified, the standards can be improved and ratified through consensus to help the standard further reach its goal, and then the cycle begins again. Many of the standards discussed at the conference are about half-way through their cycle, and I’m optimistic that we are on the heels of the second half of that cycle.
Patient’s Consent and Right to Access
The topic I heard second most are challenges around collecting patients’ consent and providing their right to access their own health data. This is a particularly challenging topic and one very close to my heart. For the uninitiated, it may seem “cut and dry” – just give patients their data when they ask for it, right? The challenge is, it’s one thing to honor a patient’s request to release information, however, it’s entirely different to release information when you THINK the patient gave consent, but it really wasn’t them on the other side of the internet. Yet another challenge is arming organizations that hold data with the ability to defend their choices to release information when relying on validated and trustworthy requests. In the end, patient consent comes down to four intertwined capabilities that mitigate different risks:
1) Patient Identity Credentials:
Identity provides assurance that you can trust the patient is whom they claim to be in a verifiable and provable way that satisfactorily mitigates the risk of fraud or impersonation. In all cases, an organization issues a credential to a patient who has done the homework to ensure the patient is whom they claim to be. This comes in two flavors. The first flavor is identity proofing (IAL for the NIST 800-63-3 nerds), which ideally only occurs only once due to its difficulty and the friction it can cause patients when proving their identity. Immediately following identity proofing, the patient should be bound to a mechanism that allows them to prove they are the same person that was originally identity proofed in a way that is very secure, and also much more convenient than being ID proofed again and again. These mechanisms are called authenticators (AAL). The combination of a set of attributes about a patient, authenticators bound to the patient and an attestation of identity from the organization vouching for the patient’s identity all make up a Patient’s Identity Credential.
2) Unique Identifiers:
Identifiers mitigate the risk of mismatching or failing to match patient records within a computer system. If there are 2 John Smith’s in a system with very similar demographic data, which of those records should be returned? This should not be confused with the identity credentials defined above. In fact, identifiers often make rather poor identity credentials. A good example is a social security number. While the social security number does a pretty decent job of distinguishing you from other citizens (serving as an identifier), it does a rather poor job of proving that you are, in fact, in possession of the social security number. This is because the best practice for protecting your social security number is to “never share it with anyone… except everyone that asks for it.” Once the number gets into the wrong hands (which is relatively easy with shared secrets) it’s very difficult to get it back, and/or to associate your identity with a new identifier. This is why identity credentials and identifiers should be kept separate, but used in combination to have the most powerful effect.
3) Legal Agreements:
Legal agreements mitigate the risk of actors failing to fulfill their duties on a network of participants. In essence, legal agreements provide the basis of Trust, which is a very human characteristic. Normally Trust is achieved through a series of interactions with an individual or organization over time. In the absence of such a utility (mainly because that can’t scale across all of healthcare) legal agreements are a tool that organizations can rely on to trust one another. Healthcare organizations may not know the other organization they interact with, but if they know the other organization is bound by a legal agreement that requires them to behave a certain way, then the legal agreement can serve as the basis of Trust. Legal agreements that all parties have committed to is the way our regional/national HIEs and Trust Frameworks have been able to achieve the nationwide exchange of information that we can observe today. In the context of an identity-based Trust Framework, the parties carrying out patient identity credentialing are bound by legal agreements, developed through consensus, that ensure the patient has been ID proofed and/or authenticated in a certain way that is satisfactory to the parties that will rely on the attestation of identity communicated through the patient’s credential.
4) Cryptographic Infrastructure:
The fourth and final capability, a Cryptographic Infrastructure, serves multiple important purposes: 1) non-repudiation and 2) communication and/or proof of the existence of a legal agreement and risk-tolerance level in a way that a computer system can understand to support automation of Trust. Non-repudiation is a very important aspect of enforcing legal agreements because it provides evidence that a particular transaction occurred. In other words, a cryptographic infrastructure provides a means to prevent a party from “repudiating” or denying that they ever participated in a transaction. The legal agreement defines exactly what each party needs to do, but it cannot prove that a party actually engaged in a transaction in the first place. If an organization on the network fails to fulfill their obligations in a transaction, but then can successfully deny ever having participated in the said transaction, then the legal agreement becomes very difficult to enforce.
The second aspect of a Cryptographic Infrastructure allows a computer system to observe certain information contained in a patient’s credential that communicates the risk-tolerance level of the credential which allows the system to make a decision about where or not it will trust the validity of the credential, automatically. These systems need to be configured in a certain way such that a person is telling the system how to make it’s decisions, but from that point forward, the system can successfully relieve the organization from making those decisions manually in the future. Not only does this improve efficiency at the organization level, but also at the national level because such a cryptographic infrastructure is able to scale. Indeed, the entire internet is built on such an infrastructure as well many other systems that patients interact with today, and may have no idea it exists. Not knowing such a capability exists means the system is working the way its supposed to, while providing immense utility to the world.
No organization has all four of the capabilities defined above, but DirectTrust is close to achieving that objective as a Trust Framework serving the healthcare industry. DirectTrust’s network of accredited identity providers and service providers address capabilities 1, 3 and 4 today. The new Privacy Enhancing Health Record Locator Service (PEHRLS) standards effort is set to address the final capability necessary to provide a means to adequately address many of the hurdles related to patient consent and their right to access their health information. DirectTrust is heavily supporting the efforts of the CARIN Alliance Proof of Concept which intends to prove out these capabilities.
Trusted Instant Messaging Plus (TIM+)
The third topic that seemed to keep coming up in discussions is the reconstitution of the TIM+ Consensus Body at DirectTrust which centers around an ANSI accredited standard for Trusted Instant Messaging within and across healthcare systems. Interestingly, this Consensus Body is reinvigorated due to a Texas-based HIE approaching DirectTrust with a use case that their Healthcare Delivery Organization (HDO) customer was interested in.
The premise is that the HIE would serve as a sort of hub of communications occurring throughout the HDO’s network of hospitals and could eventually expand the service throughout the region they serve to other HDOs. Even more exciting is the potential for HIE’s to communicate with each other over the protocol in a way that is underpinned by a Trust Framework (described above) such that HIEs serving different regions around the country could route Trusted Instant Messages to various parties in their respective networks. This construct is very analogous to the role a Health Information Service (HISP) serves for Direct Secure Messaging today and may even represent an opportunity for existing HISPs to expand their offering by helping HIEs stand up such a service for their region.
The most interesting part about this opportunity is the potential for addressing, at least in part, the first and second points outlined above through this initiative. The mere implementation of this standard within patient-facing client apps such as Patient Health Records (PHRs) could not only provide a user experience that offers usable value to typical patients but also partially offer a means to address patient consent and data sharing given the patient is communicating with their point of care or other parties in a trusted capacity that is underpinned by a nationally recognized Trust Framework. The potential for this TIM+ Consensus Body is immense and it may involve HIEs, HISPs, identity providers, EHRs healthcare providers and other parties all that were present at the conference, which may be the reason this Consensus Body got so much attention. If you would like to get involved in this exciting Consensus Body, reach out to us!
A Great Success!
In summary, the conference was an overwhelming success from my perspective and I thoroughly enjoyed the conversations I was able to have with such a variety of individuals representing various walks of Health IT. I’ve enjoyed the opportunity to reflect on some of the topics that came up during the conference and I hope you enjoyed taking the ride with me.
This post was contributed by Kyle Neuman, DirectTrust Director of Trust Framework Development.