Тестирование клинического видео: QA на надёжность и комплаенс

Это инженерные рекомендации, а не юридическая консультация. Детали подтверждайте у профильных юристов.

Кратко

В телемед-продукте проваленный тест – не косметический баг. Звонок, оборвавшийся посреди консультации, становится клиническим событием, а ошибка в обработке данных – инцидентом, о котором Роскомнадзор нужно уведомить за 24 часа. Поэтому контроль качества (QA – дисциплина, которая доказывает, что продукт работает, ещё до встречи с реальными пользователями) значит здесь гораздо больше, чем в потребительском приложении. У QA клинического видео две половины: тесты надёжности доказывают, что видео держится на плохих сетях и старых устройствах пациентов, а тесты комплаенса и безопасности – что меры защиты медданных делают то, чего требуют 152-ФЗ, 323-ФЗ и приказ 193н: вход через ЕСИА, подпись УКЭП, журнал событий, хранение в России, ни одного идентификатора пациента в логах. Это не добровольная инициатива: 152-ФЗ требует оценивать эффективность мер защиты до ввода системы в эксплуатацию (ст. 19 ч. 2), приказ ФСТЭК № 21 – повторять оценку не реже раза в три года, а неподписанный проект его замены добавляет переоценку после каждого инцидента. Ниже – полный план тестов к запуску, инструменты и порядок прогона, а в конце – план для QA-лида в PDF.

Зачем это читать

Запуск телемедицины чаще всего задерживает не недостающая функция, а запоздалое открытие: продукт тестировали только на хорошей офисной сети и новом телефоне. Эта статья – для основателя, продакт-менеджера или QA-лида, который должен ответить на вопрос «можно ли показывать это реальным пациентам и проверяющему?». Именно QA отделяет демо для инвесторов от продукта, который переживёт январский пик ОРВИ, пациента с мобильным интернетом в райцентре и регулятора, который просит доказать, что контроль доступа работает. Цена пропущенного теста вполне конкретна: оборванная консультация «врач – врач» по неотложному случаю – это инцидент безопасности пациента, а непроверенный журнал событий превращает мелкую ошибку в расследование утечки с уведомлением Роскомнадзора за 24 и 72 часа и штрафом 10–15 млн ₽ за утечку данных о здоровье.

Две половины QA клинического видео

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

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

Вторая половина – тесты комплаенса и безопасности. Можете ли вы доказать, что меры защиты медданных работают так, как требуют правила? Что контроль доступа действительно не пускает постороннего, в консультацию нельзя войти без ЕСИА, журнал событий фиксирует, кто открыл запись, а данные пациента не уходят туда, куда не должны, и не хранятся за рубежом? Эта половина решает, законен ли продукт, и у потребительских команд ей нет аналога.

Нажмите, чтобы увеличить

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

Тесты надёжности: продукт в реальных условиях

Тесты сетевых условий

Самый важный тест и одновременно самый пропускаемый – прогон видео в плохих сетевых условиях. Офисный Wi-Fi хороший, демо работает, команда идёт дальше. Но пациенты, которым телемедицина нужнее всего, – пожилые люди, жители малых городов и сёл, владельцы старых телефонов и дешёвых тарифов – как раз сидят на худших соединениях. Продукт, проверенный только на сильной сети, проверен не на той сети.

Сеть деградирует тремя измеримыми способами, и тестировать нужно все три. Потеря пакетов – доля пакетов данных, которые так и не доходят (2% потерь значит, что два из ста пропадают). Задержка – время прохода пакета в одну сторону, в миллисекундах. Джиттер – разброс этого времени: пакеты приходят неравномерными порциями, а не ровным потоком. Для интерактивного видео ориентир давно устоялся: международная рекомендация ITU-T G.114 считает одностороннюю задержку до 150 мс практически незаметной для пользователя, а 150–400 мс – приемлемой, но заметно ухудшающей разговор. План тестов должен подтвердить, что звонок остаётся пригодным, когда задержка подходит к 150 мс и к ней добавляются реалистичные потери.

Чтобы тестировать плохие сети, настоящие плохие сети не нужны – их моделируют. В Linux встроенный инструмент управления трафиком tc с модулем netem добавляет в соединение точную задержку, потери и джиттер, так что «4G в райцентре с 3% потерь и 200 мс задержки» воспроизводится по команде. Браузерную сторону берут на себя headless-браузеры под Playwright или Selenium: Chrome подставляет вместо камеры и микрофона тестовые файлы (флаги --use-fake-device-for-media-stream и --use-file-for-fake-video-capture), а джиттер, потери и битрейт снимаются вызовом WebRTC getStats(). (WebRTC – браузерный стандарт видео реального времени, на котором построено почти всё телемед-видео; протокол разобран в статье WebRTC: объяснение.) В облачные платформы тестирования WebRTC загружайте только синтетических пациентов.

Нажмите, чтобы увеличить

Цель – не идеальное видео на плохой сети: это невозможно. Цель – плавная деградация: по мере ухудшения связи продукт снижает качество видео, затем переходит на один звук, затем предупреждает пользователя и никогда не зависает молча и не падает. Какое качество клинически «достаточно хорошо», разобрано в отдельной статье задержка, качество и клиническая планка «достаточно хорошо».

Матрица устройств и браузеров

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

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

Облачные фермы реальных устройств позволяют небольшой QA-команде прогнать сценарий по этой сетке, не покупая пятьдесят телефонов (и снова – только на синтетических данных). Результат – не общее «работает», а зачёт или незачёт по каждой ячейке с описанием конкретного сбоя: баг с разрешением на камеру в одной старой версии Android никогда не всплывает в демо и всегда всплывает в продакшене.

Тесты переподключения

Во время реального приёма пациент не сидит на месте. Он переходит из комнаты с Wi-Fi в комнату без него, телефон сворачивает приложение ради входящего звонка, ноутбук на миг засыпает. Каждое такое событие рвёт соединение, и QA должен ответить: корректно ли переподключается продукт, возвращая пациента в ту же консультацию, или выбрасывает его на экран ошибки и повторный вход? Переподключение – полноценная функция, и тестируют его целенаправленно: обрывают сеть посреди звонка, переключают Wi-Fi на сотовую сеть, сворачивают приложение и проверяют, что сессия возобновилась.

Дело не только в удобстве. Переподключение и плавный откат обеспечивают доступность: сервис продолжает работать, даже когда что-то отказывает. 152-ФЗ требует защищать персональные данные не только от неправомерного доступа, но и от уничтожения и блокирования (ст. 19 ч. 1), а в приказе ФСТЭК № 21 доступности посвящена целая группа мер (ОДТ) – от отказоустойчивых средств до резервного копирования и восстановления. Продукт, который теряет консультацию и не умеет её восстановить, проваливает тест надёжности и заодно расходится с требованиями комплаенса. Механика переподключения разобрана в статье надёжность соединения и переподключение.

Нагрузочные и пиковые тесты

Спрос в телемедицине скачкообразный. Сезон ОРВИ, снегопад, отрезавший дорогу к поликлинике, тревожная новость об эпидемии – любое из этого за ночь кратно увеличивает число одновременных консультаций. Нагрузочный тест показывает, держится ли платформа при множестве одновременных звонков, пиковый тест – переживёт ли она внезапный всплеск намного выше нормы. Вы моделируете сотни или тысячи скриптовых звонков (теми же headless-браузерами или инструментами open-source медиасерверов, например командой нагрузочного теста в консольной утилите LiveKit) и ищете точку отказа: где звонок перестаёт устанавливаться по таймауту, где качество падает у всех сразу, где медиасерверам не хватает мощности.

Здесь надёжность пересекается с регулированием. Для консультаций «врач – врач» 193н задаёт сроки: экстренная – от 30 минут до 2 часов, неотложная – от 3 до 24 часов (п. 19), а за сроками консультаций, которые оплачивает ОМС, следят страховые медицинские организации (программа госгарантий, ПП 2188). Платформа, которая в пик не может установить звонок, срывает не только приём, но и норматив. Как спроектировать архитектуру, которая выдержит пик, разобрано в статье масштабирование клинического видео: регионы, мощности и пики.

Тесты комплаенса и безопасности: доказать, что меры работают

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

Правовое основание: оценка обязательна

152-ФЗ перечисляет, чем обеспечивается безопасность персональных данных, и два пункта этого списка напрямую касаются QA: оценка эффективности принимаемых мер до ввода информационной системы в эксплуатацию (ст. 19 ч. 2 п. 4) и контроль за принятыми мерами и уровнем защищённости (п. 9). Подзаконные акты задают периодичность: приказ ФСТЭК № 21 требует повторять оценку эффективности не реже раза в три года (п. 6), ПП 1119 – с той же периодичностью контролировать выполнение требований, самостоятельно или с привлечением лицензиата ФСТЭК (п. 17). В приказе № 21 есть группа мер «контроль (анализ) защищённости» (АНЗ): выявление уязвимостей с оперативным устранением, контроль обновлений, настроек и правильности работы ПО и средств защиты. При актуальных угрозах 1-го и 2-го типа приказ называет и тестирование системы на проникновение (п. 11).

Если вы обрабатываете данные по поручению клиники, у отчёта о тестах есть второй адресат: оператор вправе запросить у вас документы о соблюдении требований (ст. 6 ч. 3 152-ФЗ). Если заказчик – государственная клиника, к её МИС с 1 марта 2026 года применяется приказ ФСТЭК № 117.

Требования ужесточаются. В июле 2026 года ФСТЭК опубликовала проект замены приказа № 21: оценка до начала обработки, раз в три года и после каждого инцидента, показатель зрелости, меры для ИИ, контейнеров и API, требования к обработчикам. На конец сентября 2026 года проект не подписан, но направление понятно: стройте план QA так, будто новые требования уже действуют.

Нажмите, чтобы увеличить

Тесты контроля доступа

Первый тест комплаенса задаёт прямой вопрос: может ли посторонний увидеть данные чужого пациента? Контроль доступа – мера, при которой каждый видит только то, что позволяет его роль: пациент – свою карту, врач – своих пациентов, администратор – то, что он администрирует. 152-ФЗ требует установить правила доступа к персональным данным и регистрировать все действия с ними (ст. 19 ч. 2 п. 8); в приказе ФСТЭК № 21 этому соответствуют группы мер ИАФ (идентификация и аутентификация) и УПД (управление доступом). Контроль тестируют, пытаясь его сломать: войдите как пациент А и откройте записи пациента Б; попробуйте выполнить действие администратора с минимальными правами; подмените идентификатор в запросе. Задача QA – доказать, что контроль выдерживает намеренную атаку, а не только работает в позитивном сценарии. Проектирование этих мер разобрано в статье журналы аудита и контроль доступа для клинического видео.

Тесты идентификации: ЕСИА, ФРМР и УКЭП

Телемедицина добавляет к обычной аутентификации три обязательных элемента, и каждый тестируется как отдельная функция. Участники консультации идентифицируются через ЕСИА (ч. 6 ст. 36.2 323-ФЗ, п. 7 193н). Консультирующий врач должен быть внесён в ФРМР, организация – в ФРМО (п. 9 193н). Документация по консультации оформляется с усиленной квалифицированной электронной подписью (УКЭП) медработника (ч. 7 ст. 36.2, п. 48 193н), а электронные медицинские документы по приказу 209н подписываются только УКЭП. Негативные сценарии здесь важнее позитивных.

Последняя строка – интеграционный тест, о котором часто забывают: продукт, который молча теряет отправку в ЕГИСЗ, создаёт клинике нарушение без единой ошибки в интерфейсе. Подробнее о сценариях входа и обмена – в статье идентификация через ЕСИА, SSO и регистры ФРМР/ФРМО.

Тесты журнала событий

Журнал событий (аудит-лог) фиксирует, кто, когда и к каким медданным обращался. 152-ФЗ требует регистрации и учёта всех действий с персональными данными (ст. 19 ч. 2 п. 8). Приказ ФСТЭК № 21 раскладывает это на меры группы РСБ: какие события регистрировать, что входит в запись, как её хранить и как реагировать на сбои регистрации. А 209н требует журналировать доступ к электронным медицинским документам. Типичная проблема – не отсутствие журнала, а журнал, который что-то тихо пропускает: пишет входы, но не просмотры записей, или фиксирует действие без того, кто его совершил. Поэтому тест журнала устроен так: генерируете известные события доступа и проверяете, что каждое попало в журнал целиком – пользователь, действие, пациент, время. Если по журналу нельзя восстановить, кто открыл конкретную запись консультации, он подведёт именно тогда, когда нужен больше всего, – при расследовании утечки, когда на итоги у вас 72 часа.

Проверка шифрования: «зашифровано» ещё не значит «законно»

Шифрование необходимо, но недостаточно, и QA должен точно проверить ту часть, которая необходима. Живое WebRTC-видео по умолчанию шифруется в канале через DTLS-SRTP (стандарт, шифрующий аудио и видео реального времени при передаче); хранимые данные – записи, заключения, бэкапы – должны быть зашифрованы при хранении. QA проверяет обе стороны: что медиапоток действительно зашифрован (DTLS-рукопожатие состоялось, никакое медиа не идёт открытым текстом) и что всё записанное в хранилище там зашифровано. Если модель угроз опирается на криптографию для защиты медданных, применяются средства криптографической защиты информации (СКЗИ), сертифицированные ФСБ (приказ ФСБ № 378), и тест проверяет, что в контуре стоят именно те средства, которые указаны в документации. Подробно о слоях шифрования – в статье шифрование для телемедицины: при передаче, при хранении, сквозное.

Отдельно о ловушке: зашифровано – ещё не значит законно. Идеально зашифрованный звонок всё равно может оказаться нарушением, если сервер с его записью стоит за рубежом или если подрядчик, через которого идёт видео, обрабатывает данные без поручения оператора (ст. 6 ч. 3 152-ФЗ). QA проверяет шифрование, а лид по комплаенсу – поручения и размещение. Одна проверка не заменяет другую; договорную сторону разбирает статья поручение обработки ПДн и договоры с подрядчиками.

Тесты утечки медданных

Самый частый реальный дефект комплаенса в телемедицине прозаичен: данные пациента оказываются там, где их быть не должно, обычно в лог-файле или стороннем инструменте. Разработчик добавляет отладочную строку, которая пишет тело запроса с ФИО пациента в лог за пределами защищённого контура. SDK аналитики или краш-репортинга незаметно отправляет своему поставщику снимок экрана с данными пациента. Если поставщик зарубежный, это ещё и запись персональных данных граждан России в зарубежную базу – прямой запрет ст. 18 ч. 5 152-ФЗ с 1 июля 2025 года (штраф для юрлица до 6 млн ₽, повторно – до 18 млн ₽), – и трансграничная передача, о которой ст. 12 требует заранее уведомлять Роскомнадзор.

Поэтому в каждом плане QA должен быть отдельный тест утечки. Заведите синтетических пациентов с уникальными метками-«канарейками» в ФИО, телефоне и номере полиса, прогоните реальные сценарии и ищите эти метки в логах, трекере ошибок, данных каждого стороннего инструмента и записанном исходящем трафике клиентов. Тест пройден, только если не найдено ни одной метки. Один этот тест закрывает целый класс незаметных утечек, за которые при данных о здоровье грозит штраф 10–15 млн ₽ (ч. 16 ст. 13.11 КоАП).

Тесты локализации хранилищ

Смежный автотест – инвентаризация мест, где лежат данные. Ст. 18 ч. 5 152-ФЗ требует хранить персональные данные граждан России в базах на территории России и прямо запрещает зарубежные базы. Для QA это проверяемые утверждения: перечень хранилищ (базы, хранилища записей консультаций, бэкапы, логи, очереди, сервер транскрибации) совпадает с реальной инфраструктурой, и у каждого регион размещения – Россия; исходящий трафик клиентов не содержит обращений с персональными данными к зарубежным хостам. Новые зависимости проходят ту же проверку автоматически: один новый SDK может обесценить весь предыдущий аудит. Как выбирать размещение, разбирает статья локализация данных, суверенитет и где хранятся медданные.

Пентест и сканирование уязвимостей

Два самых специализированных теста безопасности. Сканирование уязвимостей – автоматическая проверка систем по каталогу известных слабостей (устаревший софт, неверные настройки, открытые порты). Оно дёшево, его запускают постоянно, и оно напрямую закрывает меру АНЗ приказа № 21. Российский открытый каталог – Банк данных угроз безопасности информации ФСТЭК (БДУ), где наряду с угрозами ведётся перечень уязвимостей. Тестирование на проникновение (пентест) – специалист или нанятая команда пытается проникнуть в систему так, как действовал бы реальный злоумышленник, и находит то, что сканер пропускает. Этапы стандартные: планирование, разведка, атака, отчёт. Для внешнего контроля привлекают организацию с лицензией ФСТЭК на техническую защиту конфиденциальной информации. Смысл пентеста не в ежегодной галочке: он нужен, чтобы найти дефект доступа или утечку раньше злоумышленника. Против каких угроз тестировать, определяет модель угроз – она разобрана в статье моделирование угроз телемедицинской платформы.

Тесты доступности: WCAG 2.1 и ГОСТ Р 52872-2019

Доступность – тоже часть комплаенса. Общая обязанность обеспечивать людям с инвалидностью доступ к услугам вытекает из 181-ФЗ, а технический ориентир – ГОСТ Р 52872-2019, построенный на WCAG 2.1. Стандарт добровольный, но на него удобно сослаться в техническом задании, а WCAG 2.1 AA – это чек-лист примерно из пятидесяти критериев: контраст, навигация с клавиатуры, скринридеры, субтитры.

Для клинического видео особенно важны субтитры в реальном времени – WCAG 2.1, критерий 1.2.4 Captions (Live), уровень AA: глухой или слабослышащий пациент должен иметь возможность их включить. Тесты сочетают автоматические сканеры (контраст, разметка) с ручной проверкой на реальном скринридере и навигацией только с клавиатуры: самые серьёзные барьеры автоматика не видит. Полный разбор – в статье WCAG 2.1 AA и ГОСТ Р 52872-2019 для телемед-видео.

Когда тестирование становится испытаниями: граница медизделия

Есть ещё одна граница, за которой QA превращается в другой процесс. Если продукт лишь передаёт и показывает данные, а решение принимает врач, хватает обычного QA. Но если функция интерпретирует клинические данные – оценивает снимок, считает риск, предлагает диагноз, – она может оказаться медицинским изделием: по ст. 38 323-ФЗ медизделием бывает и специальное программное обеспечение, предназначенное производителем для диагностики, лечения или мониторинга. Такое ПО регистрируют в Росздравнадзоре по правилам ПП 1684 (ПО прямо входит в их сферу, п. 2), класс риска определяют по приказу Минздрава 4н от 06.06.2012, и ПО с искусственным интеллектом там всегда относится к классу 3 (п. 15.1.1). В телемедицине это не теория: 193н допускает системы поддержки принятия врачебных решений на базе ИИ, только если они зарегистрированы как медизделия (п. 15–17).

За этой границей «тестирование» становится формальной верификацией и валидацией – документированным прослеживаемым процессом, обычно по международному стандарту жизненного цикла медицинского ПО IEC 62304. В нём каждое требование связано с доказательством выполнения, а результаты идут в технические и клинические испытания для регистрации. Для ПО-медизделий разрешение Росздравнадзора на клинические испытания не требуется (п. 31 «в» ПП 1684), но сами испытания никто не отменял. Граница между «показать врачу» и «интерпретировать за врача» проведена в статье где ИИ встраивается в телемед-продукт, а клинические испытания разобраны в статье пилоты, клиническая валидация и развёртывание. Отмечайте как можно раньше любую функцию, которая смещается в сторону диагностики: встраивать верификацию и валидацию в уже собранный продукт дорого.

Пример: размер матрицы надёжности

На цифрах объём работы виден лучше, а считать здесь несложно. Допустим, по вашей аудитории имеет смысл тестировать пять комбинаций «устройство – браузер» и четыре именованных сетевых профиля (хороший интернет, средний домашний, загруженный Wi-Fi, плохой мобильный), а в основном сценарии три критических пути, которые проверяются на каждой комбинации: войти в звонок, пережить переподключение, перейти на один звук.

Перемножаем. Пять комбинаций устройств × четыре сетевых профиля = двадцать ячеек окружения. Двадцать ячеек × три критических пути = шестьдесят тест-кейсов надёжности, которые прогоняются заново на каждом релиз-кандидате. Объём ощутимый, но посильный при автоматизации: шестьдесят скриптовых WebRTC-кейсов на облачной сетке занимают минуты, вручную – дни. Поэтому надёжность клинического видео не «проверяют» один раз перед запуском: этот набор прогоняют постоянно, ведь каждый релиз может сломать любую из шестидесяти ячеек.

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

Частая ошибка: тестировать только позитивный сценарий на хорошей сети

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

Вторая ловушка – считать тесты комплаенса разовой проверкой перед запуском. Контроль доступа и журналы ломаются, как любой код: рефакторинг через три спринта может незаметно сломать журнал, который запросит проверяющий, а новый SDK – начать отправлять данные за рубеж. Выход один: включить тесты плохой сети, старых устройств и комплаенса в автоматический набор, который запускается на каждом релизе. Тогда условия, которых вы больше всего боитесь в продакшене, станут условиями, в которых вы тестируете по умолчанию.

Нажмите, чтобы увеличить

Где здесь Фора Софт

Фора Софт разрабатывает софт для видео реального времени с 2005 года, в том числе телемедицинские платформы. Надёжность в плохих реальных условиях – основа нашей работы: тесты сетевых условий, переподключения и пиков, на которых спотыкаются универсальные команды, для нас рутина. Поскольку речь о здравоохранении, комплаенс и безопасность мы считаем полноправной частью QA, а не довеском в конце: тесты контроля доступа, входа через ЕСИА и подписи УКЭП, журналов, шифрования, утечек и размещения данных в России входят в план тестов с первого спринта, как и тесты доступности. Мы также работаем с видеоконференциями, стримингом, e-learning и видеонаблюдением, поэтому отказы живого видео под нагрузкой для нас привычная задача, а не сюрприз в неделю запуска.

Главное

• В телемедицине проваленный тест оборачивается клиническим событием или утечкой с уведомлением Роскомнадзора, поэтому цена ошибки QA здесь выше, чем в потребительском приложении.
• У QA клинического видео две половины: тесты надёжности и тесты комплаенса и безопасности. Нужны обе.
• Тестируйте на плохих сетях и старых устройствах целенаправленно: у тех, кому телемедицина нужнее всего, худшие соединения.
• Оценку мер защиты требует закон: ст. 19 152-ФЗ – до ввода в эксплуатацию, приказ ФСТЭК № 21 – не реже раза в три года; проект замены добавляет переоценку после инцидентов.
• Вход через ЕСИА, ФРМР, УКЭП, журнал событий, утечки и локализация хранилищ – проверяемые утверждения, и для каждого нужен автотест.
• Если функция интерпретирует данные за врача, QA превращается в верификацию и валидацию медизделия с регистрацией в Росздравнадзоре.

Что читать дальше

• Надёжность соединения: реконнект, смена сети и плавная деградация – как должно работать переподключение, которое проверяет ваш набор тестов надёжности.
• Журналы аудита и контроль доступа для клинического видео – меры, работу которых доказывают ваши тесты комплаенса.
• Чек-лист готовности по 152-ФЗ и 323-ФЗ и подготовка к проверкам – куда войдут результаты ваших тестов к запуску.