Research program aims to advance security in Health IT

It pains me greatly that this project is perceived as being needed. There has been so much research and standards development in this area. The problems are not unique to healthcare, and the path is well worn by other industries. However all experts of any field will likely recognize that everyone feels that they need to fix what ever it is you have spent your life working on. 

"To accomplish this," Gunter added, "SHARPS has assembled an elite multidisciplinary team of healthcare and cyber-security experts that is uniquely capable of carrying out an ambitious strategic program to bring security and privacy in health information technology to a new level of sophistication."  More

Yes, that is an actual quote...  It terifies me that they feel we need a 'new level of sophistication'. Why is it so clear to Gunther that we need a new level of sophistication? Is it that the current solutions are too simple? Further it saddens me that they feel they have an 'elite' team that is 'uniquely capable'. Oh dear are we going to get some crap out of this.

No one has identified to me what this vast list of "critical problems" is. I suspect that the root of the problems are 99% a lack of declared policies:


1) Lack of Policies -- this is usually due to those responsible for the protection not taking the time to make compliance clear. The article on  E-health security a problem at Vancouver Coastal Health Authority should have made this very clear. If no policies are declared then no one can say that anything not working as it should be. Yet without policies there will be breaches. This is a big concern that I have as part of the NHIN-Direct as this project is clearly trying to put off Privacy and portions of Security under the singular simplification that the sending provider has determined out-of-band that they are authorized to send the data to the specified receiver. The good news is that this is a declared policy of the NHIN-Direct.

Other Posts on the topic: EHR not used securely, A Look into the HHS Posts Data Breach Notifications.

2) Lack of Consent -- this is very related but distinctly different. One can have policies without allowing the consumer/patient to have a say. This lack of control is a problem. Simply giving control, however limited can calm the consumer. This is shown over and over with social networking sites.

Former Posts on the Topic The meaning of Opt-Out, Opt-In, Opt-Out.... Don't publish THAT!,  Consent standards are not just for consent, Consumer Preferences and the Consumer, and RHIO: 100,000 Give Consent.

3) 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 

4) 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. De-Identification 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?