Як сертифікувати програмне забезпечення як медичний виріб: нюанси, які варто врахувати для стандартизації за ISO 13485

Всім привіт! Я Віталій Опара, консультант з сертифікації в Infinity Technologies. Нещодавно ми пройшли повний цикл сертифікації для нашого клієнта, його програмного продукту за стандартом ISO 13485. Це був складний, але цінний досвід. Я хочу поділитися нашим шляхом: що це за сертифікація, навіщо вона потрібна софтверній компанії, і як ми перебудували наші процеси розробки, щоб їй відповідати.

Що таке ISO 13485 і навіщо він софту?

Якщо коротко, ISO 13485 — це міжнародний стандарт, що визначає, якою має бути QMS організації протягом життєвого циклу медичного виробу: від дизайну та розробки — до виробництва, постачання, сервісу й постмаркетингового нагляду. Він побудований на принципах ризик-орієнтованого підходу, простежуваності та регуляторної відповідності. Сучасні регулятори (в ЄС це MDR, у США — FDA) ввели поняття Software as a Medical Device (SaMD), або «Програмне забезпечення як медичний виріб».

Навіщо він бізнесу (value proposition)

1. Доступ на ключові ринки

• ЄС: EN ISO 13485 (із додатком A11) адаптований під MDR/IVDR; застосування стандарту відповідає ряду вимог регламентів.
• США: перехід FDA до QMSR означає, що система якості, сумісна з ISO 13485, стає фактично базовою нормою для американського ринку.
• MDSAP: один аудит для п’яти юрисдикцій — оптимізація витрат на комплаєнс і інспекції.

1. Зниження ризиків: системне управління ризиками, CAPA, постмаркетинговий нагляд та контроль постачальників прямо зменшують імовірність рекламацій, відгуків і збоїв постачань.
2. Комерційні можливості: OEM/ODM‑контракти й великі тендери часто вимагають ISO 13485 як кваліфікаційний бар’єр.

Навіщо це нам було потрібно?

1. Доступ до ринків. Без маркування CE (в ЄС) або дозволу FDA (в США) ви просто не маєте права продавати свій продукт. А ISO 13485 — це фундамент для отримання цих дозволів.
2. Управління ризиками. Це головне. Стандарт змушує вас думати не про «баги», а про «потенційну шкоду пацієнту».
3. Довіра клієнтів. Наявність сертифіката доводить, що ваші процеси надійні, передбачувані та безпечні.

Як розробляти софт, щоб пройти аудит

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

Для розробників це означає знайомство з двома новими стандартами:

1. IEC 62304: Це стандарт, що описує життєвий цикл програмного забезпечення для медичних виробів.
2. ISO 14971: Це стандарт з управління ризиками.

Ось як це змінює звичний нам процес розробки.

1. Класифікація софту і чому це важливо

Перше, що ми зробили, — це класифікували наш софт за класом безпеки (згідно з IEC 62304):

• Клас А: Може спричинити несерйозну шкоду.
• Клас B: Може спричинити серйозну шкоду (non-serious injury).
• Клас C: Може спричинити смерть або тяжку шкоду (serious injury).

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

2. Управління ризиками (Risk Management):

За ISO 14971, ви повинні:

1. Ідентифікувати ризики: Що, якщо наш алгоритм ШІ дасть хибнонегативний результат при аналізі онкомаркерів?
2. Оцінити ризики: Яка ймовірність (Probability) і яка тяжкість (Severity) наслідків?
3. Контролювати ризики: Що ми технічно зробимо, щоб знизити ризик?

Приклад з нашої практики:

• Ризик: Некоректний розрахунок дози інфузії через помилку округлення (floating-point error).
• Оцінка: Ймовірність — низька, Тяжкість — катастрофічна (смерть пацієнта).
• Захід контролю (Mitigation):
• На рівні архітектури: Використання Decimal замість float/double для всіх критичних розрахунків.
• На рівні коду: Впровадження захисних перевірок (defensive programming), які спрацьовують, якщо значення виходить за межі безпечного діапазону.
• На рівні тестування: Створення окремого набору unit-тестів тільки для цього розрахунку з граничними значеннями.

3. Traceability (Простежуваність)

Це був наш найбільший виклик. Аудитор хоче бачити повний, нерозривний ланцюжок. Він може ткнути пальцем у будь-який рядок коду і запитати:

• Яку вимогу користувача (User Need) реалізує цей код?
• Яку технічну вимогу (Software Requirement) він закриває?
• Яким ризиком (Risk) був зумовлений цей if?
• Якими unit-тестами (Verification) покрито цей код?
• Якими системними тестами (Validation) перевірено цю фічу?

Ми реалізували це через жорстке зв’язування у JIRA та Confluence. Кожна вимога мала унікальний ID, який «тягнувся» через весь цикл:

User_Need_001 -> Software_Req_015 -> Risk_004 -> Task-123 (JIRA) -> Git_Commit_Branch -> Unit_Test_Case_045 -> System_Test_Protocol_007

Без такої «матриці простежуваності» (Traceability Matrix) аудит ви не пройдете.

4. Життєвий цикл: V-Model замість «чистого» Agile

Багато хто з нас звик до гнучких методологій. Але для MedTech «чистий» Scrum — це проблема. Ви не можете просто взяти фічу в спринт, написати код і віддати в реліз.

Ми не відмовилися від Agile повністю, але інтегрували його у V-Model.

Це означає, що на кожен етап проектування (ліва частина V) у нас є симетричний етап тестування (права частина V):

• Написали Software Requirements -> Написали System Tests (Validation).
• Спроектували Архітектуру -> Написали Integration Tests.
• Написали Detailed Design (специфікацію класу/модуля) -> Написали Unit Tests (Verification).

Код не вважається «написаним», поки не написані і не пройдені всі рівні тестів, що доводять, що він робить те, що треба (Verification) і робить правильну річ (Validation).

Архітектурні виклики та SOUP

Як має виглядати архітектура такої системи?

Ключові архітектурні рішення:

1. Ізоляція критичних компонентів. Модуль, що розраховує дози, жив у «пісочниці». Він мав мінімум залежностей і чіткий, вузький API. Ми ізолювали його, щоб довести аудитору, що помилка в UI (наприклад, не прогрузилася іконка) ніколи не вплине на критичний розрахунок.
2. Детальний «Alarm Management». Що відбувається, коли щось іде не так? Ми розробили цілу підсистему алармів, класифікованих за пріоритетом (низький, середній, високий — знову ж таки, на основі ризиків).
3. Кібербезпека «by design». Це вимога ISO 13485. Ми впровадили шифрування даних (in transit, at rest), жорстке управління доступом (RBAC) і, що важливо, документували кожен з цих заходів як міру зі зниження ризику (наприклад, ризику витоку даних пацієнта).

SOUP (Software of Unknown Provenance)

Це будь-який сторонній код, який ви не писали. Ваша улюблена npm-бібліотека? Це SOUP. .NET Core? Це SOUP.

Ви не можете просто зробити npm install. Для кожної бібліотеки, навіть найменшої, ми мали:

• Обґрунтувати її необхідність.
• Оцінити ризики, пов’язані з нею (а що, якщо в left-pad знову буде проблема?).
• Задокументувати версію, яку ми використовуємо.
• Написати тести, які перевіряють, що бібліотека робить саме те, що ми від неї очікуємо.

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

Як отримати сертифікацію (практичний roadmap)

1. Діагностика (gap‑аналіз): проти ISO 13485 та релевантних регуляцій (MDR/IVDR, QMSR).
2. Архітектура QMS: політики, процесна карта, RACI, контроль документів/записів.
3. Імплементація критичних процесів: дизайн‑контроль, валідація процесів/ПЗ/стерилізації, supplier quality, complaint/CAPA, UDI/traceability де потрібно.
4. Risk & PMS контур: інтегрувати управління ризиками, постмаркетинговий нагляд і звітність.
5. Навчання, внутрішній аудит, перегляд керівництва.
6. Сертифікаційний цикл: Stage 1 (документи) → Stage 2 (on‑site) → усунення NC → сертифікат (зазвичай 3 роки) + щорічні наглядові аудити.

Складнощі та висновки

ISO 13485 — це не про те, як добре ви пишете код. Це про те, наскільки добре ви можете довести, що ваш процес написання коду безпечний, контрольований і керований ризиками.

Що ми отримали в результаті?

1. Сертифікат і доступ на ринок ЄС.
2. Код, в якому ми впевнені. Коли ти знаєш, що від твоєї функції calculate() залежить життя, ти тестуєш її зовсім інакше.
3. Дисципліновану команду. Наші інженери тепер мислять не «фічами», а «ризиками для пацієнта».

Це дорого, повільно і бюрократично. Але коли мова йде про MedTech, іншого шляху просто не існує.