Современная медицинская информационная система (далее МИС) — это не статичный продукт, а живой, постоянно развивающийся организм. Ее первоначальное внедрение — лишь начало долгого пути. Постоянные изменения диктуются развитием медицинской науки, новыми требованиями регуляторов (Минздрав, ФОМС, Росздравнадзор), а также внутренними потребностями лечебного учреждения в повышении эффективности. Поскольку вносить изменения в код системы может только разработчик, критически важно выстроить с ним четкое и продуктивное взаимодействие.
Взаимодействие с разработчиком не сводится к схеме «сообщили — исправили». Это сложный, непрерывный процесс, требующий от медицинской организации продуманной стратегии и организационной дисциплины.
вверхПочему возникают запросы к разработчику? Эволюция потребностей
Запросы к разработчику — это не признак неудачной системы, а индикатор ее активного использования в живом клиническом и административном процессе.
Основные причины запросов:
- Исправление ошибок: Даже после успешного внедрения неизбежно выявляются программные баги и недоработки. Если некоторые функции используются редко, ошибки могут оставаться незамеченными годами.
- Адаптация к внешним изменениям: Новые приказы Минздрава, изменения в формах статистической отчетности, порядках оказания медицинской помощи, появление новых реестров (например, для высокотехнологичной помощи или в рамках ОМС) требуют оперативного обновления МИС.
- Развитие и оптимизация внутренних процессов: Медицинская организация растет, появляются новые услуги, методы диагностики и лечения. МИС должна гибко подстраиваться под эти изменения, чтобы оставаться эффективным инструментом, а не препятствием.
Работа с разработчиком не ограничивается «заплатками». Ее главная цель — содержательная поддержка системы, обеспечение ее соответствия актуальным клиническим и административным задачам.
вверхОрганизация процесса подачи запросов: создаем эффективный контур обратной связи
Стихийные устные просьбы «сделайте удобнее» неэффективны. Необходимо создать формализованный, удобный и обязательный для всех канал связи.
Ключевые элементы организации:
- Единый центр приема заявок: Назначьте ответственного (системного администратора, заместителя главного врача по ИТ), через которого будут проходить все запросы от пользователей. Это позволит избежать дублирования, провести первичный анализ и «отсеять» проблемы, решаемые силами внутренней ИТ-поддержки (например, сброс пароля).
- Специализированная система учета : Используйте для регистрации обращений специализированное ПО. Это может быть как модуль внутри самой МИС, так и внешняя система . Такая система позволяет:
- Присваивать заявке уникальный номер.
- Указывать приоритет (критический, высокий, средний, низкий).
- Классифицировать тип проблемы (ошибка, нововведение, вопрос).
- Назначать ответственного и отслеживать статус выполнения.
- Хранить всю историю коммуникаций.
- Обязательная формализация запроса: Любое обращение, даже устное, должно быть переведено в письменную форму с четким описанием.
Образец формы для регистрации запроса на доработку МИС
вверхЗАЯВКА № [номер присваивается системой]
на доработку/исправление в МИС1. Дата и время подачи: «25» марта 2025 г., 14:30
2. Автор заявки:
ФИО: Петрова Анна Игоревна
Должность: Врач-эндокринолог
Подразделение: Эндокринологическое отделение
Контактный телефон: [номер]3. Тип заявки:
[X] Исправление ошибки
[ ] Запрос на новую функцию
[ ] Доработка существующей функции
[ ] Вопрос по использованию4. Приоритет:
[ ] Критический (система не работает, невозможность оказания помощи)
[X] Высокий (существенное нарушение рабочего процесса)
[ ] Средний (неудобство, но работа возможна)
[ ] Низкий (пожелание по улучшению)5. Краткое описание проблемы/предложения:
*В справочнике МКБ-10 для кода E23.33 "Синдром пустого турецкого седла" отсутствует необходимая детализация. Невозможно формализованно указать сопутствующие проявления (ожирение, гиперпролактинемию и др.).*6. Детальное описание:
В настоящее время врач вынужден писать сопутствующие синдромы вручную в текстовом поле, что не позволяет в дальнейшем проводить выборку пациентов по этим признакам для анализа эффективности лечения. Требуется добавить в МИС подрубрики к коду E23.33 для детализации синдрома.7. Шаги для воспроизведения ошибки (если применимо):
- Открыть карту пациента.
- Перейти в раздел "Диагнозы".
- Попытаться установить диагноз E23.33 с уточнением синдрома.
- Система не предоставляет вариантов для уточнения.
8. Требуемый результат:
*Появится выпадающий список с вариантами: E23.330 - с ожирением, E23.331 - с гиперпролактинемией, ... E23.339 - смешанная форма. Выбранный вариант должен сохраняться в структурированном виде.*9. Приложения:
[X] Скриншот экрана (прилагается)
[ ] Ссылка на нормативный документ (Приказ Минздрава № XXX от...)
[ ] Другое (указать)Системный администратор ЛПУ:
Дата обработки: «25» марта 2025 г.
Заключение: Заявка обоснована. Передана разработчику для оценки и реализации.
_______________ /[ФИО администратора]/
Классификация запросов и правила их оформления
Разные типы проблем требуют разного подхода к описанию.
1. Критические ошибки: аварийные завершения и зависания
- Что делать: Немедленно уведомить системного администратора.
- Что указать в заявке:
- Точная последовательность действий, приведшая к сбою.
- Учетная запись пользователя.
- Данные, с которыми работали (например, ФИО пациента, номер карты).
- Скриншот ошибки (если возможно).
- Важно: В МИС должна быть встроена система логирования, которая автоматически записывает технические детали ошибки в журнал. Разработчику для анализа нужен доступ к этим логам или копия базы данных.
2. Логические ошибки и неверные расчеты
- Пример: Неправильный расчет среднего дневного заработка для больничного листа, неверное отображение данных в отчете.
- Что указать в заявке:
- Конкретный пример с исходными данными и ожидаемым результатом.
- Скриншоты, демонстрирующие ошибку.
- Ссылка на нормативный документ, алгоритм или методику расчета, которая нарушается.
3. Запросы на изменение и пополнение справочников
Справочники — это «мозг» МИС. Они делятся на:
- Локальные (сотрудники, подразделения): наполняются силами самой медорганизации.
- Системные (МКБ-10, лекарства, процедуры): требуют централизованной поддержки разработчиком для сохранения единого информационного пространства.
При запросе на добавление лекарства достаточно указать его международное непатентованное название (МНН) или торговое наименование. Разработчик обязан внести его в справочник, используя авторитетные источники (Государственный реестр лекарственных средств, справочник Видаль), с указанием всех лекарственных форм, дозировок и путей введения
Образец запроса на добавление процедуры в справочник
вверх
- Наименование: Трансуретральная резекция предстательной железы (полное название, без аббревиатур).
- Анатомическая область: Мочеполовая система.
- Тип: Операция.
- Категория: [ ] Малая операция [X] Большая операция [ ] Высокотехнологичная медицинская помощь (указать вид ВМП по Приказу Минздрава № XXXн).
- Код по номенклатуре медицинских услуг: [указать, если известно].
Новые функции и структурные изменения: стратегические запросы
Самые сложные запросы связаны с добавлением совершенно нового функционала.
Алгоритм действий:
- Обоснование: Четко сформулируйте, какую бизнес- или медицинскую проблему решит новая функция.
- Техническое задание (ТЗ): Разработайте максимально детализированное описание. Если это новый отчет — приложите его макет. Если это новый модуль — опишите пошаговые сценарии работы всех ролей (врач, медсестра, администратор).
- Оценка последствий: Поймите, потребуются ли структурные изменения в базе данных (добавление новых полей, таблиц). Например, введение нового поля «СНИЛС» повлечет за собой доработку форм ввода, отчетов и алгоритмов проверки.
Пользователи часто ставят задачу схематично, не осознавая всей сложности ее реализации. Чем детальнее и конкретнее будет ТЗ, тем быстрее и точнее разработчик выполнит работу, избежав многочисленных доработок
вверхОснования для отклонения запросов
Не все запросы пользователей являются обоснованными. Разработчик вправе отклонить запрос в следующих случаях:
- Несоблюдение установленной процедуры подачи (устные просьбы, неформализованные заявки).
- Конфликт с законодательством или внутренними регламентами.
- Нарушение архитектуры системы без веских причин.
- Следование устаревшим, неэффективным привычкам (например, просьба продублировать автоматически формируемые данные ручным вводом).
- Запрос функций, дублирующих уже существующие и более эффективные инструменты контроля и отчетности.