Информационные технологии - http://www. *****/

Межрегиональная общественная организация содействия стандартизации

и повышению качества медицинской помощи

УТВЕРЖДАЮ

Исполнительный директор

Межрегиональной общественной

организации содействия стандартизации

и повышению качества

медицинской помощи

________п/п_________

" 21 " июня 2004 г.

СИСТЕМА СТАНДАРТИЗАЦИИ В ЗДРАВООХРАНЕНИИ

РОССИЙСКОЙ ФЕДЕРАЦИИ

СТАНДАРТ ОРГАНИЗАЦИИ

ИНФОРМАЦИОННЫЕ СИСТЕМЫ

В ЗДРАВООХРАНЕНИИ

Общие требования

СТО МОСЗ 91500.16.

Москва

2004

Программой создания и развития стандартизации в здравоохранении на годы, принятой Минздравом России, Госстандартом России и Федеральным фондом ОМС, была запланирована разработка отраслевого стандарта «Информационные системы в здравоохранении. Общие требования». После завершения разработки и согласования проекта стандарта в соответствии с требованиями системы стандартизации в здравоохранении он был одобрен Экспертным советом Минздрава России по стандартизации в здравоохранении.

Проект стандарта «Информационные системы в здравоохранении. Общие требования» разработан рабочей группой из специалистов: Института системного программирования Российской академии наук ( – научный руководитель, ), Федерального фонда обязательного медицинского страхования (, ), Департамента организации и развития медицинской помощи населению Минздрава России (), Департамента экономического развития здравоохранения, управления финансами и материальными ресурсами Минздрава России (), Главного научно-исследовательского вычислительного центра Медицинского центра Управления делами Президента Российской Федерации (), Московской медицинской академии им. (, ), фирмы РЕЛАКС (, , ), Государственного унитарного предприятия «Медицина для Вас» ().

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

СТАНДАРТ ОРГАНИЗАЦИИ

ИНФОРМАЦИОННЫЕ СИСТЕМЫ

В ЗДРАВООХРАНЕНИИ

Общие требования

Дата введения – 2004 –

1. ОБЛАСТЬ ПРИМЕНЕНИЯ

1.1. Назначение

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

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

1.2. Область распространения

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

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

-  Министерство здравоохранения РФ;

-  органы территориального (ведомственного) управления здравоохранением (ОТУЗ);

-  медицинские управления министерств и ведомств (МУВ);

-  органы Государственного санитарного эпидемиологического надзора (ГСЭН);

-  Федеральный фонд ОМС;

-  Территориальные фонды ОМС (ТФОМС);

-  филиалы ТФОМС и их представительства;

-  страховые медицинские организации (СМО);

-  лечебно-профилактические учреждения (ЛПУ);

-  санаторно-курортные учреждения (СКУ);

-  медицинские учебные заведения (МУЗ).

2. НОРМАТИВНЫЕ ССЫЛКИ

1. Федеральный закон «О медицинском страховании граждан в Российской Федерации». 28.06.91 № 000-1 (в редакции ФЗ от 02.04.93 № 000-1).

2. «Основы законодательства Российской Федерации об охране здоровья граждан» от 22.07.93 г. № 000-1 (в редакции Указа Президента РФ от 24.12.93 № 000, Федеральных законов от 02.03.98 , от 20.12.99 ).

3. Закон Российской Федерации «Об информации, информатизации и защите информации» 20.02.95 .

4. Постановление Правительства Российской Федерации от 26.10.99 № 000 «О Программе государственных гарантий обеспечения граждан Российской Федерации бесплатной медицинской помощью».

3. Функциональные требования к ИНФОРМАЦИОННЫМ СИСТЕМАМ в здравоохранении

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

3.1. Функциональная классификация информационных систем в здравоохранении

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

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

1.  Медико-технологические ИС (МТИС), предназначенные для информационного обеспечения процессов диагностики, лечения, реабилитации и профилактики пациентов в лечебно-профилактических учреждениях.

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

3.  Статистические ИС (СМИС) органов управления здравоохранением.

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

5.  Обучающие ИС (ОМИС), предназначенные для информационного обеспечения процессов обучения в медицинских учебных заведениях.

Пользователями ИС указанных классов являются учреждения и организации системы здравоохранения:

-  больницы (участковые сельские, районные, городские, областные, ведомственные);

-  клинические НИИ;

-  поликлиники (районные, городские, ведомственные);

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

-  санаторно-курортные учреждения;

-  органы управления здравоохранением на федеральном (Минздрав России) и территориальном уровнях (ОТУЗ), ведомственные медицинские управления других министерств и ведомств (МУВ);

-  территориальные органы Госсанэпиднадзора;

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

-  медицинские учебные заведения.

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

К классу медико-технологических систем относятся:

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

2. Системы вычислительной диагностики.

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

4. Экспертные системы, основанные на базах знаний, собранных от экспертов - опытных специалистов в определенной области.

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

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

Таблица 1

Примечание.

Возможны два варианта использования ИС указанных классов учреждениями и организациями – пользователями ИС:

-  использование автономных ИС каждого класса из числа отмеченных знаком «+»;

-  использование интегрированных ИС, в которых системы, отмеченные знаком «+», применяются в качестве подсистем при помощи программных и аппаратных средств интеграции (см. подраздел 3.4.).

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

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

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

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

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

Медико-технологические ИС подразделяются на следующие виды:

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

-  автоматизированные системы консультативной вычислительной диагностики в ЛПУ;

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

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

Информационно-справочные системы (ИСС) в зависимости от широты охвата обслуживаемого населения подразделяются на следующие виды:

-  ИСС ЛПУ – поликлиник, стационаров, родильных домов и др. ЛПУ, СКУ;

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

-  ИСС с базой данных на все население административной территории, в т. ч. фонды ОМС и страховые организации.

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

Статистические ИС органов управления здравоохранением (СМИС) в зависимости от объектов описания подразделяются на следующие виды:

-  СМИС “Здоровье населения”, содержащие статистические данные по группам населения в целом по России, регионам, муниципальным образованиям;

-  СМИС “Среда обитания”, содержащие статистические данные по социальным институтам и экологическим нишам (зонам);

-  СМИС “Учреждения здравоохранения”, содержащие данные с описанием типов и характеристик деятельности учреждений (БД паспортов ЛПУ);

-  СМИС “Кадры здравоохранения”, содержащие данные о персонале учреждений здравоохранения;

-  СМИС “Медицинская промышленность”, содержащие сведения о предприятиях и их продукции (лекарства, медицинские приборы и оборудование).

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

Научно-исследовательские ИС (НИИС) в зависимости от объектов описания подразделяются на следующие виды:

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

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

-  системы автоматизации медико-биологических исследований.

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

-  обучающие ИС по принципу «вопрос-ответ», контролирующие знания по ответам учащихся на вопросы системы, выбранным из числа возможных вариантов;

-  обучающие ИС, предоставляющие знания в виде электронных учебных курсов и учебных пособий и контролирующие усвоение знаний по принципу «вопрос-ответ»;

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

3.2. Классификация функций информационных систем в здравоохранении

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

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

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

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

Таблица 2

Примечание.

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

В настоящем документе выделены следующие классы функций ИС:

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

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

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

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

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

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

3.2.7. Функции мониторинга за состоянием медико-демографической и эпидемиологической ситуации.

3.2.8. Функции сбора и обработки медицинских статистических данных, в т. ч. трансформации данных из электронных медицинских карт в «паспорт здоровья» и агрегирования деперсонифицированных «паспортов здоровья» на уровнях ОТУЗ, ТФОМС и других организаций; функции мониторинга состояния здоровья населения, в т. ч. иммунопрофилактики; функции оформления и представления государственной медицинской статистической отчетности; функции анализа статистических данных для формирования отчетов о состоянии здоровья населения, медико-демографической ситуации, и для прогнозирования.

3.2.9. Функции поддержки принятия решений, в т. ч. на основе современных баз знаний, методов логического вывода на знаниях, экспертных систем и других методов «интеллектуализации» ИС.

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

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

Под телемедицинскими технологиями в настоящем документе понимают медицинские технологии, реализуемые с применением средств телекоммуникаций («телемедицина»):

- лечебно-диагностические телемедицинские консультации;

- телемониторинг (телеметрия) функциональных показателей больного;

- телемедицинское функциональное (лабораторное) обследование;

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

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

- системы дистанционного обучения в медицинских учебных заведениях.

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

3.2.13. Функции поддержки процессов обучения, подготовки и переподготовки специалистов.

3.2.14. Функции ведения нормативно-справочной информации.

3.2.15. Функции автоматизации документооборота в учреждении (организации).

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

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

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

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

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

3.3.3. Модульное построение функциональных подсистем ИС и ИС в целом должно быть реализовано на основе применения стандартных программных интерфейсов API (Application Program Interface - интерфейсов прикладного программирования) и стандартных протоколов взаимодействия между приложениями. Такие интерфейсы и протоколы должны быть выбраны разработчиками ИС по перечням существующих стандартов, которые предусмотрены Системой стандартизации в здравоохранении для построения профилей ИС.

Под интерфейсом в настоящем документе понимают:

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

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

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

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

3.3.4. В проектную документацию на каждую ИС учреждений (организаций) здравоохранения должны быть включены функциональные профили ИС, содержащие ссылки на существующие стандарты интерфейсов прикладного программирования и протоколов взаимодействия, которые подлежат реализации при разработке приложений и баз данных ИС. Разработка функциональных профилей ИС должна производиться в соответствии с ГОСТ Р ИСО/МЭК ТО 10000-3 (часть 3. «Принципы и таксономия профилей среды открытых систем»).

Согласно эталонной модели среды открытых систем OSE/RM, принятой в этом стандарте, ИС разделяются на приложения (прикладные программы) и среду (платформы функционирования прикладных программ – прикладные платформы). Между приложениями и средой должны быть определены стандартные программные интерфейсы – API. Кроме API в профиле должны быть также определены стандартизованные интерфейсы между ИС и внешней для нее средой – EEI (External Environment Interface).

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

3.3.5. Функциональные подсистемы ИС ЛПУ / СКУ должны обеспечивать реализацию следующих функций (согласно классификации по п. 3.1.):

-  ведение медицинской документации («электронных историй болезни»);

-  формирование структурно-экономических описаний (паспортов) ЛПУ и передачу их в сводные БД паспортов ЛПУ, которые ведутся в ТФ ОМС и ОТУЗ;

-  учет пациентов и ведение реестра выполненных медицинских услуг по ОМС;

-  планирование и учет выполненных прививок;

-  взаиморасчеты со СМО и ТФ ОМС за пролеченных пациентов;

-  ведение нормативно-справочной информации (НСИ);

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

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

-  представление государственной медицинской статистической отчетности в ОТУЗ;

-  ведение БД зарегистрированных диагнозов для формирования статистики заболеваний;

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

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

3.3.6. Функциональные подсистемы организаций управления здравоохранением (Минздрава России, ОТУЗ и МУВ) должны обеспечивать реализацию следующих функций классов БИИС, СМИС и НИИС (согласно классификации по п. 3.1.):

-  прием и проверку структурно-экономических описаний (паспортов) ЛПУ, СКУ и МУЗ, расположенных на территории, подведомственной данной организации; ведение сводной базы данных паспортов ЛПУ и формирование запросов к этой базе;

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

-  прогнозирование заболеваемости населения данной территории;

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

-  прием и агрегирование статистической информации от подведомственных ЛПУ.

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

3.3.8. Функциональные подсистемы ИС Федерального Фонда ОМС и территориальных фондов ОМС должны обеспечивать реализацию следующих функций:

-  персонального учета зарегистрированных по ОМС лиц;

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

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

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

-  учета взносов по ОМС;

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

-  ведения базы данных паспортов ЛПУ и формирования запросов к этой базе;

-  ведения сводных регистров: лиц, застрахованных по ОМС, договоров, предприятий-плательщиков.

3.3.9. Функциональные подсистемы ИС МУЗ должны обеспечивать подготовку и переподготовку специалистов по медицинским специальностям.

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

В частности, ИС МУЗ должны обеспечивать решение задач:

1.  Интенсивного компьютерного обучения.

2.  Дистанционного обучения.

Подсистемы ИС, обслуживающие клинические отделения МУЗ, должны обеспечивать те же функции, что и ИС ЛПУ, перечисленные в п. 3.3.5.

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

3.4.1. Информационное взаимодействие информационных систем.

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

- ЛПУ – ЛПУ/СКУ:

– по функциям обмена персональными данными о пациентах (данные по регистрации пациентов, медицинские карты, данные из медико-технологических систем ЛПУ), по функциям информационного обеспечения процессов профилактики, диагностики, лечения и реабилитации больных;

- ЛПУ – ОТУЗ/МУВ:

a)  по функциям формирования паспортов ЛПУ и ведения сводных баз данных паспортов ЛПУ;

b)  по функциям учета и планирования материальных и финансовых ресурсов;

c)  по функциям формирования и представления государственной медицинской статистической отчетности;

d)  по функциям сбора и обработки медицинской статистики;

e)  по функциям учета иммунопрофилактики (БД сделанных прививок);

f)по функциям ведения НСИ;

g)  по ведению фармакологических БД и учету льготных лекарств;

h)  по функциям медико-социальной реабилитации инвалидов.

- ЛПУ – ТФОМС/ СМО:

a)  по функциям персонального учета пациентов, застрахованных по ОМС;

b)  по функциям учета медицинской помощи, оказанной по ОМС;

c)  организации взаиморасчетов по ОМС;

d)  расчета норм и тарифов на оплату медицинской помощи по ОМС;

e)  по функциям ведения НСИ в области ОМС.

- ГСЭН – ОТУЗ:

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

- Минздрав России – ОТУЗ/МУВ – ГСЭН :

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

- МУЗ – ЛПУ:

a)  по функциям телемедицины, доступа в Интернет;

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

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

Таблица 3

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

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

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

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

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

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

3.4.2.1. Средства интеграции на уровне «приложение – приложение»

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

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

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

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

Для взаимодействия приложений ИС должны применяться унифицированные форматы обмена данными согласно стандарту организации СТО МОСЗ 91500.16. «Информационные системы в здравоохранении. Общие требования к форматам обмена информацией».

3.4.2.2. Средства интеграции приложений – службы ПО промежуточного слоя (middleware)

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

Услуги, предоставляемые приложениям со стороны ПО промежуточного слоя, должны быть специфицированы в проектной документации ИС в виде стандартных интерфейсов прикладного программирования (API) для служб ПО промежуточного слоя - вызова удаленных процедур – RPC (Remote Procedure Call - вызов удаленной процедуры); обмена сообщениями – MOM (Messaging Oriented Middleware - ПО промежуточного слоя, ориентированное на сообщения);, посредников (брокеров) запросов к объектам (ORB), мониторов обработки транзакций (TPM).

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

3.4.2.3. Средства интеграции данных

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

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

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

3.4.2.4. Средства интеграции платформ в гетерогенных сетевых средах

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

Клиенты и серверы могут быть реализованы на базе различных аппаратно-программных платформ, т. е. опираться на разные машинные архитектуры и операционные системы. В таких случаях в составе взаимодействующих. ИС должны быть предусмотрены средства интеграции приложений, которые выполняются на аппаратно-программных платформах под управлением операционных систем Windows NT/2000 и операционных систем типа Unix/Linux, соответствующих стандартам для среды выполнения приложений. На этом уровне для интеграции приложений в составе системного ПО ИС должны быть средства интеграции разных платформ в гетерогенных сетях.

3.4.2.5. Средства интеграции компонентов в составе приложений информационных систем

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

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

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

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

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

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

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

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

Для компонентной разработки корпоративных приложений ИС, включающих в себя распределенные серверные и клиентские компоненты, должны использоваться интегрированные среды разработки и выполнения распределенных компонентов (Distributed Component Platform – DCP), поддерживающие сложившиеся «де-факто» стандарты компонентов:

-  спецификации COM/DCOM (Component Object Model - компонентная объектная модель / Distributed Component Object Model - распределенная компонентная объектная модель) корпорации Microsoft;

-  спецификации EJB (Enterprise Java Beans) с протоколом RMI (Java Remote Method Invocation - протокол вызова удаленного метода на языке Java – аналог протокола RPC для распределенных объектных Java-приложений) фирмы Sun Microsystems;

-  спецификации компонентов в архитектуре CORBA (Common Object Request Broker Architecture - общая архитектура брокера объектных запросов), поддерживаемые консорциумом OMG (Object Management Group - Консорциум "Группа управления объектами");

-  стандарты компонентной разработки Web- приложений, предложенные консорциумом W3C (World Wide Web Consortium - консорциум "Всемирной паутины" – сети Интернет).

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

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

В ИС здравоохранения, как правило, должен быть реализован графический интерфейс пользователя. Реализация графического интерфейса пользователя должна опираться на соответствующие средства операционных систем автоматизированных рабочих мест пользователей ИС (клиентов), описанные в спецификациях этих ОС: Motif для ОС типа Unix, Win32 для Windows 95/98/2000, а также в спецификациях интерфейса Web-браузеров.

Общие требования к конструированию интерфейса пользователя представлены в серии международных стандартов ISO 9241 «Ergonomic requirements for office work with visual display terminals», серии стандартов ISO 13407 «Human – centered design processes for interactive systems» и серии стандартов ISO 14915 «Software ergonomics for multimedia user interfaces».

Настоящий документ определяет две группы требований к пользовательскому интерфейсу:

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

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

Для поддержки графического пользовательского интерфейса клинические ИС ЛПУ должны обеспечивать:

1)  доступ лечащим врачам и специалистам по диагностике к сведениям о пациентах, накапливаемым в базах данных медицинских карт («электронных историй болезни») путем сбора этих данных из многих разнородных источников (подсистем ИС ЛПУ регистрации и движения пациентов, медико-технологических подсистем диагностических отделений и центров, подсистем лабораторного анализа и т. д.);

2)  возможность получать данные из этих источников и размещать их в своих базах данных; возможность переадресовать своего пользователя к другому источнику информации (информационному ресурсу корпоративной сети Интернет), например, к Web–сайту другого госпиталя или к другому приложению, функционирующему в локальной вычислительной сети ЛПУ;

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

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

Клинический контекст может, например, описывать:

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

-  идентификацию пользователя ИС, которому нужны данные, формируемые разными приложениями ИС;

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

-  идентификацию диагностического или лечебного назначения;

-  идентификацию места лечения пациента;

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

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

-  межкомпонентного взаимодействия на основе моделей COM/DCOM фирмы Microsoft;

-  брокеров запросов объектов (ORB), совместимых со спецификацией CORBA 2.0 консорциума OMG;

-  любых языков программирования, поддерживающих OLE Automation/Active X фирмы Microsoft и взаимодействие объектов архитектуры CORBA;

-  платформ, обеспечивающих работу виртуальной машины Java.

В ИС ЛПУ должны быть реализованы компоненты и интерфейсы управления клиническим контекстом.

Интерфейс пользователя в ИС ЛПУ должен обеспечивать общий клинический контекст в виде сеанса доступа, в котором участвуют:

-  авторизованный пользователь;

-  приложение ИС;

-  менеджер контекста;

-  системный администратор.

В качестве основы для детализации общих требований к пользовательскому интерфейсу ИС ЛПУ может быть использован американский стандарт HL7 «Context Management Specification technology and Subject independent Component Architecture, Version CM 1.4» (Спецификация управления клиническим контекстом и компонентная архитектура, независимая от описываемого предмета. Рабочая группа по объектам клинического контекста американского Института стандартизации (ANSI CCOW)).

3.6. Требования к ведению медицинской документации

ИС ЛПУ должны обеспечивать ведение медицинской документации (медицинских карт больных в стационарных и амбулаторных условиях) в электронном виде. В ИС ЛПУ должны поддерживаться стандартные протоколы ведения больных в соответствии с документами, принятыми в установленном порядке.

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

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

Основными требованиями, предъявленными к НСИ, являются:

-  структурирование данных: необходимость структурирования и иерархической организации элементов базы данных НСИ;

-  адаптация и развитие: учет возможности постоянного пополнения и обновления базы данных НСИ по мере принятия новых нормативно-справочных документов;

-  совместимость: обеспечение возможности взаимодействия различных подсистем НСИ;

-  стандартизация и унификация: необходимость применения типовых, унифицированных и стандартизованных элементов построения системы НСИ;

-  непротиворечивость и полнота НСИ;

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

-  обеспечение доступа конечных пользователей ИС к базе данных НСИ.

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

3.8. Требования к структуре классификаторов и справочников

Справочник в системе НСИ должен представлять собой структуру вида:

< код понятия > < наименование понятия >.

Классификатор в системе НСИ должен представлять собой иерархическую структуру понятий вида: < код понятия > < наименование понятия > < код старшего понятия > < признак подуровня >.

3.9. Состав классификаторов и справочников

В ИС здравоохранения должны поддерживаться классификаторы, справочники и перечни, утвержденные в установленном порядке:

-  общероссийские - единые для всех учреждений здравоохранения в Российской Федерации;

-  территориальные - единые для территории (региона) Российской Федерации;

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

В состав общероссийских справочников и классификаторов включаются следующие группы:

-  справочники, идентифицирующие субъекты здравоохранения и ОМС;

-  справочники формирования паспортов ЛПУ;

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

-  справочники учета застрахованных (пациентов).

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

-  справочники субъектов здравоохранения и ОМС;

-  справочники организации взаиморасчетов.

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

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

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

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

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

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

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

3.10. Общие нормативно-справочные файлы информационных систем в здравоохранении

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

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

Экземпляры нормативно-справочного файла в системе необходимо синхронизировать. Для описания диаграммы классов объектной модели предметной области нормативно-справочных файлов рекомендуется применять универсальный язык моделирования UML по стандарту консорциума OMG.

Для представления модели нормативно-справочных файлов в ИС, с которыми должны работать приложения, должен быть разработан частный нормативный документ, за основу которого следует взять главу 8 стандарта ANSI HL7, версии 2.4, и стандарт ISO 17113, 2000, (приложение С).

Пример поддержки нормативно-справочных файлов при помощи языка UML приведен в справочном приложении Б к настоящему документу.

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

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

ИС ЛПУ, СМО, СКУ должны обеспечивать взаимодействие с карточными системами чтения и обновления информации на индивидуальных персонифицированных картах пациентов.

ИС ОТУЗ (МУВ) и ИС ЛПУ должны обеспечивать взаимодействие с карточными системами чтения и обновления информации на индивидуальных персонифицированных картах медицинских работников.

ИС ОТУЗ (МУВ) должны обеспечивать взаимодействие с системами персонализации индивидуальных карт медицинских работников.

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

Структура хранения данных на индивидуальных картах пациентов должна соответствовать стандартам ISO «Health informatics - Patient healthcard data - Parts 1-7» (по мере принятия решений об их введении в России). За основу структуры данных на индивидуальных картах медицинских работников можно принять спецификацию Германской карточки медицинского работника (врача), версия 1.0., разработанную объединенной рабочей группой Национальной ассоциации врачей общей практики и Германской медицинской ассоциации (июль 1999 г.).

4. Требования информационной безопасности ИНФОРМАЦИОННЫХ СИСТЕМ в здравоохранении

4.1. Общие требования

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

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

-  политика информационной безопасности;

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

-  образование и тренинг персонала по информационной безопасности;

-  отчетность по инцидентам с безопасностью;

-  защита от вирусов;

-  обеспечение непрерывности работы ИС;

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

-  защита архивной документации организации / учреждения;

-  защита персональных данных;

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

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

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

4.2. Защита информации от несанкционированного доступа

ИС здравоохранения должны иметь средства защиты информации от несанкционированного доступа в соответствии с руководящим документом (РД) Гостехкомиссии при Президенте РФ «Классификация автоматизированных систем и требования по защите информации», 1997 г.

В зависимости от уровня конфиденциальности информации, подлежащей защите от несанкционированного доступа, класс ИС должен быть выбран из 1Д, 1Г, 1В, 1Б, 1А указанного РД Гостехкомиссии.

Под защитой информации в настоящем документе понимается комплекс мер по:

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

b)  предотвращению угроз безопасности личности, общества, государства;

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

d)  обеспечению правового режима документированной информации как объекта собственности;

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

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

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

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

Режим защиты информации устанавливается на основании Закона Российской Федерации «О государственной тайне»:

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

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

- в отношении персональных данных - данным федеральным законом (ст. 21).

4.3. Конфиденциальная информация в информационных системах в здравоохранении

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

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

4.4. Требования к электронной цифровой подписи

При обмене данными между ИС здравоохранения в обоснованных случаях должна применяться электронная цифровая подпись (ЭЦП) по ГОСТ Р 34.10-2001 «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи».

Под электронной цифровой подписью в настоящем документе понимают:

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

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

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

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

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

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

-  создание закрытых и открытых ключей электронных цифровых подписей.

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

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

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

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

4.5. Средства шифрования данных при передаче по открытым каналам

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

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

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

4.5.2. Средства защиты от вирусов

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

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

-  сканирование;

-  онлайновый мониторинг;

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

-  обнаружение неизвестных вирусов и вирусов-невидимок;

-  контроль подозрительного поведения узлов сети.

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

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

В составе средств антивирусной защиты должны быть предусмотрены три категории антивирусного ПО:

-  для конечных пользователей;

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

-  для системных и сетевых администраторов.

5. Требования к системотехнической структуре ИНФОРМАЦИОННЫХ СИСТЕМ в здравоохранении

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

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

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

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

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

- требования к программным средствам ПО промежуточного слоя, в частности, в соответствии со спецификациями среды распределенных вычислений DCE консорциума The Open Group, или спецификациями архитектуры CORBA консорциума OMG;

-  требования к операционным системам серверов и клиентов: Windows – по спецификациям Win 32 корпорации Microsoft и Unix – по совокупности стандартов POSIX (Portable Operating System Interface - интерфейс переносимой операционной системы) ИСО/МЭК и IEEE (Institute of Electrical and Electronic Engineers - Институт инженеров по электротехнике и электронике);

-  требования к аппаратным средствам ИС;

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

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

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

Методологическую основу построения функциональных профилей ИС определяет ГОСТ Р ИСО/МЭК ТО 10000 «Информационная технология. Основы и таксономия функциональных стандартов». Часть 3 этого документа описывает эталонную модель среды открытых систем OSE/RM, которая разделяет любую ИС на два крупных слоя: приложения и среду функционирования приложений. Между приложениями и средой определяются стандартизованные интерфейсы прикладного программирования (API), специфицирующие услуги среды, предоставляемые приложениям. Именно эти интерфейсы составляют основные объекты стандартизации в функциональных профилях ИС.

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

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

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

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

ФС не следует присваивать категорию выше, чем категория БС, на основе которых он построен.

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

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

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

-  разработки ПС;

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

-  документирования ПС;

-  обеспечения качества ПС.

Эти документы должны учитывать результаты адаптации ГОСТ Р ИСО/МЭК 12207 применительно к условиям создания, сопровождения и развития ИС в здравоохранении.

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

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

Для поддержки процессов системного анализа и проектирования ИС должны быть выбраны и документированы методология и инструментальные средства. В качестве методологической основы могут быть рекомендованы унифицированный язык моделирования UML (Unified Modeling Language) по стандарту Консорциума OMG и инструментальные средства, поддерживающие унифицированный процесс проектирования RUP по спецификациям фирмы Rational Software.

В справочном приложении Г к настоящему документу приведены объекты стандартизации, связанные с поддержкой процессов создания, сопровождения и развития ИС.

Информационные технологии - http://www. *****/