1
Доступно поисковых запросов: 1 из 2
Следующий пробный период начнётся: 09 февраля 2023 в 13:25
Снять ограничение

ГОСТ Р 57301-2016

Информатизация здоровья. Требования защиты и конфиденциальности систем EHR, используемые при оценке соответствия
Действующий стандарт
Проверено:  01.02.2023

Информация

Название Информатизация здоровья. Требования защиты и конфиденциальности систем EHR, используемые при оценке соответствия
Название английское Health informatics. Security and privacy requirements of EHR systems for use in conformity assessment
Дата актуализации текста 01.01.2021
Дата актуализации описания 01.01.2023
Дата издания 20.01.2017
Дата введения в действие 01.01.2018
Область и условия применения Настоящий стандарт распространяется на системы электронных карт пациента в пунктах медицинского обслуживания, которые обеспечивают взаимодействие с системами EHR. Аппаратные средства и средства управления технологическим процессом не входят в область применения. Настоящий стандарт рассматривает проблемы их безопасности и защиты конфиденциальности путем предоставления ряда требований безопасности и конфиденциальности, наряду с руководством и передовыми практическими методами для оценки соответствия
Опубликован Официальное издание. М.: Стандартинформ, 2017 год
Утверждён в Росстандарт

     
ГОСТ Р 57301-2016/
ISO/TS 14441:2013

     

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

ИНФОРМАТИЗАЦИЯ ЗДОРОВЬЯ

Требования защиты и конфиденциальности систем EHR, используемые при оценке соответствия

Health informatics. Security and privacy requirements of EHR systems for use in conformity assessment

ОКС 35.240.80

Дата введения 2018-01-01

     

Предисловие

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

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

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

4 Настоящий стандарт идентичен международному документу ISO/TS 14441:2013* "Информатизация здоровья. Требования безопасности и конфиденциальности, используемые при оценке соответствия систем EHR" (ISO/TS 14441:2013 "Health informatics - Security and privacy requirements of EHR systems for use in conformity assessment", IDT).

________________

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


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

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


Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

В связи с развитием местных, региональных и национальных информационных структур электронного учета здоровья системы электронных карт пациента используются во многих местах оказания медицинской помощи, которые посещают пациенты [клинические системы пункта обслуживания (point of service, POS)]. Помимо таких учреждений, как больницы, в которых системы, установленные в различных отделениях (например, сестринский пост), как правило, интегрированы в карту отдельного пациента, небольшие системы специального назначения, например электронные медицинские карты (Electronic Health Record, EHR), также используются во врачебных кабинетах и других необщественных учреждениях, например относящихся к здравоохранению населения, в которых сложность систем и местной инфраструктуры поддержки ИТ значительно ниже. Так как страны начинают объединять такие системы медицинского обслуживания с инфоструктурами EHR (или же напрямую обмениваться клиническими данными с другими клиническими системами POS посредством связи "система - система"), безопасность и конфиденциальность этих систем становится гораздо более важной и сложной задачей, чем в случаях, когда системы работают автономно или не связаны с другими системами. Для обеспечения надлежащей реализации требуемых стандартов в этих системах, чтобы они могли безопасно взаимодействовать с инфоструктурами EHR и сохранять конфиденциальность информации о пациентах, многие страны используют программы сертификации и проверки соответствия с целью обеспечения объективного свидетельства соответствия этим требованиям.

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

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

Доступ к системе разрешен только уполномоченным и зарегистрированным пользователям. Такими пользователями являются:

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

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

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

- аудиторы, которые изучают аудиторские следы;

- другие системы EHR, которые вводят и принимают данные;

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

К совместимым клиническим системам POS применяются следующие основные допущения:

- объект оценки (TOE) может включать в себя коммерчески доступное (COTS), государственное, запатентованное и бесплатное программное обеспечение (ПО), а также ПО с открытым исходным кодом;

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

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

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

- надлежащее управление системой защиты выполняется в процессе установки эксплуатации системы.

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

Настоящий стандарт включает в себя:

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

- обзор теоретической базы требований;

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

- описание процесса оценки соответствия, включающее ключевые понятия и технологии.

В приложении А предоставлены более подробная информация о моделях и процессах оценки соответствия, а также примеры программ оценки соответствия в четырех странах (на период 2010 г.).

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

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

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

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

Стандарт ИСО/МЭК 15408 (все части) определяет "объект оценки" для оценки безопасности продуктов ИТ. Настоящий стандарт включает перекрестное сопоставление 82 требований безопасности и конфиденциальности в соответствии с категориями общих критериев в ИСО/МЭК 15408 (все части). Клиническое программное обеспечение пунктов обслуживания (POS), как правило, является частью большей системы, например, функционирует на основе операционной системы, таким образом, оно должно работать совместно с другими компонентами для обеспечения надлежащего уровня безопасности и конфиденциальности. Несмотря на то что профиль защиты (РР) включает в себя требования к функциям безопасности компонентов для поддержки служб безопасности системы, он не определяет протоколы и стандарты для оценки соответствия и не затрагивает требований конфиденциальности.

Настоящий стандарт сосредоточен на двух основных вопросах:

a) Требования безопасности и конфиденциальности (раздел 5). Раздел 5 является техническим и предоставляет исчерпывающий набор 82 требований, необходимых для защиты (информации, пациентов) от основных видов риска, рассматривает вопросы безопасности и конфиденциальности мест оказания медицинской помощи, совместимых клинических (электронная карта пациента) систем. Данные требования применимы при оценке соответствия.

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

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

     2 Нормативные ссылки

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

_______________

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


ISO/IEC 17000, Conformity assessment - Vocabulary and general principles (Оценка соответствия. Словарь и общие принципы)

ISO 27799:2008, Health informatics - Information security management in health using ISO/IEC 27002 (Информатизация здоровья. Менеджмент информационной безопасности в здравоохранении по стандарту ИСО/МЭК 27002)

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

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

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

[ИСО 15489-1:2001, статья 3.2]

Примечание - Требуется, чтобы все пользователи ПМД были доступны прослеживанию.

3.2 контроль доступа (access control): средство, благодаря которому доступ к ресурсам системы обработки данных разрешен только авторизованным лицам и осуществляется установленным способом.

[ИСО/МЭК 2382-8:1998, статья 08.04.01]

3.3 орган по аккредитации (accreditation body): Авторитетный орган, который проводит аккредитацию.

Примечание - Как правило, орган по аккредитации получает полномочия от правительства.


[ИСО/МЭК 17000:2004, статья 2.6]

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

[ИСО/TS 25237:2008, статья 3.2]

3.5 ресурс (asset): Все, что представляет ценность для организации.

Примечания

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

2 По ИСО/МЭК 27000:2012, статья 2.4.

3.6 гарантия (assurance): Результат набора методов соответствия, с помощью которого организация достигает доверия в статусе управления информационной безопасностью.

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

Примечания

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

2 См. также область аттестации (scope of attestation).

3 По ИСО/МЭК 17000:2004, статья 5.2.

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

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


[ИСО/МЭК 17000:2004, статья 4.4]

3.9 готовность (availability): Свойство быть доступным и готовым к использованию по запросу авторизованного субъекта.

[ИСО/МЭК 27000:2012, статья 2.10]

3.10 сертификация (certification): Аттестация, проводимая третьей стороной, относящаяся к продукции, процессам, системам или лицам.

Примечание - По ИСО/МЭК 17000:2004, статья 5.5.

3.11 соответствие (compliance): Действие, направленное на то, что необходимо для выполнения установленного требования.

3.12 конфиденциальность (confidentiality): Свойство, при котором информация недоступна или закрыта для неавторизованных лиц, субъектов или процессов.

[ИСО 7498-2:1989, статья 3.3.16]

3.13 оценка соответствия (conformity assessment): Доказательство того, что заданные требования, относящееся к продукции, процессу, системе, лицу или организации, выполнены.

Примечание - По ИСО/МЭК 17000:2004, статья 2.1.

3.14 система оценки соответствия (conformity assessment system): Правила, процедуры и руководство для выполнения оценки соответствия.

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


[ИСО/МЭК 17000:2004, статья 2.7]

3.15 субъект данных (data subject): Лицо, к которому относятся данные.

Примечание - В настоящем стандарте термин "субъект данных" относится к отдельному лицу (в отличие от группы лиц).

3.16 субъект (entity): Физическое или юридическое лицо, орган власти, учреждение или любой другой орган.

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

3.17 деятельность по оценке соответствия первой стороной (first-party conformity assessment activity): Деятельность по оценке соответствия, которую осуществляют лицо или организация, представляющие объект.

Примечания

1 См. также деятельность по оценке соответствия второй стороной и деятельность по оценке соответствия третьей стороной.

2 По ИСО/МЭК 17000:2004, статья 2.2.

3.18 медицинская информационная система (health information system): Хранилище информации о здоровье субъекта получения медицинской помощи в форме, удобной для обработки вычислительной машиной, надежно хранящейся, передаваемой и доступной нескольким зарегистрированным пользователям.

[ИСО 27799:2008, статья 3.1.2]

Примечания

1 Она имеет общепринятую логическую информационную модель, которая не зависит от систем EHR (электронная медицинская карта).

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

3.19 медицинская помощь (healthcare): Любые виды услуг, оказываемые специалистами или средним медицинским персоналом, влияющие на состояние здоровья.

[Европейский парламент, 1998, согласно ВОЗ]

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

Примечание - По ИСО/ТР 20514:2005, статья 2.21.

3.21 специалист здравоохранения (health professional): Лицо, уполномоченное авторитетным органом на осуществление определенной медицинской деятельности.

Примечания

1 По материалам ИСО 17090-1:2008, статья 3.1.8.

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

3.22 идентичность (identity): Набор атрибутов, которые позволяют распознать, связаться или обнаружить объект оказания помощи.

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

[Директива 95/46/ЕС Европейского парламента и Совета от 24 октября 1995 г. по вопросам защиты отдельных лиц в области обработки персональных данных и свободного перемещения таких данных]

3.24 идентификация (identification): Опознание лица в определенном домене с помощью набора его или ее атрибутов.

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

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

[Основано на определении конфиденциальности из "Общепринятых принципов сохранения конфиденциальности" Американского института дипломированных бухгалтеров-ревизоров и дипломированных бухгалтеров Канады]

3.27 защита информации (information security): Сохранение конфиденциальности, целостности и доступности информации.

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


[ИСО/МЭК 27000:2012, статья 2.30]

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

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


[ИСО/МЭК 17000:2004, статья 4.3]

3.29 персональные данные о состоянии здоровья; ПМД (personal health information; PHI): Информация о распознаваемом лице, которая относится к физическому или психическому здоровью отдельного лица или к оказанию медицинских услуг отдельному лицу.

Примечания

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

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

3.30 Разглашение ПМД (PHI disclosure): Разглашение или предоставление доступа к персональным медицинским данным.

Примечание - По материалам ИСО/ТС 25237:2008, статья 3.20.

3.31 клиническая система пунктов обслуживания; POS (point-of-service; POS clinical system): Система, которая используется в пунктах оказания медицинской помощи или медицинских услуг объекту оказания помощи.

Пример - Электронная медицинская карта (EMR), Система фармацевтического менеджмента (PMS), Больничная информационная система (HIS), Информационная система общественного здравоохранения (PHIS).

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

3.33 управление конфиденциальностью (privacy control): Технические и организационные меры, направленные на снижение рисков, которые могут привести к нарушению конфиденциальности.

Примечания

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

2 Термин "управление" также используется в качестве синонима терминов "мера безопасности" или "контрмера".

3.34 политика конфиденциальности (privacy policy): Спецификация целей, правил, обязанностей и средств контроля конфиденциальности применительно к обработке персональных данных о состоянии здоровья в отдельной ситуации.

3.35 предпочтения конфиденциальности (privacy preferences): Конкретный или предполагаемый выбор, сделанный лицом касательно того, как должны обрабатываться его/ее персональные данные о состоянии здоровья.

3.36 принципы конфиденциальности (privacy principles): Набор общих значений, регулирующих защиту конфиденциальности ПМД при обработке в системах ИКТ.

3.37 оценка риска для конфиденциальности (privacy risk assessment): Анализ рисков нарушения конфиденциальности, возникающих в планируемой операции обработки.

Примечание - Данный анализ, также известный как оценка последствий нарушения конфиденциальности, обеспечивается с целью: а) обеспечения соответствия обработки применимым правовым, нормативным требованиям и требованиям политики в отношении конфиденциальности; b) определения рисков и результатов обработки ПМД; с) изучения и оценки средств контроля конфиденциальности и альтернативных процессов обработки ПМД с целью снижения выявленных рисков нарушения конфиденциальности.

3.38 требования к обеспечению безопасности конфиденциальности (privacy safeguarding requirements): Критерии, выполнение которых необходимо при реализации средств контроля конфиденциальности, предназначенных для содействия снижению рисков нарушения конфиденциальности.

3.39 процедура (procedure): Установленный способ осуществления деятельности или процесса.

[ИСО 9000:2005, статья 3.4.5]

3.40 обработка ПМД (processing of PHI): Любые действия или набор действий, выполняемых с ПМД (например, сбор, хранение, управление доступом, анализ, объединение, передача, разглашение или задержка).

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

3.42 продукт (product): Результат процесса.

Примечания

1 Четыре общие категории продукции указаны в ИСО 9000:2005: сервисы (например, транспорт); программное обеспечение (например, компьютерная программа, словарь); техническое обеспечение (например, мотор, механическая деталь); обработанные материалы (например, смазочный материал). Большинство продуктов включают элементы, принадлежащие к различным общим категориям продукта. Продукт называется сервисом, программным обеспечением, техническим обеспечением или обрабатываемым материалом в зависимости от преобладающего элемента.

2 Заключение о соответствии может рассматриваться как продукт аттестации.

3 По ИСО 9000:2005, статья 3.4.2.

3.43 псевдонимизация (pseudonymization): Процесс, применяемый к ПМД, который заменяет информацию об идентификационных данных псевдонимом.

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

3.44 проверка (review): Контроль пригодности, соответствия и эффективности действий выбора и определения, а также результатов этих действий в отношении выполнения установленных требований объектом оценки соответствия.

[ИСО/МЭК 17000:2004, статья 5.1]

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

Примечание - По ИСО 73:2009, статья 1.1.

3.46 оценка риска (risk assessment): Целостный процесс анализа и оценки риска.

Примечание - По ИСО 73:2009, статья 3.4.1.

3.47 управление риском (risk management): Скоординированные действия по руководству и управлению организацией в области риска.

[Руководство ИСО 73:2009, статья 2.1]

Примечание - Управление риском, как правило, включает в себя оценку риска, обработку риска, принятие риска, информирование о рисках, мониторинг риска и проверку риска.

3.48 обработка риска (risk treatment): Процесс выбора и реализации мер по модификации риска.

Примечание - По ИСО 73:2009, статья 3.8.1.

3.49 отбор образцов (sampling): Предоставление образцов объекта оценки соответствия согласно процедуре.

[ИСО/МЭК 17000:2004, статья 4.1]

3.50 область подтверждения соответствия (scope of attestation): Диапазон или характеристики объектов оценки соответствия, охватываемые подтверждением соответствия.

[ИСО/МЭК 17000:2004, статья 5.3]

3.51 деятельность по оценке соответствия второй стороной (second-party conformity assessment activity): Деятельность по оценке соответствия, которую осуществляют лицо или организация, заинтересованные в объекте как пользователи.

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


[ИСО/МЭК 17000:2004, статья 2.3]

3.52 установленные требования (specified requirement): Заявленные потребности или ожидания.

Примечание - Требования могут быть установлены в нормативных документах, таких как регламенты, стандарты и технические условия.


[ИСО/МЭК 17000:2004, статья 3.1]

3.53 объект получения медицинской помощи, пациент (subject of care, patient): Одно или несколько лиц, планирующих получить, получающих или получивших медицинские услуги.

Примечание - По ИСО 18308:2011, статья 3.47.

3.54 целостность системы (system integrity): Свойство, при котором система выполняет предусмотренные для нее функции без нарушений, преднамеренного или случайного вмешательства, осуществляемого неавторизованным пользователем.

[ИСО 27799:2008, статья 3.2.14]

3.55 объект оценки (target of evaluation, TOE): Совокупность программного, программно-аппаратного и/или аппаратного обеспечения, возможно, сопровождаемая руководством.

[ИСО/МЭК 15408-1:2009, статья 3.1.72]

3.56 проведение испытаний (testing): Определение одной или более характеристик объекта оценки соответствия согласно процедуре.

Примечание - Термин "проведение испытаний" обычно относится к материалам, продукции или процессам.


[ИСО/МЭК 17000:2004, статья 4.2]

3.57 деятельность по оценке соответствия третьей стороной (third-party conformity assessment activity): Деятельность по оценке соответствия, которую осуществляют лицо или орган, независимые от лица или организации, представляющих объект, и от пользователя, заинтересованного в этом объекте.

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


[ИСО/МЭК 17000:2004, статья 2.4]

3.58 угроза (threat): Возможная причина нежелательного происшествия, которое может привести к нанесению ущерба системе или организации.

[ИСО/МЭК 27000:2012, статья 2.77]

3.59 уязвимость (vulnerability): Неустойчивость ресурса или контроль, который может быть использован угрозой.

     4 Сокращения

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

EHR - электронный учет здоровья;

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

ПМД - персональные медицинские данные;

POS - пункт обслуживания;

РР - профиль защиты.

     5 Требования безопасности и конфиденциальности

     5.1 Общие положения

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

     5.2 Теоретические основы

5.2.1 Общее описание

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

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

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

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

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

Основную ценность представляет информация. Медицинские данные включают:

a) персональную медицинскую и идентификационную информацию;

b) анонимные данные, выведенные из персональных данных о состоянии здоровья посредством методов идентификации с помощью псевдонима;

c) статистические данные и результаты исследований, включая конфиденциальные данные, выведенные из персональных данных о состоянии здоровья путем удаления личных идентификационных данных;

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

e) данные о медицинских работниках, персонале и волонтерах;

f) информация, связанная с надзором в сфере здравоохранения;

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

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

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

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

В соответствии с ИСО 27799:2008, приложение А, угрозы нарушения неприкосновенности частной жизни, конфиденциальности, целостности и доступности включают:

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

b) неразрешенное использование медицинских информационных приложений и данных, хранимых на этих приложениях;

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

d) неправильное использование системных ресурсов;

e) несанкционированное проникновение в связь, например, отказ от обслуживания и взлом защиты путем замещения оригинала;

f) перехват информации в каналах связи;

g) отрицание причастности к происхождению или получению данных;

h) нарушение связи;

i) аварийное нарушение маршрутизации;

j) техническую неисправность ведущего компьютера, системы памяти или сетевой инфраструктуры;

k) отказ поддержки жизнеобеспечения, включая перебои электропитания и прерывание обслуживания, вызванное природными или антропогенными катастрофами;

I) отказ прикладного программного обеспечения;

m) ошибку операций;

n) ошибку технического обслуживания;

о) ошибку пользователя.

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

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

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

Эти два типа угроз описаны в 5.2.2 и 5.2.3.

5.2.2 Организационные угрозы

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

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

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

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

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

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

5.2.3 Системные угрозы

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

5.2.4 Применимость

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

Наиболее известным международным стандартом по безопасности является ИСО/МЭК 27002. Несмотря на то что он рассматривает вопросы управления информационной безопасностью в целом, средства управления, описанные в нем, применяются к электронным системам. Стандарт медико-фармацевтической отрасли ИСО 27799 является одним из нескольких стандартов, разработанных в рамках ИСО/ТС 215 для обеспечения реализации программных средств управления и практик в сфере здравоохранения.

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

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

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

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

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

     5.3 Требования конфиденциальности и безопасности POS

5.3.1 Общие положения

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

5.3.2 Согласие субъекта данных на сбор, использование или раскрытие персональной медицинской информации
     
     Требование 1. Согласие на регистрацию данных.
В случае когда субъекты данных имеют право согласно закону или обычаю отказаться или аннулировать свое согласие на использование или разглашение их персональных медицинских данных, клинические системы POS:

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

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

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


Требование 2. Зарегистрировано минимальное количество данных. В случае когда клинические системы POS записывают директивы разглашения информации субъекта данных, должны быть записаны особенности директив (например, отказ от согласия или отказ от согласия, данного ранее), а также тип согласия в тех юрисдикциях, которые распознают два или более типа согласия (например, подразумеваемое или выраженное согласие), и дата, на которую была выдана директива.

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

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

Требование 5. Регистрация экстренного доступа. Клинические системы POS должны быть способны:

a) регистрировать события, при которых обработка директив согласия делает невозможным разглашение данных;

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

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

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

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

Обоснование

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

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

Ссылки:

ИСО 27799, ИСО/МЭК 15408 (все части), ИСО 18308, ИСО 27789.

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

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

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

Обоснование

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

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

Ссылки:

Организация экономического сотрудничества и развития. Принципы честного использования данных (OECD Fair Information Practices).

5.3.4 Доступ субъекта данных к персональной медицинской информации и исправление неточных сведений
     
     Требование 11. Доступ субъекта данных.
В случае когда субъект данных оспаривает полноту и точность информации в записи субъекта, а организация не согласна с его оценкой, клиническая система POS должна иметь возможность записи несогласия и/или причины отказа в обновлении записи.

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

Примечание - В некоторых юрисдикциях субъекты данных имеют право доступа к своим записям и право запроса на внесение изменений в их записи.


Обоснование

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

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

Ссылки:

ИСО 27799, ИСО/МЭК 15408 (все части), ИСО 18308, ИСО 27789.

5.3.5 Точность данных
     
     Требование 13. Точность.
Клинические системы POS должны включать средства обеспечения точности и полноты ПМД в той степени, в которой это необходимо для установленных целей применения. Примеры включают в себя внедрение средств контроля проверки ввода данных и осуществление проверок целостности, таких как определение контрольной суммы и хэш-суммы.

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

Обоснование

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

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

Ссылки:

ИСО 27799, ИСО/МЭК 15408 (все части), ИСО 18308, ИСО 27789.

5.3.6 Идентификация и аутентификация пользователя
     
     Требование 15. Идентификация пользователя.
Пользователям клинических систем POS должен быть присвоен идентификатор (ID пользователя), который, возможно, и в комбинациях с другими идентификаторами (например, идентификаторами учреждения или юрисдикции) однозначно идентифицирует каждого отдельного пользователя и используется при аутентификации пользователя и ведении журналов аудита. Если транзакции выходят за пределы организации или юрисдикции, ID пользователя в сочетании с другой регистрационной информацией пользователя (например, имя пользователя, адрес, идентификатор учреждения, идентификатор юрисдикции) должен:

a) однозначно идентифицировать каждого пользователя;

b) позволять принимать решения в системе контроля доступа (см. 5.3.7);

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

Требование 16. Идентификаторы (ID) пользователя. Клинические системы POS должны поддерживать идентификаторы пользователей без учета регистра, которые содержат знаки, взятые из ИСО/МЭК 8859 (все части) [например, ИСО/МЭК 8859-1, также известный как US ASCII (Американский национальный стандартный код для обмена информацией)] или из ИСО/МЭК 10646 [также известный как Unicode (Юникод)].

Требование 17. Аутентификация пользователя. Клинические системы POS должны гарантировать, что все пользователи надежно аутентифицированы.

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

Требование 19. Методы аутентификации. При наличии возможности клинические системы POS должны поддерживать многофакторную аутентификацию пользователя.

Требование 20. Аутентификация пользователя и системы. Клинические системы POS должны аутентифицировать каждое лицо, запрашивающее доступ к ПМД.

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

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

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

Требование 22. Пароли: использование, качество, сброс и изменения пользователя. При использовании паролей клиническая система POS должна использовать следующие средства контроля безопасности:

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

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

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

d) чувствительность к регистру: необходима поддержка паролей, чувствительных к регистру, которые содержат знаки, взятые из ИСО/МЭК 8859 (все части) [например, ИСО/МЭК 8859-1, также известный как US ASCII (Американский национальный стандартный код для обмена информацией)] или из ИСО/МЭК 10646 [также известный как Unicode (Юникод)].

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

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

Обоснование

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

Ссылки:

ИСО 27799, ИСО/МЭК 15408 (все части), ИСО 18308, ИСО 27789.

5.3.7 Управление доступом
     
     Требование 25. Средства управления доступом.
Клинические системы POS должны подтверждать, что каждое аутентифицированное лицо или субъект, запрашивающий доступ к персональным медицинским данным, авторизован для допуска к данной информации.

Требование 26. Контроль авторизации. Перед реализацией системы передачи данных, относящихся к ПМД, клинические системы POS должны подтвердить, что запрашивающий пользователь или субъект имеет необходимые права доступа.

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

Требование 28. Другие формы управления доступом. Клинические системы POS также должны иметь способность сопоставления каждого пользователя с правами доступа, предоставленными или ограниченными на основе:

a) рабочей группы, к которой принадлежит пользователь, или

b) контекста операции (например, время суток, местоположение рабочей станции или экстренный доступ).

Требование 29. Передача доступа к персональным медицинским данным объекта получения помощи. Клинические системы POS должны иметь возможность поддержания ассоциации между выбранными пользователями и картами объекта получения помощи и предоставлять доступ на основе данной ассоциации; т.е. клинические системы POS должны иметь способность предоставления передаваемого доступа к записям на основе передачи пользователем с санкционированным доступом права доступа к этим записям другому пользователю.

При реализации такое предоставление доступа не должно:

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

b) превышает основанные на роли права доступа пользователя, получающего доступ.

Требование 30. Сообщение о правах доступа. Клинические системы POS должны иметь возможность сообщения касательно определенного пользователя, имеет ли он доступ к записям определенного объекта получения помощи и разрешения (просмотр, изменение и пр.), касающихся записей объекта получения помощи.

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

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

Обоснование

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

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

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

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

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

Ссылки:

ИСО 27799, ИСО/МЭК 15408 (все части), ИСО 18308, ИСО 27789, ИСО/TS 22600 (все части).

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

Обоснование

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

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

Ссылки:

ИСО 27799, ИСО/МЭК 15408 (все части), ИСО 18308, ИСО 27789.

5.3.9 Безопасность сеанса и время ожидания
     
     Требование 34. Безопасность сеанса.
Клинические системы POS должны защищать автоматически управляемые рабочие станции от посторонних лиц, пользующихся возможностью использования рабочей станции, пока система функционирует с автоматическим временем ожидания после бездействия.

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

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

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

Требование 37. Безопасность сеанса. Клиническая система POS должна иметь средства контроля безопасности сеанса связи для предотвращения похищения или кражи сеанса пользователя.

Обоснование

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

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

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

Ссылки:

ИСО 27799, ИСО/МЭК 15408 (все части), ИСО 18308, ИСО 27789.

5.3.10 Поддержка доступности данных
     
     Требование 38. Резервное копирование.
Клиническая система POS должна поддерживать создание резервных копий данных приложения, набора удостоверений защиты, журналов аудита и других данных и файлов, необходимых для нормальной работы клинической системы POS.

Требование 39. Параллельное резервное копирование. Если клиническая система POS доступна в непрерывном режиме, то система должна иметь возможность выполнения параллельного резервного копирования параллельно с работой приложения.

Требование 40. Восстановление. Восстановление данных клинической системы POS должно предоставлять пользователю возможность возврата системы в полностью рабочее и безопасное состояние. Данное состояние должно включать восстановление данных приложения, набора удостоверений защиты и журналов аудита, а также должно обеспечивать возможность проверки полноты восстановленных данных (также см. 5.3.13).

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

Обоснование

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

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

- экспортируйте атрибуты защиты вместе с данными;

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

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

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

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

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

Ссылки:

ИСО 27799, ИСО/МЭК 15408 (все части), ИСО 18308, ИСО 27789.

5.3.11 Защита данных в ходе передачи

Клинические системы POS должны применять алгоритмы шифрования информации и протоколы, соответствующие промышленным стандартам, для передачи ПМД по сети Интернет или другим открытым сетям для поддержки конфиденциальности и целостности данных.

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

a) аутентификация участника (например, клиента или сервера);

b) целостность данных;

c) конфиденциальность данных.

Примеры
     


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


    2 Сеансы связи клинической системы POS между клиентским браузером и Web-сервером происходят через Интернет или другие открытые сети при наличии защиты на основе Web-технологии, например, защиты транспортного уровня (TLS) для обеспечения аутентификации сервера, целостности данных и конфиденциальности данных.

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

Обоснование

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

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

В случае необходимости, система должна получить подтверждение получения при передаче ПМД, чтобы гарантировать, что передаваемые данные были получены.

Ссылки:

ИСО 27799, ИСО/МЭК 15408 (все части), ИСО 18308, ИСО 27789.

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

Требование 45. Защита данных на портативных носителях. При хранении ПМД на любых носителях или съемных и портативных приборах (например, флеш-накопитель, CD-ROM, PDA или портативный компьютер) клинические системы POS должны поддерживать использование формата шифрования, соответствующего отраслевым стандартам.

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

а) персональная информация (например, персональные данные пациента или другая информация, которая идентифицирует пациента);

b) персональные данные о состоянии здоровья;

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

Обоснование

Защита ПМД имеет существенное значение, если использование и разглашение данной информации должно контролироваться.

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

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

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

Ссылки:

ИСО 27799, ИСО/МЭК 15408 (все части), ИСО 18308, ИСО 27789.

5.3.13 Целостность данных
     
     Требование 47. Целостность вводов данных.
Данные, импортируемые из других EHR посредством портативного устройства, должны быть четко ассоциированы с объектом получения помощи и лечащим врачом, местом, датой и временем импорта, а также с пользователем, который импортирует данные.

Требование 48. Целостность данных в ходе обработки. Средства управления должны быть готовы к использованию в клинической системе POS для проверки целостности данных EHR с целью предотвращения действий пользователя или отказов системы от несоответствия данных или отказов в целостности ссылочных данных для связей между записями данных.

Требование 49. Целостность выводов данных. Клинические системы POS должны обеспечивать читателю возможность проверки полноты печатных копий документа (например, "страница 3 из 5").

Обоснование

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

Ссылки:

ИСО 27799, ИСО/МЭК 15408 (все части), ИСО 18308, ИСО 27789.

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

Обоснование

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

Ссылки:

ИСО 27799, ИСО/МЭК 15408 (все части), ИСО 18308, ИСО 27789, ИСО/TS 21547.

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

Обоснование

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

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

Ссылки:

ИСО 27799, ИСО/МЭК 15408 (все части), ИСО 18308, ИСО 27789.

5.3.16 Аудит
     
     Требование 52. Регистрация аудита.
Клинические системы POS должны регистрировать события, связанные с использованием системы (т.е. запуск и остановка системы, вход и выход пользователя, время ожидания сеанса, резервное копирование и восстановление, блокировка учетных записей) и управлением информацией о состоянии здоровья (т.е. создание, доступ, изменение и архивирование, а также импорт, экспорт, печать или иное разглашение персональных медицинских данных).

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

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

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

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

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

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

Требование 57. События, подвергаемые аудиту. Журналы аудита клинической системы POS должны проверять следующие события:

a) создание, обновление медицинских карт или осуществление доступа к ним (например, отображение на экране, распечатка, скачивание);

b) доступ к данным, которые были защищены или скрыты согласно указанию пациента/лица (экстренный доступ);

c) создание и изменение директив согласия пациента/лица;

d) запрос персональных медицинских данных;

e) импорт ПМД (прием), включая передачу данных, обмен данными;

f) экспорт ПМД, включая передачу данных, обмен данными и печать;

g) действия, связанные с пользователем, ролью и управлением группами, а также

h) доступ к журналу аудита.

Журналы аудита клинической системы POS должны также иметь возможность проведения аудиторской проверки следующих событий:

- запуска и остановки системы;

- попытки аутентификации пользователя и результата (успешно или нет);

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

- резервного копирования и восстановления (при инициации самой системой);

- доступа к базе данных;

- ошибки аутентификации узла;

- создания/утверждения цифровой подписи;

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

- удаления карт.

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

Требование 58. Минимальное содержание записанной информации. Журнал аудита клинической системы POS должен включать следующую информацию:

a) запись с идентификационной информацией пользователя;

b) запись с идентификационной информацией ответственного лица - лица, осуществляющего ввод или доступ к данным, если оно не является пользователем;

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

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

e) характер события, подвергнутого аудиту, и идентификатор данных, связанных с событием (например, ID пациента, ID сообщения), подвергнутым аудиту;

f) функции, выполняемые пользователем;

g) временную отметку (дату и время события);

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

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

j) оконечное устройство или точку доступа (при наличии);

k) в случае изменения пароля пользователь, чей пароль был изменен;

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

Требование 59. Интерфейс аудита. Клиническая система POS должна поддерживать ведение журнала в общей библиотеке аудита [например, используя схему и средства передачи, указанные в спецификации журнала аудита профиля аудиторских следов и аутентификации узла IHE (ATNA)].

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

a) система должна предоставлять возможность создания отчетов на основе интервалов дат и времени или

b) система должна иметь возможность экспорта данных журнала таким образом, чтобы обеспечить связь на основе даты и времени [например, синхронизация UTC (всемирное координированное время)].

Требование 60. Защита журналов аудита. Клинические системы POS должны:

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

b) запрещать пользователям вносить изменения в данные журнала аудита.

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

Требование 61. Непрерывное ведение журнала. Ведение журналов аудита клинической системы POS должно поддерживаться постоянно, а пользователи не должны иметь никаких средств для отмены любой записи аудита.

Требование 62. Сохранение истории ПМД. Клиническая система не должна стирать записи или данные журнала аудита или вносить изменения в записи субъекта данных, которые препятствуют восстановлению записей объекта получения помощи на предшествующий момент времени.

Обоснование

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

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

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

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

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

Ссылки:

ИСО 27799, ИСО/МЭК 15408 (все части), ИСО 18308, ИСО 27789.

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

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

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

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

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

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

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

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

c) установка, запуск и подключение системы, включая установку защиты связи;

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

e) управление и работа системы;

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

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

h) управление изменениями ПО и текущие исправления;

i) синхронизация системного времени (часы) в применимых случаях;

j) сообщения об ошибках системы или работе пользователям и администраторам с указанием необходимых действий;

k) процедуры резервного копирования данных, включая проверку целостности данных при создании или восстановлении резервной копии.

Требование 69. Документация и управление версиями. Все руководства по эксплуатации клинической системы POS должны четко обозначать в начале документа версию, к которой они применяются.

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

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

Обоснование

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

Ссылки:

ИСО 27799, ИСО/МЭК 15408 (все части), ИСО 18308, ИСО 27789.

5.3.18 Синхронизация времени и форматирование времени/даты
     
     Требование 71. Формат времени.
Клинические системы POS должны принять единый формат отображения времени для осуществления контроля и аудита.

Требование 72. Синхронизация часов. Клинические системы POS должны поддерживать синхронизацию времени с помощью протоколов NTP/SNTP и использовать это синхронизированное время во всех записях безопасности времени.

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

Требование 74. Источники времени. Клинические системы POS должны использовать достоверный и защищенный источник времени.

Клинические системы POS должны поддерживать синхронизацию времени с помощью сетевого протокола синхронизации времени IET (NTP) или простого сетевого протокола синхронизации времени (SNTP).

Обоснование

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

Ссылки:

ИСО 27799, ИСО/МЭК 15408 (все части), ИСО 18308, ИСО 27789, ИСО 8601.

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

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

Обоснование

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

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

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

Ссылки:

ИСО 27799, ИСО/МЭК 15408 (все части), ИСО 18308, ИСО 27789.

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

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

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

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

a) позволять пользователям системы применять цифровые подписи с отметкой времени в соответствии с ETSI TS 101 733 (Электронные подписи и инфраструктуры - ESI - CMS. Расширенные электронные подписи - CAdES) или ETSI TS 101 903 (Расширенные электронные подписи XML - XAdES), используя цифровой сертификат с полем для ключа, который обеспечивает отказоустойчивость;

b) на момент подписания проверять, что срок действия сертификата подписавшего не истек, сертификат не аннулирован, а метод сертификации действителен, в соответствии RFC 3280 (Интернет Х.509. Инфраструктура открытого ключа. Сертификат и список отозванных сертификатов. Профиль CRL) или RFC 2560 (Интернет Х.509. Инфраструктура открытого ключа. Протокол онлайн-получения статуса сертификата - OCSP);

c) позволять всем пользователям системы POS просматривать и подтверждать информацию, которая должны быть подписана в момент подписания.

Требование 81. Проверка подлинности, сохранение и передача цифровых подписей. Система POS должна:

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

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

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

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

Требование 82. Цель использования цифровой подписи и роль подписавшего. Системы POS, предоставляющие возможность использования цифровых подписей, должны включать в себя атрибут "индикация типа обязательства" (commitment-type-indication) и роль подписавшего (т.е. атрибут роли подписавшего).

Обоснование

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

Ссылки:

ИСО 27799, ИСО/МЭК 15408 (все части), ИСО 18308, ETSI TS 101 733, ETSI TS 101 903, RFC3280, RFC2560.

     5.4 Общие критерии

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

Стандарт направлен на то, чтобы охватить все различные виды ИТ-продуктов и систем, и предоставляет широкий спектр требований, позволяя разработчику продукта или системы определить область применения, называемую объектом оценки (ОО), и выбрать набор требований, который применяется в конкретном случае.

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

Ниже приведен список классов ОК:

a) аудит безопасности (FAU);

b) связь (FCO);

c) криптографическая поддержка (FCS);

d) защита данных пользователя (FDP);

e) (G) идентификация и аутентификация (FIA);

f) (H) управление безопасностью (FMT);

g) (I) неприкосновенность частной жизни (FPR);

h) (J) защита функций безопасности объекта оценки TSF - TOE (FPT);

i) (K) использование ресурсов (FRU);

j) (L) доступ к объекту оценки (FTA);

k) доверенный маршрут/канал (FTP);

I) управление безопасностью:

- управление версиями;

- документация и методы;

- доступность;

- контроль времени;

m) неприкосновенность частной жизни;

n) защита функций безопасности;

о) управление доступом.

В таблице 1 приведено перекрестное сопоставление классов ОК с требованиями, установленными в предыдущем разделе.


Таблица 1 - Сравнение требований с общими критериями

Требование

Совпадение между требованием и классом ОК

Класс ОК

1 Согласие субъекта данных на сбор, использование и разглашение персональных медицинских данных

-

Нет прямых совпадений для неприкосновенности частной жизни (не рассматривается в ОК)

2 Ограничение использования и разглашения

-

Нет прямых совпадений для неприкосновенности частной жизни (не рассматривается в ОК)

3 Доступ субъекта данных к личной информации и исправление недостоверных сведений

-

Нет прямых совпадений для неприкосновенности частной жизни (не рассматривается в ОК)

4 Достоверность данных

Да

Защита данных пользователя. Целостность хранимых данных

5 Идентификация и аутентификация пользователя

Да

Идентификация и аутентификация

6 Управление доступом

Да

Доступ: политика контроля доступа, функции управления доступом

7 Приемлемое использование

-

Нет прямых совпадений для неприкосновенности частной жизни (не рассматривается в ОК)

8 Безопасность сеанса и время ожидания

Да

Доступ: блокировка и завершение сеанса

9 Поддержка доступности данных

Да

Управление безопасностью

10 Защита данных в ходе передачи

Да

Криптографическая поддержка: работа в режиме криптографической защиты

11 Защита данных при хранении

Да

Защита данных пользователя

12 Целостность данных.

Контроль инцидентов нарушения безопасности и конфиденциальности

Да

Защита данных пользователя: целостность хранимых данных

13 Хранение записей

-

Нет прямых совпадений с категориями ОК

14 Маркировка данных

Да

Доступ к объекту оценки

15 Аудит

Да

Аудит безопасности

16 Управление версиями программного обеспечения и документация

Да

Управление безопасностью

17 Синхронизация времени и форматирование времени/даты

Да

Управление безопасностью

18 Контроль инцидентов нарушения безопасности и конфиденциальности

-

Нет прямых совпадений с категориями ОК

19 Цифровые сертификаты и электронно-цифровые подписи

Да

Криптографическая поддержка

     

     6 Современные подходы и руководство по разработке и поддержке программ оценки соответствия

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

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

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

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

- увеличение возможностей международной торговли;

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

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

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

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

     6.1 Принципы

Оценка соответствия определена Комитетом ИСО по оценке соответствия (CASCO) в ИСО/МЭК 17000:2004 как "подтверждение того, что установленные требования, относящиеся к продукту (включая программное обеспечение), процессу, системе, лицу или органу, соблюдены".

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

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

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

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

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

- вопроса конкретного контекста системы каждой страны-участника в соответствии с определением в объектах оценки и

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

А также:

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

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

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


Рисунок 1 - Пример модели оценки соответствия

К данному вопросу относятся три принципа:

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

- сертификация - аттестация, проводимая третьей стороной, относящаяся к продукции, процессам, системам или лицам;

- соответствие - действие, направленное на то, что необходимо для выполнения установленного требования.

Одной из особенностей оценки соответствия является то, что она может принимать различные формы, используя различные методы в зависимости от задач, для которых она используется. Независимо от того, кем будет проводиться работа - поставщиком продукции, покупателем или независимым органом, требуется четкое понимание необходимости наличия знаний, навыков и опыта у тех, кто выполняет задачи по оценке соответствия. Каждая организация независимо от ее роли должна использовать систему управления, в которой установлены необходимые компетенции и средства подтверждения того, что отдельные лица соответствуют указанным требованиям. ИСО/МЭК 17065 содержит общие критерии для организаций, использующих системы сертификации продуктов; хотя стандарт касается сертификации продукта, проводимой третьей стороной, многие из его положений могут также быть полезными при оценке соответствия продукции, проводимой первой и второй стороной.

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

- первая сторона: лицо или организация, которая предоставляет объект, подлежащий оценке соответствия;

- вторая сторона: лицо или организация, которая заинтересована в объекте как пользователь;

- третья сторона: лицо или организация, независящая от лица или организации, предоставляющей объект и заинтересованной в объекте как пользователь.

     6.2 Процессы оценки соответствия

ИСО/МЭК 17000 устанавливает "функциональный подход" к оценке соответствия. Функциональный подход включает в себя основные процессы, такие как выбор, определение, рассмотрение и аттестация, а также наблюдение при необходимости.

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


Рисунок 2 - Функциональный подход к оценке соответствия

_______________

Рисунок, обозначенный как рисунок 4 в документе ИСО "Построение доверительных отношений. Набор средств по оценке соответствия", Центральный секретариат ИСО, февраль 2010 г.


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

Выбор

- Спецификация стандарта (стандартов) или другого документа (документов), соответствие которым будет оцениваться.

- Выбор примеров объектов, которые подлежат оценке.

- Спецификация методов статистической выборки в соответствующих случаях.

Определение

- Тестирование для определения указанных характеристик объекта оценки.

- Проверка физических свойств объекта оценки.

- Аудит систем и записей, относящихся к объекту оценки.

- Определение качеств объекта оценки.

- Изучение спецификаций и чертежей для проверки и аттестации объекта оценки.

Проверка и аттестация

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

- Возвращение к этапу определения для устранения несоответствий.

- Составление и выдача заключения о соответствии.

- Размещение знака соответствия на продукции, соответствующей требованиям осмотра.

Надзор

- Выполнение действий по определению в месте производства или в канале поставок на место торговли.

- Выполнение действий по определению в месте торговли.

- Выполнение действий по определению на месте использования.

- Рассмотрение результатов действий этапа определения.

- Возвращение к этапу определения для устранения несоответствий.

- Составление и выдача подтверждения о сохранении соответствия.

- Выполнение корректирующих и предупреждающих действий в случае выявления несоответствия.

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

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

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

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

Несколько стран (например, США, Великобритания, Бразилия и Канада) внедрили программы по оценке соответствия при поддержке национального правительства для расширяемого массива клинических программных продуктов и требований, так как клиническая функциональность и совместимость клинических систем POS увеличивается. Эти программы продолжают развиваться на основе опыта и изменении потребностей, а приложение А представляет собой описание подходов, примененных в четырех странах к 2010 г. В последнее время также появляются подходы, разработанные с участием многих стран, например, проект "Интеллектуальное открытое обслуживание европейских пациентов" [European Patients Smart Open Services (epSOS)].

В случае с США Бюро национальных координаторов (ONC) аккредитовало агентства третьих сторон на право выдачи сертификатов согласно требованиям соответствия и методам проведения испытаний, установленным Национальным институтом науки и техники (NIST). В других странах сертификаты предоставляются отдельным органам, назначенным правительством страны.

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

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

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

Приложение А
(справочное)

Программы по оценке соответствия. Конструктивные решения и наглядные примеры от стран-участников на 2010 г.

А.1 Общие сведения

Данное приложение предоставляет более подробную информацию о моделях оценки соответствия, процессах и других решениях, сопровождаемую примерами программ оценки соответствия и сертификации с целью продемонстрировать альтернативные подходы, которые могут быть применены в зависимости от ситуации в определенной стране. Несмотря на то что примеры, приведенные в данном приложении, допускают обмен информацией в пределах государственных границ, их принципы все еще применимы в ситуациях с межгосударственным обменом. Такие проекты, как epSOS [European Patients Smart Open Services (Интеллектуальное открытое обслуживание европейских пациентов)], в Европе являются реальным примером межгосударственного обмена в рассматриваемой области.

А.2 Программы по оценке соответствия. Конструктивные решения
     


    А.2.1 Уполномоченный орган

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

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

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

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

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

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

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

А.2.2 Требования к органам сертификации продукта

Требования к органам, осуществляющим сертификацию продукта, процесса или услуг, определены в ИСО/МЭК 17065.

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

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

- Требования к структуре: организационная структура и высшее руководство; механизмы сохранения беспристрастности.

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

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

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

А.2.3 Вопросы стоимости и другие решения

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

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

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

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

А.2.4 Ответственность

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

А.2.5 Разработка программы оценки соответствия

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

А.2.6 Заявление о соответствии

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

А.2.7 Определение. Условия проведения и методы тестирования

Руководство ИСО/МЭК 67 описывает семь основных типов систем сертификации продукции, отмечая, что элементы этих систем могут быть объединены другими способами для создания дополнительных систем. Эти системы могут включать в себя один или несколько следующих компонентов:

- образцы, запрашиваемые органом сертификации;

- определение соответствующих характеристик продукта путем проведения испытания (ИСО/МЭК 17025) или оценки;

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

- изучение отчетов оценки или испытания;

- подтверждение соответствия;

- выдача лицензии на использование сертификатов и знаков на продукции;

- контроль с помощью испытаний или проверки образцов с завода или рынка.

Закупки не найдены
Свободные
Р
Заблокированные
Р
Роль в компании Пользователь

Для продолжения необходимо войти в систему

После входа Вам также будет доступно:
  • Автоматическая проверка недействующих стандартов в закупке
  • Создание шаблона поиска
  • Добавление закупок в Избранное