Управление рисками в программных системах медицинских устройств. Узнай, как специалисты Sii помогают клиентам внедрять эффективный контроль рисков

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

Из-за характера производства медицинских устройств, организации по всему миру определили потребность в создании единых правил и стандартов, необходимых для выполнения таких проектов. Применяя правила, все вовлеченные стороны обязуются защищать безопасность пациентов, одновременно содействуя медицинским инновациям.

— Sii — это консалтинговая компания, которая работает с клиентскими системами управления качеством и рисками, — говорит Wojciech Drescher, Senior Head of Healthcare в Sii. – Сейчас компании должны иметь рабочую среду, в которой внедрено ISO 13485 (Система управления качеством) и ISO 14971 (Управление рисками), а разработка программного обеспечения для медицинских устройств выполняется в соответствии с IEC 62304. Если это не так, Sii специалисты могут помочь клиенту реализовать необходимые настройки, – добавляет он.

Классификация безопасности программного обеспечения – обязательное условие для систем в медицинских устройствах

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

• A: нет травм или возможен вред здоровью,
• B: возможна травма, но не серьезная (реверсивная),
• C: возможна смерть или серьезная травма.

Эта классификация отличается от Регламента ЕС по медицинским устройствам (EU MDR) или Классификации медицинских изделий Управления по продовольствию и медикаментам США (FDA MDC). Вы все еще можете иметь медицинское оборудование класса III с SSC класса A.

Определение программного риска – как обеспечить эффективность процесса

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

— Команда специалистов Sii проводит комплексный процесс управления рисками программного обеспечения, — говорит Marek Matuszak, Senior Software Engineer в Sii. — Анализ выполняется на системном уровне, учитывая не только программное обеспечение и целевое использование, но и оборудование и механику медицинского устройства, аксессуары и предполагаемое ненадлежащее использование, — объясняет он.

Во-первых, специалисты Sii оценивают риск на основе единственной неисправности, худшего сценария. Затем правила, определенные документом IEC/TR 80002-1, используются для выбора типичных сценариев ошибок программного обеспечения. Что касается устройств, подключенных к сети, вопросы кибербезопасности также учитываются.

— Рассмотрим, например, программное обеспечение, отвечающее за управление приводом, — говорит Marcin Lis, Compliance and Medical Software Validation Specialist в Sii. — Вопрос, на который нужно ответить, что могло произойти, если бы программное обеспечение отогнало привод в наименее ожидаемое время и позицию? Или вместо того чтобы остановиться, он загнал привод дальше, чем было запланировано? Какой ущерб может нанести такое событие? – продолжает он.

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

Влияние на развитие медицинского оборудования

Следствием процесса являются три возможных результата:

• Все риски приемлемы, а программная система относится к классу A.
• Некоторые риски являются неприемлемыми, но возможно внедрение внешних мер контроля рисков. Это включает, но не ограничивается разработкой аппаратных методов смягчения или разработкой других мер по уменьшению последствий программной ошибки.
• Некоторые риски недопустимы, им присваивается класс B или C, в зависимости от тяжести возможного повреждения. Могут быть введены дополнительные требования к программному обеспечению, которые становятся мерами контроля рисков. Высшие SSC, требования к программному обеспечению и результаты испытаний могут быть использованы в качестве аргумента для уменьшения частоты в анализе ISO 14971.

Поскольку IEC 62304 требует, чтобы все факторы риска программного обеспечения рассматривались с вероятностью возникновения «1», оценка риска между IEC 62304 и ISO 14971 имеет некоторые общие моменты, но их следует рассматривать как две разные области.

— Безопасность и качество на первом месте без компромиссов, — говорит Piotr Mazurski, Lead Auditor/Cybersecurity Consultant at Sii. — Чем выше SSC, тем строже процедура разработки программного обеспечения согласно IEC 62304. Разработка программного обеспечения класса C требует значительно больше ресурсов, чем программное обеспечение класса A. Это связано с требованиями, необязательными для класса А.