ВЫБОР МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА ИНФОРМАЦИОННОЙ СИСТЕМЫ МЕДИЦИНСКОГО УЧРЕЖДЕНИЯ И УПРАВЛЕНИЕ РИСКАМИ РАЗРАБОТКИ

АННОТАЦИЯ

В статье рассматривается проблема выбора модели жизненного цикла при разработке информационной системы медицинского учреждения. Проведён сравнительный анализ каскадной, итерационной и спиральной моделей с точки зрения их применимости к условиям медицинских организаций. Обоснован выбор итерационной модели как наиболее соответствующей специфике данной предметной области. Систематизированы риски жизненного цикла ИС медицинского учреждения - технические, организационные и правовые - и предложены меры по их снижению. Результаты исследования апробированы в ходе разработки прототипа информационной системы для автоматизации деятельности медицинской организации.

Ключевые слова: жизненный цикл информационной системы, модель жизненного цикла, итерационная разработка, риски ИС, медицинские информационные системы, автоматизация здравоохранения, 1С:Предприятие.

Введение

Разработка информационной системы для медицинского учреждения - задача, где цена ошибки выше, чем в большинстве других прикладных областей. Сбой в учёте медикаментов, потеря данных пациента или ошибка в логике формирования медицинских документов - всё это напрямую влияет на качество лечения. Поэтому вопрос управления жизненным циклом такой системы нельзя решать по остаточному принципу: он должен быть проработан ещё до начала разработки.

На практике выбор модели жизненного цикла нередко происходит интуитивно - просто берут то, с чем уже работали, или то, что рекомендовано в методических материалах. Между тем разные модели дают принципиально разные результаты в зависимости от контекста: размера организации, стабильности требований, квалификации команды, регуляторных ограничений. Применительно к медицинским ИС этот выбор особенно важен, поскольку требования к системе нередко уточняются в процессе работы, а нормативная среда - законодательство о персональных данных, приказы Минздрава - может меняться.

В настоящей статье рассмотрены три основные модели жизненного цикла, проведён их сравнительный анализ применительно к условиям медицинских организаций и обоснован выбор итерационной модели для разработки конкретной системы. Отдельный раздел посвящён систематизации рисков и мерам по их снижению.

1. Модели жизненного цикла ИС: сравнительный анализ

Под жизненным циклом информационной системы понимается совокупность этапов от возникновения потребности в системе до её вывода из эксплуатации. В зависимости от того, как организована последовательность и взаимосвязь этих этапов, выделяют различные модели жизненного цикла. Наиболее распространёнными в практике разработки прикладных систем являются каскадная, итерационная и спиральная модели [1].

Каскадная модель (Waterfall) предполагает строгую последовательность этапов: анализ требований, проектирование, разработка, тестирование, внедрение, сопровождение. Переход на следующий этап происходит только после полного завершения предыдущего. Преимущество этой модели - простота планирования и чёткость контрольных точек. Недостаток, критичный для медицинских систем, - жёсткость: если требования уточняются в процессе разработки (а в медицине это правило, а не исключение), возвращение к предыдущему этапу становится дорогостоящим. Исследования показывают, что в проектах с нестабильными требованиями каскадная модель приводит к тому, что до 40% разработанного функционала либо не используется, либо требует переработки [2].

Спиральная модель (Boehm, 1988) строится как повторяющиеся циклы, каждый из которых включает планирование, анализ рисков, разработку и оценку результата. Главное достоинство - постоянное внимание к рискам на каждом витке спирали. Это делает модель привлекательной для сложных и дорогостоящих проектов. Однако для средних и небольших медицинских организаций спиральная модель избыточна: она требует высокой зрелости процессов управления и значительных затрат на организацию каждого цикла [3].

Итерационная модель разбивает разработку на короткие итерации (обычно 2–4 недели), каждая из которых завершается рабочей версией системы с нарастающим набором функций. Требования могут уточняться между итерациями, что делает модель гибкой. При этом она не требует той степени управленческой зрелости, которая нужна для спиральной. Именно это сочетание гибкости и доступности обусловило широкое распространение итерационных подходов в разработке прикладных систем [4].

Сравнительная характеристика трёх моделей применительно к условиям медицинских организаций представлена в таблице 1.

Таблица 1

Сравнение моделей жизненного цикла ИС применительно к медицинским организациям

2. Обоснование выбора итерационной модели для ИС медицинского учреждения

На основании проведённого анализа для разработки информационной системы медицинского учреждения была выбрана итерационная модель жизненного цикла. Это решение обусловлено рядом факторов, характерных для данной предметной области.

Во-первых, нестабильность требований. В медицинских организациях требования к ИС формируются постепенно: в начале проекта врачи и администраторы нередко не могут точно сформулировать, что именно им нужно от системы - это становится понятным только в процессе работы с прототипом. Итерационная модель позволяет принимать уточнения между итерациями без необходимости пересматривать всю архитектуру.

Во-вторых, возможность поэтапного запуска. Медицинское учреждение не может позволить себе ситуацию, когда старая система уже не работает, а новая ещё не готова. Итерационная разработка позволяет запустить базовый функционал - например, регистрацию пациентов и ведение карт - и постепенно добавлять остальные модули: управление расписанием, учёт медикаментов, аналитику.

В-третьих, управляемость для небольших команд. Разработка ИС медицинского учреждения в условиях малой клиники, как правило, ведётся небольшой командой, нередко без выделенного менеджера проекта. Итерационная модель не требует сложной инфраструктуры управления, характерной для спиральной, и при этом даёт достаточно гибкости, которой лишена каскадная.

Наконец, соответствие практике разработки на платформе «1С:Предприятие». Конфигурации «1С» традиционно разрабатываются итерационно: сначала реализуются базовые объекты метаданных, затем наращивается функциональность. Интеграция внешних компонентов - в данном случае Python-сервиса аналитического модуля - также удобнее выполняется поэтапно, с тестированием каждого шага интеграции.

3. Риски жизненного цикла ИС медицинского учреждения

Выбор модели жизненного цикла неотделим от анализа рисков: именно риски нередко определяют, какая модель подходит для конкретного проекта, и задают приоритеты при планировании работ. Применительно к ИС медицинского учреждения можно выделить три группы рисков.

Технические риски. Основной риск этой группы - несовместимость компонентов системы. В разрабатываемой ИС используются три технологически разнородных компонента: платформа «1С:Предприятие 8.3», Python-сервис аналитического модуля и база данных PostgreSQL. Взаимодействие между «1С» и Python-сервисом реализовано через файловый обмен - нестандартное, но работоспособное решение, позволяющее избежать необходимости открывать дополнительные сетевые порты в условиях жёстких политик безопасности медицинских учреждений. Тем не менее при масштабировании системы этот механизм потребует замены на защищённый внутренний API.

Второй технический риск - производительность под нагрузкой. Медицинская карта пациента может содержать записи за несколько лет от разных специалистов; при одновременной работе нескольких врачей с системой время отклика аналитического модуля может стать критичным. По результатам тестирования прототипа на наборе карт средней сложности время анализа составило 15–20 секунд, что приемлемо для текущего этапа, но требует оптимизации при промышленном внедрении.

Организационные риски. Главный организационный риск - сопротивление персонала при переходе на новую систему. Медицинские работники, как правило, имеют устойчивые рабочие привычки и воспринимают автоматизацию как дополнительную нагрузку, а не как облегчение. Это стандартная проблема при внедрении любой ИС в организациях с большой долей ручного труда [5]. Мера снижения - поэтапное внедрение с обучением персонала на каждом шаге и сохранение привычных интерфейсных элементов там, где это возможно.

Второй организационный риск - неполнота исходных требований. В начале проекта медицинский персонал нередко не может точно сформулировать, что именно должна делать система. Итерационная модель частично снимает эту проблему: каждая итерация уточняет требования на основе реальной работы с системой. Дополнительная мера - проведение структурированных интервью с представителями разных групп пользователей (регистраторы, врачи, администраторы) до начала разработки.

Правовые риски. Медицинские данные относятся к специальным категориям персональных данных в соответствии с Федеральным законом № 152-ФЗ «О персональных данных». Это накладывает ряд обязательных требований: необходимость получения явного согласия пациента на обработку данных, разграничение прав доступа, шифрование данных при хранении и передаче, ведение журнала операций с персональными данными. Несоответствие этим требованиям влечёт административную и, в отдельных случаях, уголовную ответственность [6].

В текущей архитектуре прототипа правовые риски частично не закрыты: файловый обмен между компонентами не обеспечивает достаточного уровня защиты персональных данных для промышленной эксплуатации. Приведение системы в соответствие с требованиями 152-ФЗ является обязательным условием перед реальным внедрением.

4. Меры по снижению рисков

На основании выявленных рисков сформирован комплекс мер по их снижению, структурированный по этапам жизненного цикла:

• Этап анализа требований: структурированные интервью с пользователями всех категорий, прототипирование ключевых экранов для уточнения ожиданий, формирование технического задания в соответствии с ГОСТ 34.602-89.
• Этап проектирования: выбор архитектуры с чётким разделением компонентов, что позволяет заменять их независимо; проектирование с учётом требований 152-ФЗ на уровне модели данных (шифрование, разграничение доступа, аудит операций).
• Этап разработки: покрытие критических функций автоматизированными тестами; поэтапная интеграция компонентов с тестированием каждого шага; документирование принятых архитектурных решений.
• Этап внедрения: поэтапный ввод в эксплуатацию по модулям; параллельная работа старой и новой систем на переходный период; обязательное обучение пользователей.
• Этап сопровождения: регулярное резервное копирование данных; мониторинг производительности; план реагирования на инциденты информационной безопасности.

Заключение

Выбор модели жизненного цикла - это не технический формализм, а управленческое решение, которое определяет, насколько гибко команда сможет реагировать на изменения и насколько предсказуемым будет результат. Для ИС медицинского учреждения итерационная модель оказывается оптимальным выбором: она допускает уточнение требований в процессе разработки, позволяет вводить систему в эксплуатацию поэтапно и не требует избыточной управленческой инфраструктуры.

Анализ рисков показал, что наиболее критичными для данного класса систем являются правовые риски, связанные с требованиями 152-ФЗ, и организационные риски, обусловленные сопротивлением персонала. Предложенный комплекс мер по снижению рисков может быть использован как практическое руководство при разработке аналогичных систем для медицинских организаций.

Результаты, представленные в статье, получены в ходе разработки прототипа информационной системы медицинского учреждения на платформе «1С:Предприятие 8.3» с аналитическим модулем на Python. Дальнейшее развитие работы предполагает приведение архитектуры в соответствие с требованиями 152-ФЗ и проведение пилотного внедрения системы в реальных условиях.

Список литературы:

1. Зараменских Е.П. Управление жизненным циклом информационных систем. - М.: Инфра-М, 2020. - 236 с.
2. Standish Group. CHAOS Report 2020: Beyond Infinity. - Boston: Standish Group International, 2020. - 54 p.
3. Boehm B.W. A Spiral Model of Software Development and Enhancement // IEEE Computer. - 1988. - Vol. 21. - № 5. - P. 61–72.
4. Larman C. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. - 3rd ed. - Upper Saddle River: Prentice Hall, 2004. - 703 p.
5. Lapointe L., Rivard S. A Triple Risk Model for Information System Implementation // MIS Quarterly. - 2005. - Vol. 29. - № 2. - P. 199–232.
6. Федеральный закон от 27 июля 2006 г. № 152-ФЗ «О персональных данных». - М.: Собрание законодательства Российской Федерации, 2006. - Ст. 3970.