Оценка рисков системы

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

Оценка рисков\ компьютерной системы «n-tst.ru»

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

Версия: 1.0

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

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

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

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

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

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

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

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

Настоящая процедура устанавливает методологию выявления, оценки и минимизации рисков, связанных с использованием компьютеризированной системы «n-tst.ru». Оценка рисков является основой для определения глубины и объема тестирования при валидации системы, в соответствии с требованиями п. 5.5.3 Решения ЕЭК № 63 и методологией GAMP 5.

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

Процедура применима ко всем процессам, связанным с работой системы «n-tst.ru» в Production-среде, включая сбор первичных данных, ведение электронных форм, журналирование (Audit Trail), процессы резервного копирования и экспорта данных. Процедура обязательна для всех сотрудников, участвующих в управлении системой и обработке данных клинического исследования.

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

  2. Решение Совета Евразийской экономической комиссии № 63 от 01.08.2025 г. «О Правилах надлежащей клинической практики Евразийского экономического союза» (в частности, п. 5.5.3 и п. 5.5.4).

  3. ГОСТ Р 52379-2005 «Надлежащая клиническая практика».

  4. Федеральный закон РФ №61-ФЗ от 12.04.2010 г. «Об обращении лекарственных средств».

  5. ICH Guideline for Good Clinical Practice E6 (R2/R3).

  6. ISPE GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems (Second Edition).

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

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

Вероятность Оценка того, насколько часто может возникать сбой в работе системы (1 - Низкая, 2 - Средняя, 3 - Высокая). Серьезность Оценка степени влияния сбоя на безопасность субъекта исследования или достоверность данных (1 - Незначительное, 2 - Умеренное, 3 - Критическое). Уровень риска Произведение вероятности на серьезность (Риск = Вероятность × Серьезность). Audit Trail Документальный след, позволяющий проследить историю создания, изменения и удаления электронных записей. GAMP 5 Свод правил и методология валидации, основанная на оценке рисков. OQ / PQ Operational / Performance Qualification (Квалификация функционирования / эксплуатации).

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

<!-- -->
1. Владелец системы (Спонсор / Контрактно-исследовательская организация): Утверждает настоящую оценку рисков и обеспечивает выделение ресурсов на мероприятия по их минимизации.

  1. Специалист по качеству (QA): Проводит независимую проверку оценки рисков, контролирует выполнение планов по минимизации рисков (тестирование, SOP).

  2. Администратор системы: Реализует технические меры контроля (настройка прав доступа, резервное копирование, настройка валидаторов).

  3. Разработчик: Устраняет выявленные уязвимости и дефекты кода, влияющие на уровень риска.

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

6.1. Методология оценки рисков

Риски оцениваются по двум критериям: Вероятность (Probability) и Серьезность (Severity). Оценка проводится по трехбалльной шкале (от 1 до 3).

Уровень риска рассчитывается как произведение: Риск = Вероятность × Серьезность.

  • Высокий риск (6-9): Требуется обязательное тестирование (OQ/PQ) и строгие меры контроля.

  • Средний риск (3-5): Требуется тестирование, контроль достаточен.

  • Низкий риск (1-2): Достаточно визуального контроля.

6.2. Матрица рисков системы «ИРК»

№ Описание риска (Процесс/Функция) Вероятность Серьезность Уровень риска Меры минимизации (Контроли) Доказательства при валидации (OQ/PQ)

1 Несанкционированный доступ к данным. Доступ к картам пациентов или изменение данных задним числом. 2 3 Высокий (6) Разграничение ролей (RBAC), аутентификация по JWT-токенам, протокол SSL. Тест OQ: Проверка прав доступа для ролей Admin, Doctor, Supervisor. 2 Потеря данных при сбое сервера. Отказ жесткого диска или падение БД. 1 3 Средний (3) Ежедневное резервное копирование (Cron), использование надежной СУБД PostgreSQL. Тест PQ: Восстановление БД из бэкапа на тестовом стенде. 3 Ввод некорректных данных (Human Error). Ввод неверного роста/веса, неверный формат даты. 3 2 Высокий (6) Встроенная система валидации (JS-валидаторы, min/max, required), блокировка сохранения при ошибках. Тест OQ: Проверка срабатывания валидаторов (ввод букв в числовое поле). 4 Потеря Audit Trail (Журнала аудита). Невозможность доказать, кто и когда изменил данные. 1 3 Средний (3) Автоматическая запись действий пользователей в таблицу audit_log на уровне бэкенда. Тест OQ: Проверка записи в audit_log при создании/сохранении карты. 5 Ошибка при экспорте данных. Выгруженный файл CSV/Excel не соответствует данным в БД. 2 3 Высокий (6) Скрипт валидации validate_export.py, строгий фильтр is_complete = true, проверка кодировки BOM. Тест PQ: Выгрузка данных, запуск скрипта сверки БД и файла. 6 Сбой при изменении конфигурации. Изменение структуры визита ломает исторические данные пациентов. 2 3 Высокий (6) Версионирование визитов, логическое удаление блоков, сохранение default_definition. Тест OQ: Изменение структуры блока и проверка того, что старые данные не пропали. 7 Сбой отправки Email (Sendersy). Уведомления о SAE или сброс пароля не доходят до адресата. 2 2 Средний (4) Настройка SPF, DKIM, Return-Path; использование API Sendersy; логирование отправок в БД. Тест OQ: Отправка тестового письма и проверка лога в админке.

6.3. Управление рисками

Меры минимизации, указанные в Матрице рисков, должны быть проверены в ходе валидации (OQ/PQ) и задокументированы в Протоколах тестирования. Если в ходе эксплуатации системы выявляются новые риски, они вносятся в настоящий СОП, и для них разрабатываются новые меры контроля.

  1. ПЕРЕЧЕНЬ ПРИЛОЖЕНИЙ

Без приложений.