Digital Health and Health Data Toolkit: HIPAA Boundaries, Apps, Clinical Data, and Enforcement

By Casey Scott McKay · 2025-03-22

Health data is regulated by whoever holds it rather than by what it says, which means the same blood glucose reading is protected health information in one system and ordinary consumer data in another. This toolkit collects the resulting analysis. It works through the covered entity and business associate boundary, the rules that apply outside it, the tracking technology exposure that has produced most recent enforcement, and the state consumer health data statutes that create private rights of action where federal law does not. It then addresses the intellectual property layer that digital health businesses actually monetise: clinical datasets, de-identified data, models trained on patient records, and the licensing arrangements that move them between health systems, vendors, and researchers. It closes on breach response and on the diligence questions that decide what a digital health company is worth.

IP and Technology > Privacy Data Security | Toolkit | Published 22 March 2025 - Updated 25 July 2026 | Casey Scott McKay - marksy.us

Summary. Health data is regulated by whoever holds it rather than by what it says, which means the same reading is protected health information in one system and ordinary consumer data in another. This toolkit works through the covered entity and business associate boundary, the rules that apply outside it, the tracking technology exposure that has produced most recent enforcement, and the state consumer health data statutes that create private rights of action where federal law does not. It then addresses the intellectual property layer digital health businesses actually monetise — clinical datasets, de-identified data, and models trained on patient records — and closes on breach response and diligence.

Keywords: digital health toolkit · HIPAA covered entity · business associate agreement · health data outside HIPAA · FTC Health Breach Notification Rule · tracking technologies · consumer health data statutes · clinical data licensing · de-identification · software as a medical device · telehealth · wearables · research data · breach notification · health app privacy

Start Here

The single most useful thing to know about health privacy in the United States is that the federal statute does not follow the data.

HIPAA regulates entities, not information. Health plans, health care clearinghouses, and health care providers that transmit information electronically in connection with covered transactions are covered entities, and their vendors handling protected health information on their behalf are business associates.

A direct-to-consumer application is neither. The same blood pressure reading is protected health information when a clinic holds it and ordinary consumer data when a wellness app holds it, and the app's obligations come from an entirely different set of sources.

Those sources have multiplied. The Federal Trade Commission's authority under 15 U.S.C. § 45; the Health Breach Notification Rule at 16 C.F.R. Part 318, which reaches vendors of personal health records and which the Commission has interpreted broadly and enforced actively; comprehensive state privacy statutes with sensitive data categories; and specific consumer health data statutes in several states, one of which carries a private right of action.

So the first question in any digital health matter is which side of the line the client sits on, and the second is whether it sits on both — because most digital health businesses do, serving providers under business associate agreements and consumers directly, with the same infrastructure.

Then there is the asset question. Digital health companies are valued on their data and their models, and neither is property. Ownership is contractual, use is constrained by the terms on which the data was obtained, and the diligence question is whether the company can lawfully do what its business plan assumes.

The HIPAA Boundary

Covered entity status is a factual determination, and businesses guess it wrongly in both directions.

Business associate status arises from function, not from a label: a vendor that creates, receives, maintains, or transmits protected health information on behalf of a covered entity is a business associate, whether or not an agreement was signed.

The business associate agreement is mandatory and its required elements are specified: permitted uses and disclosures, safeguards, reporting of security incidents, subcontractor flow-down, individual access support, return or destruction on termination, and termination for material breach.

Subcontractors are business associates too, which means the flow-down is a chain rather than a single link, and the chain has to be documented at every stage.

The security rule requires administrative, physical, and technical safeguards with a documented risk analysis, and the risk analysis is the first document requested in every enforcement matter and the one most frequently absent or stale.

The privacy rule governs uses and disclosures, minimum necessary, individual rights of access and accounting, and the marketing and sale restrictions that catch commercial arrangements repeatedly.

Breach notification obligations run to individuals, to the regulator, and — above a threshold — to media, on defined timelines, with a presumption of breach unless a documented risk assessment concludes otherwise.

And enforcement is by the regulator rather than by individuals. HIPAA has no private right of action, which is precisely why plaintiffs plead state law claims and consumer protection theories instead — and why the absence of a federal private right is not the comfort clients assume.

Outside HIPAA

This is where most digital health businesses live, and where most recent enforcement has landed.

The Health Breach Notification Rule at 16 C.F.R. Part 318 requires vendors of personal health records to notify individuals, the Commission, and sometimes media of breaches of unsecured identifiable health information — and the Commission has taken the position that unauthorised disclosure to advertising partners is a breach, not merely a bad practice.

Section 5 does the rest. Under 15 U.S.C. § 45, a privacy policy that misdescribes practice is deceptive, and a practice that causes substantial unavoidable injury not outweighed by benefits is unfair. Consent orders in this area have imposed multi-year obligations, deletion of data and of models trained on it, and prohibitions on certain sharing entirely.

Tracking technologies are the recurring fact pattern. Analytics tags, advertising pixels, and software development kits embedded in health websites and applications transmit page views, search terms, and identifiers to third parties. Where the page relates to a condition, a provider, or an appointment, that transmission is a disclosure of health information, and it has generated regulatory action, class litigation under wiretapping and privacy statutes, and settlements at scale.

State consumer health data statutes define health data expansively — including inferences about health status — and impose consent, contract, and access requirements. At least one carries a private right of action, which changes the exposure profile fundamentally, and geofencing restrictions around health facilities are a specific feature.

Comprehensive state privacy laws treat health data as sensitive, requiring opt-in consent or a defined lawful basis, and grant access, correction, deletion, and portability rights.

Biometric statutes reach face, voice, and other identifiers used in patient identification, telehealth, and monitoring, with written consent and retention schedule requirements and, in one state, statutory damages that have driven very large settlements.

And genetic privacy statutes in several states impose their own consent and disclosure requirements on direct-to-consumer testing.

Clinical Data as an Asset

Health systems hold data; digital health companies want it; and the arrangements that move it between them are where the value and the risk both sit.

There is no property right in data. Feist Publications, Inc. v. Rural Telephone Service Co., 499 U.S. 340 (1991), forecloses copyright in facts, and a database attracts protection only in original selection or arrangement. So every data arrangement is a contract question.

Ask five questions of any inbound data. What is the source; on what legal basis was it collected; what did the individual consent to; what does the upstream contract permit; and what does the downstream use require?

De-identification is the mechanism that makes most of it work. Under HIPAA, data de-identified by the expert determination method or by removing the specified identifiers is no longer protected health information, and the resulting dataset falls outside the rule.

But de-identified is not unregulated. State consumer health data statutes reach inferences and may not accept HIPAA de-identification; contractual restrictions frequently survive de-identification; and re-identification risk is a technical question that changes as auxiliary datasets grow.

Prohibit re-identification expressly in every downstream contract, and require the same of any onward recipient.

Limited data sets with a data use agreement are the middle path for research and public health purposes, and they are underused because they are less familiar than full de-identification.

Research uses engage institutional review board approval, informed consent or a waiver, and — for federally funded work — the common rule framework, alongside any HIPAA authorisation.

And the commercial terms deserve attention. Exclusivity, field limitations, derived data ownership, model ownership, publication rights, and what happens to models already trained if the agreement terminates. The last of those is the term that decides whether a data licence is worth having, and it is routinely omitted.

Models, Derived Data, and What Survives Termination

A model trained on clinical data is the asset the business is built on, and its legal status is unsettled in exactly the places that matter.

The model is not the data, and a well-drafted agreement says so: the licensee owns the model weights and the derived insights, subject to obligations not to re-identify and not to reproduce the underlying records.

But the counterparty frequently wants the reverse, and health systems have become considerably more sophisticated about claiming ownership of models trained on their patients' data.

Address deletion explicitly. A regulator or a counterparty demanding deletion of data raises the question whether the model trained on it must also be deleted — and the Federal Trade Commission has ordered exactly that in several matters. A business whose entire value is a model trained on data it should not have had is a business with an existential problem, and the drafting response is to be able to show lawful provenance for every training input.

Keep the provenance record per dataset: source, date, consent basis, contract, permitted uses, and any deletion or expiry obligation.

Segregate training data by permission, so a dataset with restrictive terms can be excluded from a model that must be portable.

And version the models against their training sets, because the question "what was this trained on" has to be answerable years later.

Regulatory Classification of the Product

Alongside the data question sits the device question, and it determines the entire development pathway.

Software as a medical device. Software intended to diagnose, treat, cure, mitigate, or prevent disease is a device, and the intended use — established by labelling, marketing, and promotional statements — is what determines classification.

Wellness claims are the boundary. General wellness products making low-risk claims fall outside device regulation, and the line is drawn by what the marketing says. Which means the marketing copy is a regulatory document, and it is written by people who do not know that.

Clinical decision support has its own carve-outs conditioned on the clinician being able to independently review the basis for the recommendation, which constrains how opaque a model may be.

Cleared or approved products carry configuration control: a change to the algorithm, the training set, or the deployment environment may require a new submission, and predetermined change control plans exist precisely to manage that.

Telehealth adds licensure, prescribing, and corporate practice questions that vary by state and that have nothing to do with intellectual property but that determine whether the product may be offered at all.

Reimbursement determines whether it will be used, and coding and coverage strategy should run alongside the regulatory and IP strategy rather than after them.

And the intellectual property consequence is real. A cleared device with a validated dataset and a regulatory package has a barrier to entry that a patent on an algorithm — vulnerable under 35 U.S.C. § 101 and the Alice Corp. v. CLS Bank International, 573 U.S. 208 (2014), framework — does not provide.

Protecting the Technology

Patents are available and constrained. Diagnostic correlations face Mayo Collaborative Services v. Prometheus Laboratories, Inc., 566 U.S. 66 (2012); algorithmic claims face Alice; and the surviving claim types are technical improvements to the functioning of a system, specific data processing architectures, novel sensing hardware, and methods of treatment.

Trade secret protects the model and the pipeline, and for most digital health companies it is the primary regime: architectures, feature engineering, training procedures, and validation methods are not visible in the product and satisfy 18 U.S.C. § 1839 if reasonable measures are taken.

Copyright protects the code and, thinly, the user interface, with registration under 17 U.S.C. § 411 as the precondition to suit and the timing rules of 17 U.S.C. § 412 governing what a claim is worth.

Trademarks matter more than expected, because health brand names are screened by regulators for confusion with existing products in some contexts and because condition-descriptive names are weak and unregistrable.

And the clinical validation dataset is frequently the strongest asset of all — expensive to assemble, protected as a secret, and required for the regulatory pathway a competitor must also complete.

So the protection strategy is layered and unusually weighted toward secrecy and regulatory position, which is a different balance from most software businesses and should be explained to founders who arrive expecting a patent programme.

Vendors, Platforms, and the Chain

Digital health runs on vendors, and each one extends the compliance perimeter.

Cloud and hosting providers handling protected health information are business associates and must sign agreements, with the security configuration a shared responsibility that the customer usually owns more of than it realises.

Analytics and advertising vendors are the highest-risk category, and the correct default is that no such tag runs on a page or screen containing health-related content without a specific, documented review.

Communication tools — messaging, video, transcription, scheduling — touch health information constantly and are frequently adopted by clinical teams without procurement review.

Artificial intelligence vendors raise the training question directly: whether submitted data may be used to improve the vendor's models, and whether that is compatible with the terms on which the data was obtained. Read this term in every vendor agreement, because the default in many standard forms is permissive.

Subprocessors must be disclosed, flowed down, and reviewed, and a vendor that will not identify its subprocessors is a vendor that cannot be assessed.

Diligence proportionately: security questionnaire, certification review, contractual terms, subprocessor list, breach history, and — for critical vendors — a right to audit and an exit plan.

And maintain the vendor inventory, because the tracking technology exposure that has driven enforcement in this sector is almost always a tag nobody remembered was there.

Breach Response

Run one process for multiple regimes, because a single incident can trigger HIPAA, the Health Breach Notification Rule, state breach statutes, contractual obligations, and sector regulators simultaneously.

Preserve privilege from the first hour, with counsel engaging the forensic firm and a clear separation between the investigative work product and the operational remediation.

Establish the facts before the clock is asserted, and document the timeline contemporaneously.

Run the risk assessment properly. Under HIPAA an impermissible use or disclosure is presumed to be a breach unless a documented four-factor assessment demonstrates low probability of compromise, and the assessment must be written down.

Map the notification obligations across every applicable regime, with the shortest deadline governing the operational timetable.

Notify contractually as well as legally. Business associate agreements and customer contracts typically impose shorter and stricter obligations than any statute.

Expect litigation. Health breach class actions follow notification reliably, and the theories are negligence, contract, state consumer protection, and — where tracking is involved — wiretapping statutes.

And treat remediation as the deliverable. Regulators assess the response more than the incident, and a documented, prompt, and complete remediation is what converts an enforcement matter into a closed file.

Diligence and Valuation

A buyer asks seven questions of a digital health company, and the answers determine the price.

What data do you hold, from where, and on what basis? With the provenance record per dataset.

Are you a covered entity, a business associate, both, or neither — and does your documentation match?

Show the risk analysis and the date it was last updated.

What tags run on your health-related pages and screens, and when were they last reviewed?

What may you do with the data under the upstream agreements, and does the business plan exceed it?

Who owns the models, and what survives termination of the data agreements?

And what is the regulatory classification of the product, with the marketing copy read against it?

A company that can answer these in a week is worth materially more than one that cannot, and the assembly is a few weeks of work done calmly in advance rather than a month of panic under a term sheet.

Building the Programme

Determine the classification first — covered entity, business associate, both, or neither — and document the reasoning.

Build the data inventory by system, source, category, legal basis, retention, and the contract that governs it.

Run the tag audit across every health-related page and screen, and establish a standing rule that no analytics or advertising technology is added without documented review.

Refresh the risk analysis and keep it current, because it is the first document any regulator asks for.

Paper the business associate chain including subcontractors, and verify the flow-down rather than assuming it.

Build the model provenance and versioning records, so that deletion demands can be scoped and training inputs can be traced.

Read the vendor training clauses, and negotiate them where the default permits use of submitted data.

Align the marketing copy with the regulatory classification, and review it with the same discipline as a labelling change.

Layer the protection: trade secret for the model and pipeline, copyright registration for the code, trademarks for the brand, patents where a genuine technical improvement exists, and the clinical validation dataset treated as the crown jewel.

And rehearse the breach process, because an untested plan is a document rather than a capability.

A Worked Example

A company builds a symptom-checking application, sells an enterprise version to health systems, and licenses de-identified aggregate insights to a pharmaceutical customer.

It is both. Business associate for the enterprise deployment; outside HIPAA for the consumer application; and subject to the Health Breach Notification Rule at 16 C.F.R. Part 318 on the consumer side.

The tags are the immediate exposure. The consumer application transmits symptom search terms to an advertising network through a software development kit nobody reviewed, which is a disclosure of health information and the fact pattern in the recent enforcement wave.

The state statutes matter more than HIPAA here. Consumer health data legislation reaches inferences about health status, requires consent, and — in at least one state — supports a private action.

The de-identified licence needs work. HIPAA de-identification does not necessarily satisfy the state statutes; the upstream health system agreements may not permit onward licensing at all; and the pharmaceutical customer's agreement should prohibit re-identification and address what happens to any model it trains.

The regulatory classification is unresolved. The marketing says the application tells users what condition they have, which is a device claim, while the internal position is that it is a wellness product.

And the intellectual property strategy is inverted. The company has filed on the algorithm, which faces Alice, and has no trade secret programme covering the model and the pipeline, which is where the actual value sits.

Five findings, one product, and the one the founders raised was the patent.

Consent, Notices, and What They Actually Do

A privacy policy is a promise, and under 15 U.S.C. § 45 a promise that misdescribes practice is deceptive. That is the entire basis of most enforcement in this area, and it means the policy has to be drafted from the data inventory rather than from a template.

Consent has different meanings in different regimes. A HIPAA authorisation has prescribed elements and expiry; a state consumer health data consent must be specific, informed, and separate from other terms; a biometric consent must be written and precede collection; and a comprehensive state privacy consent must be freely given, specific, informed, and unambiguous with no dark patterns.

Do not stack them into one screen. A single consent purporting to cover research use, marketing, advertising analytics, and model training is unlikely to satisfy any of the specific regimes and reliably fails the separateness requirements.

Granularity is now the expectation, particularly for advertising, model training, and research use.

Withdrawal has to be operational. A consent that cannot be withdrawn, or whose withdrawal does not propagate to vendors and to training pipelines, is a consent the business cannot honour.

Notices at collection must be layered and available before or at the point of collection, and mobile applications carry additional platform requirements about disclosure and permissions.

Children's health data engages additional consent requirements, and services attractive to minors should assume scrutiny.

And record the version. Which policy was in force when a given individual's data was collected determines what the business may lawfully do with it now, and a company that cannot answer that question cannot scope a deletion request or defend a training set.

Litigation Exposure

Health privacy litigation has shifted from breach cases to tracking cases, and the theories have shifted with it.

Wiretapping and interception statutes are the current vehicle. Federal and state statutes analogous to 18 U.S.C. § 2511 reach the interception of communications contents, and plaintiffs characterise a pixel transmitting a page request to a third party as exactly that. Two-party consent states carry the greatest exposure and some statutes carry statutory damages.

Standing is the recurring battleground. TransUnion LLC v. Ramirez, 594 U.S. 413 (2021), and Spokeo, Inc. v. Robins, 578 U.S. 330 (2016), require concrete injury, and disclosure of health information to an advertising network is a comparatively strong candidate for concreteness by analogy to privacy torts.

Contract and consumer protection claims follow, based on the privacy policy and on state statutes with their own damages provisions.

Breach of confidence and negligence theories appear where a provider relationship exists.

Defence practice concentrates on three things: what was actually transmitted, whether it was identifiable, and whether consent was obtained in a form the statute recognises. The first of those is a technical question answered by a packet capture, and companies that cannot answer it are negotiating in the dark.

Preserve the evidence. Tag configurations change; the question is what was running on a given date, and the answer requires version control over the deployment rather than a current screenshot.

And review the arbitration and class waiver position in the terms of service, because it frequently determines the exposure more than the merits do.

Research, Publication, and Real-World Evidence

Digital health companies generate research output, and the governance is separate from the commercial data question.

Human subjects research requires institutional review board approval and informed consent or a documented waiver, and secondary use of clinical data for research is a different permission from secondary use for product improvement — a distinction companies collapse routinely.

Real-world evidence programmes using de-identified clinical data occupy an uncomfortable middle ground: not research requiring consent, not ordinary product development, and increasingly examined by both regulators and health system partners.

Publication rights are negotiated in every health system agreement and are frequently drafted so that the company cannot publish adverse findings, which is both an ethical problem and a diligence finding.

Authorship and inventorship diverge. A clinical collaborator may be an author on the paper and not an inventor on the patent, or the reverse, and 35 U.S.C. § 116 determines the second regardless of what the acknowledgements say.

The publication itself is a disclosure under 35 U.S.C. § 102, and a company presenting validation results before filing has a one-year domestic grace period and no foreign one.

Data sharing mandates from journals and funders may require deposit of datasets, which collides directly with the trade secret strategy and should be resolved before submission rather than at proof stage.

And registry and post-market surveillance obligations generate their own data flows with their own permissions, which belong in the data inventory alongside everything else.

Scale and Cadence

A pre-launch start-up needs the classification determination, a privacy policy drafted from an actual data inventory, no advertising tags on health surfaces, and vendor training clauses read before signature.

A commercial consumer product needs the Health Breach Notification Rule analysis, state consumer health data compliance, granular consent, the tag review as a standing control, and a rehearsed breach process.

An enterprise vendor to health systems needs the business associate chain papered including subcontractors, a current risk analysis, and data licence terms that permit what the product actually does.

A data licensor needs provenance per dataset, de-identification documented, re-identification prohibitions downstream, and clarity about model ownership and post-termination survival.

A regulated device business needs all of the above plus configuration control, intended-use discipline over marketing copy, and a predetermined change control plan for algorithm updates.

Review quarterly for tags, vendors, and consent flows. Review annually for the risk analysis, the data inventory, and the business associate chain. Review on trigger for a new market, a new data source, a new model, a new marketing claim, and any enforcement development in the tracking space — which has moved faster than any other area of this field.

A Ninety-Day Programme

Days one to ten. Determine the classification and write it down: covered entity, business associate, both, or neither, for each product line, with reasoning.

Days ten to twenty-five. Build the data inventory by system, source, category, legal basis, retention, governing contract, and permitted uses. Everything else depends on it.

Days twenty-five to thirty-five. Run the tag audit across every health-related page and screen. Remove what cannot be justified, document what remains, and establish the standing review control.

Days thirty-five to forty-five. Refresh the risk analysis and paper the business associate chain, including subcontractors, with evidence of flow-down rather than assumed flow-down.

Days forty-five to sixty. Read the vendor agreements for training clauses and subprocessor disclosure, and negotiate the ones that permit use of submitted data by default.

Days sixty to seventy-five. Build the model provenance and version register, segregate training data by permission, and confirm the business can scope a deletion demand.

Days seventy-five to ninety. Rewrite the privacy policy and consent flows from the inventory, align the marketing copy with the regulatory classification, and rehearse the breach process end to end.

The output is five documents and one rehearsal, and a company that has them can answer a diligence request, a regulator, and a plaintiff's first demand from the same file.

A Closing Note

The structural oddity of health privacy in the United States is that the most protective statute applies to the fewest of the entities handling health data.

A hospital is closely regulated. An application collecting the same information from the same person, twenty minutes later, was for years regulated barely at all — and the gap was filled not by amending the statute but by the Federal Trade Commission's general authority, by a breach rule written in 2009 and rediscovered a decade later, and by state legislatures acting individually.

The result is a patchwork that is harder to navigate than a single comprehensive regime, and that changes fastest precisely where digital health companies operate.

Which produces the practical advice this toolkit keeps returning to. Do not ask whether the data is health data. Ask which entity holds it, under which agreements, subject to which state statutes, and disclosed to whom by which technology — and build the inventory that answers all four.

And treat the marketing copy and the analytics configuration as legal documents, because in this sector they are the two artefacts most likely to create liability and the two least likely to be reviewed by anyone who knows that.

What Clients Actually Ask

"We're not a hospital, so HIPAA doesn't apply to us, right?" Correct as far as it goes, and it is the beginning of the analysis rather than the end. The Health Breach Notification Rule at 16 C.F.R. Part 318, section 5, and the state consumer health data statutes all apply, and at least one of them supports a private action.

"Can we run analytics on our symptom pages?" Not without a specific, documented review, and the default answer for advertising technology is no. This single control prevents the fact pattern behind most recent enforcement.

"Our data is de-identified, so we can do what we like." De-identified under HIPAA, perhaps. Free of contractual restrictions, usually not. Outside the state consumer health data statutes, not necessarily — several reach inferences about health status regardless of identifiers.

"Who owns the model?" Whoever the agreement says. If it is silent, expect the health system to claim it, and expect that claim to be taken seriously in a renewal negotiation.

"What happens if we're told to delete the data?" Ask whether the model must go too. Regulators have ordered exactly that, and a company that cannot trace training inputs cannot scope the answer.

"Is our product a device?" Read your own marketing. Intended use is established by what you say the product does, and the copy usually says more than the regulatory position assumes.

"What is our biggest exposure?" A software development kit somebody added two years ago, transmitting search terms from a page about a condition, to a company nobody has a contract with.

Telehealth and Cross-State Delivery

Telehealth is where the compliance perimeter stops being a data question, and it deserves a note even in an intellectual property toolkit because it constrains what the product may be.

Licensure follows the patient. A clinician must generally be licensed where the patient is located at the time of the encounter, and a platform matching clinicians to patients across state lines is designing around that constraint whether or not it realises it.

Corporate practice restrictions in many states prevent a corporation from employing clinicians or controlling clinical judgement, producing the friendly professional entity structures that most telehealth platforms run on and that acquirers examine closely.

Prescribing rules differ by drug class and by state, with additional federal requirements for controlled substances.

Fee splitting and referral rules constrain revenue models, and a platform paid a percentage of clinical revenue may be structurally problematic in some states.

Records ownership and retention are governed by state medical records law, which sits alongside — and sometimes conflicts with — the platform's own data terms.

And the intellectual property consequence is indirect but real. A platform whose clinical operations sit in a professional entity it does not own has a chain of title question about anything that entity's clinicians create, and the assignment architecture has to be built deliberately rather than assumed from the employment relationship that does not exist.

That question is asked in every telehealth acquisition and answered well in very few, which makes it worth raising at formation rather than at exit.

The fix at formation is a paragraph in the management services agreement; the fix at exit is an indemnity and a holdback.

That ratio holds across most of the items in this toolkit, and it is the argument for running the ninety-day programme before anybody asks for it.

A Suggested Reading Path

Start with the doctrine in The App That Knows Your Diagnosis.

Then the practice in Building a Digital Health Product.

Then the audit in the digital health data checklist.

For breach response, The First Seventy-Two Hours, Running a Data Breach Response, and the incident response checklist.

For biometric exposure, Your Face as Data, Building a Biometric Compliance Program, and the Biometric and Sensitive Data Toolkit.

For the state privacy layer, the State Privacy Compliance Toolkit and the Privacy and Marketing Data Toolkit.

For the data asset layer, the Data Licensing and Rights Toolkit.

For the model layer, the AI Procurement and Governance Toolkit and the AI procurement checklist.

For device-side intellectual property, The Device and the Approval and the Medical Device and Diagnostics IP Toolkit.

And for brand clearance in a regulated setting, the regulated healthcare brand name checklist.

Primary Authorities

| Authority | Proposition | |---|---| | 15 U.S.C. § 45 | Unfair or deceptive acts and practices | | 16 C.F.R. Part 318 | Health Breach Notification Rule | | 16 C.F.R. Part 255 | Endorsement Guides; testimonials in health marketing | | 42 U.S.C. § 1320d-6 | Wrongful disclosure of individually identifiable health information | | 45 C.F.R. Part 160 | HIPAA general administrative requirements | | 45 C.F.R. Part 164 | Privacy, security, and breach notification rules | | 21 U.S.C. § 321(h) | Device definition; intended use | | 35 U.S.C. § 101 | Eligibility of algorithmic claims | | 17 U.S.C. § 411 | Registration precondition to suit | | 17 U.S.C. § 412 | Statutory damages and fees | | 18 U.S.C. § 1839 | Trade secret; reasonable measures | | 18 U.S.C. § 2511 | Wiretap Act; interception theories in tracking cases | | Alice Corp. v. CLS Bank International | Eligibility framework | | Mayo Collaborative Services v. Prometheus Laboratories | Diagnostic correlations | | Association for Molecular Pathology v. Myriad Genetics | Natural products | | Feist Publications v. Rural Telephone Service | No property in facts | | TransUnion LLC v. Ramirez | Article III standing for statutory harms | | Spokeo v. Robins | Concrete injury requirement | | Van Buren v. United States | Exceeding authorised access | | Tracking technology enforcement in health | The dominant recent fact pattern | | State consumer health data statutes | Consent, geofencing, private actions | | HIPAA de-identification standards | Expert determination and identifier removal | | Software as a medical device classification | Intended use and carve-outs |

Forms and Templates

The License Agreement Template supplies the structure for a clinical data licence, and the terms that decide its value are the permitted purposes, the derived data and model ownership, the re-identification prohibition, the publication rights, and — above all — what survives termination, because a licence that requires deletion of models trained during its term is a licence that cannot support a product. The Assignment Agreement Template covers engineer, clinician, and contractor assignments, which in this sector frequently involve clinical collaborators at institutions with their own policies. The Portfolio Inventory Template adapts into the data inventory this toolkit treats as foundational: system, source, category, legal basis, retention, governing contract, and permitted uses. Beyond those, maintain four records: a tag and vendor inventory for every health-related surface; a current risk analysis; a model provenance and version register tied to training sets; and a business associate chain map including subcontractors.

Related Toolkits and Checklists

The State Privacy Compliance Toolkit carries the comprehensive state law analysis that increasingly governs health data outside HIPAA. The Biometric and Sensitive Data Toolkit covers the consent and retention regime with the largest statutory exposure. The Data Licensing and Rights Toolkit covers the contractual architecture for clinical datasets. The AI Procurement and Governance Toolkit covers the vendor training clauses and model governance, and the Medical Device and Diagnostics IP Toolkit covers the regulated product pathway.