Saturday, October 27, 2012

Identity Proofing and Authentication -- Patient vs Provider

The HIT Policy Privacy and Security Tiger team is going to be looking into Patient identity credentials
Misuse/Fraud ID Proofing (including re: attributes, in-person, online and delegated registration) Authentication (including re: attributes and online challenges, two-factor authentication, credentialing, third-party authentication) Usability (including workability of solutions, complexity for patients)

I am a member of the HIT Standards Privacy and Security workgroup, so I eagerly await this testimony  GE Healthcare has been invited and will speak to the experience with the Patient Portal that is part of our Centricity EHR product. I will leave this  testimony stand alone.

From my perspective I look at this with RISK in mind. I certainly hope that 2-factor authentication is not needed by patients. I, as a patient, would be very annoyed by that, and it is simply not justified. Healthcare Providers are different, and I could get behind a multi-factor effort there for specific workflows (use-cases).

The difference is that a patient only has access to their own data, thus a failure exposes only ONE individual. Where providers have access to a very large number of patient data, one might say ALL possible patients. Thus a failure on provider is high risk. The Risk profile for Healthcare Providers and others using an EHR are clearly higher, but so are the ability of their environment to sustain more complexity. Note that I am not saying that ONE individual exposure is acceptable, I am saying that the risk profile is simply different and thus should be assessed.

I would like to see a risk profile put together on Patient Identities, as well as Provider Identities. This would look at the use-cases of these identities and misuse-cases. By putting together realistic Threats one can do realistic Impact assessment and Likelihood assessments. The Impact value is the most likely to be different, as I stated above. Without understanding the use-cases, misuse-cases, and risks; I fear that fear is all that will  be used to justify very expensive solutions.

I want to make sure that whatever is presented as ‘current state’; and that the healthcare industry continue to pursue the NSTIC efforts currently underway (for which I am participating). I want healthcare to NOT do something special, thus non-standard.

UPDATE: The GE testimony to the HIT Standards committees is published.

User Identity and Authentication

3 comments:

  1. What I want the HIT Policy Privacy and Security Tiger Team to do is reference NIST SP 800-60, vol 2, section D.14. It points out that, at least for government HIT, higher risks are to health care data integrity and availability. They can harm or kill people rather than just embarrass them.

    Undo attention is being paid to identity proofing and authentication. There are already useful cross-industry standards with mature implementations. The chore is to pick one and provide incentives for its use.

    The higher-risk integrity and availability threat profile for health data, and potential harm to patients, could be under the FDA's purview. That is the default choice. I wonder if the HIT industry is OK with that. If so, encourage the FDA to assert its existing authority. If not, develop a workable alternative.

    ReplyDelete
  2. I have been watching the debate around the security in Healthcare, there has been a big debate over which methods of security are best suited to add additional layers of security and authentication for account access and transaction verification without being unreasonably expensive or complex. There is a need to step up the implementation of Two-Factor authentication and make it so employees can telesign into the system and access patient data securely.

    ReplyDelete
    Replies
    1. I am not sure that even for Providers that we must presume 2-factor authentication in the classic sense. I really hope patients don't need to do 2-factor. Many advances are happening and are being architected to be isolated into an authentication provider. For example using OpenID or OAuth. This allows the EHR to focus on the tasks of an EHR, while relying on a service to handle user authentication. This way the EHR can progress independent from the advancements in authentication. This also decouples the changes to authentication overtime from the EHR. Same can be said of PHR or Patient Portals.

      Delete