The voice for the medical software reseller community.

Last month we reviewed Electronic Medical Records (EMR) and HIPAA Privacy – VARs also need to understand the issues around EMR and HIPAA Security.  Hardly a week goes by without news of a computer security breach at a major national organization.  With confidential medical records, and the ubiquity of technologies like wireless – the potential for security breaches is high.

The security regulation mandates that practices put in place physical, technical, and administrative safeguards.   In all there are 42 “Implementation Specifications” which must be considered.  This article will deal with one of these three categories – the technical safeguards.  This information will be useful for you in both selecting an EMR to sell, in sales situations when you present your EMR to a technical buyer, and for appropriate installation and configuration. 

Some of the technical features are required, which we indicate with an “R”.  The rest are “addressable” – which means that each covered entity must determine whether the requirement is applicable to them – based on their risk assessment – and if it is applicable, then it is required.  Addressable items are indicated with an “A”.

So, here are the technical implementation requirements, with a commentary on EMR:

§           Unique User ID (R).  Virtually every package will include this feature.  As we will see, this feature works in conjunction with several of the other technical requirements.

§           Auto Logoff (A).  The software should have a user-configurable auto logoff, or workstation lockdown, which disables the workstation after the pre-established period of inactivity.  Your users will hate this feature!

§           Encryption and Decryption (A).  This requirement indicates the need to perform a careful risk analysis (one of the administrative safeguards).  For information stored on the server, many practices will conclude that no encryption is necessary.  For backup tapes taken off site each day by the office manager or physician, which are at much greater risk of theft or loss, encryption would be very appropriate.  Finally, for portable devices which store patient data locally (for example PDAs taken to the hospital for rounds), encryption would also be very appropriate to protect confidentiality in the event of loss or theft.  This requirement illustrates that a certain level of skill, sophistication, and judgment is necessary to appropriately apply these requirements.

§           Audit Controls (R).  This is a vital area which is often not well implemented by vendors.  The idea is that the software should maintain a log, by user ID, of who did what, and when they did it.  The best audit trail will allow a complete reconstruction of a user’s entire session, including all information added, changed, deleted, and viewed.  A large percentage of software will completely ignore data viewing from their audit trails.  When evaluating software, don’t just pass over the audit trail capability!  You will often find imperfections.

§           Integrity – Mechanism to Authenticate Protected Health Information (R).  The software should have technical mechanisms to insure that the data is stored correctly and remains unaltered.  We are looking for features like the use of a modern database management system, along with proper programming techniques such as the use of checkpoints and transaction logging that protect data integrity even with power interruptions and system malfunctions.  This can be tough to evaluate withoug really getting under the hood.  Usually, this type of capability is added over a period of years as software is enhanced and becomes mature.  Compliance on this requirement might be more of a continuum than a discrete yes or no.

§           Authentication (R).  Presenting a User ID is “identification”.  Providing a password is “authentication”, that is, proving that you are who you say you are.  Virtually all systems include passwords, so this requirement is easily met.  Costs are rapidly coming down for alternative authentication methods, including biometrics like thumbprint and retina scanners as well as token systems like key cards.

§           Transmission Security – Integrity Controls (A).  This requirement applies with data transmitted over an open network.  Most communications software includes features that verify that information is transmitted correctly, like CRCs and checksums, so this is usually handled.

§           Transmission Security – Encryption when transmitting over an open network (A).  This requirement generally applies if you are transmitting over an open network such as an office wireless network or the internet.  In a previous article, we provided suggestions for appropriate configuration of an office wireless network – attending to these configuration issues is a must.  Another important feature of EMR systems is the ability of the physician to access data remotely, for example from home or the golf course.  There are a number of technologies which can be employed to meet this requirement, such as a Virtual Private Network (VPN).  Attention should also be given to EMR systems which send e-mails to patients, allows a patient to access their records over the internet, or e-prescribing functionality which transmits data to a pharmacy or clearinghouse.  Some encryption scheme should be employed in all of these scenarios.

This is just the start of HIPAA Security Compliance with EMRs – the technical features in the software and hardware employed – and represents perhaps 25% of the compliance effort required.  The other 75% involves appropriately using these features, implementing other management processes, and attending to physical security issues.   Stay tuned for more on these – including value added services you can provide to help your clients with their HIPAA compliance.

Gary Pritts

Eagle Consulting Partners

www.eagleconsultingpartners.com

(For a 7-page matrix detailing all 42 HIPAA Security Requirements and their relationship to EMRs, Billing Software, and Network setup, you can e-mail the author at gpritts@eagleconsultingpartners.com.)

Gary Pritts is not affiliated with InvestMed; he is a healthcare, business and information systems consultant with 25 years of experience.  To contact Gary with questions about this article or HIPAA in general, visit his website at:  www.eagleconsultingpartners.com