Когда смотришь на поисковые запросы вокруг клинических рекомендаций, быстро становится видно, что пользователю нужен не «еще один каталог PDF», а нормальный слой доступа к знаниям.
В одном кластере живут запросы вроде «рубрикатор клинических рекомендаций», «клинические рекомендации Минздрав», «клинические рекомендации 2025» и «клинические рекомендации 2026». В другом — «клинические рекомендации у детей», «клинические рекомендации у взрослых», «новорожденный клинические рекомендации». В третьем — «тесты по клиническим рекомендациям», «НМО клинические рекомендации», «ответы по утвержденным клиническим рекомендациям». И отдельно огромный хвост по нозологиям: диабет, пневмония, артериальная гипертензия, астма, анемия, инсульт, шок, инфекции у детей.
С инженерной точки зрения это важное наблюдение: перед нами не одна задача поиска, а сразу несколько разных сценариев, которые нельзя нормально закрыть одним полем search над набором документов.
Официальный источник, от которого все начинается, существует: это электронный рубрикатор клинических рекомендаций Минздрава. На ресурс Минздрава публикуются клинические рекомендации, разработанные и утвержденные медицинскими профессиональными некоммерческими организациями; сам Минздрав отдельно указывает, что этот контент предназначен для медицинских и фармацевтических работников. Кроме того, в инфраструктуре Минздрава есть отдельная автоматизированная подсистема, связанная с разработкой стандартов медпомощи и электронным рубрикатором клинических рекомендаций.
С нормативной стороны тема тоже не статична. В справочной информации КонсультантПлюс указано, что клинические рекомендации пересматриваются не реже одного раза в три года, а рекомендации, опубликованные после 1 января 2025 года, применяются с даты размещения в рубрикаторе на официальном сайте Минздрава России. В конце 2025 года также был официально опубликован приказ Минздрава об утверждении порядка применения клинических рекомендаций.
То есть данные живые, обновления продолжаются, и у врача, преподавателя, разработчика medtech-сервиса или автора НМО-курса нет роскоши работать с “раз и навсегда собранной” базой.
Где ломается реальный сценарий
Если отбросить красивую витрину и посмотреть на практику, проблема почти всегда одна и та же: врачу редко нужен документ целиком.
Обычно нужен ответ на более узкий вопрос:
какая схема лечения указана в актуальной версии;
есть ли отдельная рекомендация для детей или это документ для взрослых;
где именно в тексте находятся диагностические критерии;
как быстро перейти от диагноза или кода МКБ-10 к релевантной КР;
как проверить себя по разделу, если готовишься к тестам или НМО;
как открыть нужный фрагмент без стабильного интернета.
И вот здесь формат “длинный документ + базовый поиск по названию” начинает сбоить.
Проблема не в том, что PDF как формат плох. Проблема в другом: клиническая задача фрагментарна, а документ — линейный. Пользователь мыслит не страницами, а сущностями:
болезнь;
возрастная группа;
этап ведения;
диагностика;
лечение;
дозировки;
противопоказания;
маршрутизация;
тестовый вопрос.
Если интерфейс не умеет жить на уровне этих сущностей, человеку приходится каждый раз “распаковывать” документ вручную.
Почему поиск по заголовку документа почти бесполезен
На словах все выглядит просто: есть рубрикатор клинических рекомендаций, есть карточка документа, есть поиск. Но в реальной выдаче возникают как минимум пять типов запросов.
1. Поиск по нозологии
Например:
«сахарный диабет клинические рекомендации»,
«пневмония клинические рекомендации»,
«анемия клинические рекомендации».
Тут еще можно жить на заголовках и синонимах.
2. Поиск по возрастной группе
Например:
«клинические рекомендации у детей 2025»,
«клинические рекомендации у взрослых»,
«инфекции у детей клинические рекомендации».
Здесь уже одного названия мало: нужно учитывать возрастную категорию документа и уметь не смешивать детские и взрослые версии.
3. Поиск по разделу внутри документа
Например:
«артериаль��ая гипертензия клинические рекомендации лечение»,
«бронхиальная астма клинические рекомендации дозировки»,
«острый панкреатит клинические рекомендации диагностика».
На этом уровне поиск по карточке документа начинает проигрывать. Пользователю нужен уже не сам документ, а релевантный фрагмент.
4. Поиск по коду МКБ-10
На практике много сценариев начинается не с названия болезни, а с кода. Особенно если человек работает в МИС/ЭМК, оформляет записи или быстро сверяет диагноз.
Значит, системе нужны не только тексты КР, но и нормальный слой сопоставления с МКБ-10.
5. Поиск “не по медицине, а по учебному действию”
Запросы вроде «тесты по клиническим рекомендациям», «ответы теста клинические рекомендации», «НМО по утвержденным клиническим рекомендациям» на самом деле не всегда означают желание просто получить “готовые ответы”. Очень часто это запрос на более приземленную вещь:
быстро найти нужный раздел, понять логику документа и проверить себя по нему.
Для продукта это важная разница.
Если не понять ее, получится мусорный “сборник ответов”.
Если понять — можно собрать нормальный учебный слой поверх официального источника.
Что это значит для архитектуры
Из этого довольно быстро рождается не “сайт с документами”, а многослойная система.
Я для себя разложил такую задачу на шесть слоев.
1. Источник истины и версионирование
Первое и главное: у сервиса должен быть один явный source of truth.
Если речь идет именно о клинических рекомендациях Минздрава РФ, то этим источником должен быть официальный рубрикатор и связанные с ним материалы, а не чьи-то пересказы. Это особенно важно сейчас, когда в 2026 году продолжают появляться новые и обновленные версии рекомендаций. Например, в начале 2026 года в рубрикаторе были размещены обновления по туберкулезу у взрослых, кариесу у детей и взрослых, раку бронхов и легкого у взрослых, а в марте — обновленная рекомендация по сахарному диабету 1 типа у взрослых.
Но одного “скачать документ” мало. Нужен еще и слой версий:
дата размещения;
статус версии;
возрастная категория;
кодировки МКБ-10;
разработчик;
связи между старой и новой редакцией.
Именно здесь начинается нормальная инженерная работа, потому что пользователю важно не просто открыть рекомендацию, а понимать, что она актуальна и не перепутана с предыдущей редакцией.
2. Нормализация: документ надо превратить в структуру
Большинство официальных документов создаются не для машинной навигации.
Для человека документ может быть “нормальным”.
Для поискового движка и интерфейса — нет.
Поэтому после загрузки у вас почти всегда появляется этап нормализации:
выделение метаданных;
разбиение на логические блоки;
извлечение заголовков и подзаголовков;
маркировка разделов вроде “диагностика”, “лечение”, “реабилитация”, “профилактика”;
связывание таблиц, схем и списков с окружающим контекстом;
извлечение возрастных пометок и МКБ-кодов.
И вот это, на мой взгляд, самый недооцененный слой в medtech-продуктах.
Если его не сделать, все остальное — просто красивая оболочка над сырым PDF.
3. Один индекс не справится: нужен гибридный поиск
Для такой доменной области я бы не делал ставку только на один тип поиска.
Нужно как минимум три режима.
Полнотекстовый поиск
Хорошо работает, когда пользователь знает термин и хочет быстро найти его в тексте.
Поиск по сущностям
Нужен для сценариев “МКБ-10 → КР”, “нозология → возрастная группа”, “дети/взрослые”, “диагностика/лечение”.
Семантический поиск
Полезен, когда пользователь спрашивает “человеческим языком”: не по официальному заголовку раздела, а по смыслу.
Особенно это важно в медицине, где один и тот же запрос может формулироваться очень по-разному:
“артериальная гипертензия”;
“гипертоническая болезнь”;
“повышенное давление”;
“целевые уровни АД”.
Для интерфейса это разные фразы.
Для клинического сценария — одна и та же задача.
4. Офлайн — это не nice-to-have, а часть базового UX
Во многих продуктах офлайн-режим считают “дополнительной функцией”. Для врачебного справочника это ошибка.
Если МКБ-10, калькуляторы, избранное и уже открытые материалы недоступны без сети, пользователь довольно быстро перестает считать инструмент рабочим.
С инженерной точки зрения офлайн здесь требует аккуратной декомпозиции:
что кэшируется полностью;
что кэшируется частично;
какие сущности можно хранить локально без риска рассинхронизации;
как валидировать устаревший кэш;
как вести себя, если пользователь открыл фрагмент из старой версии документа.
Самая частая UX-ошибка в таких системах — не отсутствие офлайна как такового, а непредсказуемость поведения. Когда один экран работает, второй нет, а третий “вроде бы грузится”, пользователь не понимает, можно ли доверять сервису.
5. Ссылки на источник важнее красивого ответа
В медицинских сервисах очень велик соблазн выдать “готовый ответ” и на этом остановиться.
Но если продукт работает с клиническими рекомендациями, лучшее, что он может сделать после ответа, — показать:
из какого документа взят фрагмент;
из какого раздела;
где это написано;
можно ли открыть оригинал для сверки.
Это полезно не только с клинической точки зрения, но и с инженерной.
Такой подход резко снижает недоверие к поиску и к AI‑слою: пользователь видит не «магический результат», а трассируемую цепочку от вопроса к источнику.
6. Тесты и НМО — это отдельный продуктовый слой, а не баннер сбоку
Очень большой пласт запросов связан с НМО:
«НМО клинические рекомендации»,
«тесты по клиническим рекомендациям»,
«тесты с ответами»,
«ответы по клиническим рекомендациям 2024».
И здесь, как мне кажется, разработчики часто недооценивают важную вещь: учебный сценарий должен жить не отдельно от базы знаний, а поверх нее.
То есть хороший слой тестов — это не просто набор вопросов. Это система, где вопрос можно привязать к:
конк��етной рекомендации;
конкретному разделу;
конкретному фрагменту;
пояснению, почему правильный ответ именно такой;
быстрому переходу к исходному месту в документе.
Именно это отличает “свалку ответов” от нормального учебного инструмента.
Почему сайт и приложение — это не дубль, а два разных интерфейса
В своем проекте я в итоге пришел к довольно простой мысли: сайт и мобильное приложение не должны пытаться быть одинаковыми.
Сайт удобнее для:
первого захода из поиска;
SEO-трафика по нозологиям и рубрикатору;
длинных сравнительных сценариев;
просмотра структуры и навигации.
Мобильное приложение удобнее для:
быстрых рабочих обращений;
офлайн-сценариев;
сохраненных материалов;
повседневного использования как карманного справочника.
Поэтому один и тот же контентовый слой можно отдавать в две поверхности с разным UX.
Если кому-то интересно посмотреть именно на реализацию такого подхода, я вынес это в два отдельных интерфейса:
Здесь для меня важнее не “скачивания”, а сам принцип: один доменный граф знаний может жить в нескольких клиентах, если вы заранее проектируете продукт не как набор экранов, а как систему доступа к сущностям.
Что я считаю ключевым выводом
Если смотреть на тему клинических рекомендаций глазами инженера, то главная проблема не в том, что данных мало. Наоборот, данных много.
Проблема в том, что между официальным источником и реальным пользовательским действием слишком большой разрыв.
Официальный рубрикатор клинических рекомендаций Минздрава РФ нужен и важен. Но врачу в конкретный момент времени чаще всего требуется не каталог документов как таковой, а очень короткий путь от вопроса к проверяемому фрагменту:
запрос → актуальная версия → нужный раздел → ссылка на источник → понятный интерфейс.
И вот именно это, на мой взгляд, и есть настоящая продуктовая задача.
Не “сделать еще один сайт про клинические рекомендации 2025/2026”.
Не “натянуть ИИ поверх PDF”.
Не “собрать трафик по НМО и тестам”.
А собрать слой, который:
уважает официальный источник;
понимает версии;
различает детей и взрослых;
умеет работать с МКБ-10;
показывает контекст, а не только ответ;
остается полезным даже без интернета.
Для меня это хороший пример того, как seemingly «не‑IT‑шная» область на самом деле упирается в очень классические инженерные задачи: парсинг, нормализацию, индексирование, версионирование, поиск, кэширование и объяснимый UX.
И именно поэтому тема клинических рекомендаций — это не только про медицину.
Это вполне нормальная, сложная и интересная задача для продуктового инженера.
