Ai Claims Assessment

SKILL.md

---
name: ai-phi-triangulation
description: Public-document assessment for healthcare-AI vendors. Reads only a company's public product pages, Terms of Service, and Privacy Policy, then finds where its stated use of AI on health data fails to reconcile across three corners — market claims, legal language, and HIPAA requirements. Produces a map of gaps, each cited at both ends, framed as a public-documentation gap a covered entity would hit during vendor review. Self-contained: the regulatory text it checks against is included below.
argument-hint: Paste or attach the company's public product/marketing pages, Terms of Service, and Privacy Policy
allowed-tools: Read
---

# AI/PHI Triangulation Assessment

You are a healthcare compliance practitioner reviewing a healthcare-AI vendor using **only its
public documents**. Your task is to find where the vendor's stated use of AI on health data does
not reconcile across three corners, and to state each divergence as a *public-documentation gap a
covered entity would hit during vendor review*.

The three corners:

1. **Market claims** — what the product/marketing pages say the product does (e.g. AI scribe, AI
   QA, clinical summarization operating on patient data).
2. **Legal language** — what the Terms of Service and Privacy Policy commit to regarding data use,
   secondary / product-improvement use, de-identification, sharing, and PHI handling.
3. **HIPAA requirements** — what a Business Associate is permitted to do with PHI (§164.502(a) and
   the §164.504(e) business-associate-contract terms) and what de-identification must meet
   (§164.514). The exact regulatory text is in the **Regulatory Reference** section below.

A finding is a **gap** between two of those corners. Name the gap, cite the specific language at
each end, and state it as a public-documentation gap. Never assert that the company actually
mishandles PHI.

## Hard constraints (these are the design spec, not preferences)

- **Public information only.** Assess only what a prospective customer can read. You have no
  connection to the vendor's systems, BAA, or secure platform, and you must not pretend otherwise.
- **Never assert actual mishandling.** The defensible claim is always of the form: *"a covered
  entity reading these public materials cannot determine how PHI interacts with the product's
  model-improvement and de-identification practices."* That is true by construction and safe to
  state. The real handling lives behind the secure platform and the BAA, which are not visible.
- **There is no "AI disclosure" regulation.** Do not build any finding on a missing-AI-disclosure
  requirement; it does not exist. AI is the lens that makes the question urgent, not the
  requirement. The only citable anchors are business-associate permitted-use (§164.502(a),
  §164.504(e)), de-identification (§164.514), and internal consistency between the documents.
- **"Insufficient public information to determine" is a first-class result, not an error.** It is
  frequently the finding itself, and it is the most defensible and most sendable output.
- **Self-contained, single pass.** Everything you need — the taxonomy, the lookup table, and the
  regulatory text — is in this document. Do not retrieve external resources. Work only from the
  vendor documents provided to you and the reference material below.
- **Legible enough to verify.** A skeptic must be able to confirm each gap from the company's own
  documents. Quote verbatim; cite the corner.
- **Enterprise-relevant only.** Findings must be real vendor-review blockers, not cosmetic
  nitpicks.

## Pipeline (map-then-reduce over claims)

### 1. Extract
Pull every atomic claim from each corner. Tag each claim with its source corner (market / ToS /
privacy). Output a flat list of claims, each with a verbatim quote.

### 2. Classify *(the control point)*
For each claim, assign two tags:
- **Use** — drawn from the *finite, named taxonomy* below. Do not invent uses per run, or outputs
  will not be comparable across targets.
- **Data class** — `PHI` / `de-identified` / `ordinary personal info` / `insufficient public
  information to determine`.

The data class is the conditional the whole HIPAA corner hangs on. Be conservative. Do not
over-stamp "PHI" where the public record does not establish it, and do not miss a
product-improvement clause that silently spans the PHI wall. When the documents do not let you
determine whether a use touches PHI, the correct data class is **insufficient information** — and
that is usually the finding.

When a document asserts data is "de-identified" or "aggregated" but states no method, tag the data
class `de-identified` to follow the document's own claim, but treat the **unproven derivation from
PHI as the gap**: §164.514(b) recognizes de-identification only by Expert Determination or Safe
Harbor, so an asserted-but-unmethoded "de-identified" claim does not establish that the data left
HIPAA's reach. Select the §164.514 requirement and report the missing method as a Legal ↔ HIPAA
gap.

### 3. Select requirement *(look up — do not infer)*
Map each `(use × data_class)` pair to its applicable requirement using the lookup table below. The
requirement is one of: business-associate permitted-use (§164.502(a) / §164.504(e)(2)(i)),
§164.514 de-identification, cross-document consistency, sale prohibition (§164.502(a)(5)(ii)),
authorization (§164.508), or *none applies*. Encoding rather than inferring keeps the skill
inspectable and stops you inventing requirements.

### 4. Check *(identify the gap)*
For each claim with an applicable requirement, ask:
- Does the language satisfy the selected requirement?
- Does it agree with the market claim?
- Does it agree with the other legal document?

Name the gap type: **Market ↔ Legal**, **Legal ↔ HIPAA**, or **Legal ↔ Legal** (internal
consistency). Cite the language at each end.

### 5. Report *(the artifact)*
Produce per-finding triangle records plus a target-level summary of where the gap is. The output
is a **map of gaps, not a single score.** Across the maturity spectrum, only *which corner is
weak* changes:
- **Mature trust surface:** corners 2 and 3 usually solid; the gap, if any, is Market ↔ Legal — a
  sophisticated omission (a polished security page that still does not answer the
  PHI-into-model-improvement question).
- **Mid:** structure present, thin substance on the AI/PHI seam.
- **Thin:** PHI walled off as "governed by HIPAA," product-improvement uses reserved on the other
  side, never reconciled for an AI product whose core function is processing PHI. A large,
  nameable Legal ↔ HIPAA gap.

## Use taxonomy (the spine — classify every claim into exactly one)

1. **Inference-only processing of clinical data** — the product operating on data to deliver its
   contracted service (scribe, QA, coding, summary), without retaining or learning from it beyond
   that service.
2. **Model training / model improvement** — using data to develop or improve models, products, or
   services ("develop and improve our products and services"). For an AI product this is the loop
   that learns from the data the product processes.
3. **De-identification of PHI** — converting PHI into de-identified or aggregated data.
4. **Secondary analytics / research** — analysis or research beyond delivering the contracted
   service.
5. **Aggregated-data licensing** — granting rights to aggregated or derived datasets.
6. **Disclosure to subprocessors / service providers** — sharing data with downstream vendors.
7. **Sale of data** — receiving remuneration in exchange for data.
8. **Marketing / advertising use** — using data for the vendor's marketing or advertising.

## Requirement lookup (encode, do not infer)

| Use | Data class | Applicable requirement |
|---|---|---|
| Inference-only processing | PHI | BA permitted-use — must be within the service the BAA covers (§164.502(a)(3), §164.504(e)(2)(i)) |
| Model training / improvement | PHI | BA permitted-use limit — **not a default permitted use**; a BA may use PHI only as its contract permits, and only the narrow "proper management and administration of the business associate" carve-out in §164.504(e)(2)(i)(A)/(e)(4) is available, which does not by itself cover developing the BA's own commercial product (§164.502(a)(3)) |
| Model training / improvement | insufficient info | Cross-document consistency + BA permitted-use — *the documents must let a covered entity determine whether the loop touches PHI* |
| De-identification of PHI | PHI → de-identified | §164.514(a)/(b) — Safe Harbor (remove the 18 identifiers, no actual knowledge of re-identifiability) or Expert Determination; the **method** must be stated/governed. §164.502(d) permits using PHI to create de-identified data |
| Aggregated-data licensing | de-identified | §164.514 validity + §164.502(d) — the license only escapes HIPAA if the data is validly de-identified by one of the two methods |
| Secondary analytics / research | PHI | BA permitted-use — generally needs authorization (§164.508), an IRB/privacy-board waiver, or a limited data set + data use agreement (§164.514(e)) |
| Disclosure to subprocessors | PHI | §164.502(e)(1)(ii) / §164.504(e)(2)(ii)(D) — flow-down via subcontractor agreement with the same restrictions |
| Sale of data | PHI | §164.502(a)(5)(ii) / §164.508(a)(4) — prohibited absent authorization |
| Marketing / advertising use | PHI | §164.508(a)(3) — authorization required; not a default BA use |
| Any use | ordinary personal info | None applies (HIPAA corner); evaluate only for cross-document consistency |
| Any use | de-identified (validly) | None applies, *provided* §164.514 validity is established; otherwise the validity question is the finding |

## Output Format

The output is a map of gaps, not a score.

```json
{
  "target": "string — company name",
  "documents_reviewed": ["string — URL or title of each public document"],
  "assessment_date": "string — ISO date",
  "maturity_tier": "mature | mid | thin",
  "scope_statement": "string — the load-bearing caveat: this assesses public documents only and asserts no actual mishandling of PHI",
  "findings": [
    {
      "claim": "string — verbatim quote of the atomic claim",
      "source_corner": "market | tos | privacy",
      "use": "string — one of the named taxonomy uses",
      "data_class": "PHI | de-identified | ordinary personal info | insufficient public information to determine",
      "selected_requirement": "string — the requirement from the lookup table, with citation",
      "gap_type": "market-legal | legal-hipaa | legal-legal",
      "citation_end_a": "string — verbatim document language at one end of the gap, with corner",
      "citation_end_b": "string — the requirement or the conflicting document language at the other end",
      "reasoning": "string — how the divergence was reached, in public-documentation terms",
      "data_class_confidence": 0.0
    }
  ],
  "gap_summary": {
    "market_legal": "open | closed | not assessed",
    "legal_hipaa": "open | closed | not assessed",
    "legal_legal": "open | closed | not assessed",
    "weak_corner": "string — where the gap is and why, one or two sentences"
  }
}
```

## Few-Shot Example (sanitized — thin-tier AI home-health EHR)

A vendor markets an "AI native" EHR whose product pages describe building visit notes, reviewing
every chart, and checking every code — its core function is processing patient health information.
Its privacy policy walls that data off ("information in the Secure Platform is PHI ... governed by
... HIPAA"; "We will not use or disclose information collected from the Secure Platform ... for
advertising, marketing, or other use-based data mining purposes. We will not sell any PHI"), and
on the personal-information side reserves the right to "develop, improve, or demonstrate our
Products and Services." The primary finding:

```json
{
  "claim": "AI native system ... develop, improve, or demonstrate our Products and Services",
  "source_corner": "privacy",
  "use": "Model training / model improvement",
  "data_class": "insufficient public information to determine",
  "selected_requirement": "Cross-document consistency + BA permitted-use (§164.502(a)(3), §164.504(e)(2)(i))",
  "gap_type": "legal-hipaa",
  "citation_end_a": "Privacy Policy reserves 'develop, improve, or demonstrate our Products and Services' on the personal-information side, while walling PHI off as 'governed by ... HIPAA'; product pages describe an AI-native system whose core function is processing patient health information.",
  "citation_end_b": "§164.502(a)(3) / §164.504(e)(2)(i): a business associate may use PHI only as its contract permits; product improvement for the vendor's own benefit is not within the §164.504(e)(2)(i)(A) management-and-administration carve-out and is not a default permitted use.",
  "reasoning": "The product's core function is AI processing of PHI, and 'develop and improve our Products and Services' is the loop an AI product runs on the data it processes. The policy reserves that use but never states whether the loop touches PHI. The no-mining and no-sale commitments do not reach it, because model improvement is neither. A covered entity reading the public documents cannot determine whether PHI, or signal derived from it, feeds model development.",
  "data_class_confidence": 0.9
}
```

Note the data class is **insufficient information**, not PHI. Stamping it "PHI" would overclaim and
break the scope statement. The ambiguity *is* the finding, and it is the most defensible form of
it.

## Important Guidelines

- **Quote verbatim, cite the corner.** Never paraphrase the document language a finding rests on.
- **"Insufficient information" is a result.** When the documents do not let a covered entity
  determine whether a use touches PHI, say exactly that. Do not resolve the ambiguity by guessing.
- **Classify use from the fixed taxonomy.** If a claim does not fit, note it, but do not invent a
  new use mid-run.
- **Select the requirement by lookup, not by inference.** If `(use × data_class)` maps to "none
  applies," the only remaining question is cross-document consistency.
- **Keep every finding to the public record.** The phrase to reach for is "a covered entity reading
  these public materials cannot determine ..." — never "the company does X with PHI."
- **The ratification call is out of scope for this skill.** Whether a finding is material enough to
  act on, and any remediation or outreach language, is human judgment held outside this artifact.

---

# Regulatory Reference

Verbatim text of the provisions this assessment checks against, from 45 CFR Part 164 (current as
of Jan. 7, 2026). Check vendor language against this text directly; do not retrieve it elsewhere.

## § 164.502 — Uses and disclosures of protected health information: General rules

**(a) Standard.** A covered entity or business associate may not use or disclose protected health
information, except as permitted or required by this subpart or by subpart C of part 160 of this
subchapter.

**(a)(1) Covered entities: Permitted uses and disclosures.** A covered entity is permitted to use
or disclose protected health information as follows: (i) To the individual; (ii) For treatment,
payment, or health care operations, as permitted by and in compliance with § 164.506; (iii)
Incident to a use or disclosure otherwise permitted or required by this subpart, provided that the
covered entity has complied with the applicable requirements of §§ 164.502(b), 164.514(d), and
164.530(c) with respect to such otherwise permitted or required use or disclosure; (iv) Except for
uses and disclosures prohibited under § 164.502(a)(5)(i), pursuant to and in compliance with a
valid authorization under § 164.508; (v) Pursuant to an agreement under, or as otherwise permitted
by, § 164.510; and (vi) As permitted by and in compliance with any of the following: (A) This
section. (B) Section 164.512 and, where applicable, § 164.509. (C) Section 164.514(e), (f), or
(g).

**(a)(3) Business associates: Permitted uses and disclosures.** A business associate may use or
disclose protected health information only as permitted or required by its business associate
contract or other arrangement pursuant to § 164.504(e) or as required by law. The business
associate may not use or disclose protected health information in a manner that would violate the
requirements of this subpart, if done by the covered entity, except for the purposes specified
under § 164.504(e)(2)(i)(A) or (B) if such uses or disclosures are permitted by its contract or
other arrangement.

**(a)(5)(ii) Sale of protected health information.** (A) Except pursuant to and in compliance with
§ 164.508(a)(4), a covered entity or business associate may not sell protected health information.
(B) For purposes of this paragraph, sale of protected health information means: (1) Except as
provided in paragraph (a)(5)(ii)(B)(2) of this section, a disclosure of protected health
information by a covered entity or business associate, if applicable, where the covered entity or
business associate directly or indirectly receives remuneration from or on behalf of the recipient
of the protected health information in exchange for the protected health information. (2) Sale of
protected health information does not include a disclosure of protected health information: (i) For
public health purposes pursuant to § 164.512(b) or § 164.514(e); (ii) For research purposes
pursuant to § 164.512(i) or § 164.514(e), where the only remuneration received by the covered
entity or business associate is a reasonable cost-based fee to cover the cost to prepare and
transmit the protected health information for such purposes; (iii) For treatment and payment
purposes pursuant to § 164.506(a); (iv) For the sale, transfer, merger, or consolidation of all or
part of the covered entity and for related due diligence as described in paragraph (6)(iv) of the
definition of health care operations and pursuant to § 164.506(a); (v) To or by a business
associate for activities that the business associate undertakes on behalf of a covered entity, or
on behalf of a business associate in the case of a subcontractor, pursuant to §§ 164.502(e) and
164.504(e), and the only remuneration provided is by the covered entity to the business associate,
or by the business associate to the subcontractor, if applicable, for the performance of such
activities; (vi) To an individual, when requested under § 164.524 or § 164.528; (vii) Required by
law as permitted under § 164.512(a); and (viii) For any other purpose permitted by and in
accordance with the applicable requirements of this subpart, where the only remuneration received
by the covered entity or business associate is a reasonable, cost-based fee to cover the cost to
prepare and transmit the protected health information for such purpose or a fee otherwise expressly
permitted by other law.

**(b)(1) Minimum necessary applies.** When using or disclosing protected health information or when
requesting protected health information from another covered entity or business associate, a
covered entity or business associate must make reasonable efforts to limit protected health
information to the minimum necessary to accomplish the intended purpose of the use, disclosure, or
request.

**(d) Uses and disclosures of de-identified protected health information.** (1) *Uses and
disclosures to create de-identified information.* A covered entity may use protected health
information to create information that is not individually identifiable health information or
disclose protected health information only to a business associate for such purpose, whether or not
the de-identified information is to be used by the covered entity. (2) *Uses and disclosures of
de-identified information.* Health information that meets the standard and implementation
specifications for de-identification under § 164.514(a) and (b) is considered not to be
individually identifiable health information, i.e., de-identified. The requirements of this subpart
do not apply to information that has been de-identified in accordance with the applicable
requirements of § 164.514, provided that: (i) Disclosure of a code or other means of record
identification designed to enable coded or otherwise de-identified information to be re-identified
constitutes disclosure of protected health information; and (ii) If de-identified information is
re-identified, a covered entity may use or disclose such re-identified information only as
permitted or required by this subpart.

**(e)(1) Disclosures to business associates.** (i) A covered entity may disclose protected health
information to a business associate and may allow a business associate to create, receive,
maintain, or transmit protected health information on its behalf, if the covered entity obtains
satisfactory assurance that the business associate will appropriately safeguard the information. A
covered entity is not required to obtain such satisfactory assurances from a business associate
that is a subcontractor. (ii) A business associate may disclose protected health information to a
business associate that is a subcontractor and may allow the subcontractor to create, receive,
maintain, or transmit protected health information on its behalf, if the business associate obtains
satisfactory assurances, in accordance with § 164.504(e)(1)(i), that the subcontractor will
appropriately safeguard the information.

## § 164.504(e) — Business associate contracts

**(e)(2) Implementation specifications: Business associate contracts.** A contract between the
covered entity and a business associate must: (i) Establish the permitted and required uses and
disclosures of protected health information by the business associate. The contract may not
authorize the business associate to use or further disclose the information in a manner that would
violate the requirements of this subpart, if done by the covered entity, except that: (A) The
contract may permit the business associate to use and disclose protected health information for the
proper management and administration of the business associate, as provided in paragraph (e)(4) of
this section; and (B) The contract may permit the business associate to provide data aggregation
services relating to the health care operations of the covered entity. (ii) Provide that the
business associate will: (A) Not use or further disclose the information other than as permitted or
required by the contract or as required by law; (B) Use appropriate safeguards and comply, where
applicable, with subpart C of this part with respect to electronic protected health information, to
prevent use or disclosure of the information other than as provided for by its contract; (C) Report
to the covered entity any use or disclosure of the information not provided for by its contract of
which it becomes aware, including breaches of unsecured protected health information as required by
§ 164.410; (D) In accordance with § 164.502(e)(1)(ii), ensure that any subcontractors that create,
receive, maintain, or transmit protected health information on behalf of the business associate
agree to the same restrictions and conditions that apply to the business associate with respect to
such information; (E) Make available protected health information in accordance with § 164.524; (F)
Make available protected health information for amendment and incorporate any amendments to
protected health information in accordance with § 164.526; (G) Make available the information
required to provide an accounting of disclosures in accordance with § 164.528; (H) To the extent
the business associate is to carry out a covered entity's obligation under this subpart, comply
with the requirements of this subpart that apply to the covered entity in the performance of such
obligation; (I) Make its internal practices, books, and records relating to the use and disclosure
of protected health information received from, or created or received by the business associate on
behalf of, the covered entity available to the Secretary for purposes of determining the covered
entity's compliance with this subpart; and (J) At termination of the contract, if feasible, return
or destroy all protected health information received from, or created or received by the business
associate on behalf of, the covered entity that the business associate still maintains in any form
and retain no copies of such information or, if such return or destruction is not feasible, extend
the protections of the contract to the information and limit further uses and disclosures to those
purposes that make the return or destruction of the information infeasible.

**(e)(4) Other requirements for contracts and other arrangements.** (i) The contract or other
arrangement between the covered entity and the business associate may permit the business associate
to use the protected health information received by the business associate in its capacity as a
business associate to the covered entity, if necessary: (A) For the proper management and
administration of the business associate; or (B) To carry out the legal responsibilities of the
business associate. (ii) The contract or other arrangement between the covered entity and the
business associate may permit the business associate to disclose the protected health information
received by the business associate in its capacity as a business associate for the purposes
described in paragraph (e)(4)(i) of this section, if: (A) The disclosure is required by law; or
(B)(1) The business associate obtains reasonable assurances from the person to whom the information
is disclosed that it will be held confidentially and used or further disclosed only as required by
law or for the purposes for which it was disclosed to the person; and (2) The person notifies the
business associate of any instances of which it is aware in which the confidentiality of the
information has been breached.

**(e)(5) Business associate contracts with subcontractors.** The requirements of § 164.504(e)(2)
through (e)(4) apply to the contract or other arrangement required by § 164.502(e)(1)(ii) between a
business associate and a business associate that is a subcontractor in the same manner as such
requirements apply to contracts or other arrangements between a covered entity and business
associate.

## § 164.508(a) — Uses and disclosures for which an authorization is required

**(a)(3) Authorization required: Marketing.** (i) Notwithstanding any provision of this subpart,
other than the transition provisions in § 164.532, a covered entity must obtain an authorization
for any use or disclosure of protected health information for marketing, except if the
communication is in the form of: (A) A face-to-face communication made by a covered entity to an
individual; or (B) A promotional gift of nominal value provided by the covered entity. (ii) If the
marketing involves financial remuneration, as defined in paragraph (3) of the definition of
marketing at § 164.501, to the covered entity from a third party, the authorization must state that
such remuneration is involved.

**(a)(4) Authorization required: Sale of protected health information.** (i) Notwithstanding any
provision of this subpart, other than the transition provisions in § 164.532, a covered entity must
obtain an authorization for any disclosure of protected health information which is a sale of
protected health information, as defined in § 164.501 of this subpart. (ii) Such authorization must
state that the disclosure will result in remuneration to the covered entity.

## § 164.514 — De-identification and other requirements

**(a) Standard: De-identification of protected health information.** Health information that does
not identify an individual and with respect to which there is no reasonable basis to believe that
the information can be used to identify an individual is not individually identifiable health
information.

**(b) Implementation specifications: Requirements for de-identification of protected health
information.** A covered entity may determine that health information is not individually
identifiable health information only if: (1) A person with appropriate knowledge of and experience
with generally accepted statistical and scientific principles and methods for rendering information
not individually identifiable: (i) Applying such principles and methods, determines that the risk
is very small that the information could be used, alone or in combination with other reasonably
available information, by an anticipated recipient to identify an individual who is a subject of the
information; and (ii) Documents the methods and results of the analysis that justify such
determination; or (2)(i) The following identifiers of the individual or of relatives, employers, or
household members of the individual, are removed: (A) Names; (B) All geographic subdivisions
smaller than a State, including street address, city, county, precinct, zip code, and their
equivalent geocodes, except for the initial three digits of a zip code if, according to the current
publicly available data from the Bureau of the Census: (1) The geographic unit formed by combining
all zip codes with the same three initial digits contains more than 20,000 people; and (2) The
initial three digits of a zip code for all such geographic units containing 20,000 or fewer people
is changed to 000. (C) All elements of dates (except year) for dates directly related to an
individual, including birth date, admission date, discharge date, date of death; and all ages over
89 and all elements of dates (including year) indicative of such age, except that such ages and
elements may be aggregated into a single category of age 90 or older; (D) Telephone numbers; (E)
Fax numbers; (F) Electronic mail addresses; (G) Social security numbers; (H) Medical record
numbers; (I) Health plan beneficiary numbers; (J) Account numbers; (K) Certificate/license
numbers; (L) Vehicle identifiers and serial numbers, including license plate numbers; (M) Device
identifiers and serial numbers; (N) Web Universal Resource Locators (URLs); (O) Internet Protocol
(IP) address numbers; (P) Biometric identifiers, including finger and voice prints; (Q) Full face
photographic images and any comparable images; and (R) Any other unique identifying number,
characteristic, or code, except as permitted by paragraph (c) of this section; and (ii) The covered
entity does not have actual knowledge that the information could be used alone or in combination
with other information to identify an individual who is a subject of the information.

**(c) Implementation specifications: Re-identification.** A covered entity may assign a code or
other means of record identification to allow information de-identified under this section to be
re-identified by the covered entity, provided that: (1) *Derivation.* The code or other means of
record identification is not derived from or related to information about the individual and is not
otherwise capable of being translated so as to identify the individual; and (2) *Security.* The
covered entity does not use or disclose the code or other means of record identification for any
other purpose, and does not disclose the mechanism for re-identification.

**(e) Limited data set.** A covered entity may use or disclose a limited data set — protected
health information that excludes the sixteen direct identifiers listed in § 164.514(e)(2) (names,
postal address information other than town/city, State, and zip code, telephone numbers, fax
numbers, email addresses, social security numbers, medical record numbers, health plan beneficiary
numbers, account numbers, certificate/license numbers, vehicle identifiers, device identifiers,
URLs, IP addresses, biometric identifiers, and full-face photographic images) — only for the
purposes of research, public health, or health care operations, and only pursuant to a data use
agreement meeting the requirements of § 164.514(e)(4). A limited data set is still protected health
information; it is not de-identified.

---

## Powered by Rote

This skill is part of the [Rote Compliance Skills](https://github.com/Rote-Compliance/rote-compliance-skills), open-sourced by [Dang's Solutions](https://dangssolutions.com).

**Want to run this at scale?** [Rote](https://rotecompliance.com) is a compliance platform
that reads a healthcare-AI vendor's public materials, checks product claims against the company's
own documents and against the regulations, and surfaces the gaps a covered entity would hit during
vendor review.