Эксплуатационные проверки и контроль устройств

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

Синхронизация времени и контроль часов\ в компьютерной системе «n-tst.ru»

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

Версия: 1.0

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

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

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

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

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

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

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

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

Настоящая Стандартная операционная процедура (СОП) устанавливает порядок проведения эксплуатационных проверок (валидации ввода данных) и контроля устройств (рабочих станций пользователей) при работе с компьютерной системой «n-tst.ru» (далее --- Система). Процедура обеспечивает защиту от ошибочного ввода, корректность работы программного обеспечения на устройствах пользователей и соответствие требованиям GCP и 21 CFR Part 11.

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

Процедура распространяется на:

Все формы ввода данных в Системе (визиты, дневники, НЯ, запросы).
Все устройства (ПК, ноутбуки, планшеты), с которых осуществляется доступ к Системе.
Веб-браузеры и сетевые компоненты, используемые для работы.
Процедуры периодического тестирования работоспособности (Smoke-тесты).
НОРМАТИВНО-ПРАВОВАЯ БАЗА
21 CFR Part 11: Electronic Records; Electronic Signatures (США), п. 11.10(f) (Эксплуатационные проверки), п. 11.10(h) (Контроль устройств).
ICH E6 (R2) Good Clinical Practice: Section 4.9, 5.5.
ISPE GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems.
ОПРЕДЕЛЕНИЯ И СОКРАЩЕНИЯ

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

Эксплуатационная проверка (Edit Check) Программная проверка данных, вводимых пользователем, на соответствие заданным правилам (формат, диапазон, обязательность). Контроль устройств (Device Check) Проверка того, что устройство и его программное обеспечение (ОС, браузер) соответствуют требованиям Системы и не создают угроз для целостности данных. Smoke-тест Быстрая проверка основных функций Системы после обновления или изменения конфигурации. Рабочая станция Компьютер или мобильное устройство, используемое для доступа к Системе.

ОБЯЗАННОСТИ
Пользователь --- использует только разрешенные устройства и браузеры, не отключает защитные механизмы (антивирусы, блокировщики скриптов), не использует общие учетные записи на одном устройстве.
Администратор Системы / IT --- настраивает серверные проверки (валидаторы), проводит периодические Smoke-тесты, контролирует журналы ошибок.
QA --- утверждает правила валидации в формах (совместно с разработкой), проверяет результаты Smoke-тестов, проводит периодический аудит изменений.
ОПИСАНИЕ ПРОЦЕДУРЫ

6.1. Эксплуатационные проверки на стороне сервера (Edit Checks)

Обязательные поля: При попытке сохранения визита, если критичное поле не заполнено, Система блокирует сохранение и выдает сообщение об ошибке.
Валидация диапазонов (Range Checks): Для числовых полей (АД, пульс, температура, рост, вес) заданы минимальные и максимальные значения. При вводе данных вне диапазона Система выдает предупреждение и требует подтверждения или исправления.
Проверка форматов (Regex): Для полей типа «Скрининговый номер», «Номер полиса» настроены регулярные выражения (маски ввода), не позволяющие ввести некорректные символы.
Логические проверки: Проверки, зависящие от других полей (например, если «Пол = Мужской», поле «Тест на беременность» блокируется и получает значение «Н.П.»).
Проверки при подписании: Система не позволяет подписать визит, если в нем есть открытые запросы (Queries) или незаполненные обязательные поля (если протокол требует 100% заполнения).
Дублирование проверок на клиенте (Frontend) и сервере (Backend): Основная валидация происходит на сервере. Клиентская валидация служит только для удобства (быстрая реакция), но не может быть обойдена.

6.2. Контроль устройств (Device Checks)

Требования к устройствам: Доступ к Системе разрешен только с устройств, имеющих современные браузеры (Яндекс, Chrome, Firefox, Edge, Safari) с поддержкой JavaScript и включенным TLS 1.2/1.3.
Запрет общих учетных записей: Каждый пользователь обязан иметь уникальный логин. Работа под одной учетной записью на нескольких устройствах одновременно запрещена (Система может отслеживать это по токенам/IP).
Синхронизация времени: Клиентские устройства не обязаны быть синхронизированы с точным временем, так как все критичные временные метки (подписи, аудит) формируются на сервере в UTC.
Безопасность устройства: Пользователи обязаны использовать антивирусную защиту и не устанавливать подозрительные расширения браузера (например, скрипты для автоматизации ввода), которые могут изменять данные в обход проверок.

6.3. Периодические проверки работоспособности (Smoke-тесты)

Перед каждым релизом (обновлением) на Production выполняется Smoke-тест на Staging согласно Чек-листу Smoke-теста (Приложение 1).
В ежедневном режиме Администратор проверяет эндпоинт /health. Если он не возвращает {status: \'ok\'}, это классифицируется как инцидент (СОП-КС-РП-10).
Раз в месяц QA проводит выборочный осмотр журналов (journalctl, логи Nginx) на предмет ошибок 500/502 и аномалий.

6.4. Действия при выявлении несоответствий

Если проверка на стороне сервера дает сбой (например, пропускает некорректные данные), Администратор немедленно сообщает разработчику.
Изменение правил валидации оформляется через Change Control (СОП-КС-ЭД-08).
Если устройство пользователя не соответствует требованиям (например, устаревший браузер), Пользователь обязан обновить ПО или перейти на разрешенное устройство.

<!-- -->

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

Приложение 1. Чек-лист Smoke-теста (после релиза/обновления).

Приложение 1. Чек-лист Smoke-теста (после релиза/обновления).

Дата проведения: «___» __________ 20 г.\ Версия Системы: ________________________\ Кто проводит (ФИО/Роль): ________________________

№ Проверяемая функция Ожидаемый результат Статус (ОК/Ошибка) Комментарий

1 Доступность API /health Возвращает JSON {status: \"ok\"}
2 Вход в систему (валидный логин/пароль) Успешный вход, выдача токена
3 Вход в систему (неверный пароль) Блокировка, запись в audit_log
4 Создание/сохранение тестового визита Данные сохранены без ошибок 500
5 Работа ИИ-Ассистента (проверка терапии) Выдача предупреждения (в Sandbox)
6 Работа валидаторов (ввод АД вне диапазона) Система выдает предупреждение
7 Подписание тестового визита Успешная подпись с фиксацией app_version
8 Отображение футера с версией Версия совпадает с релизной

Вывод: Система работоспособна__\ Выявлены дефекты (описать)__________________________________________.\ Подпись QA / Администратора: _______________ / ______________ / «___» ___ 20__ г.