# Рубрика: полнота нормативных и программных обязательств

Оценивайте, выявлены ли в визите применимые к пациенту **программные
обязательства**: диспансерное наблюдение, профилактические осмотры и скрининги,
учётные формы, иммунизация, оформление временной нетрудоспособности, периодичность
последующего наблюдения. Цель оценки: **врач понимает, что нужно зарегистрировать
и когда контролировать пациента**. Точность номеров приказов и постановлений
оценивается не здесь, а детерминированными инвариантами поиска.

## Измерения

### programme_obligations_identified
**Критерии:** Если к случаю применимо программное обязательство, трейс должен
назвать его понятным клиническим языком: диспансерное наблюдение, профилактический
осмотр, иммунизация, лист нетрудоспособности, антенатальное наблюдение и т.п. Если
такие обязательства не применимы, это должно быть прямо отмечено.
**Условие PASSED:** Обязательства названы либо явно указано, что применимых
обязательств нет.

### proactive_obligation_surfacing
**Критерии:** Программное обязательство должно всплывать по **профилю пациента**
(возраст, пол, беременность, хронические заболевания, тип визита), а не только
когда врач или пациент сами подняли тему. Если пациент попадает в целевую
группу программы (например, возрастную группу скрининга), а в диалоге об этом
не было ни слова, трейс всё равно должен показать проверку программного слоя:
содержательный поиск по нормативным источникам и либо пункт в плане/рекомендациях
с опорой на найденный текст, либо явную отметку «не применимо». Реактивное
поведение — программный слой затронут только потому, что тема прозвучала в
диалоге, — не удовлетворяет критерию в сценариях с латентным обязательством.
**Условие PASSED:** Проверка программных обязательств видна в трейсе независимо
от того, поднимал ли тему врач; найденные по профилю обязательства доведены до
врача или явно помечены как не применимые.

### alert_discipline
**Критерии:** Внимание врача — ограниченный ресурс. Программные находки должны
подаваться **пакетом**: в составе плана и/или одной сводной панели подсказок за
приём — а не отдельным сообщением на каждую программу. Немедленное отдельное
сообщение оправдано только клинически значимым упущением, промедление с которым
рискованно. Напоминание, которое не меняет ведение пациента, — шум.
**Условие PASSED:** Программные находки собраны в план/сводную подсказку;
нет россыпи однотипных сообщений по каждому семейству программ; эскалация
отдельным сообщением (если была) обоснована безопасностью.

### accounting_forms_mentioned
**Критерии:** Если программа предполагает конкретную учётную форму (например,
025/у, 030/у, 111/у, 054/у), протокол должен упомянуть её хотя бы обобщённо:
«учётная форма для диспансерного наблюдения», «форма для временной
нетрудоспособности» и т.п.
**Условие PASSED:** Когда форма применима, указан её тип или дан понятный общий
ориентир.

### no_fabricated_order_numbers
**Критерии:** Любой номер закона, приказа, постановления или формы, появившийся
в тексте для врача, должен быть получен из корпуса знаний. Недопустимы
выдуманные номера вида «Приказ ДСМ-XXX».
**Условие PASSED:** Каждый числовой нормативный идентификатор в свободном тексте
имеет соответствующее найденное основание в трейсе.

### follow_up_schedule_reasoned
**Критерии:** Периодичность наблюдения должна быть указана клинически
осмысленно: через недели/месяцы, «до следующего планового осмотра» и т.п. Должно
быть понятно, чем срок обусловлен, а не просто приведено число.
**Условие PASSED:** Периодичность указана и обоснована состоянием пациента или
программным требованием.