In medical malpractice (medMal) cases, electronic health records (EHRs) are crucial for both defense and plaintiff’s counsel, in-house counsel for hospitals, and risk managers for medMal insurance groups. The complexity of Health IT systems and the associated data have made eDiscovery increasingly challenging, with disputes often arising over the data produced or not produced. This article sheds light on key factors and trends in the discovery of EHRs in medical malpractice cases and offers insights into navigating these complexities.
Recent Trends – Increased Focus and Burden on Electronic Record Discovery
Medical malpractice cases typically include the review of a set of electronic medical records produced under discovery, as both sides rely on such data to determine the relevant facts and form expert opinions. Increasingly, the exact set of data produced or withheld is the subject of major disputes in the discovery process.
This trend is due in large part to the increased complexity of Health IT systems as well as an increased volume and complexity of associated Health IT data. There is no longer a one-size-fits-all solution for eDiscovery in medical malpractice cases, and the historic concept of a “single file” which contains all of the data and metadata that a healthcare organization can hand over to the other side is no longer reality. The current reality for large health systems is that a single patient’s information is spread out across different vendors and IT systems, and can require extensive cost and expertise to access, extract, and interpret the totality of the data. Furthermore, it’s often the case that this volume of data isn’t relevant or useful to the particular questions at issue in the matter.
In addition to the focus on the software systems in the discovery phase, a unique subset of medical malpractice claims allege the Health IT or medical device software itself is the cause, or at least contributed to personal harm. Typically, these claims allege that this is due to a software error, or “bug,” or simply a highly confusing user interface. Such cases are likely to increase with the proliferation of artificial intelligence in healthcare software, such as clinical decision support algorithms.
Regardless of the role of Health IT in these cases, confusion often abounds due in part to a lack of consistent Health IT terminology, where terms such as “medical record,” “audit report,” and “clinical notes” can mean different things based on the context (e.g., regulatory, vendor-specific, court-defined) and the audience ( e.g., regulators, software vendors, healthcare organizations, counsel, or the courts).
We take a closer look at each of these trends and key factors in the remainder of this article.
Key Considerations in Discovery:
Courts typically take into consideration a range of factors when evaluating what to ultimately require a party to produce in a medical malpractice litigation. Three high-level categories of factors include:
- Health IT Laws and Regulations
- Federal regulations such as HIPAA, the 21st Century Cures Act, ONC’s Certified Health IT regulations, and FDA-regulated systems provide guidance for the discovery process. However, a judge’s discovery order can go beyond these regulations. Understanding these laws and regulations is crucial for both plaintiffs and defendants when preparing for medical malpractice cases.
- Burden
- Both plaintiff and defense sides must consider the effort required to produce and analyze the requested information. Understanding the capabilities of the Healthcare IT systems and the specific implementation at the healthcare institution is essential. Evaluating the burden involves considering the relevant time period, the type and volume of medical data, and the technical effort and skill required to extract the data.
- Relevance
- In medical malpractice cases, requests for data production may be extensive, but not all data is relevant to the case. Factors to consider when determining relevance include how the data was typically utilized or acted upon by the end user and whether the data was ever seen or utilized by the healthcare provider or caregiver. It is crucial for both plaintiff and defense to weigh the relative importance of the data and ensure that time and money are spent efficiently.
We look at each of these categories below.
a) Health IT Laws and Regulations
In the United States, parties and the courts (typically state courts in medical malpractice) often look towards federal regulations for guidance of what information should be produced in the context of a medical malpractice case. However, it is important to understand that a judge’s discovery order can go above and beyond any such regulation, and a full legal and regulatory analysis is beyond the scope of this article.
In summary, there are a few different areas of federal regulation that cover a patient’s medical data, and the Office of National Coordinator (ONC)- and Food and Drug Administration (FDA)-regulated systems used to store such data. The laws and regulations most often referenced are:
- HIPAA and related Updates and Rules (a broad set of laws and regulations, which have been updated over time since 1996)
- The 21st Century Cures Act and the ONC’s (Office of National Coordinator for Health IT) Information Blocking Rule
- ONC’s Certified Health IT regulations covering EHR vendors and CMS’s various incentive programs (e.g., Meaningful Use, Quality Payment Program, MACRA, etc.) which either historically or currently apply to eligible hospitals and healthcare providers
- FDA-regulated systems (these include systems that store data from Laboratory, Medication/Pharmacy, Imaging, Medical Devices, and others)
We briefly cover below some of the ways these regulations intersect with medical malpractice discovery proceedings:
HIPAA
The HIPAA Privacy rule addresses the use and disclosure(s) of an individual’s “protected health information” (PHI) to include their right of access to PHI in the hospital’s designated record set(s) (DRS). Given that a patient has the right to access this PHI under normal circumstances, it is not surprising that it is often referenced in a patient’s discovery request. Specifically, under HIPAA’s individual right of access, it is up to each healthcare organization to define their designated record set (DRS) which will dictate what information is provided to the patient when they request their electronic medical record. It is important to note that differences across EHRs and differences in the DRS definitions across hospitals can result in vastly different levels of information being shared with the patient.
One common type of data that is often under dispute in medical malpractice cases is audit or access data or metadata. Industry experts and Health IT professional societies have long held that “data such as audit trails, metadata…are not included in the definitions for these record sets.” [1] HHS has clarified that an individual does not have a right to access PHI that is not part of a designated record set ‘because the information is not used to make decisions about individuals.” Hospitals are not required to create additional information that is not already in the DRS. [2]
While HIPAA’s individual right of access rule, along with each institution’s DRS dictates what information must be shared with a patient when they request their medical record, medical malpractice cases often include discovery request for information that extends well beyond what is required to be shared with the patient per the right of access rule.
21st Century Cures Act and Information Blocking
The 21st Century Cures Act, passed into law in 2016, included a goal of providing seamless and secure access, use, and exchange of health information. The Act led directly to regulations from the Department of Health and Human Services (HHS)/ONC and Centers for Medicare & Medicaid Services (CMS) that address the goals of seamless and secure access, use, and exchange of “Electronic Health Information” (EHI). ONC defined EHI (which is intentionally aligned with HIPAA e-PHI) as the DRS. ONC also put forth “Information Blocking” regulations addressing exceptions to sharing of EHI that would not constitute information blocking. Information blocking is any practice that, except as required by law or covered by a (very rare) exception, is likely to interfere with access, exchange, or use of EHI. As of October 2, 2022, Information Blocking provisions apply to “all EHI” (i.e., e-PHI in the DRS).
While these regulations may offer broader access to certain sub-components of EHI in certain circumstances, they do not go as far as some medical malpractice attorneys or experts may assume. For example, with regard to audit and access data in particular; these data are not medical data, are not e-PHI, nor are they in the DRS, thus it is not data required to be shared/given access to per HIPAA individual’s right of access nor EHI for purposes of information blocking. Most recently, and in response to the new regulatory concept/definition of EHI, a task force of leading informatics bodies (i.e., AHIMA, AMIA, and EHR Association) formed an EHI task force and produced a detailed report that specified “audit trail” and “event logs” are not considered e-PHI, part of a DRS, nor EHI. [3]
ONC Certified Health IT
With regard to ONC’s regulations for Certified Health IT, which govern EHR vendor software, this is again a very broad set of regulations, which focus on describing the functionality that an EHR software should possess. Of particular interest in medical malpractice cases are the requirements for “auditable events” [4] and “audit reports.” [5] While the regulation does require certain elements and functionality to be present within the software, the implementation and capabilities of each system varies not only from EHR to EHR but also the same EHR system can vary in its implementation from hospital to hospital.
In summary, while these laws and regulations include numerous specific requirements for healthcare providers and institutions, when it comes to what data must be stored or exchanged under various use cases, they do not prescribe the exact set of data that a patient must be given access to from a particular set of IT systems installed at a particular hospital. In fact, these laws and regulations often leave that decision in large part to each healthcare provider or institution, and of course, the courts still have the ultimate say and can require additional information to be produced.
b) What Is the Burden?
It is important for both plaintiff and defense sides to have an understanding of what level of effort it may take for the requested information to not only be produced but also analyzed. However, before the question of burden can be addressed, the functional questions of what the software is capable of, and what type of data generally exists in the systems should be addressed.
What Is the Software Capable of and What Type of Data Exists?
Given that regulations and industry standards don’t determine exactly what set of data a healthcare provider or EHR/technology vendor must provide in a medical malpractice matter, it is important for both plaintiffs and defendants to have an understanding of what each Healthcare IT system is capable of (as implemented) in regards to generating medical information. Common questions to answer include:
- What EHR system is utilized at the institution, what version, and how long have they been using it?
- Is the EHR system capable of exporting revision histories?
- Is the EHR system capable of exporting revision histories that include attribution data, such as who added what line of text and when (or if the line of text originated from a copy & paste or a template)?
- Is the EHR system capable of providing redline type revision histories?
- What types of events are captured in the EHR and the audit report?
- Is there any information contained in the patient’s record that is only viewable on-screen within the EHR versus the printed or exported medical record?
- Does the EHR integrate with medical devices? If so, is that data included in the medical record?
- Does the EHR integrate outside medical information (such as those from an HIE or HISP) into the patient’s record? If so, is that data included in the printed or exported medical record?
- Are there any data sources available that are not included in the EHR such as medical device data or systems that do not integrate with the EHR?
- Who within the organization is most familiar with the EHR’s capabilities? Keep in mind that it often is not a single person but several teams.
While this is not an exhaustive list of questions, it provides a good starting point to gain an understanding of the capabilities of implemented Healthcare IT software. It is important to note that not all installations of any given EHR are the same. For example, a healthcare institution that utilizes Epic may be configured to integrate medical device data (such as vitals monitors) to populate the patient chart automatically, while another institution also using Epic may have to manually enter vital information. Just because one hospital can perform a certain task, does not mean all hospitals have the same capabilities. This is especially true in the systems capability to export the medical record and audit reports. Although a base level understanding of each EHR’s capability is valuable, care must be taken to ensure you understand the specific capabilities of the EHR as it is implemented at any given healthcare institution.
Quantifying Burden
Although it may be possible for knowledgeable users of the EHR system to generate vast amounts of data related to a patient’s medical record, it is important to understand what level of effort it would take to generate such data. While it may be technically possible to develop and generate new reports or otherwise obtain more data, it is important to keep in mind the work associated with not only producing that data but also analyzing it. Data that is seemingly simple – such as note revisions coupled with audit report data – can be expensive and time consuming to extract and evaluate.
Things to consider when quantifying the burden:
- What period of time is relevant to the case?
- What type and volume of medical data is relevant to the case? (This can range from a single laboratory result sent on a single day, or it can include a much longer or complex history with multiple visits and thousands of data points).
- Who has access to the data and what level of technical effort and skill are needed to extract the data? (In some cases, the data can only be extracted by third parties, such as the software or device vendor).
c) What Is the Relevance or Importance of the Data?
Production requests in medical malpractice cases often include a “give us everything” approach. While it may be technically possible to account for and produce literally every piece of data generated by EHRs and medical devices for a particular patient, much of this data is often irrelevant to the case – and for some patients may include decades worth of medical data. Although it is sometimes possible to generate “lower level” data such as system logs, error logs, database extracts, transform, load (ETL) logs, and interface logs much of this data is irrelevant (except in specialized cases such as forensic investigations, claims of spoliation, or in cases where an IT failure is alleged) and can often lead to wasted budget.
There should be consideration from a medical perspective of which parts of the medical record are relevant which we don’t cover in detail here.
Important considerations when it comes to relevance, from a technical perspective, are:
- As a matter of practice, how was such data typically utilized or acted upon by the end user?
- It is important to keep in mind that most healthcare organizations have their own unique Standard Operating Procedures (SOPs), and they don’t use specific vendor software programs (like Epic or Cerner) in the same manner, which can lead to false assumptions about the existence/non-existence or relevance of particular data fields for a particular instance or case.
- In specific cases, was the data ever utilized or seen by the healthcare provider or caregiver?
- If data isn’t viewable or visible to a caregiver, it could be irrelevant or less relevant.
Notwithstanding the above considerations, care should be taken to ensure relevant data is requested and shared. In conjunction with the burden of generating and analyzing the data, both plaintiff and defense should weigh the relative importance of the data to ensure time and money are spent most efficiently.
Conclusion
Navigating the complexities of EHR discovery in medical malpractice cases is a challenging task for all parties involved. Understanding the laws and regulations governing Health IT, assessing the burden of data production and analysis, and determining the relevance of the data are critical steps in the process. By considering these factors and staying informed of the latest regulatory trends and events, defense and plaintiff’s counsel, in-house counsel for hospitals, and risk managers for medMal insurance groups can more effectively manage the discovery process and ultimately better serve their clients.
Quandary Peak Is Focused in Health IT and Medical Malpractice
Quandary Peak Research is the nation’s leading compliance and litigation consulting firm specializing in software and IT. Our Health IT group comprises experts in computer science, clinical informatics, patient safety, privacy, cybersecurity, and government regulations. We offer tailored guidance in a wide range of Health IT regulatory, IP, and litigation matters. Our clients include top law firms, hospitals, patients, EHR vendors, medical device manufacturers, pharmaceutical companies, government agencies, and federal and state courts.
For our clients in professional medical liability (i.e., medical malpractice) our Health IT experts assist with increasing volumes and complexity of data in EMRs and other systems in medical malpractice disputes. We review audit logs and medical records from major EHR platforms, provide litigation strategy consulting, and assist in active litigations, providing affidavits, expert reports, and testimony.