Несколько слов по результатам семинара по ГОСТ IEC 62304 в Перми.
К сожалению, мероприятие получилось закрытым, и кое-кто из докладчиков так и не доехал до Перми сославшись на занятость. Но мероприятие получилось весьма полезным для прояснения ситуации.
Я обещал поделиться своей презентацией для Перми, она касалась применения ГОСТ IEC 62304 для ПО связки "ПЛК + Сенсорный экран" в медицинском изделии. Это получается "Embedded Software", но и это ПО так же требует правильного документирования.
У нас с документированием такого отечественного ПО ситуация как на этой классической картинке (не у всех, конечно, но всё же):
В Перми мы начали обсуждать этот вопрос непосредственно с программистами, которые сразу заявили, что "ГОСТ IEC 62304 - это ваш стандарт, медицинский, а не программистский, поэтому документированием по этому стандарту должен заниматься специалист по регистрации медизделий или кто-то ещё, но не мы".
Однако, без специальных знаний в области программного обеспечения, осилить ГОСТ IEC 62304 нелегко. Особенно когда специалист по регистрации или специалист СМК пытается объяснить программистам, что им нужно делать - это выглядит, как минимум, смешно.
Больших трудов стоило создать рабочее настроение на семинаре и начать совместными усилиями работать над осмыслением стандарта. Кое-что сделать удалось, - однако моя презентация требует серьезной переработки, чем я и занимаюсь в свободное от поездок время.
ГОСТ IEC 62304 - стандарт не испытательный, он не содержит конкретных требований к медицинскому ПО, а некоторые его требования вызывают у программистов недоумение.
Финские авторы Ilkka Juuso и Ilpo Pöyhönen написали 367-страничную книгу об этом стандарте, о котором можно говорить бесконечно как раз из-за его неконкретности.
Но всё равно, лучше со стандартом, чем без него.
В Перми мы попытались ответить на основной вопрос специалиста по документированию: «а что конкретно писать в этом пункте?». Особенно в таких неисчерпаемых пунктах как, например, 5.3 «Проектирование АРХИТЕКТУРЫ программного обеспечения», 5.5 «Имплементация ПРОГРАММНЫХ БЛОКОВ».
Рекомендую здесь подход «take it easy» - не нужно пытаться поразить регулятора знанием IEEE 1471-2000 или деталями программирования. Регулятор не проверяет сам код, ему нужны доказательства безопасности.
То же самое и с пунктом 3.22 «Защищённость» - задокументировать этот пункт кажется непосильной задачей, особенно если постоянно мониторить баг-репорты.
Например:
В конце января 2024 года aiohttp обновилась до версии 3.9.2, в которой устранили уязвимость CVE-2024-23334. Это path traversal баг, затрагивающий все версии aiohttp (начиная с 3.9.1) и старше, который позволяет удаленным злоумышленникам без авторизации получить доступ к файлам на уязвимых серверах.
Ссылка: https://nvd.nist.gov/vuln/detail/CVE-2024-23334
На мой взгляд, это нужно прорабатывать в Файле Менеджмента Риска, а не в документации жизненного цикла, к которой относится документация на ПО, составленная по требованиям ГОСТ IEC 62304.
В общем, я попытался систематизировать все замечания и учесть все пожелания - как это получилось (или нет) - скоро увидим.
Сейчас мы с коллегами работает над подготовкой документации для медицинского ПО с Искусственным интеллектом, если Вам интересно применение ГОСТ IEC 62304-2022 в отношении такого продукта, то напишите в комментариях. Мы планировали подготовить несколько лекций.
#ГОСТ_62304 #медицинские_изделия #программное_обеспечение #жизненный_цикл_программного_обеспечения