This guide to HIPAA designated record sets is designed to reduce common misunderstandings about how individually identifiable non‑health information may become Protected Health Information (PHI) when it is maintained in a designated record set, and what information patients have the right to access, amend, or request restrictions on under HIPAA.

Understanding how HIPAA defines and protects patient information requires more than familiarity with the term “Protected Health Information.” HIPAA treats information contextually, and whether a non-health data element is protected often depends on how it is maintained and used within the organization.

This is why the concept of HIPAA designated record sets is so important to HIPAA compliance. The designated record set determines which information falls under HIPAA’s privacy protections and becomes subject to individual rights such as access and amendment. When organizations misunderstand what belongs in a designated record set, they risk misclassifying information, mishandling access requests, and applying HIPAA protections inconsistently.

This guide explains how HIPAA designated record sets function, how non‑health information may assume HIPAA protections by virtue of its context, and how federal and state confidentiality laws and minor‑consent statutes interact with HIPAA’s framework.

Although written primarily for healthcare providers, who typically maintain patient information across diverse operational systems, this guide is equally relevant to health plans and business associates responsible for classifying HIPAA‑regulated data and responding to access requests.

Why Understanding HIPAA Designated Record Sets Matters

HIPAA designated record sets sit at the center of HIPAA’s privacy and individual rights framework, yet they are often misunderstood. These misunderstandings have real consequences because HIPAA does not protect information based solely on where it is stored or the category of information it represents, but rather on how the information is used and whether it resides within a designated record set.

HIPAA designated record sets matter for three reasons:

• They determine when individually identifiable non‑health information may be treated as PHI.
  HIPAA protects information contextually. A piece of information that is not inherently health‑related, such as a name, address, or scanned ID, may assume HIPAA protections when it is maintained within a designated record set if it becomes part of the records associated with an individual’s care or benefits. The same information stored elsewhere may not be PHI at all.
• They define the scope of patient access and amendment rights.
  Individuals have the right to inspect, obtain copies of, and request corrections to information in HIPAA designated record sets. If an organization misidentifies what is or is not part of a designated record set, it may improperly deny access, fail to amend inaccurate information, or disclose information that should not be disclosed. These errors are among the most common sources of HIPAA complaints and enforcement actions.
• They determine which information is subject to HIPAA’s privacy and security protections.
  Information outside of HIPAA designated record sets may not be PHI under HIPAA, even if it identifies an individual. Conversely, information inside a designated record set can be protected as PHI even when it is not inherently health‑related. Misunderstanding this distinction can lead to the over‑protection of non‑PHI, the under‑protection of PHI, or the failure to apply other federal and state confidentiality laws that may govern the same information.

Misunderstandings can also lead to:

• incomplete or delayed responses to access requests,
• improper denials of access or amendment,
• unauthorized disclosures of specially protected information (e.g., Title X, Part 2, minor‑consent records),
• inconsistent handling of patient information across departments,
• gaps in HIPAA Security Rule risk analyses,
• litigation exposure when records are omitted or misclassified, and
• erosion of patient trust.

Understanding designated record sets is therefore essential not only for HIPAA compliance but also for ensuring that individuals can exercise their HIPAA rights and that organizations apply privacy protections consistently and appropriately.

The Definition of a Designated Record Set Under HIPAA

HIPAA’s designated record set concept reflects the Privacy Act’s principle that individuals should have access to records used to make decisions about them. HIPAA applies this principle to healthcare entities and expands it to include medical and billing records. Under §164.501 of the HIPAA Privacy Rule, HIPAA designated record sets are defined as:

“A group of records maintained by or for a covered entity that is:
(i) The medical records and billing records about individuals maintained by or for a covered health care provider;
(ii) The enrollment, payment, claims adjudication, and case or medical management record systems maintained by or for a health plan; or
(iii) Used, in whole or in part, by or for the covered entity to make decisions about individuals.”

The word “or” in the definition means that each category stands independently:

• Category (i): All medical and billing records maintained by or for a provider automatically qualify as HIPAA designated record sets.
• Category (ii): All enrollment, payment, claims adjudication, and case or medical management systems maintained by or for a health plan automatically qualify.
• Category (iii): Any other clinical or administrative records that do not qualify under categories (i) or (ii) qualify as a set – or part thereof – if they are used to make decisions about individuals.

HIPAA defines a record broadly as any item, collection, or grouping of information that includes PHI and is maintained, collected, used, or disseminated by or for a covered entity. This means HIPAA designated record sets may span multiple systems, formats, and data types, and may even consist of a single document.

A Recap of the Definition of Protected Health Information

Protected Health Information is individually identifiable health information created or received by a covered entity or business associate that relates to an individual’s health, the provision of healthcare, or payment for healthcare. Any individually identifiable non-health information becomes PHI when it:

• identifies an individual or could reasonably be used to identify them, and
• relates to health, healthcare, or payment.

HIPAA protects non-health information contextually. Individually identifiable non‑health information may assume HIPAA protections when it is maintained within a designated record set because it becomes part of the records associated with an individual’s care or benefits. Examples include demographic data, financial identifiers, scanned identification documents, and administrative attachments stored in an EHR or billing system. The practical effect of context determining protection is that:

• The same piece of information may be PHI in one context and not PHI in another.
• The same identifier may be protected under HIPAA in one system but not in another.
• The same data element may be subject to access rights in one location but not in another.

Note: With regard to the “18 HIPAA identifiers”, these originate from the HIPAA Safe Harbor de‑identification method and do not define PHI. Because PHI is defined by function and context, information that identifies a person in connection with healthcare qualifies as PHI even if it does not appear on the Safe Harbor list. Conversely, information that identifies a person, but is unrelated to healthcare, is not PHI even when maintained in the same designated record set as PHI.

Case Study 1: Emotional Support Animal Details as PHI

A behavioral health provider documents that a patient owns a rare, easily identifiable emotional support animal. Although “animal details” are not one of the 18 HIPAA identifiers, the information can identify the patient and relate to care. It is therefore PHI and, because it appears in the medical record, is automatically part of the designated record set.

Case Study 2: PHI vs. Non‑PHI in Operational Systems

A hospital parking garage maintains a database of license plate numbers, credit card numbers, timestamps, and stall assignments in the same designated record set as patients’ PHI. None of this information relates to healthcare or payment for healthcare. Even though some identifiers appear on the HIPAA Safe Harbor list, the data is not PHI because it is not connected to treatment, care, or payment.

Specially Protected Categories of Patient Information

Some categories of patient information are subject to heightened protections under federal or state law, regardless of whether they are included in a designated record set. These laws may restrict disclosure, limit parental access, require specific consent, or impose redisclosure prohibitions that override HIPAA.

• 42 CFR Part 2: Protects substance use disorder treatment records. These records may be part of a HIPAA designated record set but cannot be disclosed without patient consent or a specific exception.
• Title X: Protects information related to family planning services for minors.
• State minor‑consent laws: May grant minors exclusive control over certain categories of information.
• State mental health confidentiality laws: May impose additional restrictions on psychotherapy notes or mental health evaluations.
• Other federal and state protections: Such as Family Violence Prevention and Services Act (FVPSA) confidentiality requirements or CMIA in California.

These overlays mean that inclusion in a designated record set does not automatically determine whether information can be accessed or disclosed. The most protective standard typically governs.

Healthcare providers must implement reliable methods for identifying and segregating specially protected categories of information within a designated record set to prevent impermissible disclosures. Because HIPAA allows broad use and disclosure of PHI for treatment, payment, and healthcare operations, but other federal and state laws impose stricter rules, tagging is essential to ensure that these stricter standards are honored.

Effective document, encounter, and data element tagging, role-based access controls, and automated disclosure-blocking rules allow organizations to maintain a unified medical record while still applying heightened protections to sensitive data.

Multiple HIPAA Designated Record Sets and Single Record Sets

As mentioned previously, the definition of a designated record set in §164.501 of the HIPAA Privacy Rule notes that “the term record means any item, collection, or grouping of information that includes Protected Health Information and is maintained, collected, used, or disseminated by or for a covered entity.”

This is important because it means that a covered health care provider can maintain multiple designated record sets for the same patient. For example, a provider might maintain separate sets of patient information for clinical care, specialty care, and billing. Payment plans and financial assistance programs may also qualify as sets.

Other reasons why a health care provider might maintain multiple HIPAA designated record sets for patients include incompatible data structures between systems, different retention rules, and compliance with minimum necessary and role-based access standards. It may also be the case that some patient information is maintained on paper or in legacy systems.

The inclusion of “any item” in the definition means a designated record set can consist of a single item of medical or billing information which, unless it is de-identified, will also qualify as PHI. This matters because a covered entity must be able to identify every location where designated record sets are maintained in order to meet the patients’ rights requirements of the HIPAA Privacy Rule.

At the same time, the HIPAA Security Rule requires covered entities to know where PHI is created, received, stored, or transmitted so they can conduct risk assessments. Understanding that even one document can constitute a designated record set reinforces the need for clear visibility into both where designated record sets reside and where PHI exists across the organization.

Case Study 3: A Standalone Patient Authorization as a Single‑Item Designated Record Set

A patient signs an authorization allowing the clinic to release PHI to an attorney for a non‑routine purpose. Instead of scanning the authorization into the EHR, the clinic’s Health Information Management (HIM) department stores the original signed form in its Release‑of‑Information (ROI) system. The ROI system is separate from the medical record and the billing system, and the authorization is kept there as the only document associated with that request.

The signed authorization contains the patient’s name, date of birth, and details about the PHI to be disclosed, so it is PHI. It is also used to make decisions about the individual, specifically whether the clinic is permitted to release the requested information. Because it is maintained in a system that is not part of the medical or billing record, the authorization does not become part of those record sets.

Instead, the authorization itself becomes a single‑item designated record set under the third category of the HIPAA definition: a record used, in whole or in part, to make decisions about individuals. Even though it is only one document, the patient has the right to request access to it, and the organization must include it when responding to an access request.

Case Study 4: A Baby Photo That Is PHI but Not Part of a Designated Record Set

A pediatrician keeps a “baby wall” in the clinic hallway with photos of former patients. One of the photos shows an identifiable infant and includes the child’s first name and birth month. Because the photo reveals that the child received care from the practice, it qualifies as PHI. However, the photo is not part of the medical record and is not maintained within any medical or billing record system. It is displayed for decoration and does not document treatment, support clinical decision‑making, or serve any billing or operational purpose.

Since HIPAA defines the designated record set as the medical and billing records maintained by a provider, the baby photo – while PHI – is not part of the designated record set and does not need to be produced in response to an access request.

Patients’ Rights to Access, Amend, and Withhold Protected Health Information

HIPAA grants individuals several rights related to designated record sets, including the right to access, amend, and request restrictions on the use and disclosure of their PHI.

The right of access allows individuals to inspect or obtain copies of their PHI in HIPAA designated record sets. The right of amendment allows individuals to request corrections to inaccurate or incomplete information in the sets. Covered entities must review the request, determine whether the amendment is appropriate, and document their decision.

The right to request restrictions allows individuals to ask covered entities not to use or disclose certain PHI for treatment, payment, or health care operations. While covered entities are not required to agree to most restrictions, they must honor restrictions on disclosures to health plans when the individual pays out of pocket in full.

These rights reinforce the importance of accurately identifying HIPAA designated record sets. If information is part of a designated record set, it is subject to these rights. If it is not, the rights do not apply. Covered entities must therefore maintain clear policies and procedures for classifying information, responding to requests, and documenting decisions.

Case Study 5: Operational Information About a Patient That Falls Outside the Designated Record Set

A large outpatient clinic uses a visitor management system (VMS) to track everyone who enters the building. The system captures each visitor’s name, the time they arrived, the time they left, and the reason for their visit. When patients check in for appointments, they also pass through the VMS, which records their arrival time and the name of the provider they are scheduled to see. The VMS is used exclusively for building security, emergency evacuation procedures, and general operational oversight. It is not connected to the electronic health record (EHR), billing system, scheduling system, or any clinical workflow.

A patient submits a HIPAA access request asking for “all information the clinic maintains about me, including logs of my arrival and departure times.” The clinic’s Health Information Management (HIM) department reviews the request and determines that the VMS data is not part of any designated record set. The information is not a medical record, not a billing record, and not used to make decisions about the individual’s care, benefits, or financial responsibility. It is also not incorporated into any system that constitutes a designated record set under §164.501.

Because the VMS data does not meet any of the three criteria, it is not subject to HIPAA’s access or amendment rights. The clinic responds to the patient by providing all information contained in HIPAA designated record sets but explains that building security logs are not part of a designated record set and therefore are not included in the HIPAA response.

Operational Considerations for Managing HIPAA Designated Record Sets

Understanding the definition of HIPAA designated record sets is only the first step for compliance officers, HIM leaders, privacy teams, and business associates. Compliance officers (et al.) must also translate that definition into day‑to‑day operational practices that ensure HIPAA compliance across complex, distributed information environments.

Modern healthcare organizations maintain patient information in dozens of systems, platforms, and archives. Many of these may contain a mixture of PHI, non‑PHI, DRS content, and non‑DRS content. Without clear operational structures, even a correct conceptual understanding of HIPAA designated record sets can break down in practice.

The following sections outline operational considerations that organizations must address to manage HIPAA designated record sets (DRS) effectively. Together, these considerations form the operational backbone of a compliant DRS program and ensure that individuals can meaningfully exercise their rights under HIPAA.

Building and Maintaining a DRS Inventory

A comprehensive DRS inventory is essential for ensuring HIPAA compliance and for enabling organizations to respond accurately and consistently to patient access, amendment, and restriction requests. Because modern healthcare environments rely on multiple systems, organizations must identify every location where DRS‑eligible records are created, stored, or maintained.

An effective inventory documents not only the systems themselves but also system owners, data stewards, retention rules, access pathways, and any system‑specific limitations that may affect how information is retrieved or amended.

A complete inventory must also include paper archives, scanned documents, and legacy systems that remain accessible for historical reference. These systems often contain PHI that qualifies as part of the DRS even if they are no longer actively used. The inventory should align with the HIPAA Security Rule’s asset inventory so that privacy and security teams share a common understanding of where PHI resides.

Because healthcare organizations frequently undergo EHR upgrades, vendor transitions, mergers, and acquisitions, the DRS inventory must be updated regularly to reflect changes in system architecture and data flows. Without a current and accurate inventory, organizations cannot reliably meet their HIPAA obligations or ensure that individuals receive complete and timely access to their information.

Conducting the Decision‑Making Analysis for Category (iii)

Category (iii) of the definition of a designated record set under HIPAA requires a functional analysis rather than a system‑based one. A record qualifies for inclusion when it is used, in whole or in part, to make decisions about individuals. This includes decisions related to treatment, benefits, eligibility, case management, care coordination, utilization review, or other determinations that affect the individual’s care or financial responsibility.

Records such as care coordination notes, case management documentation, external consult reports, and HIE data incorporated into clinical workflows typically meet this standard because they inform clinical or administrative decisions.

Conversely, records that are not used to make decisions about individuals generally fall outside the DRS. Examples include quality improvement reports, peer review materials, internal business planning documents, and administrative workflow notes. These records may contain PHI, but they are not used to guide care or benefits for specific individuals.

Because the decision‑making analysis can be nuanced, organizations should document their rationale for including or excluding specific record types. This documentation supports consistency across departments, reduces the risk of improper access denials, and provides defensibility during audits or investigations. A clear, repeatable analysis ensures that the DRS reflects how information is used, not merely where it is stored.

Redisclosure Rules and Their Interaction with the DRS

Even when information is part of a DRS, redisclosure may be restricted by federal or state confidentiality laws that impose stricter protections than HIPAA. For example, 42 CFR Part 2 governs substance use disorder treatment records and prohibits redisclosure without patient consent or a specific regulatory exception, even when the records are part of the DRS.

Title X family planning records for minors may not be disclosed to parents without the minor’s consent, regardless of their inclusion in the DRS. State minor‑consent laws may similarly restrict parental access to mental health, reproductive health, or STI‑related information.

State mental health confidentiality laws may impose additional restrictions on psychotherapy notes, mental health evaluations, or behavioral health records. FVPSA confidentiality rules protect information about individuals receiving domestic violence services and may prohibit redisclosure even when HIPAA would otherwise permit it. When records contain a mixture of specially protected patient information and standard PHI, such as Part 2 information embedded in an EHR, organizations must apply the strictest applicable standard. Understanding redisclosure rules is essential for ensuring that DRS access does not inadvertently violate other legal obligations. Organizations must train staff to recognize specially protected categories and implement workflows that prevent unauthorized redisclosure.

The Designated Record Set and Accounting of Disclosures

The right to an accounting of disclosures applies to PHI, but not all PHI is part of the designated record set, and not all disclosures from the DRS must be included in an accounting. HIPAA exempts disclosures for treatment, payment, and healthcare operations from accounting requirements, even when the information comes from a DRS.

However, disclosures for public health reporting, law enforcement, judicial proceedings, and certain administrative functions must be tracked and reported upon request. Understanding the boundaries of the DRS helps organizations determine which disclosures involve PHI that is subject to accounting and which disclosures fall outside the scope of the requirement.

Organizations must maintain consistent documentation practices to ensure that required disclosures are captured accurately. This includes identifying systems that generate reportable disclosures, ensuring that audit logs are retained, and training staff to document disclosures that occur outside automated systems.

Because accounting requests may span multiple years, organizations must also ensure that historical systems and archives remain accessible for reporting purposes. A clear understanding of the DRS helps organizations avoid over‑reporting, under‑reporting, or misreporting disclosures, all of which can lead to compliance risks and patient dissatisfaction.

Confidential Communications and the DRS

Individuals have the right to request confidential communications, such as receiving correspondence at an alternate address or phone number or through a different communication channel. Because demographic and contact information typically reside within the DRS, organizations must ensure that these requests are honored when reasonable and that updated contact information is stored and protected appropriately.

Systems must support alternate contact fields, and staff must understand how to classify and safeguard this information to prevent inadvertent disclosures.

Confidential communication requests often intersect with sensitive services, such as reproductive health, behavioral health, or minor‑consent services. Failure to honor these requests can result in unauthorized disclosures that violate HIPAA and other federal or state confidentiality laws. Organizations must implement workflows that ensure confidential communication preferences are consistently applied across all systems, including EHRs, billing platforms, patient portals, and communication tools.

Mixed‑Purpose Systems

Modern healthcare systems frequently serve multiple functions and contain a mixture of PHI, non‑PHI, DRS content, and non‑DRS content. Examples include EHRs that store administrative attachments, CRM systems used for both care coordination and marketing, and patient portals that contain clinical information alongside appointment reminders and billing notices. Because HIPAA defines the DRS based on function rather than system location, organizations must classify each data element according to how it is used, not where it resides.

This requires a granular understanding of system architecture and data flows. For example, a scanned driver’s license stored in the EHR may be part of the DRS if it is used for identity verification related to care or billing, but marketing preferences stored in the same system may fall outside the DRS. Organizations must document which components of mixed‑purpose systems are included in the DRS and ensure that access and amendment rights are applied appropriately. Clear classification prevents over‑disclosure, under‑disclosure, and inconsistent handling of patient information.

Patient‑Generated Data in HIPAA Designated Record Sets

Patient‑generated data becomes part of the DRS when it is incorporated into the medical record or used to make decisions about the individual. Examples include home monitoring data, wearable device data, patient‑entered portal information, and documents uploaded by patients. When clinicians rely on this information to guide treatment or administrative decisions, it becomes part of the DRS and is subject to access and amendment rights.

However, not all patient‑generated data qualifies. Information that is submitted but not reviewed, not used in decision‑making, or stored in systems outside the DRS may fall outside HIPAA’s access and amendment requirements. Organizations must establish clear policies for how patient‑generated data is reviewed, incorporated, and stored.

Clear policies that address how data is triaged, when it becomes part of the medical record, and how it is retained. ensure that patient‑generated data is handled consistently and that individuals understand how their information will be used.

External Records Incorporated into the DRS

External records become part of the designated record set when they are used to make decisions about the individual, incorporated into the medical record, or stored in systems that constitute the DRS. Examples include outside consultation notes, imaging or laboratory results performed elsewhere, HIE data, and referral packets. When clinicians rely on these records to guide treatment or administrative decisions, they become part of the DRS and must be included in responses to access and amendment requests.

However, external records that are received but not used, such as unsolicited consult notes or duplicate imaging reports, may fall outside the DRS if they are not incorporated into the medical record or used in decision‑making. Organizations must establish clear policies for reviewing and classifying external records to ensure consistent handling. Documentation of inclusion or exclusion decisions supports defensibility during audits and ensures that individuals receive complete and accurate access to their information.

Mergers, Acquisitions, and EHR Transitions

During mergers, acquisitions, or EHR transitions, organizations must ensure continuity of access to designated record sets across legacy systems, archives, and new platforms. This includes identifying all systems that contain DRS‑eligible records, classifying archived data, and ensuring that individuals retain their rights to access and amend information regardless of system changes.

The failure to maintain access to legacy systems and archives when all patient data is not imported into new platforms can result in incomplete responses to access requests, compliance violations, and litigation risk. Organizations must document DRS boundaries during system consolidation, including which systems will be retained, which will be archived, and how archived data will be accessed.

Organizations must also ensure that amendments made in new systems are reflected in legacy data when appropriate. Clear communication between IT, HIM, compliance, and legal teams is essential to ensure that transitions do not disrupt individuals’ rights or compromise the integrity of PHI stored in legacy systems and archives.

Retention and Destruction Policies

Retention policies must align with HIPAA’s access and amendment rights, state medical record retention laws, federal program requirements, and organizational policies. Because the designated record set determines which information is subject to access and amendment rights, organizations must distinguish between PHI in the DRS, PHI outside the DRS, and non‑PHI. DRS content must be retained long enough to support individuals’ rights, while non‑DRS content may be subject to different retention rules.

Organizations must also ensure that destruction practices are consistent with retention requirements and that records are not destroyed prematurely. Clear documentation of retention schedules, destruction procedures, and DRS classifications supports compliance and reduces litigation risk. Retention policies should be reviewed regularly to reflect changes in law, technology, and organizational structure.

Documenting DRS Decisions for Audit and Litigation

Organizations should document designated record set boundaries, inclusion and exclusion rationales, system inventories, decision‑making analyses, and responses to access and amendment requests. This documentation provides defensibility during audits, investigations, and litigation by demonstrating that the organization applied consistent, well‑reasoned criteria when classifying records.

Documentation should include the methodology used to determine whether records fall within the DRS, the systems that contain DRS‑eligible content, and the processes used to retrieve and amend records. It should also include logs of access and amendment requests, including the rationale for any denials. Clear documentation supports transparency, reduces the risk of inconsistent practices, and strengthens the organization’s ability to defend its decisions.

The Importance of Including HIPAA Definitions in Workforce Training

The inclusion of HIPAA definitions in workforce training is essential for ensuring that staff correctly identify designated record sets and respond appropriately to individual rights requests. Staff must understand the definitions of PHI, designated record sets, and the rights associated with them. Without this foundational knowledge, errors are likely to occur, leading to compliance risks and potential harm to individuals.

More advanced HIPAA training should cover the functional criteria for HIPAA designated record sets, the distinction between PHI that is and is not part of a designated record set, and the operational implications of maintaining multiple HIPAA designated record sets. Staff in management roles should also understand how to identify records used to make decisions about individuals, how to handle access and amendment requests, and how to document decisions.

Including HIPAA definitions in training helps ensure that staff understand the scope of their responsibilities and the importance of accurate classification. It also helps prevent common errors, such as denying access to information that is part of a designated record set or providing access to information that is not. Effective training supports compliance, protects patient rights, and strengthens trust in the health care system.

Understanding Requires More Than Reading Regulatory Text

Understanding designated record sets requires more than reading the regulatory text. It requires recognizing how HIPAA’s definition interacts with the realities of contemporary healthcare information systems. The “OR”‑based structure of §164.501 makes clear that medical and billing records qualify automatically, health plan administrative systems qualify automatically, and only the third category of other records used to make decisions requires a functional analysis. This structure means that the designated record set is always a subset of the information a provider maintains, not a separate system or folder.

In practice, healthcare providers maintain far more information about a patient than HIPAA strictly requires for a designated record set. Modern EHRs and billing platforms are designed as comprehensive repositories that capture every item entered into the system. Providers do this, not because HIPAA requires all of this information to be part of the designated record set, but because unified storage supports continuity of care, reduces operational risk, and reflects how clinical and administrative work is actually performed.

The interpretation clarifies that this broad storage does not expand the designated record set. Instead, it highlights the importance of distinguishing between what is stored and what is subject to access and amendment rights. Some information in the system is PHI but not part of the designated record set. Some information is not PHI at all, and some information becomes part of the designated record set only when it is used to make decisions about the individual.

This distinction matters. It ensures that individuals can access and amend the information that shapes their care and benefits, while allowing covered entities to maintain internal documents and operational data that support their work but fall outside HIPAA’s access requirements. It also underscores the need for clear policies, staff training, and well‑maintained DRS inventories so organizations can respond accurately and consistently to individual rights requests.

Taken together, the regulatory definition and the operational reality reinforce the same principle: the designated record set is not defined by where information is stored, but by what it is and how it is used. Understanding that principle is essential for compliance, transparency, and patient trust.

HIPAA Designated Record Sets: FAQs

Is All Protected Health Information Maintained in HIPAA Designated Record Sets?

Not all PHI maintained by a covered entity is part of a designated record set. HIPAA designated record sets only include the records that fall into one of the three categories in §164.501. Many types of PHI fall outside these categories because they are not medical or billing records, not part of health plan administrative systems, and not used to make decisions about individuals.

Examples of PHI that are not part of a designated record set include:

• Internal quality improvement reports,
• Peer review materials,
• Risk management analysis,
• Workforce training materials,
• System testing data,
• Administrative notes not used in decision‑making.

These documents may contain PHI, but they are not subject to access or amendment rights because they do not meet any of the three criteria for qualifying as a designated record set. This distinction is especially important when PHI is maintained in systems that are not connected to clinical care or payment.

Case Study 6: A Nurse’s Informal Sticky Note

A nurse writes a temporary reminder on a sticky note and compliantly disposes of the note after entering the information into the EHR. The sticky note is not part of the medical record, not part of a health plan administrative system, and not used to make decisions. It is PHI until such time as it is disposed of, but not part of the designated record set.

Does All Individually Identifiable Information Maintained in a Designated Record Set Qualify as PHI?

Most individually identifiable information maintained in a designated record set qualifies as PHI, but not all. Individually identifiable information such as names, addresses, and Social Security Numbers qualifies as PHI when it relates to a patient’s health, treatment, or payment for the treatment. In such circumstances, the individually identifiable information assumes the same privacy and security protection as PHI.

When individually identifiable information stored in a designated record set does not relate to a patient’s health, treatment, or payment, it does not qualify as PHI and is not protected by HIPAA, although state privacy and data security laws may offer similar protection. Examples of individually identifiable information that do not qualify as PHI include:

• Administrative information, such as a scanned driving license used for identity verification or a form acknowledging receipt of the Notice of Privacy Practices.
• Documents about the patient that do not reveal a treatment relationship – for example, a complaint about the furniture in the waiting room.
• Operational metadata such as document IDs or internal routing notes that identify the patient but do not relate to health, treatment, or payment.
• Information about a third party that does not relate to the patient’s health, treatment, or payment and is not protected by the Genetic Information Non-Discrimination Act.

The post A Comprehensive Guide to HIPAA Designated Record Sets appeared first on The HIPAA Journal.