Why New Healthcare Technology Needs to Keep eDiscovery in Mind

For Healthcare Service Providers, new technologies to capture healthcare data can also create eDiscovery challenges. Previously healthcare records were kept in paper. But as a part of the American Recovery and Reinvestment Act, all public and private healthcare providers were mandated to adopt the use of electronic medical records by 2014. Since then the use of electronic record keeping has spread worldwide. The drive to digitize patient records makes these records a rich source of information.

Electronic health records include huge amounts of patient demographics, provider notes, prescribed treatments, medical histories, test results and reports. Moreover the technological equipment used in the process of diagnostics and treatment also create an abundance of data and information. These records, then, are appealing targets for eDiscovery in a variety of litigation and investigatory contexts.

Other new technologies to capture healthcare information have also been growing rapidly. The use of mobile devices in the provision of health care, known as Mobile health or “mHealth” have allowed for the delivery of healthcare from anywhere possible. There are thousands of health applications that can assist with many health related tasks like health records maintenance and access, patient management, sensor data collection numerous, health statistics, confidential communication.

Technological Advances Made Without eDiscovery Considerations

The challenge within the eDiscovery context is that most, if not all, of these new technological advances were not created with eDiscovery in mind.

Many of these systems were not created with the purpose of having a physical manifestation of the records. Rather, what the healthcare provider sees when they use an electronic medical record is a computer screen and not what eventually gets exported or printed. What a doctor sees on the screen may not be reflected in what ultimately gets produced to the opposing side. There is an application layer, a UI, and a data storage mechanism that may be difficult to collect from in an understandable format. Further, for many of these systems, extracting specific data regarding specific individuals or claims, as it is stored in the normal course of business, may be impossible to collect.

To address some of these challenges accommodations for forensic collection of this data may be necessary. For a given system, forensic collection may not be the best approach. For example, exporting structured data from electronic medical records applications for a specific individual may not be possible without exporting the data for all individuals’ data being stored. In this case, producing the records for a specific individual may require a stakeholder within the healthcare provider network manually generating a report that only includes the individual’s health information.

Similarly, in a matter in which the underlying claim is based on a billing practice without regard to the individual patients, generating reports with respect to the billing while eliminating the patient information may also require manual report generation. This will not only be more cost-effective than exporting all structured data held by an entity but it also eliminates risk of disclosure of protected health information. Data sampling of records is another solution for the challenge of collection and production of structured data in healthcare litigation. Previously used in litigation and investigations for other data-heavy industries (e.g. insurance), sampling portions of a data set for relevancy prior to full collection, have provided substantial costs savings. Regardless of the approach, if the collection process falls outside of the typical parameters, agreement between the parties and a full understanding of the systems that are generating the data will be required. There have been a few recent cases that have addressed some of the issues that have come out of the production of these new technologies.

Discovery of Patient Charts, Medical and Diagnostic Records, Metadata, and Audit Logs

A great deal of cooperation is required among parties, their counsel and other stakeholders in a dispute as to what information exists, is worth extracting, can be extracted in a targeted and meaningful way, and can be explained based on the context from which it was extracted. For example, each medical record in charts and in diagnostic and monitoring equipment contains the patient information and medical information. It also contains metadata about how and when the patient and medical information was written, when it was accessed by whom, and when it was transmitted, opened, read, printed, commented or edited. Unlike the vast stores of emails and Office files that are the subject of most eDiscovery, in the medical records and devices context, this metadata may be hidden or embedded, encoded and in proprietary format. The degree to which counsel can gain an understanding of the records and metadata needed, the better the chance of managing risk and cost in eDiscovery.

One eDiscovery issue in Puerto Rico Medical Emergency Group, Inc., v. Iglesia Episcopal Puertorriqueña, Inc. illustrates the problem. One party responded to a discovery request for a range of medical billing information with millions of records in PDF format. The requesting party objected to what it regarded as a data dump in an unusable format, despite its [failure to?] request native Excel files or a similar format. The court had enough information to order re-production in the correct format, but the requesting party did not have or provide enough information on how it needed the data filtered to limit the response to only what it needed. Understanding the time and expense already incurred by both parties, the Court added, “[i]n their best interests, the parties may want to communicate regarding the scope of the data required.”

According to AHIMA,7 many healthcare IT systems have a common metadata. It may be expressed as follows:

Understanding whether the information you seek or need to produce has a common metadata pattern is the first step to accurate request or production. The second is to understand where and how the elements of data are stored. They may be on-board a device, transmitted to local storage, centrally stored in available medical records, cloud-stored, and in either a format readily exported or in a format requiring complex query or some routine scripting.