top of page

Розробка медичного програмного забезпечення: погляд бізнес-аналітика на регуляторні вимоги

Фото автора: Iryna SizikovaIryna Sizikova

Роль бізнес-аналітика у дотриманні регуляторних вимог


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


Бізнес-аналітик має добре орієнтуватися в основних нормативних актах, таких як FDA 21 CFR Part 820, ISO 13485, ISO 14971 та IEC 62304. Його робота включає інтерпретацію цих регламентів і забезпечення їх відображення у вимогах до програмного забезпечення. Це означає ідентифікацію аспектів продукту, які повинні відповідати галузевим стандартам, та співпрацю з фахівцями з регулювання для уточнення вимог відповідності.


Одна з найважливіших задач бізнес-аналітика є збір та документування нормативних вимог. Ці вимоги повинні бути чіткими, простежуваними та піддаватися тестуванню. Бізнес-аналітик гарантує інтеграцію нормативних обмежень у процес розробки продукту шляхом документування функціональних і нефункціональних вимог, які відповідають регулюванням; впровадження принципів управління ризиками (згідно з ISO 14971) у визначення вимог; застосування нормативних вимог до конкретних функцій програмного забезпечення; забезпечення покриття всіх вимог відповідності.

Бізнес-аналітик тісно співпрацює з менеджером із забезпечення якості (QA), щоб забезпечити відповідність вимогам на всіх етапах життєвого циклу програмного забезпечення. Він сприяє комунікації між командами, організовуючи воркшопи та дискусії з експертами з регулювання, перевіряючи відповідність вимог нормативним стандартам перед їх передачею розробникам, а також допомагаючи командам QA у визначенні підходів до верифікації та валідації (V&V).


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


Відмінності між розробкою медичного та немедичного програмного забезпечення


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


На відміну від звичайних програмних продуктів, медичний програмний продукт має відповідати міжнародним нормам охорони здоров'я та проходити суворі перевірки. Регуляторний контроль вимагає дотримання таких стандартів, як FDA у США, MDR у ЄС та ISO. Ці нормативи гарантують, що медичне програмне забезпечення відповідає високим стандартам безпеки, на відміну від загального програмного забезпечення, яке керується лише галузевими стандартами.


Ще одним важливим аспектом є управління ризиками: медичне програмне забезпечення підлягає ретельному аналізу ризиків відповідно до ISO 14971. У немедичному програмному забезпеченні такі комплексні оцінки зазвичай не проводяться. Крім того, велике значення мають простежуваність та документація: кожна зміна в медичному програмному забезпеченні має бути задокументована й обґрунтована, забезпечуючи повне простежування від вимог до реалізації, тестування та деплойменту.


Недотримання нормативних вимог може мати серйозні наслідки, зокрема ризики для пацієнтів через можливі діагностичні помилки або несправність критичних медичних пристроїв; юридичні та фінансові санкції, включаючи штрафи, відкликання продуктів або заборону використання невідповідного програмного забезпечення; обмеження на ринковий доступ - без відповідних регуляторних схвалень медичне прогамне забезпечення не може продаватися в ключових регіонах, таких як США та ЄС.


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


Класифікація FDA (США)

FDA класифікує програмне забезпечення залежно від рівня ризику:

  • Клас I (низький ризик) – мінімальний вплив на безпеку пацієнта, часто звільняється від попереднього схвалення.

  • Клас II (помірний ризик) – вимагає 510(k) для демонстрації схожості з уже затвердженими пристроями.

  • Клас III (високий ризик) – потребує Premarket Approval (PMA) та розширених клінічних досліджень.


Класифікація MDR (ЄС)

MDR класифікує медичне програмне забезпечення за ризиком для пацієнта:

  • Клас I – загальні медичні програми без критичного впливу.

  • Клас IIa – програме забезпечення, що підтримує клінічні рішення.

  • Клас IIb – програме забезпечення, що впливає на критичні медичні рішення.

  • Клас III – автономні системи ухвалення критичних рішень.


Класифікація безпеки програмного забезпечення за IEC 62304

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

  • Клас A – відсутній ризик травмування або пошкодження

  • Клас B – можливе несерйозне травмування

  • Клас C – можливе серйозне травмування або смерть


Приклади медичного програмного забезпечення за класифікацією

Тип програмного забезпечення

FDA Class

EU MDR Class

IEC 62304 Class

Приклади

Загальні оздоровчі додатки

Class I

Class I

Class A

Додатки для відстеження фізичної активності, крокоміри, монітори сну

Управління робочими процесами в лікарні

Class I

Class I

Class A

Управління ліжками, планування прийомів

Електронні медичні записи (EHR)

Class I / II

Class I / IIa

Class A / B

Системи EMR/EHR, такі як Epic, Cerner

Програмне забезпечення для вимірювання артеріального тиску

Class II

Class IIa

Class B

Додатки для аналізу показників АТ, цифрові тонометри

Додатки для моніторингу рівня глюкози

Class II

Class IIa

Class B

Додатки, що відображають рівень цукру в крові з глюкометра

Програмне забезпечення для аналізу зображень (некритичне)

Class II

Class IIb

Class B

AI-додатки для покращення якості медичних зображень у радіології

Програмне забезпечення для моніторингу пацієнтів у відділенні інтенсивної терапії

Class II / III

Class IIb

Class C

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

Програмне забезпечення для AI-діагностики раку

Class III

Class III

Class C

AI-системи для виявлення пухлин на КТ/МРТ-знімках

Програмне забезпечення для керування інсуліновою помпою

Class III

Class III

Class C

Програмне забезпечення, що безпосередньо регулює подачу інсуліну

Програмне забезпечення для планування променевої терапії

Class III

Class III

Class C

Програмне забезпечення для розрахунку доз опромінення при лікуванні раку

 

Інструменти для управління вимогами


У розробці медичного програмного забезпечення, структуроване управління вимогами має вирішальне значення через сувору відповідність нормативним вимогам і потреби в управлінні ризиками.


JIRA та плагін R4J служать потужними інструментами для структурованого керування вимогами. У той час як JIRA надає гнучку систему відстеження проблем, яка дозволяє командам створювати, керувати та відстежувати вимоги в Agile або традиційній структурі розробки, R4J використовується для розширення її можливостей.


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


Confluence, інструмент для спільного документування та управління знаннями, розроблений Atlassian, надає потужні макроси інтеграції JIRA, які дозволяють командам експортувати, відображати та динамічно керувати даними JIRA на сторінках Confluence. Це особливо корисно для керування вимогами, звітів про відстеження та документації відповідності в регульованих галузях.


Висновки


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

 


About author:

My name is Iryna Sizikova.

For the past 17 years I have been working in the healthcare industry, at Dentsply Sirona, US dental equipment and software product manufacturer that markets its products in over 120 countries.

My current role is the Chapter Lead of the System Analysis and Documentation team.

I am passionate about business analysis and enjoy sharing best practices and techniques with my colleagues. We regularly hold BA club meetings where we discuss challenging topics and explore solutions together.

 
 
 

Комментарии


bottom of page