ТЗ СИМИ ЕМИАС

ДЕПАРТАМЕНТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ ГОРОДА

МОСКВЫ

СОГЛАСОВАНО Должность

______________________Х.Х. ХХХХ (личная подпись) (расшифровка подписи)

«___» ______________20ХХ г

УТВЕРЖДАЮ Должность


«___» ______________20ХХ г

СИСТЕМА ИНТЕГРИРОВАННОЙ МЕДИЦИНСКОЙ ИНФОРМАЦИИ

ЕДИНОЙ МЕДИЦИНСКОЙ ИНФОРМАЦИОННО-АНАЛИТИЧЕСКОЙ

СИСТЕМЫ ГОРОДА МОСКВЫ

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

66469537.4251801.001.ТЗ

Версия 0.5

СОГЛАСОВАНО Представители организации

Разработчика Должность


«___» ______________20ХХ г

Должность


«___» ______________20ХХ г

2012

ДЕПАРТАМЕНТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

ГОРОДА МОСКВЫ

Утвержден

66469537.4251801.001.ТЗ-ЛУ

СИСТЕМА ИНТЕГРИРОВАННОЙ МЕДИЦИНСКОЙ

ИНФОРМАЦИИ ЕДИНОЙ МЕДИЦИНСКОЙ ИНФОРМАЦИОННО-

АНАЛИТИЧЕСКОЙ СИСТЕМЫ ГОРОДА МОСКВЫ

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

66469537.4251801.001.ТЗ

Листов 95

Версия 0.5

2012

Департамент

Информационных

Технологий

Страница 2 из 95

АННОТАЦИЯ

В настоящем документе определены требования и порядок создания автоматизированной

системы (АС) «Система интегрированной медицинской информации Единой медицинской

информационно-аналитической системы города Москвы» (СИМИ ЕМИАС), в соответствии с

которыми будет проводиться разработка АС и еѐ приѐмка при вводе в эксплуатацию.





СОДЕРЖАНИЕ

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

1.1. Полное наименование системы и ее условное обозначение ......... 15

1.2. Номер договора .................................................................................. 15

1.3. Наименования предприятий разработчика и заказчика системы . 15

1.4. Перечень документов, на основании которых создается система 16

1.5. Плановые сроки начала и окончания работы по созданию системы

16

1.6. Сведения об источниках и порядке финансирования работы по

созданию системы ...................................................................................................... 16

1.7. Порядок оформления и предъявления заказчику результатов работ

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

(технических, программных, информационных) и программно-технических

(программно-методических) комплексов системы ................................................ 16

2. Назначение и цели создания системы ........................................................ 18

2.1. Назначение системы .......................................................................... 18

2.2. Цели создания системы ..................................................................... 20

3. Характеристика объектов автоматизации ................................................. 23

3.1. Краткие сведения об объекте автоматизации ................................. 23

3.2. Сведения об условиях эксплуатации объекта автоматизации и

характеристиках окружающей среды ...................................................................... 24

4. Требования к системе .................................................................................. 25

4.1. Требования к системе в целом.......................................................... 25

4.1.1. Требования к структуре и функционированию системы .............. 25

4.1.1.1. Перечень подсистем, их назначение и основные характеристики .......... 25

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

между компонентами системы ............................................................................................... 30

4.1.1.3. Требования к характеристикам взаимосвязей создаваемой системы со

смежными системами .............................................................................................................. 30





4.1.1.4. Требования к режимам функционирования системы ............................... 31

4.1.1.5. Требования по диагностированию системы .............................................. 32

4.1.1.6. Перспективы развития. Модернизация системы ....................................... 33

4.1.2. Требования к численности и квалификации персонала системы и

режиму его работы ..................................................................................................... 34

4.1.3. Показатели назначения ..................................................................... 36

4.1.4. Требования к надѐжности ................................................................. 38

4.1.4.1. Восстановление при аварийных ситуациях ............................................... 38

4.1.4.2. Надѐжность программного обеспечения .................................................... 38

4.1.4.3. Надѐжность технических средств ............................................................... 40

4.1.5. Требования безопасности ................................................................. 40

4.1.6. Требования к эргономике и технической эстетике ........................ 40

4.1.7. Требования к транспортабельности системы ................................. 41

4.1.8. Требования к эксплуатации, техническому обслуживанию, ремонту

и хранению компонентов системы ........................................................................... 41

4.1.9. Требования к защите информации от несанкционированного

доступа 42

4.1.10. Требования по сохранности информации при авариях ................. 46

4.1.11. Требования к защите от влияния внешних воздействий ............... 47

4.1.12. Требования к патентной чистоте ...................................................... 48

4.1.13. Требования по стандартизации и унификации ............................... 48

4.1.14. Дополнительные требования ............................................................ 49

4.2. Требования к функциям, выполняемым системой ......................... 49

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

4.2.1.1. Подсистема хранилища СЭМД ................................................................... 49

4.2.1.2. Требования к подсистеме управления регистром иЭМК ......................... 50

4.2.1.3. Требования к подсистеме хранилища структурированных данных СЭМД 50





4.2.1.4. Требования к подсистеме управления НСИ .............................................. 50

4.2.1.5. Требования к подсистеме хранилища протоколов .................................... 51

4.2.1.6. Требования к подсистеме администрирования ......................................... 52

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

безопасности 52

4.2.1.8. Требования к подсистеме интеграции ........................................................ 55

4.2.1.9. Требования к подсистеме диагностики ...................................................... 56

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

информации 56

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

56

4.2.4. Требования к интерфейсу пользователя .......................................... 57

4.3. Требования к видам обеспечения ..................................................... 58

4.3.1. Требования к математическому обеспечению системы ................ 58

4.3.2. Требования к информационному обеспечению системы .............. 58

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

58

4.3.2.2. Требования к информационному обмену между компонентами системы 63

4.3.2.3. Требования к информационной совместимости со смежными системами 64

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

отраслевых классификаторов, унифицированных документов и классификаторов,

действующих на данном предприятии .................................................................................. 64

4.3.2.5. Требования по применению систем управления базами данных ............ 65

4.3.2.6. Требования к структуре процесса сбора, обработки, передачи данных в

системе и представлению данных .......................................................................................... 65

4.3.2.7. Требования к защите данных от разрушений при авариях и сбоях в

электропитании системы ......................................................................................................... 65





4.3.2.8. Требования к контролю, хранению, обновлению и восстановлению данных

65

4.3.3. Требования к лингвистическому обеспечению системы .............. 66

4.3.4. Требования к программному обеспечению системы ..................... 66

4.3.4.1. Прикладное программное обеспечение ...................................................... 66

4.3.4.2. Системное программное обеспечение ........................................................ 68

4.3.5. Требования к техническому обеспечению системы ...................... 71

4.3.6. Требования к метрологическому обеспечению системы .............. 72

4.3.7. Требования к организационному обеспечению системы .............. 72

4.3.8. Требования к методическому обеспечению системы .................... 72

5. Требования К составу и содержанию работ по созданию (развитию)

системы 73

5.1. Перечень этапов работ по созданию системы и их документирование

73

5.2. Содержание работ первого этапа ..................................................... 74

5.2.1. Проектный офис ................................................................................. 75

5.2.2. Научно-исследовательские работы .................................................. 75

5.2.3. Разработка частных технических заданий ...................................... 76

5.2.4. Разработка модели нарушителя и угроз ИБ .................................... 77

5.2.5. Разработка прототипа ........................................................................ 78

5.2.6. Разработка технического проекта .................................................... 79

5.2.7. Разработка плана релизов ................................................................. 79

5.3. Содержание работ второго этапа ..................................................... 79

5.3.1. Разработка программного обеспечения ........................................... 79

5.3.2. Разработка эксплуатационной документации ................................ 79

5.3.3. Выпуск релизов (версий) СИМИ ЕМИАС ...................................... 80

5.4. Содержание работ третьего этапа .................................................... 80

6. Порядок контроля и приѐмки системы ...................................................... 82





7. Требования к составу и содержанию работ по подготовке объекта

автоматизации к вводу системы в действие ............................................................... 85

7.1. Техническая подготовка к вводу системы в действие ................... 85

7.1.1. Основные мероприятия со стороны Заказчика ............................... 85

7.1.2. Основные мероприятия со стороны Исполнителя ......................... 85

7.1.3. Основные мероприятия с привлечением прочих участников ....... 86

7.2. Организационная, методическая подготовка к вводу системы в

действие 86

8. Требования к документированию .............................................................. 88

9. Источники разработки ................................................................................. 89

Приложение 1. Перечень законодательных актов и методологических

рекомендаций в части обеспечения информационной безопасности ...................... 93

Список изменений ............................................................................................... 95





ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ

АВТОМАТИЗИРОВАННАЯ

СИСТЕМА (АС)

Система, состоящая из персонала и комплекса средств

автоматизации его деятельности, реализующая

информационную технологию выполнения

установленных функций (ГОСТ 34.003).

АВТОРИЗАЦИЯ Предоставление определѐнному лицу или группе лиц

прав на выполнение определѐнных действий, а также

процесс проверки (подтверждения) данных прав при

попытке выполнения этих действий (см. «Руководящий

документ. Руководство по разработке профилей защиты

и заданий по безопасности». Гостехкомиссия России,

2003 год).

АУТЕНТИФИКАЦИЯ Проверка принадлежности субъекту доступа

предъявленного им идентификатора; подтверждение

подлинности. («Руководящий документ. Защита от

несанкционированного доступа к информации. Термины

и определения», утверждѐн решением председателя

Гостехкомиссии России от 30 марта 1992 г.).

АРХИТЕКТУРА СИСТЕМЫ Организационная структура системы, в которой

идентифицированы компоненты, их интерфейсы и

концепция взаимодействия между ними.

СТАНДАРТИЗИРОВАННЫЙ

ЭЛЕКТРОННЫЙ

МЕДИЦИНСКИЙ

ДОКУМЕНТ (СЭМД)

Структурированный документ, сформированный в ходе

оказания медицинской услуги, используемый для

передачи и хранения медицинской информации о

пациенте в определѐнной совокупности

взаимодействующих систем.

СЭМД содержит заголовок и заполненный протокол,

содержащий данные о выполненном или

запланированном медицинском мероприятии, включая

обследования, осмотры, лабораторные исследования,





процедуры, операции, пребывание в стационаре,

назначения, и другое. Заполненный протокол может

также содержать данные о льготном лекарственном

обеспечении, информированном согласии пациента,

другую медицинскую информацию.

ИНТЕГРИРОВАННАЯ

ЭЛЕКТРОННАЯ

МЕДИЦИНСКАЯ КАРТА

(ИЭМК)

Совокупность СЭМД по всем случаям обращения,

относящимся к одному пациенту независимо от ЛПУ,

где они были сделаны.

ПЕРСОНАЛЬНАЯ

МЕДИЦИНСКАЯ ЗАПИСЬ

(ПМЗ)

Любая запись, имеющая отношение к состоянию

здоровья конкретного человека и выполненная

конкретным лицом, отвечающим за содержание этой

записи; запись также характеризуется конкретным

контекстом и моментом выполнения этой записи. ПМЗ

могут быть типизированы в соответствии с содержанием

записи.

ЭЛЕКТРОННАЯ

ПЕРСОНАЛЬНАЯ

МЕДИЦИНСКАЯ ЗАПИСЬ

(ЭПМЗ)

Персональная медицинская запись, сохранѐнная на

электронном носителе информации.

Далее в данном документе используется термин

Протокол в следующем значении: структура данных

ЭПМЗ определѐнного типа, состоящая из параметров

протокола, объединѐнных в группы параметров, которая

используется для формирования СЭМД.

Структура протокола определяется в DI (Developer

Interface) – конструкторе параметров протоколов, групп

параметров протоколов, протоколов и связанных с ними

экранных и печатных форм.

ПАРАМЕТР ПРОТОКОЛА Минимальная логическая, информационная и

структурная единица протокола. Может использоваться

в разных протоколах и в разных группах параметров

протокола.

Имеет определѐнный тип данных и может иметь набор

дополнительных свойств, таких как значение по





умолчанию, референсные значения, область

применения, другие.

Между значениями параметров протокола может быть

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

ГРУППА ПАРАМЕТРОВ

ПРОТОКОЛА

Совокупность параметров протокола и/или групп

параметров протоколов, объединѐнных в соответствии с

их информационной нагрузкой. Группа параметров

протокола может использоваться в разных протоколах.

ШАБЛОН Вариант (несколько вариантов) заполнения значений

параметров протокола. Может быть определѐн на уровне

отдельного пользователя или отделения.

ГОСУДАРСТВЕННОЕ

УЧРЕЖДЕНИЕ

ЗДРАВООХРАНЕНИЯ (ГУЗ)

Общее название медицинских учреждений,

оказывающих первичную медико-санитарную помощь,

паллиативную помощь, специализированную (в том

числе высокотехнологичную медицинскую помощь),

скорую (в том числе скорую специализированную)

медицинскую помощь.

В системе здравоохранения города Москвы выделяются

два уровня ГУЗ: территориальные ГУЗ (первичная

медико-санитарная и паллиативная помощь), и

специализированные ГУЗ.

В данном документе применяется также термин

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

ОБЩЕГОРОДСКОЙ

ИНФОРМАЦИОННЫЙ

СЕРВИС

Совокупность основных и обеспечивающих процессов,

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

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

на организацию оказания медицинской помощи, а также

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

помощи.

СЕРВИС Программный компонент, оснащѐнный





стандартизированным интерфейсом для взаимодействия

по стандартизированному протоколу, реализующий

определѐнный набор функций системы.

WEB-СЕРВИС Идентифицируемая веб-адресом программная система

со стандартизированными интерфейсами,

описываемыми WSDL. Веб-сервисы могут

взаимодействовать друг с другом и со сторонними

приложениями посредством сообщений, основанных на

протоколе SOAP. Веб-сервис может использоваться как

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

ориентированной архитектуры приложения.

СЛУЧАЙ ОБРАЩЕНИЯ Посещение (одно или несколько) амбулаторно-

поликлинического учреждения (с целью проведения

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

диагностического мероприятия), или случай

госпитализации.

Соответствует понятию «Эпизод» в терминологии

Приложения 4 к постановлению 513-ПП.

Может быть (с оговорками) соотнесено с понятием

«Визит» (encounter) в терминологии ГОСТ Р ИСО/ТО

20514-2009 «Информатизация здоровья. Электронный

учѐт здоровья. Определение, область применения и

контекст» (ENV 13940:2001) (―Контакт, в ходе которого

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

в его присутствии и осуществляется доступ или

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

здоровья»).

ФАКТОГРАФИЧЕСКАЯ

ИНФОРМАЦИЯ

Описание фактов, относящихся к состоянию здоровья

пациента, сгруппированных по определѐнным

системообразующим признакам.

http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F_%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B9

http://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%82%D0%B5%D0%B2%D0%BE%D0%B9_%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB

http://ru.wikipedia.org/wiki/%D0%92%D0%B5%D0%B1

http://ru.wikipedia.org/wiki/URI

http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D1%82%D0%B5%D1%80%D1%84%D0%B5%D0%B9%D1%81

http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80%D0%BD%D0%B0%D1%8F_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0

http://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D1%83%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)

http://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%80%D0%B2%D0%B8%D1%81-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%B0%D1%8F_%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0

http://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%80%D0%B2%D0%B8%D1%81-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%B0%D1%8F_%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0









ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ

АРМ Автоматизированное рабочее место

АС Автоматизированная система

БД

БМИ

База данных

Базовая межведомственная инфраструктура

ЕМИАС Единая медицинская информационно-аналитическая система

ГУЗ Государственное учреждение здравоохранения

ИБП Источник бесперебойного питания

ИС Информационная система

иЭМК Интегрированная электронная медицинская карта

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

МГ ФОМС Московский городской Фонд обязательного медицинского страхования

МИС Медицинская информационная система

НИР Научно-исследовательские работы

ПО Программное обеспечение

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

РЕИС Региональная единая информационная система

СВТ Средства вычислительной техники

СИМИ Система интегрированной медицинской информации

СУБД Система управления базами данных

СУПП Система управления потоками пациентов

СХД Система хранения данных

СЭМД Стандартизированный электронный медицинский документ

ТЗ Техническое задание

ТС Технические средства

ФОМС Фонд обязательного медицинского страхования

ЦОД Центр обработки данных

ЧТЗ Частное техническое задание

ЭП Электронная подпись

DI Developer Interface (интерфейс разработчика для конфигурирования Системы)

PDA Personal Digital Assistant (карманный персональный компьютер)

SOAP Протокол обмена структурированными сообщениями в распределѐнной

вычислительной среде

SSL Secure Socket Layer (уровень защищѐнных сокетов)





UI User Interface (пользовательский интерфейс)

VPN Virtual Private Network (виртуальная частная сеть)

WORM Write Once, Read Manу (однократная запись, многократное чтение)

WSDL Web Services Description Language (язык описания web-сервисов)





1. ОБЩИЕ СВЕДЕНИЯ

1.1. Полное наименование системы и ее условное обозначение

Полное наименование Системы: Система интегрированной медицинской информации

Единой медицинской информационно-аналитической системы города Москвы.

Условное обозначение Системы: СИМИ ЕМИАС.

Далее по тексту также используется сокращенное условное обозначение, «СИМИ» и

«Система».

1.2. Номер договора

Договор № ХХ от ХХ.ХХ.ХХХХ г. между Департаментом информационных технологий г.

Москвы и «Название предприятия разработчика Системы».

1.3. Наименования предприятий разработчика и заказчика системы

Предприятие разработчик: Названия предприятие разработчика системы

Реквизиты предприятия разработчика:

Индекс, Страна, Город, ул., д.,к., ИНН: ХХХХХХХХХХ, КПП: ХХХХХХХХХ,

тел. 8 (499/495) ХХХ-ХХ-ХХ

Р/счет (Л/c) № номер счета в «Название банка»

К/счет (Р/с) № номер счета

БИК ХХХХХХХХХ

Предприятие заказчик: Департамент информационных технологий города Москвы

Реквизиты предприятия заказчика:

107078, Россия, Москва, ул. Новая Басманная, д.10, строение 1

ИНН: 7710878000

КПП: 770101001

тел. +7(495) 957-75-42

Л/счет № 0381111000451187 в Отделении 1 Московского ГТУ Банка России г. Москва 705

Р/счет № 40201810200000000001

БИК 044583001





1.4. Перечень документов, на основании которых создается система

Система создается на основании следующих документов:

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

здравоохранения;

Программа модернизации здравоохранения города Москвы на 2011-2012 годы;

Постановление Правительства Москвы от 27.10.2011 № 513-ПП и Приложение 4 к

этому постановлению;

Договор № ХХ от ХХ.ХХ.ХХХХ г. между Департаментом информационных технологий

города Москвы и «Название предприятия разработчика Системы».

1.5. Плановые сроки начала и окончания работы по созданию системы

Плановые сроки начала работ по созданию Системы: ХХ.ХХ.ХХХХ/

Плановые сроки окончания работ по созданию Системы: ХХ.ХХ.ХХХХ/

Общая продолжительность выполнения работ не должна превышать 510 дней (не менее 350

дней).

1.6. Сведения об источниках и порядке финансирования работы по

созданию системы

Финансирование работ осуществляется в соответствии с Договором № ХХ от

ХХ.ХХ.ХХХХ г. между Департаментом информационных технологий города Москвы и «Название

предприятия разработчика Системы».

Источник финансирования – бюджет города Москвы.

Порядок финансирования работ определяется в соответствии с нормативно-правовыми

актами города Москвы, регулирующими вопросы финансирования расходов городского бюджета

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

1.7. Порядок оформления и предъявления заказчику результатов работ

по созданию системы (ее частей), по изготовлению и наладке

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

и программно-технических (программно-методических) комплексов

системы

По завершению работ по каждому этапу работ в соответствии с перечнем этапов,

приведѐнном в разделе 5.1 и в сроки, определенные в календарном плане Договора № ХХ от

ХХ.ХХ.ХХХХ г. между Департаментом информационных технологий города Москвы и «Название





предприятия разработчика Системы», Исполнитель предоставляет Заказчику Системы результаты

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

технического задания (ТЗ), а также подписанный со стороны разработчика Акт сдачи-приѐмки

работ.

Документация передаѐтся Исполнителем на бумажных (в двух экземплярах) и машинных

(CD|DVD) носителях; исходный и скомпилированный код программного обеспечения Системы

передаѐтся на машинных носителях. Документы на машинных носителях должны быть

представлены в формате MS Office.

Все материалы должны быть переданы с сопроводительными документами Исполнителя.





2. НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ

2.1. Назначение системы

В соответствии с Программой модернизации здравоохранения города Москвы на 2011-2012

годы, и в рамках Государственной программы города Москвы 2012-2016 годы «Развитие

здравоохранения города Москвы (Столичное здравоохранение)» должен быть создан

Региональный фрагмент Единой государственной информационной системы в здравоохранении

(ЕГИСЗ) города Москвы – Региональная Единая Информационная Система (РЕИС). РЕИС

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

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

фрагментом ЕГИСЗ, так и с общегородской информационной инфраструктурой города Москвы.

Региональный фрагмент ЕГИСЗ должен охватывать медицинские организации амбулаторного и

стационарного типа, подведомственные Департаменту здравоохранения города Москвы, и

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

здравоохранения.

Основными композиционными элементами РЕИС прикладного уровня должны быть

Общегородские информационные сервисы Единой медицинской информационно-аналитической

системы (ЕМИАС) города Москвы, размещѐнные на инфраструктуре Центра обработки данных

(ЦОД) ЕМИАС, и совокупность медицинских информационных систем (МИС), размещенных на

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

Концептуальная архитектура РЕИС, определѐнная в Приложении №4 к постановлению

Правительства Москвы от 27.10.2011 № 513-ПП, представлена на Рисунке 1.





БАЗОВЫЙ КОНТУР БЕЗОПАСНОСТИ РЕИС

ОБЩЕГОРОДСКИЕ ИНФОРМАЦИОННЫЕ СЕРВИСЫ ЕМИАС

ИНТЕГРАЦИОННАЯ ШИНА

СИ

СТЕ

МА

КО

НС

ОЛ

ИД

ИР

ОВ

АН

НО

ГО

УП

РА

ВЛ

ЕНЧ

ЕСК

ОГО

УЧ

ЕТА

СИ

СТЕ

МА

ПЕР

СО

НИ

ФИ

ЦИ

РО

ВА

НН

ОГО

У

ЧЕТ

А М

ЕДИ

ЦИ

НС

КО

Й П

ОМ

ОЩ

И

СИ

СТЕ

МА

ИН

ТЕГР

ИР

ОВ

АН

НО

Й

МЕД

ИЦ

ИН

СК

ОЙ

ИН

ФО

РМ

АЦ

ИИ

СИ

СТЕ

МА

УП

РА

ВЛ

ЕНИ

Я П

ОТО

КА

МИ

П

АЦ

ИЕН

ТОВ

ИНТЕГРАЦИОННЫЙ ШЛЮЗ

ОБЩЕГОРОДСКОЙ РЕГИСТР

ПАЦИЕНТОВ (МГ ФОМС)

ПОДСИСТЕМА ФОРМИРОВАНИЯ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА

ПОДСИСТЕМА ИНТЕГРАЦИИ МИС

СИ

СТЕ

МА

УП

РА

ВЛ

ЕНИ

Я

МЕД

ИЦ

ИН

СК

ИМ

И Р

ЕГИ

СТР

АМ

И

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

(ИНФОРМАЦИОННЫЕ СИСТЕМЫ ФЕДЕРАЛЬНОГО ФРАГМЕНТА,

ИНФОРМАЦИОННЫЕ СИСТЕМЫ ЭЛЕКТРОННОГО ПРАВИТЕЛЬСТВА)

МЕДИЦИНСКОЕ УЧРЕЖДЕНИЕ

МЕДИЦИНСКАЯ ИНФОРМАЦИОННАЯ

СИСТЕМА



СИСТЕМА



СИСТЕМА

МЕДИЦИНСКОЕ УЧРЕЖДЕНИЕМЕДИЦИНСКОЕ

УЧРЕЖДЕНИЕМЕДИЦИНСКОЕ УЧРЕЖДЕНИЕ

Рис. 1. Концептуальная архитектура РЕИС.

«Система интегрированной медицинской информации Единой медицинской

информационно-аналитической системы города Москвы» (СИМИ ЕМИАС) представляет собой

один из Общегородских информационных сервисов в составе ЕМИАС, предназначенный для

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

Сбора, хранения (в том числе архивного), обработки и консолидации

медицинской информации о пациенте в составе интегрированной электронной

медицинской карты (иЭМК) пациента – в едином хранилище на основе

стандартизированных электронных медицинских документов (СЭМД) по всем

случаям обращения гражданина в медицинские учреждения города Москвы;

Оперативного авторизованного поиска и извлечения медицинской информации о

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





Москвы, а также из других регионов РФ через федеральные сервисы (после

ввода в эксплуатацию федеральных сервисов и реализации интеграции Системы

с ними);

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

состоянии здоровья и оказании медицинской помощи;

Создания, редактирования, публикации протоколов.

2.2. Цели создания системы

Основной целью создания СИМИ ЕМИАС является повышение эффективности

деятельности системы здравоохранения города Москвы за счѐт внедрения современных

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

ниже в таблице 1.

Таблица 1. Цели создания СИМИ ЕМИАС.

Цели Показатель Критерий

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

оказания медицинской

помощи на основе

оперативного

предоставления врачу

актуальной информации о

состоянии здоровья

пациента

Время предоставления врачу

полной актуальной

информации о состоянии

здоровья пациента.

Уменьшение времени

получения врачом

информации о состоянии

здоровья пациента с

использованием СИМИ.

Повышение достоверности

медицинской информации

при автоматизации ввода и

проверок данных пациента

Количество ошибок при

формировании медицинских

документов.

Уменьшение количества

ошибок при формировании

медицинских документов с







Оперативное заполнение

протоколов по

утвержденным формам и

наборам параметров,

заданных пользователем

Время заполнения



наборам параметров

заданных пользователем.

Количество ошибок при

заполнении протоколов по


наборам параметров

заданных пользователем.

Уменьшение времени

заполнения протоколов с



ошибок при заполнении



наборам параметров,

заданных пользователем с


Повышение эффективности

оказания медицинской

помощи за счѐт устранения

дублирования медицинских

услуг и обеспечения

преемственности и

непрерывности

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

разных уровнях

Количество медицинских

услуг, дублированных при

направлении пациента в

специализированное

медицинское учреждение из

территориального ГУЗ


дублированных

медицинских услуг при

направлении пациента в

специализированное

медицинское учреждение из

территориального ГУЗ;

Сокращение общей

продолжительности

обследований.






Формирование

динамических отчѐтных

форм (журналов)

Время формирования

динамической отчѐтной

формы (журнала)

Уменьшение времени,

затрачиваемого на

формирование

динамических отчѐтных

форм (журналов) с






3. ХАРАКТЕРИСТИКА ОБЪЕКТОВ АВТОМАТИЗАЦИИ

3.1. Краткие сведения об объекте автоматизации

Объектом автоматизации в рамках создания Общегородского информационного сервиса

СИМИ ЕМИАС являются процессы:

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

информации о пациенте в составе интегрированной электронной медицинской карты

(иЭМК) пациента;

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

пациенте, хранящейся в иЭМК.

Основным источником медицинской информации для СИМИ ЕМИАС являются

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

ввода в эксплуатацию системы иЭМК, входящей в Федеральный сегмент ЕГИСЗ, должна быть

обеспечена возможность загрузки в СИМИ ЕМИАС медицинских документов, созданных в

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

в Регистре застрахованных лиц города Москвы.

По данным Программы модернизации здравоохранения города Москвы на 2011-2012 годы,

сеть учреждений здравоохранения города Москвы включает 780 лечебно-профилактических

учреждения, в том числе 149 больничных учреждения, 76 диспансеров, 428 амбулаторно-

поликлинических учреждений, 28 центров, в том числе научно-практических, станция скорой и

неотложной медицинской помощи, станция переливания крови, 63 учреждения охраны

материнства и детства, 36 учреждений санаторного типа, 12 учреждений здравоохранения особого

типа. Планируемые в 2012 году объѐмы амбулаторно-поликлинической помощи – около 161 млн.

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

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

45 тысяч человек.

Указанные количественные и качественные характеристики сети медицинских учреждений

города Москвы определяют следующие особенности объекта автоматизации:

Разнородность источников данных для СИМИ, связанную с использованием различного

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

Наличие большого количества форм с несовпадающими или дублирующимися

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





Недостаточная зрелость или отсутствие некоторых классификаторов; несогласованность

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

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

и региональными нормативными документами;

Отсутствие требований к ведению документации в электронном виде;

Значительный объѐм обрабатываемых данных;

Большое число участников процессов.

Сведения об объекте автоматизации будут дополнены и уточнены в ходе выполнения

работ.

3.2. Сведения об условиях эксплуатации объекта автоматизации и

характеристиках окружающей среды

Системное и прикладное программное обеспечение СИМИ развѐртывается на

существующем оборудовании Центра обработки данных (ЦОД) ЕМИАС.

Особые условия эксплуатации Системы не выявлены.





4. ТРЕБОВАНИЯ К СИСТЕМЕ

4.1. Требования к системе в целом

4.1.1. Требования к структуре и функционированию системы

4.1.1.1. Перечень подсистем, их назначение и основные характеристики

В соответствии с назначением СИМИ ЕМИАС, составу бизнес-процессов и требованиям к

еѐ функциональности, приведѐнным в подпрограмме «Внедрение современных информационных

систем в здравоохранение» программы модернизации здравоохранения города Москвы 2011-2012

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

назначение и основные характеристики которых представлены в таблице 2.

Таблица 2. Назначение подсистем и их основные характеристики.

№ Название

подсистемы

Назначение


Основные

характеристики подсистемы

1. Хранилище СЭМД Подсистема должна

обеспечивать поддержку

процессов загрузки,

хранения и извлечения

СЭМД.

Форматный контроль СЭМД.

Регистрация СЭМД.

Поддержка версионности СЭМД

(механизм аннулирования и

добавления новой версии СЭМД,

механизм установления связей

между СЭМД).

Архивирование СЭМД.

Поиск и выгрузка СЭМД по

авторизованному запросу (в том

числе и из архива СЭМД).

Ведение аудита загрузки СЭМД и

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

2. Подсистема

управления регистром

иЭМК

Подсистема должна


процессов создания,

Создание иЭМК.

Редактирование статусной









Основные


версионного хранения,

поиска, архивации,

слияния иЭМК.

информации иЭМК.

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

иЭМК.

Слияние иЭМК.

3. Хранилище

структурированных

данных СЭМД



процессов разбора СЭМД в

соответствии со

структурой используемого

протокола и хранения

структурированных

данных СЭМД,

поиска СЭМД и сведений

на основе данных СЭМД

по заданным критериям по

авторизованным запросам.

Контроль ссылочной целостности

и корректности данных СЭМД и

размещение структурированных

данных в реляционных таблицах.

Поиск и извлечение данных по

значениям различных параметров

протокола, включая

идентификаторы пациента,

медицинского работника, ЛПУ,

случаи обращения,

Возможность группировки данных

СЭМД по:

Случаям обращения

(амбулаторным и

стационарным ИБ);

Видам обследований;

Другим настраиваемым

параметрам.

4. Управление НСИ Подсистема должна


процессов управления

НСИ Системы, включая

внутренние

классификаторы СИМИ и

классификаторы,

Первоначальная загрузка НСИ;

Синхронизация НСИ со смежными

системами в составе ЕМИАС.

Редактирование НСИ с

обеспечением поддержки

версионности и сроков действия;









Основные


синхронизируемые со

смежными системами в

составе ЕМИАС.

валидация изменений НСИ.

Поиск и извлечение НСИ.

5. Хранилище

протоколов Подсистема с

использованием Developer

Interface должна


процессов создания,

редактирования,

публикации описаний

объектов предметной

области, включая

протоколы, группы

параметров протоколов,

параметры, шаблоны

протоколов, экранные и

печатные формы; а также

возможность

использования объектов

предметной области

другими подсистемами

СИМИ и смежными

системами.

Создание и настройка протоколов,

параметров протоколов и групп

параметров протоколов (с

поддержкой версионности).

Конфигурирование шаблонов

протоколов.

Конфигурирование печатных форм

для протоколов.

Конфигурирование экранных форм

для протоколов.

Экспорт/импорт протоколов,

шаблонов протоколов, параметров

протоколов и групп параметров,

экранных и печатных форм.

6. Администрирование Поддержка работы

Системы

Управление режимом работы

(производственный, тестовый,

аварийный, диагностический).

Диагностика (доступ к системным

журналам).









Основные


Управление оповещениями о

системных событиях.

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

и обеспечение

информационной

безопасности

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

пользователей, систем и

обеспечение защиты

информации,

обрабатываемой в системе

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

авторизация пользователей.

Создание ролей.

Настройка прав доступа для ролей.

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

пользователей.

Регистрация согласия пациента на

обработку персональных данных.

Регистрация и аудит действий


Антивирусная защита.

Криптографическая защита.

8. Интеграция Взаимодействие со

смежными подсистемами

ЕМИАС

Взаимодействие с

системой иЭМК, входящей

в Федеральный сегмент

ЕГИСЗ

Конфигурирование параметров

взаимодействия.

Обеспечение работоспособности

сервисов.

Обеспечение взаимодействия с

федеральной иЭМК.

9. Диагностика

Системы*


обеспечивать возможность

выполнение проверок

доступности и

работоспособности

Проверка доступности и

работоспособности элементов

Системы.









Основные


элементов Системы

Для обеспечения надежности подсистема диагностики работоспособности Системы

размещается отдельно от СИМИ на базе базовой межведомственной инфраструктуры

(БМИ).

Схема компонентной архитектуры Системы представлена на рисунке 2.

НСИ

Сервисы НСИ

Интеграционная шина ЕМИАС

Система формирования пользовательского интерфейса

Система интеграции с МИС

Хранилище протоколов

Сервисы хранилища протоколов

Регистр иЭМК

Сервисы регистра иЭМК

Хранилище СЭМД

Сервисы хранилища

СЭМД

Архив СЭМД

Хранилище структурированных

данных СЭМД

Сервисы хранилища

структурированных данных

СЭМД

Архив структурированных данных СЭМД

Архив регистра иЭМК

БД управления доступом

Сервисы подсистемы управления

доступом

БД администрирования

Сервисы подсистемы

администрирования

Подсистема интеграции СИМИ

Сервисы подсистемы диагностики

Сервисы подсистемы интеграции

Сервисы взаимодействия с иЭМК Федерального

сегмента ЕГИСЗ

Обработчик событий шины ЕМИАС

Сервисы взаимодействия с другими смежными

системами

...

Рис.2. Компонентная архитектура СИМИ.

В архитектуре Системы должны быть выделены следующие уровни иерархии:

Уровень пользовательского интерфейса, обеспечивающий доступ пользователей к

функциональности Системы;

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

на сервере приложений сервисов;

Уровень данных, обеспечивающий хранение данных Системы;





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

собой и со смежными системами.

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

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

обмена между компонентами системы

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

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

реализованных в интерфейсах подсистем.

4.1.1.3. Требования к характеристикам взаимосвязей создаваемой

системы со смежными системами

В соответствии с проектом «Методических рекомендаций по применению облачных

технологий при создании регионального уровня единой государственной информационной

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

здравоохранения в 2011 – 2012 годах» информационная система, предназначенная для

использования в составе РЕИС, должна иметь открытую сервисно-ориентированную архитектуру.

Базовой технологией для реализации архитектуры СИМИ должно быть использование web-

сервисов.

Разрабатываемая система СИМИ является частью ЕМИАС и, в соответствии с общей

архитектурой ЕМИАС, предоставляемые Системой сервисы работы с хранилищем СЭМД,

хранилищем структурированных данных СЭМД и хранилищем протоколов должны быть

доступны для использования следующими смежными системами:

подсистемой формирования пользовательского интерфейса ЕМИАС;

подсистемой интеграции МИС;

информационными системами федерального фрагмента ЕГИСЗ и информационными

системами Электронного правительства.

СИМИ создается на основе базовой межведомственной инфраструктуры (БМИ) ЕМИАС и

должна использовать сервисы, предоставляемые системами в составе БМИ ЕМИАС и ЕМИАС:

Набор базовых сетевых и системных сервисов БМИ ЕМИАС:

o подсистема единого каталога пользователей;

o подсистема аутентификации;

o подсистема резервного копирования и восстановления данных.





НСИ;

Сервисы общегородского Регистра пациентов;

Сервисы системы управления медицинскими регистрами.

Для обработки случаев отсутствия связи между Системой и смежной ИС должны быть

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

рамках которого возникает необходимость изменения данных, как со стороны Системы, так и со

стороны смежной ИС. При этом должна сохраняться непротиворечивость и целостность данных

во всех взаимодействующих системах. Например, функционирование МИС на уровне ЛПУ не

должно остановиться в случае отсутствия связи с СИМИ.

Характеристики взаимодействия СИМИ и смежных систем должны быть специфицированы

в составе документов ЧТЗ по результатам НИР на стадии технического проектирования Системы;

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

утверждены требования к интерфейсам интеграции со следующими системами:

смежные системы в составе ЕМИАС;

сервисы федерального сегмента ЕГИСЗ;

системы ведения специализированных регистров по ряду нозологий.

4.1.1.4. Требования к режимам функционирования системы

В СИМИ должна быть реализована возможность работы системы в следующих режимах

функционирования:

Производственный (штатный) – основной режим работы системы, в котором доступна

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

системы доступны для внешних вызовов;

Тестовый – режим работы, при котором доступна вся функциональность системы и

выполняется обработка тестовых данных (которые могут быть потом удалены); сервисы

системы недоступны для внешних вызовов;

Диагностический – режим работы, при котором функциональность системы доступна

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

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

системы могут быть доступны или недоступны для внешних вызовов;

Аварийный – режим работы системы, при котором функциональность системы

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

обеспечении Системы. С использованием подсистемы мониторинга должен быть





реализован механизм оповещения администраторов Системы о еѐ переходе в аварийный

режим. Смежные системы при попытке вызова сервиса Системы в период еѐ

нахождения в аварийном режиме должны получать ответное сообщение о временной

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

Параметры режимов функционирования Системы должны быть специфицированы в ЧТЗ,

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

4.1.1.5. Требования по диагностированию системы

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

соответствии с эксплуатационной документацией на аппаратные средства, входящие в комплекс

технических средств Системы.

Для диагностики доступности и работоспособности web-сервисов СИМИ должна быть

реализована автономная подсистема диагностики, размещаемая на инфраструктуре РЕИС как

внешняя по отношению к СИМИ система. Требования к подсистеме диагностики приведены в

разделе 4.2.1.9.

Для диагностики состояния Системы и выявления возможных сбоев в ходе еѐ эксплуатации

в СИМИ должна быть реализована журнализация системных событий. Уровень детализации

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

Системы и каждой еѐ подсистемы должен быть определѐн уровень детализации, применяемый по

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

журнала системных событий должны быть специфицированы в ЧТЗ на стадии технического

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

Основные системные события, подлежащие журнализации, приведены в следующем

списке:

Вызов сервиса системы (добавление данных, чтение данных);

Результат выполнения вызова;

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

обработка параметра протокола);

Вызов сервиса смежной системы;

Результат вызова сервиса смежной системы.

Записи в системном журнале событий должны содержать следующие данные:

Пользователь СИМИ или смежной системы, от имени которого инициировано

системное событие;

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





Дата и время события;

Тип события;

Описание события (степень детализации описания определяется параметрами режима

функционирования);

Результат завершения (степень детализации описания результата определяется

параметрами режима функционирования).

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

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

системных событий (см. п. 4.1.1.4). При разработке Системы должны быть спроектированы и

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

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

быть описаны в ЧТЗ на стадии технического проектирования.

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

диагностики применяемого платформенного ПО (СУБД, серверы приложений), в том числе

журнализация событий.

Для информирования административного персонала Системы о возникновении нештатных

ситуаций должна использоваться функциональность:

- внешней диагностической системы;

- БМИ ЕМИАС (электронная почта).

4.1.1.6. Перспективы развития. Модернизация системы

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

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

системы не должна изменяться.

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

направлениях:

Расширение прикладных функций;

Интеграция Системы с другими информационными системами и ресурсами.

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

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

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

информации, которая хранится в Системе в структурированном виде.





Расширение функциональности системы возможно в процессе разработки сервисов,

обеспечивающих экспорт данных для системы формирования аналитической отчѐтности, а также

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

смежными системами.

4.1.2. Требования к численности и квалификации персонала системы и

режиму его работы

В соответствии с назначением Системы не предусматривается непосредственное

взаимодействие бизнес-пользователей (персонала амбулаторно-поликлинических и лечебно-

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

работать с подсистемой пользовательского интерфейса, разрабатываемой в составе ЕМИАС, или с

локальными МИС, развѐрнутыми в ЛПУ. Требования к уровню подготовки этой группы

пользователей Системы определены приказом Минздравсоцразвития РФ от 23 июля 2010 г. №

541н «Об утверждении Единого квалификационного справочника должностей руководителей,

специалистов и служащих, раздел «Квалификационные характеристики должностей работников в

сфере здравоохранения»; дополнительных требований для квалификации пользователей этой

группы не предъявляется.

Персонал Системы обеспечивает выполнение административных действий в Системе,

обновление НСИ и разработку протоколов, параметров протоколов, групп параметров протокола,

экранных и печатных форм для протоколов с использованием конструктора Developer Interface

(DI) хранилища протоколов.

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

выполнена в ЧТЗ на стадии разработки технического проекта Системы. В число ролей

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

Администратор системы;

Разработчик протоколов.

Состав персонала, работающего с Системой через еѐ пользовательский интерфейс,

представлен в таблице 3.

Таблица 3. Подсистемы и их персонал.

№ Наименование подсистемы Персонал подсистемы

1. Администрирование Администратор системы

2. НСИ Администратор системы





№ Наименование подсистемы Персонал подсистемы

3. Хранилище протоколов Разработчик протоколов

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

информационной безопасности

Администратор системы

5. Управление регистром иЭМК Администратор системы

6. Диагностика Администратор системы

Требования к персоналу Системы приведены в таблице 4.

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

персонала.

Наименование

пользователя Количество Квалификация Режим работы

Администратор 2 Квалифицированный

специалист –

системный

администратор,

Квалифицированный


администратор

СУБД.

Сменный режим,

обеспечивающий

поддержку 24х7х365

Разработчик протоколов 2 Квалифицированный


системный аналитик

9.00 – 18.00

5-и дневная рабочая

неделя

При внедрении Системы численный состав персонала подсистем должны быть уточнѐн для

каждого подразделения, эксплуатирующего Систему.

В таблице 5 представлены требования к уровню квалификации персонала Системы.

Таблица 5. Уровни квалификации персонала Системы.

Уровень квалификации Требования

Квалифицированный специалист –

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

Высшее техническое образование, стаж работы не

менее 2 лет, желательно знание английского языка





Уровень квалификации Требования


администратор СУБД

(технический перевод).

Знание администрирования СУБД, используемой в

составе Системы, сервера приложений,

операционных систем, сетевых протоколов. Опыт

работы с большими распределѐнными базами

данных.


системный аналитик

Высшее техническое образование, стаж работы не

менее 2 лет, знание английского языка

(технический перевод).

Знание предметной области, знание XML.

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

квалификацию и прошедшим обучение по вопросам эксплуатации данной системы.

Первоначальное обучение персонала должно быть проведено до ввода Системы в эксплуатацию.

Программа обучения и учебные материалы должна быть разработаны на стадии разработки

технического проекта Системы.

4.1.3. Показатели назначения

СИМИ ЕМИАС должна быть создана с учетом обеспечения штатного функционирования

при следующих ориентировочных значениях целевых количественных и качественных

показателей:

Суммарное количество СЭМД в год – до 1 млрд. документов (суммарный объѐм

документов до 25ТБ в год);

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

– до 60 000 чел.;

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

и доступом к СЭМД - не менее 1000;

Предельное количество государственных учреждений здравоохранения города Москвы,

охваченных ЕМИАС – до 1 000 ед.;

Срок хранения данных – до 50 лет.





В соответствии с приказом Минздрава СССР от 30 мая 1974 года №493 «О введении в

действие «Перечня документов со сроками хранения Министерства здравоохранения СССР,

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

проекту приказа Минздравсоцразвития РФ от 14 декабря 2011 года «Перечень форм учѐтной

медицинской документации с подразделением еѐ на группы в зависимости от функционального

назначения и применения по типам медицинских учреждений с определением сроков хранения,

форматов и видов» для хранения медицинской документации установлен максимальный срок 50

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

сроком хранения медицинских документов в Системе в зависимости от типа документа, и

регламент архивирования документов.

При проектировании Системы должны быть предусмотрены возможности для расширения

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

В производственном режиме функционирования Система должна обеспечивать время

отклика в соответствии с требованиями, указанными в таблице 6:

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

Показатель Средняя

величина

(не более)

Максимальная

величина

(не более)

Время отклика для сервисов загрузки, поиска и

извлечения СЭМД из оперативной БД

2 секунды 5 секунд

Время отклика для остальных сервисов СИМИ 3 секунды 7 секунд

В случае если в рамках функционирования сервиса происходит взаимодействие с внешней

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

требованиям, , то время отклика сервисов СИМИ может быть увеличено, но не более, чем в 2 раза.

В условиях пиковых нагрузок допустимо увеличение времени отклика сервисов Системы

не более, чем в 2 раза.

Целевые показатели Системы должны сохраняться на протяжении всего срока

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

вычислительных комплексов, своевременным проведением работ по замене (обновлении)

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

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

сохраняться неограниченно долго.





4.1.4. Требования к надѐжности

4.1.4.1. Восстановление при аварийных ситуациях

Обеспечение возможности восстановления работоспособности Системы без критической

потери данных при возникновении аварийных ситуаций возлагается на БМИ ЕМИАС, а именно,

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

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

данных, которые были записаны в базу данных Системы в результате корректно завершѐнной

транзакции.

4.1.4.2. Надѐжность программного обеспечения

В Системе должны быть предусмотрены:

Средства контроля корректности входных данных и обработки недопустимых

форматов/значений входных данных при работе с пользовательским интерфейсом

Системы и при загрузке СЭМД;

Средства информирования пользователя об ошибочных или противоречивых входных

данных при работе с пользовательским интерфейсом Системы и при загрузке СЭМД;

Средства обработки неверных действий пользователей при работе с пользовательским

интерфейсом Системы;

Средства обработки некорректных данных СЭМД.

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

пользователя, или недопустимым форматом/значением входных данных при работе с

пользовательским интерфейсом, Система должна:

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

исключительной ситуации;

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

Возвращаться в рабочее состояние, предшествовавшее неверной (недопустимой)

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

В случае возникновения исключительной ситуации, вызванной некорректным форматом

СЭМД, или некорректными данными СЭМД, Система должна:

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

включая:

o идентификатор СЭМД;

o дату и время получения СЭМД;





o тип СЭМД;

o источник СЭМД;

o описание исключительной ситуации.

Формировать сообщение для системы – источника СЭМД с описанием исключительной

ситуации.

При невозможности по тем или иным причинам завершить пользовательскую транзакцию

Система должна обеспечить целостность и непротиворечивость данных, и выдать аварийное

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

обеспечить информирование пользователей о еѐ временной недоступности.

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

отключение электропитания, программное обеспечение Системы должно автоматически

восстанавливать свою работоспособность после устранения причины сбоя и корректного

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

носителей информации с исполняемым программным кодом).

Импульсные помехи, сбои или прекращение электропитания не должны приводить к

выходу из строя технических средств и/или нарушению целостности или потере данных.

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

развѐрнуты таким образом, чтобы обеспечивать успешное восстановление Системы при

возникновении сбоев, вызванных следующими причинами:

Задержки в каналах связи;

Снижение скорости обмена информацией по сети;

Аппаратные сбои оборудования;

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

Рост числа запросов к приложению сверх прогнозируемого уровня;

Рост требуемых ресурсов сверх прогнозируемого уровня, в том числе лицензий,

вычислительных мощностей, оперативной и дисковой памяти.

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

вертикальное и горизонтальное масштабирование с возможностью статической и динамической

балансировки нагрузки.

Обновление информационной системы или компонента в еѐ составе должно происходить в

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

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

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

сервиса; переключение пользователей на новую версию происходит без остановки системы).





В Системе должна быть реализована поддержка «горячей» замены конфигурации:

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

действие с момента публикации, без остановки и перезапуска Системы или еѐ компонента.

4.1.4.3. Надѐжность технических средств

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

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

резервированию;

формированием требований к дублированию носителей информации.

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

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

проекта ЦОД ЕМИАС.

4.1.5. Требования безопасности

Требования безопасности не предъявляются.

4.1.6. Требования к эргономике и технической эстетике

Пользовательский визуальный интерфейс Системы должен удовлетворять следующим

требованиям:

Все экранные формы пользовательского интерфейса должны быть выполнены в едином

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

навигации.

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

редактирование), а также последовательности действий пользователя при их

выполнении, должны быть унифицированы.

Интерфейс должен быть рассчитан на преимущественное использование манипулятора

типа «мышь», то есть управление Системой должно осуществляться с помощью набора

экранных меню, кнопок, значков и тому подобных элементов.

Клавиатурный режим ввода должен использоваться главным образом при заполнении

и/или редактировании текстовых и числовых полей экранных форм. В интерфейсах

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

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

объѐма действий, в том числе должен быть обеспечен удобный переход от поля к полю

Все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме

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





При отображении многострочных массивов информации, выходящих за рамки экрана,

должна показываться полоса прокрутки.

Экранные формы должны отражать всю информацию и элементы оформления при

разрешении экрана 1024х768, 1280х1024, 1366х768, 1600х900 с использованием

стандартного шрифта.

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

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

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

производиться по возможности наиболее простыми действиями; при этом в форме

должны сохраняться корректно введѐнные данные.

Пользовательские интерфейсы Системы должны разрабатываться индивидуально для

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


4.1.7. Требования к транспортабельности системы

К техническому обеспечению Системы не предъявляются требования мобильности.

.

4.1.8. Требования к эксплуатации, техническому обслуживанию, ремонту

и хранению компонентов системы

Эксплуатация Системы должна производиться в соответствие с эксплуатационной

документацией и регламентом технического обслуживания. При нарушении условий

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

только пользователь несет ответственность за последствия таких нарушений.

Обслуживание Системы должно производиться службой эксплуатации ЕМИАС.

Для размещения компонентов АРМ Системы должны быть использованы площади,

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

электронно-вычислительным машинам и организации работы (СанПиН 2.2.2/2.4.1340-03 от 30 мая

2003 г., утверждены Главным государственным санитарным врачом Российской Федерации).

Уровень квалификации обслуживающего персонала должен соответствовать требованиям

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

документации.

Регламент обслуживания должен содержать перечень работ, периодичность их проведения,

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

Системы и включѐн в состав эксплуатационной документации Системы.





4.1.9. Требования к защите информации от несанкционированного

доступа

СИМИ относится к группе многопользовательских автоматизированных систем с разными

правами доступа. С учетом особенностей обрабатываемой информации, СИМИ должна

соответствовать требованиям, предъявляемым действующим в Российской Федерации

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

обработку персональных данных.

В соответствии со статьѐй 13 Федерального закона Российской Федерации от 21 ноября

2011 г. №323-ФЗ «Об основах охраны здоровья граждан в Российской Федерации» предоставление

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

законного представителя (подпункты 8-10 пункта 4 указанной статьи закона):

«8) при обмене информацией медицинскими организациями, в том числе размещенной в

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

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

9) в целях осуществления учета и контроля в системе обязательного социального

страхования;

10) в целях осуществления контроля качества и безопасности медицинской

деятельности в соответствии с настоящим Федеральным законом» [№ 323-ФЗ].

Тем не менее, Система должна обеспечивать возможность регистрации:

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

данных в прикрепленной поликлинике (доступ к иЭМК и СЭМД предоставляется всем

врачам прикрепленной поликлиники);

специального согласия пациента (его законного представителя) на обработку:

o персональных данных в прикрепленной поликлинике, в ином

медицинском учреждении (доступ к иЭМК и СЭМД предоставляется

врачам из списка специального согласия);

o персональных данных, производимую в иных целях, с указанием цели

обработки персональных данных в соответствии с требованиями

Федерального закона от 27.07.2006 г. № 152-ФЗ «О персональных

данных» (с учѐтом последних редакций).

Медицинская информация в Системе должна хранится без персональных данных, в виде,

исключающем возможность идентификации пациента по значениям атрибутов иЭМК или данным

в составе СЭМД как через веб-сервисы и веб-интерфейсы компонентов СИМИ, так и через

интерфейсы баз данных.





Размещение разрабатываемых компонентов СИМИ осуществляется в пределах

защищенного окружения РЕИС, формируемого системами инфраструктурного уровня БМИ

ЕМИАС. Создание систем инфраструктурного уровня, формирующих защищенное окружение

ЕМИАС, не входит в рамки работ, определяемых настоящим Техническим заданием.

Защищенное окружение призвано реализовать всю базовую функциональность СИМИ по

защите информации, включая

Безопасность межсетевого взаимодействия;

Обнаружение и предотвращение вторжений;

Контроль защищенности;

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

информации;

Защиту каналов связи между ЛПУ и общегородским центром обработки данных.

Вместе с тем, при проектировании аппаратно-программного комплекса, обеспечивающего

работу компонентов СИМИ, должна быть предусмотрена реализация подсистемы управления

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

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

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

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

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

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

безопасностью при эксплуатации Системы. Документ «Политика обеспечения информационной

безопасности» должен войти в состав эксплуатационной документации Системы.

При проведении работ по обеспечению информационной безопасности должны

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

Приложении 1.

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

Для пользователей из числа административного персонала Системы:

Доступ в систему через пользовательский интерфейс должен предоставляться только

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

Должна выполняться журнализация входа / выхода пользователей (включая

администраторов) в Систему с использованием пользовательского интерфейса Системы.

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

o дата и время входа / выхода пользователя в систему;





o результат попытки входа (успешная или неуспешная);

o идентификатор пользователя;

o адрес исходящего запроса.

Для всех пользователей - пользователей из числа административного персонала Системы

и бизнес-пользователей (сотрудников ЛПУ, работающих с Системой через посредство

подсистемы формирования пользовательского интерфейса ЕМИАС или локальных МИС

ЛПУ):

Должна выполняться журнализация действий администраторов Системы;

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

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

o дата и время попытки доступа к данным;

o тип доступа (запись, чтение);

o результат попытки доступа к данным (успешная, неуспешная);

o идентификатор пользователя;

o идентификатор системы пользователя;

o спецификация защищаемых данных (таблица БД, условия поиска).

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

администраторов Системы;

Подтверждение авторства транзакций должно быть обеспечено:

o использованием технологии электронной подписи (ЭП);

o использованием (на временной основе) облегчѐнных методов, например,

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

В Системе должна быть реализована комбинированная модель обеспечения

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

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

определѐнному пользователю СИМИ (врачу) к определѐнным данным по

пациенту (например, доступ на чтение/запись для конкретного врача

пользователя к иЭМК конкретного пациента или к конкретному СЭМД пациента

на основании зарегистрированного документа - «Специального согласия на

обработку персональных данных») – окончательный вариант модели





обеспечения доступа должен быть разработан на этапе техно-рабочего

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

Права пользователя в Системе должны складываться из прав, определяемых

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

Ролевая модель обеспечения доступа к данным и функциям Системы должна

поддерживать:

o Возможность создавать и настраивать в Системе различные роли, для

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

o Поддержку глобальных и контекстных ролей; глобальная роль определяет

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

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

терапевт»); контекстная роль определяет права доступа с учѐтом имеющихся

отношений (например, «лечащий врач»);

o Возможность определения прав доступа роли к данным с точностью до

протокола, группы параметров протокола;

o Возможность определения глубины прав доступа роли к данным (список

СЭМД, содержание СЭМД);

o Возможность определения уровня прав доступа роли к данным (чтение,

запись, отсутствие доступа, аннулирование, дополнение, архивирование,

возврат из архива);

o Возможность определения области прав доступа к данным (пользователь,

подразделение ЛПУ, ЛПУ, округ);

o Возможность определения прав доступа к данным в зависимости от даты

создания данных;

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

o Возможность назначать роли пользователям, группам пользователей,

подразделениям организационной структуры ЛПУ.

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

конкретным иЭМК, СЭМД для пользователя, группы пользователей, подразделения

ЛПУ;





При необходимости передачи данных через публичные сети должна быть обеспечена

защита данных с использованием технологии SSL v.3 или VPN;

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

использованием криптоалгоритма ГОСТ 28147 – 89;

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

нарушителя информационной безопасности Системы. Данная модель должна быть

разработана на стадии технического проектирования;

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

осуществляться путем самостоятельно разрабатываемых программных модулей в

составе прикладного ПО Системы или использованием штатных механизмов

системного ПО (операционных систем и СУБД). В случае использования штатных

механизмов, должны использоваться сертифицированные по требованиям ФСТЭК и

предназначенные для использования в составе АС класса 1Г и систем персональных

данных класса К1 версии ОС и СУБД;

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

требованиям ФСТЭК России или ФСБ России и разрешено к использованию в составе

АС класса 1Г и систем персональных данных класса К1.

4.1.10. Требования по сохранности информации при авариях

Программные модули Системы должны сохранять работоспособность и обеспечивать

восстановление своих функций при возникновении сбоев в системе электроснабжения аппаратной

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

Системы должно происходить восстановление работоспособности.

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

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

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

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

вводу данных.

Обеспечение целостности и сохранности данных и обработка нестандартных ситуаций в

ходе работы программы (таких как ввод неправильных данных, удаление используемой записи и

т.д.) должно обеспечиваться на нескольких архитектурных уровнях Системы:

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

Системы;

Программные модули, реализующие функции Системы;





Транзакционные механизмы СУБД, механизмы обеспечения целостности данных

СУБД.

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

сохранности данных представлена в таблице 7:

Таблица 7. Способы обеспечения целостности и сохранности данных.

Действия в

отношении данных Архитектурный уровень

Способы обеспечение

целостности и сохранности

данных

Ввод данных Пользовательские и

программные интерфейсы,

предоставляющие доступ к

функциям Системы

Проверка корректности

форматов, типов, наличия

обязательных параметров

Обработка данных Программные модули,

реализующие функции

Системы

Логические проверки данных

Хранение данных СУБД Механизмы транзакционности и

обеспечения целостности,

предоставляемые СУБД

Целостность и сохранность информации должна обеспечиваться следующими мерами,

реализованными в Системе:

Запись и хранение истории изменений данных;

Контроль входа в Систему;

Наличие процедур резервного копирования и восстановления;

Возможность возврата данных в корректное состояние.

Исполнитель должен реализовать вышеперечисленные меры средствами прикладного ПО

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

ПО.

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

БМИ ЕМИАС, и штатными средствами используемых СУБД.

4.1.11. Требования к защите от влияния внешних воздействий

Средства защиты от внешних воздействий не предъявляются.





4.1.12. Требования к патентной чистоте

Используемое оборудование и программное обеспечение (ПО) должны иметь патентную

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

территории Российской Федерации.

Кроме этого, исключительное авторское право на созданное ПО по государственному или

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

Исполнителю (Разработчику), являющемуся автором либо иным выполняющим государственный

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

предусмотрено, что это право принадлежит Российской Федерации, субъекту Российской

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

муниципальный Заказчик; либо совместно Исполнителю и Российской Федерации, Исполнителю

и субъекту Российской Федерации или Исполнителю и муниципальному образованию.

Имущественные права принадлежат Заказчику.

4.1.13. Требования по стандартизации и унификации

Проводимые работы должны соответствовать следующим требованиям:

Применяемые при создании Системы технические (форматы данных, протоколы

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

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

независимой реализации третьими сторонами. Применение недокументированных или

недоступных решений не допускается.

При выборе применяемых решений преимущество должно отдаваться решениям,

основанным на стандартизированных технологиях, т.е. прошедшим процедуру

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

признанным международным, федеральным, отраслевым, промышленным органом по

стандартизации.

Экранные формы пользовательского интерфейса должны быть спроектированы с

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

эргономике и технической эстетике.

Совместимость со смежным системами должна быть обеспечена путем предоставления

возможностей импорта и экспорта информации в файлы согласованного формата и/или

предоставлением специфицированного программного интерфейса.

При проектировании информационной модели Системы должны быть использованы

существующие утверждѐнные (рекомендованные к использованию) стандартами и





федеральными или ведомственными (отраслевыми) нормативными актами

классификаторы и словари.

4.1.14. Дополнительные требования

При реализации Системы должен быть разработан базовый набор протоколов,

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

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

до 5 протоколов для каждой из врачебных должностей, перечисленных в приказе Министерства

здравоохранения и социального развития Российской Федерации от 25 июля 2011 года №801н «Об

утверждении Номенклатуры должностей медицинского и фармацевтического персонала и

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

здравоохранения». Состав базового набора протоколов должен быть согласован и утверждѐн на

стадии технического проектирования.

4.2. Требования к функциям, выполняемым системой

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

4.2.1.1. Подсистема хранилища СЭМД

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

Загрузка документа:

o Регистрация документа в журнале приѐма;

o Выполнение форматного контроля документа;

o Проверка ЭП документа;

o Запись документа в Регистр СЭМД;

Поиск документа по значениям атрибутов документа (тип документа, дата, ЛПУ, др.);

Получение статуса документа;

Извлечение документа;

Поиск по журналу приѐма;

Аннулирование документа (с обязательной регистрацией документа-основания);

Архивирование документов.

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

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

медицинских документов в соответствии с действующими регламентами и нормативными актами.





На стадии технического проектирования Системы должен быть согласован и утверждѐн

список необходимых типов СЭМД для врачебных должностей, перечисленных в приказе

Министерства здравоохранения и социального развития Российской Федерации от 25 июля 2011

года №801н «Об утверждении Номенклатуры должностей медицинского и фармацевтического

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

здравоохранения» (от 1 до 5 типов СЭМД для каждой врачебной должности), и 280 .

4.2.1.2. Требования к подсистеме управления регистром иЭМК


Создание иЭМК (регистрация субъекта иЭМК);

Изменение статусной информации иЭМК;

Поиск иЭМК по значениям атрибутов (пациент, ЛПУ, дата создания, и др.);

Получение статусной информации о иЭМК;

Слияние иЭМК;

Архивация иЭМК;

Восстановление (активация) иЭМК из архива.

4.2.1.3. Требования к подсистеме хранилища структурированных данных

СЭМД


Контроль ссылочной целостности и корректности данных СЭМД;

Создание записи структурированных данных СЭМД;

Замена записи структурированных данных СЭМД;

Поиск записей структурированных данных СЭМД по значениям различных параметров

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

обращения;

Извлечение записей структурированных данных СЭМД;

Аннулирование записи структурированных данных СЭМД;

Архивирование записей структурированных данных СЭМД.

4.2.1.4. Требования к подсистеме управления НСИ

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

функций:

Управление обновлением НСИ:





o Первоначальная загрузка НСИ;

o Загрузка обновлений НСИ (с поддержкой версионности и журнализацией

изменений);

o Редактирование НСИ (с поддержкой версионности и журнализацией

изменений);

o Публикация обновлений;

Поиск и извлечение НСИ.

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

стадии технического проектирования с учѐтом требований к системе НСИ ЕМИАС.

Для выполнения первоначальной загрузки и обновления НСИ в процессе эксплуатации

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

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

проектирования.

4.2.1.5. Требования к подсистеме хранилища протоколов


Разработка протоколов:

o Создание/редактирование параметров протоколов;

o Создание/редактирование групп параметров протоколов;

o Создание/редактирование протоколов;

o Создание/редактирование шаблонов протоколов;

o Создание/редактирование экранных форм для протоколов;

o Создание/редактирование печатных форм для протоколов;

o Публикация протоколов/шаблонов протоколов/экранных форм/печатных

форм;

Экспорт протоколов/шаблонов протоколов/экранных форм/печатных форм;

Импорт протоколов/шаблонов протоколов/экранных форм/печатных форм;

Предоставление списка доступных для пользователя протоколов и шаблонов в

соответствии с его правами доступа (с возможностью выбора для заполнения одного

или нескольких протоколов);

Предоставление описания экранной формы для протокола (включая данные шаблона и

проверочные условия для данных);

Предоставление описания экранной формы для поиска СЭМД;

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





Предоставление описания экранной формы для поиска сведений в составе СЭМД;

Предоставление описания экранной формы для отображения сведений в составе СЭМД.

Подсистема должна обеспечивать возможность создания и использования протоколов,

групп параметров протоколов, параметров, шаблонов протоколов, экранных и печатных форм на

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

должны быть обеспечены поддержка версионности описаний объектов и ведение журнала

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

На стадии технического проектирования Системы должен быть согласован и утверждѐн

набор необходимых протоколов, параметров протоколов, групп параметров протоколов и

соответствующих экранных и печатных форм, обеспечивающих поддержку работы с Системой

медицинских работников в соответствии с перечнем врачебных должностей, приведѐнном в

приказе Министерства здравоохранения и социального развития Российской Федерации от 25

июля 2011 года №801н «Об утверждении Номенклатуры должностей медицинского и

фармацевтического персонала и специалистов с высшим и средним профессиональным

образованием учреждений здравоохранения» и в приказе Министерства здравоохранения СССР от

04 мая 1970 года №280 (с изменениями и дополнениями от 12 октября 2006 года) «О номенклатуре

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

здравоохранения» (от 1 до 5 типов СЭМД для каждой врачебной должности).

4.2.1.6. Требования к подсистеме администрирования

Подсистема администрирования должна обеспечивать:

Управление режимами функционирования:

o Перевод Системы в определѐнный режим функционирования;

o Конфигурирование параметров режима функционирования;

Регистрацию пользователей;

Просмотр журналов событий;

Оповещение персонала Системы о возникновении нештатных ситуаций;

Настройка взаимодействия с подсистемой интеграции МИС.

4.2.1.7. Требования к подсистеме управления доступом и

информационной безопасности

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

обеспечения:

Управления ролями;





Управления правами доступа к данным;

Защиты от несанкционированного доступа в систему;

Защиты от несанкционированного доступа к информации, обрабатываемой в Системе, и

выполнения операций в Системе;

Защиты конфиденциальных данных о пациентах, в том числе и от сотрудников ЛПУ;

Регистрации согласия пациента (его законного представителя) на обработку

персональных данных;

Подтверждения авторства транзакций и ведения аудита.

Необходимая функциональность для управления доступом и обеспечения информационной

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

Компонент управления доступом;

Компонент регистрации и учѐта;

Компонент антивирусной защиты;

Компонент криптографической защиты.

В таблице 8 приведено распределение функций подсистемы управления доступом и

обеспечения информационной безопасности по компонентам.

Таблица 8. Функции подсистемы управления доступом и обеспечения информационной

безопасности.

Компонент Функции, выполняемые компонентом

Компонент управления

доступом

Выполнение идентификации и аутентификации

пользователей системы с использованием

соответствующего сервиса БМИ по протоколам,

используемым в БМИ;

Выполнение идентификации и аутентификации внешних

МИС по сертификату (сертификат ключа проверки ЭП);

Выполнение внутренней авторизации пользователей на

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

персональных прав доступа;

Выполнение внутренней прикладной авторизации

пользователей на основании содержимого запроса

(например, запрос на получение данных

аутентифицирован от имени МИС больницы, но

осуществлен от имени врача данной больницы);






Создание роли;

Конфигурация прав роли;

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

Создание группы пользователей;

Удаление (запрет использования) группы пользователей;

Назначение роли пользователю/группе пользователей/

подразделению оргструктуры ЛПУ;

Отмена назначения роли пользователю, группе

пользователей, подразделению оргструктуры ЛПУ;

Назначение прав доступа пользователю/группе

пользователей/подразделению оргструктуры ЛПУ к

конкретной иЭМК;

Отмена назначения прав доступа пользователю/группе

пользователей/подразделению оргструктуры ЛПУ к

конкретной иЭМК;

Регистрация согласия пациента (его законного

представителя) на обработку персональных данных;

Регистрация отзыва согласия пациента (его законного

представителя) на обработку персональных данных.

Компонент регистрации и

учѐта

Регистрация входа / выхода пользователей (включая

администраторов) в Систему;

Регистрация события доступа пользователя к

защищаемым данным.

Компонент антивирусной

защиты

Выявление, удаление и защита объектов файловой

системы ОС серверов Системы от угроз вредоносного ПО

следующих типов:

o классических вирусов;

o сетевых червей;

o троянских программ;

o программ-реклам;

o потенциально опасных приложений;






o прочего вредоносного ПО.

Выполнение проверки следующих объектов:

o файлы при их записи и чтении;

o альтернативные потоки файловых систем NTFS;

o главные загрузочные записи и загрузочные сектора

жестких дисков.

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

времени или по заданному расписанию.

Обновление антивирусного ПО и его баз данных по

расписанию или по запросу.

Компонент криптографической

защиты

Выполнение криптографической защиты данных при

передаче данных через публичные сети с использованием

технологии SSL v.3, или VPN.

4.2.1.8. Требования к подсистеме интеграции

Подсистема интеграции должна обеспечивать взаимодействие между подсистемами

СИМИ, взаимодействие со смежными системами ЕМИАС и взаимодействие с системой иЭМК,

входящей в Федеральный сегмент ЕГИСЗ, включая:

Проверку допустимости источника входящего вызова;

Обработчик событий сервисной шины ЕМИАС;

Набор адаптеров для обеспечения взаимодействия со смежными системами, включая

взаимодействие с системой иЭМК Федерального сегмента ЕГИСЗ.

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

асинхронном режиме.

Состав адаптеров и требования к ним должны быть специфицированы в отдельных ЧТЗ на

сопряжение со смежными системами по мере ввода в эксплуатацию смежных систем или

получения утверждѐнных требований к этим системам. Требования, указываемые в ЧТЗ на

сопряжение со смежными системами, должны обеспечивать совместимость СИМИ со смежными

системами на различных уровнях:

На уровне протоколов взаимодействия;

На уровне используемых технологий;

На уровне применяемых решений;





На уровне поддерживаемых бизнес-процессов.

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

Подсистема диагностики должна обеспечивать предоставление для СИМИ в целом и для

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

в отношении их:

Доступности;

Производительности;

Безопасности;

Корректности конфигурации.

Требования к формату предоставления подсистемой диагностики сведений должны быть

специфицированы в ЧТЗ и согласованы на стадии разработки технического проекта.

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

информации

Система должна содержать встроенное инструментальное средство (DI хранилища

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

печатные формы. Формат описания печатных форм должен обеспечивать возможность

формирования документов в следующих форматах:

Open Office XML;

OpenDocument Format.

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

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

использован формат XML.

4.2.3. Требования к составу и форме представления входной

информации

Входная информация Системы должна быть специфицирована на стадии разработки

технического проекта.

Основным форматом входной информации Системы является СЭМД. Список типов СЭМД

для разработки должен быть согласован и утверждѐн на стадии технического проектирования для

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

развития Российской Федерации от 25 июля 2011 года №801н «Об утверждении Номенклатуры

должностей медицинского и фармацевтического персонала и специалистов с высшим и средним





профессиональным образованием учреждений здравоохранения» (от 1 до 5 типов СЭМД для

каждой врачебной должности)..

4.2.4. Требования к интерфейсу пользователя

Пользовательские интерфейсы Системы включают в себя:

Пользовательский интерфейс Администратора системы (для работы с подсистемой

администрирования, подсистемой управления доступом и обеспечения

информационной безопасности, подсистемой управления НСИ, подсистемой

управления регистром иЭМК, подсистемой диагностики работоспособности);

Пользовательский интерфейс Разработчика протоколов (для работы с хранилищем

протоколов).

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

возможности работы пользователей с использованием стандартных Интернет-браузеров типа

Mozilla Firefox (версия 7 и выше – базовый браузер), Google Chrome (версия 11.0 и выше),

Microsoft Internet Explorer (версия 8 и выше).

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

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

зависимые программные библиотеки (например, таких как Microsoft ActiveX, Microsoft Silverlight,

Adobe Flash или аналогичные).

Для Системы на стадии технического проектирования должны быть разработаны

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

связанные с экранными формами должны быть отображены в отдельном документе, который

должен быть согласован и утвержден Заказчиком.

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

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

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

интерфейса (GUI);

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

интерфейсу, перечисленных в разделе 4.1.6 ТЗ.

Должна быть обеспечена поддержка кодировки UTF-8;

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

правилам работы с Системой в целом.

Пользовательский интерфейс должен обеспечивать полнофункциональную работу без

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





Silverlight, ActiveX, Flash и т.д.; Вся логика работы экранных форм должна быть

реализована с использованием HTML, JavaScript, CSS;

При реализации взаимодействия с пользователем должны быть обеспечена первичная

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

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

требований к пропускной способности канала связи;

Информационная система должна поддерживать ввод данных пользователем с

устройств бесклавиатурного типа, таких как планшетные компьютеры, сенсорные

экраны и пр.;

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

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

аутентификации пользователей;

4.3. Требования к видам обеспечения

4.3.1. Требования к математическому обеспечению системы

Требования к математическому обеспечению не предъявляются.

4.3.2. Требования к информационному обеспечению системы

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

в системе

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

следующие общие требования:

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

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

документа (СЭМД);

Медицинская информация должна храниться в Системе в деперсонифицированном

виде;

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

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

Список используемых источников приведѐн в разделе 9 данного ТЗ.

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

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





Информация в Системе должна обладать достаточной полнотой для обеспечения

достижения целей создания Системы;

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

структурированной и неструктурированной медицинской информации, в том числе

хранение мультимедийных данных;

Основной единицей хранения является СЭМД, структура которого разрабатывается с

учѐтом международных стандартов в сфере информатизации здравоохранения;

Состав СЭМД должен обеспечивать однозначное определение обстоятельств его

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

учреждение, и др.);

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

информации и прав запрашивающего информацию пользователя (системы);

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

аннулирование СЭМД по пользователям (ролям пользователей) и по срокам;

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

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

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

операции записи, изменения (например, статуса данных), чтения и архивации данных.

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

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

Введѐнная в Систему информация не подлежит физическому удалению; все когда-либо

введѐнные в Систему данные (в том числе журналы, автоматически создаваемые

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

определѐнного регламентами, срока хранения.

Протоколы и параметры протоколов должны удовлетворять следующим общим

требованиям:

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

параметров, а группы параметров – в разные протоколы;

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

протоколов и хранения соответствия СЭМД в иЭМК без изменения структуры

хранилища. Должна быть обеспечена возможность поиска по значениям различных

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

ЛПУ, случая обращения;





Версионность структуры протоколов. Должна быть обеспечена возможность изменения

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

параметров или групп параметров начиная с определѐнной даты;

Типизация параметров протокола. Должна быть обеспечена поддержка использования

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

o Текстовый (в том числе с возможностью выбора текста из предварительно

настроенного справочника);

o Числовой (целое и вещественное число):

Простое значение;

Пропорции;

Интервал;

o Количество (число и единица измерения);

o Дата/время:

Простое значение;

Длительность;

Интервал;

o Выбор из списка, в том числе множественный;

o Логический (да/нет, положительный/отрицательный);

o Мультимедиа (рисунок, звук, видео, текст и др.);

o URI (ссылка);

o Ссылка на объект;

o Таблица значений.

Настройка параметров протокола. Должна быть обеспечена возможность настройки

свойств параметра протокола пользователями с ролью Разработчик протоколов с

использованием DI без необходимости перезапуска Системы или еѐ подсистем;

Настройка печатных форм. Должна быть обеспечена возможность настройки печатных

форм для протоколов пользователями с ролью Разработчик протоколов с


Настройка экранных форм. Должна быть обеспечена возможность настройки экранных

форм для протоколов пользователями с ролью Разработчик протоколов с


Применение шаблонов значений параметров протоколов. Должна быть обеспечена

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

применения при заполнении протоколов данного типа. Шаблоны заполнения протокола





могут создаваться и использоваться на уровне отдельного пользователя (медицинского

работника) или на уровне отделения;

Уровни использования протоколов. Должна быть обеспечена возможность создания и

использования параметров протоколов, групп параметров протоколов, параметров,

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

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

должности, Системы;

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

изменений в составе или структуре параметров протоколов, групп параметров

протоколов, параметров, печатных и экранных форм протокола, шаблона протокола.

Изменения становятся доступны для использования в Системе с даты, указанной при

публикации этих изменений;

Протокол (совокупность протоколов), а также параметры протоколов или группы

параметров могут быть обязательными и необязательными для заполнения

пользователями. Необходимость заполнения протоколов (параметров) может

определяться на уровне отдельного пользователя, отделения, ЛПУ или Системы. На

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

минимальным. По мере освоения пользователями возможностей системы количество

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

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

Экспорт и импорт параметров протоколов, групп параметров протоколов, протоколов,

шаблонов протоколов, экранных и печатных форм в xml формате. Структура

применяемых xml файлов должна быть определена дополнительно при техническом

проектировании.

Источником данных для СИМИ должны являться медицинские информационные системы

медицинских организаций, поддерживающие ведение электронной медицинской карты (ЭМК)

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

ЕМИАС.

Каждый СЭМД должен быть подписан электронной подписью (в терминах Федерального

закона Российской Федерации от 6 апреля 2011 года № 63-ФЗ "Об электронной подписи" с учѐтом

последних редакций). Технология обработки электронной подписи в СИМИ должна

соответствовать реализации электронной подписи в рамках БМИ ЕМИАС.

Ответственность за содержание медицинской информации несут медицинские работники,

еѐ подписавшие.





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

СЭМД по пользователям и по срокам. При аннулировании должна сохраняться полная копия

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

допускающий такое изменение документа.

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

информации, включая:

Архивное хранение данных Регистра иЭМК;

Архивное хранение СЭМД;

Архивное хранение структурированных данных СЭМД.

В Системе должно быть реализовано распределение СЭМД и данных в составе СЭМД по

группам в соответствии с регламентными сроками хранения данных:

5 лет;

10 лет;

25 лет;

50 лет.

На стадии разработки технического проекта должен быть определѐн регламент архивного

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

К средствам архивного хранения;

К условиям архивации данных;

К порядку перезаписи/обновления данных;

К организации хранения архивных данных;

К организации доступа к архивным данным;

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

данных.

Регламент архивного хранения должен входить в состав эксплуатационных документов

Системы.

В составе подсистем СИМИ должны быть созданы базы данных, перечисленные ниже в

таблице 9:

Таблица 9. Базы данных подсистем СИМИ.

Подсистема Базы данных

Хранилище СЭМД База данных оперативного хранения СЭМД;

База данных архивного хранения СЭМД.





Подсистема Базы данных

Подсистема управления Регистром иЭМК База данных регистра иЭМК (оперативная);

База данных архивного хранения регистра

иЭМК.

Хранилище структурированных данных СЭМД Оперативная база структурированных данных

СЭМД;

База данных архивного хранения

структурированных данных СЭМД;

Хранилище протоколов База данных описаний объектов предметной

области (протоколы, группы параметров

протоколов, параметры, шаблоны протоколов,

экранные и печатные формы).

Подсистема управления НСИ База данных НСИ.

Подсистема администрирования База данных администрирования.

Подсистема управления доступом и

обеспечения информационной безопасности

База данных описаний пользовательских ролей

и матрицы доступа;

База данных аудита доступа.

Структуры баз данных СИМИ должны быть специфицированы на стадии разработки

технического проекта.

4.3.2.2. Требования к информационному обмену между компонентами

системы

Обмен информацией между подсистемами должен осуществляется путѐм совместного

доступа подсистем к общим наборам данных в базах данных Системы, а также через вызовы

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

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

процессами одновременно.

Хранилище СЭМД должно использовать сервисы подсистемы управления доступом для

ведения аудита событий загрузки и извлечения документов.

Назначение и изменение прав доступа к иЭМК, СЭМД и данным СЭМД должно

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





4.3.2.3. Требования к информационной совместимости со смежными

системами

Информационная совместимость со смежными системами и системой иЭМК, входящей в

Федеральный сегмент ЕГИСЗ, должна обеспечиваться:

Использованием принятых отраслевых, национальных и международных

классификаторов и нормативных документов;

Публикацией технического регламента взаимодействия с внешними системами;

Использованием единой для ЕМИАС НСИ, Общегородского Регистра Пациентов,

Регистра Медицинских работников, Регистра ЛПУ, единого каталога пользователей

БМИ ЕМИАС.

Реализацией хранения в Системе слабоструктурированной или неструктурированной

медицинской информации для возможности приѐма и регистрации документов (СЭМД)

из МИС, различающихся уровнем и составом используемых справочников.

Реализацией возможности расширения перечня поддерживаемых протоколов в ходе

эксплуатации Системы.

Требования к интеграции со смежными системами должны быть уточнены в ЧТЗ на стадии

технического проектирования.

4.3.2.4. Требования по использованию зарегистрированных

федеральных, отраслевых классификаторов, унифицированных

документов и классификаторов, действующих на данном

предприятии

При проектировании информационной модели Системы должны быть использованы

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

и федеральными или отраслевыми нормативными актами.

Классификаторы, используемые в Системе, должны быть нормализованы и

синхронизированы с классификаторами, используемыми в системах федерального сегмента

ЕГИСЗ.

В методических материалах по эксплуатации Системы должны быть предусмотрены

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

Для обеспечения неизменности отчѐтных данных в Системе должна быть реализована

версионность содержания классификаторов.





Состав используемых классификаторов должен быть определѐн в ЧТЗ на стадии


4.3.2.5. Требования по применению систем управления базами данных

Для хранения данных Системы должна использоваться промышленная СУБД. Перечень

возможных для использования при реализации Системы СУБД приведѐн в разделе 4.3.4.2

настоящего документа.

4.3.2.6. Требования к структуре процесса сбора, обработки, передачи

данных в системе и представлению данных

Регламент процесса сбора медицинских данных в Системе должен быть разработан на

стадии разработки технического проекта. Процесс подготовки СЭМД должен обеспечивать

поступление в СИМИ для регистрации, хранения и последующей обработки актуальной,

достоверной и непротиворечивой информации о случаях обращения пациента, состоянии его

здоровья и оказанной ему медицинской помощи.

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

Регистрация входящего СЭМД;

Выполнение форматного контроля СЭМД;

Сохранение СЭМД;

Контроль ссылочной целостности и корректности данных СЭМД и размещение данных

СЭМД в таблицах базы данных хранилища структурированных данных СЭМД;

Обновление (создание) интегральных показателей иЭМК пациента по данным СЭМД.

4.3.2.7. Требования к защите данных от разрушений при авариях и

сбоях в электропитании системы

Мероприятия по обеспечению сохранности данных при авариях и сбоях в электропитании

обеспечиваются в рамках проектов БМИ ЕМИАС (подсистема резервного копирования и

восстановления данных) и ЦОД ЕМИАС (обеспечение гарантированного электропитания).

4.3.2.8. Требования к контролю, хранению, обновлению и

восстановлению данных

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

и логического контроля входящих СЭМД, и применением необходимых ограничений на таблицы

баз данных.





Для хранения данных системы используется СУБД, средствами которой выполняются

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

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

должны применяться также средства СУБД.

Другие требования по обеспечению хранения и восстановления данных Системы

приведены в разделе 4.1.1.10.

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

Моделирование предметной области, требований Системы, еѐ архитектуры, компонентов

Системы и их взаимодействия должно быть произведено с использованием стандартов в области

разработки ПО.

Система должна поддерживать использование для текстовых полей кодировки UTF-8.

Система должна быть реализована с использованием языков программирования высокого

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

программирования и средств разработки должен быть сделан по результатам НИР на стадии


Для описания протоколов, параметров и внешних интерфейсов web-сервисов должны

применяться XML и WSDL.

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

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

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

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

латыни.

В качестве языка манипулирования данными и языка определения данных в СУБД должен

быть использован язык SQL.

4.3.4. Требования к программному обеспечению системы

4.3.4.1. Прикладное программное обеспечение

Разрабатываемое прикладное программное обеспечение (ППО) Системы должно обладать

следующими свойствами:

Функциональная достаточность (полнота);

Модульность построения и удобство эксплуатации;

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

системного ПО и общесистемной архитектуры в пределах требований к техническому





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

информационному обмену.

В ППО должны быть реализованы меры по защите от ошибок при вводе и обработке

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

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

Заказчику вместе с исходными кодами.

Вся эксплуатационная программная документация на разработанное ППО должна

соответствовать стандарту РД 50-34.698-90 и содержать все сведения, необходимые для его

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

проверки их функционирования с помощью соответствующих тестов.

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

следующие слои:

Уровень пользовательского интерфейса (UI) для обеспечения доступа пользователей к

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

Уровень бизнес - логики (Business Logic Layer), представляющий собой набор

программных сервисов, исполняемых на сервере приложений и реализующих всю

бизнес-логику и общесистемные механизмы;

Уровень данных (Data Layer), который должен быть реализован на основе

промышленной СУБД и СХД;

Уровень интеграции (Integration Layer), предназначенный для взаимодействия между

компонентами СИМИ и со смежными системами. Должен быть реализован на основе

промышленных интеграционных продуктов.

Разделение Системы на отдельные независимые слои должно обеспечить:

Возможность масштабирования каждого слоя Системы в отдельности с использованием

кластерных технологий и механизмов балансировки нагрузки для достижения

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

Возможность резервировать наиболее ответственные узлы для достижения высоких

показателей доступности и отказоустойчивости;

Возможность построения территориально разнесенной системы (когда различные части

системы физически расположены на различных площадках и аппаратных платформах);

Возможность разворачивать Систему в самых разных конфигурациях (различные

серверы приложений, СУБД, интеграционные решения).

СИМИ должна обеспечивать возможность настройки (создания, редактирования)

используемых в системе протоколов и процессов обработки СЭМД и применяемых при этом





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

для выполнения этой настройки.

4.3.4.2. Системное программное обеспечение

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

Детальные спецификации системного программного обеспечения должны быть определены на

стадии разработки технического проекта.

Таблица 10. Требования к системному программному обеспечению.

№ Категория ПО Требование

1. Пользовательский

интерфейс

Реализация пользовательского интерфейса Системы - должна

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

работы стандартных браузеров типа:

Mozilla Firefox (версия 7 и выше) – базовый браузер,

Google Chrome (версия 11.0 и выше),

Microsoft Internet Explorer (версия 8 и выше).

2. Сервер приложений Сервер должен представлять собой среду выполнения и

инструменты управления приложениями, созданными на

основе JavaEE и Web-служб. Должен быть сертифицирован

на соответствие стандарту JavaEE и обеспечивать поддержку

сложных защищѐнных транзакций. Конфигурация сервера

приложений должна обеспечивать наличие кластерных

возможностей, компонентов балансировки нагрузки с

кэшированием часто используемой информации и функций

обеспечения высокой степени готовности в распределенных

средах. Сервер должен поддерживать

кроссплатформенность, т.е. как минимум, следующие

операционные системы и платформы:

AIX®;

HP-UX® on PA-RISC;

HP-UX® on HP Integrity;

Linux® on x86;

Linux® on System z™;






Solaris® on SPARC;

Solaris® on x86;

Microsoft Windows Server 2008.

Сервер приложений должен обеспечивать совместимость с

СУБД, выбранной для использования при реализации

Системы.

Сервер приложений должен поддерживать, как минимум,

следующие HTTP-серверы:

Apache Server 2.0.59;

IBM HTTP Server 6.1;

IBM HTTP Server for i5/OS V5R4 and V6R1;

IBM Lotus Domino Enterprise Server (as Web server 8.0.1, 8.0,

7.0.3, 7.0.2, 7.0.1);

Microsoft Internet Information Services (versions include those

provided with supported Microsoft Windows operating

systems);

Sun Java System Web Server 6.1 SP3;

Sun Java System Web Server 6.0 SP9.

3. СУБД (Система

управления базой

данных)

СУБД должна обеспечивать:

Поддержку реляционной модели данных;

Поддержку обеспечения целостности данных с

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

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

сбоях;

Возможность перераспределения нагрузки, оптимизации и

корректировки SQL-запросов, выявления и

прогнозирования ошибок;

Возможность организации кластера СУБД;

Поддержку кроссплатформенности;

Возможность сжатия данных на уровне СУБД, включая






структурированные и неструктурированные данные, такие

как документы, изображения и мультимедиа, а также

сетевой трафик и данные в процессе резервного

копирования;

Конфиденциальность информации, передаваемой по сети,

предотвращая «прослушивание» и разнообразные виды

атак;

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

встроенные непосредственно в ядро СУБД;

Возможность разбиения таблицы и индексов на более

простые компоненты для обеспечения более простого

управления, производительности и доступности;

Возможность масштабирования, обеспечивающую быстрый

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

Автоматическое и динамическое разделение данных в

памяти нескольких серверов;

Возможность хранить и осуществлять выборки документов

в формате xml;Возможность обеспечивать непрерывный

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

случае сбоев.

Сервер должен поддерживать кроссплатформенность, т.е.

как минимум, следующие операционные системы и

платформы:

AIX®;

HP-UX® on PA-RISC;

HP-UX® on HP Integrity;

Linux® on x86;

Linux® on System z™;

Solaris® on SPARC;

Solaris® on x86;

Microsoft Windows Server 2008.






4. http-сервер http-сервер должен обеспечивать:

Возможность установления защищенного соединения с

клиентским ПО;

WSDL/SOAP;

Возможность кэширования статического контента и

документов;

Возможность балансировки внешних запросов;

Возможность сжатия ответов сервера методом gzip.

4.3.5. Требования к техническому обеспечению системы

Системное и прикладное программное обеспечение СИМИ развѐртывается на

существующем оборудовании Центра обработки данных (ЦОД) ЕМИАС, в состав которого

входят:

Группа фронтальных серверов;

Группа серверов приложений;

Группа серверов сервисной шины;

Группа серверов БД;

Система хранения данных;

Инфраструктура информационной безопасности.

Требования к параметрам оборудования ЦОД ЕМИАС должны быть уточнены на стадии

технического проектирования СИМИ.

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

модернизации здравоохранения города Москвы, создаваемый в рамках проекта Общегородской

информационный сервис Системы интегрированной медицинской информации Единой

медицинской информационно-аналитической системы города Москвы (СИМИ ЕМИАС) должен

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

централизованных вычислительных мощностях в составе общегородского центра обработки

данных. Информационное взаимодействие Общегородских информационных сервисов между

собой и с другими элементами системы должно осуществляться посредством Единой

интеграционной шины ЕМИАС.





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

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

4.3.7. Требования к организационному обеспечению системы

В ходе разработки технического проекта и разработки Системы должно быть организовано

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

реализацией проекта, в том числе вопросов согласования требований к СИМИ и к другим

системам в составе ЕМИАС.

Эксплуатация Системы обеспечивается эксплуатирующей организацией.

Ввод Системы в эксплуатацию должен проводиться поэтапно, с последовательным

расширением перечня обрабатываемых типов СЭМД и увеличением количества ЛПУ,

использующих СИМИ.

На стадии разработки технического проекта Системы должны быть разработаны и

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

персонала Системы.

4.3.8. Требования к методическому обеспечению системы

При разработке СИМИ рекомендуется использовать методические материалы

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

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

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

В ходе разработки технического проекта Системы должны быть разработаны:

Методические рекомендации для разработчиков;;

Руководство разработчика протоколов;

Руководство программиста.

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

протоколов, форматы СЭМД и типы (форматы) данных, приведены требования к использованию

классификаторов и справочников при формировании СЭМД, специфицированы интерфейсы web-

сервисов и диаграммы взаимодействия. Для сервисов, предоставляемых Системой для

использования смежными и внешними информационными системами, должны быть разработаны

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





5. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО

СОЗДАНИЮ (РАЗВИТИЮ) СИСТЕМЫ

5.1. Перечень этапов работ по созданию системы и их документирование

Процесс создания ИС, согласно ГОСТ 34.601-90, представляет собой совокупность

упорядоченных во времени, взаимосвязанных, объединенных в стадии и этапы работ, выполнение

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

предыдущих разделах данного документа.

Этапы работ выделены как части общего процесса создания ИС по соображениям

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

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

требованиям ГОСТ 34.201-89.

Состав работ по этапам приведѐн в таблице 11.

Таблица 11. Состав работ по этапам.

№

этапа Наименование этапа Результат выполнения работ Срок

1 Научно-

исследовательские

работы, уточнение

требований и техно-

рабочее проектирование

Устав проекта,

Рабочий план проекта (приложение к

Уставу проекта),

Отчѐт о НИР,

Частные технические задания на

подсистемы по ГОСТ 34.602-89,

Модель нарушителя и угроз

информационной безопасности,

Ведомость технического проекта по РД 50-

34.698-90 п.2.1,

Пояснительная записка к техническому

проекту по РД 50-34.698-90 п.2.2,

Описание информационного обеспечения

по РД 50-34.698-90 п.5.3,

Описание программного обеспечения по РД

50-34.698-90 п.6.1,

Описание комплекса технических средств

по РД 50-34.698-90 п.4.2,

Перечень входных сигналов и данных по

РД 50-34.698-90 п. 5.2,

Перечень выходных сигналов (документов)

по РД 50-34.698-90 п.5.2,

Программа и методика испытаний

(компонентов, комплексов средств

автоматизации, подсистем, систем) по РД

50-34.698-90 п.2.14,

Не менее 70 дней,

но не более 110

дней





№

этапа Наименование этапа Результат выполнения работ Срок

Ведомость машинных носителей

информации по РД 50-34.698-90 п. 5.4.1,

Акт сдачи-приѐмки отчетных документов.

2 Разработка программ Разработанное программное обеспечение

подсистем СИМИ ЕМИАС на машинных

носителях,

Ведомость машинных носителей

информации по РД 50-34.698-90 п. 5.4.1,

Ведомость эксплуатационных документов

по РД 50-34.698-90 п.2.13,

Паспорт по РД 50-34.698-90 п.2.8,

Общее описание системы по РД 50-34.698-

90 п.2.11,

Описание технологического процесса

обработки данных по РД 50-34.698-90 п.3.5,

Руководство администратора системы по

РД 50-34.698-90 п. 3.4,

Руководство разработчика протоколов по

РД 50-34.698-90 п. 3.4,

Руководство программиста по РД 50-

34.698-90 п.3.4,

Политика обеспечения информационной

безопасности,

Инструкция по обеспечению защиты

информации,

Регламент сопровождения и эксплуатации

системы.

Не менее 220

дней, но не более

300 дней

3 Ввод в действие Протокол проведения предварительных

испытаний,

Акт приѐмки в опытную эксплуатацию,

Отчѐт о результатах опытной эксплуатации,

Протокол проведения приемочных

испытаний,

Акт приемки в промышленную

эксплуатацию,

Акты о проведении гарантийных работ по

периодам эксплуатации.

Не менее 60 дней,

но не более 100

дней

Состав предъявляемой по завершении второго и третьего этапов документации может быть

уточнѐн или дополнен по результатам НИР, выполняемой на первом этапе.

5.2. Содержание работ первого этапа

Первый этап «Научно-исследовательские работы, уточнение требований и техно-рабочее

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

успех проекта в целом.





5.2.1. Проектный офис

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

устава проекта. Целью является повышение эффективности взаимодействия всех участников

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

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

сторон.

Устав проекта является основным регламентным документом, в котором определяются:

Состав проектных групп со стороны Заказчика и Исполнителя, кураторы проекта;

Разграничение зон ответственности Заказчика и Исполнителя;

Порядок и способы взаимодействия сторон;

Регламенты предоставления проектных документов и сроки их согласования;

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

конфиденциальности разработанной проектной документации и информации, которой

обмениваются Стороны в ходе выполнения работ;

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

выходящие за договорные сроки этапов).

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

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

в количестве, указанном в уставе проекта.

Проектная группа Заказчика и Исполнителя должны располагать средствами совместной

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

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

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

Хранилище должно обеспечивать различные права доступа к документам членам

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

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

5.2.2. Научно-исследовательские работы

В ходе первого этапа должен быть выполнен анализ и обобщѐн опыт применения

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

обосновано их применение либо нецелесообразность применения в СИМИ ЕМИАС. В качестве

базовых следует рассматривать международные стандарты HL7 (версии 2.х и 3.х), IHE, OpenEHR,

LOINC, SNOMED и другие, а также российские ГОСТы по информатизации здравоохранения.





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

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

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

Медицинская информация о состоянии здоровья пациента поддерживается в качестве

информационного ресурса во многих российских и зарубежных медицинских учреждениях (МИС,

ЛИС и пр.), в сервисах ведения персональных электронных медицинских записей, органами

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

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

анализ неудачных подходов очень важен при выборе архитектуры и технологии ИС, регламентов

информационного обмена.

Следует изучить функциональные возможности и архитектуру медицинских систем,

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

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

степени структуризации данных ЭМК.

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

состав документации по итогам первого этапа.

5.2.3. Разработка частных технических заданий

В ходе выполнения работ первого этапа должно быть проведено уточнение требований, и

разработаны ЧТЗ на следующие подсистемы:

Управление НСИ (в том числе требования к содержимому);

Хранилище иЭМК в составе:

o Хранилище СЭМД;

o Подсистема управления регистром иЭМК;

o Хранилище структурированных данных СЭМД.

Хранилище протоколов в составе:

o Конструктор протоколов;

o Конструктор шаблонов;

o Конструктор экранных форм;

o Конструктор печатных форм.

Администрирование;

Управление доступом и обеспечение информационной безопасности;

Интеграция;

Адаптеры для сопряжения со смежными системами;





Мониторинг работоспособности.

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

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

изложенные в текущем документе.

Частные технические задания должны быть согласованы с Заказчиком до начала второго

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

обеспечении.

5.2.4. Разработка модели нарушителя и угроз ИБ

Перед выполнением работ по разработке ЧТЗ на подсистему управления доступом и

информационной безопасности должны быть определены потенциальные нарушители и угрозы

информационной безопасности СИМИ, а также оценены вероятность и последствия реализации

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

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

формирующие защищенное окружение, так и собственные средства защиты СИМИ. Таким

образом, все направления защиты от угроз информационной безопасности СИМИ должны

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

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

собственным функционалом подсистем СИМИ. Соответственно, в отношении направлений

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

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

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

СИМИ, должны быть спроектированы соответствующие модули и компоненты подсистем СИМИ.

Должны быть определены защищаемые объекты Системы, основные угрозы безопасности,

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

атак на информационные и телекоммуникационные ресурсы Системы, определены совокупности

условий и факторов, создающих опасность нарушения характеристик безопасности объектов,

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

этих возможностей. На основании полученных данных должны быть сформированы Модель угроз

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

документах.

Модель нарушителя информационной безопасности должна определять:

Классификацию типов возможных нарушителей информационной безопасности;

Предположения об имеющейся у нарушителя информации;





Основные каналы, цели и объекты атак;

Предположения об имеющихся у нарушителя средствах.

Модель угроз информационной безопасности должна определять:

Защищаемые объекты;

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

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

Уязвимости Системы к деструктивным воздействиям.

ЧТЗ на подсистему управления доступом и информационной безопасности должно

разрабатываться на основе результатов разработки модели нарушителя и угроз и уточнять

основные или определять дополнительные требования по обеспечению информационной

безопасности к системному программному обеспечению и аппаратному комплексу СИМИ и

систем инфраструктурного уровня, формирующих защищенное окружение ЕМИАС. При этом

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

Требования к аутентификации пользователей;

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

Требования к мониторингу информационной безопасности;

требования к безопасности сетевой инфраструктуры;

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

Требования к антивирусной защите;

Требования к средствам обнаружения и предотвращения вторжений и поиска

уязвимостей;

Требования к контролю целостности программной среды;

Требования к физической защите мест размещения средств обработки и хранения

конфиденциальной информации.

5.2.5. Разработка прототипа

На первом этапе требуется разработать прототип СИМИ ЕМИАС, в котором будут

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

обследования.

В ЦОД ЕМИАС необходимо развернуть стенды для проведения дальнейших работ по

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

демонстрации результатов работ Заказчику.

Разработанный прототип должен быть установлен на всех трѐх стендах в рамках первого

этапа проектных работ.





5.2.6. Разработка технического проекта

По результатам разработки прототипа должен быть разработан технический проект (с

пояснительной запиской) в составе:

Ведомость технического проекта по РД 50-34.698-90 п.2.1;

Пояснительная записка к техническому проекту по РД 50-34.698-90 п.2.2;

Описание информационного обеспечения по РД 50-34.698-90 п.5.3;

Описание программного обеспечения по РД 50-34.698-90 п.6.1;

Описание комплекса технических средств по РД 50-34.698-90 п.4.2;

Перечень входных сигналов и данных по РД 50-34.698-90 п. 5.2;

Перечень выходных сигналов (документов) по РД 50-34.698-90 п.5.2.

Документы в составе технического проекта должны содержать спецификации:

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

обеспечения Системы, включая сервера СУБД и сервера приложений;

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

другого системного программного обеспечения;

Выбор системного программного обеспечения должен соответствовать перечню,

приведѐнному в разделе 4.3.4.2.

Результатом этапа должна быть готовность к началу реализации СИМИ ЕМИАС.

5.2.7. Разработка плана релизов

По результатам первого этапа работ должен быть разработан и согласован план выпуска

релизов Системы в рамках второго этапа, содержащий не менее 5 релизов.

5.3. Содержание работ второго этапа

5.3.1. Разработка программного обеспечения

На втором этапе проводится разработка программного обеспечения согласно

разработанному техническому проекту, описаниям информационного и программного

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

5.3.2. Разработка эксплуатационной документации

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

следующем составе:

Ведомость эксплуатационных документов по РД 50-34.698-90 п.2.13;

Паспорт по РД 50-34.698-90 п.2.8;





Общее описание системы по РД 50-34.698-90 п.2.11;

Описание технологического процесса обработки данных по РД 50-34.698-90 п.3.5;

Руководство администратора системы по РД 50-34.698-90 п. 3.4;

Руководство программиста по РД 50-34.698-90 п.3.4.

5.3.3. Выпуск релизов (версий) СИМИ ЕМИАС

В ходе проектных работ планируется выпустить не менее пяти релизов для отражения (и

контроля) различных этапов разработки в соответствии с планом, согласованным на первом этапе.

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

СИМИ ЕМИАС к внедрению.

5.4. Содержание работ третьего этапа

На третьем этапе проводится внедрение СИМИ ЕМИАС. На этом этапе:

1. До начала работ по внедрению должны быть разработаны документы:

Политика обеспечения информационной безопасности СИМИ. Этот документ должен

регламентировать процессы по обеспечению информационной безопасности при

эксплуатации Системы;

Инструкция по обеспечению защиты информации в СИМИ.

2. Будут проведены испытания, которые состоят из предварительных испытаний по

согласованной Программе и методике и из нагрузочного тестирования. Программное

обеспечение СИМИ ЕМИАС будет оптимизировано по результатам испытаний под

проектную нагрузку.

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

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

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

3. Отладка взаимодействия с МИС.

4. Обучение администраторов СИМИ ЕМИАС. Обучение проводит Исполнитель на основе

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

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

5. Опытная эксплуатация.

6. Приѐмочные испытания.

7. Промышленная эксплуатация начинается после успешного завершения приемочных

испытаний.





С момента начала промышленной эксплуатации Исполнитель организует гарантийное

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

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

программного обеспечения определяются договорными соглашениями Заказчика и Исполнителя.





6. ПОРЯДОК КОНТРОЛЯ И ПРИЁМКИ СИСТЕМЫ

Виды, состав, объѐм и методы испытаний должны соответствовать требованиям ГОСТ

34.603-92 «Виды испытаний автоматизированных систем».

Целью этапа является подтверждение соответствия создаваемой системы требованиям

технического задания.

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

определения и проверки соответствия требованиям технического задания количественных и (или)

качественных характеристик системы, выявления и устранения недостатков в действиях системы,

в разработанной документации.

Система проходит следующие виды испытаний:

Предварительные испытания;

Опытную эксплуатацию в пилотной зоне (относится к видам испытаний согласно ГОСТ

34.603-92);

Приѐмочные испытания.

Заказчик обеспечивает помещение, оборудование и инфраструктуру в составе в ЦОД

ЕМИАС, а Исполнитель подготавливает стенд для проведения работ: выполняет установку и

настройку подготовленного релиза на предоставленном оборудовании. Испытания проводятся в

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

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

протоколу может быть составлен перечень выявленных замечаний. Заказчик и Исполнитель

согласуют сроки устранения критических замечаний.

В таблице 12 приведен перечень документов, которые должны быть сформированы по

каждому виду испытаний.

Таблица 12. Документы и виды испытаний.

Вид испытания Документы этапа Кто формирует

1 Предварительные

испытания

Программа и методика

испытаний

Исполнитель

Протокол проведения

предварительных испытаний

Исполнитель и Заказчик

Акт приемки в опытную

эксплуатацию


2 Опытная эксплуатация Программа опытной Исполнитель





Вид испытания Документы этапа Кто формирует

эксплуатации

Приказ о проведении опытной

эксплуатации

Заказчик

Рабочий журнал проведения

опытной эксплуатации

Заказчик

Протокол опытной эксплуатации Заказчик

Акт завершения опытной

эксплуатации и допуска системы

к приемочным испытаниям


3 Приемочные

испытания

Программа и методика

испытаний

Исполнитель

Протокол проведения

приѐмочных испытаний


Акт приѐмки в промышленную

эксплуатацию


Содержание и оформление «Программы и методики испытаний» должно соответствовать

РД 50-34.698-90 п. 2.14 «Программа и методика испытаний (компонентов, комплексов средств

автоматизации, подсистем, систем)». ГОСТ допускает добавление дополнительных разделов в

документ, объединение или исключение. Решение принимает разработчик в зависимости от

особенностей создаваемой ИС.

Объѐм испытаний для каждого вида испытаний определен в таблице 13, приведенной ниже.

Таблица 13. Объѐм испытаний.

Вид испытания Объем испытаний

1 Предварительные испытания Функциональное тестирование

2 Опытная эксплуатация Функциональное тестирование;

Тестирование интерфейса;

Тестирование эргономичности (юзабилити).

3 Приемочные испытания Функциональное тестирование;

Тестирование производительности

(нагрузочное тестирование);

Тестирование совместимости (комплексное

тестирование).





Тестирование производительности должно быть выполнено на специально подготовленном

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

состав тестового стенда должны быть предварительно согласованы с Заказчиком. Исполнитель

должен подготовить специализированные скрипты.

Испытания производительности могут быть проведены непосредственно Исполнителем

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

Заказчику перед проведением приемочных испытаний должны быть переданы протоколы

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

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

Тестирование интерфейса и эргономичности проводит Заказчик в процессе опытной

эксплуатации.

На этапе проведения приемочных испытаний проводится комплексное тестирование,

которое включает в себя проверку работоспособности интеграционных компонентов. Сценарии

испытаний должны содержать сценарии взаимодействия СИМИ ЕМИАС со смежными

подсистемами.





7. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО

ПОДГОТОВКЕ ОБЪЕКТА АВТОМАТИЗАЦИИ К ВВОДУ СИСТЕМЫ В

ДЕЙСТВИЕ

7.1. Техническая подготовка к вводу системы в действие

7.1.1. Основные мероприятия со стороны Заказчика

Для развертывания стендов, требуемых для проведения испытаний (см. раздел «Порядок

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

средства связи.

Опытная и промышленная эксплуатация Системы осуществляется на программных,

технических и инфраструктурных средствах предоставляемых БМИ ЕМИАС и ЦОД ЕМИАС.

Заказчик должен обеспечить наличие технических средств (оборудования и инфраструктуры) с

характеристиками, обеспечивающими работу в требуемых режимах функционирования (см.

раздел 4.1.1.4 «Требования к режимам функционирования системы »), с требуемыми показателями

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

Техническом задании:

По диагностированию;

По надежности;

По безопасности;

По эргономике и технической эстетике;

По эксплуатации, техническому обслуживанию, ремонту и хранению компонентов

системы;

По обеспечению безопасности информации;

По сохранности информации при авариях.

Основные характеристики технического обеспечения приведены в разделе «Требования к

техническому обеспечению».

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

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

7.1.2. Основные мероприятия со стороны Исполнителя

Исполнитель должен принять от Заказчика подготовленное оборудование стенда,

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

сторонних производителей и развернуть разработанные подсистемы СИМИ на стенде.





Работы по переносу разработанных подсистем СИМИ необходимо выполнить для каждого

релиза (версии), поставляемой Исполнителем на этапе разработки. По результатам завершения

проектных работ по созданию СИМИ Исполнитель переносит разработанное программное

обеспечение в среду промышленной эксплуатации.

7.1.3. Основные мероприятия с привлечением прочих участников

Проект предусматривает разработку решения, взаимодействующего с внешними

системами:

Смежными подсистемами ЕМИАС;

Инфраструктурой УЭК.

Список внешних систем должен быть уточнѐн на стадии технического проектирования при

разработке ЧТЗ.

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

разработчиков ЕМИАС и других внешних систем, с которыми требуется обеспечить интеграцию

СИМИ.

Исполнитель обеспечивает настройку СИМИ ЕМИАС на этапах подготовки к проведению

испытаний, а также в среде опытной и промышленной эксплуатации.

7.2. Организационная, методическая подготовка к вводу системы в

действие

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

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

разделах настоящего Технического задания.

Должностные обязанности персонала, участвующего в эксплуатации СИМИ ЕМИАС,

должны быть изложены в технологических инструкциях либо в должностных инструкциях

штатных единиц организации Заказчика.

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

штатной (организационной) структуры организации Заказчика, руководство организации должно

закрепить перераспределение обязанностей персонала в положениях о соответствующих

подразделениях.

Исполнитель должен подготовить методические документы:

Для обучения персонала Заказчика (повышения квалификации);

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

инструкциях.





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

администратора, программиста или другой эксплуатационной документации. Допускается

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

и утверждѐн в порядке, общем для всей документации на СИМИ.





8. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ

Требования к документированию каждого из этапов работы приведены в таблице раздела

5.1 «Перечень этапов работ по созданию системы и их документирование».

Рабочая документация проекта, необходимая Исполнителю на различных стадиях

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

тестирования, не предъявляются Заказчику как итоговые документы этапов работы или для

проведения испытаний.

Исполнитель предъявляет и передает Заказчику следующие документы:

Устав проекта;

Рабочий план проекта (приложение к Уставу проекта, по согласованной с Заказчиком

форме);

Паспорт по РД 50-34.698-90 п.2.8;

Ведомость эксплуатационных документов по РД 50-34.698-90 п.2.13;

Отчет о НИР;

Частные технические задания на подсистемы по ГОСТ 34.602-89;

Модель нарушителя и угроз;

Ведомость технического проекта по РД 50-34.698-90 п.2.1;

Пояснительная записка к техническому проекту по РД 50-34.698-90 п.2.2;

Описание информационного обеспечения по РД 50-34.698-90 п.5.3;

Описание программного обеспечения по РД 50-34.698-90 п.6.1;

Описание комплекса технических средств по РД 50-34.698-90 п.4.2;

Перечень входных сигналов и данных по РД 50-34.698-90 п. 5.2;

Перечень выходных сигналов (документов) по РД 50-34.698-90 п.5.2;

Программа и методика испытаний (компонентов, комплексов средств автоматизации,

подсистем, систем) по РД 50-34.698-90 п.2.14;

Общее описание системы по РД 50-34.698-90 п.2.11;

Описание технологического процесса обработки данных по РД 50-34.698-90 п.3.5;

Руководство администратора системы по РД 50-34.698-90 п. 3.4;

Руководство пользователя по РД 50-34.698-90 п. 3.4;Руководство программиста по РД

50-34.698-90 п.3.4;

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

Инструкция по обеспечению защиты информации;





Регламент обслуживания;

Ведомость машинных носителей информации по РД 50-34.698-90 п. 5.4.1.

9. ВСЕ ТЕКСТОВЫЕ ДОКУМЕНТЫ ДОЛЖНЫ БЫТЬ ПРЕДСТАВЛЕНЫ

КАК НА БУМАЖНЫХ, ТАК И НА МАШИННЫХ НОСИТЕЛЯХ (НА

МАШИННЫХ НОСИТЕЛЯХ – В ФОРМАТЕ ДОКУМЕНТОВ MS

OFFICE). ИСТОЧНИКИ РАЗРАБОТКИ

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

которых также было разработано настоящее Техническое задание:

«Концепция создание единой государственной информационной системы в сфере

здравоохранения», приказ Министерства здравоохранения и социального развития

№364 от 28.04.2011;

Программа модернизации здравоохранения города Москвы на 2011-2012 годы;

Постановление Правительства Москвы от 27.10.2011 № 513-ПП и Приложение 4 к

этому постановлению;

Постановление Правительства Москвы от 21 декабря 2011 г. N 604-ПП;

Приказ Министерства связи и массовых коммуникаций Российской Федерации от

27.12.2010 г. №190;

ГОСТ 19.101-77 «Виды программ и программных документов»;

ГОСТ 19.301-79 «Программа и методика испытаний. Требования к содержанию и

оформлению»;

ГОСТ 34.003-90 «Автоматизированные системы. Термины и определения»;

ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании

автоматизированных систем»;

ГОСТ 19.301-79 «Программа и методика испытаний. Требования к содержанию и

оформлению»;

ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»;

ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы»;

ГОСТ 34.603-92 «Виды испытаний автоматизированных систем»;

РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию

документов»;





ГОСТ 15150-69 «Машины, приборы и другие технические изделия. Исполнения для

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

транспортирования в части воздействия климатических факторов внешней среды»;

ГОСТ 21552-84 «Средства вычислительной техники. Общие технические требования,

приемка, методы испытаний, маркировка, упаковка, транспортирование и хранение»;

ГОСТ 27201-87 «Машины вычислительные электронные персональные. Типы,

основные параметры, общие технические требования»;

ГОСТ 28195-89 «Оценка качества программных средств. Общие положения»;

ГОСТ 28806-90 «Качество программных средств. Термины и определения»;

ГОСТ 16504-81 «Система государственных испытаний продукции. Испытания и

контроль качества продукции. Термины и определения»;

ГОСТ Р ИСО/МЭК ТО 12182-2002 «Информационная технология. Классификация

программных средств»;

ГОСТ Р ИСО/МЭК 12207:1999 «Процессы жизненного цикла программных средств»;

ГОСТ Р ИСО/МЭК ТО 15271-2002 «Информационная технология. Руководство по

применению ГОСТ Р ИСО/МЭК 12207»;

ГОСТ Р ИСО/МЭК 9126:93 «Информационная технология. Оценка программной

продукции. Характеристики качества и руководства по их применению»;

ГОСТ Р ИСО/МЭК 15026:1998 «Информационная технология. Уровни целостности

систем и программных средств»;

ГОСТ Р ИСО/МЭК 14764:2002 «Информационная технология. Сопровождение»;

ГОСТ Р ИСО/МЭК ТО 9294:93 «Информационная технология. Руководство по

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

ГОСТ Р ИСО/МЭК 15910-2002 «Информационная технология. Процесс создания

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

ISO 14756: 1999 «ИТ. Измерение и оценивание производительности программных

средств компьютерных вычислительных систем»;

ГОСТ 2.051-2006 «Единая система конструкторской документации. Электронные

документы. Общие положения»;

СанПиН 2.2.2.542-96 «Гигиенические требования к видеодисплейным терминалам,

персональным электронно-вычислительным машинам и организации работы» (утв.

постановлением Госкомсанэпиднадзора РФ от 14 июля 1996 г. № 14);

ГОСТ Р 52636-2006 Электронная история болезни. Общие положения;





ГОСТ Р ИСО 13606-1 Информатизация здоровья. Обмен электронными медицинскими

картами. Базовая модель;

ГОСТ Р ИСО/TС 18308-2008 Информатизация здоровья. Требования к архитектуре

электронного учета здоровья;

ГОСТ Р ИСО/ТО 20514-2008. Информатизация здоровья. Определение, область

применения и контекст электронной истории болезни;

ГОСТ Р 52976-2008 Информатизация здоровья. Состав первичных данных медицинской

статистики лечебно-профилактического учреждения для электронного обмена этими

данными. Общие требования;

ГОСТ Р 52600-2006 Протоколы ведения больных. Общие положения;

ГОСТ Р ИСО/ТО 20514-2009 Информатизация здоровья. Электронный учет здоровья.

Определение, область применения и контекст;

ГОСТ Р ИСО 17432-2009 Информатизация здоровья. Сообщения и обмен информацией.

Веб-доступ к постоянным объектам DICOM;

ГОСТ 91500.09.0001-1999 Протоколы ведения больных. Общие положения.

Перечисленные ниже международные стандарты должны носить методический,

рекомендательный характер:

ISO 1087-1:2000, Terminology work — Vocabulary — Part 1: Theory and application;

ISO 13606-1:2008, Health informatics — Electronic health record communication — Part 1:

Reference;

ISO 18308:2011(Е), Health informatics — Requirements for an electronic health record

architecture;

ISO 7498-2:1989, Information processing systems — Open Systems Interconnection — Basic

Reference Model — Part 2: Security Architecture;

ISO/HL7 10781:2009, Electronic Health Record-System Functional Model, Release 1.1;

ISO/HL7 21731:2006, Health informatics -- HL7 version 3 -- Reference information model --

Release 1;

ISO/HL7 27931:2009, Data Exchange Standards -- Health Level Seven Version 2.5 -- An

application protocol for electronic data exchange in healthcare environments;

ISO/HL7 27932:2009, Data Exchange Standards -- HL7 Clinical Document Architecture,

Release 2;

ISO/IEC 10746-1, Information technology — Open Distributed Processing — Reference

model: Overview — Part 1;





ISO/IEC 10746-2:2009, Information technology — Open distributed processing — Reference

model: Foundations — Part 2;

ISO/IEC 2382-17:1999, Information technology — Vocabulary — Part 17: Databases;

ISO/IEC 2382-4:1999, Information technology — Vocabulary — Part 4: Organization of data;

ISO/IEC 6523-1:1998, Information technology — Structure for the identification of

organizations and organization parts — Part 1: Identification of organization identification

schemes;

ISO/TR 20514:2005, Health informatics — Electronic health record — Definition, scope and

context;

ISO/TR 22221, Health informatics — Good principles and practices for a clinical data

warehouse;

ISO/TS 13606-4, Health informatics — Electronic health record communication — Part 4:

Security;

ISO/TS 22600-1:2006, Health informatics — Privilege management and access control — Part

1: Overview and policy management;

ISO/TS 25237:2008, Health informatics – Pseudonymization;

ISO/TS 29585, Health informatics — Deployment of a clinical data warehouse; Model.





ПРИЛОЖЕНИЕ 1. ПЕРЕЧЕНЬ ЗАКОНОДАТЕЛЬНЫХ АКТОВ И

МЕТОДОЛОГИЧЕСКИХ РЕКОМЕНДАЦИЙ В ЧАСТИ

ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

Федеральный закон Российской Федерации от 27.07.2006г. №149-ФЗ «Об информации,

информационных технологиях и о защите информации»;

Федеральный закон Российской Федерации от 27.07.2006г. №152-ФЗ «О персональных

данных»;

Федеральный закон Российской Федерации от 29.07.2004г. №98-ФЗ «О коммерческой

тайне»;

Указ Президента Российской Федерации от 06.03.1997г. №188 «Об утверждении

перечня сведений конфиденциального характера»;

«Положение об обеспечении безопасности персональных данных при их обработке в

информационных системах персональных данных», утверждено постановлением

Правительства РФ № 781 от 17 ноября 2007 г.;

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

использования средств автоматизации», утверждено постановлением Правительства РФ

№ 687 от 15 сентября 2008 г.;

«Методика определения актуальных угроз безопасности персональных данных при их

обработке в информационных системах персональных данных» от 15 февраля 2008 г.;

Приказ ФСТЭК от 5 февраля 2010 г. № 58 «Об утверждении положения о методах и

способах защиты информации в информационных системах защиты персональных

данных»;

Методические рекомендации по обеспечению с помощью криптосредств безопасности

персональных данных при их обработке в информационных системах персональных

данных с использованием средств автоматизации. ФСБ, 21 февраля 2008 г.

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

информационных системах персональных данных. ФСТЭК, от 15 февраля 2008 г.

«Порядок проведения классификации информационных систем персональных данных»,

утвержден совместным приказом ФБС России, ФСТЭК России и Мининформсвязи

России от 13 февраля 2008 г. №55/86/20»;

Типовые требования по организации и обеспечению функционирования шифровальных

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

содержащей сведений, составляющих государственную тайну в случае их





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

информационных системах персональных данных. ФСБ России, 21 февраля 2008 г.;

«Положение об особенностях оценки соответствия продукции (работ, услуг),

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

законодательством Российской Федерации информации ограниченного доступа, не

содержащей сведения, составляющие государственную тайну, а также процессов еѐ

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

эксплуатации, хранения, перевозки, реализации, утилизации и захоронения»,

утвержденное постановлением Правительства РФ от 15 мая 2010. №330";

«Методические рекомендации по оснащению медицинских учреждений компьютерным

оборудованием и программным обеспечением для регионального уровня Единой

государственной информационной системы в сфере здравоохранения, а также

функциональные требования к ним», от 14 ноября 2011 г., подготовленные

Минздравсоцразвития РФ;

«Методические рекомендации для организации защиты информации при обработке

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

занятости» от 23 декабря 2009 г, утвержденными Минздравсоцразвития РФ.





СПИСОК ИЗМЕНЕНИЙ

Дата Версия Описание изменений Автор

27.03.2012 0.1 Начальная версия документа

10.04.2012 0.2 Версия документа с учѐтом замечаний

рецензентов





Health & Medicine

ТЗ СИМИ ЕМИАС