Three Security Concerns for 2010

One of the HIMSS groups that I participate in asked the members for their three security concerns for 2010. (This is what also caused Glen to write the text that I have as a guest blog: Accounting of Disclosure Challanges and Top Information Security Concerns).

1) Identity. Including Patient Identity, Provider Identity, and User Identity. Identity is important to make sure that we get operational access controls correct, patient-privacy-preferences correct, delegation correct, accounting of disclosures correct, oversight correct, etc.

• Patient The aversion to a federally issued identity is well known. I am amazed that we are the only country that can’t get over this, yet have so many federally issued identities. We don’t need a federally issued identity, but a federation of identities. This is a strong linkage between the various healthcare identities. There could be purpose-of-use views into this federation that forbids the viewing of identities that your purpose-of-use does not need access to. What is important is that this is a STRONGLY provisioned linkage. This is NOT an algorithm that evaluates two sets of demographics and ‘decides’ that there is a probability that they match. The act of entering a new identity and matching it to the existing identities must be done following only well documented process. Essentially I am worried that a fuzzy matching of patient identities will have too many false positives and false negatives. Patient’s lives are too important. Patient misbehavior is too valuable.
• User Identity. This is highly linked to the Patient Identity as they are often going to be ‘users’ in the context of a PHR. This is also highly linked to “Provider Registries” that can be used to find a provider for treatment. And this is highly linked to “Directories” that are used today in the operational setting to manage user accounts for healthcare applications as well as other business applications (yes healthcare is a business and users need to do things besides use the EHR). Again a Federated approach is needed. The reason here is different than for Patient Identities. There is already a federally issued identity for Providers, NPI. This does not address all the ‘users’ of a Health Information Exchange; that is the P and O in TPO. Further there are many ‘users’ in the Treatment side that would not be issued a NPI.
  Former Posts on the topic: Federated ID is not a universal ID 

2) Secure by Design. I am worried that there is such a rush to carry on with point-to-point links without thinking through the security and PRIVACY issues that this would raise. I participate in standards, profiling, and government initiatives because I want to build security into the architecture, not bolt it on later when success accidentally happens. I attribute this to the false perception that if we let the security guys in to the discussion up-front they will slow us down and make the system non-functional. There is very good excitement around the medical advantages of sharing healthcare information. The Security geeks must not be pushed aside; we MUST push our way back into the discussion. And when we push our way into the discussion we must NOT prove ‘them’ right. Designing in Security does not need to be a problem. Use a RISK based approach, and Keep It Simple and Secure (KISS).

Former Posts on the topic: IT security problems continue, What has HITSP done to protect confidentiality with a suite of implementable security standards,  Implementing standards takes time. 

• A sub-theme here is abuse of de-identification. This is a method of LOWERING risk, it does not eliminate risk. ONC to test re-identification of protected data, De-Identification is highly contextual, How Private can Electronic Information Ever Be?

3) Accounting of Disclosures. This very important part of patient-centered-healthcare needs to be discussed more than it is today. There are many bad ways to implement this, as in assuming that it can be generated on-the-fly ala a security log. I suspect that the requirements today are not even meeting the need, especially in the USA. I expect that over time this topic will morph into something far more useful to the patient and less frightening to the healthcare organizations. I expect that we will learn much from the likes of Facebook/Twitter/YouTube/etc, yet will also have our social norms educated. ATNA and Accounting of Disclosures, Patrick Pyette: The Case for Privacy Accounting

4) Privacy Policies. I put this one in at #4 of 3 because I have little faith that this is solvable in 2010. There are simply too many divergent views on Privacy Policies.  IHE took a brave move in creating BPPC, a profile that simply provided a basic framework for indicating that a patient has agreed to a policy. No details about the policy are given except for it's unique identifier. HL7 is now extending this concept with a mechanism to add variables to the policy so that the content of the policy can be customized by each Organization-Patient pair. This customization is going to take a while to work out. This will be useful, but will take another 5 years before one could say that it is mature enough to implement. Consumer Preferences and the Consumer, Opt-In, Opt-Out.... Don't publish THAT!, RHIO: 100,000 Give Consent.