Тестування додатків для медичного обладнання

В останній час отримувати медичну допомогу через цифрові сервіси стає дедалі більш популярним. Маючи загальне розуміння про медицину можна здогадатись, що скоріш за все, це дуже серйозне програмне забезпечення. Адже лікарська помилка, як і помилка в роботі додатку може нанести великої шкоди здоров’ю пацієнта.

Медичний додаток – це програмний продукт, створений для лікарів і пацієнтів. Функціонал та призначення кожного додатку дуже відрізняється. Це можуть бути ресурси для зберігання медичних даних, корпоративні додатки для клінік і лікарень, керування драйверами медичного обладнання та інше. Зазвичай застосунки, які пов'язані з ризиком для життя пацієнта, розробляються за V-подібною або гнучкою методологією.

Особливості тестування 

На перший погляд, тестування медичних додатків технічно не сильно відрізняється від рішень в інших галузях. Однак є кілька важливих особливостей, які позначаються на роботі та надають їй своєрідності.

Створюючи програмні продукти для охорони здоров'я, потрібно орієнтуватися на провідні практики. Найчастіше працюють за гнучкою ітеративною методологією, коли за етапом розробки слідує тестування, а за його результатами може бути запущений новий цикл створення. Все це зводиться в єдиний безперервний потік.

Тестування медичного ПЗ – це підвищена відповідальність за результат праці спеціаліста. Інформаційні системи надають лікарям різні інструменти, що полегшують прийняття рішень: розрахунок дозування препаратів, призначення тієї чи іншої терапії. Але вони не приймають ці рішення за лікаря. Останнє слово завжди залишається за фахівцем, і найближчим часом в цьому плані навряд чи щось зміниться. З одного боку, розробник медичного софта формально не відповідає за лікарське рішення, але з іншого – зобов'язаний зробити все можливе, щоб інформаційна система не давала збоїв і приносила лише користь.

Тестування медичного ПЗ включає велику кількість персональних даних, що підлягають обробці і зберіганню. Крім того, тут можна зіткнутися з даними, які вимагають підвищеного рівня захисту. Якщо фахівці з інформаційної безпеки виявляють загальні, очевидні сценарії джерел, то відділ тестування повинен також перевірити відсутність критичних помилок в коді.

Варто відмітити, що сховища персональних і клінічних даних розділяються. Таким чином, управління доступом і обробка особистої інформації пацієнта і його клінічних даних – це різні процеси. При тестуванні необхідно перевіряти можливість зробити запит з бази в обхід авторизації.

Однією з особливостей перевірки продукту є специфічний контент медичних сервісів: наприклад, картки пацієнтів з результатами аналізів і оглядів, діагнозами й пропонованими видами терапії. Всі ці фактори, які взаємно впливають один на одного, не дозволяють при розробці софта тестувати його формально, використовуючи якісь умовні параметри. Доводиться заглиблюватися в предметну область, виявляти взаємозв'язки між параметрами.

Розробник будь-якої інформаційної системи повинен враховувати в першу чергу саме інтереси користувачів медичних сервісів. Тестувальникам потрібно вжитися в роль кінцевого споживача і видати незвичайні сценарії, які потім трансформуються в тестові. 

Іноді спеціалісти змушені відходити від принципу атомарних тестів і досліджувати довгі користувацькі сценарії та великі пласти бізнес-логіки.

Жоден постачальник медичних виробів чи оператор ринку не захочуть доставити несправний продукт. Провайдер стикається зі значними ризиками. Пристрій у супроводі несправного програмного забезпечення може не отримати схвалення ринку. Якщо проблеми виникають після випуску, через оновлення або під час більш інтенсивного використання пристрою, його можна відкликати з ринку. Організація, яка представила несправний продукт, може бути оштрафована, а неякісне програмне забезпечення може вплинути на добробут користувачів. Наприклад, коли терапевтичне рішення приймається на основі неправильних даних діагностики.

Також якщо безпека недостатня, постачальник ризикує розкрити інформацію про стан здоров’я пацієнтів. Репутація продавця медичних виробів псується, що може призвести до втрати угод та зменшення доходу, проте цього можна уникнути. Нижче будуть наведені варіанти забезпечення якості та тестування, які слід здійснити, щоб гарантувати високу якість програмного забезпечення для медичних виробів.

1. Починати процес тестування слід, перевіряючи формулювання передбачуваного використання програмного забезпечення – опис того, для чого та як продукт буде використовуватися. Застосування за призначенням буде в основі подальшої валідації.
2. Наступним кроком потрібно визначити потреби у дотриманні програмного забезпечення. 
3. Далі необхідно визначити, до якого рівня занепокоєння (великого, помірного чи незначного) належить програмне забезпечення, що супроводжує медичний виріб.

Процес тестування усіх рівнів занепокоєння має включати такі заходи:

1. Перевірка програмного забезпечення

Починати потрібно з перевірки вимог до продукту та переконання, що воно буде узгоджене та стане корисним у призначенні.

2. Перевірка вимог до програмного забезпечення

Щоб виявити потенційні дефекти продукту на самих ранніх етапах життєвого циклу, потрібно перевірити якість вимог. Функціональні можливості, продуктивність, безпеку та інші вимоги до продукту для ясності, послідовності та відстеження.

3. Перевірка дизайну програмного забезпечення

Необхідно залучити архітектора програмного забезпечення, щоб перевірити, чи належним чином відображаються вимоги, чи дотримуються відповідні стандарти безпеки для мінімізації ризиків якості. Команда QA, у свою чергу, має перевірити специфікацію розробки продукту на ясність та однозначність. Необхідно додати перевірку дизайну наприкінці кожного етапу життєвого циклу програмного забезпечення.

4. Перегляди коду та одиничне тестування

Потрібно встановити методи, які дозволяють виявляти дефекти на початку життєвого циклу розробки програмного забезпечення. Прийняти вказівки щодо якості коду, щоб визначити вимоги щодо його чіткості, складності, ремонтопридатності та інших відповідних аспектів. Необхідно виконати аналіз вихідного коду, щоб перевірити його відповідність прийнятим настановам, і налаштувати регулярний огляд коду.

Крім того, корисно збільшити частку тестування, що проводиться командою розробників на рівні підрозділу, оскільки це допомагає виявляти дефекти в той момент, коли їх виправлення значно легше та дешевше.

5. Перевірка програмного забезпечення

Постачальники медичних виробів та програмного забезпечення часто наполягають на швидкій доставці якісного продукту, проте його тестування не можна скоротити до мінімуму. Таким чином, щоб спростити процес перевірки, не впливаючи на якість, рекомендують поєднувати тестування на рівні API та на системному. Також потрібно розглянути можливість застосування таких перевірених практик, як автоматизація тестування та безперервне тестування, реалізовані в конвеєрі CI/CD.

Необхідно також ретельно перевірити нефункціональні аспекти програмного забезпечення медичних виробів. Потрібно супроводжувати функціональне тестування тестами продуктивності, зручності використання, безпеки та сумісності.

6. Перевірка відповідності

Якщо медичний виріб підлягає перевірці відповідності, він має бути протестований на норми, вимоги ISO 13485, IEC 62304 або IEC 82304-1.

Стандарт IEC 62304 

Міжнародний стандарт IEC 62304 – це норма, яка визначає вимоги до життєвого циклу розробки медичного програмного забезпечення та програмного забезпечення для медичних пристроїв. Він узгоджений Європейським союзом (ЄС) і США (Сполучені Штати Америки), і тому може використовуватися як еталонний тест до відповідності нормативним вимогам на обох цих ринках. Цей стандарт поширюється на розробку та обслуговування програмного забезпечення для медичних пристроїв. Стандарт IEC 62304 забезпечує основу для процесів життєвого циклу розробки продукту з діями та завданнями, необхідними для безпечного проєктування та обслуговування продукту. Він не охоплює перевірку продукту, навіть якщо той повністю складається з програмного забезпечення.

Стандарт IEC 62304 вимагає певних застережень при використанні продукту, особливо SOUP (софт невідомого походження). 

Відповідно до стандарту IEC 62304, ПЗ присвоюється клас безпеки, виходячи з можливих наслідків впливу на пацієнта або користувача.

Класи безпеки розділені за ступенем тяжкості наступним чином:

Class A: Відсутність ризику травми або нанесення шкоди здоров'ю.

Class B: Ризик незначних травм.

Class C: Ризик серйозних травм, летального результату.

Класи ризику 

Кожній програмній системі виробник повинен присвоїти клас ризику згідно з можливим впливом на пацієнта, користувача або інших осіб. Якщо небезпека може відбуватися через відмову в роботі програмної системи, то ймовірність цього повинна бути прийнята, як стовідсоткова.

Якщо ризик смерті або серйозної травми, що виникає через відмову продукту, зменшується до допустимого рівня за допомогою апаратних заходів управління небезпекою або зниження наслідків відмови, ступінь ризику може бути знижений з класу C до В.

Якщо ризик незначної травми, що залежить від відмови продукту подібним чином зменшений до допустимого рівня за допомогою апаратних заходів, ступінь ризику може бути знижений відповідно з класу В до А.

Кожній системі, якщо їй не присвоєно рівень безпеки, за замовчуванням, може бути присвоєно клас С.

Нижче представлена таблиця необхідної документації для кожного класу

Для того, щоб успішно представити медичний виріб на ринку, постачальнику продукту необхідно переконатися, що їхній процес забезпечення якості відповідає певним критеріям. Документація з випробувань має бути точною та повною. Потрібно надати матеріальний доказ виконаної діяльності з валідації та перевірки. 

Вимоги до бізнесу, відповідності та поводження з ризиками повинні бути зіставлені з технічною та проєктною документацією на випробування. Це не тільки допоможе переконатися, що всі вимоги охоплені тестовими прикладами, але й прискорить процес перевірки та полегшить налагодження. Діяльність з випробування має бути пріоритетною на основі рівня ризику компонентів програмного забезпечення. Компоненти з найбільшою небезпекою мають бути перевірені раніше у життєвому циклі випуску продукту.