В BloodGPT — концептуальный фрейм для проектирования summary, собственного IPS-документа в продакшене нет.

Международный стандарт минимального медицинского extract о пациенте. ISO 27269 + HL7 FHIR IPS Implementation Guide v2.0.0. Семантика — “essential healthcare information” для emergency, cross-border handoff, передачи specialist-у. Не полная медкарта; минимальный clinically-significant snapshot.

Структура

FHIR Bundle (type=document) с fhir-composition как root. Composition группирует sections.

Обязательные секции (с LOINC через loinc):

  • Allergies — 48765-2
  • Medications — 10160-0
  • Problems (active conditions) — 11450-4

Опциональные (~20): Procedures, Immunizations, Devices, Results (labs), Vital Signs, Past Illness History, Functional Status, Plan of Care.

emptyReason — критичный нюанс

Для обязательных секций без данных нужно явно указать причину пустоты:

  • nilknown — известно что нет (“no known allergies”)
  • unavailable — не выяснили / не спросили

Клинически важно: “нет аллергий” ≠ “не спросили”.

$summary operation — server-side генерация IPS

Стандартный FHIR-operation для генерации IPS Bundle на стороне сервера. Клиент делает GET Patient/{id}/$summary → сервер сам собирает Bundle согласно IPS-стандарту из имеющихся ресурсов пациента.

  • hapi-fhir — поддерживает с версии 7.2 (built-in implementation).
  • google-healthcare-api (наш production backend) — поддержка $summary неочевидна, нужно verify (см. О1). Если не поддерживается — генерация IPS должна быть на нашей стороне.

Важно: у нас сейчас $summary НЕ используется — мы не имеем production-IPS-документа для пациентов. Composition мы создаём только для test-level overview (см. fhir-composition). IPS остаётся как concept/reference, не реализован.

Использование в BloodGPT

Concept-фрейм, не реализация. IPS-стандарт повлиял на наше мышление о patient summary (см. session 18d2aef8 — initial discovery), но:

  • Собственного Patient-level IPS-документа у нас нет
  • Patient/$summary operation пока не используем
  • Patient/$everything (другая стандартная FHIR-операция, тоже не наша придумка — это часть FHIR-спеки) может быть использован если нужно отдать полный пакет данных пациента, но в production cutover ещё не перешли

Открытые вопросы

[О1] Поддерживает ли Google Healthcare API $summary

Нужно verify. Если да — потенциально упрощает реализацию IPS-документа: server-side собирает Bundle из existing resources. Если нет — придётся писать свой IPS-builder.

[О2] Нужен ли нам Patient-level IPS вообще

Мы pivot-нулись на test-level Composition. Patient-level IPS — другой use case (cross-org sharing, emergency context). Решение зависит от того, появятся ли у нас такие сценарии.

Связано

  • fhir-composition — root resource для IPS Bundle
  • fhir-bundle — Bundle type=document
  • loinc — required sections кодируются LOINC
  • hapi-fhir — built-in $summary operation
  • google-healthcare-api — наш FHIR backend, поддержка $summary под вопросом
  • (TBD-страница про нашу cold-start scoring + 2-layer model — см. log.md, отдельная concept-страница нужна)
  • abridge, nabla, ambience — индустрия-патrns поверх IPS

Источники

Источники: 1 2 3 4 5.

**Замечание (от Ильдара.

Сноски

  1. HL7 FHIR IPS IG v2.0.0, accessed 2026-05-17, http://hl7.org/fhir/uv/ips/.

  2. ISO 27269, accessed 2026-05-17, https://www.iso.org/standard/79491.html.

  3. HAPI $summary, accessed 2026-05-17, https://hapifhir.io/hapi-fhir/docs/server_plain/ips.html.

  4. IPS Bundle examples (HL7), accessed 2026-05-17, http://hl7.org/fhir/uv/ips/STU2/.

  5. Сессия ildar/18d2aef8, 2026-01-30 — (origins discovery)