Identity is Vital to the Concept of Interoperability
I’m Eric Rosenfeld, Chief Technology Officer at DrFirst. Or am I? Do you really know? But in truth, I could be anyone. Without wading into deep existential waters here, once you begin to really question what you think you know about who a person is, you quickly realize how much we rely on assumptions.
“Ah,” you say. “But I could ask you to prove who you are! Show me your driver’s license.”
I can certainly show you my state-issued driver’s license, but that only tells you that a government entity has authenticated my identity. We all agree, for the sake of convenience, to accept this as proof. That’s fine for many situations, but when you’re talking about healthcare interoperability, it is simply not rigorous enough.
Identity is vital to the concept of interoperability. At its most basic, interoperability allows people without prior association to share information confidently, securely, privately, and in a way that is as useful on the receiving end as it was on the sender’s. The key aspect of the exchange and any confidence you have in that exchange is that you know who you’re talking to.
When two doctors are talking, without a prior association, there must be a reliable means of managing the identity of the doctors so that both can trust that the other doctor is who he purports to be. Without that assertion, you’re dependent upon less rigorous means of identification – a business card, employment by a hospital – and you’re sending information blindly. Even our current best practices within the DIRECT project network, and HISPS and HIEs don’t guarantee that the wrong person won’t receive your message. The rigor of the identity proofing just isn’t there. A chain is only as strong as its weakest link, and if there is not much rigor in proving your identity (and consequently your presumed authority) to an HIE, then potentially anyone could fraudulently assume that authority.
While there are so-called trust organizations that are beginning to establish standards of practice as part of their work towards creation of trust and interchange standards, there remains a big hole in the middle: non-refutable identity proofing for the providers themselves. This responsibility has been left to the so-called registration authorities and is not rigorously defined. That is, within the nascent HISP ecosystem, there are wide discrepancies between the actual practices used by the HISP to achieve identity proofing of their provider participants. The certification guidance available does call for identity proofing as a step, but stops short of specifying the actual nature and level of the identity proofing process, thus leaving it open to interpretation and differing implementations. Up to now, only electronic prescribing of controlled substances (EPCS) standards, driven by DEA requirements, have satisfactorily addressed the need for identity management in clear and consistent terms. EPCS requirements include audit control and burdens of proof required within the EPCS regulations, enforced with the weight of federal DEA action. In order to secure healthcare data in this age of data interchange and interoperability, we need to implement an easily adoptable, yet solidly provable solution for identity proofing.
The structure of such a solution requires, at its foundation, a thorough form of identity proofing based on financial or other personal data that is private, and therefore generally not accessible to others. This process cannot be proxied. There must be direct participation by the individual providers themselves for the original identity proofing. There must also be a mechanism to bind the physician’s identity to a reusable device or technology so that it can later be verified. Two-factor or three factor identification devices, biometrics or other secure and FIPS-certified technologies, now generally available could be employed to answer this deficiency.
It must be said, even the strictest identity proofing will not protect against a physician who is either intentionally or unintentionally sending the wrong data. However, we must set the standard so that we can be assured at least that all providers engaged in the exchange of information are clearly and consistently identified, verified, and trustable.
We must build in identity challenges when the message is sent and received. One option is a published HISP to HISP interchange based on directory search and verifiable identity, allowing a user to search another HISP through HPD or some similar universal protocol. That would be a good first step. The next logical step would be to require HISPs or HIEs to have a certificate of authenticity of their identities, and to tie that identity to a certificate used in the message exchange. That would strengthen all of the links in the information exchange chain: the sending doctor, the entity the doctor is sending from, the entity of the receiving doctor, and then, finally, the receiving doctor. Until every link in the chain is iron clad, mistakes and possibly even fraud are not just possible risks but inevitable liabilities.
About the author: Eric Rosenfeld is the Chief Information Officer, having broad responsibility for all Information Technology at DrFirst, including software product development, computer operations, Quality Assurance, and Project Management. Mr. Rosenfeld possesses over 25 years of business and IT experience in companies throughout the health care industry. In June, 2010, he came to DrFirst from BlueCross BlueShield of Tennessee, where he was the Senior Vice President of Information Technology for BCBST’s wellness division. Mr Rosenfeld is an expert in the process of application design and development, project management, and process control.