Medical Data in the Internet “cloud” (part 2) – Data security

This is the second of a 3-part series, where we dig a little deeper into the questions of medical data in the Internet “cloud.” In the first part, we reviewed issues of data safety – how to guard against loss of data. In this second part, we will review data security – how to guard against data theft. The third part will focus on privacy and ensuring that only the right people can access the right data.


DATA SECURITY

A review of issues around medical records ownership and protection shows that medical records are the property of those who prepare them (medical professionals), and not the property of those about whom they are concerned (patients), although patients generally have a right to review them, demand copies of them and demand their confidentiality. With limited and specific exceptions, consent is required in order to disclose such information to others. So, how does one create a framework of security that protects the confidentiality of such records against unauthorized breach?

In a paper-based charting environment (where most of the medical records reside in this country), securing medical data – so-called Protected Health Information, or PHI – is a manual process. Charts are stored in a chart rack (though sometimes left out on desktops and counters), and are only as secure as the locks on the clinic door – given that they are in plain text (handwritten or typed), a simple local break-in or breach from personnel can result in an unauthorized person (e.g. another patient, the after-hours janitor, etc.) reading the record. HIPAA rules specify that medical practices have a policy around protecting such information, and have in place “vendor agreements” with any third party that might be entrusted with PHI.

HIPAA rules also define encryption steps that must be taken when transmitting PHI electronically, including sending billing and claims information electronically, and faxing information to other offices and pharmacies. Faxing, which is point-to-point and local to that specific connection, is very unlikely to be intercepted (other than through wiretap) and is not encrypted. Email communication, however, which flows across public, shared “information highways,” is not suitable for PHI transmission, as it is not encrypted – in order to communicate PHI this way, a secure connection must be established. Secure web mail sites have been created which allow electronic transmission of PHI in a HIPAA-compliant fashion.

When medical information is moved from paper onto an electronic platform, additional vulnerabilities for security breaches (i.e. theft) need to be identified and addressed. When implementing a local, client/server legacy EHR system, there are issues of securing the source of medical information (the server, which is the e-equivalent of the paper chart rack), as well as electronic transmission of data across computer connections. If any PHI is stored locally onto workstations (which may occur, depending on the EHR system being used), then that workstation needs to have locks on it – password access to restart when timed out, as well as the need to have whatever PHI may be stored on the workstation encrypted too. A more significant risk is when the server is broken into and stolen, or local backup data devices are stolen. Physical theft of hardware containing PHI is an area of risk for local client/server EHRs and should be addressed by a policy and security plan at the local office.

The HITECH Act (part of American Recovery and Reinvestment Act, or ARRA) passed February 17, 2009, specifies that PHI must be protected both “at rest” as well as “in transit” – there are specifications by the National Institute of Standards and Technology (NIST) which cover how PHI must be encrypted in files on a computer. When data is encrypted on the storage devices in this way (which includes EHR databases, as well as scanned images that may also contain PHI, and also backups of these data), then physical theft of these devices is less onerous, since the data is contained in a way that is unusable, unreadable, or indecipherable to unauthorized individuals. If PHI is not encrypted at its source in a way consistent with the NIST specifications, and a breach (a theft) has occurred, then there is a burden on the practitioner to disclose to all affected parties (all the patients) that a data theft of PHI has occurred – some states, such as California, in fact, impose significant penalties for failure to make such disclosures.

Failure to keep the data files encrypted, as well as potential failure to use encrypted, secure connections between computers that pass PHI, make the use of many online tools intended for general “public” documentation not compliant with the standards (e.g. Google docs, or passing word documents from transcriptionists via normal email). If a data breach occurs, then the burden of disclosure is encumbered.

As EHRs start to migrate from local, legacy systems to hosted, web-based systems in the Internet “cloud,” the risk of hardware theft is reduced – most vendors (e.g. Practice Fusion) will use commercial enterprise-level server farms with biometric security at the hosting sites, and with access locks that are beyond what can be achieved by most local practices hosting their own. The local “workstation” is replaced by a web browser, and minimal-or-no PHI is actually stored or cached in the local machine – it is all hosted on the server. If a local computer is used to capture scanned images containing PHI intended for upload to web servers, then once the data is uploaded the original local files should be either encrypted or destroyed.

The use of firewalls in servers keep the internal data contained in a fairly safe environment, shielded from most intrusion. In addition, server-end encryption of the data in compliance with the NIST guidelines noted above keeps the data very safe. In fact, if these methods are implemented then notification to individuals, HHS or the media is not required in the event of a breach (a “safe harbor” provided by NIST-level encryption) – this is an important issue to note, and a physician should make sure that their EHR vendor is in compliance with these. A good review of this issue is discussed here. In addition, Meaningful Use criteria specify that an HHS-certified EHR must conform to these security standards.

As one can see, when health information moves from paper to local electronic systems, and then to hosted “cloud”-based systems, the risk of security breaches is actually reduced, provided that the vendors and systems utilized conform to specified standards. More problematic is the issue of privacy and consent (making sure that only the right people see the information), especially in an era where we see the emergence of shared EHR records, PHR records (stand-alone or linked to EHRs), and variations in local state laws about these matters. This will be the subject of the third segment of this series.


Robert Rowley, MD – Chief Medical Officer, Practice Fusion, Inc.