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

Вот так солидно нейросеть видит медицинских QA

В этой статье я сконцентрирую внимание на открытом стандарте IEEE 11073 Service-oriented Device Connectivity (SDC) и рассмотрю, зачем нужно ручное тестирование медицинских устройств, в том числе на нескольких примерах.

Не будем останавливаться на подробном описании деталей SDC протокола, это уже отлично сделано в двух других статьях «Как общаться в проприетарном зоопарке или проблема совместимости медицинских устройств» и «Алгоритмы автоматической проверки требований к внедрению SDC протокола».

Вместо этого я лучше расскажу в чем уникальность тестирования медицинского продукта, пусть даже мы тестируем не сам продукт, а передачу данных между разными продуктами.

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

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

Соответственно, каждое их этих требований должно быть проверено, что приводит к огромному количеству необходимых атомарных тестов.

Давайте разберем несколько наглядных требований.

Поговорим про асистолию – полную остановку сердца.

Асистолия (далее также ASY) является одной из важнейших видов тревог, которые, в принципе, могут случиться с пациентом. Поэтому мало того, что она имеет максимально высокий уровень тревоги, так еще и отключить ее просто так невозможно.

Возьмём для примера 2 упрощённых требования для ASY:

1.В SDC протоколе должна передаваться информация о тревогах и сообщениях об асистолии;

2.Если не включены специальные баннеры на мониторе об отключении ASY, асистолия должна всегда находиться в состоянии «включено», или при включенных баннерах – «выключена» (хотя на самом деле ASY отображается даже в выключенном состоянии, просто уже не как тревога, а как сообщение или баннер).

Стоит сказать несколько слов о самом SDC протоколе, а точнее о том, что из себя представляют тревоги (alerts) в нём:

Они состоят из двух сущностей - Alert conditions и Alert signals. Более детально про Alert conditions и Alert signals можно прочитать в статье “Алгоритмы автоматической проверки требований к внедрению SDC протокола”, если вкратце:

Alert conditions (далее так же кондишены) – описывают сущность, отвечающую за условия, когда тревога должна быть выставлена.

Alert signals (далее так же сигналы) – описывают сущность, отвечающую за отображение сигналов, в нашем случае визуальных и аудио.

Рассмотрим на примере с помощью SDCclient (https://github.com/Draegerwerk/sdc11073/tree/master) – софта, представляющий из себя SDC consumer, то есть потребителя данных.

Так будет выглядеть ASY во вкладках Alert conditions и Alert signals:

Нас в данном случае интересует 2 свойства: Activation и Presence

Activation – атрибут, показывающий включена ли интересующая нас сущность, для простоты мы будем рассматривать только два состояния – «On» и «Off». У тревоги это свойство означает ведётся ли мониторинг, или нет.

Presence – атрибут, принимающий значение «True» (Alert conditions) и «On» (Alert signals) в момент активной тревоги. Для простоты мы снова будем рассматривать только значения «True/False» у тревоги, «On/Off» у сигнала.

Как видно на скриншотах выше, в неактивном состоянии Alert condition ASY имеет Activation = on и Presence = off, что соответствует состоянию, когда тревога включена и неактивна.

При этом аудио и визуальные сигналы тоже имеют Activation = on и Presence = off, что говорит о том что отображение тревоги включена, но в данный момент не активно.

Теперь создадим тревогу остановки сердца и посмотрим данные, которые придут через SDC протокол:

Как мы видим, Activation кондишенов и сигналов осталось прежней, а вот Presence сменился на True и On соответственно.

Отсюда можно сделать вывод что ASY передается и один атомарный тест для подтверждения 1 требования готов.

Включим специальный баннер “hr/asy/vf off”

При активном баннере активация ASY становиться выключена, как и сказано во втором требовании.

Если подходить совсем формально, то мы проверили оба наших упрощенных требования, каждое одним атомарным тестом. В реальности нам приходится проверять значительно большее количество случаев, но подход в целом остается тот же.

С одной стороны, мы видим при возникновении ASY в протоколе передаётся информация о Alert conditions и Alert signals об этой тревоги. С другой – если асистолия отключена с помощью баннера «hr/asy/vf off» то активация Alert conditions и Alert signals уходит в off. Тут мы не рассматриваем требование стандарта о взаимосвязи Activation и Presence кондишенов и сигналов, не рассматриваем состояния паузы, фиксированного состояния (это состояние, когда тревога уже прошла, но сообщение о том, что тревога была, все еще должно передаваться, пока врач не уведомит что прочитал его) и прочего.

Можно, кстати, добавить, что работа с мед. оборудованием вызывает небольшую проф. деформацию (начинаешь обращать внимание на мед. мониторы в фильмах и сериалах)

Вот, для примера, известный сериал "Игра в кальмара", сцена, где пациент на больничной койке только-только умер:

Как видим, сердце у пациента остановилось, но никакой тревоги ASY мы не видим, а почему? Если посмотреть на верхнюю часть экрана, то видно плашку ECG LL Lead Off. То есть съёмочная группа просто сняла ECG клеймо с пациента, чтобы и сердцебиение пропало, и чтобы не включалась максимальная тревога и своей красной мигающий частью и пронзительным звуковым сигналом не портила трогательный момент.

Давайте рассмотрим еще пару требований:

1. SDC устройство не должно использовать свойство extension у элемента, если этот extension имеет семантическое значение, которое совпадает со значением атрибута этого элемента.

Звучит достаточно сложно, но на самом деле это означает, что мы не должны использовать имя extension’а в элементе, которое может воспринять за какой-либо атрибут этого элемента.

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

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

Как итог – проверяем мы его с помощью ревью кода нашего продукта, ищем все места, где у нас создаются extension’ы, и проверяем, что все они нам известны и требование не нарушают.

2. Инсталлятор должен выставлять ACL’ы (https://ru.wikipedia.org/wiki/ACL/) для всех файлов и папки куда устанавливается софт.

И как формально тестируется это требование для верификации? Мы должны проверить, что инсталлятор выставляет какие-то ACL’ы, потому что требование не уточняет детали. В то же время вполне очевидно, что проверять просто факт выставление прав доступа к файлам — это недостаточно, и, в данном случае, очевидно, что дополнительно надо проверить какие именно доступы проставлены и как они влияют на работоспособность приложения, но в формальном тесте не верификацию этого не будет.

Тестирование медицинского оборудования, с одной стороны, заключается в анализе тысяч формальных требований, спущенных с разных уровней (аналитики, риск менеджмент, стандарты, важные запросы мед. сестер и врачей, которые приходят от product owner’а). Хотя тема тестирования требований заслуживает совершенно отдельной темы. С другой – необходимо покрывать все требования формальными тестами для официальной верификации, также необходимо огромное количество ad hoc теста, ибо цена дефекта может грозить критическими травмами и даже угрожать жизни пациента. Именно поэтому ручное тестирование в медицинском оборудование максимально необходимо.

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

Ручное тестирование в медицине на примере SDC протокола