Assessing EHR Vendors on Security
In an exclusive interview (full transcript below), Ames says:
- "Any vendor worth their salt is going to be able to add the security functions in time to qualify" to be certified for the incentive program.
- Most EHR vendors will continue to offer username and password as the main way to meet the software certification requirement for access controls and authentication. But she predicts demand for biometrics and single sign-on will grow.
- Organizations acquiring or upgrading EHRs should ask for a demonstration of security functions and "obtain a copy of the administration manual that describes how security is implemented."
- Those buying EHRs should withhold a portion of the licensing fee until after a 90-day post-implementation period when security and other functions can be validated in a real-world environment.
Ames has more than 20 years of health information technology experience, including 15 years as a hospital CIO. As a principal with HIS Professionals, she has consulted with hospitals, physician groups and health information exchanges.
HOWARD ANDERSON: This is Howard Anderson, managing editor with Information Security Media Group. Today we are talking with Elise Ames, a principal at HIS Professionals, which provides IT consulting to healthcare organizations. Thanks so much for joining us today Elise.
ELISE AMES: It's a pleasure to be here.
ANDERSON: The final rule creating certification standards for electronic health records software that qualifies for the Medicare and Medicaid incentive program spells out a long list of security capabilities that the applications must include. Do you think that many of the electronic health records systems for hospitals and for physician groups now on the market already have many or most of the required security capabilities? Or will the vendors have to add many new security functions in a hurry to qualify for certification?
AMES: Well I think that most of the security capabilities specified do exist today....And also, the technology aspect is not overly complex in many of them. For instance, encryption is established technology. So I think any vendor worth their salt is going to be able to add the functions in time to qualify.
ANDERSON: The effort to certify EHR software is slated to begin in the next several months. Do you think most will be able to add those functions that they lack by year's end, or might some of them wind up partnering with security application vendors to add any missing functions?
AMES: Well I think that depends on how the vendor generally manages their operations. There are some HIT vendors that are primarily engineering-focused companies. Those companies will be building every bit of code to meet the certification requirements. Other companies have a history of partnering with other vendors to get a complete product, so I think they will pretty much follow what they have done in the past with that. I don't think that partnering with other companies will be a necessity, but I think it certainly would be an option.
ANDERSON: The certification standards state that records software must be able to audit not just who has accessed an application to make additions, updates or deletions, but also those who accessed it just in read-only mode and did not take any action. Is the capability to do those kinds of audits now rare in clinical software?
AMES: No, I don't think it's rare. I think because of the HIPAA privacy requirements that that capability has existed for a while. I spent a number of years as a privacy officer in a hospital, and I was involved in several privacy and security investigations where I needed to access the audit logs and you could see who had opened a record. So I think that most, if not all, of the vendors have the capability to make an entry in the audit log on read-only access...I don't think that is going to be a problem for them.
ANDERSON: The software certification standards require access controls and authentication be offered but they don't specify which ones must be used. Do you have a prediction on what forms of access control and authentication will be most commonly offered in EHRs?
AMES: Well, I think that the good old username and password is going to persist as the most commonly offered. The EHRs may provide requirements for stronger passwords and may add some additional security around automatic expiration of passwords, which, by the way is not required for certification....
I do think, though, as use of clinical systems becomes more ubiquitous there is going to be more demand for technologies that make access and authentication easier for the user -- maintaining security but not having the user enter a 10-character password and get logged out 15 minutes later for inactivity and enter a 10-character password again. Clinicians, in my experience, want to take care of patients and they are not going to want to spend time re-entering passwords. So we may see more use of technologies, like biometrics or single sign-on, that make it easier. But I don't think that the technology for access control at this point is going to require any big reworking from what has been offered for years.
ANDERSON: Should those acquiring electronic health records software or upgrading to a new version of the software ask to test drive the security functions before they make their decision on what to buy? And what other questions should they ask the vendors?
AMES: Well I think they absolutely should be asking the vendors questions about the security functions and other functions at every single point in the lifecycle of their procurement and their upgrades.
So if an organization is looking to purchase an EHR, they should be asking the vendors from day one, first of all to demonstrate their security capabilities and to explain them, and secondly to provide the actual user documentation -- a system administration manual -- which describes how security is implemented, how encryption is implemented....
Then, as part of implementation and testing, validation of the security functions is going to be absolutely necessary. And we always recommend a post-live acceptance period of up to 90-days where now you are really validating the software as it is being used in production, in real life, and you can test it and you withhold a portion of licensing payments until that acceptance testing is satisfied.
In regard to validation of the security capabilities, there are some of them, like the secure hashing algorithm, which are kind of difficult to test. I don't know if end users will be able to test to that degree. But the good thing about this whole certification process is that it is going to create documentation about the vendors' capabilities by an independent certifying body, which hopefully will give the users some comfort that the software does what the software vendor says it does.
So test-driving software is useful, as is talking with references before buying software, calling other users and asking how well the security functions work....
ANDERSON: Thanks Elise. We have been talking today with Elise Ames of HIS Professionals. This is Howard Anderson of Information Security Media Group.
