GINA Compliance for Large Language Models in Health Plans

What GINA and HIPAA prohibit, and what they permit

GINA Title I sections 101 to 104 prohibit group health plans, group and individual market issuers, and Medigap issuers from discriminating on the basis of genetic information and from collecting it. Section 105 directed HHS to revise the HIPAA privacy regulations to confirm that genetic information is health information and to prohibit its use or disclosure for underwriting.

The implementing regulation at 29 CFR 2590.702-1 sets out three restrictions relevant to LLM design. A group health plan or issuer must not adjust premium or contribution amounts for the plan, or for any group of similarly situated individuals, based on genetic information. It must not request or require an individual or family member to undergo a genetic test, subject to the exceptions in paragraph (c). And it must not collect genetic information for underwriting purposes.

On the HIPAA side, 45 CFR 164.502(a)(5)(i) states that, notwithstanding any other provision of Subpart E, a health plan shall not use or disclose PHI that is genetic information for underwriting purposes. The exception is an issuer of a long-term care policy within paragraph (1)(viii) of the health plan definition. HHS guidance confirms that genetic information is protected once it is individually identifiable and held by a covered provider, health plan or clearinghouse.

The distinctions that matter for model workflows

Three points shape how the rules apply to an LLM. First, the restrictions attach to use, disclosure, request and collection. Each LLM data path therefore has to be assessed for whether it amounts to one of those acts on genetic PHI.

Second, the prohibition is purpose-based, not a ban on all handling. The regulation allows a plan to limit or exclude a benefit based on medical appropriateness, and a medical appropriateness determination is not within the meaning of underwriting purposes. Payment and health care operations under 164.506 remain permitted purposes. GINA also does not bar premium increases, preexisting exclusions or eligibility rules based on the manifestation of a disease or disorder of an enrolled individual. A utilization management workflow may be lawful where a risk-rating workflow is not, even if both touch similar records. A runtime policy has to encode that classification, and ambiguous cases need a defined escalation route.

Third, consent does not resolve the question. Uses under a valid authorization are permitted except for those prohibited under 164.502(a)(5)(i), so an authorization does not lift the underwriting prohibition. Business associates, including model hosts and tool providers handling PHI, may use PHI only as their business associate contract permits or as required by law. Disclosure of summary health information to a plan sponsor for premium bids is a separate path where the underwriting prohibition is expressly preserved.

The scope of protected information is also broader than predictive testing. It reaches diagnostic, pharmacogenetic and carrier testing and tumor profiling, and detection rules should cover these categories along with family medical history and genetic services data.

Runtime enforcement: allow, redact, block, escalate

Review after the fact can identify a problem, but it does not prevent the use or disclosure. For restrictions framed around what a plan uses, requests or collects, the stronger control sits in the execution path, where the decision is made before the model or tool acts.

Four actions cover most cases. Allow applies where the workflow relies on a permitted purpose such as a medical appropriateness review and the role is authorized. Redact removes genetic elements while letting the rest of the interaction proceed, which suits member service questions and retrieved documents with incidental genetic content. Block applies where no permitted purpose exists, such as any path touching premium setting or underwriting. Escalate for human approval handles the ambiguous middle, where a reviewer must decide whether a request is medical appropriateness or underwriting.

There are tradeoffs. Detection will not be perfect, so thresholds involve a choice between over-blocking legitimate care and claims work and under-detecting genetic content. Policy rules also need an owner who can document the line between permitted and prohibited purposes. Role, workflow and destination should be inputs to the decision, because the same record can be lawful in one context and prohibited in another.

Where Trussed fits

Trussed is control, provenance and evidence infrastructure for consequential AI. It enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact, block, rate limit and escalate-for-human-approval actions applied to individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact.

That enforcement generates continuous, audit-ready evidence mapped to HIPAA. Trussed supports self-managed deployment in the customer cloud, with configurable retention and data residency, which helps keep PHI within a plan's and its business associates' contractual boundaries. Trussed runs in production with healthcare and pharma organizations, has 18+ months of continuous production in a regulated enterprise, and has maintained 99.95% uptime on live production traffic.

These capabilities are controls to evaluate against the obligations above. They do not deliver GINA compliance by themselves, and the classification of workflows and the legal conclusions remain with the plan and its counsel. This guide is not legal advice.