Quartz 4

RuCore — Russian Core FHIR Implementation Guide

active
Not verified

Created · Updated 4 min read

Российский аналог US Core / IL Core / HL7 EU Base — базовые профили FHIR-ресурсов под российские реалии. Делается рабочей группой HL7 FHIR Russia (модератор — Е.Коган, ведёт сам IG).

Цель: дать «национальную модель медицинских данных» как layer профилей, от которой наследуются прикладные спецификации (Ru-SEMD, отраслевые СЭМД, российские vendor-профили). Прикладные IG не профилируют FHIR-core напрямую — они профилируют RuCore.

Где живёт

FHIR-уровень

  • FHIR R5. Решение группы — основной слой на R5, прикладные спецификации могут быть R4-аналогами при необходимости, но новые работы — R5. Это контрастирует с BloodGPT (мы на R4 во всём стеке, см. fhir-versions).
  • Профилирование через FSH (FHIR Shorthand), 168 артефактов (Core + SEMD + PLI на момент июля 2025).

Что профилируется

Основные профили — те, что часто перекодируются российскими СЭМД:

  • core-patient (Patient) — российские identifier-системы (СНИЛС, полис ОМС), ru-расширения для пола/гражданства
  • core-relatedperson — отношения представителя к пациенту, codes с маппингом на HL7 RoleCode + три минздравовских справочника
  • core-practitionerrole — code привязан к справочнику специальностей из НСИ Минздрава РФ
  • core-address — только для российских адресов (КЛАДР / ФИАС-based fields). Важное ограничение: профиль НЕ применяется к адресам не-РФ объектов (см. ниже «Известные ошибки»).
  • core-organization — российские МО, OGRN, и т.п.
  • Финансовые ресурсы — в декабре 2025 — январе 2026 решено добавить Claim, ClaimResponse, Contract для моделирования взаиморасчётов ОМС. Драйвер — необходимость покрыть ГИС ОМС.

Каждый профиль имеет вводный текст в IG, описывающий принятые решения.

Известные ошибки и open вопросы

  • Address constraint mismatch (исправлено в 0.3.0): профиль core-address ошибочно применялся к Patient.address, что навязывало РФ-структуру на адреса не-РФ объектов. Coгласовано на встрече 24.03.2026, выпущено в 0.3.0.
  • Extension search parameters gap: в RuCore добавлялись custom extensions, но SearchParameter-определения для них не делались — поэтому extension-поля не работают как search parameters. Известно с марта 2026.
  • Over-strict constraints (апрель 2026): Олег Пензин на встрече 28.04.2026 высказал опасение, что текущие ограничения RuCore мешают наследованию от него. Коган провёл исследование (blockers.md), результаты подтвердили опасение — конкретные cardinality-ограничения и must-support пометки приходится ослаблять. Это активная open-thread, влияет на готовящийся ГОСТ.
  • Парадокс с extensions: RuCore широко использует extensions для российских специфик. Контрастирует с нашим решением минимизировать extensions — но контексты разные: они моделируют национальные регуляторные требования (СНИЛС, ОМС-полис), мы — AI-output на стандартном R4. При интеграции с RuCore наш extension-набор останется, плюс мы будем наследовать их экстеншены для PHI-полей.

Отношения с другими IG

  • Ru-SEMD — единая структура заголовков СЭМД-документов; наследуется от RuCore. IG для конкретных типов медицинских документов в России. Опубликованного рендера IG нет: декларируемый canonical https://fhir.ru/ig/semd и https://build.fhir.org/ig/fhir-ru/Ru-SEMD оба отдают 404 (Ru-SEMD не зарегистрирован в build.fhir.org/ig/qas.json). Читаемый артефакт — только source на GitHub: https://github.com/fhir-ru/Ru-SEMD (версия 0.1.0, последний коммит июль 2025).
  • PLI_SEMD (СЭМД Протокол Лабораторного Исследования) — наследуется от RuSEMD. На R5, 13 типов ресурсов, см. github.com/fhir-ru/core/discussions/290.
  • ГОСТ по интероперабельности (в активной разработке май 2026) — нормативно закрепляет правила профилирования и сам RuCore как base. Текст версии 005, готовится через ТК468.

Релевантность для BloodGPT

Сегодня не используем — наш FHIR (multi-tenant-fhir-storage) на чистом R4 для Healthcare API. Если BloodGPT выходит на российский рынок и нужна интеграция с ЕГИСЗ / российскими МИС:

  • Профилирование AI-output (Composition / CarePlan / Observation) — наследоваться от соответствующих RuCore-профилей, не от vanilla R4.
  • PHI-поля Patient (СНИЛС, ОМС-полис, гражданство) — через RuCore extensions; не изобретать свои.
  • Provider/Practitioner — core-practitionerrole с кодами специальностей из НСИ Минздрава.
  • Address — только если объект в РФ; для не-РФ vendor’ов остаётся vanilla Address.
  • Версия FHIR — если RuCore-совместимость нужна, R5; ещё одна причина не торопиться с R5-миграцией без чёткой потребности.

Open carry-over: реальная задача интеграции пока не стоит. Если возникнет — детально проанализировать наши Composition/CarePlan/Observation профили на совместимость с RuCore-cardinalities и must-support.

Связано

  • us-core — американский аналог; контраст по регуляторному статусу (US Core обязателен через HTI-1, RuCore — пока в разработке ГОСТ) и extension-подходу
  • fhir-russia-working-group — кто и как ведёт RuCore, формат работы группы
  • nsi-rosminzdrav — основной источник терминологии для российских codesystems в RuCore
  • fhir-versions — наш статус по R4/R5 и почему мы пока R4
  • zero-extensions-fhir — наш подход к extensions, контраст с RuCore approach
  • hapi-fhir — vendor FHIR-server; в FHIR-Russia сообществе обсуждался как один из options
  • google-healthcare-api — наш текущий FHIR backend

Источники

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

Сноски

  1. RuCore IG, accessed 2026-05-17, https://build.fhir.org/ig/fhir-ru/RuCoreIG. ↩

  2. Версии, accessed 2026-05-17, https://build.fhir.org/ig/fhir-ru/RuCoreIG/history.html. ↩

  3. GitHub, accessed 2026-05-17, https://github.com/fhir-ru/core. ↩

  4. Discussions, accessed 2026-05-17, https://github.com/fhir-ru/core/discussions. ↩

  5. Ru-SEMD source, accessed 2026-05-17, https://github.com/fhir-ru/Ru-SEMD — canonical https://fhir.ru/ig/semd и https://build.fhir.org/ig/fhir-ru/Ru-SEMD пока 404 — рендера IG нет, только репо). ↩

  6. RuCore IG GitHub Pages mirror (fallback), accessed 2026-05-17, https://fhir-ru.github.io/core/. ↩

Graph View

Backlinks