Minnesota Health Records Act: Patient Privacy, Tracking Pixels and Lawsuit Risk

A healthcare organization’s website can disclose patient information without anyone stealing a password or breaking into its network. An appointment event, billing page or portal integration may send information to an outside service as part of the site’s ordinary operation. The privacy question is whether that information should have left the provider and what authorized its release.

The Minnesota Health Records Act addresses that question directly. It also gives patients rights to obtain their records and provides remedies for specified unlawful conduct. For providers and businesses handling records received from providers, it deserves a separate review alongside HIPAA and any applicable interception law.

The issue is current. On September 24, 2026, a federal court approved the Allina Health System pixel settlement, backed by a $12.5 million fund. Minnesota also changed its disclosure law in 2024 after a Supreme Court decision accepted a particular HIPAA regulation as authorization for a release. Organizations relying on older legal summaries need to examine the current text.

This article continues Captain Compliance’s privacy lawsuit series, including CIPA, Pennsylvania’s WESCA, New Hampshire’s wiretap law and North Carolina’s Electronic Surveillance Act. Minnesota’s health-records framework adds a different inquiry: even if a communication was lawfully acquired, was the resulting patient information lawfully disclosed?

Statutory and case materials reviewed October 12, 2026. Allegations, settlement terms and court holdings are identified separately.

A health record is broader than a chart or diagnostic report

The Act is codified at Minnesota Statutes §§ 144.291–144.298. Its definition of a health record includes information in any medium, including oral information, relating to a patient’s past, present or future physical or mental health, provision of healthcare or payment for healthcare. The definition therefore is not confined to a completed clinical chart.

The statute separately defines patients and providers. Providers include specified regulated healthcare professionals, licensed home-care providers, healthcare facilities and assisted-living facilities. Whether a business falls within those definitions requires review of its services and legal status. Calling a product “wellness” or “health technology” does not decide its role.

For a website investigation, the relationship between the information, patient and provider matters. An appointment request associated with an existing patient can present a different question from an anonymous visit to a general health article. A medical word on a page does not automatically make every resulting request a regulated release of a patient’s record.

Likewise, information can have health meaning without a diagnosis field. A scheduled visit, selected specialty or payment description may disclose something about care when connected to an identifiable patient. Review the fields together and the recipient’s ability to interpret them. The technical analysis should describe what was transmitted before counsel decides whether it meets the statutory definition.

The release rule applies to providers and recipients of provider records

Section 144.293, subdivision 2, generally prohibits a provider, or a person receiving health records from a provider, from releasing a patient’s records without signed and dated consent authorizing the release, specific authorization in Minnesota law, or a representation from a provider holding the required consent. Other provisions contain defined exceptions.

These include qualifying medical emergencies and necessary current-treatment disclosures within related healthcare entities. Consent generally lasts one year unless it specifies another period or Minnesota law provides otherwise, with special rules for particular purposes. Requests and releases must also respect limits imposed by the patient.

For businesses, the recipient language deserves attention. A technology company may need to examine onward disclosure of records it received from a provider even when the company is not itself a hospital. Its actual role and receipt of covered information matter; providing software to a healthcare customer does not automatically establish liability.

A useful review identifies the recipient and purpose for each release. Hosting an appointment service, supporting treatment, measuring a marketing campaign and reusing information for another customer are different activities. A single vendor relationship may contain several of them. Contracts and configurations should reflect the approved activity rather than authorize everything the vendor can technically do.

The 2024 changes make older HIPAA-based summaries unreliable

In Schneider v. Children’s Health Care, decided October 11, 2023, the Minnesota Supreme Court considered a disclosure to an institutionally related foundation and a business associate for fundraising. Under the statutory wording then in effect, the court held that the relevant HIPAA fundraising regulation qualified as specific authorization in law and affirmed judgment for the defendants.

The dispute arose after a vendor breach brought the disclosure to the family’s attention. The holding concerned the legal authority for the particular release, not a general approval of health information entering any fundraising or advertising system. The court applied the earlier text.

Minnesota subsequently amended the disclosure provision to specify authorization in Minnesota law. It also enacted § 144.2925, directing that the Act be construed to protect patient-record privacy more stringently than the HIPAA Privacy Rule with respect to use, disclosure and required permission. The Minnesota Department of Administration’s July 2024 legislative update identifies the changes as a response to Schneider and gives an effective date of May 25, 2024.

That history changes the compliance question. An organization should not rely on the 2023 decision alone to justify a present-day release through a HIPAA permission. It should identify the current Minnesota basis, applicable exception or valid consent and independently evaluate the federal requirements.

The provisions still contain exceptions, so “Minnesota always requires consent for everything” would be inaccurate too. The work is to determine which rule governs the specific release. A legally reviewed disclosure matrix should identify the information, sender, recipient, purpose and authority rather than use “HIPAA compliant” as its only entry.

The Revisor also flags a 2026 amendment to subdivision 7, removing the Health Data Institute reference from a particular consent exception. It is not a new permission for advertising pixels. Teams maintaining legal inventories should check amendment notices and effective dates when reviewing an existing disclosure practice.

Allina’s $12.5 million settlement connects the Act to website tracking

Ahlers, et al. v. Allina Health System, No. 0:24-cv-03674, provides a recent example. The settlement agreement describes allegations that tracking technologies disclosed patients’ private information to third parties, including Meta and Google. The asserted theories included the Minnesota Health Records Act, federal ECPA and several common-law claims. Allina denies wrongdoing and liability.

The agreement establishes a $12.5 million non-reversionary fund, meaning the approved settlement does not return unused fund money to Allina under its ordinary distribution terms. Fees, expenses, administration and other approved costs come from the fund. It should not be described as $12.5 million distributed entirely to patients.

Judge Susan Richard Nelson granted final approval on September 24, 2026. The approved class includes two groups covering relevant portal, billing and scheduling use, and other qualifying patient website use, from September 16, 2018 through May 11, 2026. That class definition belongs to the settlement; it does not establish that every member’s activity was proven to violate the Act.

The outcome is a settlement of disputed claims, not a trial finding that a particular pixel always unlawfully releases health records. Nor does it assign the full fund to the Minnesota statutory count alone. Its practical relevance is the cost of resolving a dispute that included both interception and disclosure theories.

For a provider reviewing its own systems, the different workflows are useful. An authenticated portal, an unauthenticated bill-payment page and a scheduling page can expose different information. Each should have its own approved tracking policy, instead of inheriting a public marketing page’s settings simply because the pages share a template.

The remedy differs from wiretap statutory damages

Section 144.298 allows compensatory damages caused by the specified unauthorized release or intentional unauthorized access, plus costs and reasonable attorney fees. Covered conduct includes negligent or intentional requests or releases violating the relevant provisions, consent forgery or material alteration, obtaining consent or records under false pretenses, and specified unauthorized access to a record locator or patient information service.

Violations can also support professional licensing action. A separate provision addresses qualifying failures by entities maintaining record locator or patient information services. The statutory routes and required conduct should be examined individually.

This is not the $100-per-day or $1,000-minimum formula discussed in several wiretap articles. The Minnesota provision requires attention to causation and compensatory damages. It does not turn every website request into a fixed statutory award. The size of a settlement also does not establish the damages that an individual could prove under the Act.

At the same time, negligence is expressly relevant to certain releases. A business should not assume that an unintended marketing transmission is harmless because no employee set out to disclose confidential information. Review both the alleged release and the controls that were supposed to prevent it.

Patients must be able to obtain their own records

Health-record privacy also includes the patient’s ability to access information. Section 144.292 includes requirements to furnish records within 30 calendar days after a written request, subject to the relevant provisions and exceptions. It also addresses notices of rights and limits on charges. A request for records to review current medical care must not incur a fee under the specified rule.

In Findling v. Group Health Plan, Inc., decided December 6, 2023, the Minnesota Supreme Court held that patients could use the private attorney general statute to seek equitable relief compelling compliance with the Act’s record-access obligation. The consolidated cases involved several providers, including HealthPartners, Essentia, Fairview and Allina. The court did not recognize the separate asserted remedy under the Minnesota Health Care Bill of Rights.

The decision concerned obtaining records and the available enforcement route, not marketing pixels. It also should not be converted into a universal damages holding for every late response. But it makes access operations part of the privacy program: identify the request, verify the requester’s authority and route it to the people who can retrieve the complete records.

A general privacy-request inbox can receive a medical-record request without the organization recognizing the difference. Configure intake so staff can distinguish records access from advertising preferences, a disclosure complaint or a request concerning another person’s records. The applicable deadline and response process should follow the request’s legal character.

Cookie consent and health-record consent answer different questions

A visitor might agree to analytics while having no reason to expect a medical appointment or billing record to reach an advertising company. The action taken in a preference center must be evaluated against the release it supposedly authorizes. Category labels alone cannot establish that the patient authorized the particular information, recipient and purpose.

The Minnesota Department of Health’s standard release form illustrates the detail involved. It identifies the patient, the sender and recipient, the information to release, the reason, duration and signature. Its instructions also flag categories requiring special consent. It is a useful reference for designing an approved records-release workflow, not a template for silently expanding a cookie choice.

Electronic execution is possible where the relevant requirements are satisfied. Minnesota’s electronic-transactions law recognizes electronic records and signatures. That does not make every “Accept all” click a signed medical-release consent. Identity, attribution, the text presented, authorization and applicable legal requirements still need review.

A practical system should keep the two decisions distinct. One rule controls whether optional website technology runs. Another determines whether a particular release of health records is allowed. The second may prohibit a payload even after the patient permits general analytics.

It is often simpler to keep patient details out of optional measurement altogether. Aggregate operational measures can answer many business questions without sending the appointment specialty, account identifier or payment narrative. Any proposed alternative still needs testing and review; calling data “anonymous” does not establish that it cannot identify a patient.

How this relates to CIPA, WESCA and the other privacy lawsuits

The laws in the series can apply at different stages of one workflow. Interception questions concern acquisition of communications. The Minnesota Health Records Act concerns covered records, patient rights and release authority. Neither analysis replaces the other.

Framework	Question to investigate	Relevant controls
Minnesota Health Records Act	Does the information qualify as a patient health record, and what authorizes its release?	Recipient restrictions, approved release workflows, purpose limits and evidence of authority.
HIPAA	For covered entities and business associates, does the proposed use or disclosure meet the applicable federal requirements?	Role and purpose review, appropriate agreements, authorizations where required and safeguards.
CIPA, WESCA and state interception laws	Does the technology perform prohibited acquisition or recording, and is the relevant consent or exception satisfied?	Script and recording review, participant analysis, execution controls and timing evidence.
Confidentiality and contract claims	Did the organization act consistently with its duties and promises concerning entrusted information?	Accurate notices, vendor governance, minimized payloads and verified implementation.

North Carolina’s one-party interception rule, for example, does not establish permission to release a Minnesota patient’s health records. New Hampshire’s all-party rule does not tell a Minnesota provider how to fulfill a medical-record request. A national provider needs a legal assessment of the particular participants, activities and applicable jurisdictions.

The Pennsylvania firearm confidentiality article addressed a comparable operational problem involving a different category of protected information. Ordinary marketing infrastructure can encounter data subject to a specific confidentiality rule. The relevant protection needs to follow that data, rather than assume every transaction can use the same advertising event.

Which organizations should review their data flows?

Hospitals and health systems should examine portals, appointment scheduling, bill payment and patient communications. Smaller clinics, dental practices, pharmacies, mental-health providers, home-care organizations and assisted-living facilities should review their status and workflows under the provider definition. A smaller website or marketing budget does not remove the need to handle covered records lawfully.

Vendors receiving provider records also need to examine their obligations. Review patient engagement services, hosted forms, call support, record exchange and other systems that can receive patient information. The relevant issue is actual receipt and onward handling, not whether the vendor describes itself as a healthcare company.

Consumer health apps and wellness retailers require a more careful scope assessment. They are not automatically covered by the Act simply because users discuss health. Determine the provider relationship and source of the information, then assess other applicable privacy rules where this statute does not govern.

Nonprofit status is not a general answer to health-record confidentiality. Fundraising teams should review the information used in donor systems, particularly after the 2024 changes. An authorization analysis should address the recipient and purpose actually involved, rather than reuse an earlier assumption about federal fundraising permissions.

What technical teams should inspect

Start with the patient journey rather than a cookie inventory. List the pages and services through which an existing patient schedules care, pays a bill or sends a message. Identify scripts, embedded forms, analytics events and backend integrations at each step. Then inspect what those components transmit.

In an illustrative scheduling flow, a tool might send an appointment event containing a specialty, date and customer-matching identifier. Another script might send the complete page address, including a parameter with similar information. Removing a field from the first integration will not solve the second route.

Inspect the complete request, including event bodies and parameters. Hashing an identifier does not automatically eliminate its matching function. Masking a form in a replay product does not establish that another script failed to read it. Check the transmitted values and the recipient’s documented capabilities.

Timing matters for consent-based controls, but minimization matters even after consent. A patient may permit an optional tool without authorizing every record available on the page. Use an approved list of event fields and block unnecessary patient details before transmission. Sensitive portal areas may warrant excluding optional marketing technology altogether.

Backend events, customer-list exports and automated integrations belong in the review. A browser scan cannot establish that an appointment service never forwards a record from its server. Moving the transfer off the browser changes the evidence needed to investigate it, not the underlying disclosure question.

Record the legal basis and technical implementation together. A vendor-purpose inventory should identify which release is allowed and the rule enforcing that boundary. Test changes to templates and integrations before deployment, because a field added for patient service can accidentally become available to an existing tracker.

Where Captain Compliance’s software fits

Captain Compliance’s documented website privacy capabilities include scanning for tracking technologies, configured consent and blocking controls, consent evidence and continued monitoring. These support discovery and control of optional technology. They do not automatically determine whether a payload is a health record or establish the legal authority to release it.

The distinction is particularly important in healthcare. A configured consent system can enforce a rule that optional technology waits for a permitted choice. It cannot, by its presence alone, transform a general cookie preference into the medical-release authorization a particular data flow requires.

Captain Compliance’s guidance on gating nonessential scripts and beacons explains that restricting cookies may not prevent a script from sending a request. Hardcoded scripts and code outside a controlled tag manager need appropriate execution controls. Integrations must connect the approved rule to the actual component acquiring or sending information.

For a provider, implementation should combine those controls with patient-workflow rules. Identify the pages where optional trackers should never run, the events that can operate without patient details and any separately approved release process. Test the resulting behavior under acceptance, refusal, selected preferences and relevant account journeys.

Retain the notice version, choice and configuration evidence needed to explain operation. Keep sensitive medical details out of routine consent logs unless there is a specific justified need and appropriate protection. Legal evidence should establish authority and behavior without unnecessarily creating another repository of patient information.

Monitoring helps find changes after the initial review. A new scheduling extension, campaign or portal template can introduce another recipient or field. Assign an owner to investigate relevant findings and verify that the approved restrictions still work. Backend review remains a separate responsibility.

Patient-record access needs its own accountable process. General privacy intake can help route a request, but the provider still needs to retrieve and securely deliver the appropriate records through its medical-record operations. Consent software is not a substitute for that work.

Businesses evaluating Compliance Shield should confirm whether a particular health-record claim qualifies under the written terms, including deployment requirements, coverage limits and exclusions. A guarantee concerning eligible website claims should not be assumed to cover every medical-confidentiality dispute.

Keep authorization and actual behavior connected

The Allina settlement puts a substantial financial figure on a dispute involving patient-facing technology. The Schneider decision and subsequent legislation show why historical legal advice needs updating. Findling shows that patients’ ability to obtain records belongs in the same privacy program as protecting records from unauthorized recipients.

The practical task is to know where patient information travels and what permits each release. Review the vendor, the fields and the purpose together. Then verify that the deployed software respects the approved boundary. A policy statement and a consent record are useful evidence only when they describe what the system actually did.

Book a Captain Compliance demo to discuss how scanning, configured consent controls and monitoring can support your patient-facing websites and broader privacy program.