Управление изменениями (Change Control)

СТАНДАРТНАЯ ОПЕРАЦИОННАЯ ПРОЦЕДУРА

Управление изменениями (Change Control)\ в компьютерной системе «n-tst.ru»

Номер СОП: СОП-КС-08

Версия: 1.0

Дата эффективности: 01.11.2026

Планируемая дата пересмотра СОП: 01.11.2028

           ФИО   Должность                                 Подпись   Дата

Утвердил Генеральный директор
Разработал Специалист по клиническим исследованиям

История изменений документа

Версия Дата эффективности Изменения Необходимость тренинга

СОП-КС-08, версия 1.0 01.11.2026 Первоначальный документ. Да

  1. НАЗНАЧЕНИЕ ПРОЦЕДУРЫ

Настоящая процедура устанавливает порядок запроса, оценки, одобрения, внедрения и документирования любых изменений, вносимых в компьютеризированную систему «n-tst.ru» после завершения её первичной валидации. Целью процедуры является сохранение системы в валидированном состоянии и предотвращение влияния неконтролируемых изменений на целостность данных и безопасность пациентов.

  1. ОБЛАСТЬ ПРИМЕНЕНИЯ

Процедура распространяется на любые изменения в Production-среде:

  • Изменения исходного кода (Backend, Frontend).

  • Изменения структуры базы данных (добавление/удаление столбцов, изменение таблиц).

  • Изменения конфигурации серверов (Nginx, Node.js, PostgreSQL).

  • Обновление версий программного обеспечения.

  • НОРМАТИВНО-ПРАВОВАЯ БАЗА

    • Решение Совета Евразийской экономической комиссии № 63 от 01.08.2025 г.

    • 21 CFR Part 11: Electronic Records; Electronic Signatures (США).

    • ISPE GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems..

  • ОПРЕДЕЛЕНИЯ И СОКРАЩЕНИЯ

Термин Определение

Change Request (CR) Запрос на изменение (форма в Приложении 1). Оценка влияния (Impact Assessment) Анализ того, как изменение повлияет на безопасность данных и работу системы. Регрессионное тестирование Повторное выполнение критических тест-кейсов (из OQ/PQ) для проверки того, что новое изменение не сломало старый функционал. Staging (Тестовый стенд) Среда, идентичная Production, но изолированная от реальных данных. Hotfix (Экстренное исправление) Внеплановое изменение для устранения критической ошибки (Severity 1).

  1. ОБЯЗАННОСТИ

<!-- -->
1. Заявитель (Владелец продукта / QA / Врач): инициирует Change Request (CR), описывая проблему или новую потребность.

  1. Разработчик: оценивает трудозатраты, вносит изменения в код, проводит тестирование на Staging-стенде.

  2. QA (Гарантия качества): проводит оценку влияния на валидированное состояние, утверждает план регрессионного тестирования, верифицирует результаты.

  3. Администратор системы: выкладывает изменения на Production (при наличии одобрения) и делает бэкап перед выкаткой.

<!-- -->
6. ОПИСАНИЕ ПРОЦЕДУРЫ

6.1. Классификация изменений

Все изменения делятся на три категории:

  1. Критические (Critical): Влияют на целостность данных, безопасность или электронные подписи. Требуют полной валидации (OQ/PQ) и утверждения Владельцем системы.

  2. Средние (Major): Изменения интерфейса, не влияющие на данные, но меняющие логику работы. Требуют регрессионного тестирования.

  3. Незначительные (Minor): Исправление опечаток, изменение цвета кнопки. Достаточно визуальной проверки QA.

6.2. Процесс внесения изменений (Workflow)

  1. Инициация: заявитель заполняет форму Change Request (CR) (Приложение 1) и передает её QA.

  2. Оценка влияния: QA и Разработчик совместно определяют уровень риска и категорию изменения (Critical/Major/Minor).

  3. Одобрение: если изменение критическое, CR утверждается Владельцем системы (Спонсором).

  4. Разработка и тестирование (Staging):

  5. Разработчик вносит изменения в код на тестовом стенде (Staging).

  6. QA проводит тестирование согласно плану (включая регрессионные тесты из СОП-КИ-97).

  7. Заполняется протокол тестирования (или баг-репорт, если найдены ошибки).

  8. Выкатка на Production:

  9. Администратор делает внеплановый бэкап (согласно СОП-КИ-93).

  10. Разработчик переносит проверенный код на Production.

  11. QA проводит финальный Smoke-тест (проверка доступности API /api/health и базовых функций).

  12. Закрытие CR: после успешной выкатки и проверки на Production, Change Request подписывается QA и подшивается в файл исследования (TMF).

    1. Экстренные изменения (Hotfix)

Если на Production обнаружена критическая ошибка (блокирующая работу), процедура может быть проведена в ускоренном режиме:

  1. Разработчик немедленно исправляет ошибку.

  2. QA проводит точечное тестирование конкретного исправления.

  3. Выкатка на Production происходит без длительного ожидания одобрения.

  4. Change Request оформляется «задним числом» (в течение 24 часов после выкатки) с указанием причины экстренности.

    1. Обновление документации

После выкатки критического или среднего изменения:

  1. Обновляется Матрица прослеживаемости (Traceability Matrix).

  2. При необходимости обновляются инструкции пользователя и СОПы.

  3. Изменяется номер версии системы (например, с v1.0 на v1.1).

<!-- -->
7. ПЕРЕЧЕНЬ ПРИЛОЖЕНИЙ

Приложение 1. Форма Запроса на изменение (Change Request).

Приложение 2. Журнал учета изменений (Change Log).

Приложение 1. Форма Запроса на изменение (Change Request).

Change Request № CR-2026-___\ Дата создания: «__» _________ 20__ г.\ Инициатор: _______________________

1. Описание изменения

  • Затрагиваемый модуль: [ ] Backend [ ] Frontend [ ] База данных [ ] Инфраструктура

  • Суть изменения: (Кратко опишите, что нужно сделать).

  • Причина изменения: [ ] Исправление бага (Bug Fix) [ ] Новое требование [ ] Оптимизация [ ] Безопасность

2. Оценка влияния (Заполняется QA)

  • Категория изменения: [ ] Критическое [ ] Среднее [ ] Незначительное

  • Влияет ли на электронные подписи (21 CFR Part 11): [ ] Да [ ] Нет

  • Влияет ли на целостность данных: [ ] Да [ ] Нет

  • Требуется ли перевалидация: [ ] Да [ ] Нет

3. План тестирования (Заполняется QA)

  • Перечень тест-кейсов для проверки (номера из OQ/PQ): _______________________

  • Необходимость регрессионного тестирования: [ ] Да [ ] Нет

4. Выполнение (Заполняется Разработчиком)

  • Дата выкатки на Staging: «___» _____ 20__ г.

  • Дата выкатки на Production: «__» _____ 20__ г.

  • Сделан ли бэкап перед выкаткой: [ ] Да

  • Новая версия системы: v______

5. Верификация и Закрытие (Заполняется QA)

  • Результаты тестирования на Staging: [ ] Успешно [ ] С ошибками

  • Результаты Smoke-теста на Production: [ ] Успешно [ ] С ошибками

  • Подпись QA: _____________ / _________________ / «___» _____ 20__ г.

**\ **

Приложение 2. Журнал учета изменений (Change Log)

(Сводная таблица всех CR, ведется QA)

№\ Дата Модуль Краткое описание Критичность Статус (Открыт/Закрыт) Версия системы CR