Кратко предложу реляционную модель, затем отмечу ключевые вопросы нормализации, приватности, масштабируемости и миграции.
Модель (ядро таблиц — примеры столбцов; PK — первичный ключ, FK — внешние ключи):
- Patient (patient_id UUID PK, given_name, family_name, dob DATE, gender, ssn_hash, legal_id_hash, preferred_language)
- PatientIdentifier (id PK, patient_id FK → Patient, id_type, id_value_hash, issuer)
- Address (id PK, patient_id FK, type, line1, city, state, postal_code, country)
- Provider (provider_id UUID PK, name, specialty, npi_hash, org_id FK)
- Organization (org_id PK, name, address_id FK)
- Encounter (encounter_id UUID PK, patient_id FK, provider_id FK, org_id FK, start_ts TIMESTAMP, end_ts, encounter_type, status)
- Diagnosis (diag_id PK, encounter_id FK, icd_code FK → ICD_Code, diag_date, primary_flag)
- Procedure (proc_id PK, encounter_id FK, cpt_code FK → CPT_Code, proc_date)
- MedicationOrder (med_order_id PK, patient_id FK, prescriber_id FK, drug_code FK, dose, route, start_date, end_date, status)
- Observation (obs_id PK, encounter_id FK, loinc_code FK, value_numeric, value_text, units, obs_time) — большой объём, партицирование
- LabResult (lab_id PK, observation_id FK, result_blob_ref → объектное хранилище, normalized_value)
- Document (doc_id PK, patient_id FK, encounter_id FK NULLABLE, s3_uri, checksum, mime_type, encrypted_key_ref)
- Consent (consent_id PK, patient_id FK, granularity, allowed_party, purpose, start_ts, end_ts)
- AuditLog (audit_id PK, who, action, table_name, row_pk, diff_json, ts) — immutable
- Code tables: ICD_Code, CPT_Code, LOINC, SNOMED (код, description, version)
Кардинальности и принцип размещения: Patient 1:N Encounter; Encounter 1:N {Diagnosis, Procedure, Observation}. Записи, связанные с пациентом, по возможности шардировать по patient_id.
Нормализация
- Для транзакционной целостности — стремиться к $3NF$ или $BCNF$ для основных таблиц (patients, encounters, orders, observations). Это уменьшает избыточность и облегчает поддержку справочных кодов.
- Кодовые справочники (ICD, LOINC) вынести в отдельные таблицы, хранить только ссылки.
- Для быстро растущих/полиморфных данных (разные структуры наблюдений) использовать гибрид: нормализованные колонки для частых запросов + JSONB для дополнительных атрибутов.
- Денормализация допустима ради чтения/отчётности: материализованные представления, агрегаты, кэши. Делать явно и с механизмом инвалидации.
Приватность и безопасность
- Шифрование: дисковое (TDE) + шифрование колонок с PII (ssn, legal_id) через KMS/HSM; ключи — ротация и разделение прав.
- Транзит: TLS для всех соединений.
- Псевдонимизация/ токенизация идентификаторов при экспортe и аналитике; хранить соответствие в защищённом месте.
- Контроль доступа: RBAC + атрибутный доступ/контроль на уровне строк (Row-Level Security в PostgreSQL) для обеспечения принципа "least privilege".
- Логирование доступа и аудита (AuditLog) — неизменяемое, с хранением кто/когда/почему видел или изменял запись.
- Consent management: соблюдать согласия пациента, поддерживать механизмы удаления/анонимизации данных (право на удаление), но учесть требования аудита/ретенции — для логов хранить псевдонимизированные записи.
- Тестовые копии данных: использовать де-идентифицированные или синтетические наборы.
Масштабируемость
- Горизонтальное масштабирование чтения: реплики для чтения, балансировка запросов.
- Масштабирование записи: партицирование таблиц по дате (для событий/лабов) или по patient_id (шардинг). Часто выбирают шардирование по patient_id, чтобы связанный набор таблиц размещался вместе.
- Партицирование: range по датам для наблюдений/результатов; hash по patient_id для равномерного распределения.
- Индексы: составные индексы по (patient_id, ts), частичные индексы для активных/нужных состояний, GIN для JSONB.
- UUID / ULID: использовать UUIDv4/ULID для распределённой генерации PK; для уменьшения проблем с горячими точками — улучшающие версии (monotonic UUID).
- Разделение нагрузок: OLTP БД для записей, отдельное хранилище аналитики (data warehouse) через CDC (Debezium) и ETL; CQRS: отдельные модели для записи и чтения.
- Кеширование (Redis) для горячих данных (последние визиты, сессии).
- Хранение больших документов в объектном хранилище (S3), в БД — ссылки и метаданные.
Миграция при изменении требований
- Использовать миграционные инструменты (Flyway, Liquibase) и CI/CD.
- Безопасный шаблон: expand → backfill → switch → contract.
- Шаг 1: добавить новые nullable колонки / новые таблицы (backward-compatible).
- Шаг 2: начать писать в оба формата (dual writes) или использовать триггеры для синхронизации.
- Шаг 3: выполнить фоновые backfill-скрипты батчами (чтобы не блокировать).
- Шаг 4: обновить читателей/сервисы на новую схему.
- Шаг 5: удалить старые поля после проверки.
- Для больших таблиц: обновления чанками, использование онлайн-ALTER (если поддерживается), либо создание новой таблицы + копирование + переключение имен.
- Для изменений, затрагивающих семантику (например, изменение кодировки диагнозов), сохранять версию схемы/кода, предоставлять адаптеры (view или API-версионирование).
- Миграции данных: предусмотреть проверку целостности, откатные скрипты, мониторинг времени и размера операций.
- Минимизировать окно недоступности: использовать схемы обратимой миграции, feature flags, тестовые окружения и прогон миграций на репликах.
Дополнительные рекомендации
- Хранить PII и чувствительные поля минимально; отделять индексируемые поля от больших BLOB-ов.
- Отдельный сервис авторизации/аудита — снижает количество проверок в БД.
- Документировать схемы, соглашения об идентификаторах и политики ретенции.
- Обзор соответствия (HIPAA/GDPR/etc.) и регулярные тесты на проникновение.
Если нужно, могу привести детальную DDL-схему конкретных таблиц или пример плана миграции для конкретного изменения.