Practice Fusion Blog

Is my data safe with Practice Fusion?

We recently reviewed the question of putting medical data in the Internet “cloud” from the standpoint of safety (guarding against loss of data), and of security (guarding against theft of data). The discussion was a general overview of the issues involved in paper vs. local EHR deployment vs. hosting in the Internet “cloud” – but what about Practice Fusion? How safe if my medical data on that platform?

As noted in the previous posts, medical information (specifically, Protected Health Information, or PHI – which is subject to HIPAA Privacy Rules) in a paper-based environment is the least safe and secure. Local disasters can lead to wholesale, irretrievable loss (like a building fire, hurricane, etc), and individual charts can be lost or looked at inappropriately with relative ease. Office policy is supposed to be in place to address these concerns, but in reality the implementation of this is hit-and-miss across the landscape.

When a practice moves its medical data onto a locally-installed legacy EHR system, there is an improvement in safety and security – not to mention, an improvement in access (charts are always available, never lost, and accessible from in-house as well as remote locations). There are also new vulnerabilities that need to be addressed – is there PHI located on hardware (servers, workstations, backup devices) that could potentially get stolen? Theft of PHI-containing computers is one of the main ways that data-security breaches take place. Is the data on those local servers encrypted? If so, are the encryption keys stored separately, so that theft of a computer with PHI on it does not also include theft of the keys?

And what about electronic intrusion – are there firewalls, access controls and 128-bit encryption-secured connections in place? These kinds of issues may be addressed by a practice hosting its own local EHR server, but generally require an IT support vendor (a new line item of cost to a practice) to set it up. The IT support consultant has been called “the new best friend” of a medical practice, and represents another barrier to a practice moving from paper to an electronic platform.

When a practice makes a decision to move its EHR to a hosted platform (either moving directly there from paper, or by abandoning the use of a local EHR system and moving to “the cloud”), there are better server-end resources available to the practice – as well as new risks (or, at least, perception of risk) – “who are these guys, and can I trust them with my data?” After all, the Internet “cloud” is not inherently secure – yet banking has long used Internet access that we have all become accustomed to over the years. Banking over the Internet has engendered trust by paying very-detailed attention to building secure containers, connections and access to their data. Can this be replicated for Internet-hosted PHI?

Practice Fusion has devoted great resources to security, and building its applications in a way that meets-or-exceeds what is required by the HIPAA Privacy Rules. The servers are hosted in secure commercial facilities with multi-geography locations, and with safeguards against Denial-of-Service attacks. The data is secured behind firewalls, and encrypted (including the databases, uploaded scanned documents, and backups). Access to the data is protected through 3 keys (user ID, practice ID, and password), and are required to be of sufficient strength that they are un-guessable. Many of the technical security practices implemented by banks, as well as requirements specified by specific HIPAA implementation guidance, are part of an ongoing program of security and privacy, and represent a Continual Quality Improvement effort by Practice Fusion. Using Practice Fusion satisfies the principle of data encryption “at rest” and “in transit”, such that the HITECH “safe harbor” that relieves practices from the burden of disclosure to each-and-every patient in the event of a breach is satisfied– PHI data is secured in a manner that renders it unusable, unreadable, and indecipherable to unauthorized intruders. These are levels of security unlikely to be achieved with a locally-installed EHR system.

So, “is my data safe with Practice Fusion?” Not only is your data safe, it is certainly safer than is achievable with paper charts, and even with most locally-installed EHR systems. Practice Fusion remains committed to ongoing vigilance concerning data safety, and hopes to be able to “set the standard” for satisfying the fears about Internet-housed PHI. The banking sector has been able to achieve this (even without HIPAA) – so should we.

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

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.

Medical Data in the Internet “Cloud” (part 1) – Data Safety

The question of data security in a “brave new world” of cloud-based Electronic Health Records (EHRs), Personal Health Records, and iPhone and other smartphone apps that could transmit personal health information, has attracted the attention of many. Web-based services – so-called “cloud computing” – are not inherently secure. Such technology is focused more on widespread reach and interconnectedness rather than on making sure that the connections and the data are foolproof. Yet much of our personal information, such as banking information, is housed electronically and accessed through the web – we have become so accustomed to it that we seldom think very much about it. Personal health information, moreover, is protected by law: HIPAA, which is focused around physician and hospital-centered recordkeeping, and now ARRA, which extends HIPAA-like protection to patient-centered Personal Health Records as well.

In a previous blog post, we reviewed (at a high level) the ways in which special attention to security and privacy can create what is needed to house personal health information in a hosted, “cloud”-based setting. In this series of posts, we will dig a little deeper into these questions. This first part addresses the issues of data safety, and protection against loss and “down-time.” The second part will address the question of security between connections (making sure “the pipes don’t leak”). The third part will focus on privacy and ensuring that only the right people can access the right data.


DATA SAFETY

Medical records – a physician’s charts – are critical and central in a physician practice. It is both a medico-legal record that documents the advice given by the physician to the patient, and is also the core work-flow tool that allows the physician to function. These records must be available on-demand, at all times. Given that only 13% of physicians have any kind of electronic recordkeeping, the majority of medical data is housed in paper charts.

With paper charts, what kind of safety is there? Charts are usually housed in chart racks, and also pile up in various locations around the office (e.g. the physician desk). There is little or no backup of these records in case of some mishap – individual charts can be lost, or some disaster (e.g. fire, water damage, weather events and the like) can wipe out such charts wholesale. When this happens, there is little a physician can do other than start over, and piece together previous data where possible, as if everyone was a “new patient” again.

Migration to EHRs has resulted in an improvement in medical record availability and back-up, when compared to paper. Historically, most EHRs have been locally installed, as client/server systems. There is often a data-backup plan, so that the locally-housed database is backed up somewhere – on tape, disk, or secure offsite backup hosting service. When backed up locally (onto tapes or disks), these backups should be housed off-site (in the event of fire) – in reality, however, adherence to such a plan is hit-and-miss (though still better than with paper).

In a client/server EHR scenario, the bigger question is how to avoid server down-time. As stated, medical record access is a critical core business function for a physician practice (and also for a hospital). Hardware redundancy in the server has become routine – such as arrays of mirrored hard drives which avoid crashes if a hard drive fails. But again, given that these steps involve cost on the server-end, such precautions are hit-and-miss across the landscape. Further, what happens when there is a power outage? Is there battery backup of the server, and at least one workstation in the office? Good safety planning would recommend that these steps be done.

Other local issues have to do with viral infestations and system lock-ups or crashes in the local server. Good IT support is needed when such calamities occur, and often are done via outside vendors, as many smaller practices are not able to hire their own IT support staff. The result can be that down-time of the server can last for hours, even days.

Moving the server-end of EHRs off-site, and onto the Internet “cloud,” reduces these kinds of risks significantly, compared to locally-installed client/server systems. When data and server hosting is taken on by a vendor (such as Practice Fusion), commercial enterprise-level server farms can be used. Biometric security within hosting facilities, multi-geography co-location, and mirrored servers with automatic fail-over in case of server crashes, are all technologies that can be leveraged and offered to all users, even the smallest practices – and would be beyond the reach of what smaller practices could afford were they to do it themselves. Down times are rare, and at worst, are short-lived.

The recent reports of “denial of service” attacks on high-visibility web sites is not so much a “hacking” attack that attempts to penetrate a database and steal information – it is an intentionally simultaneous flooding of a web site in order to cause it to freeze up. Vulnerability of hosted EHR systems to these kinds of attacks has been raised by some observers, and should therefore be mentioned in this “data safety” segment (rather than the “data security” segment, next). There are a number of steps vendors can take to protect against such events, and creation of internal security protocols about this type of attack (done vendor-by-vendor) minimizes the risk to physician end-users.

Of course, the more centralized the data becomes, the bigger the target it becomes (“why do you rob banks? – because that’s where the money is!”). Creating good “locks” to secure the data becomes a focus of “cloud”-based vendors. Data security – making sure that data exchange across the Internet is safe, and that data storage is sufficiently fragmented and encrypted to minimize the risk of hacking – is the focus of HIPAA and ARRA regulation, and is the focus of the next installment in this series.


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

A Measured Approach to De-Identified Patient Data

The first part of this series appeared on July 29.

Benefits of De-Identified Patient Data
For decades, de-identified patient data has been used to support clinical research.

As mentioned previously, the VA intends to extract de-identified patient data from its EHR to improve our understanding of care processes for cancer and PTSD. The research might show that certain treatment plans are more effective in certain patient subpopulations like the elderly or females, or that some approaches are more cost-effective than others.

Similarly, scientists in fields such as diabetes, cardiovascular disease and oncology use de-identified patient data on a regular basis to conduct trials of drugs and medical devices.

Post-marketing research also relies on such data. This is how scientists discovered that Vioxx posed an increased cardiovascular risk. De-identified patient data will undoubtedly be used to assess the safety of the Swine Flu vaccine once it becomes available, and comparative effectiveness research of the sort contemplated by the Obama administration will rely heavily on de-identified patient data as well.

Risks of De-Identified Patient Data
Jay Cline, a prominent expert on patient privacy recently conducted an exhaustive multi-data base review of the matter and was unable to turn up even one case in which a de-identified patient data set had been breached and re-identified with criminal intent.

Why? Cline hypothesizes that for those who seek to profit from the theft of private information, de-identified patient data is far less valuable than say, credit card information. “It's harder to monetize the fact that I know Judy Smith of Peoria has heart disease -- by filing false claims in her name, for example -- than to have Judy's credit card number and expiration date,” he says.

“If I'm a criminal with advanced data skills and I have a day to spend, I'm going to go after financial data and not health data.”

To be sure, there have been cases in which White Hat hackers have succeeded in re-identifying patient data, including Carnegie Mellon computer scientist LaTanya Sweeney’s famously successful effort to identify then Massachusetts governor William Weld’s health information by combing a $20 list of demographic information she obtained off the Internet with a de-identified set of health-insurance information…and that’s what has privacy advocates worried.

What Should HHS Do?

Despite these concerns, HHS should not to wield too heavy a sword in deciding whether to overturn current HITECH legislation, which does not require that patients be notified when their de-identified data is breached.

FTC Delays Enforcement of Red Flags Rule

Just 2 weeks after announcing plans to roll-out its Red Flags Rule on August 1, the Federal Trade Commission has decided to punt on the implementation date until November 1.

The regulation requires creditors and financial institutions to develop identity theft prevention programs.

As described in an earlier post on this blog, physicians that accept health insurance or permit patients to pay in installment plans are going to have to implement written policies and procedures that protect against identity theft in accordance with the Rule, or risk incurring a $2,500 penalty for each “knowing violation.”

Vigorous objections by the Medical Group Management Association and the American Medical Association have been instrumental in delaying the initiation of the FTC program.

Hat tip: Douglas Arnold, Middlesex Professional Services, Middletown, CT.

Glenn Laffel, MD, PhD, Sr. VP, Clinical Affairs

The De-Identification of Patient Data (Part I)

This article is based on a July 24 Computerworld piece by Jay Cline, a former chief privacy officer at a Fortune 500 company who is now president of Minnesota Privacy Consultants.

Many organizations use de-identified patient data—that is, data in which all information that could be used to identify individuals has been removed—to support clinical research and development. The Veteran's Administration for example, has recently announced it will use such data to improve the care for medical conditions ranging from cancer to PTSD. Similarly, private-sector organizations such as IMS Health and SDI Health use de-identified prescriber-level data to create reports that inform the CDC, the US Department of Public Health and most major pharmaceutical companies.

At the moment, the HITECH provisions contained within the American Recovery and Reinvestment Act (also known as the stimulus plan) do not require patient notification when de-identified data are breached.

However, at the request of privacy advocates, the US Department of Health and Human Services has decided to review this policy.

A reversal of the status quo would force health care organizations to notify patients if their de-identified data has been breached.

The consequences of such a reversal are enormous, as the California experience has shown. California recently mandated that patients should be notified when their de-identified data has been breached. This year alone, more than 800 breaches have been reported to the beleaguered state, which has managed to investigate 122 of them.

The state has yet to detect a case in involving criminal mischief, or an intent to use the information for personal financial gain.

How is Patient Data De-Identified?
The Health Insurance Portability and Accountability Act says that health information can be linked with particular individuals if it is associated with any of the following “Direct Identifiers.”
 
1. Names
2. Geographic subdivisions smaller than a state, including street address, city, county, precinct, ZIP code, and their equivalent geocodes, except for the initial three digits of a ZIP code
3. All elements of dates (except year) for dates directly related to an individual (e.g., date of birth, admission)
4. Telephone numbers
5. Fax numbers
6. E-mail addresses
7. Social Security numbers
8. Medical record numbers
9. Health plan beneficiary numbers
10. Account numbers