Набор данных СМП

[ТЗ] Паспорт задаёт точный объём, в котором взаимодействие бригады СМП с приёмным отделением стационара должно быть организовано на программном уровне. Это нормативный минимум приёмной стороны: система обязана уметь принять и сохранить каждое из перечисленных полей.

Это перечень полей, а не схема сообщения

Паспорт перечисляет, что передаётся, но не задаёт формат. Формат определяется приказом МЗ РБ № 1001 (HL7 FHIR). Ниже — отображение перечня паспорта на ресурсы FHIR и на схему БД. Колонка «Ресурс FHIR» — [ПР], всё остальное — [ТЗ].

Структура набора

flowchart TB
  subgraph CALL["Вызов (п. 1–14)"]
    C1["Время, дата, адрес вызова"]
    C2["Повод и приоритет вызова"]
    C3["Номер бригады, вызывающий"]
    C4["Пациент: ФИО, возраст, пол, полис"]
  end
  subgraph ANAM["Анамнез (п. 15–20)"]
    A1["Травма, жалобы"]
    A2["Анамнез заболевания,<br/>перенесённые заболевания"]
    A3["Акушерско-гинекологический<br/>анамнез, аллергия"]
  end
  subgraph OBJ["Объективные данные (п. 21.1–21.20)"]
    O1["Общее состояние, положение,<br/>поведение, сознание"]
    O2["Шкала ком Глазго"]
    O3["Неврологический статус<br/>(9 подпунктов)"]
    O4["Витальные показатели:<br/>АД, пульс, ЧД, сатурация,<br/>гликемия, ЭКГ"]
    O5["Осмотр по системам:<br/>кожа, слизистые, живот,<br/>печень, отёки, локальный статус"]
  end
  subgraph CARE["Помощь и исход (п. 22–28)"]
    R1["Предварительный диагноз"]
    R2["Оказанная помощь"]
    R3["Состояние после помощи,<br/>результат, смерть, отказ"]
  end
  subgraph TRANS["Транспортировка (п. 29–36)"]
    T1["Транспортировка до/из автомобиля"]
    T2["Положение и состояние в пути"]
    T3["Завершение, УЗ, передача пациента"]
  end
  subgraph MISC["Прочее (п. 37–40)"]
    M1["Примечания, километраж,<br/>сообщение о пациенте,<br/>врач/фельдшер"]
  end

  CALL --> ANAM --> OBJ --> CARE --> TRANS --> MISC

Полный перечень с отображением на FHIR

Вызов и пациент

№	Поле	Ресурс FHIR	Примечание
1	Время	Encounter.period.start	Момент начала эпизода
2	Адрес вызова бригады СМП	Encounter.location[].location.display	Место вызова
3	Фамилия, собственное имя, отчество пациента	Patient.name (family, given[])
4	Возраст (со слов обратившегося), пол	Patient.birthDate / Patient.gender	Возраст может быть приблизительным → Patient.extension с указанием источника «со слов»
5	Повод вызова бригады СМП	Encounter.reasonCode	Кодируется справочником поводов
6	Приоритет вызова бригады СМП	Encounter.priority	Категория по приказу МЗ РБ № 46
7	Вызывает, контактный телефон	RelatedPerson + telecom	Вызывающий ≠ пациент
8	Номер бригады СМП	Device.identifier / Encounter.serviceProvider	Бригада и машина — разные сущности
9	Уточнённые сведения	Encounter.reasonCode.text	Свободный текст диспетчера
10	Страховой полис	Patient.identifier (система полиса)
11	Территориальная амбулаторно-поликлиническая организация	Patient.managingOrganization	Прикрепление пациента
12	Вызов	Encounter.identifier	Идентификатор ЭКВ
13	Безрезультатный выезд	Encounter.status = cancelled + Encounter.extension	Причина безрезультатности
14	Дата и время	Encounter.period	Уточнение п. 1

Анамнез

№	Поле	Ресурс FHIR	Примечание
15	Травма	Condition (категория «травма»)	Влияет на маршрутизацию и режим «светофор»
16	Жалобы	Condition.code / Observation (survey)
17	Анамнез заболевания	Condition + Encounter.reasonReference
18	Перенесённые заболевания	Condition (clinicalStatus = resolved)
19	Акушерско-гинекологический анамнез	Observation / Condition	Категория — женское репродуктивное здоровье
20	Аллергия	AllergyIntolerance	Критично для приёмного отделения

Аллергия обязана доезжать до приёмника целиком

AllergyIntolerance — единственное поле набора, потеря которого может привести к прямому вреду пациенту при назначении препарата. Правило нормализации: если вендор передал аллергологический анамнез в формате, который ACL не смог разобрать, поле не отбрасывается — сырой текст сохраняется и выводится оператору с пометкой «не структурировано». См. «Адаптеры».

Объективные данные (п. 21)

Ядро для движка правил сортировки. Все — Observation, привязанные к Encounter.

№	Поле	Код	Тип значения
21.1	Общее состояние	справочник	код
21.2	Положение	справочник	код
21.3	Поведение	справочник	код
21.4	Шкала ком Глазго	LOINC 9269-2	valueInteger 3–15
21.5	Сознание	справочник	код
21.6	Неврологический статус	группа Observation.hasMember	см. ниже
21.6.1	Зрачки	справочник	код
21.6.2	Речь	справочник	код
21.6.3	Походка	справочник	код
21.6.4	Лицо	справочник	код
21.6.5	Нистагм	справочник	valueBoolean / код
21.6.6	Тонус мышц	справочник	код
21.6.7	Патологические рефлексы	справочник	код
21.6.8	Менингеальные знаки	справочник	код
21.6.9	Плегии, парезы	справочник	код + локализация
21.7	Кожа	справочник	код
21.8	Слизистые	справочник	код
21.9	Артериальное давление	LOINC 85354-9 (панель), компоненты 8480-6 / 8462-4	valueQuantity мм рт. ст.
21.10	Тоны сердца	справочник	код
21.11	Пульс	LOINC 8867-4	valueQuantity уд/мин
21.12	Асцит; периферические отёки	справочник	код
21.13	Частота дыхания	LOINC 9279-1	valueQuantity /мин
21.14	Живот	справочник	код
21.15	Печень	справочник	код
21.16	Мочеиспускание; стул	справочник	код
21.17	Локальный статус	текст	valueString
21.18	Электрокардиограмма	LOINC 11524-6	valueString + при наличии Media
21.19	Гликемия	LOINC 2339-0	valueQuantity ммоль/л
21.20	Сатурация	LOINC 2708-6 / 59408-5	valueQuantity %

Шесть показателей, на которых держится сортировка

Выделенные жирным — шкала Глазго, АД, пульс, ЧД, гликемия, сатурация — это те значения, из которых движок правил выводит цвет. Они обязаны быть числовыми и нормализованными по единицам; для них ACL не имеет права на «не структурировано». Остальные поля могут приходить как коды справочника или текст.

Обратите внимание: температура в перечне паспорта отсутствует, хотя операционные требования включают её в набор анонимной сортировки самообращений (FR-T-15). Расхождение разобрано в «Логике ТРИАЖ» — для СМП-пациентов температура не является обязательным входом правил.

Помощь, исход, транспортировка

№	Поле	Ресурс FHIR	Примечание
22	Предварительный диагноз врача (фельдшера) СМП	Condition + Encounter.diagnosis	Ключевое для сбора бригады встречи
23	Отказ от медпомощи, от транспортировки (эвакуации)	Consent (отказ)	Юридически значимо
24	Медицинская помощь на месте вызова и при транспортировке	Procedure, MedicationAdministration
25	Состояние пациента после оказания помощи	Observation	Сравнение с 21.1 — динамика
26	Результат оказания медицинской помощи	Encounter.extension / Observation
27	Смерть	Patient.deceased[x] + Encounter.status	Останавливает маршрут в приёмник
28	Результат выезда	Encounter.hospitalization.dischargeDisposition
29.1	Транспортировка до автомобиля	Procedure	Способ переноски
29.2	Транспортировка из автомобиля	Procedure
30	Положение пациента во время транспортировки	Observation
31	Состояние пациента во время транспортировки	Observation (поток)	Источник transport_health_status
32	Состояние пациента после транспортировки	Observation	Фиксируется при доставке
33	Завершение транспортировки бригадой СМП	Encounter.period.end	Отсечка времени доставки (FR-T-13)
34	Организация здравоохранения	Encounter.hospitalization.destination	Целевое УЗ
35	Передача пациента медицинскому работнику	Encounter.participant	Момент передачи ответственности
36	Медицинский работник, принявший пациента	Practitioner + PractitionerRole	Принимающая сторона
37	Примечания	Encounter.note	Свободный текст
38	Километраж выезда	Encounter.extension	Для отчётности СМП
39	Сообщение о пациенте	Communication	Предуведомление приёмника
40	Врач СМП / Фельдшер	Practitioner + qualification	Кто оказывал помощь

Покрытие набора по типам сообщений

Не все 40 полей приходят одновременно. Распределение по пяти типам входящих сообщений:

flowchart LR
  R["transport_request<br/>запрос мест"] --> R1["п. 4, 5, 6, 22<br/>минимум для решения<br/>о госпитализации"]
  N["transport_notification<br/>направление"] --> N1["п. 1–28, 34, 40<br/>основной массив"]
  H["transport_health_status<br/>состояние в пути"] --> H1["п. 21.x, 30, 31<br/>поток обновлений"]
  C["transport_cancel<br/>отмена"] --> C1["п. 12, 13, 23, 27, 28"]
  D["transport_complete<br/>доставка"] --> D1["п. 32, 33, 35, 36, 38<br/>отсечка времени"]

Поле	request	notification	health_status	cancel	complete
Идентификатор вызова (п. 12)	✅	✅	✅	✅	✅
Пациент (п. 3, 4, 10)	частично	✅	—	—	—
Повод и приоритет (п. 5, 6)	✅	✅	—	—	—
Бригада (п. 8, 40)	✅	✅	—	—	✅
Анамнез (п. 15–20)	—	✅	—	—	—
Объективные данные (п. 21)	частично	✅	✅	—	✅
Диагноз (п. 22)	✅	✅	—	—	—
Помощь (п. 24)	—	✅	✅	—	✅
Исход (п. 26–28)	—	—	—	✅	✅
Транспортировка (п. 29–33)	—	—	✅	—	✅
Передача (п. 35, 36)	—	—	—	—	✅

Почему в transport_request полей мало

Запрос на возможность госпитализации приходит до решения о направлении и должен обрабатываться быстро. Для ответа «есть место / нет» достаточно профиля пациента, повода, приоритета и предварительного диагноза — по ним определяется профильное отделение. Требовать полный набор на этом шаге означало бы задерживать бригаду у пациента.

Открытые вопросы по набору

[?] Требуют уточнения у разработчиков МРМ СМП до начала реализации ACL:

#	Вопрос	Почему блокирует
1	Какие из полей п. 21.x передаются кодами справочника, а какие свободным текстом?	Определяет, можно ли использовать поле в правилах сортировки
2	Какие справочники используются для «общего состояния», «сознания», «неврологического статуса»?	Без них ACL не сможет нормализовать коды
3	Передаётся ли AllergyIntolerance структурно?	См. предупреждение выше
4	Есть ли стабильный идентификатор сообщения для идемпотентности?	ADR-3; при отсутствии — деградация на хеш тела
5	Частота сообщений transport_health_status — фиксированная или по изменению?	Определяет объём vital_observations и партиционирование
6	Передаётся ли ЭКГ (п. 21.18) как файл/изображение или только текстовое заключение?	Влияет на хранение и на Media

Полный список рисков — в «Рисках и открытых вопросах».