Status: draft. Понятие используется в нескольких decision-страницах (phi-in-fhir-not-sql и др.) как термин-аксиома. Эта страница — попытка зафиксировать что мы под ним понимаем; нюансы остаются открытыми вопросами.
Что это по HIPAA
Регуляторное определение: любая individually identifiable health information (IIHI), создаваемая или получаемая covered entity (медучреждение, страховая, clearinghouse) или business associate, в любой форме (электронная, бумажная, устная), которая:
- Связана с health condition / лечением / оплатой за care, и
- Может быть привязана к конкретному человеку (напрямую через identifiers или косвенно).
HIPAA Privacy Rule (45 CFR § 164.514) перечисляет 18 identifiers, по которым информация считается identifiable, если хоть один присутствует:
имя, географические данные точнее штата, даты (рождения, поступления, выписки, смерти), телефон, email, fax, SSN, medical record number, health plan ID, account number, certificate/license, vehicle ID, device ID, URL, IP, biometric (включая голос/отпечатки), фото лица, “любой другой уникальный идентифицирующий номер, характеристика или код”.
Удаление всех 18 = de-identified, перестаёт быть PHI. Statistical de-identification (HIPAA Safe Harbor / Expert Determination) — отдельный процесс.
В нашем контексте
Что мы считаем PHI у себя (по решению phi-in-fhir-not-sql — всё это живёт только в Healthcare API):
| Поле | Почему PHI |
|---|---|
| Patient name, birthDate, gender | Прямые identifiers |
Лабораторные значения (value, unit, referenceRange) | Health condition, привязаны к Patient через Observation.subject |
AI narrative (narrativeSummary, parameterDetails, panelOverview) | Содержат конкретные значения и диагностические гипотезы пациента |
identifiedPatterns, healthConsiderations, recommendedSteps | То же — derived от patient-specific data |
trendAnalysis | Привязан к history конкретного Patient |
| Идентификаторы лаборатории, дата сдачи | ”Even if name removed, date+lab может re-identify” |
Что НЕ PHI (живёт в Cloud SQL):
| Поле | Почему не PHI |
|---|---|
Organization, ApiKey | Tenant config, не про здоровье человека |
BloodTest.id, BloodTest.fhirReportId | Внутренние pointer’ы без health content |
BloodTest.gcsKey | Путь к файлу, не содержимое |
status, createdAt, timestamps процессинга | Operational metadata |
LabTestCatalog, Batch.config | Бизнес-конфигурация |
Граница проводится так: если поле может отвечать на вопрос “что у этого человека со здоровьем” или позволяет re-identify — это PHI.
Открытые вопросы
- AI-aggregate stats без identifiers — например, “среди наших пациентов 30% с pre-diabetes”. Если это считать в реальном времени из FHIR, то результат не PHI (de-identified). Но если кэшировать с привязкой к Organization — пограничный кейс. Не зафиксировано как мы относимся.
- Inngest event payloads — в phi-in-fhir-not-sql упомянуто проверить что
organizationIdв events есть, а PHI нет. Реальный audit не делался, граница “что считается PHI в payload” не зафиксирована (orgId сам по себе — нет, аbloodTestId+patientId— уже косвенный pointer). - Logs / Sentry / observability — error message может содержать частичный response, в котором конкретное value параметра. Это PHI попавший в logs — должно быть отфильтровано. Зафиксированной policy нет.
- Email / WhatsApp в notifications — если посылаем “ваши результаты готовы” — не PHI. Если “ваш HbA1c повышен” — уже PHI и канал должен быть HIPAA-compliant.
- De-identification для analytics / R&D — ни процесс, ни инструмент не зафиксированы. Если когда-то захотим использовать данные для обучения / research, нужен формальный de-id pipeline.
- PHI vs PII — близкие но не идентичные. PII шире (любая identifying info, не обязательно health). GDPR работает с personal data, не с PHI. Разграничение не везде чёткое — особенно для EU-tenants где HIPAA не applicable, а GDPR работает.
Связано
- phi-in-fhir-not-sql — главное архитектурное решение про placement
- multi-tenant-fhir-storage — defense-in-depth для PHI access
- google-healthcare-api — основной storage backend, BAA scope
- ai-enrichment-separate-step — AI-generated PHI и attribution
- llm-safety-in-medicine — regulatory framing (FDA, NOHARM)
Источники
Сноски
-
HHS HIPAA Privacy Rule, 45 CFR § 164.514, accessed 2026-05-17, https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.514. ↩
-
HHS PHI guidance, accessed 2026-05-17, https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html. ↩
-
Google Cloud BAA (HIPAA), accessed 2026-05-17, https://cloud.google.com/security/compliance/hipaa. ↩