Интеграция с ЦИСЗ

[ТЗ] Централизованная информационная система здравоохранения — государственная платформа, взаимодействие с которой предусмотрено паспортом мероприятия. Порядок функционирования — Постановление СМ РБ № 267 от 13.05.2021; ввод в эксплуатацию — приказ МЗ РБ № 1729 от 31.12.2024.

Кто с кем разговаривает

[ADR-9] Подсистемы ПАК не подключаются к ЦИСЗ напрямую.

flowchart LR
  subgraph PAK["ПАК 3H"]
    T["«Триаж»"]
  end
  MIS["МИС АИС «Медик»<br/><i>подключена к ЦИСЗ</i>"]
  BUS["Интеграционная шина<br/>центральной платформы<br/>Минздрава"]
  CISZ["ЦИСЗ"]

  T <-->|"FHIR, внутренний контур УЗ"| MIS
  MIS -->|"отправка показателей"| BUS --> CISZ
  MIS <-->|"запрос данных, ЭЦП врача"| CISZ

  X["3H → ЦИСЗ напрямую"]:::forbidden
  classDef forbidden stroke-dasharray: 5 5,color:#999

Основания:

1. [ТЗ] Способ взаимодействия описан как «использование API для запроса данных из ЦИСЗ напрямую из МИС учреждения».
2. [ТЗ] Отправка: «собранные показатели могут быть отправлены в ЦИСЗ посредством интеграционной шины центральной платформы Министерства здравоохранения».
3. [ОП] Данные попадают в ЦИСЗ ретроспективно — для realtime-сценария «карета в пути» ЦИСЗ непригодна в принципе.
4. [ПР] Прямое подключение продублировало бы функцию МИС, потребовало бы отдельной аттестации канала и создало бы второй источник истины по ЭМК.

Из этого следует главная зависимость проекта

Всё, что ПАК должен получить из ЦИСЗ или отправить в неё, проходит через API МИС «Медик». При этом паспорт фиксирует, что доработка МИС не требуется. Если API «Медик» не покрывает нужные операции — возникает незапланированная и непрофинансированная работа. Это R-4; проверка возможностей API МИС — задача стадии проектирования, а не интеграции.

Ресурсы FHIR для обмена

[ТЗ] Перечень определён паспортом. Колонка «Роль ПАК» — [ПР]: что именно подсистемы производят или потребляют.

Ресурс	Назначение по паспорту	Роль ПАК
Patient	Личная информация о пациенте	Читает через МИС при сопоставлении пациента; производит при самообращении нового пациента
Encounter	Обращение пациента за медицинской помощью	Производит — обращение в приёмный покой (FR-T-22)
Observation	Результаты оценки функционального состояния	Производит — витальные показатели из СМП, сортировки и мониторов реанимации
Composition	Сведения о диагнозе пациента	Производит через МИС при оформлении
Bundle	Передача информации в ЦИСЗ	Транспортная обёртка
Practitioner	Участник медицинского процесса	Читает — справочник медработников
PractitionerRole	Специализация и должность	Читает — сбор бригады (FR-T-11)
Location	Структурное подразделение или его часть	Читает — отделения, палаты, койки
Endpoint	Конечные точки организаций здравоохранения	Читает — адресация УЗ
RelatedPerson	Контактное лицо пациента	Производит — вызывающий при вызове СМП (п. 7 набора данных)
DocumentReference	Неструктурированный документ, скан-копия	Производит — сканы документов при оформлении
FamilyMemberHistory	Заболевание или состояние родственника	Читает при наличии
MedicationRequest	Выписанное лекарственное средство или изделие	Не используется ПАК
MedicationStatement	История принятых лекарственных средств	Читает — важно при аллергоанамнезе
AllergyIntolerance※	—	Производит — из данных СМП (п. 20)
Appointment	Бронирование слота в расписании	Не используется ПАК
Schedule	Расписание работы медработника	Не используется ПАК
Slot	Слот в расписании приёма	Не используется ПАК
List	Идентификаторы электронных рецептов	Не используется ПАК

※ [ПР] AllergyIntolerance в перечне паспорта отсутствует, но входит в обязательный набор данных СМП (п. 20 — «Аллергия»). Расхождение требует уточнения: либо ресурс добавляется в перечень обмена, либо аллергоанамнез передаётся в составе Composition. Вопрос вынесен в R-3.

Технические требования к взаимодействию

[ТЗ]

Аспект	Требование
API	REST API или SOAP
Стандарт	HL7 FHIR
Авторизация	ЭЦП врача для доступа к данным и подтверждения действий
Шифрование	TLS/SSL при передаче
Логирование	Фиксация всех действий в системе для прозрачности и контроля
Доступ у койки	Возможность получения информации о пациенте прямо у койки (мобильное приложение или планшет)

«Доступ у койки» — уже покрыт закупкой

Требование получения информации о пациенте прямо у койки обеспечивается закупаемыми планшетами IP65 со сканером ШК (2 шт.). Сценарий: сканирование браслета пациента → запрос сводки через МИС → отображение. См. «Аппаратный комплекс».

ЭЦП: что именно подписывается

[ТЗ] ЭЦП требуется для «подтверждения действий врачей» и «обеспечения подлинности и контроля целостности электронных документов». [ПР] Конкретизация для ПАК:

Действие	Подписывается	Почему
Присвоение цвета сортировки	Результат сортировки + версия правил	Клинически значимое решение; предмет разбора при жалобе
Оформление обращения в приёмный покой	Обращение целиком	Первичный медицинский документ
Передача пациента медработнику (п. 35–36)	Факт передачи ответственности	Юридически значимый момент
Отказ от медпомощи или транспортировки (п. 23)	Consent	Юридически значимо
Выписка из приёмного отделения	Отметка выбытия	Завершение эпизода

ЭЦП нельзя добавить в конце

Подпись охватывает содержимое документа, поэтому структура подписываемых объектов должна быть зафиксирована до реализации: изменение состава полей после внедрения ломает проверку ранее выданных подписей. Требование включено в FR-C-3 и в эпик E11 с началом работ в этапе 1.

Средства ЭЦП — только сертифицированные по приказу ОАЦ № 77 от 12.03.2020.

Что ПАК в ЦИСЗ не отправляет

[ПР] Явное ограничение объёма, чтобы не создать незапланированный поток:

• Координаты карет — операционные данные логистики, медицинского значения не имеют, в ЭМК не входят.

• Логи запросов положения — служебные.

• Сырые входящие Bundle — хранятся локально для разбора инцидентов; в ЦИСЗ идёт нормализованный результат.

• Данные анонимной очереди до оформления — по определению не содержат паспортной части (FR-T-15); в ЦИСЗ попадает уже оформленное обращение.

Последний пункт особенно важен: он согласован с требованием минимизации персональных данных — см. «Безопасность».