Национальный стандарт РФ ГОСТ Р ИСО/ТО 27809-2009 "Информатизация здоровья. Меры по обеспечению безопасности пациента при использовании медицинского программного обеспечения" (утв. приказом Федерального агентства по техническому регулированию и метрологии от 14 сентября 2009 г. N 405-ст)

Health informatics. Measures for ensuring the patient safety of health software

Дата введения - 1 июля 2010 г.

Введен впервые

Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. N 184-ФЗ "О техническом регулировании", а правила применения национальных стандартов Российской Федерации - ГОСТ Р 1.0-2004 "Стандартизация в Российской Федерации. Основные положения"

Сведения о стандарте

1 Подготовлен Федеральным государственным учреждением "Центральный научно-исследовательский институт организации и информатизации здравоохранения Росздрава" (ЦНИИОИЗ Росздрава) и Государственным научным учреждением "Центральный научно-исследовательский и опытно-конструкторский институт робототехники и технической кибернетики" на основе собственного аутентичного перевода на русский язык стандарта, указанного в пункте 4

2 Внесен Техническим комитетом по стандартизации ТК 468 "Информатизация здоровья" при ЦНИИОИЗ Росздрава - единоличным представителем ИСО ТК 215

3 Утвержден и введен в действие приказом Федерального агентства по техническому регулированию и метрологии от 14 сентября 2009 г. N 405-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/ТО 27809:2007 "Информатизация здоровья. Меры по обеспечению безопасности пациента при использовании медицинского программного обеспечения" (ISO/TR 27809:2007 "Health informatics - measures for ensuring patient safety of health software")

5 Введен впервые

Введение

Угроза безопасности пациента

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

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

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

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

- медицинское программное обеспечение потенциально может нанести вред пациентам;

- данная возможность возрастает по мере увеличения сложности внедряемого программного обеспечения;

- организации здравоохранения все больше зависят от медицинского программного обеспечения.

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

В мире существует повышенное внимание к большому числу клинических инцидентов, которые можно было предотвратить, но которые оказали неблагоприятное воздействие на пациентов, включая летальный исход и инвалидность. Это отмечено в разных источниках (см. [1], [2], [3], [4], [5] и [6]). К таким предотвратимым инцидентам относятся неточные или неверные диагнозы и другие решения. Влияющим фактором часто является отсутствие или неполнота информации, или просто незнание, например, о медицинских возможностях в трудных случаях или побочных реакциях на лекарственные препараты.

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

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

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

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

- плохая доказательная база для проектирования;

- ошибки в логике проектирования, не позволяющие правильно представить цели проектирования;

- логические ошибки, не позволяющие представить правильные решения или доказательства на стадии проектирования;

- плохое или запутывающее представление информации или плохие средства поиска;

- проблемы с обновлениями, соответствующими современному уровню знаний.

Некоторые из недостатков таких систем проявляются не сразу и могут быть не заметны для пользователя.

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

Контроль рисков

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

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

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

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

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

Требования настоящего стандарта не распространяются на:

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

- программное обеспечение, являющееся дополнением к медицинскому прибору;

- программное обеспечение, являющееся само по себе медицинским прибором.

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

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

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

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

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

2.1 вред (harm): Смерть, физическая травма и/или повреждение здоровья или самочувствия пациента.

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

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

- необходимо для правильного применения медицинского прибора;

- является дополнением к медицинскому прибору;

- само по себе является медицинским прибором.

Примечание - В настоящем стандарте понятие "программное обеспечение" включает в себя встроенное программное обеспечение.

2.4 изготовитель (manufacturer): Физическое или юридическое лицо, отвечающее за разработку, изготовление, упаковку или маркировку программного продукта для сферы здравоохранения, компоновку системы или адаптацию программного продукта до того, как он будет представлен на рынке и/или введен в эксплуатацию, независимо от того, выполняются ли эти действия самим лицом или третьей стороной по его поручению.

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

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

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

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

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

- поддержание жизни;

- контроль оплодотворения;

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

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

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

Примечание - Данное определение взято из [8]. Однако, в отношении сферы действия программного обеспечения в разных странах существуют некоторые различия в ее определении, которые приведены в приложении А.

2.6 пациент (patient): Любое лицо, к которому применяется программный продукт для сферы здравоохранения.

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

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

2.8 риск (risk): Комбинация вероятности нанесения вреда и серьезности этого вреда [7].

2.9 безопасность (safety): Независимость от недопустимого риска [7].

3 Круг рассматриваемых проблем

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

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

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

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

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

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

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

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

Следует отметить, что будет существовать постоянная потребность разработки стандартов применительно к конкретным рискам (см. раздел 8).

4 Общая информация о средствах контроля медицинских приборов

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

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

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

5 Граница между программными продуктами для сферы здравоохранения и медицинскими приборами

Программное обеспечение, необходимое для правильного применения медицинского прибора либо являющееся дополнением к нему, бесспорно, рассматривается как регулируемое средствами контроля медицинских приборов в ЕС, Австралии, Канаде, США и GHTF. Некоторое программное обеспечение само по себе рассматривается как медицинский прибор.

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

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

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

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

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

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

6 Классификация программных продуктов для здравоохранения

6.1 Возможные варианты

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

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

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

Системы классификации медицинских приборов в ЕС, Австралии, Канаде, США и GHTF не подходят для программных продуктов для сферы здравоохранения.

Классификация "программного обеспечения в медицинских приборах" [9] и "имеющегося на рынке" программного обеспечения [10] Центра по приборам и радиологической безопасности Администрации по контролю за продуктами питания и лекарствами Министерства здравоохранения и социальных служб США может быть применена к программным продуктам для сферы здравоохранения.

Однако в [11] представлена наиболее подходящая система классификации на основе оценки установленных классов риска, представленных в таблице 4 данного документа. Данная классификация не противоречит подходу Центра по приборам и радиологической безопасности Управления по контролю за продуктами питания и лекарствами Министерства здравоохранения и социальных служб США к "программному обеспечению для медицинских приборов" и "имеющемуся на рынке" программному обеспечению.

6.2 Выводы

Если средства контроля должны быть пропорциональны риску, который продукт может представлять для пациента, то программные продукты для сферы здравоохранения следует классифицировать в соответствии сданными рисками. Системы классификации медицинских приборов не подходят для программных продуктов для сферы здравоохранения. Наиболее подходящим представляется подход ИСО, основанный на оценке установленных классов риска и изложенный в [11].

7 Возможные мероприятия по контролю за программными продуктами для сферы здравоохранения

7.1 Обзор

7.1.1 Общие сведения

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

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

- предпродажное извещение с или без предпродажной аттестации;

- регистрация предприятия;

- номенклатура изделий;

- требования к клиническим данным;

- требования к маркировке;

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

- требования к системе качества или производственным нормам с или без проверки;

- контроль проектирования;

- управление рисками.

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

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

7.1.2 Выводы

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

7.2 Маркировка и документация

7.2.1 Общие сведения

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

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

7.2.2 Выводы

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

7.3 Клинические данные

7.3.1 Общие сведения

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

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

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

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

Здесь возможно применение стандарта ИСО по клиническим исследованиям медицинских приборов на людях [14].

7.3.2 Выводы

Если предоставление клинических данных является частью средств контроля над безопасностью программных продуктов для сферы здравоохранения, то должен быть принят содержащий руководящие указания стандарт, являющийся основой и соответствующий характеристикам программных продуктов для сферы здравоохранения, таких как поддержка принятия решений. Такой стандарт должен охватывать как клинические данные, относящиеся к достоверности данных, положенных в основу принятия решений, так и их использование программным обеспечением, а также клинические данные, полученные в результате использования программного продукта. В данном контексте должна быть рассмотрена возможность применения ИСО 14155 [14].

7.4 Регистрация инцидентов

7.4.1 Общие сведения

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

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

- ИСО/ТС 19218:2005 [15];

- GHTF для медицинских приборов [16];

- MedWatch Управления по контролю за продуктами питания и лекарствами;

- общие требования к регистрации Национального агентства по безопасности пациентов Великобритании [17];

- работа, проводимая в Рабочей группе по вопросам фармацевтики и применения лекарств (РГ 6) ТК 215 ИСО, подготовившей проект стандарта по электронной регистрации неблагоприятных реакций на лекарства [18] на основе национальных и международных документов.

7.4.2 Выводы

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

7.5 Системы качества

7.5.1 Общие сведения

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

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

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

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

- документацию, например руководство по качеству и контроль документов и записей;

- ответственность за управление, включая обязательства по управлению, сфокусированность на потребителя, планирование систем политики в области качества и управления качеством;

- распределение ответственностей и полномочий;

- связь;

- управление ресурсами, включая компетенцию, понимание, обучение и рабочую среду;

- обзоры по управлению.

7.5.2 Стандарты по системам качества, относящиеся к медицинским приборам

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

В большинстве Европейских стран изготовители медицинских приборов внедрили систему качества, чтобы соответствовать директиве ЕС по медицинским приборам [19]. Однако в соответствии с установкой ЕС по директивам нового подхода [20], если система качества изготовителя соответствует "гармонизированным стандартам", но не называет их, то она может ссылаться на допущение соответствия. Однако в листинге руководства по директивам для медицинских приборов [21] строка, относящаяся к системам качества, ссылается на документы от GHTF.

Руководство GHTF до июня 2005 г. было включено в документ "Руководство по системам качества для проектирования и производства медицинских приборов" [22], который, в свою очередь, был создан на основе ИСО 9001 (версия 1994 года) [23]. В 2005 г. данное руководство было изъято из обращения и заменено ИСО/ТО 14969:2004 [24], в разработке проекта которого участвовала GHTF. Настоящий стандарт также основан на ИСО 9001.

В США требования "Успешной производственной практики" представлены в "Положении по системам качества" [25]. В предисловии данного документа представлены полученные общественные комментарии и ответы Управления по контролю за продуктами питания и лекарствами. Из приведенных ответов становится ясно, что требования, в основном, основаны на ИСО 9001:1994 [23] и разработаны в тесном сотрудничестве с GHTF. В главе 2 "Системы качества" Руководства по системам качества для медицинских приборов для малых предприятий [26] также отмечено, что требования "Успешной производственной практики" "гармонизированы с ИСО 9001:1994 и ИСО 13485 [27]" (который сам основан на ИСО 9001).

Ситуация в Австралии и Канаде сложилась похожим образом. Их требования к системе качества для медицинских приборов также основаны на серии стандартов ИСО 9000.

Ясно, что если программные продукты для сферы здравоохранения были бы предметом контроля со стороны системы управления качеством, то любой стандарт должен быть основан на ИСО 9001:2000 [28]. Встает вопрос, существует ли уже такой стандарт, который мог бы быть применен непосредственно.

Стандарты, применяемые в отношении медицинских приборов, являются очевидными кандидатами на рассмотрение. Как уже отмечалось, стандартом, который упоминался в контексте "Директивы по медицинским приборам" ЕС, является "Руководство по системам качества" GHTF [22], которое было отозвано и заменено ИСО/TО 14969:2004 "Руководство по применению ИСО 13485:2003" [24]. ИСО 13485:2003 "Системы управления качеством. Требования к целям регулирования" [27] является, как видно из наименования, специально разработанным документом для "целей регулирования" и посвящен медицинским приборам. Он не может подходить для программных продуктов для сферы здравоохранения по двум причинам:

- хотя его определение "медицинского прибора" соответствует GHTF и тем самым включает "программное обеспечение" (см. А.3), совершенно очевидно, что данный стандарт разрабатывался без учета программных продуктов для сферы здравоохранения;

- данный стандарт разработан для целей регулирования, тогда как настоящий стандарт не основан на предположении, что средства контроля не обязательно будут средствами регулирования; ряд дополнений и поправок к ИСО 9001 в ИСО/ТО 14969:2004 [24] и ИСО 13485:2003 [27], может не поддерживаться в нерегулируемой среде.

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

7.5.3 Стандарты по системам качества, относящиеся к программному обеспечению

Другим возможным подходом к стандарту по программным продуктам для сферы здравоохранения на основе ИСО 9001 является рассмотрение существующих стандартов, основанных на ИСО 9001, которые в общем случае применимы к программному обеспечению. Очевидным претендентом на применение является ИСО/МЭК 90003:2004 "Руководства по применению ИСО 9001:2000 к программному обеспечению компьютеров" [29].

Данный стандарт, в свою очередь, ссылается на ряд стандартов ИСО/МЭК, в частности, на ИСО/МЭК 12207:1995, "Процессы жизненного цикла программного обеспечения" [30], поправку к нему 2002 г. [31] и руководство по его применению ИСО/МЭК ТО 15271 [32].

Стандарт ИСО/МЭК 9003:2004 мог бы непосредственно быть применен к программным продуктам для сферы здравоохранения и, таким образом, мог бы стать выбранным из существующих стандартов. Его возможным недостатком является отсутствие ссылок на стандарты для медицинских приборов, основанные на ИСО 9001.

7.5.4 Выводы

Если одним из средств контроля для обеспечения безопасности программных продуктов для сферы здравоохранения является требование к системе управления качеством, то все необходимые стандарты должны быть основаны на ИСО 9001:2000 [28].

Если устанавливается, что требуется новый стандарт, регулирующий программные продукты для сферы здравоохранения, то он должен быть создан на основе рассмотрения ИСО/МЭК 90003:2004 [29]:

- в качестве возможного претендента без каких-либо поправок;

- в качестве исходного материала с возможными поправками, отражающими специфику программных продуктов для сферы здравоохранения (с учетом требований к медицинским приборам, установленным в ИСО 13485:2003 [27] и связанным с ним руководством ИСО/ТО 14969:2004 [24]).

7.6 Контроль проектирования

7.6.1 Общие сведения

Контроль проектирования включен в большинство законодательных подходов.

В ЕС имеются рекомендации по контролю проектирования, основанные на документах GHTF. Руководство GHTF до июня 2005 г. содержалось в документе "Руководство по контролю проектирования для изготовителей медицинских приборов" [33]. В 2005 г. это руководство было изъято из обращения и заменено ИСО/ТО 14969:2004 "Системы управления системами качества. Руководство по применению ИСО 13485:2003" [24]. Оно, по сути, заменило 44 страницы руководства на 8 страниц ИСО/ТО 14969:2004, раздел 7. Это привело к потере некоторых деталей.

Австралия и Канада применяют подход, аналогичный подходу GHTF.

В США Администрация по контролю за продуктами питания и лекарствами выпустила "Руководство по контролю проектирования для производителей медицинских приборов" [34]. Оно имеет отношение к Правилам 820.30 по "Контролю проектирования" и разделу 4.4 ИСО 9001:1994. Данное руководство охватывает те же аспекты, что и руководство GHTF, а именно:

- планирование проектирования и разработки;

- исходные данные для проектирования;

- экспертизу проекта;

- верификацию проекта;

- аттестацию проекта;

- передачу проекта;

- изменения проекта;

- документирование истории проекта.

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

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

- некоторые требования могут быть применены к программному обеспечению с изменениями;

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

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

7.6.2 Выводы

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

7.7 Управление рисками

7.7.1 Общие сведения

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

- процессы "управление рисками на предприятиях";

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

- другие области, например управление информационной безопасностью.

7.7.2 Выводы

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

- специально для программных продуктов для сферы здравоохранения необходим новый стандарт, согласованный на высшем уровне с ИСО 31000 [35], ИСО 14971 [36], МЭК 61508-3 [37] и МЭК 61508-5 [38]. Данный стандарт должен реализовывать положения, изложенные в GHTF/SG3/NI5R8 [39], и быть основан на опыте использования CRAMM [40] совместно с ИСО/МЭК 17799 [65];

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

8 Стандарты, относящиеся к рискам определенного характера

8.1 Общие сведения

Конкретный программный продукт для сферы здравоохранения или программные продукты для сферы здравоохранения вообще могут быть объектами рисков определенного характера. Примерами, применимыми к большинству программных продуктов для сферы здравоохранения, и для которых существуют стандарты ИСО и/или CEN, относящиеся к программным продуктам для сферы здравоохранения, являются следующие:

- безопасность в контексте защиты личной информации;

- аутентификация медицинских работников;

- правильная однозначная идентификация пациентов.

8.2 Выводы

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

9 Надзор за безопасностью и рисками в сфере деятельности пользователя

9.1 Общие сведения

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

9.2 Выводы

Необходимо обратить внимание на стандарты по обеспечению безопасности программных продуктов для сферы здравоохранения в сфере деятельности пользователя.

10 Систематизация

10.1 Общие сведения

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

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

- процессы (дозирование лекарств);

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

10.2 Выводы

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

11 Общие выводы

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

11.1 Если средства контроля должны быть адекватны риску, который программный продукт может представлять для пациента, то программные продукты для сферы здравоохранения классифицируют в соответствии сданными рисками. Системы классификации медицинских приборов не подходят для программных продуктов для сферы здравоохранения. ИСО/ТС 25238 "Классификация угроз безопасности от медицинского программного обеспечения" [11] наиболее подходит для принятия определенных в нем классов рисков (см. [11], таблица 4).

11.2 Если требуются предпродажное извещение, регистрация предприятия или продукта, то, по-видимому, они не потребуют разработки стандартов (см. 7.1).

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

11.4 Предоставление клинических данных может потребоваться некоторым программным продуктам для сферы здравоохранения, например для поддержки принятия решений с наивысшим риском. Если это так, то желательно иметь стандарт в форме руководства, конкретизированного под программные продукты для сферы здравоохранения. Такой стандарт должен охватывать как клинические данные, относящиеся к достоверности данных, положенных в основу принятия решений, так и их использование программным обеспечением, а также клинические данные, полученные в результате использования программного продукта. В данном контексте должна быть рассмотрена возможность применения ИСО 14155 [14] (см. 7.3).

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

11.6 Если одним из средств контроля для обеспечения безопасности программных продуктов для сферы здравоохранения является требование к системе управления качеством (см. 7.5), то все необходимые стандарты должны быть основаны на ИСО 9001:2000 [28]. Если устанавливается, что требуется новый стандарт, регулирующий программные продукты для сферы здравоохранения, то он должен быть создан на основе рассмотрения ИСО/МЭК 90003:2004 [29]:

- в качестве возможного претендента без каких-либо поправок;

- в качестве исходного материала с возможными поправками, отражающими специфику программных продуктов для сферы здравоохранения (с учетом требований к медицинским приборам, установленным в ИСО 13485:2003 [27] и связанным с ним руководством ИСО/ТО 14969:2004 [24]).

11.7 Если контроль проектирования должен быть частью требований для обеспечения безопасности программных продуктов для сферы здравоохранения, то должна быть рассмотрена необходимость разработки стандарта непосредственно для программных продуктов для сферы здравоохранения (см. 7.6). Поскольку подобный стандарт должен базироваться на основных требованиях, содержащихся в стандартах по контролю проектирования медицинских приборов [24], [33], [34], то эти требования должны быть адаптированы к программным продуктам для сферы здравоохранения и учитывать специфичные потребности, такие как контроль алгоритмов и использование клинических данных в программных продуктах, например в системах поддержки принятия решений.

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

- специально для программных продуктов для сферы здравоохранения необходим новый стандарт, согласованный на высшем уровне с ИСО 31000 [35], ИСО 14971 [36], МЭК 61508-3 [37] и МЭК 61508-5 [38]. Данный стандарт должен реализовывать положения, изложенные в GHTF/SG3/NI5R8 [39], и быть основан на опыте использования CRAMM [40] совместно с ИСО/МЭК 17799 [65];

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

11.9 Если для рисков определенного характера существуют стандарты, то программные продукты должны проектироваться в соответствии сданными стандартами.

11.10 Необходимо обратить внимание на стандарты по обеспечению безопасности программных продуктов для сферы здравоохранения в среде пользователя.

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

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

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

[1]	Kohn, I.T., Corrigan, J.M. and Donaldson, M.S., To Err is Human: Building a Safer Health System, USA Institute of Medicine, National Academy Press, 1999
[2]	An Organisation with a Memory, HMSO, June, 2000
[3]	Quality in Australian Healthcare, Study, 1994
[4]	Brennan, T.A., Leape, I.I., Laird, N.M., Herbert, I., Localio, A.R. and Lawthers, A.G., Incidents of adverse events and negligence in hospitalised patients, results of the Harvard Medical Practice Study, New England J Med., 324, 1991, pp. 370 - 376
[5]	Quality of care: patient safety, Report of the WHO Secretariat, EB 109/9, 5 December, 2001
[6]	Building a safer NHS for Patients, UK Department of Health, April, 2001
[7]	ISO/IEC Guide 51:1999, Safety aspects - Guidelines for their inclusion in standards
[8]	Information document concerning the definition of the term "Medical Device", Final document GHTF/SG1/N29R16:2005, GHTF Study Group 1, the Global Harmonization Task Force, 29 June, 1999
[9]	Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, Center for Devices and Radiological Health, Food and Drug Administration, US Department of Health and Services, 11 May, 2005
[10]	Off-the-Shelf Software Use in Medical Devices, Guidance, Center for Devices and Radiological Health, Food and Drug Administration, US Department of Health and Services, 9 September, 1999
[11]	ISO/TS 25238 Health informatics - Classification of safety risks from health software
[12]	CEN/TS 15260:2006 Health informatics - Classification of safety risks from health informatics products
[13]	EN 1041:1998 Information supplied by the manufacturer with medical devices
[14]	ISO 14155 (both parts) Clinical investigation of medical devices for human subjects
[15]	ISO/TS 19218:2005, Medical devices - Coding structure for adverse event type and cause
[16]	Adverse Event Reporting Guidance for the Medical Device Manufacturer or its Authorized Representative, Final Document GHTF/FD:99-7, GHTF Study Group 2, the Global Harmonization Task Force, 29 June, 1999
[17]	UK National Patient Safety Agency, http://www.npsa.nhs.uk
[18]	ISO/TS 22224, Health informatics - Electronic Reporting of adverse drug reactions
[19]	Council Directive 93/42/EEC of 14 June, 1993, Concerning medical devices
[20]	Guide to the implementation of directives based on the New Approach and the Global Approach, European Commission, Luxembourg, Office for Official Publications of the European Communities, 2000, ISBN 92-828-7500-8
[21]	http://europa.eu.int/comm/enterprise/medical_devices/meddev/index.htm
[22]	Guidance on Quality Systems for the Design and Manufacture of Medical Devices, GHTF.SG3.N99-8, Global Harmonization Task Force, 29 June, 1999
[23]	ISO 9001:1994 Quality systems - Model for quality assurance in design, development, production, installation and servicing
[24]	ISO/TR 14969:2004 Medical devices - Quality management systems - Guidance on the application of ISO 13485:2003
[25]	Quality System Regulations, 21 CFR Part 820 (Federal Register, October 7, 1996, Part VII 21 CFR Parts 808, 812 and 820 Medical Devices; Current Good Manufacturing Practice (CGMP); Final Rule)
[26]	Medical Device Quality Systems Manual: A Small Entity Compliance Guide, Center for Devices and Radiological Health, FDA, December, 1996
[27]	ISO 13485:2003, Medical devices - Quality management systems - Requirements for regulatory purposes
[28]	ISO 9001:2000, Quality management systems - Requirements
[29]	ISO/IEC 90003:2004, Software engineering - Guidelines for the application of ISO 9001:2000 to computer software
[30]	ISO/IEC 12207:1995, Information technology - Software life cycle processes
[31]	ISO/IEC 12207:1995/Amd.1:2002, Information technology - Software life cycle processes Amendment 1
[32]	ISO/IEC TR 15271:1998, Information technology - Guide for ISO/IEC 12207 (Software Life Cycle Processes)
[33]	Design Control Guidance for Medical Device Manufacturers, GHTF.SG3.N99-9, Global Harmonization Task Force, 29 June, 1999
[34]	Design Control Guidance for Medical Device Manufacturers, Center for Devices and Radiological Health, FDA, 11 March, 1997
[35]	ISO 31000 General guidelines for principles and implementation of risk management
[36]	ISO 14971:2007, Medical devices - Application of risk management to medical devices
[37]	IEC 61508-3:1998, Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 3: Software Requirements
[38]	IEC 61508-5:1998, Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 5: Examples of methods for the determination of safety integrity levels
[39]	GHTF/SG3/NI5R8, Global Harmonization Task Force Study Group 3, Risk Management Principles and Quality Management Systems, May, 2005
[40]	CRAMM, UK Government's Preferred Risk Analysis and Management Method for Information Security Management, January, 2003
[41]	Council Directive 90/385/EEC of 20 June 1990 on the approximation of the laws of the Member States relating to active implantable medical devices
[42]	Council Directive 98/79/EC of the European Parliament and of the Council of 27 October 1998 on in-vitro diagnostic medical devices
[43]	Therapeutic Goods Act 1989 as amended by the Therapeutic Goods Amendment (Medical Devices) Bill 2002 and the Therapeutic Goods (Medical Devices) Regulations 2002 [known as Therapeutic Goods Amendment (Medical Devices) Act 2002]
[44]	Australian Medical Devices Guidelines: An Overview of the New Medical Devices Regulatory System, Guidance Document Number 1, Version 1.6, Therapeutic Goods Administration, Department of Health and Ageing, 23 May, 2003
[45]	Differences between the Australian and European Union regulatory systems (1), Fundamental differences and classification, Fact Sheet, Draft for comment, Therapeutic Goods Administration, Australian Department of Health and Ageing, December, 2004
[46]	Differences between the Australian and European Union regulatory systems (2), Essential principles, Fact Sheet, Draft for comment, Therapeutic Goods Administration, Australian Department of Health and Ageing, April, 2005
[47]	Medical Devices Regulations, 1998 of the Food and Drugs Act
[48]	Medical Device Compliance and Enforcement Directive, Health Products and Food Branch Inspectorate, Health Canada, 11 February, 2004
[49]	Guidance for the Risk-based Classification System, Draft, GD006, Therapeutic Products Directorate, Medical Devices Bureau, Health Canada, 4 May, 1998
[50]	Guidance for the Risk-based Classification System of In Vitro Diagnostic Devices, Draft, GD007, Therapeutic Products Directorate, Medical Devices Bureau, Health Canada, 17 March, 1998
[51]	Keyword Index To Assist Manufactures In Verifying The Class of Medical Devices, Therapeutic Products Programme, Licensing Services Division, Medical Devices Bureau, Health Canada
[52]	Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, Center for Devices and Radiological Health, Food and Drug Administration, US Department of Health and Human Sciences, 11 May, 2005
[53]	Off-The-Shelf Software Use in Medical Devices, Center for Devices and Radiological Health, Food and Drug Administration, US Department of Health and Human Sciences, 9 September, 1999
[54]	General Principles of Software Validation; Final Guidance for Industry and FDA staff, Center for Devices and Radiological Health, Food and Drug Administration, US Department of Health and Human Sciences, 11 January, 2002
[55]	Principles of Medical Devices Classification, Proposed Document SG1/N015R22, GHTF Study Group 1, the Global Harmonization Task Force, 17 November, 2003
[56]	The Classification Rules, Bulletin Number 10, UK Medical Devices Agency (now UK Medicines and Healthcare products Regulatory Agency), February, 1995
[57]	Classification of Medical Devices, Guidance Document Number 25, Therapeutic Goods Administration, Australian Department of Health and Ageing, January, 2005
[58]	PD 6668, Managing Risk for Corporate Governance, British Standards Institution, November, 2000
[59]	AS/NZS 4360:2004, Risk Management, Standards Australia Institute
[60]	World Standards Cooperation Healthcare Technology Task Force (HTTF), Final Report, January, 2006
[61]	IEC 62304:2004 Medical device software - Software life cycle processes
[62]	Australian Medical Devices Guidelines - Conformity Assessment Procedures, Guidance Document Number 3, Version 1.5, Therapeutic Goods Administration, Australia, 23rd May, 2003
[63]	Medical Device Compliance and Enforcement Directive, Health Canada, 11th February, 2004
[64]	ISO/IEC 27001:2005 Information technology - Security techniques - Information security management systems - Requirements
[65]	ISO/IEC 17799 Information technology - Security techniques - Code of practice for information security management
[66]	ISO/IEC 27005 Information technology - Security techniques - Information security risk management
[67]	IEC 60601-1-4, Medical electrical equipment - Part 1-4: General requirements for safety - Collateral Standard: Programmable electrical medical systems
[68]	EN 1441, Medical devices - Risk analysis
[69]	BS 7799-3, Information security management systems - Guidelines for information security risk management