It's been three weeks since I joined the CCHIT Advanced Security working group and so far it has been a very educational experience. I’ve been impressed by the amount of knowledge and drive my new colleagues bring to the process, as well as the sheer volume of government regulations, standards and guidelines that we have to contend with. As I spend more time thinking about this initiative, two new points have become apparent:

Certification is Expensive

Developing more secure software is expensive, but that expense actively improves the software. The certification process can also be expensive. Currently, CCHIT tests products by auditing a demonstration of the product following a set of test scripts and reviewing documentation provided by the vendor. When I first looked at this, it did not seem like much, at least in terms of security. However, I’m beginning to realize that the level of organization the process requires and the amount of time qualified professionals must invest to observe demonstrations and review paperwork is immense.

I still believe we need a more rigorous testing process, but I think we also need to consider how to do this in a way that is both economically feasible and actively improves the products. This is easier said than done, but it’s an important thought to keep in mind.

Failure would be Really, Really Bad

This wasn’t an entirely new thought for me – health data has always seemed more valuable than financial data because of its permanence. If someone gets your credit card number, you can cancel your credit card and get a new one. Of course, it isn’t quite that simple, but knowing that your data has been compromised can allow you to prevent future misuse. With health data, the information is about you, not assigned to you.

The part I had not considered is that a failure to handle security and privacy properly could prevent electronic health records from being quickly and widely adopted. While the Obama administration and others believe that electronic records can improve efficiency and accuracy in medicine, many believe they are expensive boondoggles. In short, supporters of electronic health records need to push for stronger security regulations. Without these regulations, we are likely to see a series of public breaches like the ones we've seen in the financial industry, which could prove to be a huge setback for the digitization of health records for decades to come.

Technorati Tags: cchit ehr arra security

The American Recovery and Reinvestment Act (ARRA) has set aside $2 billion to improve Health Information Technology (a nice summary of this part of the bill is available here), particularly to encourage the use of Electronic Health Records (EHR). There are many reasons this makes sense – why should I have to fill out the same health history forms every time I walk into a doctor’s office or hospital? It’s important to remember, however, that any computer systems designed to help solve these problems will necessarily maintain and communicate incredibly sensitive and valuable health data. Of course, anytime the government starts talking about spending a couple billion dollars on something, a whole lot of people get involved. One of the biggest conversations has been on how to decide what is a "qualified" EHR.

The definitive answer to that question won’t come until the Office of Health and Human Services releases standards at the end of this year. However, existing certification standards give some idea of how the health industry currently handles security. The Certification Commission on Healthcare Information Technology (CCHIT), which is working on certification that complies with the ARRA, has around 50 security criteria for access control, auditing, authentication and other specific security features. However, the criteria and test scripts that are used to demonstrate compliance fail to describe any way to test or audit the software that implements these features to make sure it does so securely.

One of the ubiquitous challenges in software security is to get the focus away from the features and on to the details of how the software is built. When you say the word “security”, many people think of encryption and authentication features. What encryption algorithm are you using? How big are your keys? Security features are important, but if the software is not developed securely, features alone won’t protect you.

We were here five years ago, only we were talking about financial data, not health data. In 2004, the Payment Card Industry established the Data Security Standard (PCI DSS). It wasn’t until it was revised in 2006 that any mention of auditing or testing the code was included in the standard. Starting in 2008, the PCI DSS requires source code analysis, web application scanning or an application firewall.

I hope that those in charge of the new standards will look at the process the PCI DSS went through and recognize the value of code analysis and application scanning from the beginning. To that end, I will be joining the CCHIT Advanced Security working group starting in July and plan to both call attention to lessons learned in the past and promote the official adoption of industry best practices around the development of secure software. I will also be heading up a continued effort within Fortify to help organizations keep our health records secure.

Technorati Tags: ehr hit cchit healthcare security