ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТР

56849—

2015/

ISO/TR

17791:2013

Информатизация здоровья

РУКОВОДСТВО ПО СТАНДАРТАМ БЕЗОПАСНОСТИ МЕДИЦИНСКОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ISO/TR 17791:2013 Health informatics — Guidance on standards for enabling safety in health softwares (IDT)

Издание официальное

Москва

Стандартинформ

2016

Предисловие

1    ПОДГОТОВЛЕН Федеральным государственным бюджетным учреждением «Центральный научно-исследовательский институт организации и информатизации здравоохранения Министерства здравоохранения Российской Федерации» (ЦНИИОИЗ Минздрава) и Федеральным бюджетным учреждением «Консультационно-внедренческая фирма в области международной стандартизации и сертификации «Фирма «ИНТЕРСТАНДАРТ» на основе собственного аутентичного перевода русский язык международного документа, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 468 «Информатизация здоровья» при ЦНИИОИЗ Минздрава – постоянным представителем ISO ТС 215

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 30 декабря № 2241-ст

4    Настоящий стандарт идентичен международному документу ISO/TR 17791:2013 «Информатизация здоровья. Руководство по стандартам безопасности медицинского программного обеспечения» (ISO/TR 17791:2013 «Health informatics — Guidance on standards for enabling safety in health software»).

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2016

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

ГОСТ Р 56849-2015

НКЧ    – национальный комитет-член;

PACS – системы передачи и архивирования изображений;

СМК    – система менеджмента качества;

ЦРПО -жизненный цикл разработки программного обеспечения;

ОРС    – организация — разработчик стандартов;

СУЗС    – средство управления знаниями стандарта;

UCD    – проектирование с ориентацией    на пользователя;

ВОЗ    – Всемирная организация здравоохранения.

В ИТ-программе НСЗ Англии «Connecting for Health» был создан упреждающий процесс управления инцидентами, связанными с безопасностью, для решения вопросов, связанных с безопасностью программного обеспечения [3]. За пятилетний период с 2006 по 2010 гг. было зарегистрировано и изучено 708 сообщений об инцидентах. Было установлено, что примерно 80 % этих инцидентов представляли некоторую угрозу безопасности пациентов (4.1).

4 Безопасность медицинского программного обеспечения

4.1 Инциденты, связанные с безопасностью медицинского программного обеспечения

В рамках ИТ-программы НСЗ Англии «Connecting for Health» был реализован упреждающий процесс менеджмента инцидентами, связанными с безопасностью, для решения вопросов безопасности программного обеспечения в Англии. За пятилетний период с 2006 по 2010 гг. было зарегистрировано и изучено 708 сообщений об инцидентах. Было обнаружено, что примерно 80 % этих инцидентов представляют некоторую угрозу для безопасности пациентов. Был реализован план мероприятий по устранению этих инцидентов, который делает их безопасными в течение 24 ч. Другие страны либо не имеют конкретных данных, либо находятся на ранних стадиях сбора и проверки данных об инцидентах связанного с безопасностью медицинского программного обеспечения, или действительно имеют научные знания, основанные на исследованиях [4], [5]. Данные НСЗ указывают на возможность причинения вреда пациентам, а также на возможность возникновения непредвиденных последствий для безопасности пациентов, исходящих от медицинского программного обеспечения. Вероятность того и другого была бы гораздо выше, если бы НСЗ не разработала и не провела активную кампанию по менеджменту рисков для безопасности программного обеспечения.

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

–    система либо не может передать пациенту сигнал тревоги либо не поддерживает и не обновляет такие сигналы так, чтобы они отражали новые протоколы лечения пациента;

–    ошибки отображения названия препарата и другие ошибки, связанные с клинической терминологией, особенно в тех случаях, когда данные интегрированы из различных лечебных учреждений, информационных систем или организаций;

–    неверно вычисленный возраст пациентов, например для предродовой рентгеноскопии или иммунизации;

–    дозы лучевой терапии либо лекарственного препарата, которые были рассчитаны, представлены либо неправильно сообщены в связи с расчетом или ошибкой при переводе единиц измерения;

–    врачи неправильно интерпретируют клинические данные, представленные им через интерфейс другой системы без предоставления полного контекста этих данных;

–    аннотации к медицинскому изображению, которое отображено в неправильном положении;

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

–    изображения не были своевременно извлечены врачами из системы хранения и передачи изображений (PACS);

–    ошибки миграции данных при приведении в действие новых систем или обновлении основных систем;

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

5

–    правила поддержки принятия клинических решений не были инициированы в правильном порядке, так как некоторые исходные данные были записаны в другом контексте или неправильно преобразованы;

–    нарушения безопасности, которые повреждают целостность или доступность системы;

–    повышенная неготовность работы системы.

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

4.2 Определения медицинского программного обеспечения

Определения программного обеспечения, в частности программных элементов, программных систем и программных модулей, были предоставлены на основе нескольких стандартов, включая ИСО/МЭК 90003:2004 и МЭК 62304:2006. Эти общие определения особенно эффективны при решении проблем построения структур, однако существует постоянная дихотомия, появляющаяся при применении определений программного обеспечения к медицине. Это деление проводит различие между программным обеспечением, которое по определению является медицинским прибором, и медицинским программным обеспечением, которое не является медицинским прибором:

–    первое из вышеупомянутых является определением программного обеспечения медицинского прибора: «Система программного обеспечения, которая была разработана с целью включения в медицинский прибор или которая предназначена для использования в качестве медицинского прибора самостоятельно» (см. МЭК/ТО 80001-1:2010 с изменениями 3.12 МЭК 62304:2006), и

–    второе является определением медицинского программного продукта: «Программное обеспечение, предлагаемое для применения в сфере здравоохранения в целях защиты здоровья, но за исключением программного обеспечения, необходимого для надлежащего применения медицинского прибора» (см. 2.3 ИСО/ТС 25238:2007).

Если исходить из правил применения медицинского оборудования во всем мире, определение программного обеспечения как медицинского прибора может отличаться в определенных регламентах и меняться стечением времени.

Подход настоящего стандарта состоит в применении определения программного обеспечения, используемого в здравоохранении, которое охватывает любое программное обеспечение, оказывающее влияние на обслуживание пациента, независимо оттого, считается ли оно программным обеспечением для медицинского прибора. Как отмечалось Европейским координационным комитетом по радиологической, электромедицинской отрасли и информационным технологиям в здравоохранении (COCIR) о медицинском программном обеспечении в контексте международной стандартизации, комитет COCIR требует, чтобы комитеты, например МЭК/ТК 62 и ИСО/ТК 215, разрабатывали свои стандарты и другие публикации с максимально широкой областью применения.

Настоящий стандарт предназначен для медицинского программного обеспечения со следующими характеристиками:

–    программное обеспечение в своей канонической форме, которая включает в себя системы, элементы и модули (см. МЭК 62304), которые включает в себя связанные с ними данные, хранящиеся в цифровой форме, например таблицы данных или наборы правил, системы кодирования, контентные модели, механизмы логических выводов, архетипы, онтологии, и связанные документы, необходимые для эксплуатации и обслуживания программного обеспечения;

ГОСТ P 56849—2015

–    программное обеспечение, которое используется в сфере здравоохранения, то есть программное обеспечение, которое в любой стадии его жизненного цикла используется, потребляется, приносит выгоду или применяется в любой области сферы здравоохранения. В то же время понятие «предназначено для использования» также может быть применимо, понятие «используется» предполагает более широкое применение. Сфера здравоохранения включает в себя все государственные и частные организации или предприятия, которые обеспечивают охрану здоровья и медицинскую помощь лицам, в том числе медицинские услуги для потребителей (личные медицинские карты, приложения для смарт-фонов/планшетов и т. д.);

–    программное обеспечение, которое включает в себя то, что является коммерчески и не коммерчески доступным.

Наглядными примерами медицинского программного обеспечения являются:

–    реестры пациентов и база данных основных показателей пациентов, ЭМА и ЭМК;

-ЛИС;

–    информационная система лекарственных препаратов;

–    рентгенологическая информационная система;

–    информационная система больницы;

–    система назначения лечения и составления отчета о результатах;

–    системы отслеживания и регистрации вакцинации;

–    система планирования для пациентов, врачей или клинических ресурсов (например, для кабинетов врачей);

–    системы коммунальной медико-социальной помощи;

–    системы медицинской помощи на дому;

-личные медицинские карты;

–    системы, связанные с психическим здоровьем, и системы для определенных заболеваний; и

–    системы здравоохранения населения в той мере, в которой они ориентированы на отдельных лиц (например, прививки, оповещения, эпидемии и т. д.).

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

Наглядными примерами программного обеспечения, которое не относится к медицинскому программному обеспечению в настоящем стандарте, являются:

–    системы управления финансами, кадрами, материалами;

–    обследование населения и системы обследования населения;

–    системы стандартной обработки текста, электронных таблиц или системы программного обеспечения баз данных;

–    системы телекоммуникаций и сетей.

4.3    К более безопасному медицинскому программному обеспечению

Группа стандартов, выявленных и оцененных в настоящем стандарте, рассматривает средства, позволяющие снизить риск и стремиться к более безопасному медицинскому программному обеспечению по мере применения этих стандартов. Программное обеспечение, являющееся безопасным для всех взаимодействий с пациентом, наряду с соответствующей целью и желательным конечным состоянием, никогда не обеспечивается гарантией ввиду невозможности устранения всех рисков. Поэтому подход, основанный на менеджменте рисков, используется для снижения всех рисков, связанных с медицинским программным обеспечением, до приемлемых уровней. Таким образом, основное внимание в подходе, основанном на риске, уделяется снижению, но необязательно устранению, рисков на протяжении всего жизненного цикла медицинского программного обеспечения. Это применимо к полному жизненному циклу медицинского программного обеспечения, как описано в 4.4, и способствует разработке, внедрению и эксплуатации более безопасного медицинского программного обеспечения.

4.4    Жизненный цикл медицинского программного обеспечения

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

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

7

тацией, техническим обслуживанием и действиями по выводу из эксплуатации программного продукта с начала появления до окончательного прекращения работы программного обеспечения (см. ИСО/МЭК 12207:2008). Такие модели жизненного цикла предоставляют средства для проведения всеобъемлющего, полного исследования и оценки стандартов, содействующих повышению безопасности медицинского программного обеспечения.

В настоящем стандарте для содействия такому исследованию и оценке был принят прагматический подход к моделям жизненного цикла. Следующие вопросы являются основополагающими при определении стадий жизненного цикла программного обеспечения:

–    существует ли изменение риска на разных стадиях;

–    существуют ли другие: профиль риска, характеристика менеджмента рисков или необходимость минимизации его последствий между стадиями; и

–    существует ли вероятность распространения риска от одной стадии к другой.

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

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

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

Необходимо отметить, что жизненный цикл программного обеспечения отличается от ЦРПО, несмотря на то что стандарты по ЦРПО предоставляют информацию для настоящего стандарта. Эти стадии жизненного цикла программного обеспечения не предполагают никакого конкретного ЦРПО.

Также в соответствии с целями настоящего стандарта следует отметить, что жизненный цикл программного обеспечения имеет как стадии, так и события:

–    стадиями являются те компоненты жизненного цикла программного обеспечения, которые сопровождаются сопутствующими видами работ, назначенными ресурсами и результатами, и

–    событиями считаются те компоненты, которые являются существенными явлениями, происходящими в данном месте и в данное время.

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

–    разработчики отвечают за проектирование, разработку, производство и техническую поддержку медицинского программного обеспечения (также в некоторых стандартах называемые «производитель» или «поставщик»),

–    специалисты по внедрению отвечают за установку и интеграцию программного обеспечения в клинических условиях (специалист по внедрению может быть разработчиком или владельцем),

–    владельцами являются медицинские организации, закупающие программное обеспечение (и/или специалисты по внедрению управляемых услуг),

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

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

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

Примечания

1    Данные стадии необязательно подразумевают линейное упорядочивание или строгую последовательность во времени.

2    По возможности, для описаний стадий жизненного цикла приведены ссылки; там, где это недоступно, описания стадий жизненного цикла носят лишь информативный характер.

Таблица 1 — Описания жизненного цикла в стандартах

Стандартная стадия жизненного цикла Подстадия(и)а) Определение Участ ники)13) Концепция Документ Формулировка, представление и определение исходного проекта, эстетики и основные функции программного обеспечения R П Требования Документ Требование является необходимостью, условием или обязательством. Оно может устанавливаться или предполагаться организацией, покупателями или другими заинтересованными сторонами [см. ИСО 9000] Р Проектирование Документ Является фазой разработки программного обеспечения, следующей за анализом, которая определяет, как должна быть решена проблема [SKMT — Глоссарий организации Canada Health Infoway] Р Разработка Код, испытание, документ0) Проектирование и разработка представляет собой процесс (или набор процессов), использующий ресурсы для преобразования требований (входов) в характеристики или спецификации (результаты) изделий, процессов и систем01) Р Производство Обеспечение наличия изделия для покупателя или пользователя Р Выпуск Распростране ние Выпуск — это определенная версия конфигурационной единицы, которая предоставлена или выпущена для конкретной целие) [ИСО/МЭК 90003] R в Закупка Покупка коммерчески доступного продукта или привлечение организации к производству «программного обеспечения, сделанного по заказу, или собственной разработки» Р, В, ВО Внедрение Конфигурация оборудования, интеграция, размещение Проверка на совместимость программного обеспечения и сертификация также могут быть включены в этап внедрения либо как первый этап, либо как этап перед установкой Р, в, во Ввод в действие Полная активация некоторой системы, которая находилась на стадии разработки или функционировала в ограниченном тестовом режиме, так чтобы предполагаемые пользователи могли получить к ней доступ [Интернет-сайт AIIWords.com] в, п, во Эксплуатация Любое использование медицинского программного обеспечения при любых настройках, не предназначенных для испытания. Существует вероятность того, что для нового программного обеспечения может возникнуть интервал между вводом его в эксплуатацию и полным применением в клинических условиях п, во Клиническое применение Стадия клинического применения программного обеспечения, на которой в клинике в полном объеме используется программное обеспечение, установленное в соответствии с определением медицинского программного обеспечения из настоящего стандарта, и ее «..влияние на здоровье и здравоохранение субъекта оказания медицинской помощи» п, во Техническая поддержка Техническая поддержка при разработке программного обеспечения является модификацией программного продукта после поставки, с целью исправления ошибки, улучшения производительности и других характеристик [ИСО/МЭК 14764] р, в, п, во

Окончание таблицы 1

Стандартная стадия жизненного цикла Подстадия(и)а) Определение Участ ники)13) Вывод из эксплуатации Система выводится из среды эксплуатации, и результаты работы системы и данные архивируются соответствующими способами*) R П, ВО Окончательное удаление Удаление и завершение работы имеющихся программных продуктов или служб системы, сохраняя при этом целостность работы организации [по материалам ИСО/МЭК 12207] R П, ВО a)    Не каждая стадия жизненного цикла имеет подстадию. b)    Р — разработчик; В — специалист по внедрению; ВО — владелец-оператор; П — пользователь. c)    Также именуемый «производитель». d)    Проектирование и разработка могут рассматриваться как разные стадии отдельного интегрированного процесса проектирования и разработки или как два (или более) отдельных процесса (см. ИСО 9000, ИСО 9001 или ИСО 9004). e)    Для данной стадии система и все связанные с ней продукты передаются покупателю или пользователю. *> Данные также могут быть перемещены или перенесены из одной системы в другую при сохранении семантической целостности.

Авторами настоящего стандарта признается, что «язык» жизненного цикла программного обеспечения, особенно в части, касающейся обеспечения безопасности медицинского программного обеспечения, не фиксирован. Признано считать, что формулировки и определения (если они отсутствуют в каком-либо документе ИСО или другом утвержденном стандарте) могут быть уточнены при дальнейшей разработке стандартов. Также принято считать, что имеются и другие модели программного обеспечения, например модель базовых компонентов (GCM) и связанный с ней комплекс стандартов [6]. Будущий или дальнейший анализ и представление группы применимых стандартов по безопасности медицинского программного обеспечения, например тех, что приведены в данном стандарте, могут быть осуществлены при последующей разработке стандартов, используя классификацию GCM.

Далее представлена сводная информация о жизненном цикле по пяти категориям стадий жизненного цикла, необходимая для настоящего стандарта:

1)    проектирование: включает концепцию, требования и этапы проектирования;

2)    разработка: включает этапы разработки, производства и выпуска;

3)    внедрение: включает этапы установки, настройки, интеграции и ввода в действие;

4)    функционирование: включает этапы функционирования, клинического использования и технической поддержки;

5)    вывод из эксплуатации: включает этапы вывода из эксплуатации и удаления.

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

4.5 Метод выбора стандартов для оценки

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

Источники включают:

-изданные стандарты и текущую программу работ ИСО/ТК 215 «Информатизация здоровья» (ISO/TC 215 Health informatics);

–    изданные стандарты и текущую программу работ ИСО/ТК 210 «Менеджмент качества и общие аспекты медицинского оборудования» (ISO/TC 210 Quality management and corresponding general aspects for medical devices);

–    изданные стандарты и текущую программу работ МЭК/ТК62 КК62А «Общие аспекты электрооборудования, используемого в медицинской деятельности» (IEC/TC 62 SC62A Common aspects of electrical equipment used in medical practice);

10

ГОСТ Р 56849-2015

–    изданные стандарты и текущаую программу работ ИСО/ТК 176 «Менеджмент качества и обеспечение качества» (ISO/TC 176 Quality management and quality assurance);

–    изданные стандарты и текущую программу работ ИСО/МЭК СТК 1 и его подкомитетов и работа технической консультативной группы ИСО/МЭК «Безопасность»;

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

Для определения того, должен ли стандарт находиться среди тех, что рассмотрены в настоящем стандарте, применялось несколько критериев. Стандарт рассматривался, если:

–    стандарт был разработан международной или многонациональной организацией по разработке стандартов;

–    стандарт может быть использован в ходе одного или более этапов жизненного цикла медицинского программного обеспечения;

–    стандарт применялся более чем в одной стране (как определено в ходе неформальной проверки стандартов, перечисленных выше);

–    стандарт применим или рассматривает программное обеспечение или медицинское программное обеспечение, как это определено или выявлено в настоящем стандарте;

–    стандарт рассматривает проблемы риска и безопасности.

Примечание — Все общеприменимые стандарты, например стандарты качества, стандарты, посвященные рискам, или стандарты на системы и проектирование систем (например, СТК 1), определяются как применимые основы надлежащей практики для стадий жизненного цикла программного обеспечения, менеджмента рисков и повышения безопасности и в указанном качестве сгруппированы для упрощения поиска.

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

У нескольких стандартов, которые применяются к безопасному медицинскому программному обеспечению, существуют сопровождающие их информативные руководства по применению этих стандартов. Если у соответствующих стандартов по безопасности медицинского программного обеспечения есть такое руководство, то такая информация дана в подразделе «Отношения» для каждого конкретного оцениваемого стандарта (см. 5.1).

4.6 Стандарты, оценка которых выполнена в настоящем стандарте

В таблицах 2 и 3, приведенных ниже, предоставлен список стандартов, рассмотренных в настоящем стандарте. Таблицы включают номер, название стандартов и организации, ответственные за их разработку (в том числе указание технического ко митета/п од комитета). В таблице 2 перечислены основополагающие серии стандартов по безопасности медицинского программного обеспечения (серии стандартов, которые имеют общее применение). В таблице 3 перечислены те стандарты, которые имеют общие положения для медицинских устройств или специального медицинского программного обеспечения.

Таблица 2 — Основополагающие стандарты, относящиеся к безопасности медицинского программного обеспечения

Область применения Стандарты(ы), руководства и отчеты Организация- разработчик Менеджмент качества ИСО 9000:2005 Системы менеджмента качества. Основные положения и словарь (ISO 9000:2005 Quality management systems — Fundamental and vocabulary) ИСО 9001:2008 Системы менеджмента качества. Требования (ISO 9001:2008 Quality management systems — Requirements) ИСОЯК 176 и ИСО/МЭК СТК 1 ПК7

Окончание таблицы 2

Область применения Стандарты(ы), руководства и отчеты Организация- разработчик Менеджмент качества ИСО 10005:2005 Системы менеджмента качества. Руководящие указания по планам качества (ISO 10005:2005 Quality management systems — Guidelines for quality plans) ИСО 10006:2003 Системы менеджмента качества. Руководящие указания по менеджменту качества проектов (ISO 10006:2003 Quality management systems — Guidelines for quality management in projects) ИСО 10007:2003 Системы менеджмента качества. Руководящие указания по управлению конфигурацией (ISO 10007:2003 Quality management systems — Guidelines for configuration management) ИСО 90003:2004 Техника программного обеспечения. Рекомендации по применению ИСО 9001:2000 к компьютерному программному обеспечению (ISO/IEC 90003:2004 Software engineering — Guidelines for the application of ISO 9001:2000 to computer software)3) ИСОЯК 176 и ИСО/МЭК СТК 1 ПК7 Разработка систем и программного обеспечения ИСО/МЭК 12207:2008 Разработка систем и программного обеспечения. Процессы жизненного цикла программного обеспечения (ISO/IEC 12207:2008 Systems and software engineering — Software life cycle processes) ИСО/МЭК 20000 Информационные технологии. Управление услугами (ISO/IEC 20000 Information technology — Service management) (серия из нескольких частей) ИСО/МЭК 25000 Разработка программного обеспечения. Требования и оценка качества программного продукта (SQuaRE). Руководство по SQuaRE [ISO/IEC 25000 Software Engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Guide to SquaRE] (часть из серии) ИСО/МЭК 15026 Разработка систем и программного обеспечения. Обеспечение систем и программного обеспечения. (ISO/IEC 15026 Systems and software engineering — Systems and software assurance) (серия из нескольких частей) ИСО/МЭК 15504 Информационные технологии. Оценка процессов. (ISO/IEC 15504 Information technology — Process assessment) (серия из нескольких частей) Также серия ИСО/МЭК 27000 (ISO/IEC 27000) именуемая «Серия стандартов ISMS» ИСО/МЭК СТК 1 КК 7 и КК27 Управление риском ИСО 31000:2009 Менеджмент рисков. Принципы и руководство (ISO 31000:2009 Risk management — Principles and guidelines) Руководство ИСО 73:2009 Менеджмент рисков. Термины и определения. (ISO Guide 73:2009 Risk management — Vocabulary) Техническое руководящее бюро ИСО (ТМВ) Эргономика взаимодействия человека и системы ИСО 9241-129:2010 Эргономика взаимодействия человека и системы. Часть 129. Руководство по индивидуализации программного обеспечения (ISO 9241-129:2010 Ergonomics of human-system interaction — Part 129: Guidance on software individualization) ИСО/ТР 16982:2002 Эргономика взаимодействия человека и системы. Методы, основанные на удобстве применения, для обеспечения проектирования, ориентированного на человека (ISO/TR 16982:2002 Ergonomics of human-system interaction — Usability methods supporting human-centred design) ИСОЯК 159 Безопасность Руководство ИСО/МЭК 51:1999 Аспекты безопасности. Руководящие указания по включению в стандарты (ISO/IEC Guide 51:1999 Safety aspects — Guidelines for their inclusion in standards) Объединенная техническая консультативная группа ИСО/МЭК по безопасности а) В настоящее время в ИСО/МЭК СТК 1 /ПК 7 разрабатывается ИСО/МЭК ТО 90003 с целью замены ИСО/МЭК 90003:2004.

Таблица 3 — Стандарты для медицинских устройств или специального медицинского программного обеспечения

Стандарт Название Организация- разработчик Менеджмент качества ИСО 13485:2003 Медицинские приборы. Системы менеджмента качества. Требования для целей регулирования (ISO 13485:2003 Medical devices — Quality management systems — Requirements for regulatory purposes) ИСО/ТК 210 Процесс жизненного цикла программного обеспечения МЭК 62304:2006 Программное обеспечение медицинских приборов. Процессы жизненного цикла программного обеспечения (IEC 62304:2006 Medical device software — Software life cycle processes) ИСОЯК 62 ПК 62A ИСОЯК 210 Менеджмент рисков ИСО 14971:2007 Медицинские приборы. Применение менеджмента рисков к медицинским приборам (ISO 14971:2007 Medical devices—Application of risk management to medical devices) ИСОЯК 210 Менеджмент рисков МЭК/ТО 80001-1:2010 Менеджмент рисков для информационных сетей с медицинскими приборами. Часть 1. Роли, ответственности и деятельность (IEC 80001-1:2010 Application of risk management for IT-networks incorporating medical devices — Part 1: Roles, responsibilities and activities) МЭК/ТК 62 ПК 62А ИСОЯК 215 Менеджмент безопасности ИСО 27799:2008 Информатизация здоровья. Менеджмент информационной безопасности в здравоохранении по стандарту ИСО/МЭК 27002 (ISO 27799:2008 Health informatics — Information security management in health using ISO/IEC 27002)a> ИСОЯК 215 Безопасность ИСО/ТР 27809:2007 Информатизация здоровья. Меры обеспечения безопасности пациента при использовании программных средств (ISO/TR 27809:2007 Health informatics — Measures for ensuring patient safety of health software) ИСОЯК 215 Безопасность ИСО/ТС 25238:2007 Информатизация здоровья. Классификация рисков для безопасности, связанных с медицинским программным обеспечением (ISO/TS 25238:2007 Health informatics — Classification of safety risks from health software) ИСОЯК 215 Проектирование эксплуатационной пригодности МЭК 62366:2007 Медицинские приборы. Проектирование медицинских приборов с учетом эксплуатационной пригодности (IEC 62366:2007 Medical devices —Application of usability engineering to medical devices) ИСОЯК 210 а) Включает ссылки на ИСО/МЭК 27001, ИСО/МЭК 27002 и ИСО/МЭК 27005

4.7 Менеджмент рисков

Определяющим для оценки стандартов, предназначенных для обеспечения безопасности медицинского программного обеспечения, является вопрос: заключается ли цель стандарта в снижении риска на всех этапах жизненного цикла или только для этапов, связанных с программным обеспечением.

Менеджмент рисков подразумевает под собой систематическое применение менеджмента политик, процедур и методик при выполнении задач по анализу, оценке и управлению риском. В ИСО 31000 менеджмент рисков определяется как «скоординированная деятельность по руководству и управлению организацией в отношении рисков. Менеджмент рисков обычно включает оценку, обработку, принятие и предупреждение рисков».

Общий подход к менеджменту рисков определяется в общепризнанном ИСО 31000 и в связанных с ним стандартах:

–    ИСО 31000:2009 Принципы и руководящие указания по реализации (ISO 31000:2009, Principles and guidelines on implementation);

–    МЭК 31010:2009 Менеджмент рисков. Методы оценки риска (IEC 31010:2009, Risk management — Risk assessment techniques); и

–    Руководство ИСО 73:2009 Менеджмент рисков. Словарь (ISO Guide 73:2009, Risk management — Vocabulary).

13

ISO 31000 является исходной точкой для разработки стандартов по менеджменту рисков и служит руководством, применяемым в течение функционирования организации для широкого круга деятельности. Он может быть применен к любому типу риска, независимо от его природы и от того, положительные или отрицательные последствия он имеет. Данный стандарт не предназначен исключительно для рассмотрения вопросов безопасности. Инструкции по введению аспектов безопасности в стандарты указаны в Руководстве 51 ИСО/МЭК.

Менеджмент рисков, связанный со здравоохранением, включен в стандарт по медицинским приборам: ИСО 14971:2007 Медицинские приборы. Применение менеджмента риска к медицинским приборам (ISO 14971:2007, Medical devices —Application of risk management to medical devices) и сопровождающий его МЭК/ТР 80002-1, Руководство по применению ИСО 14971 к программному обеспечению медицинских приборов (IEC/TR 80002-1, Guidance on the application of ISO 14971 to medical device software). ИСО 14971 и МЭК/ТР 80002-1 предназначены для производителей медицинских приборов и программного обеспечения медицинских приборов, включая ЛИС и PACS.

Менеджмент рисков, связанный со здравоохранением, также изложен в МЭК/ТО 80001-1:2010 Применение менеджмента рисков к ИТ-сетям с медицинскими приборами. Часть 1. Роли, ответственности и деятельность (IEC/TR 80001-1:2010 Application of risk management for IT-networks incorporating medical devices — Part 1: Roles, responsibilities and activities), в котором рассматривается риск, возникающий во время внедрения системы и во время ее эксплуатации.

Дополнительный полезный материал по менеджменту рисков, в частности, как он относится к медицинскому программному обеспечению, можно найти в ИСО/ТО 27809:2007 Информатизация здоровья. Меры обеспечения безопасности пациента при использовании медицинского программного обеспечения (ISO/TR 27809:2007 Health informatics — Measures for ensuring patient safety of health software), и ИСО/ТС 25238 Классификация рисков безопасности, связанных с медицинским программным обеспечением (ISO/TS 25238 — Classification of safety risks from health software).

Другой ключевой проблемой менеджмента рисков при обеспечении безопасности медицинского программного обеспечения является необходимость решения вопросов, связанных с распределением рисков и определением остаточного риска в медицинском программном обеспечении на всех стадиях его жизненного цикла. Руководство ИСО 73 определяет распределение рисков как «форму обработки рисков, включающую согласованное распределение рисков с другими заинтересованными сторонами».

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

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

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

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

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

ГОСТ P 56849—2015

Содержание

1    Область применения …………………………………………………………………………………………………………………..1

2    Термины и определения………………………………………………………………………………………………………………2

3    Сокращения ……………………………………………………………………………………………………………………………….4

4    Безопасность медицинского программного обеспечения……………………………………………………………….5

4.1    Инциденты, связанные с безопасностью медицинского программного обеспечения…………………5

4.2    Определения медицинского программного обеспечения…………………………………………………………6

4.3    К более безопасному медицинскому программному обеспечению…………………………………………..7

4.4    Жизненный цикл медицинского программного обеспечения ……………………………………………………7

4.5    Метод выбора стандартов для оценки………………………………………………………………………………….10

4.6    Стандарты, оценка которых выполнена в настоящем стандарте……………………………………………11

4.7    Менеджмент рисков…………………………………………………………………………………………………………….13

4.8    Человеческий фактор …………………………………………………………………………………………………………15

4.9    Уровень детализации ………………………………………………………………………………………………………….16

5    Оценка стандартов и руководящие указания ………………………………………………………………………………16

5.1    Оценка стандартов ……………………………………………………………………………………………………………..16

5.2    Распределение стандартов по их применению для стадий жизненного цикла

и уровню детализации, рассматриваемого в них программного обеспечения…………………………29

5.3    Анализ неохваченных и повторно рассмотренных вопросов при оценке стандартов ………………31

5.4    Стандарты по обеспечению безопасности медицинского программного обеспечения.

Руководство по реализации и использованию………………………………………………………………………34

Приложение А (справочное) Повышение безопасности пациентов благодаря инвестициям

в разработку медицинских программ …………………………………………………………………….38

Приложение В (справочное) Анализ стандартов с позиции жизненного цикла

программного обеспечения …………………………………………………………………………………..39

Приложение С (справочное) Информация об области применения стандартов СТК 1,

касающихся безопасности…………………………………………………………………………………….43

Библиография………………………………………………………………………………………………………………………………45

ГОСТ P 56849—2015

В процессе рассмотрения медицинского программного обеспечения распределение рисков является важным элементом при рассмотрении стандартов с целью понять, охватывает ли область применения стандарта точки перехода, в которых риски распределяются между сторонами, и если это так, то какая из сторон (разработчик, специалист по внедрению, владелец-оператор и/или пользователь) должна предпринять действия по менеджменту рисков.

4.8 Человеческий фактор

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

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

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

ИСО 9241 — это стандарт, состоящий из нескольких частей, предоставляющий всестороннюю основу для решения вопросов, связанных с различными элементами эргономики взаимодействия человека с компьютером.

Следующие два дополнительных стандарта выделяют принципы, связанные с человеческими факторами, которым необходимо следовать при разработке медицинских приборов:

– МЭК 62366:2007 Медицинские приборы. Применение эргономического проектирования для медицинских приборов (IEC 62366:2007 Medical devices —Application of usability engineering to medical devices);

-ANSI/AAMI HE75.2009 Проектирование с учетом человеческого фактора. Проектирование медицинских приборов (Human factors engineering — Design of medical devices).

Несмотря на то что эти два стандарта посвящены медицинским приборам, те же важные принципы применимы к медицинскому программному обеспечению и включают:

a)    привлечение пользователей заранее и часто в процесс проектирования. Привлечение пользователей с самого начала процесса проектирования поможет продвижению подхода проектирования с ориентацией на пользователя. Оба стандарта описывают способы, с помощью которых это может быть достигнуто;

b)    рассмотрение разработчиками характеристик, возможностей и предпочтений пользователей. С целью обеспечения эффективности и безопасности медицинского программного обеспечения, возможности пользователей и их ограничения должны быть учтены в разработке. НЕ75 выделяет принципы проектирования, которые следует учитывать разработчикам с целью обеспечения надлежащей разработки и безопасности в использовании медицинского программного обеспечения. Руководство по проектированию, связанное со зрительным восприятием, слуховым восприятием, обработкой информации, памятью, способностью к ответным действиям и эргономикой, должно быть принято во внимание для повышения безопасности медицинского программного обеспечения. Для оценки соответствия медицинского программного обеспечения основным принципам проектирования [7] могут быть использованы эвристические подходы (см. ZHANG);

c)    управление риском возникновения ошибок эксплуатации. Методы, помогающие управлению рисками возникновения ошибок эксплуатации, представлены в НЕ75. Также рассмотрен процесс менеджмента рисков ошибок эксплуатации. Этот процесс является важной частью структуры человеческих факторов для повышения безопасности медицинского программного обеспечения и дает эффект при интеграции с системами менеджмента рисков;

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

15

Введение

Повышение безопасности пациентов

Безопасность пациентов является одной из основных общемировых проблем в здравоохранении. Как отмечается в публикации ИСОЯК215 «Сводный отчет экспертной группы по качеству обслуживания и безопасности пациента» (1БОЯС215 Summary Report from the Task Force on Patient Safety and Quality) 2010 г., прошло более десяти лет с выпуска фундаментальной публикации в 1999 г. «Человеку свойственно ошибаться: создание более надежной системы здравоохранения» Института медицины (ИМ) [1], [2].

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

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

Информатизация здоровья может как снизить существующие, так и добавить новые

риски обеспечения безопасности пациентов

Информатизация здоровья и связанные с ней электронные медицинские системы имеют значительные возможности для устранения, снижения или ослабления установленных угроз безопасности пациента и качеству обслуживания (см. приложение А) и являются на данный момент объектами для крупных инвестиций в здравоохранение.

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

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

В ИТ-программе Национальной службы здравоохранения Англии (НСЗ) «Connecting for Health» был создан упреждающий процесс управления инцидентами, связанными с безопасностью, для решения вопросов, связанных с безопасностью программного обеспечения [3]. За пятилетний период с 2006 г. по 2010 г. было зарегистрировано и изучено 708 сообщений об инцидентах. Было установлено, что примерно 80 % этих инцидентов представляли некоторую угрозу безопасности пациентов (4.1).

Стандарты, направленные на обеспечение безопасности медицинского программного

обеспечения. Текущие разработки

Вопрос безопасности медицинского программного обеспечения впервые был затронут в ИСО/ТК 215 в 2006 г., когда началась работа над следующими стандартами:

ГОСТ Р 56849-2015

–    ИСО/ТС 25238:2007 Информатизация здоровья. Классификация угроз для безопасности, вызванных медицинским программным обеспечением (ISO/TS 25238:2007 Health informatics — Classification of safety risks from health software), и

–    ИСО/ТО 27809:2007 Информатизация здоровья. Меры обеспечения безопасности пациента при использовании медицинского программного обеспечения (ISO/TR 27809:2007 Health informatics — Measures for ensuring patient safety of health software).

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

В ИСО/ТО 27809 дан обзор классификаций продуктов медицинского программного обеспечения, обсуждаются варианты мер управления, связанные с таким программным обеспечением, схема классификации риска, описанная в ИСО/ТС 25238, а также идентификация национальных и международных стандартов по менеджменту рисков.

В течение многих лет сообщество, образовавшееся вокруг медицинского оборудования, поддерживало разработку стандартов на программное обеспечение в МЭК/ТК 62 ПК А [Общие аспекты электрооборудования, используемого в медицинской деятельности (Common aspects of electrical equipment used in medical practice)], в ИСО/ТК 215 [Информатизация здоровья (Health informatics)] и в ИСО/ТК 210 [Менеджмент качества и соответствующие общие аспекты медицинских приборов (Quality management and corresponding general aspects for medical devices)]. Несколько других технических комитетов ИСО и МЭК, таких как ИСО/МЭК СТК 1 подкомитет 7 [Разработка систем и программного обеспечения (Software and systems engineering)], создавали стандарты по разработке систем и программного обеспечения начиная с конца 1980-х гг.

Действующие в настоящее время стандарты по медицинскому оборудованию сосредоточены на функциональности и испытании установленного медицинского оборудования и включают в себя стандарты на программное обеспечение как медицинский прибор [в МЭК 62304 Медицинское программное обеспечение устройства. Процессы жизненного цикла программного обеспечения (IEC 62304:2006, Medical device software — Software life cycle processes) «программное обеспечение как медицинский прибор» определяется как «система программного обеспечения, которая была разработана с целью включения ее в разрабатываемый медицинский прибор или которая была предназначена для ее самостоятельного использования в качестве медицинского прибора»]. Основные стандарты, разработанные или приведенные в качестве справочного материала, используемые для обеспечения безопасности медицинских приборов и программного обеспечения для медицинских приборов, включают:

-ИСО 13485:2003 Медицинские приборы. Системы менеджмента качества. Требования для целей регулирования (ISO 13485:2003, Medical devices — Quality management systems — Requirements for regulatory purposes);

–    ИСОЯР 14969:2004 Медицинские приборы. Системы менеджмента качества. Руководство по применению ИСО 13485:2003 (ISO/TR 14969:2004, Medical devices — Quality management systems — Guidance on the application of ISO 13485:2003);

–    МЭК 62304:2006 Программное обеспечение медицинских приборов. Процессы жизненного цикла программного обеспечения (IEC 62304:2006, Medical device software — Software life cycle processes);

–    ИСО 14971:2007 Медицинские приборы. Применение менеджмента риска к медицинским приборам (ISO 14971:2007, Medical devices —Application of risk management to medical devices);

–    МЭК/ТО 80001-1:2010 Применение менеджмента рисков для ИТ-сетей с медицинскими приборами. Часть 1. Роли, ответственности и деятельность (IEC 80001-1:2010, Application of risk management for IT networks incorporating medical devices, Part 1 – Roles, responsibilities and activities).

В центре внимания данных стандартов отражена заинтересованность медицинского приборостроения в предпродажных (т. е. проектирование и разработка) стадиях жизненного цикла приборов с программным обеспечением, включая программное обеспечение и медицинские приборы, работающие самостоятельно. Недавнее дополнение МЭК/ТО 80001-1 является признаком растущего внимания к подключению приборов к физической сети.

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

v

медицинского программного обеспечения независимо от того, работает ли оно как медицинское изделие. Настоящий стандарт рассматривает стандарты, которые могут предоставить полезное руководство для покупателей, специалистов по внедрению и пользователей, а также для разработчиков и производителей вплоть до конфигурирования, реализации и текущего использования при любых настройках и условиях работы. Анализ и рекомендации, представленные в настоящем стандарте, указывают, что медицинское программное обеспечение все чаще внедряется и эксплуатируется в сложной среде «экосистемы» или «социально-технологической системы», где программное обеспечение тесно связано с другими системами, технологиями, инфраструктурами и предметными областями (людьми, организациями и внешними условиями) и где оно также должно быть сконфигурировано, чтобы поддерживать локальные клинические и бизнес-процессы.

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

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

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

Кому следует ознакомиться с настоящим стандартом?

Общий вопрос красной нитью проходит через все обсуждения безопасности медицинского программного обеспечения: «Какие стандарты должны использоваться для того, чтобы обеспечить безопасность медицинского программного обеспечения?» Настоящий стандарт предназначен для национальных комитетов-членов и пользователей, которые ищут ответ на этот вопрос.

VI

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информатизация здоровья

РУКОВОДСТВО ПО СТАНДАРТАМ БЕЗОПАСНОСТИ МЕДИЦИНСКОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Health informatics. Guidance on standards for enabling safety in health software

Дата введения — 2016—11—01

1 Область применения

Настоящий стандарт предоставляет руководящие указания для национальных комитетов-членов (НКЧ) и пользователей путем выявления связанного набора международных стандартов, имеющих отношение к разработке, реализации и использованию безопасного медицинского программного обеспечения. Подход, представленный в настоящем стандарте, вместе с отображением стандартов в этом подходе иллюстрирует соответствующие стандарты и их оптимальное применение. Такое отображение ясно демонстрирует, где существуют пробелы и совпадения в стандарте. В частности, настоящий стандарт:

–    определяет связанный набор международных стандартов, которые поддерживают безопасную для пациента (или более безопасную) разработку, внедрение и использование медицинского программного обеспечения;

-дает представление о применимости этих стандартов для достижения оптимальной безопасности медицинского программного обеспечения в рамках методов всеобщего менеджмента риска и менеджмента качества, а также в рамках стадий жизненного цикла и процессов разработки медицинского программного обеспечения;

–    решает вопросы безопасности медицинского программного обеспечения, которые остаются нерассмотренными или дублируются в рассматриваемых стандартах;

–    рассматривает, как эти пробелы и дублирование можно устранить (за короткий или длительный срок) путем пересмотра действующих стандартов или разработки новых.

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

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

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

Издание официальное

2 Термины и определения

В соответствии с целями и задачами настоящего стандарта применены следующие термины с соответствующими определениями:

2.1    общий подход (framework): Неотъемлемая поддерживающая или лежащая в основе структура.

[ИСО 9001:2008]

2.2    степень структурированности (granularity): Уровень сложности или то, до какой степени система поделена на более мелкие части.

Примечание — Несмотря на то что определение для термина «степень структурированности» можно найти в ИСО 17115 Информатизация здоровья. Словарь терминологических систем, оно не касается области применения и контекста настоящего стандарта.

2.3    вред (harm): Смерть, телесное повреждение и/или ущерб, причиненный здоровью или состоянию пациента.

[Руководство ИСО/МЭК 51:1999 измененное]

2.4    опасность (hazard): Потенциальный источник вреда.

[Руководство ИСО/МЭК 51:1999]

2.5    информатизация здоровья (health informatics): Пересечение клинических практик, практик ИМ/ИТ (информационный менеджмент, информационные технологии) и методик управления для достижения наилучшего качества здравоохранения.

Примечание — Информатизация здоровья включает в себя применение информационных технологий для облегчения создания и использования данных, информации и знаний, связанных со здравоохранением. Информатизация здоровья обеспечивает условия и поддерживает все аспекты медицинского обслуживания. [ИСО/ТК215 Отчет рабочей группы организации (Organization Task Force Report) (план) — по материалам www.coachorg.com].

2.6    медицинское программное обеспечение (health software): Программное обеспечение, используемое в здравоохранении, способное оказывать влияние на здоровье и предоставление медицинских услуг субъекту оказания медицинской помощи.

Примечание — Включает следующее:

–    программное обеспечение в исходной форме, которое включает в себя системы, элементы и модули (см. МЭК 62304);

–    связанные системы кодирования, механизмы логического вывода, архетипы и онтологии;

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

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

–    программное обеспечение, которое приобретается на коммерческих и некоммерческих условиях.

2.7    жизненный цикл (lifecycle): Развитие системы, изделия, услуги, проекта или других изготовленных человеком объектов, начиная со стадии разработки концепции и заканчивая выводом из эксплуатации.

Примечание — В ИСО/МЭК 12207 (предыдущая редакция) модель жизненного цикла программного обеспечения определена как «концептуальная основа, используемая для организации и управления развитием, работой, техническим обслуживанием и действиями по выводу из эксплуатации программного обеспечения». В ИСО/МЭК 12207 также отмечается, что «модели жизненного цикла используются для управления развитием программного обеспечения от начала их создания и до прекращения их службы».

[ИСО/МЭК 12207:2008]

2.8    медицинский прибор (medical device): Любой прибор, устройство, приспособление, машина, аппарат, имплантат, лабораторный реагент или калибратор, программное обеспечение, материал или другие подобные или связанные с ними изделия:

а) предполагаемые производителем для применения к человеку, отдельно или в сочетании друг с другом для одной или более заданных целей, таких как:

-диагностика, профилактика, контроль, лечение или облегчение течения заболеваний,

-диагностика, контроль, лечение, облегчение травмы или компенсация последствий травмы,

–    исследование, замещение, изменение или поддержка анатомического строения или физиологических процессов,

ГОСТ P 56849—2015

–    поддержание и сохранение жизни,

–    предупреждение беременности,

–    дезинфекция медицинских приборов,

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

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

Примечания

1    Определение прибора для лабораторных исследований включает, например, реагенты, калибраторы, приборы забора и хранения образцов, контрольные материалы и связанные с этим инструменты и приспособления. Данные, полученные с помощью такого лабораторного диагностического прибора, могут использоваться в целях диагностики, контроля или совместимости. В некоторых юрисдикциях отдельные приборы лабораторной диагностики, включая реагенты и подобные им, могут подчиняться отдельным правилам и положениям.

2    Изделия, которые в некоторых юрисдикциях могут рассматриваться как медицинские приборы, но для которых еще не существует согласованного подхода в этом вопросе, — это:

–    средства помощи инвалидам и людям с ограниченными возможностями;

–    приборы для лечения/диагностики болезней и травм животных;

–    аксессуары для медицинских приборов (см. Примечание 3);

-дезинфицирующие вещества;

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

3    Аксессуары, специально предназначенные производителями для использования совместно с медицинским прибором, для которого они были разработаны, реализующие цели медицинского прибора, должны подчиняться тем же процедурам GHT (Целевая группа глобальной гармонизации), которые применяются к самому медицинскому прибору. Например, аксессуар классифицируется так, как будто он является медицинским прибором. Это может привести к другой классификации аксессуара, отличной от его «исходной» классификации.

4    Компоненты медицинских приборов в общем случае контролируются через систему менеджмента качества производителя и процедуры оценки соответствия прибора. В некоторых юрисдикциях компоненты включаются в определение «медицинский прибор».

[Специальная группа по глобальной гармонизации (GHTF) Исследовательская группа 1: 2005]

2.9    риск (risk): Сочетание вероятности причинения вреда и его последствий.

[ISO 14971:2007]

2.10    применимость риска (risk applicability): Отношение, обоснованность и уместность риска в определенном контексте.

2.11    менеджмент риска (risk management): Систематическое применение менеджмента политик, процедур и методик при выполнении задач по анализу, оцениванию и управлению рисков.

[ИСО 14971:2007]

2.12    распределение риска (risk sharing): Форма обработки риска путем соглашения о распределении риска с другими вовлеченными сторонами.

Примечания

1    Законодательные или нормативные требования могут ограничивать, запрещать или делать обязательным распределение риска.

2    Распределение риска может проводиться с помощью договора страхования или других видов договоров.

3    Степень распределения риска может зависеть от надежности и четкости договоренностей о распределении.

4    Передача риска является формой распределения риска.

[Руководство ИСО 73:2009]

2.13    обработка риска (risk treatment): Процесс преобразования риска.

Примечания

1 Обработка риска может включать:

–    предотвращение риска путем принятия решения не начинать или не продолжать деятельность, которая приводит к риску,

–    принятие или повышение риска с целью реализации возможностей,

–    удаление источника риска,

–    изменение вероятности возникновения,

–    изменение последствий,

–    распределение риска с другим лицом или лицами (включая договоры и финансирование риска) и

–    сохранение за собой риска путем принятия обоснованного решения.

3

2    Обработку риска, который касается негативных последствий, иногда называют «смягчение последствий рисков», «устранение рисков», «предотвращение рисков» и «снижение рисков».

3    Обработка риска может привести к возникновению новых рисков или изменению существующих.

[Руководство ИСО 73:2009]

2.14    безопасность (safety): Отсутствие неприемлемых рисков.

Примечание — Роль медицинского программного обеспечения в способствовании возникновению ятрогенного вреда пациентам может быть прямой (т. е. проект не отвечает требованиям заданного применения) или косвенной (т. е. выполняется соответствие проекта требованиям заданного применения, однако система не настроена должным образом). Для безопасности пациентов это означает снижение риска причинения вреда, связанного с медицинским программным обеспечением до приемлемого минимума. Данный контекст, используемый в определении, находится на стадии активного рассмотрения Всемирной организацией здравоохранения.

[Руководство ИСО/МЭК 51:1999]

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

Примечания

1    Международные стандарты ИСО являются соглашениями. Стандарты ИСО относятся к соглашениям, поскольку члены этой организации должны договориться о содержании и давать формальное одобрение, перед их публикацией. Международные стандарты ИСО разрабатываются техническими комитетами. Члены этих комитетов – представители разных стран. Таким образом, международные стандарты ИСО, как правило, имеют очень широкую поддержку.

2    Стандарты должны основываться на консолидированных результатах науки, техники, опыта и должны быть направлены на достижение оптимальных положительных результатов для сообщества.

[Руководство ИСО/МЭК 2:2004]

2.16    субъект оказания медицинской помощи (subject of саге): Человек, которому должны предоставить, предоставляют или уже предоставили медицинское обслуживание.

Примечание — Субъектом оказания медицинской помощи считается и здоровый человек.

[ИСО 18308:2011]

3    Сокращения

ЕКС    – Европейская комиссия по стандартизации;

ЕКСЭЛ – Европейский комитет по стандартизации в области электротехники;

COCIR – Европейский координационный комитет по радиологической, электромедицинской и медицинской ИТ-отраслям;

АСНЛ    – автоматизированная система назначения лечения;

DICOM – формирование цифровых изображений и обмен ими в медицине;

ЭМА    -электронный медицинский архив;

ЭМК    – электронная медицинская карта;

FDA    – управление по контролю продуктов и лекарств;

GCM    – модель базового компонента;

GHTF – специальная группа по глобальной гармонизации;

ИЗ    – информатизация здравоохранения (медицинская информатика);

ИКТ    – информационно-коммуникационные технологии;

СМИБ -система менеджмента информационной безопасности;

ITIL    -библиотека инфраструктуры информационных технологий;

ЛИС    -лабораторная информационная система;

НСЗ    – национальная служба здравоохранения;

4