Андрій Петльований Провідний архітектор із понад чверть століття досвіду у сфері розробки програмного забезпечення та роботизованих систем. З 2019 року працює в команді GlobalLogic, де спеціалізується на створенні медичних пристроїв найвищого ризику (Class III) з використанням C, C++ та Python. 9 липня, 16:02 0
MedTech – одна з галузей, де інженерна помилка має фізичну вартість. Будь-який продукт проходить тривалий шлях від припущення до фактичного застосування в операційній. Причина криється в суворих регуляторних вимогах: кожен пристрій мусить бути сертифікований, безпечний і детально задокументований. Окрім того, MedTech має високий поріг входу — інвестиції тут значно більші, ніж в інших сферах, а розробка вимагає цілої екосистеми фахівців: від Embedded-інженерів до експертів із сертифікації та лікарів.
Андрій Петльований, Principal Architect у GlobalLogic Ukraine, та Андрій Дворакевич, кандидат медичних наук і керівник Центру хірургії лікарні Святого Миколая, розповіли, як створюються медичні продукти на перетині інженерії, робототехніки та клінічної практики.
З чого починається розробка медичного продукту
У медтеху ТЗ — це не відправна точка, а результат дослідження. Продукт завжди починається з потреби лікаря, пацієнта або системи охорони здоров’я. Discovery-фаза тут значно ширша за стандартний аналіз ринку: команда мусить валідувати ідею з наукової, технічної та регуляторної точок зору. Необхідно довести: чи можливий такий продукт фізично, чи відповідатиме він очікуванням зацікавлених сторін і чи не запізниться з виходом на ринок.
Для трансформації запиту медиків у конкретні вимоги розробники використовують, зокрема, підхід Voice of Customer (VoC). Це система збору зворотного зв’язку, де фіксуються відгуки всіх, хто взаємодіятиме з пристроєм — від хірургів до центрів підтримки. Далі ці дані фільтруються за моделлю Кано, щоб відокремити критичні функції безпеки від другорядних особливостей.
Результатом цього аналізу стає TRS (Technical Requirement Specification) — документ, де кожна клінічна потреба перетворюється на вимірюваний технічний атрибут: частоту імпульсу, пропускну здатність, рівень енергоспоживання тощо. Головним інструментом контролю тут є Traceability Matrix (матриця простежуваності). Вона наскрізно пов’язує первинну вимогу лікаря з конкретним архітектурним модулем, задіяним класом у коді та фінальним тест-кейсом.
Архітектурні виклики на Discovery фазі: проєктування приладів Класу III
На етапі Discovery інженери мають довести технічну здійсненність (Feasibility) концепту. Для цього створюються швидкі прототипи на відлагоджувальних платах (DevBoards) або програмні симулятори. Головне завдання — перевірити, чи можливо виконати потрібні математичні алгоритми на залізі в межах специфікованих часових інтервалів, щоб це не вплинуло на загальний час реакції системи на зовнішні та внутрішні події.
Особливо критично це для медичних приладів Класу III за класифікацією FDA — систем, від яких залежить життя пацієнта. У них затримка виконання операції або раптове просідання батареї може призвести до летальних наслідків.
Приклад такої Hard Real-Time системи з практики GlobalLogic — архітектурне проєктування кардіостимулятора. Це імплантований пристрій, що генерує електричні імпульси для синхронізації серцевого ритму. Якщо система пропустить інтервал для подачі електричного імпульсу через інший алгоритм, який займає більше часу ніж очікувалося, то це негативно вплине на здоров’я людини. Тому раннє прототипування дозволяє правильно підібрати апаратне забезпечення для відповідного обчислювального навантаження.
Інша проблема, яка повинна бути вирішена у більшості таких систем — це відсутність єдиної точки відмови, яка призведе до неконтрольованої поведінки системи. Наприклад, ПЗ, яке контролює подачу імпульсу, може увійти у вічний цикл через невідому помилку. Щоб прилад працював надійно, до його дизайну додається спеціальний код, який регулярно робить перекличку всіх підсистем і має план дій у випадку “мовчання” однієї із них.
Останнім часом доволі популярним стає розробка вбудованих систем із використанням середовища QPC від Quantum Leaps:
| Характеристика | Традиційна RTOS (напр., FreeRTOS, Zephyr) | Quantum Leaps QP/C |
| Базова архітектура | Багатозадачність (Потоки) | Подійно-орієнтована (Активні об’єкти та ієрархічні скінченні автомати) |
| Механізм взаємодії (IPC) | Черги повідомлень, семафори, прапорці подій | Асинхронний обмін подіями (повідомленнями) між об’єктами |
| Модель виконання | Переважно блокуюча (задача чекає на ресурс або системну затримку) | Run-to-Completion (RTC). Обробник події виконується швидко і без блокувань. |
| Споживання пам’яті (RAM) | Високе. Кожна задача потребує власного виділеного стеку | Низьке. Можливе використання одного спільного стеку (через кооперативний планувальник QV) |
| Ризики Concurrency | Високі. Ризик інверсії пріоритетів, deadlocks та race conditions | Мінімальні. Відсутність блокуючих викликів і спільних ресурсів архітектурно усуває ці ризики |
| Тестованість та трейсинг | Складно відтворити баги, пов’язані з таймінгами потоків | Висока. QP має QSpy для детального моніторингу подій та переходів між станами |
| Крива навчання | Помірна. Більшість інженерів звикли до класичних потоків | Висока. Потрібно навчитися мислити подіями та малювати діаграми станів |
| Застосування в медицині | Широке. Багато RTOS мають медичну сертифікацію (напр., SafeRTOS) | Відмінно підходить для пристроїв зі складною логікою (напр., ШВЛ, інфузомати) завдяки передбачуваності кінцевих автоматів |
Провівши архітектурні ітерації та закодувавши ключові компоненти обох варіантів, команда довела, що асинхронна Event-Driven архітектура є на порядок ефективнішою для цього завдання. Вона усунула класичні проблеми розробки embedded-систем — дедлоки та інверсію пріоритетів.
Гібридний підхід Agile-Vee та криза стандартного IT-інструментарію
У MedTech-проєктах золотим стандартом є класична V-модель. Її логіка побудована на тому, що кожен рівень проєктування (від потреб користувача до архітектури) на протилежному боці моделі повинен мати свій етап перевірки.
Різницю між двома головними стовпами цієї моделі — Verification та Validation — найпростіше пояснити на прикладі розробки портативного кардіографічного ЕКГ-сенсора безперервного моніторингу:
- Verification перевіряє відповідність коду та заліза технічним специфікаціям (TRS). Вона проходить у лабораторних умовах на інженерних стендах. Тут перевіряється, чи сенсор зчитує сигнал із заданою частотою, чи правильно фільтрує шуми та, чи відповідає задокументованому дизайну.
- Validation відповідає на питання “Чи правильний продукт ми створили?”. Це перевірка того, чи вирішує пристрій проблему реальної людини. Для приладів Класу III — це суворо контрольовані клінічні випробування на фокус-групах пацієнтів під наглядом лікарів.
У звичайному IT V-модель інколи вважають застарілою через її лінійність. Тому ми поєднуємо її з гнучкими практиками за гібридним принципом Agile-Vee (Agile-on-the-inside, V-model-on-the-outside). Зовні ми зберігаємо чітку структуру для регулятора, але внутрішні етапи проєкту розбиваємо на спринти, де ітераційно створюються кодинг-модулі та відповідні тести.
Паралельно DevOps-інженери розгортають CI/CD-інфраструктуру: при кожному внесенні коду в репозиторій тести автоматично запускаються на емуляторах та реальному залізі (Hardware-in-the-Loop). Якщо під час спринту виявляється архітектурна прогалина або новий ризик, дизайн-документація коригується одразу, що дозволяє проходити формальні витки верифікації значно швидше.
Керувати таким детермінованим процесом за допомогою стандартного IT-софту на кшталт Jira — неможливо. Як хмарне рішення, Jira регулярно оновлюється на боці провайдера, що може непередбачувано змінити логіку роботи її API чи інтерфейсу. У медичному середовищі така нестабільність недопустима. Тому для менеджменту вимог та контролю ризиків інженери використовують спеціалізовані Heavy-duty інструменти — JAMA, IBM DOORS або Windchill RV&S. Вони мають довгий цикл підтримки, строгий контроль версійності та відмовостійкість.
Інтеграція ШІ у MedTech: чи працює це як в інших стеках?
Коли розробка доходить до релізу, нескінченно “докручувати” продукт неможливо — це занадто дорого. Апаратура, години медичної команди, утримання об’єктів для тестування коштують десятки тисяч доларів, а прострочення дедлайну може посунути сертифікацію ще на рік. Частково на стадії тестування допомагає ШІ.
Головний бар’єр тут — жорстке правове поле. Передавати закриті медичні дані, алгоритми та вихідний код публічним LLM-моделям — це прямий юридичний ризик. Будь-яка ідея впровадження ШІ на реальному проєкті проходить сувору корпоративну бюрократію. Проте, коли юридичні перешкоди подолано (зокрема, через використання ізольованих корпоративних LLM), ШІ ефективно автоматизує рутину:
- Аналіз регуляторної документації та пошук колізій: ШІ аналізує гігантські масиви стандартів (FDA, ISO 13485, ISO 14971), шукає суперечності між вимогами або перевіряє систему на відповідність конкретному пункту.
- Генерація та покриття тест-кейсами: ШІ допомагає швидше створювати архітектуру тестів, розуміти складні взаємозв’язки в коді та формувати супровідну документацію для тест-методів.
- Валідаційні звіти для інструментарію: за правилами FDA, кожен інструмент, який використовується для тестування медичного виробу, сам має бути валідований. ШІ автоматизує створення цих специфічних і об’ємних валідаційних документів.
GlobalLogic використовує для цього DeviceSure — власний внутрішній акселератор та фреймворк для автоматизованого тестування медичних приладів, у який зараз інтегрують агентську ШІ-інфраструктуру.
Один з нещодавніх кейсів, де ШІ суттєво зекономив час — підготовка аналізу Secure Bootloaders для embedded-пристроїв. Завдання завантажувача — створити безпечне середовище при запуску приладу, перевірити криптографічний підпис прошивки і заблокувати спроби залити сторонній шкідливий код. Інженеру необхідно було детально порівняти існуючі завантажувачі, виділити їхні архітектурні плюси та мінуси й підготувати технічну презентацію для клієнта. Генеративні моделі структурували та наповнили фактами документ за лічені хвилини, після чого архітектору залишалося лише провести фінальну верифікацію посилань.
UX/UI в хірургічній робототехніці: від комп’ютерного зору до Hands-Free
Лікарі співпрацюють з інженерною командою на всіх етапах розробки: від валідації гіпотез до фінальних випробувань. Але є етап, де участь хірурга є безальтернативною — це проєктування UX та UI.
Проєктування інтерфейсів у MedTech-домені відрізняється від комерційного IT. Якщо у звичайному софті невдалий інтерфейс коштує компанії втраченого клієнта, то в операційній ціною помилки може стати життя пацієнта. Сучасні медичні консолі вимагають створення інтерфейсів, які мінімізують когнітивне навантаження на лікаря і дозволяють керувати системою, не відриваючи рук від маніпуляторів.
“З появою роботів ми почали комфортніше оперувати та менше втомлюватись. Так, ми мінімізуємо потенційні помилки, зумовлені людським фактором, — зазначає Андрій Дворакевич. — Технології забезпечують досконалість маніпуляцій, зокрема мінімізацію крововтрати через їхню адресність. Коли операція триває годинами, вирішальними стають дрібниці: реакція інструмента на рух чи втома руки”.
Щоб реалізувати запити медиків на практиці, інженерам доводиться розробляти складні програмно-апаратні комплекси. Зокрема, ми реалізували такі рішення:
1. Інтелектуальний ендоскоп з Computer Vision
Під час операцій хірургам необхідно в реальному часі розуміти точні лінійні розміри внутрішніх органів, тканин або пухлин. Для цього інженери розробили системи комп’ютерного зору. Нейромережа отримує відеопотік з ендоскопа і в реальному часі виконує сегментацію кадрів: розпізнає хірургічні інструменти, визначає їхні межі та координати кінчиків. Оскільки софту відома кінематика робота, кут введення камери та її оптичні параметри, система прораховує фізичну вартість одного пікселя на екрані та автоматично вираховує реальну відстань між об’єктами в міліметрах.
Головним інженерним викликом тут є Latency. За медичними протоколами безпеки, затримувати живий відеопотік зсередини пацієнта не можна ні на мілісекунду. Ми вирішили це через розділення архітектурних потоків: “сире” відео транслюється на монітори через прямий апаратний потік без затримок, а важка математична аналітика обробляється паралельно на рівні GPU. Завдяки технології подвійної буферизації, ШІ накладає координатну сітку та вимірювання як графічний оверлей вже на наступні кадри з мінімальним запізненням, непомітним для ока хірурга.
2. Hands-free управління для робота-хірурга
Головна парадигма сучасного медичного UX — Hands-Free. Хірург не повинен відривати рук від джойстиків керування роботом, щоб змінити щось на екрані. Для цього ми розробили системи відстеження погляду лікаря та голосового управління.
На рівні заліза в консоль інтегруються високошвидкісні камери. Головна технічна складність — розпізнати рух зіниці, коли лікар працює в окулярах в умовах відблисків від операційних ламп. Інженери експериментально підібрали джерела світла та оптичні фільтри з оптимальною довжиною хвилі в інфрачервоному спектрі. Математична модель вираховує координати вектора погляду і передає їх через промисловий протокол DDS. Дані миттєво зчитує підсистема приводів робота, що працює під управлінням RTOS, змушуючи ендоскоп плавно рухатися за очима хірурга.
Щоб повністю розвантажити інтерфейс, систему доповнюють голосовим керуванням для базових команд (наприклад, “Змінити інструмент” або “Режим навігації”). Вони фактично дублюють екранне меню. Щоб навчити ШІ безпомилково розпізнавати мову в реальних умовах, аудіодані збираються наживо в операційних — на тлі писку моніторів, шуму вентиляції та розмов асистентів. Інженери адаптують алгоритми DSP та мовні бібліотеки під специфічний медичний вокабуляр. Як результат, синергія комп’ютерного зору, трекінгу очей та аудіо-моделей дозволяє створити безшовний інтерфейс, де робот підкоряється погляду та слову лікаря.
Фінішна пряма: архітектурний аналіз відмов та регуляторне сито FDA
Коли технічна частина та інтерфейси готові, продукт виходить на фінішну пряму — регуляторну сертифікацію. У MedTech-домені розробка ведеться в межах Системи управління якістю (QMS) та Стандартних операційних процедур (SOP) замовника. Вони базуються на ISO 13485 (якість медичних виробів) та ISO 14971 (менеджмент ризиків).
Особливе місце тут посідають стандарти проєктування: IEC 62304 — детально регламентує кожен крок життєвого циклу медичного софту, та IEC 60601 — визначає вимоги до базової безпеки та електромагнітної сумісності електронних медичних приладів, гарантуючи, що робот чи сенсор не створять критичних навантажень на іншу апаратуру й будуть повністю безпечними для людини.
Найвище регуляторне сито — це сертифікація FDA. Якщо компанія створює перший у своїй категорії прилад, процедура триває роками. Сам лише розгляд документів у FDA займає від 8 до 15 місяців. Регулятору передається гігантський пакет доказової документації: від результатів клінічних випробувань до звітів про надійність коду.
Щоб успішно пройти це сито, інженери ще на етапі проєктування (згідно з вимогами IEC 62304) зобов’язані провести аналіз потенційних відмов системи та оцінити їхній вплив на людину. Для цього використовуються дві інженерні методології:
- FMEA (Failure Mode and Effects Analysis): аналіз відмов та їхніх наслідків. Інженери розкладають систему на атоми й прораховують, що станеться, якщо відмовить конкретна мікросхема, просяде напруга на платі або відбудеться збій у черзі подій софту. Для кожної потенційної відмови розробляється програмний або апаратний архітектурний захист.
- FTA (Fault Tree Analysis): аналіз дерева відмов. Це дедуктивний метод, коли інженери йдуть від зворотного: беруть критичну катастрофічну подію (наприклад, “робот-хірург не виконав команду зупинки струму коагуляції”) і зводять логічне дерево з усіх можливих комбінацій апаратних збоїв та помилок у коді, які могли б до цього призвести.
Усі ці заходи з усунення ризиків детально документуються та лінкуються з архітектурним дизайном приладу. Тільки за умови наявності технічної бази та пройдених аудитів медичний виріб отримує “зелене світло” для виходу на ринок.
Висновки: як змінюється роль інженера в медицині
Медицина є консервативною сферою, де зміни запроваджуються дуже повільно. Регулятори, лікарі та безпекові вимоги формують “трикутник обмежень”, у якому будь-яка нова технологія має довести свою надійність. Тому про те, що ШІ забере роботу у медиків, а через три роки людей масово оперуватимуть роботи, мова не йде.
Найреалістичніший тренд на найближчі роки — розвиток систем-асистентів, які працюють поруч із людиною: підказують, попереджають, допомагають аналізувати дані, але не приймають остаточне рішення.
Ще один напрям — мініатюризація та зменшення травматичності втручань. Медицина рухається до рішень, які потребують менших розрізів або використовують природні шляхи доступу до організму – наприклад, через ковтання, а не розрізи на тілі.
Роль інженера в медицині змінюється: він стає частиною медичної екосистеми, де потрібно розуміти клінічний контекст, мову лікарів, обмеження регуляторів, поведінку пацієнтів і реальні умови використання продукту.
Роль лікаря так само модифікується завдяки технологіям: “Ми вже отримали точніші інструменти та підтримку. Далі лікар все більше ставатиме спостерігачем та контролером процесу, який виконуватиме роботична платформа. Проте це не означає усунення людини — радше перехід до вищого рівня точності та безпеки”, — підсумовує хірург.
За даними порталу: mezha.ua