Успешный пилот показывает, что технология может работать в ограниченных условиях. Готовность к внедрению означает больше: технология должна стабильно приносить пользу, оставаться безопасной при реальной нагрузке и быть управляемой как часть обычного клинического процесса.
Пилотирование — полезный способ проверить медицинскую технологию до масштабного внедрения. Оно позволяет увидеть, как решение работает на реальных данных, взаимодействует с персоналом, влияет на маршрут пациента и интегрируется с инфраструктурой медицинской организации.
Но положительный пилот сам по себе не означает, что технологию можно сразу переводить в постоянную эксплуатацию. Пилот часто проводится в лучших условиях: ограниченная выборка, мотивированная команда, повышенное внимание поставщика, ручная поддержка интеграций и небольшой поток пациентов. После масштабирования эти условия меняются.
Ключевой принцип: вопрос после пилота должен звучать не «работает ли технология?», а «готовы ли технология и организация стабильно, безопасно и воспроизводимо получать заявленную пользу в обычной клинической практике?».
Важно различать пилот и клинические испытания
Локальный пилот медицинской организации не заменяет государственную регистрацию медицинского изделия, обязательные технические, токсикологические или клинические испытания и иные предусмотренные законодательством процедуры оценки соответствия. Применение медицинского изделия в обычной практике должно соответствовать его зарегистрированному назначению, модели, версии и условиям эксплуатации.
Если для продукта требуется государственная регистрация как медицинского изделия, наличие успешного локального пилота не создает самостоятельного права на его клиническое применение вне установленного регуляторного режима.
Короткий ответ
| Область | Что означает готовность | Признак для решения |
|---|---|---|
| Регуляторная готовность | Продукт может использоваться в планируемом сценарии; статус, назначение, модель/версия и условия применения проверены. | Нет регуляторных ограничений, которые противоречат фактическому сценарию внедрения. |
| Клиническая эффективность | Пилот подтвердил заранее определенные клинически значимые показатели. | Результат не сводится к технической метрике и воспроизводим в целевой группе. |
| Безопасность | Риски известны, контролируются и приемлемы; предусмотрены действия при отказе и ошибке. | Есть безопасный резервный процесс и понятная ответственность. |
| Практическая ценность | Технология улучшает реальный рабочий процесс, а не только отдельный технический этап. | Измеримы время, нагрузка, качество, маршрутизация или иная польза. |
| Организационная готовность | Есть владельцы процесса, обученный персонал, регламенты и поддержка. | Внедрение не держится на одном энтузиасте или постоянном присутствии поставщика. |
| Техническая устойчивость | Интеграции, инфраструктура и производительность выдерживают реальную нагрузку. | Определены SLA, резервирование, обновления и обработка инцидентов. |
| Экономическая обоснованность | Понятна полная стоимость владения и ожидаемый эффект. | Решение остается оправданным при масштабировании. |
| Мониторинг после запуска | Определены показатели качества и безопасности, которые контролируются после внедрения. | Есть критерии эскалации, приостановки и повторной оценки. |
1. До пилота определить критерии успеха
Оценить пилот невозможно, если заранее не определено, что будет считаться успехом. Формулировка «посмотрим, как работает» почти гарантирует субъективный вывод: после завершения проекта каждая сторона сможет выбрать удобные для себя результаты.
До старта пилота следует зафиксировать исходный процесс, целевые показатели, способ их измерения, период наблюдения и пороги, при которых технология считается готовой к следующему этапу.
| Группа KPI | Что измерять |
|---|---|
| Клинический результат | Диагностическая точность, полнота выявления, изменение результата лечения или другой клинически значимый показатель. |
| Время процесса | Полный цикл от поступления исследования/пациента до результата, а не только время работы устройства или алгоритма. |
| Нагрузка | Изменение трудозатрат врачей, среднего персонала, ИТ и администраторов. |
| Качество процесса | Ошибки, повторные исследования, пропуски, вариабельность, доля ручных корректировок. |
| Безопасность | Нежелательные события, критические ошибки, отказы, ситуации потенциального вреда. |
| Техническая стабильность | Доступность, время отклика, количество сбоев, доля необработанных случаев. |
| Пользовательская приемлемость | Время обучения, ошибки применения, необходимость обходных сценариев, обратная связь пользователей. |
| Экономика | Стоимость на один случай, затраты на интеграцию и поддержку, ресурсы для масштабирования. |
2. Проверить, действительно ли пилот репрезентативен
Главный риск пилота — получить хороший результат в условиях, которые не похожи на обычную работу. Поэтому после завершения проекта необходимо оценить не только итоговые цифры, но и условия, в которых они были получены.
- достаточен ли объем случаев и период наблюдения;
- представлены ли типичные и сложные пациенты, а не только удобные случаи;
- соответствует ли нагрузка будущему промышленному режиму;
- участвовали ли обычные пользователи, а не только наиболее мотивированные специалисты;
- работали ли штатные интеграции, а не временные ручные схемы;
- были ли ночные смены, выходные, пики нагрузки и реальные сбои;
- насколько активно поставщик вручную поддерживал процесс во время пилота;
- совпадает ли протестированная версия с той, которая будет внедряться.
3. Разделить «технология работает» и «технология приносит пользу»
Техническая работоспособность отвечает на вопрос, выполняет ли продукт заявленную функцию. Клиническая и практическая ценность отвечает на другой вопрос: приводит ли эта функция к улучшению результата или процесса.
Например, алгоритм может корректно обрабатывать 99% исследований, но не сокращать время работы врача из-за большого количества ложных срабатываний. Оборудование может давать точные измерения, но создавать дополнительный этап, который увеличивает общую длительность маршрута пациента.
| Уровень | Что показывает | Значение для внедрения |
|---|---|---|
| Технический результат | Система сформировала результат, измерение или рекомендацию. | Не достаточен сам по себе. |
| Клинический результат | Результат корректен и имеет значение для диагностики, лечения или мониторинга. | Ключевой для медицинской ценности. |
| Процессный результат | Сокращено время, снижена нагрузка, улучшена маршрутизация или качество процесса. | Показывает практическую пользу для организации. |
| Системный результат | Эффект сохраняется при масштабировании и не создает неприемлемых побочных последствий. | Необходим для решения о полном внедрении. |
4. Провести проверку безопасности после пилота
Менеджмент риска не заканчивается до пилота. Реальное применение часто выявляет опасности, которые не были очевидны на этапе проектирования: нестандартные действия пользователей, неожиданные комбинации входных данных, сбои интеграций, неочевидные сообщения интерфейса или зависимость процесса от внешнего сервиса.
ГОСТ ISO 14971-2021 предусматривает управление рисками и мониторинг результативности мер контроля на протяжении жизненного цикла медицинского изделия. Поэтому результаты пилота следует использовать для актуализации локальной оценки рисков и организационных мер контроля.
| Риск после пилота | Контрольный вопрос |
|---|---|
| Отказ оборудования/ПО | Есть ли безопасный резервный процесс и понятный порядок переключения? |
| Ошибочный результат | Кто обнаруживает ошибку и какое клиническое последствие возможно? |
| Потеря данных/интеграции | Можно ли восстановить данные; как пользователь узнает, что обмен не состоялся? |
| Ошибка пользователя | Какие действия чаще всего вызывают ошибки и можно ли снизить риск обучением или изменением процесса? |
| Зависимость от поставщика | Сможет ли организация работать при недоступности поддержки или внешнего сервиса? |
| Обновление версии | Кто оценивает изменения и принимает решение о допуске новой версии? |
5. Оценить человеческий фактор и реальную эксплуатационную пригодность
Пилот — удобный момент проверить, насколько интерфейс и процесс соответствуют реальным пользователям. ГОСТ Р МЭК 62366-1-2023 связывает эксплуатационную пригодность медицинского изделия с безопасностью и рисками ошибок применения.
Важно оценивать не только удовлетворенность пользователей, но и наблюдаемое поведение: сколько действий требуется, где возникают ошибки, какие предупреждения игнорируются, появляются ли обходные сценарии и насколько быстро новый сотрудник способен освоить работу.
- понятно ли пользователю назначение и ограничения технологии;
- видны ли сбои и неопределенные результаты;
- понятна ли ответственность за окончательное решение;
- не возникает ли чрезмерное доверие автоматическому результату;
- не увеличивается ли когнитивная нагрузка;
- можно ли выполнять процесс без постоянных подсказок разработчика или поставщика.
6. Проверить техническую готовность к промышленной эксплуатации
Пилот может работать на небольшой мощности и временной инфраструктуре. Перед внедрением нужно подтвердить, что архитектура выдержит штатный поток, а техническая поддержка станет частью управляемого процесса.
| Область | Что проверить перед запуском |
|---|---|
| Производительность | Выдерживает ли система пиковый поток без неприемлемых задержек? |
| Доступность | Какой допустимый простой и как он измеряется? |
| Интеграции | Устойчивы ли обмены с МИС, ЛИС, РИС/PACS и другими системами? |
| Журналирование | Можно ли восстановить цепочку событий при инциденте? |
| Резервирование | Есть ли резервные компоненты, каналы и процедуры восстановления? |
| Обновления | Есть ли управляемый процесс тестирования и ввода новых версий? |
| Поддержка | Определены ли SLA, контакты, уровни эскалации и сроки реакции? |
| Информационная безопасность | Выполнены ли применимые требования к доступу, защите данных и эксплуатации инфраструктуры? |
7. Определить владельца технологии и процесса
Одна из причин неудачного масштабирования — пилот держится на конкретном инициаторе. После перехода в эксплуатацию вопросы начинают «падать между» врачами, ИТ, инженерами, службой качества, закупками и поставщиком.
До внедрения необходимо определить как минимум:
- владельца клинического процесса;
- ответственного за эксплуатацию технологии;
- ответственного за техническую поддержку и интеграции;
- ответственного за обучение пользователей;
- порядок регистрации и разбора инцидентов;
- кто имеет право приостановить использование при риске безопасности;
- кто согласовывает обновления и изменения конфигурации.
8. Перевести пилотные договоренности в регламенты
Во время пилота многие действия выполняются по договоренности: «если не сработало — позвонить разработчику», «сложный случай проверить вручную», «ночью систему не использовать». Для промышленной эксплуатации такие правила должны быть формализованы.
| Документ/процесс | Что зафиксировать |
|---|---|
| СОП/рабочая инструкция | Пошаговый процесс штатной работы и действия при отклонениях. |
| Роли и ответственность | Кто выполняет, проверяет, принимает решение и эскалирует проблему. |
| Инструкция по отказу | Резервный маршрут при недоступности технологии. |
| Обучение | Минимальные знания, допуск к работе, периодическое переобучение. |
| Управление изменениями | Как вводятся новые версии, настройки, интерфейсы и оборудование. |
| Инциденты | Как регистрируются ошибки, жалобы, нежелательные события и технические сбои. |
| Мониторинг | Какие показатели отслеживаются регулярно и кто их анализирует. |
9. Пересчитать экономику после реального пилота
До пилота экономика обычно строится на предположениях. После пилота появляются реальные данные: время сотрудников, стоимость интеграций, количество ручных операций, расходные материалы, требования к вычислительным ресурсам, нагрузка на поддержку и фактический объем использования.
Перед масштабированием финансовую модель нужно пересчитать. Особенно важно учитывать полную стоимость владения, а не только цену лицензии или оборудования.
- закупка или подписка;
- интеграция и доработка;
- серверные и облачные ресурсы;
- техническая поддержка и сервис;
- обновления и сопровождение;
- обучение персонала;
- расходные материалы;
- время сотрудников;
- стоимость простоя и резервного процесса.
10. Для ПО и ИИ проверить жизненный цикл версии
Для программного медицинского изделия результат пилота относится к конкретной версии. После обновления может измениться интерфейс, алгоритм, формат входных данных, интеграция или производительность. Поэтому «мы уже протестировали систему» не должно автоматически переноситься на любую следующую версию.
ГОСТ IEC 62304-2022 устанавливает процессы жизненного цикла программного обеспечения медицинских изделий. Для систем ИИ дополнительно важны контроль наборов данных, версий модели и повторная оценка характеристик после изменений.
| Для ПО/ИИ | Что должно быть обеспечено |
|---|---|
| Версия | Зафиксированы версия ПО, модель/алгоритм и значимые настройки. |
| Данные | Понятно, на каких данных подтверждены характеристики и насколько они соответствуют локальному потоку. |
| Смещение | Проверены подгруппы пациентов, оборудование и нетипичные случаи. |
| Мониторинг качества | После внедрения отслеживаются клинические и технические метрики. |
| Обновление | Есть критерии, когда новая версия требует повторного пилота или дополнительной валидации. |
| Откат | Можно безопасно вернуться к предыдущей версии или резервному процессу. |
11. Не масштабировать до определения поствнедренческого мониторинга
Самая опасная ошибка — считать проект завершенным в день промышленного запуска. После внедрения меняется состав пользователей, поток пациентов, оборудование и версии ПО. Поэтому технология должна оставаться объектом наблюдения.
| Что мониторить | Контрольный вопрос |
|---|---|
| Клинические показатели | Сохраняется ли ожидаемая эффективность? |
| Ошибки и инциденты | Есть ли рост критических или повторяющихся ошибок? |
| Доступность | Сохраняются ли заявленные показатели работы системы? |
| Время процесса | Не исчезла ли ожидаемая экономия времени после масштабирования? |
| Пользовательские ошибки | Какие трудности появляются у новых пользователей? |
| Версии и изменения | Не изменились ли характеристики после обновления? |
| Подгруппы | Нет ли ухудшения результатов в отдельных группах пациентов или на отдельных площадках? |
12. Использовать «ворота решения», а не бинарное «успешно/неуспешно»
По итогам пилота полезно принимать решение не в двух, а как минимум в четырех вариантах. Это позволяет отделить перспективную технологию, требующую доработки, от полностью готового решения.
| Решение | Когда применять | Следующий шаг |
|---|---|---|
| НЕ ГОТОВО | Есть критические проблемы безопасности, регуляторные ограничения или отсутствуют доказательства пользы. | Не внедрять; устранить основания или прекратить проект. |
| ГОТОВО К ДОРАБОТКЕ | Основная ценность подтверждена, но есть устранимые технические/организационные проблемы. | Сформировать план корректирующих действий и повторную проверку. |
| ГОТОВО К ОГРАНИЧЕННОМУ ВНЕДРЕНИЮ | Показатели приемлемы, но требуется наблюдение на ограниченной площадке или группе пользователей. | Ввести контролируемую эксплуатацию с усиленным мониторингом. |
| ГОТОВО К МАСШТАБИРОВАНИЮ | Польза, безопасность, устойчивость, ресурсы и управление подтверждены. | Переходить к плановому распространению с регулярным мониторингом. |
13. Красные флаги: когда успешный пилот не должен вести к внедрению
- критерии успеха определили после получения результатов;
- пилот проводился только на специально отобранных «простых» случаях;
- нельзя понять, сколько ручной работы выполнял поставщик за кадром;
- нет данных об ошибках, потому что регистрировались только успешные случаи;
- пилотная версия отличается от версии для промышленной эксплуатации;
- назначение медицинского изделия не покрывает планируемый сценарий использования;
- критические сбои не имеют безопасного резервного процесса;
- экономический эффект рассчитан без расходов на интеграцию, поддержку и персонал;
- внедрение зависит от одного сотрудника или постоянного присутствия поставщика;
- не определено, что делать при ухудшении показателей после запуска.
14. Практический алгоритм перехода от пилота к внедрению
1. Сверить фактически протестированный продукт с регуляторными документами, моделью и версией.
2. Сопоставить результаты с критериями успеха, утвержденными до пилота.
3. Проверить репрезентативность случаев, пользователей, нагрузки и инфраструктуры.
4. Отдельно оценить клинический эффект и практическую ценность.
5. Разобрать все ошибки, отказы, ручные корректировки и потенциально опасные ситуации.
6. Провести анализ человеческого фактора и пользовательских ошибок.
7. Проверить готовность технической инфраструктуры и интеграций к промышленной нагрузке.
8. Определить владельцев клинического и технического процессов.
9. Формализовать резервный процесс, поддержку, инциденты и управление изменениями.
10. Пересчитать полную стоимость владения на фактических данных пилота.
11. Для ПО/ИИ зафиксировать версию и правила обновлений/повторной оценки.
12. Определить KPI поствнедренческого мониторинга и пороги эскалации.
13. Принять одно из решений: не готово / доработка / ограниченное внедрение / масштабирование.
14. Зафиксировать решение, основания и ответственных.
15. После запуска провести контрольную оценку через заранее установленный период.
15. Итоговый чек-лист готовности к внедрению
| Контрольный вопрос | Отметка |
|---|---|
| Регуляторный статус и назначение соответствуют сценарию эксплуатации | ☐ |
| Фактически внедряемая модель/версия совпадает с оцененной | ☐ |
| Критерии успеха пилота были определены заранее | ☐ |
| Пилотная выборка и нагрузка достаточно репрезентативны | ☐ |
| Клиническая эффективность подтверждена | ☐ |
| Практическая ценность для процесса подтверждена | ☐ |
| Все значимые ошибки и инциденты разобраны | ☐ |
| Остаточные риски признаны приемлемыми | ☐ |
| Есть безопасный резервный процесс | ☐ |
| Пользователи обучены; ошибки применения изучены | ☐ |
| Инфраструктура выдерживает промышленную нагрузку | ☐ |
| Интеграции протестированы в штатном режиме | ☐ |
| Определены владельцы процесса и ответственности | ☐ |
| Установлены SLA и порядок технической поддержки | ☐ |
| Установлен процесс управления версиями и изменениями | ☐ |
| Полная стоимость владения пересчитана по фактическим данным | ☐ |
| Определены KPI мониторинга после запуска | ☐ |
| Определены пороги эскалации, приостановки и повторной оценки | ☐ |
| Решение о внедрении документировано | ☐ |
Рабочая матрица решения
| Критерий | Значимость | Результат | Комментарий / доказательство |
|---|---|---|---|
| Регуляторная готовность | Критично | Соответствует / не соответствует | |
| Клиническая эффективность | Критично | Подтверждена / требует данных | |
| Безопасность | Критично | Приемлемо / неприемлемо | |
| Практическая ценность | Высоко | Подтверждена / частично / нет | |
| Эксплуатационная пригодность | Высоко | Приемлема / требуется доработка | |
| Техническая устойчивость | Высоко | Готово / ограничено | |
| Организационная готовность | Высоко | Готово / требует мер | |
| Экономическая обоснованность | Средне/высоко | Положительно / неопределенно / отрицательно | |
| Поствнедренческий мониторинг | Критично | Определен / не определен |
Нормативная и методическая база
Постановление Правительства РФ от 30.11.2024 № 1684 «Об утверждении Правил государственной регистрации медицинских изделий»
Определяет действующие правила государственной регистрации медицинских изделий. На дату актуализации материала используется редакция от 03.08.2026. Для внедрения важно сверять фактический продукт, назначение и изменения регистрационного досье с действующим регуляторным статусом.
https://www.consultant.ru/document/cons_doc_LAW_491966/
Приказ Минздрава России от 13.05.2026 № 421н
Устанавливает порядок оценки соответствия медицинских изделий в форме технических испытаний, токсикологических исследований и клинических испытаний. Вступил в силу 01.09.2026 и действует до 01.09.2032.
https://www.consultant.ru/document/cons_doc_LAW_535595/
ГОСТ ISO 14971-2021 «Изделия медицинские. Применение менеджмента риска к медицинским изделиям»
Действующий стандарт по менеджменту риска медицинских изделий; процесс применяется на всех стадиях жизненного цикла и включает мониторинг результативности мер управления риском.
https://protect.gost.ru/gost/details/fc5f8123-88dd-4608-b1d0-aa23526a3b8e
ГОСТ Р МЭК 62366-1-2023 «Изделия медицинские. Часть 1. Проектирование медицинских изделий с учетом эксплуатационной пригодности»
Устанавливает требования к процессу эксплуатационной пригодности в части безопасности и ошибок применения; действует с 01.11.2023.
https://protect.gost.ru/gost/details/d32f0fdb-b380-4ae6-bb45-8d5c54c03cf5
ГОСТ IEC 62304-2022 «Изделия медицинские. Программное обеспечение. Процессы жизненного цикла»
Действующий стандарт по процессам жизненного цикла программного обеспечения медицинских изделий; применяется как методическая основа управления разработкой и изменениями ПО.
https://protect.gost.ru/gost/details/625bbecd-8dfb-4d77-8070-8ef64bc5bf08
ГОСТ Р 59921.5-2022 «Системы искусственного интеллекта в клинической медицине. Часть 5. Требования к структуре и порядку применения набора данных для обучения и тестирования алгоритмов»
Устанавливает требования к наборам данных, используемым при разработке, внутреннем и внешнем тестировании и эксплуатации систем ИИ.
https://protect.gost.ru/gost/details/df07a20c-d6dd-49e0-a91a-80799c5dc532
Всемирная организация здравоохранения. Health technology assessment of medical devices, 2nd ed. (2025)
ВОЗ рассматривает оценку медицинских технологий как многодисциплинарный процесс, охватывающий клинические, экономические, организационные, этические и социальные последствия. Этот подход полезен при принятии решений о внедрении.
Связанные материалы
Как оценить медицинскую технологию перед внедрением: эффективность, безопасность и практическая ценность
Базовая многокритериальная схема оценки до запуска пилота.
Искусственный интеллект в анализе медицинских изображений: возможности, ограничения и требования к доказательствам
Особенности доказательств, данных, валидации и рисков алгоритмов ИИ.
Качество, безопасность и эффективность медицинского изделия: в чем разница и что оценивает эксперт
Разбор трех ключевых категорий доказательств медицинского изделия.
Как провести экспертную оценку документации на медицинское изделие: пошаговый чек-лист
Практическая проверка согласованности документации и доказательств.
Практические документы и чек-листы
- Шаблон паспорта пилотного проекта медицинской технологии.
- Таблица KPI пилота: исходное значение → целевое значение → результат → вывод.
- Матрица «готовность к внедрению» с критическими и некритическими критериями.
- Реестр ошибок, инцидентов и потенциально опасных ситуаций пилота.
- Чек-лист технической и организационной готовности к промышленной эксплуатации.
- Форма решения по итогам пилота: не готово / доработка / ограниченное внедрение / масштабирование.
- План поствнедренческого мониторинга с порогами эскалации.
Актуальность материала
Дата актуализации: 10 сентября 2026 года.
Материал подготовлен с учетом действующей на дату актуализации редакции Правил государственной регистрации медицинских изделий, утвержденных постановлением Правительства РФ № 1684, приказа Минздрава России № 421н, а также действующих стандартов по менеджменту риска, эксплуатационной пригодности, жизненному циклу медицинского ПО и наборам данных систем ИИ.
Предложенная схема является методическим инструментом для предварительной оценки готовности медицинской технологии к внедрению в конкретной организации. Она не заменяет обязательные регуляторные процедуры, государственную регистрацию, клинические испытания, закупочные процедуры или локальные требования медицинской организации.
Версия материала: 1.0