Spring 2022

Defining the Designated Record Set
By Elizabeth S. Goar
For The Record
Vol. 34 No. 2 P. 10

Discover how the various interpretations of what belongs in the DRS can leave health care organizations short of answers.

The concept of the designated record set (DRS) as the foundation of a patient’s right of access to protected health information (PHI) may have originated in 1996 under the HIPAA Privacy Rule, but it was the 21st Century Cures Act Final Rule in 2020 that thrust it back into the limelight. That’s because the information blocking provision of the Cures Act prohibits providers from interfering with or blocking access to or use of electronic PHI (ePHI) “to the extent that ePHI would be included in a designated record set as defined in 45 CFR 164.501.”

Furthermore, the Cures Act requires certified health IT developers to provide a means to export all of a patient’s electronic health information (EHI) that a certified system contains—for example, when a patient requests their own information or when a health care provider is migrating information from one system to another. The export certification criterion, which relies on the same EHI definition as the information blocking provision, sets a deadline of October 6, 2022, for actors to adhere to the full scope of EHI for purposes of information blocking compliance. Certification to the EHI export criterion is expected by December 31, 2023.

“Under HIPAA, the DRS helps to define an individual’s rights to access, amend, restrict, and acquire an accounting of disclosures of their protected health information,” explains Dan Golder, principal with Impact Advisors. “Individuals have the right to inspect their health information, obtain copies if desired, and request amendments for any incorrect information—all facilitated by a defined DRS definition for each covered entity (CE).”

However, as is often the case, the exact definition of the DRS is open to interpretation. As the EHI Task Force—made up of representatives from AHIMA, AMIA, and the HIMSS EHR Association—noted in its collaborative report, “Defining EHI and the Designated Record Set in an Electronic World,” the term “record” can mean any item collection or grouping of information that includes PHI and is maintained, collected, used, or disseminated by or for a CE. However, CEs generally interpret for themselves which records may be included in the DRS for compliance purposes.

As a result, writes the task force, “There is variation and discrepancy in how health care organizations decide which types of records are included in their DRS. In turn, this has led to longstanding inconsistencies and confusion for CEs and business associates (BAs) over how to comply with federal regulations.”

Not Quite to Each Their Own
Golder points out that individual organizations are in fact required to set their own definitions of DRS because what is set forth in 45 CFR Part 164.501 is not absolute. Rather, he says, each CE is “afforded needed flexibility to define a DRS that meets its specific business needs.”

For example, organizations may have different medical record and billing systems, and different claims, enrollment, and payment profiles. This could potentially result in different DRS definitions.

“The general framework for a DRS will be the same, yet the details are likely to differ between different business entities,” Golder says, adding that “while some may advocate for a single, ‘standard’ definition for the DRS, this would likely prove unworkable given the various business and technical ecosystems in place at different health systems, as well as the varied business and legal structures of CEs that are required to comply with these regulations.”

Joe Licata, chief operating officer and general counsel with HealthMark Group and a member of the Association of Health Information Outsourcing Services, says that while organizations do have some latitude when it comes to defining their DRS, HIPAA sets a minimum standard that varies slightly depending on whether the organization is a health plan or a CE.

From a regulatory standpoint, this is not problematic. “But in practice it gets very confusing, because the sections that hint at flexibility tend to get overemphasized,” Licata says. “What I see in practice is folks generally tasked with compliance at a facility thinking that they can ‘designate’ what is in the DRS—heavily leaning on a colloquial definition of designated—and as long as they are consistent in applying their organization’s definition that they can limit the DRS substantially beyond what the minimum standards are in the regulations. And that’s certainly not a good approach.”

Also troublesome is taking a “possessory narrow approach to DRS that frames around who created the data or information in a way that is not aligned with the regulations themselves,” Licata says.

Defining Guidance
When it comes to establishing a DRS definition, Licata recommends organizations follow in the footsteps of Health and Human Services and take a “patient-first” approach to the rules and understanding what they have, where they have it, and what it is used for. These “are really the critical things to know to functionally have a consistent and compliant DRS at your organization,” he says.

According to Licata, there is specific guidance language around PHI and ePHI usage that can be helpful in assessing the direction an organization should take in defining its DRS. First, if the information is used or is reasonably likely to be used to make decisions—even those unrelated to health care—it’s a safe assumption that information should be included in the DRS. This would encompass all PHI maintained by the CE, such as billing and payment records, insurance information, lab or test results, imaging or X-rays, disease management program files, and clinical case notes.

“As a violation of this rule, I often see a ‘Did we create this record?’ test slip into practice here that has no basis in the regulations,” Licata says. “A completely reverse way to think about it is, if there’s a decision-making function for which the data or information are being collected, then you should almost take a gentle presupposition that it probably is in the DRS unless you’ve got a very good reason why it should be excluded.”

There are exceptions. For example, while clinical case notes are generally included, there is an entire set of exceptions involving psychotherapy notes.

Licata shares that a smart way to tell whether an organization is defining its DRS too narrowly to be compliant with the mandate is to fill in the blank: This part of the file isn’t part of the DRS because .

If the response is any of the following, it likely means a problematic definition is in place:

• We didn’t create this record.
• This is another CE’s record.
• That’s the hospital’s record, not ours.
• That’s not this doctor’s record.
• That’s from the lab.
• We outsource imaging; they can ask the radiology entity for that.
• That patient is unhappy with us, and we anticipate a lawsuit.

“As a side note, I have yet to see an organization that I thought was being ‘too inclusive’ in their definition, and certainly we see lots of reasonable exclusions and a variety of definitions,” Licata says.

When it comes to setting the definition, Licata recommends explaining to key stakeholders what is stored, why, and how to identify and categorize data. He says too many organizations lack basic, functional broad knowledge of how to work in their EMR system. Therefore, he recommends surveying what is in place before worrying too much about drafting a strict definition.

In practices with significant behavioral health and substance abuse treatment functions, establishing a definition gets significantly more complex due to specific restrictions and exceptions governing how that information is handled.

“But to be honest, confusion around the right way to handle that in practices where it is prevalent isn’t what we usually see. Usually there are HIM and administrative process failures to correctly handle the data,” Licata says. “The clinical staff are usually very well trained on those carve-outs and exceptions, since they live it day to day in interacting with patients.”

For its part, the EHI Task Force identified several key considerations when interpreting and applying the definition of EHI. Certain data classes may not be considered EHI, depending on their “status.” For example, some data classes may have a status condition such that it is not used in decision making and therefore would not be considered EHI.

Wrote the Task Force: “There is an inherent challenge in that use of a particular data class in decision making is a key factor in the definition of EHI, but not necessarily easy to track programmatically in an HIT system, leading to actors either casting a wide net as to what is considered EHI or relying on manual identification.”

Among the status conditions identified by the Task Force are the following:

• Unvalidated data. Examples include external records prior to clinical review or reconciliation, device readings that have not been reviewed or checked by a clinician, patient-generated data that are submitted to a clinician prior to clinical review or reconciliation, or data used for teaching workflows if a medical student writes materials that are later validated.

• Draft data. Examples include a clinical note in progress that may be written or edited but not yet signed, reports that are in the process of being written or edited, precharting, and data used for teaching workflows, provided a medical student begins the work and it is later taken over by other authors.

• Duplicative data. When information is maintained in duplicate formats or systems, the holder may have the flexibility to choose from which system the EHI could be produced, eg, audio transcription files and transcribed text or lab result information that is in both a lab system and an EHR and used for decision making.

A fourth status is “data that does not meet the ePHI definition.” According to the report, the Office of the National Coordinator for Health Information Technology defines EHI as ePHI to the extent that ePHI would be included in a DRS, regardless of whether the group of records is used or maintained by or for a CE. However, task force members believed that this broadened the applicability of the definition of EHI 45 CFR 171.102. Yet the definitions of ePHI and “individually identifiable health information,” which helps set the scope of ePHI, indicate that the context of collection and HIPAA definitions still play a role in defining EHI.

The task force went on to state its belief that information must be collected by a CE or BA of the CE when they are acting as CEs or BAs and not as employers or in other capacities. For example, if travel information is collected by a non-CE/BA and would not become part of a medical or billing record, it doesn’t qualify as EHI. However, if that same information is collected by a CE/BA as part of a medical/billing record or potentially used to make a decision about a patient, it would be EHI. Additionally, data classes that aren’t patient identifiable, such as information that lacks the 18 types of individual identifiers under the Safe Harbor standard of the HIPAA Privacy Rule, are not considered EHI.

“In both of these instances, because the data is not considered ePHI, it would not meet the threshold to constitute EHI,” the Task Force wrote.

Evolving Definitions
According to Golder, most organizations have already established clear definitions for both ePHI and their DRS because the latter was defined by HIPAA in 1996. Furthermore, the HIPAA Security Rule requires organizations to complete an annual security risk assessment (SRA) that includes documentation of where ePHI is stored, received, maintained, and transmitted.

The problem is that many of those same organizations fail to routinely update their DRS definitions, even when they conduct annual SRAs.

“Updating DRS definitions to keep pace with our evolving technological systems seem to fall by the wayside,” Golder observes. “This is unfortunate, as innovations, including telemedicine, the ubiquitous use of cell phones and apps, smart medical devices, patient portals, secure messaging with providers, and FHIR [Fast Healthcare Interoperability Resources], have all fundamentally changed how we access, use, and collect personal health information. And our DRS definitions should be amended accordingly.”

Fortunately, he notes, many organizations are now reexamining and updating their DRS definitions in light of the information blocking rules. They have focused on documenting these new sources of ePHI that patients, providers, and health systems are now leveraging on a daily basis.

However, as EHR systems evolve and new technologies are implemented, many organizations would benefit from revisiting their existing DRS definitions. When they do, Golder says, they should “focus on new and emerging technologies added to their technical ecosystems since the time they last updated their DRS, especially in areas where patients have been driving such innovation.

“With the advance of electronic technologies to assist with collecting medical information—think Fitbits or connected smart glucometers as examples—the definition of where electronic health information originates and the type of media where it is recorded is expanding, and that means our definitions of EHI, and our DRS, should be evolving as well.”

In fact, according to Golder, given the pace of technology, it is likely that the definition of each organization’s DRS will remain fluid for the foreseeable future. He recommends reviewing and updating DRS definitions annually in conjunction with annual SRAs to ensure any new sources of ePHI are identified and added to existing definitions.

Shades of Gray
“[Ultimately,] each organization will have different degrees and areas of gray when defining their DRS,” Golder says.

For example, each state may have different laws governing how CEs are required to handle, document, and administer PHI, ePHI, and EHI. Other considerations include the standards and requirements of third-party payers and the requirements of various regulatory bodies. Technologies and sources of ePHI are also likely to differ between organizations, necessitating the need for customized DRS definitions for each organization.

With so many moving parts, tapping experts for guidance is a smart move. Among these are professional, federal, state, and legal organizations such as AHIMA and Law Insider. All offer opinions, guidance, and sample documents for helping organizations define their DRS or update their definitions.

As a first stop, Licata suggests organizations look to their release of information vendor, which typically has experience in “hundreds of slightly different approaches to these operations that can inform how to do it.”

He adds: “Because we get onboarded into the compliance environments of our clients, and to the extent we can mold ourselves around their expectations, we certainly do and we can probably facilitate a discussion with someone who we think handles these processes well and is in the same practice area, etc. We wouldn’t share that information without the other party’s consent of course, but usually folks are willing to share best practices.”

The impact of getting the DRS definition right goes beyond regulatory compliance, Licata says. It also impacts patient satisfaction. “In the simplest way, it’s just about expectations,” he says. “When patients request access to ‘everything,’ they probably anticipate they’re getting ‘everything,’ so confusing applications of exceptions or legalese can be really frustrating.

“The mental paradigm of patients has shifted over the past 30 years—in no small part due to HIPAA,” he continues. “Patients view most information that’s about them as rightfully theirs to control and possess if necessary, and they care about what personal information is being held by their providers.”

— Elizabeth S. Goar is a freelance writer based in Wisconsin.