Терапевтический приём. Новая версия

[maxirmx]

Telegram messages

Разбил вест терапевтический приём на три части. Постарался указать все метки которые есть в шаблоне. Зеленым отмечены те, что должны отображаться в тексте (read-only версии для просмотра), серым отмечены те, что не должны отображаться в тексте (read-only версии для просмотра). Желтым отмечены новые пункты.

Шаблон терприёма осмотр.docx
Шаблон_терприёма_анамнез_жизни_122408.docx
Шаблон_терприёма_проблема_и_анамнез_болезни_122311.docx

Telegram: Вячеслав Порада · 2026-09-04T09:27:59.000Z

[maxirmx]

Структурированное описание: терапевтический приём v2

Цель

Заменить текущую реализацию therapeutic-appointment-v1, созданную по #6, новой версией, точно соответствующей согласованным доменным шаблонам из этой задачи. Текущая реализация и #6 являются только источниками данных для миграции, но не нормативным описанием поведения.

Источник истины и приоритет требований

1. Три DOCX-файла, приложенные к Терапевтический приём. Новая версия #117, — нормативный источник состава полей, вариантов, вложенности и подписей.
2. Пояснение к цветам в Терапевтический приём. Новая версия #117 — нормативный источник правил read-only-представления.
3. Шаблон Терапевтический прием #6 используется только для поведения, которое не противоречит Терапевтический приём. Новая версия #117 и не изменено новыми шаблонами.
4. Текущий код не является спецификацией: добавленные при реализации v1 группировки, обязательность, взаимоисключение, зависимости или варианты не сохраняются, если их нет в Терапевтический приём. Новая версия #117.

Цвета в DOCX — это метаданные спецификации, а не требование окрашивать интерфейс:

• зелёная метка выводится в read-only-представлении, если в её ветке есть заполненное значение;
• серая метка нужна только в редакторе и в read-only-представлении не выводится; выбранные под ней значения при этом выводятся на правильном уровне иерархии;
• жёлтым отмечено изменение относительно предыдущей версии;
• пустые и невыбранные ветки не выводятся.

Объём

Пересобираются три структурированные части терапевтического приёма:

1. «Проблема и анамнез болезни»;
2. «Анамнез жизни»;
3. «Осмотр».

Существующие свободные разделы «Рекомендации» и «Назначения» в рамках этой задачи не меняют своего поведения: в приложенных шаблонах для них нет новой структуры. Будущие справочники рекомендаций и препаратов, упомянутые в #6, остаются вне scope.

Общие правила редактора

• Все поля терапевтического приёма необязательны по отдельности. Нельзя добавлять обязательность, которой нет в шаблоне (например, требовать одновременно вид препарата и динамику только потому, что выбрано «применялись»).
• Иерархия и условное раскрытие полей повторяют DOCX. При смене родительского ответа скрытые дочерние значения очищаются.
• Одиночный/множественный выбор следует структуре шаблона и явным пометкам эксперта. Нельзя объединять две разные ветки в одно поле или создавать дополнительный взаимоисключающий родительский ответ для удобства реализации.
• Свободный текст сохраняет переводы строк, участвует в поиске по медицинской истории и отображается в read-only-представлении рядом со своей доменной меткой.
• Можно создать несколько проблем. Импорт из «Что случилось» сохраняется; серверный идентификатор исходного пункта переносится без реконструкции по тексту.
• В редакторе могут использоваться поясняющие подписи, в том числе серые метки. Правила зелёного/серого относятся именно к итоговому read-only-тексту.

Изменения относительно v1

Проблема и анамнез болезни

• Для каждой проблемы добавить отдельное свободное поле «Описание проблемы»; оно относится к конкретной проблеме, а не к общему комментарию всего анамнеза.
• Сохранить повторяемость проблем и поля: название проблемы, срок начала, периодичность, терапия до осмотра, препараты, свободное название препаратов и динамика.
• В «Мочеиспускание → изменилось» варианты 2.1–2.7 сделать множественным выбором.
• Для редкой рвоты добавить варианты: «1 раз в 2–3 суток», «1 раз в неделю», «1–2 раза в месяц».
• «Пенистые» и «Не пенистые» перенести непосредственно в множественный выбор «Рвотные массы». Отдельное условное поле/всплывающий селектор пенистости удалить.
• Остальные разделы, варианты и связи воспроизвести по файлу «Шаблон_терприёма_проблема_и_анамнез_болезни» без дополнительной перегруппировки.

Анамнез жизни

Добавить свободные поля:

• название средства обработки от эктопаразитов;
• название средства для дегельминтизации;
• название продуктов натурального рациона;
• название промышленного корма;
• название перенесённого/сопутствующего заболевания.

Остальные варианты и условные ветки воспроизвести по файлу «Шаблон_терприёма_анамнез_жизни».

Осмотр

• «Ротовая полость → Изменения»: добавить «Петехии/кровоизлияния».
• «Наружный слуховой проход → Кожа»: добавить «С новообразованием».
• Использовать подпись «Чем/как заполнен канал».
• «Шерсть»: добавить свободное поле «Дополнительно».
• Ветки «Гипотрихоз» и «Алопеция» должны иметь собственные значения распределения и количества локальных участков. Их нельзя хранить в одном общем поле, как в v1.
• «Брюшная стенка → Пальпируемые находки»: добавить «Инородный предмет».
• «Опороспособность»: добавить собственное свободное поле «Комментарии».
• Не создавать искусственный взаимоисключающий ответ «Есть другие изменения»: хромота, другие состояния, судороги и дискинезия должны соответствовать независимым веткам шаблона. Взаимоисключение допустимо только там, где оно следует из документа.
• Удалить варианты v1, которых нет в новом шаблоне, в частности «Увеличены мультифокально» для ПЛУ.
• Общий комментарий к осмотру сохраняется отдельно от нового комментария к опороспособности.
• Остальные варианты, вложенность и подписи воспроизвести по файлу «Шаблон терприёма осмотр».

Read-only-представление

• Сохранить последовательное представление без вкладок: показывать все непустые части приёма в порядке шаблона.
• Формировать результат как доменную иерархию, а не как плоский список пар «техническая подпись — значение».
• Выводить только зелёные метки из DOCX. Конкретные служебные вопросы, отмеченные серым (например, Состояние, Наличие, Регулярность), не должны попадать в текст, но их выбранные значения не теряются.
• Не выводить идентификаторы, номера вариантов и названия полей, придуманные реализацией v1.
• Все новые свободные поля и выбранные новые варианты выводятся на соответствующем уровне.
• Представление владельца и врача использует один и тот же компонент/форматтер и даёт одинаковый текст.

Формат данных и миграция

• Ввести therapeutic-appointment-v2. После выпуска клиент и API создают и изменяют только v2; сериализатора, валидатора, редактора или отдельного read-only-компонента v1 не остаётся.
• Выполнить одностороннюю, детерминированную и идемпотентную best-effort миграцию free-text-v0/therapeutic-appointment-v1 → v2. Исторические события не переписывать: преобразование выполняется при построении/обновлении проекции, а последующее сохранение создаёт только v2.
• Поля и option ID с неизменившейся семантикой переносятся напрямую. Названия проблем, общий текст, рекомендации, назначения и связь с sourceWhatHappenedId сохраняются.
• Для каждой старой проблемы новое поле описания и все остальные новые свободные поля инициализируются пустыми.
• Старое одиночное значение изменения мочеиспускания становится первым элементом нового множественного значения.
• Старые значения пенистости переводятся в новые варианты «Рвотных масс»; исходные выбранные цвет/тип масс сохраняются.
• Для общей v1-ветки шерсти: если выбран только гипотрихоз или только алопеция, детали относятся к выбранной ветке; если выбраны обе ветки и принадлежность неоднозначна, нельзя угадывать — человекочитаемые старые значения сохраняются в миграционной заметке/общем комментарии осмотра.
• Искусственный v1-маркер «Есть другие изменения» не переносится, а его дочерние клинические значения переносятся в соответствующие независимые ветки v2.
• Удалённые и неизвестные option ID не отбрасываются молча: известная старая подпись (либо ID, если подписи нет) добавляется в миграционную заметку соответствующей части. Так же сохраняется free-text-v0.
• Ошибка преобразования не должна превращать заполненный приём в пустой. Она отображается как явная ошибка миграции; legacy UI при этом не включается.
• Совместимость replay обеспечивается миграцией старого payload на границе проекции. Это техническая совместимость истории, а не поддержка legacy-версии в продукте.

Критерии приёмки

• Каталог v2 снапшот-тестом проверяет все разделы, варианты, режимы выбора, зависимости, порядок и признак показа метки в read-only согласно трём DOCX.
• Компонентные тесты проверяют каждую жёлтую правку, раздельные ветки шерсти, независимые ветки опороспособности и отсутствие удалённых вариантов.
• Read-only-тесты проверяют все зелёные и серые метки: зелёные появляются только при наличии данных, серые не появляются никогда, значения и свободный текст сохраняются.
• Миграционные тесты покрывают v0, обычный v1, пенистость, мочеиспускание, обе ветки шерсти, удалённый/неизвестный ID, повторный запуск миграции и невозможность тихой потери заполненных данных.
• API валидирует v2 теми же правилами, что клиент; после выпуска v1 не принимается для новых записей/изменений и нигде не создаётся.
• Поиск по истории находит новые свободные поля и новые значения.
• E2E покрывает создание, сохранение, повторное открытие, редактирование, просмотр владельцем и врачом, а также открытие мигрированной записи.
• Обязательные проектные проверки: npm run test:e2e:compose и не менее 90% Codecov patch coverage.

Definition of Done

Новая запись, мигрированная старая запись и одна и та же запись в представлении врача/владельца используют единый v2-контракт и дают одинаковый доменный текст по правилам #117; legacy-веток UI/API нет, а ни одно распознанное старое значение не теряется молча.

[maxirmx]

Уточнение по замечанию заказчика: «При аускультации»

В разделе «Грудная полость» подпись v1 «Дыхание в лёгких» является несогласованной и должна быть заменена подписью из нового шаблона «При аускультации». Варианты характера дыхания сохраняются под этой новой меткой; «Шумы» относятся к тому же аускультативному блоку согласно DOCX.

Это правило распространяется и на миграцию:

• выбранные в v1 значения exam.chest.lung-breathing.* переносятся в соответствующие значения v2 без потери;
• старая отображаемая подпись не переносится и не сохраняется как текст — migrated read-only строится по каталогу/метаданным v2 и показывает «При аускультации»;
• для новой и мигрированной записи regression-тест должен подтверждать наличие «При аускультации» и отсутствие «Дыхание в лёгких» в редакторе и read-only-представлении врача/владельца.