Meaningful Use - Security Plan

Now that I have vented and thought more about the Meaningful Use IFR, let me address what I think should happen. Given that there is so little time between the final text of the regulation and the certification deadline in 2011:

First: Everyone should comment on the IFR. What ever your opinion is, now is the time to say it. Don't just send in nasty notes about how bad it is, be specific about your concern and what you want them to do about it. Your voice will be heard far better if it is specific about the actual textual changes.

Second: To ONC: Remove all of the security requirements. Yes, this would be BETTER than what is there today. I would rather have specific requirements that assured that two different parties that are obtaining a certified EHR have at least one way that they know they can securely connect (HITSP T17). It is clear that ONC doesn't think they can ask for this due to some market reason, so I would rather have security in the hands of HIPAA than the confusion that arise from poorly worded security requirements in regulatory text. HIPAA is a risk based approach that scales well with the actual risks and thus can better adapt to different settings and changes over time.


Third: To the EHR suppliers: Follow CCHIT security/privacy requirements. I really hate to say this as I am not that big of a fan of CCHIT, but they have a good set of functional requirements for security and privacy (yes, I was co-chair when the majority of them were written, so yes I believe in every security requirement. My aversion to CCHIT has more to do with their non-openness and some of their operational issues during certification). I know that many EHR products have achieved CCHIT certification (including GE's EHR products). I have no idea who has not achieved CCHIT certification. If we understood who these were, we might understand why ONC seems to want less security than CCHIT has asked for. I am not sure I would want to recommend to any Provider that they use a product that can't show that they have met the CCHIT security requirements. These seem like a reasonable baseline of 'functional security capabilities'.

Fourth: To the EHR suppliers: Get going on HITSP security/privacy specifications. Some of these requirements are hard to meet, start with the easy ones. I have written about the maturity of the HITSP specifications, and also a scalable approach that recognizes these standards maturity issues. The reason to implement the HITSP security/privacy specifications into an EHR has more to do about interoperability than security. A Provider can secure communications with many methods including physical isolation, private networks, VPN, secret-sauce. What the EHR vendor is doing when they implement the HITSP security/privacy specifications is provide at least one way that their product will interoperate with others. They are not forbidding other ways. Meaning that just because an EHR has implemented HITSP/T17 (mutually-authenticated TLS) does not mean that a Provider can't use a VPN, they can. But if the EHR vendor doesn't implement something that provides a secure communications channel then we force Providers to use 'third party solutions' like VPN. Yes, using a VPN requires working with a third party solution. It is common for large hospitals to have VPN solutions, and that is fine. But it is NOT common for a small office to be able to support VPN by themselves.

Fifth: To the Providers, HIE, Labs, Payers, and any other party that is 'operational': Use a Security Risk Management approach.  Security by checklist is a bad idea. ‘Security Theater’ is a bad idea. This starts with a group of people thinking about security threats; that is threats to confidentiality, integrity, and availability of any resource. For any security threat, the likelihood and impact is used to determine appropriate reaction to that threat. An additional benefit of the risk management path is that security threats can be evaluated together with patient safety threats. Often times a security threat does introduce a patient safety threat, but an important thing to avoid is mitigating an unlikely security threat with a technology that introduces a patient safety threat. As with any risk management there is never zero risk. NIST has a really readable guide: *** NIST SP 800-30 Risk Management Guide for. Information Technology. If not this, then pick one from a blog post by Jeremia Grossman: In absense of a security strategy

It is so important that we stop the churn and get going with something. Achieving Meaningful Use is a good thing. We will not get there if we don't get started. We should take a pragmatic approach. Take small steps that are most likely to produce the most Meaningful Use. Fear, Uncertainty, and Doubt have frozen progress long enough.