HIPAA’s reproductive health proposal asked records to know what they hold

The week

On April 17, 2023, the HHS Office for Civil Rights, the federal office that enforces patient privacy rules, published in the Federal Register a proposed amendment to the HIPAA Privacy Rule, announced the previous week. HIPAA is the federal law that sets out how doctors, hospitals, health plans and their contractors may use and share patients’ health information. The Federal Register is the government’s official daily publication of proposed and final rules.

The proposal had a ten-month run-up. The Supreme Court decided Dobbs v. Jackson Women’s Health Organization in June 2022, and state abortion laws changed quickly after it. Within days, OCR issued guidance reminding providers that the Privacy Rule already limited disclosures to law enforcement and that most disclosures it allowed were permitted rather than required. In July 2022, Executive Order 14076 directed HHS to consider further action to protect the privacy of reproductive health information. The April 2023 proposal was that further action.

The proposal would bar covered entities and business associates from using or disclosing protected health information to investigate or impose liability on anyone for seeking, obtaining, providing or facilitating reproductive health care that was lawful where it was provided. “Covered entities” are mainly health care providers, health plans and claims clearinghouses. “Business associates” are the outside companies that handle patient data on their behalf, such as billing or transcription firms. “Protected health information” is, broadly, anything in the record that identifies a patient and relates to their health or care.

The preamble described three situations in which the bar would apply. The care was lawful in the state where it was given, and the investigation came from another state. Or federal law protected, required or authorized the care, wherever it took place. Or the care was given in the investigating state and that state’s own law permitted it. The proposal defined reproductive health care broadly, as care, services or supplies related to an individual’s reproductive health. It also proposed to clarify that a “person” under HIPAA means a human being who is born alive, a change aimed at how state laws would be preempted.

Some requests for information potentially related to reproductive health care would need a signed attestation that the purpose was not prohibited: a written statement, signed and dated by the person asking, that the data would not be used for a forbidden purpose. These included requests for health oversight, judicial and administrative proceedings, law enforcement, and coroners and medical examiners. OCR asked whether requesters should have to name the patients concerned or could describe a class of them. It also asked whether to publish a model form, and whether the statement should be made under penalty of perjury.

The stakes for getting it wrong were spelled out. A disclosure the rule prohibited would be a disclosure the Privacy Rule did not permit, so it would be presumed a breach of unsecured information. Breach notification would follow unless the organization could show a low probability that the information had been compromised. OCR’s own regulatory impact analysis put the cost of the proposal at about $883 million over its first five years, undiscounted, mostly for training, policy updates, revised privacy notices and handling attestations. Comments were due on June 16.

One passage in the preamble mattered more to technology leaders than any other. OCR explained that reproductive health information, unlike psychotherapy notes, was neither easily defined nor easily separated. A blood pressure reading in a pregnant patient can signal preeclampsia; glucose in a urine test can indicate gestational diabetes. OCR said it understood that clinical documentation and health IT did not let organizations segment categories of information without undue burden and cost. That was one reason it chose a rule based on the purpose of a request rather than on the type of data. HHS had made a similar judgment before: a federal advisory committee recommended special protection for categories such as sexuality and reproductive health information in 2010, and HHS declined in its 2013 rulemaking, partly over doubts that records could be segmented.

The next day, April 18, another part of HHS published a proposal pulling the other way. The Office of the National Coordinator for Health IT’s HTI-1 proposed rule included a new certification criterion for EHRs. It would have let users flag data a patient had asked to restrict, so the flagged data would stop flowing to summaries, portals and interfaces. It pointed to existing HL7 standards for security labels. In one week, one HHS office designed its rule around the absence of segmentation while another tried to make segmentation a certified feature.

Underneath the policy sat a practical puzzle. Suppose a records clerk at a hospital receives a formal request from an out-of-state investigator for a patient’s full medical file. Somewhere in hundreds of pages are notes about reproductive care the patient received legally, in the state where she received it. The clerk has to decide whether to send everything or only part, with no obvious way to tell which pages matter.

Most of the public argument was about law and politics. For anyone running a health system, the proposal raised a more practical question at that records desk: could the organization actually tell which parts of a record were about reproductive health, and act on that knowledge reliably?

Debate about the proposal centered on federal authority and its interaction with state law. Those are questions for courts and counsel. For health system technology leaders, the proposal carried an assumption that would outlast any version of the rule. It assumed a hospital could tell which parts of a patient’s record related to reproductive health care, and treat those parts differently.

That claim needs defending, because OCR said the opposite in its own preamble. It chose a purpose-based rule partly because it doubted that records could be segmented. Yet the design moved the segmentation problem rather than removing it. The attestation applied to requests for information “potentially related to reproductive health care.” Deciding whether a request falls in that set, and which pages of a chart a valid request may reach, still requires knowing where such information lives. A rule can avoid naming a data category in its text and still depend on one at the release desk.

A purpose-based rule depends on that, because a request for a whole chart has to be answered by deciding which pages are at issue. That capability, usually called data segmentation, breaks into three tasks with different owners and different limits: identifying the information, enforcing a policy on it inside the organization’s own systems, and keeping that policy attached when data leaves automatically. What follows starts with a short primer on how segmentation works and takes the three tasks in turn. It then considers what the capability means for the organization as a whole, how to judge readiness, and what a leader should ask first.

A warehouse of records, and stickers on the boxes

A modern patient record lives in an electronic health record, or EHR: the large software system a hospital uses to document everything from admission to discharge. An EHR is less like a single file and more like a warehouse. Diagnoses sit in one aisle, medications in another, lab results in a third, typed clinical notes in a fourth, scanned letters somewhere in the back. Each item is stored with codes that describe it, such as the standard diagnosis and procedure codes used for billing.

Data segmentation is the ability to mark some of the items in that warehouse as sensitive and to handle them differently. The labels work like colored stickers on boxes. A red sticker means “check before this leaves the building.” Segmentation is the work of deciding which boxes get stickers, making sure the staff and systems inside the warehouse respect them, and making sure the stickers stay on the boxes when they are loaded onto trucks.

That last image is the key to the whole problem. A sticker is only useful if everyone who touches the box, including people in other buildings, notices it and does what it says. As we will see, inside the warehouse the stickers can be made to work reasonably well. Once the trucks leave, the picture is much less reassuring.

A purpose-based rule needs this because it turns on why someone wants the information rather than on what it is. To apply it, the organization first has to know which parts of a record are reproductive health information at all, so it can ask the purpose question about those parts. Without labels, the only options are to review every page of every chart by hand, or to guess.

How big is a box

Labels can be applied at different levels of detail, and the choice drives cost. A label on a whole document, such as a discharge summary, is simple to apply and simple to honor, but it hides everything else in that document too. A label on a section, such as the obstetric history within a longer note, is more precise but needs the system to understand the document’s structure. A label on a single data element, such as one lab result or one medication order, is the most precise and the hardest to keep consistent across screens, reports and exports.

The standards anticipated all three. HL7’s data segmentation for privacy guidance for clinical documents allowed labels at the document, section and entry level. Its newer FHIR standard, which underpins most modern health data interfaces, carries security labels in each resource’s metadata. The labels draw on a shared vocabulary that includes confidentiality levels, from normal to restricted, and sensitivity categories such as substance use, HIV and psychiatric information. The vocabulary was never the hard part. The hard part was getting each system that creates, stores or receives data to apply the same labels in the same places.

Most health systems will end up mixing levels. Whole-document labels suit scanned outside records and free-text notes that cannot be split reliably. Element-level labels suit structured data that already carries codes. A written convention for which level applies to which kind of content saves endless arguments later.

Identifying the information

Reproductive health information is not stored in one place. It appears in diagnosis and procedure codes, medication lists, lab results, problem lists, clinical notes, imaging reports, scheduling records, claims and referral letters. Much of it is ambiguous. A pregnancy test is routine in an emergency department workup. Methotrexate treats rheumatoid arthritis as well as ectopic pregnancy. A note about an unrelated visit may mention a past pregnancy loss in a single line. Code lists therefore flag too much and too little at the same time.

Electronic health records already supported some sensitivity flags. Substance use disorder records under 42 CFR Part 2, a federal rule that gives addiction treatment records extra confidentiality, were a common example, alongside psychotherapy notes and confidential adolescent encounters. Most of these depended on a clinician or registrar applying the flag at the time of entry, and practice varied widely between departments.

A workable approach combines three methods:

• Curated code lists. A named clinical informatics owner maintains value sets, which are simply agreed lists of diagnosis, procedure, medication and lab codes, with documented reasons for each inclusion. Clinical informatics is the discipline that bridges medicine and IT; its people understand both what a code means clinically and how the system stores it.
• Text analysis. Software, including natural language processing, which is technology that reads ordinary written language and picks out meaning, finds mentions in notes and scanned documents that codes miss.
• Clinical review of a sample. Clinicians review a sample of the results to measure how often the classifier is wrong in each direction. A classifier is any rule or program that sorts items into categories, here “sensitive” or “not sensitive.”

Historical records are the hardest part. Labeling new data at entry is manageable. Labeling years of existing notes requires batch processing and a decision about how far back to go.

Where the misses come from

The places a classifier misses are predictable, which means they can be tested. Problem lists carry old diagnoses forward into every new encounter summary. Medication histories imported from pharmacy networks arrive without the context of why a drug was prescribed. Scheduling systems record visit types and clinic names that reveal the service even when the note does not. Patient portal messages are free text written by patients, who do not use clinical codes. Outside records arrive as faxes or PDFs and are filed as images, invisible to anything that does not read text.

Billing data deserves its own line. Claims carry diagnosis and procedure codes by design, so they are easier to classify than notes. They also travel to payers and clearinghouses automatically, and the explanation of benefits a health plan sends can reveal a service to the policyholder, who may be a parent or spouse. HIPAA already requires health plans to accommodate reasonable requests for confidential communications when the patient says disclosure could endanger them, and providers must accommodate reasonable requests without asking why. Those requests are another kind of label, and they are often stored in a different system from the clinical flags.

Measuring a classifier honestly

Every classifier makes errors, so the organization has to choose which error it prefers. Missing sensitive content exposes patients. Over-labeling can hide information clinicians need, such as a prior pregnancy complication relevant to surgery. That trade-off belongs to clinical leadership and the privacy officer together, and it should be written down with the error rates that informed it.

Any filter, from an email spam folder up, can be set too loose or too tight, and no setting is perfect. In health records the stakes on both sides are high, so the choice should be made deliberately by named people rather than left at a vendor’s default.

Measurement has a few rules that keep it honest. Error rates should be reported separately for each source, because a classifier that does well on structured lab results may do badly on scanned letters, and a blended figure hides that. The review sample should include records the classifier left unlabeled, since misses can only be counted by looking where nothing was flagged. Results should be measured again whenever the inputs change. Diagnosis and procedure code sets are revised every year, new drugs and tests appear, and a code list that was accurate in one year drifts out of date in the next without anyone touching it.

How it differs by type of organization

The work looks different depending on who is doing it. An academic medical center usually has an informatics team, a single enterprise EHR and the volume to justify text analysis. Its problem is scale and history: millions of notes across decades. A critical access hospital or small community hospital may have no informatics staff at all and will depend almost entirely on what its EHR vendor ships and configures. An ambulatory network built through acquisitions may run several EHRs at once, each with its own flags, and must decide whether to label in each system or in a shared data layer.

Pharmacies are covered entities in their own right, and their records are almost entirely structured: drug, dose, prescriber. That makes identification easier and ambiguity worse, since many drugs used in reproductive care have other uses. Health plans hold claims rather than notes, so their labels must work on codes and on the correspondence systems that generate member letters. Each needs the same three tasks, but the balance of effort between them shifts.

Enforcing a policy inside the organization

A label is only useful if something acts on it. Inside a health system there are three main places where it can.

Clinical access is the first. Care teams generally need to see the whole record, so labels there usually trigger an audit trail or a break-the-glass prompt rather than a block. Break-the-glass means a clinician can get through but must confirm they mean to, often by giving a reason, and the action is recorded for later review. It preserves safe care while discouraging casual browsing.

Disclosure for purposes other than treatment is the second, and the one the proposal targeted. Release-of-information staff answering a subpoena or an investigator’s request cannot read every page of a long chart for every request. A label lets the system show them which documents need a purpose check and an attestation, so staff can review those documents and nothing else. That turns an impossible manual task into a focused one.

Proxy and portal access is the third, and the least discussed. The patient portal is the website or app where patients see their results and messages. Proxy access lets someone else, such as a parent or caregiver, see a patient’s portal. The same labels decide what a parent sees in a teenager’s portal and what a caregiver with proxy access can open. A segmentation project that ignores the portal can produce a release desk that withholds correctly while the patient app shows everything.

Each of these needs measurement. Useful figures include the share of release requests where the system identified sensitive documents automatically, the review time per request, and the number of labeled documents disclosed without a recorded purpose check.

Vendors that handle release of information, coding or transcription as business associates need the same labels and the same workflow. Many hospitals outsource the release desk itself. Otherwise the control stops at the organization’s edge.

The release desk, step by step

A labeled release workflow has a recognizable sequence. Intake records who is asking and under what authority: a patient exercising their right of access, a signed authorization, a subpoena, a court order, an administrative request, or a public health or oversight demand. Each maps to a different permission in the Privacy Rule, and only some of them trigger the purpose question. Next the system lists the documents in scope and shows which carry sensitivity labels. Staff then check the purpose, collect an attestation where one is needed, and apply the minimum necessary standard to the rest.

The last step is the record of what happened. HIPAA already requires covered entities to account for many disclosures made without authorization, including those for law enforcement and judicial proceedings, if the patient asks. A workflow that logs the request type, the labels present, the attestation and the pages released produces that accounting as a by-product. One that relies on a clerk’s notes produces it only with effort, and sometimes not at all.

OCR’s own estimates show why the focused version matters. When it finalized the rule in 2024, it assumed about 2.8 million requests a year would need screening across all regulated entities, at an average of five minutes each. Five minutes is plausible for a request where the system has already shown which pages are sensitive. It is not plausible for a clerk paging through a long chart.

Results and notes that release themselves

The portal problem grew sharper after April 2021, when the federal information blocking rules began to apply. Many health systems responded by releasing test results and clinical notes to the portal as soon as they were final, rather than after a clinician reviewed them. For an adult patient that is usually welcome. For a teenager whose parent holds proxy access, it can mean a pregnancy test or a contraception note appears on the parent’s phone before the clinician has spoken to anyone.

State laws on minors’ consent to sensitive services vary widely, and so do the rules on what a parent may see. The portal configuration has to encode those rules, by age band and by service type, and it can only do so if the underlying data carries the right labels. That makes adolescent confidentiality one of the most practical tests of a segmentation program. It is also one where the organization controls almost every moving part itself.

Watching the watchers

Break-the-glass prompts and audit logs only deter misuse if someone reviews them. That means a named privacy analyst, a defined review cadence, and rules for which accesses generate an alert: a user opening a labeled record with no treatment relationship, for instance, or an employee viewing a family member’s chart. Without review, the prompt becomes one more click, and the log becomes evidence collected for an investigation that never happens.

Keeping the policy attached when data leaves

Much health data leaves without anyone handling a request. Records flow to health information exchanges and national exchange networks, to payers with claims and attachments, to public health registries, to prescription drug monitoring programs, and to apps patients choose through federally required interfaces. A health information exchange is a network that lets different hospitals and clinics share records about the same patient. An interface, in this sense, is an automated pipe between two computer systems that sends data without a person pressing “send.” These flows exist to move whole records or standard summaries quickly, and they do it well.

HL7, the organization behind the main data standards health systems use to exchange information, includes ways to attach security labels to data, and a data segmentation for privacy specification had existed for years. Adoption was thin. A label only protects information if the receiving system reads it and honors it. Many receivers ignore labels or strip them when they reformat data. Back to the warehouse: the stickers are on the boxes when they leave, but the next warehouse repacks everything into its own boxes and throws the stickers away.

A health system therefore depends on its EHR vendor, its exchange partners and their downstream recipients, as well as on its own configuration. That fits awkwardly with how executives are used to owning their risks: part of this control lives in other people’s systems.

Not every flow can be filtered

Outbound flows fall into groups with different rules. Some are required by law, such as reports to public health agencies and, in many states, dispensing data sent by pharmacies to prescription monitoring programs. The organization cannot simply stop these, and the labels matter mainly for what the recipient does next. Some are needed for payment: a claim without its diagnosis and procedure codes will not be paid, so filtering is not an option and the protection has to come from the payer’s handling. Some are for treatment through exchanges, where filtering is possible but has clinical consequences. And some are directed by the patient.

The patient-directed group is often misunderstood. Under HIPAA’s right of access, patients can obtain their own records, including through apps they choose that connect to the provider’s standard interfaces. Sensitivity labels do not justify withholding a patient’s own information from that patient. Once the data reaches a consumer app, it usually leaves HIPAA altogether. What happens next depends on the app’s own privacy terms, on Federal Trade Commission rules for health apps, and on state consumer health data laws such as the one Washington enacted later in April 2023.

Withholding data also carries legal risk of its own. Federal information blocking rules penalize interfering with access to electronic health information unless an exception applies. These rules exist because, for years, patients and other providers struggled to get records out of health systems. A decision to exclude certain document types from automated exchange needs counsel’s review against those exceptions, as well as clinical review of the effect on care elsewhere. A clinician in another emergency department may need to know about a past complication, and a well-meant exclusion could hide it.

The practical step in 2023 was an inventory of outbound interfaces. For each one, it recorded what data the interface sends, whether it can carry or filter by label, and who could change it. That list shows which flows can enforce a policy now and which depend on vendor roadmaps. It also gives procurement a specific request for every EHR and exchange contract renewal.

Every health system is also a receiver

Discussions of propagation usually cast the health system as the sender, worried about what happens to its data downstream. It is equally a receiver. Records arrive every day from exchanges, referring clinics, outside laboratories and other hospitals, and they are imported into the local EHR. If the sender labeled a document and the import process discards the label, the receiving health system has just become the place where the protection was lost. Its own release desk will later treat that outside record as ordinary.

The interface inventory should therefore cover inbound feeds too, recording which of them arrive with labels and whether the import keeps them. That is usually a configuration question for the integration team rather than a new product. Fixing it is one of the few propagation problems a health system can solve entirely on its own side.

What to ask a vendor

Contract language works better when it names capabilities that can be tested in a demonstration. A short list covers most of it:

• Labels applied at the document, section and element level, using the HL7 security label vocabulary.
• Labels carried in outbound clinical documents and FHIR responses.
• Labels read and preserved on inbound data rather than discarded on import.
• Interfaces that can be configured to exclude labeled content, with each exclusion logged.
• A release-of-information module that shows labels to staff and captures an attestation.

A vendor that demonstrates each of these is offering something different from one that answers with a roadmap date.

Trust, legal exposure and the release desk

Segmentation is more than an obscure IT configuration: it is a capability that touches several of the things boards worry about most.

Patients and trust. Patients share intimate information on the assumption that it will be handled carefully. A disclosure that a patient experiences as a betrayal is a reputational event, whatever its technical cause.

Legal exposure in two directions. Disclose too much and the organization may breach privacy rules. Withhold too much and it may run into information blocking rules or harm care elsewhere. Segmentation done well is how an organization steers between those risks with evidence rather than instinct.

Staff workload. Without labels, release staff face long charts and difficult judgments under time pressure. With labels, they can focus. That matters for accuracy and for morale.

Regulators and auditors. When a privacy regulator or an auditor asks how the organization decided what to release, “a clerk read the chart and used judgment” is a weak answer. “The system flagged these twelve documents under a code list our informatics lead maintains, and staff recorded a purpose check on each” is a strong one. Segmentation turns good intentions into a record that can be shown to someone else.

Cost and vendors. Much of the work depends on what the EHR and exchange vendors can do. Leaders who raise segmentation at contract renewal, with a specific list of requirements, are far better placed than those who discover the gap during a dispute and must pay for urgent custom work.

Reuse. The same three tasks apply to Part 2 records, behavioral health, HIV status and gender-affirming care. A health system that builds identification, enforcement and propagation once can apply them to each category as the law requires. That makes segmentation an investment rather than a one-off compliance project.

Contracts that carry the labels outward

Business associate agreements are the main tool for extending a policy to vendors, and most were written long before anyone thought about reproductive health requests. Useful additions are concrete. The vendor works inside the health system’s labeled workflow rather than from exports or printed charts. It routes any request from law enforcement, courts or other agencies to the covered entity instead of answering directly. It keeps attestations and release logs in a form the covered entity can retrieve for an audit or an accounting. It flows the same terms down to its own subcontractors. Counsel should review the wording, but the operational owner should write the requirements, because only that person knows how the work is actually done.

The case for waiting, and why it falls short

A reasonable executive in 2023 could have argued against spending on any of this. The rule was only proposed, and it faced certain legal challenge. OCR had designed it specifically so that organizations would not need to segment. Over-labeling could harm patients by hiding history from clinicians elsewhere. EHR vendors would eventually build what regulators required, so early custom work might be thrown away. And the money could go to ransomware defenses, which carried more immediate risk.

Each point has force, and the last one deserves respect: a health system with weak backups should fix those first. The rest weaken under scrutiny. The release desk needs to know where sensitive information lives whether or not any particular rule survives, because subpoenas, court orders and proxy access exist under every version of the law. The vendor argument cuts both ways, since vendors build to what customers specify, and certified features only help if the organization has decided how to use them. Over-labeling is a reason to measure error rates, not a reason to avoid labeling. The inexpensive steps, an owner for code lists, a portal review and an interface inventory, cost staff time rather than capital and pay off under any outcome.

Owners, error rates and an interface list

A health system in good shape has a named owner for each sensitive category’s code lists, with reasons recorded for each code, and measured error rates for its classifiers in both directions, taken from clinician-reviewed samples. Clinical leadership and the privacy officer have signed a written decision on whether to over-label or under-label. Labels drive the release desk and portal rules as well as clinician prompts. Business associates work inside the same labeled workflow, and there is a current inventory of outbound interfaces showing which can carry or filter labels.

The usual failures run the other way:

• Assuming the EHR “has a flag for that.” It may, but a flag nobody applies consistently is not a control.
• Relying on codes alone. Much sensitive information lives in free-text notes and scanned documents that codes never touch.
• Ignoring history. Labeling only new data leaves years of existing records unprotected.
• Forgetting the portal. Getting the release desk right while the parent’s app shows everything defeats the purpose.
• Switching off exchange feeds without legal review. Well-intended withholding can create information blocking risk and harm care.
• Treating it as purely internal. Labels that receivers strip offer little protection once data leaves.

A six-hospital system takes stock

Take a hypothetical regional health system with six hospitals. Its privacy officer is asked by the board whether the system could comply with a purpose-based rule. The honest answer, after a month of digging, is mixed. The EHR can flag diagnosis codes on a list, but nobody owns the list, and it has not been updated in years. Clinical notes are not scanned at all. The outsourced release-of-information vendor works from printed charts and has never seen the flags. And the teen portal shows everything that is not explicitly hidden. Such gaps are common, and none would have shown up in a policy memo. The useful outcome is a short plan: appoint an owner for the code lists, pilot text analysis on one hospital’s notes, require the vendor to work inside the labeled workflow, and fix the portal rules first because they touch the most patients.

A sensible order of work

Sequencing matters because the steps depend on each other. The first months go to ownership and inventory: named owners for each sensitive category, the outbound interface list, and a review of portal and proxy rules. Portal fixes come early because they affect the most people and usually need configuration rather than new software. Next comes measurement: a clinician-reviewed sample to establish baseline error rates for the existing flags, and a written decision on which error to prefer. Only then does it make sense to buy or build text analysis, because the baseline shows where it would help most.

Release-of-information changes follow, including the vendor contract amendments, the attestation step and the logging that supports an accounting of disclosures. Outbound filtering comes last, one interface at a time, each with counsel’s review and a clinical assessment. The evidence an auditor would ask for builds up along the way: the code lists with their change history, the sampling results, the signed error-preference decision, the interface inventory, and logs showing labeled documents passing through a purpose check.

The release desk is where the rule bites

A board or executive committee does not need to understand security label vocabularies to test readiness. A handful of plain questions, asked of the chief information officer and the privacy officer together, will show quickly whether segmentation is a capability or a hope. The answers matter less than whether anyone can give them with evidence.

1. If we received a request tomorrow for a full chart, could our system show staff which pages relate to reproductive health, or would someone have to read them all?
2. Who owns the code lists for each sensitive category, and when were they last reviewed?
3. What does a parent or caregiver with proxy access actually see in our portal today?
4. Can you give me a list of every automated feed that sends records out of our organization, with what it sends and whether it respects labels?
5. Before we exclude any data from automated exchange, has counsel reviewed it against the information blocking rules, and have clinicians assessed the effect on care elsewhere?

With hindsight

OCR finalized the rule in April 2024, with compliance required from December 23, 2024, and revised privacy notices due by February 16, 2026. The final version kept the purpose-based design and the attestation. It added a presumption that care was lawful when the organization receiving a request had not provided the care itself, unless it knew otherwise or the requester supplied factual information showing the care was unlawful. OCR also published a model attestation form.

The rule then met the courts. Texas and a group of other states sued, as did private plaintiffs. In June 2025, in Purl v. HHS, a federal court in Texas declared most of the rule unlawful and vacated it nationwide, meaning the court set it aside everywhere, rather than only for the parties in the case. The privacy notice changes tied to the separate Part 2 rule were left in place.

The certification route fared no better. When ONC finalized HTI-1 in January 2024, it declined to adopt the proposed criterion for flagging patient-requested restrictions. It cited mixed comments, concerns about feasibility and the lack of a clear consensus on mature standards. The existing certification criteria for sending and receiving security-labeled summaries remained, but adoption stayed thin.

The segmentation problem did not go away. If anything, it spread. California’s AB 352, enacted in 2023, required EHR developers and other businesses storing medical information for California providers to build capabilities to segregate and limit access to sensitive services data by July 2024. Other states passed their own shield laws, which aim to protect patients and providers from out-of-state legal action over care that was lawful where it was given. Washington’s consumer health data law, signed in April 2023, reached health information held outside HIPAA altogether. Each of these laws, whatever its politics, makes the same technical demand: know what is in the record and control where it goes.

In December 2024 federal health IT regulators added a Protecting Care Access exception to the information blocking rules, which recognized that withholding some reproductive health data could be justified. That eased one side of the legal squeeze described above, though it still requires organizations to show their reasoning. The same rule revised the segmentation condition of the infeasibility exception, so that an organization unable to separate restricted data cleanly from the rest of a requested record could withhold more. Regulators were acknowledging the technical gap rather than closing it.

The 2024 Part 2 final rule, with compliance due in February 2026, took a revealing path on substance use records. It stated that covered entities receiving those records under a patient’s single consent for treatment, payment and health care operations did not have to segregate or segment them. Those records still could not be used in proceedings against the patient. An organization relieved of the duty to separate records but still barred from disclosing some of them in court faces the same release-desk problem this article describes.

Both sides of the 2023 argument turned out partly right. OCR was correct that most organizations could not segment records cleanly, and later rules kept making allowances for that. The proposal’s critics in health IT were correct that a purpose-based rule still pushed the work onto the release desk. The organizations that fared worst were those that treated segmentation as either a legal requirement to wait for or a technical impossibility to ignore. It was neither: it was a set of ordinary capabilities, built gradually, that every later rule in this area ended up relying on.

Labeling has improved inside EHRs. Automated exchange still moves most records with little regard for labels. That gap between what happens inside the warehouse and what happens on the trucks remains the weakest point.

A specific federal rule can be written, finalized and struck down within a little over two years, while the underlying capability takes longer than that to build. Organizations that treated the 2023 proposal as a prompt to understand their own records, rather than as a compliance deadline, were better placed for California, for other states’ laws and for Part 2. Those that waited for legal certainty found that certainty never quite arrived, and the technical work was still waiting for them.