ТЗ СПУ ЕМИАС

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

МОСКВЫ

СОГЛАСОВАНО

Министр Правительства Москвы,

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

города Москвы

______________________ Л.М. Печатников (личная подпись) (расшифровка подписи)

«___» ______________2012 г

УТВЕРЖДАЮ

Министр Правительства Москвы,

руководитель Департамента информационных

технологий города Москвы

______________________А.В. Ермолаев (личная подпись) (расшифровка подписи)

«___» ______________2012 г

ВЫПОЛНЕНИЕ НАУЧНО-ИССЛЕДОВАТЕЛЬСКИХ И ОПЫТНО-

КОНСТРУКТОРСКИХ РАБОТ ПО СОЗДАНИЮ ОБЩЕГОРОДСКОГО

ИНФОРМАЦИОННОГО СЕРВИСА ПЕРСОНИФИЦИРОВАННОГО

УЧЁТА МЕДИЦИНСКОЙ ПОМОЩИ

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

57011331.4258901.001.ТЗ

Версия 5.6

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

Исполнителя Должность

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

подписи)

«___» ______________20ХХ г

Должность

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

подписи)

«___» ______________20ХХ г

2012

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

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

Утвержден

57011331.4258901.001.И0-ЛУ

ВЫПОЛНЕНИЕ НАУЧНО-ИССЛЕДОВАТЕЛЬСКИХ И ОПЫТНО-

КОНСТРУКТОРСКИХ РАБОТ ПО СОЗДАНИЮ ОБЩЕГОРОДСКОГО

ИНФОРМАЦИОННОГО СЕРВИСА ПЕРСОНИФИЦИРОВАННОГО

УЧЁТА МЕДИЦИНСКОЙ ПОМОЩИ

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

57011331.4258901.001.ТЗ

Листов 89

Версия 5.6

2012

Департамент

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

Технологий

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

АННОТАЦИЯ

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

исследовательских и опытно-конструкторских работ по созданию общегородского

информационного сервиса Персонифицированного учѐта медицинской помощи» (СПУ ЕМИАС),

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

АС) и ее приемка при вводе в эксплуатацию.





СОДЕРЖАНИЕ

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

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

1.2. Шифр разработки ....................................................................................... 14

1.3. Исполнитель и Государственный заказчик разработки .................... 14

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

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

15

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

компонентами Системы ............................................................................................................... 28

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

системами ...................................................................................................................................... 28

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

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





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

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

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

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

4.1.3.1. Целевые показатели объема обрабатываемой информации ..................................... 36

4.1.3.2. Вероятностно-временные характеристики, при которых сохраняется целевое

назначение Системы ..................................................................................................................... 36

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

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

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

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

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

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

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

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

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

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

4.1.8.1.1. Классификация отказов СПУ ЕМИАС. .................................................................. 40

4.1.8.1.2. Требования к срокам устранения отказов. ............................................................. 41

4.1.8.2. Требования к техническому обслуживанию Системы .............................................. 42

4.1.8.3. Требования к ремонту и хранению компонентов Системы ...................................... 42

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

доступа ..................................................................................................................... 42

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

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

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

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

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

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

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

информации ............................................................................................................ 50





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

информации ............................................................................................................ 50

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

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

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

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

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

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

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

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

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

классификаторов, действующих на данном предприятии ........................................................ 53

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СОЗДАНИЮ (РАЗВИТИЮ)

СИСТЕМЫ ............................................................................................................. 61

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

документирование ................................................................................................. 61

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

5.2.1. Устав проекта ........................................................................................... 63

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





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

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

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

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

5.3.1. Разработка прототипа ............................................................................ 67

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

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

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

5.4.3. Выпуск релизов (версий) СПУ ЕМИАС ............................................. 70

5.5. Содержание работ четвѐртого этапа ....................................................... 70

6. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ .............................. 72

6.1. Виды, состав, объѐм и методы испытаний ............................................ 72

6.2. Порядок выполнения доработок и устранения допущенных

исполнителем ошибок, выявленных на стадии приемки ............................. 74

6.3. Сведения о гарантийном обслуживании................................................ 75

7. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО

ПОДГОТОВКЕ ОБЪЕКТА АВТОМАТИЗАЦИИ К ВВОДУ СИСТЕМЫ В

ДЕЙСТВИЕ ............................................................................................................ 76

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

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

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

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

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

действие ................................................................................................................... 77

8. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ.......................................... 79

9. ИСТОЧНИКИ РАЗРАБОТКИ..................................................................... 81

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ ....................................... 83

ПРИЛОЖЕНИЕ 1. СОСТАВ ПАКЕТА НСИ АИС ОМС ........................... 84





ПРИЛОЖЕНИЕ 2. ПЕРЕЧЕНЬ ЗАКОНОДАТЕЛЬНЫХ АКТОВ И

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

ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ ................... 87





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

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

СИСТЕМА

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

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

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

функций (ГОСТ 34.003)

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

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

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

попытке выполнения этих действий

АУТЕНТИФИКАЦИЯ От англ. Authentication — процедура проверки подлинности,

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

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

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

ВЕРТИКАЛЬНОЕ

МАСШТАБИРОВАНИЕ

Увеличение производительности каждого компонента системы

c целью повышения общей производительности

ВРЕМЕННОЕ

СВИДЕТЕЛЬСТВО

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

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

помощи медицинскими организациями при наступлении

страхового случая

ГОРИЗОНТАЛЬНОЕ

МАСШТАБИРОВАНИЕ

Разбиение системы на более мелкие структурные компоненты

и разнесение их по отдельным физическим машинам (или их

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

выполняющих одну и ту же функцию

ДИНАМИЧЕСКАЯ

БАЛАНСИРОВКА НАГРУЗКИ

Алгоритм динамической балансировки нагрузки использует

характеристики состояния системы и принимает решение о

перераспределении работы. Это подход позволяет реагировать

на изменение состояния вычислительной машины или

моделируемой системы и выполнить балансировку, если

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

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

расходы на сбор статистических данных о состоянии

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

принятие решений

http://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA





ИДЕНТИФИКАЦИЯ В информационных системах — присвоение субъектам и

объектам идентификатора и / или сравнение идентификатора с

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

ИНОГОРОДНИЙ ПАЦИЕНТ Пациент, застрахованный на территории иного субъекта РФ

(вне города Москвы), которому оказана медицинская помощь

по обязательному медицинскому страхованию (далее – ОМС) в

медицинской организации (далее – МО) города Москвы

ИНФОРМАЦИОННАЯ

ПОСЫЛКА

Сообщение в электронном виде, направленное адресату по

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

– ИП) регулируется ее назначением

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

СЕРВИС

Услуга, предполагающая обработку определенной

информации из транзакционных информационных систем

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

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

информации, заполнение, исправление или утверждение

отчетов о проделанной работе, подача заявок и их утверждение

КАТЕГОРИЯ ПАЦИЕНТА Пациент, застрахованный в городе Москве или вне


КОНЦЕПТУАЛЬНАЯ

АРХИТЕКТУРА СИСТЕМЫ

Обобщенная (высокоуровневая модель) приложения

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

компоненты информационной системы

НЕЗАРЕГИСТРИРОВАННЫЙ

НОВОРОЖДЕННЫЙ

Новорожденный до государственной регистрации рождения

ОТЧЕТНЫЙ ПЕРИОД В системе ОМС отчетный период равен календарному месяцу

ПЕРСОНИФИЦИРОВАННЫЙ

УЧЕТ

Система учета сведений об оказанной медицинской помощи

каждому пациенту в рамках системы ОМС

ПРИВЕДЁННАЯ ЦЕНА Стоимость услуги в различные отчѐтные периоды может

изменяться. Для корректного сравнения стоимости оказанной

медицинской помощи стоимость услуги из различных

отчетных периодов принимается равной стоимости одного

отчѐтного периода

РЕЕСТР ПАЦИЕНТОВ Перечень пациентов, получивших медицинскую помощь в МО

в течение отчетного периода. Представляется в электронном

виде. Реестры пациентов МО разбиты на 2 категории –





«застрахованные в городе Москве», «иногородние»

РЕЕСТР СЧЕТОВ-ФАКТУР

НА ПАЦИЕНТОВ

Перечень медицинских услуг, оказанных каждой категории

пациентов МО в течение отчетного периода. Представляется в

электронном виде

СЕТЕВЫЕ СЕРВИСЫ Взаимодействие компьютеров между собой, а также с другим

активным сетевым оборудованием, в TCP/IP-сетях

организовано на основе использования сетевых служб,

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

операционной системы — демонами в UNIX-подобных

операционных системах (далее – ОС), службами в ОС

семейства Windows и т. п.

СТАТИЧЕСКАЯ

БАЛАНСИРОВКА НАГРУЗКИ

Аналитический способ распределения нагрузки на

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

оценке загрузки каждого объекта на основе знаний о

приложении

СТРАХОВЩИК Страховая медицинская организация, зарегистрировавшая

полис ОМС

СЧЁТ МО Стоимость медицинских услуг, оказанных пациентам,

пролеченным медицинской организацией по Московской

городской программе ОМС. В электронном виде

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

реестров счетов на пациентов

СЧЁТ-ФАКТУРА МО Перечень видов, объемов и стоимости медицинской помощи,

оказанной за отчетный период каждой категории пациентов, по

которой МО имеет договорные отношения со страховой

медицинской организацией (далее – СМО) по оплате.

Оформляется на бумажном носителе

WEB-СЕРВИС От англ. web service — идентифицируемая веб-адресом

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

интерфейсами. Веб-службы могут взаимодействовать друг с

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

сообщений, основанных на определѐнных протоколах. Веб-

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

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





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

АИС ОМС Автоматизированная информационная система ОМС

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

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

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

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

ГОСТ Государственный стандарт

ЕГИСЗ Единая государственная информационная система в здравоохранении

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

Москвы

ЕРЗЛ Единый регистр застрахованных лиц

ИП Информационная посылка

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

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

МГФОМС Московский городской фонд ОМС

МО Медицинская организация

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

НСИ Нормативно-справочная информация

ОЗУ Оперативное запоминающее устройство

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

ОС Операционная система

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

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

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

РС Региональный сегмент

РФ Российская Федерация





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

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

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

СПУ Система персонифицированного учета медицинской помощи

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

СУМР Система управления медицинскими регистрами

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

СХД Сеть хранения данных. англ. Storage Area Network, SAN. Архитектурное

решение для подключения внешних устройств хранения данных

СМЭВ Система межведомственного электронного взаимодействия

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

УЕТ Условная единица трудозатрат

ФСБ Федеральная служба безопасности

ФСТЭК Федеральная служба по техническому и экспортному контролю

ЦАПК Центральный аппаратно-программный комплекс

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

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

CD Compact Disc — Компакт-диск. Оптический носитель информации

DNS Domain Name System — система доменных имѐн

DVD Digital Versatile Disc — цифровой многоцелевой диск

ESB Enterprise Service Bus — интеграционная шина данных предприятия

Gzip Утилита сжатия и восстановления (декомпрессии) файлов

HL7 Health Level 7 («Седьмой уровень») — стандарт обмена, управления и

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

HTTP HyperText Transfer Prоtocоl — «протокол передачи гипертекста».

Протокол прикладного уровня передачи данных

JavaEE Java Platform, Enterprise Edition, сокращенно Java EE — набор

спецификаций и соответствующей документации для языка Java,

http://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA





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

крупных предприятий

LOINC Logical Observation Identifiers Names and Codes — база данных и

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

лабораторных наблюдений

LPAR Logical Partition Access Resources — логический сервер в составе одного

физического сервера

OpenEHR Открытый стандарт управления, хранения и обмена электронными

историями болезни

SOAP Simple Object Access Protocol — простой протокол доступа к объектам.

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

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

SQL Structured Query Language — «язык структурированных запросов».

Универсальный компьютерный язык, применяемый для создания,

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

TCP/IP Transmission Control Protocol/Internet Protocol — протокол управления

передачей — набор сетевых протоколов разных уровней модели

сетевого взаимодействия, используемых в сетях

UI User Interface — Интерфейс пользователя, он же пользовательский

интерфейс

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

операционных систем

UTF-8 Unicode Transformation Format — формат преобразования Юникода,

совместимый с 8-битным кодированием текста

WSDL Web Services Description Language — язык описания веб-сервисов и

доступа к ним, основанный на языке XML

XML eXtensible Markup Language — расширяемый язык разметки





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

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

Полное наименование Системы: Выполнение научно-исследовательских и опытно-

конструкторских работ по созданию общегородского информационного сервиса

Персонифицированного учѐта медицинской помощи.

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

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

«Система».

1.2. Шифр разработки

Шифр разработки: 57011331.4258901.001

1.3. Исполнитель и Государственный заказчик разработки

Исполнитель: Исполнитель проекта определяется на основании результатов открытого

конкурса на право заключения Государственного контракта на «Выполнение научно-

исследовательских и опытно-конструкторских работ по созданию общегородского

информационного сервиса Персонифицированного учѐта медицинской помощи» (СПУ ЕМИАС).

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

Реквизиты государственного заказчика:

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

ИНН: 7710878000

КПП: 770101001

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

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

705

Р/счет № 40201810200000000001

БИК 044583001

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

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





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

здравоохранения, утверждена приказом Министерства здравоохранения и

социального развития Российской Федерации от 28 апреля 2011 года № 364;

– Раздел IV Приложения 3 (Подпрограмма «Внедрение современных

информационных систем в здравоохранение») Программы модернизации

здравоохранения города Москвы на 2011-2012 годы, утвержденной

постановлением Правительства Москвы от 7 апреля 2011 № 114-ПП «О

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

(в редакции постановления Правительства Москвы от 27 октября 2011 № 513-

ПП);

– Состав регионального фрагмента единой информационной системы в сфере

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

обязательным для создания в 2011 – 2012 годах в рамках реализации

региональных программ модернизации здравоохранения (Решение президиума

Совета при Президенте Российской Федерации по развитию информационного

общества в Российской Федерации от 14 апреля 2011 года №А4-6106).

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

Начало работ – с момента заключения Государственного контракта.

Окончание работ – в соответствии с календарным планом работ Государственного

контракта.

Общая продолжительность работ – не более 510 дней.

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

учета медицинской помощи (далее – СПУ) Единой медицинской информационно-

аналитической системы города Москвы (далее – ЕМИАС) определена в разделе 5.1

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

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

Техническому заданию определяются Календарным планом работ Государственного

контракта.

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

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

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





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

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

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

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

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

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

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

Системы

Требования к составу и оформлению результатов работ определены разделами 5 «Состав и

содержание работ по созданию (развитию) системы» и 8 «Требования к документированию»

настоящего Технического задания (далее – ТЗ).

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

Государственным контрактом в соответствии с Календарным планом работ Государственного

контракта на основании Актов приема-передачи научно-технической продукции (НТП).

Всѐ разработанное программное обеспечение Системы должно передаваться

Государственному Заказчику вместе с исходными кодами.

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

«Ведомость машинных носителей информации».

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

носителях (CD|DVD). Текстовые документы, передаваемые на машинных носителях, должны быть

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

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





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

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

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

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

персонифицированного учѐта оказанной медицинской помощи.

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

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

Информационной Системы (далее – РЕИС), которая создаѐтся в соответствии с положениями

раздела IV Приложения 3 (Подпрограмма «Внедрение современных информационных систем в

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

утвержденной постановлением Правительства Москвы от 7 апреля 2011 № 114-ПП «О Программе

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

Правительства Москвы от 27 октября 2011 № 513-ПП). РЕИС представляет собой

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

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

государственной информационной системы в здравоохранении (далее – ЕГИСЗ), так и с

общегородской информационной инфраструктурой города Москвы. Региональный фрагмент

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

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

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

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

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

Исходные данные для формирования комплексного многомерного информационного

массива персонифицированного учета будут предоставляться:

– в отношении амбулаторно-поликлинической помощи – из Общегородского

информационного сервиса Управления потоками пациентов ЕМИАС – по факту

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

– в отношении стационарной медицинской помощи – из локальных медицинских

информационных систем медицинских учреждений стационарного типа.





Основным потребителем консолидированной в СПУ ЕМИАС информации будет

выступать:

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

– Московский городской фонд ОМС;

– медицинские организации системы здравоохранения города Москвы;

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

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

помощью в городские медицинские организации, работающие в системе ОМС и

подключенные к ЕМИАС.

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

Система персонифицированного учета медицинской помощи в составе ЕМИАС города

Москвы должна обеспечить достижение следующих целей:

– повышение эффективности управления системой здравоохранения города Москвы:

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

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

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

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

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

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

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

медицинской помощи в различных разрезах;

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

в рамках территориальной программы ОМС;

– повышение эффективности доступности и качества медицинской помощи,

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

– повышение эффективности выявления заболеваний на раннем этапе.





Показатели объекта автоматизации и критерии оценки достижения целей представлены в

таблице 1.

Таблица 1 – Цели Системы и критерии оценки достижения целей

Цели Индикаторы эффективности

Системы

Показатель. Критерии оценки

достижения целей

Повышение

эффективности

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

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


Количество пациентов Увеличение количества пациентов

Количество пациентов,

записанных на приѐм и

пришедших на приѐм

Соотношение количества пациентов,

записанных на приѐм и пришедших

на приѐм, должно приближаться к

единице

Количество условных единиц

трудозатрат (далее – УЕТ)

Увеличение количества УЕТ

Среднее количество УЕТ на

медицинского специалиста

каждой специальности

Увеличение количества УЕТ на

медицинского специалиста каждой

специальности


пациента


пациента не должно снижаться

Страховая стоимость Увеличение страховой стоимости в

приведѐнных ценах

Повышение


контроля

рационального

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

выделяемых на

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

системы

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


Страховая стоимость

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

помощи при проведении медико-

экономического контроля и

экспертизы

Уменьшение страховой стоимости

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

при проведении медико-

экономического контроля и

экспертизы

Средняя стоимость лечения

одного пациента по нозологиям

Уменьшение средней стоимости

лечения одного пациента по

нозологиям






Системы



Надлежащий контроль

за исполнением

стандартов оказания

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

разработку и

имплементацию

интегральных

индикаторов качества и

доступности

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

различных разрезах

Количество пациентов, повторно

обратившихся за медицинской

помощью по поводу одного

заболевания

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

повторно обратившихся за

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

одного заболевания

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

жизни в городе Москве

Увеличение средней

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

городе Москве

Уровень смертности в


Снижение уровня смертности в


Уровень первичной

инвалидности в городе Москве

Снижение уровня первичной

инвалидности в городе Москве

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

затраченного на

расчеты за оказанную

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

в рамках

территориальной

программы ОМС

Время подготовки

регламентированных отчетов

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

регламентированных отчетов на 15%

Повышение


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

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

оказываемой в рамках

программ

обязательного

медицинского

страхования

Количество пациентов Увеличение количества пациентов


пациента

Увеличение количества УЕТ на

пациента

Количество пациентов, для

которых не выполнены

стандарты оказания

амбулаторно-поликлинической

помощи

Сокращение количества пациентов,

для которых не выполнены

стандарты оказания амбулаторно-

поликлинической помощи

Удовлетворенность пациента Сокращение количества жалоб






Системы



пациентов

Пользовательская

удовлетворенность отдельными

сервисами Системы

Повышение


выявления заболеваний

на раннем этапе

Количество пациентов,

прошедших дополнительную

диспансеризацию

Увеличение количества пациентов,

прошедших дополнительную

диспансеризацию





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

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

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

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

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

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

страхования).

В таблице 2 представлены ориентировочные данные о количественном составе

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

Таблица 2 – Типы медицинских организаций

№ Тип медицинской организации Количество,

(шт.)

1. Женские консультации 19

2. Медико-санитарные части 22

3. Поликлиники восстановительного лечения 6

4. Поликлиники городские 223

5. Поликлиники детские городские 151

6. Поликлиники стоматологические 63

7. Центры восстановительного лечения для детей 8

8. Центры медицинские 22

Существующая организационная структура системы здравоохранения города Москвы

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

предпосылки для централизации хранения и обработки данных. Подразделения системы

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

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

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

обработки и хранения данных. Особенностями бизнес-процессов, производственных и

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

Москвы является то, что:





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

несколько подразделений;

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

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

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

эффективность их решения.

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

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

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

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

в настоящий момент являются:

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

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

исполнителями на бумажных носителях;

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

недостаточная стандартизация (ввиду отсутствия утвержденных классификаторов) и

оперативность подготовки данных.

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

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

Условия эксплуатации Системы - внутри помещений, пригодных для постоянного наличия

людей: температура 18-24 градуса С, влажность 60-80%. При эксплуатации должны учитываться

положения СНиП 23-01-99 «Строительная климатология».





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

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

На рисунке 1 представлена концептуальная архитектура Системы персонифицированного

учѐта медицинской помощи ЕМИАС.

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

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

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

СИ

СТЕ

МА

КО

НС

ОЛ

ИД

ИР

ОВ

АН

НО

ГО

УП

РА

ВЛ

ЕНЧ

ЕСК

ОГО

УЧ

ЕТА

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

СИ

СТЕ

МА

ИН

ТЕГР

ИР

ОВ

АН

НО

Й

МЕД

ИЦ

ИН

СК

ОЙ

ИН

ФО

РМ

АЦ

ИИ

СИ

СТЕ

МА

УП

РА

ВЛ

ЕНИ

Я П

ОТО

КА

МИ

П

АЦ

ИЕН

ТОВ

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

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

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

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

СИ

СТЕ

МА

УП

РА

ВЛ

ЕНИ

Я М

ЕДИ

ЦИ

НС

КИ

МИ

Р

ЕГИ

СТР

АМ

И

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

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

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

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

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

УЧРЕЖДЕНИЕ

ЕДИНЫЙРЕГИСТР

ПАЦИЕНТОВ ЕМИАС

РЕГИСТР МЕДИЦИНСКИХ СПЕЦИАЛИСТОВ

ЕМИАС

Обеспечение работы с НСИ АИС ОМС

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

Контроль учетных данных

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

Импорт результатов внешнего контроля

Мониторинг руководством МО

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

Администрирование

Информационная безопасность

Рисунок 1 – Концептуальная архитектура СПУ ЕМИАС





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

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

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

таблице 3.

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

№ Название

подсистемы

Назначение


Основные

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

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

нормативно-

справочной

информацией (далее –

НСИ)

Автоматизированной

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

системы ОМС (далее -

АИС ОМС)

Поддержка процесса

загрузки и использования

актуальной нормативно-

справочной информации

Проверка актуального пакета НСИ

АИС ОМС из Московского

городского фонда ОМС (далее –

МГФОМС), загрузка в хранилище

Системы, обеспечение сохранности

всех версий предыдущих пакетов

для использования в

соответствующем отчѐтном

периоде

2. Учет медицинской

помощи

Ввод персональных данных

пациентов и сведений об

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

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

ОМС в МО амбулаторно-

поликлинического типа

Ввод персональных данных

пациентов по категориям и

сведений об оказанной

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

системы ОМС в МО амбулаторно-

поликлинического типа с

первичным контролем информации

при вводе. Минимизация

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

пользователем









Основные


3. Контроль учетных

данных

Автоматический контроль

персональных данных

пациентов и сведений об

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

помощи

Проверка персональных данных

пациентов и сведений об оказанной

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

отчѐтного периода в соответствии с

Регламентом, разработанным

МГФОМС, без взаимодействия с

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

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

отчетов

Формирование, просмотр на

экране монитора и, при

необходимости, печать на

принтере

регламентированных

отчѐтных форм ОМС

Выбор требуемых отчѐтов,

формирование и отображение на

экране монитора. Выбор из списка

и печать сформированных отчѐтов

на принтере

5. Импорт результатов

внешнего контроля

Обеспечение контроля

результатов экспертиз,

проведѐнных в СМО /

МГФОМС, загрузки

результатов в хранилище

Системы, формирование

отчѐтности по загрузке

Получение от Центрального

аппаратного комплекса АИС ОМС

результатов контроля. Проверка

результатов внешнего контроля,

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

Формирование отчѐтности

6. Мониторинг

руководством МО

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

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

деятельности МО

руководству МО по

различным критериям, с

различными фильтрами,

результатов контроля сроков

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

специалистов

Настройка рабочего места

руководства МО. Выбор различных

критериев и фильтров для

отображения информации.

Формирование требуемых форм

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

на принтере. Отображение

результатов контроля сроков

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










Основные


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


Обеспечение

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


(интеграционная шина)

Подготовка и передача информации

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

пациентов (далее – СУПП) ЕМИАС

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

произвольный период времени

после аутентификации пациента в

инфокиоске. Обеспечение доступа к

общегородскому регистру

пациентов. Обеспечение доступа к

Центральному аппаратно-

программному комплексу (далее –

ЦАПК) АИС ОМС. Обеспечение

взаимодействия с СУПП, Системой

интегрированной медицинской

информации (далее – СИМИ),

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

медицинскими регистрами (далее –

СУМР) и Системой

консолидированного

управленческого учета (далее –

СКУУ) ЕМИАС, Единым регистром

пациентов ЕМИАС

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

в различных режимах

работы

Разграничение прав доступа,

управление организационной

структурой. Первоначальные

настройки для конкретной МО









Основные


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

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

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

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

пользователей, смежных

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

защиты информации от

несанкционированного

доступа

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

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

смежных систем. Управление

доступом к защищаемой

информации. Регистрация и учѐт

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

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

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

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

использованием совместного доступа к базам данных подсистем СПУ ЕМИАС и вызовов

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

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

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

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

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

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

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

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

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

сервисов.

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

постановлением правительства города Москвы №513 и с общей архитектурой ЕМИАС, СПУ

ЕМИАС должна быть связана со следующими смежными системами:

Система консолидированного управленческого учета Единой медицинской

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

информации СПУ ЕМИАС;

Центральный аппаратный комплекс АИС ОМС (владелец ресурса – МГФОМС) -

основной потребитель консолидированной информации СПУ ЕМИАС, поставщик НСИ

АИС ОМС и результатов внешнего контроля;





общегородской регистр пациентов (владелец ресурса – МГФОМС) – поставщик

персональных данных застрахованных в системе ОМС лиц;

Система управления потоками пациентов Единой медицинской информационно-

аналитической системы (до сдачи государственного контракта эксплуатацию системы

осуществляет разработчик системы ГК «Ланит» в соответствии с ГК ______) –

поставщик информации в части данных реестра медицинских специалистов и

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

помощи;

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

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

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

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

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

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

В соответствии с архитектурой ЕМИАС для обеспечения всех взаимодействий на

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

реализованная на продукте Oracle ESB.

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

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

ЕМИАС и ЕМИАС:

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

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

o DNS;

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

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

НСИ ЕМИАС;

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

Характеристики взаимосвязей Системы со смежными системами через ESB ЕМИАС, а так

же дополнительные требования, предъявляемые к смежным системам, должны быть определены в

частных технических заданиях (далее – ЧТЗ) на сопряжение смежных систем с СПУ ЕМИАС; в

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

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

Единый регистр пациентов ЕМИАС;

Единый регистр застрахованных лиц МГФОМС;





Единый реестр медицинских специалистов ЕМИАС;

НСИ ЕМИАС;

СУПП ЕМИАС;

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

Взаимодействие СПУ ЕМИАС со смежными системами должно строиться на основе web-

сервисов. При разработке web-сервисов и выполнении работ по обеспечению информационного

взаимодействия необходимо руководствоваться Техническими требованиями к взаимодействию

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

(Приказ Министерства связи и массовых коммуникаций Российской Федерации от 27 декабря

2010 года № 190 «Oб утверждении Технических требований к взаимодействию информационных

систем в единой системе межведомственного электронного взаимодействия»).

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

системой (далее – ИС) должны быть разработаны методы и алгоритмы взаимодействия систем,

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

данных, как со стороны Системы, так и со стороны смежной ИС. При этом должна сохраняться

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

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

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

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

нештатных ситуаций.

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

полнофункциональный;

с ограниченной функциональностью;

тестовый;

диагностический;

аварийный.

В полнофункциональном режиме работы Система должна обеспечивать выполнение всех

функций в полном объеме.

Система должна функционировать в режиме с ограниченной функциональностью в случае

отсутствия связи со смежными системами.





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

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

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

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

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

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

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

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

Системы о еѐ переходе в аварийный режим. Смежные системы при попытке обращения к Системе

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

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

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

разрабатываемых с учѐтом результатов научно-исследовательской работы (далее – НИР) на стадии

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

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

Диагностика доступности и работоспособности СПУ ЕМИАС должна быть реализована

через автономную подсистему диагностики, размещаемую в инфраструктуре РЕИС (смежную по

отношению к СПУ ЕМИАС систему).

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

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

в комплекс технических средств Системы.

Для диагностики состояния Системы и выявления возможных сбоев в ходе еѐ эксплуатации

в СПУ ЕМИАС должна быть реализована журнализация системных событий. Уровень

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

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

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

вручную.

Уровни детализации записей журнала системных событий должны быть специфицированы

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

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

списке:

недоступность смежных систем;

ошибки, выдаваемые пользователям;





протоколы обмена данными между потребителями СПУ ЕМИАС.

Записи в системном журнале событий должны содержать следующие данные:

пользователь СПУ ЕМИАС или смежной системы, от имени которого инициировано

системное событие;

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

дата и время события;

тип события;

описание события (степень детализации описания определяется параметрами режима

функционирования);

результат завершения (степень детализации описания результата определяется

параметрами режима функционирования).

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

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

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

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

диагностики применяемого программного обеспечения (далее – ПО) (Системы управления базами

данных (далее – СУБД), серверы приложений), в том числе журнализация событий.

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

ситуаций должна использоваться функциональность:

смежной диагностической системы;

БМИ ЕМИАС (электронная почта).

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

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

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

системы не должна изменяться.

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

направлениях:

расширение прикладных функций;

интеграция Системы с другими информационными системами и ресурсами;

расширение типов охваченных Системой организаций здравоохранения города Москвы

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





увеличение ресурсов программно-аппаратного комплекса в соответствии с ростом

потоков информации в Системе.

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

и медикостатистической информации, которая хранится в Системе в структурированном виде.

Расширение функциональности Системы возможно в процессе разработки сервисов,

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

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

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

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

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

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

взаимодействие пользователей-операторов (персонала амбулаторно-поликлинических и лечебно-

профилактических МО) с функционалом Системы – эта группа пользователей будет работать с

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

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

Минздравсоцразвития РФ от 23 июля 2010 г. № 541н «Об утверждении Единого

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

«Квалификационные характеристики должностей работников в сфере здравоохранения»;

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

Персонал Системы обеспечивает выполнение административных действий в Системе,

обновление и настройку справочников.

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

выполнена на стадии разработки технического проекта Системы. В число ролей пользователей

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

администратор Системы;

инженер;

оператор;

главный врач.

Состав персонала, работающего с Системой через еѐ пользовательский интерфейс,

представлен в таблице 4.





Таблица 4 – Подсистемы и их пользователи

№ Наименование подсистемы Пользователи подсистемы

1. Обеспечение работы с НСИ АИС ОМС Инженер

2. Учет медицинской помощи Оператор

3. Контроль учетных данных Оператор, Инженер

4. Формирование отчетов Инженер

5. Импорт результатов внешнего

контроля

Инженер

6. Мониторинг руководством МО Главный врач

7. Взаимодействие со смежными

системами

Оператор, Инженер

8. Администрирование Администратор

9. Информационная безопасность Инженер

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

Таблица 5 – Требования к пользователям Системы

Наименование

пользователя Количество Квалификация Режим работы

Оператор Не более 10 в

МО

Пользователь

средней

квалификации

8.00 – 17.00

5-и дневная рабочая

неделя

Инженер 1 Пользователь

средней


8.00 – 21.00


неделя

Главный врач 1 Пользователь низкой


8.00 – 17.00


неделя





Наименование

пользователя Количество Квалификация Режим работы

Администратор 2 Квалифицированный

специалист

8.00 – 21.00


неделя

При внедрении Системы состав пользователей подсистем, их роли и режим работы должны

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

«Регламент эксплуатации системы», входящем в состав эксплуатационной документации на

Систему.

В таблице 6 представлены уровни классификации, которым должны соответствовать

пользователи Системы.

Таблица 6 – Уровни квалификации пользователей

Уровень квалификации Требования

Пользователь низкой квалификации Умение включать персональный компьютер на базе

операционных систем: Windows 7 и AltLinux 6.0 и

аутентификации

Пользователь средней квалификации Опыт работы с персональным компьютером на базе

операционных систем: Windows 7 и AltLinux 6.0

Квалифицированный специалист Высшее техническое образование, стаж работы не менее

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

знание администрирования промышленной СУБД,

наличие сертификата администратора используемой

СУБД

Эксплуатация Системы должна проводиться обученным персоналом. Обучение персонала

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

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

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

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

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

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

баз данных и операционных систем.





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

4.1.3.1. Целевые показатели объема обрабатываемой информации

СПУ ЕМИАС должна быть создана с учетом обеспечения штатного функционирования при

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

суммарное количество информации о пациентах и оказанной медицинской помощи – до

2000 талонов амбулаторного пациента в сутки для одной МО;

суммарное количество пользователей в МО амбулаторно-поликлинического типа,

работающих в Системе – до 2000 чел. (6 человек х 350 МО);

срок хранения данных – до 10 лет.

4.1.3.2. Вероятностно-временные характеристики, при которых

сохраняется целевое назначение Системы

При проектировании Системы должны быть предусмотрены возможности для расширения

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

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

В штатном режиме функционирования Система должна обеспечивать время отклика в

соответствии с требованиями, указанными в таблице 7:

Таблица 7 – Время отклика Системы при функционировании в штатном режиме

Показатель

Средняя

величина

(не более)

Максимальная

величина

(не более)

Время отклика да загрузки данных

экранных форм в СУБД

1 секунда 2 секунды

Время отклика для сервисов загрузки,

поиска и извлечения данных из СУБД СПУ

ЕМИАС

2 секунды 5 секунд

Время отклика для остальных сервисов

СПУ ЕМИАС

3 секунды 7 секунд





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

не более, чем в 2 раза.

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

системы. Срок эксплуатации Системы определяется сроком устойчивой работы аппаратных

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

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

При условии постоянного выполнения этих работ целевое назначение Системы должно

сохраняться неограниченно долго.

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

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

Обеспечение возможности восстановления работоспособности Системы без критической

потери данных при возникновении аварийных ситуаций возлагается на БМИ ЕМИАС, а именно,

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

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

данных, которые были записаны в базу данных Системы в результате корректно завершѐнной

транзакции.

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

В Системе должны быть предусмотрены:

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

форматов/значений входных данных при работе с пользовательским интерфейсом

Системы в ЕМИАС;

средства информирования пользователя об ошибочных или противоречивых входных

данных при работе с пользовательским интерфейсом Системы;

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

интерфейсом Системы;

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

хранилище СПУ ЕМИАС.

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

пользователя, или недопустимым форматом/значением входных данных при работе с

пользовательским интерфейсом, Система должна:





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

исключительной ситуации;

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

При невозможности по тем или иным причинам завершить пользовательскую транзакцию

Система должна обеспечить целостность и непротиворечивость данных, и выдать аварийное

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

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

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

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

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

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

носителей информации с исполняемым программным кодом).

Импульсные помехи, сбои или прекращение электропитания не должны приводить к

выходу из строя технических средств и/или нарушению целостности или потере данных.

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

развѐрнуты таким образом, чтобы обеспечивать устойчивую работу Системы при возникновении

сбоев, вызванных следующими причинами:

задержки в каналах связи;

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

аппаратные сбои оборудования;

программные сбои различных компонентов Системы.

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

вертикальное и горизонтальное масштабирование с возможностью статической и динамической

балансировки нагрузки.

Обновление информационной системы или компонента в еѐ составе должно происходить в

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

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

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

сервиса; переключение пользователей на новую версию должно происходить без остановки

системы).

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

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





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

резервированием;

формированием требований к дублированию носителей информации.

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

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

программно-аппаратного комплекса ЕМИАС.

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

Требования безопасности не предъявляются.

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

Должны быть разработаны детальные требования к пользовательским интерфейсам и

прототипы пользовательских интерфейсов для ЕМИАС, удовлетворяющие следующим

требованиям:

все экранные формы пользовательских интерфейсов должны быть выполнены

преимущественно в едином графическом дизайне ЕМИАС, с одинаковым

расположением основных элементов управления и навигации;

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

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

унифицированы;

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

и/или редактировании текстовых и числовых полей экранных форм. В интерфейсах

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

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

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

все надписи экранных форм, а также сообщения, выдаваемые пользователю (кроме

системных сообщений), должны быть на русском языке;

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

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

экранные формы должны отражать всю информацию и элементы оформления при

разрешении экрана 1600х900 с использованием стандартного шрифта.

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

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

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





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

введѐнного набора данных.

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

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

пользователей и объемов вводимых данных.

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

Требования к транспортабельности Системы не предъявляются.

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

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

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

Эксплуатация Системы должна производиться в соответствие с эксплуатационной

документацией Системы (см. раздел 5.4.2 «Разработка эксплуатационной документации») и

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

которого развернуто системное и прикладное программное обеспечение Системы. При нарушении

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

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

При эксплуатации СПУ ЕМИАС возможно возникновение технических сбоев работы

системы ЕМИАС, которые могут выражаться в комбинации следующих условий:

полный или частичный отказ аппаратных компонент ЕМИАС;

полный или частичный отказ инфраструктурного и /или системного программного

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

полный или частичный отказ прикладного программного обеспечения СПУ ЕМИАС;

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

Центром обработки данных (далее – ЦОД).

4.1.8.1.1. Классификация отказов СПУ ЕМИАС.

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

технических сбоев.

Под отказом 0-го уровня принимается отказ СПУ ЕМИАС в нескольких МО. При таком

виде отказа нарушаются основные функции СПУ ЕМИАС и прекращается предоставление сервиса

в рамках СПУ ЕМИАС в нескольких МО. Такому виду отказа присваивается наивысший

приоритет.





Под отказом 1-го уровня принимается отказ СПУ ЕМИАС в пределах одной МО. При

таком виде отказа нарушаются основные функции СПУ ЕМИАС и прекращается предоставление

сервиса в рамках СПУ ЕМИАС в одном ГУЗ. Виду отказа присваивается высокий приоритет.

Под отказом 2-го уровня принимается отказ СПУ ЕМИАС в нескольких МО. При таком

виде отказа нарушается предоставление части функций сервиса в рамках СПУ ЕМИАС (в

пределах одной или нескольких МО) и остается частичная (базовая) работоспособность сервиса.

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

В любых других случаях (в пределах одной МО), когда работоспособность сохранена в

частичном объеме, но достаточным для обеспечения сервиса СПУ ЕМИАС, виду отказа приоритет

не присваивается.

4.1.8.1.2. Требования к срокам устранения отказов.

При обработке отказов требуется соблюдать временные параметры времени реакции и

времени решения заявки.

Под временем реакции следует понимать промежуток времени от момента обнаружения

неработоспособности компонентов СПУ ЕМИАС до внесения заявки в службу регистрации

заявок.

Под временем решения следует понимать промежуток времени от регистрации заявки в

службе регистрации до фактического устранения технических проблем.

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

характеристики времени реакции и времени решения, приведѐнные в таблице 8.

Таблица 8 – Временные характеристики

Отказ

Время реакции Время решения

Поступление

заявки в

рабочее время


заявки в

нерабочее

время


заявки в

рабочее время


заявки в

нерабочее

время

Отказ 0-го уровня 10 мин 10 мин 1 час 4 часа

Отказ 1-го уровня 10 мин 10 мин 4 часа 8 часов

Отказ 2-го уровня 30 мин 30 мин 24 часов 36 часа

Прочие отказы 1 час 1 час 24 часов 36 часа





4.1.8.2. Требования к техническому обслуживанию Системы

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

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

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

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

вычислительным машинам и организации работы (СанПиН 2.2.2/2.4.1340-03 от 30 мая 2003 г.,

утверждены Главным государственным санитарным врачом Российской Федерации).

Уровень квалификации обслуживающего персонала должен соответствовать требованиям

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

эксплуатационной документации.

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

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

при разработке Системы и включѐн в состав эксплуатационной документации Системы.

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

доступа

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

разными правами доступа. С учетом особенностей обрабатываемой информации, СПУ ЕМИАС

должна соответствовать требованиям, предъявляемым действующим в Российской Федерации

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

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

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

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

данным как через сервисы СПУ ЕМИАС, так и через интерфейсы баз данных.

Размещение разрабатываемых компонентов СПУ ЕМИАС осуществляется в пределах

защищенного окружения РЕИС, формируемого системами инфраструктурного уровня БМИ

ЕМИАС. Создание систем инфраструктурного уровня, формирующих защищенное окружение

ЕМИАС, не входит в рамки работ, определяемых настоящим Техническим заданием.

Защищенное окружение призвано реализовать всю базовую функциональность СПУ

ЕМИАС по защите информации, включая:





безопасность межсетевого взаимодействия;

обнаружение и предотвращение вторжений;

контроль защищенности;

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

информации;

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

общегородским центром обработки данных.

Вместе с тем, при проектировании аппаратно-программного комплекса, обеспечивающего

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

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

окружения в части, необходимой для обеспечения соответствия СПУ ЕМИАС требованиям

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

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

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

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

безопасностью при эксплуатации Системы. Документ «Политика обеспечения информационной

безопасности» должен войти в состав эксплуатационной документации Системы.

При проведении работ по обеспечению информационной безопасности должны

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

2).

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

Для пользователей из числа административного персонала Системы:

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

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

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

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

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

o дата и время входа / выхода пользователя в систему;

o результат попытки входа (успешная или неуспешная);

o идентификатор пользователя;

o адрес исходящего запроса;





o действия администраторов без возможности изменения записей в журналах,

включая удаление.

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

К авариям относятся:

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

Системы;

сбои электропитания;

сбой системного программного обеспечения (см. Таблица 10);

сбой прикладного программного обеспечения (см. Таблица 10);

сбой из-за ошибок в работе персонала.

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

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

БМИ ЕМИАС, и штатными средствами используемых СУБД.

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

Средства защиты от внешних воздействий не предъявляются.

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

Используемое программное обеспечение должны иметь патентную чистоту и при

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

Российской Федерации.

Кроме этого, исключительное авторское право на созданное ПО по государственному или

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

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

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

предусмотрено, что это право принадлежит Российской Федерации, субъекту Российской

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

муниципальный Заказчик; либо совместно Исполнителю и Российской Федерации, Исполнителю

и субъекту Российской Федерации или Исполнителю и муниципальному образованию.

Имущественные права принадлежат Заказчику.





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

Проводимые работы должны соответствовать следующим требованиям:

применяемые при создании Системы технические (форматы данных, протоколы

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

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

независимой реализации третьими сторонами. Применение недокументированных или

недоступных решений не допускается;

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

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

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

признанным международным, федеральным, отраслевым, промышленным органом по

стандартизации;

экранные формы пользовательских интерфейсов должны быть спроектированы с

учѐтом требований унификации, представленных в разделе 4.1.6 «Требования к

эргономике и технической эстетике»;

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

взаимодействия через ESB ЕМИАС;

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

существующие утверждѐнные / рекомендованные к использованию стандартами и

федеральными или ведомственными / отраслевыми нормативными актами

классификаторы и словари.

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

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

ориентированы на OpenDocument Format либо html формат.

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

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

представлены в таблице 9.





Таблица 9 – Функциональные требования к Системе

№ Роль пользователя Функция

ПОДСИСТЕМА: ОБЕСПЕЧЕНИЕ РАБОТЫ С НСИ АИС ОМС

1. Инженер Контроль актуального пакета НСИ, в частности, правильность

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

классификаторов, входящих в состав пакета

Формирование сообщения в ЦАПК АИС ОМС при

обнаружении ошибок в пакете

Загрузка актуального пакета НСИ из смежной системы

(ЦАПК АИС ОМС) в хранилище Системы. Список НСИ

представлен в Приложение 1

Формирование отчета о загрузке пакета НСИ

ПОДСИСТЕМА: УЧЕТ МЕДИЦИНСКОЙ ПОМОЩИ

2. Оператор Поиск пациента по документу ОМС или фамилии, имени

отчеству

При отсутствии пациента добавление его персональных

данных в реестр пролеченных в соответствии с категорией

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

данных пациента

Отбор информации о медицинской помощи по выбранному

пациенту за требуемый период, по умолчанию, требуемый

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

Ввод новой информации об оказанной медицинской помощи.

Контроль информации при вводе данных об оказанной

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

Коррекция информации об оказанной медицинской помощи.

Контроль информации при коррекции данных об оказанной

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






Удаление информации об оказанной медицинской помощи (с

подтверждением)

Формирование и отображение статистического отчѐта о

введѐнной информации за выбранный период работы, по

умолчанию, текущий день

ПОДСИСТЕМА: КОНТРОЛЬ УЧЕТНЫХ ДАННЫХ

3. Оператор Идентификация пациентов по регионального сегмента (далее

– РС) Единого регистра застрахованных лиц (далее – ЕРЗЛ) с

помощью запроса и обработки ответа. Запрос формируется

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

4. Инженер Контроль персональных данных пациентов, пролеченных в

выбранном отчѐтном периоде (в соответствии с категорией

пациента)

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

выбранном отчѐтном периоде

Исправление ошибок по результатам контроля в реестре

пациентов и реестре счетов с помощью разработанного

интерфейса

ПОДСИСТЕМА: ФОРМИРОВАНИЕ ОТЧЕТОВ

5. Инженер Формирование отчѐтов в электронном виде по категориям

пациентов и отчѐтному периоду. Должна быть предоставлена

возможность изменения состава отчѐтов, по умолчанию

указывается состав отчѐтов, сформированных в предыдущий

сеанс работы

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

пациентов и отчѐтному периоду

Экспорт счетов в СМО / МГФОМС по категориям пациентов






и отчѐтному периоду

Формирование отчѐтов Форма ОМС-2 «Счѐт-фактура за

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

в городе Москве, по Московской городской программе ОМС»

Формирование отчѐта Форма ОМС-2 «Счѐт-фактура за

медицинскую помощь, оказанную иногородним пациентам по

Московской городской программе ОМС»

Формирование отчѐтов СПРАВКА 1 к счѐту-фактуре о

пациентах, получивших медицинскую помощь по Московской

городской программе ОМС

Формирование отчѐтов Форма ОМС-3 «Справка по оказанным

медицинским услугам в системе ОМС» по отделениям


медицинским услугам в системе ОМС» по специалистам


медицинским услугам в системе ОМС» по пациентам

Просмотр списка ранее сформированных отчѐтов с

возможностью фильтрации

ПОДСИСТЕМА: ИМПОРТ РЕЗУЛЬТАТОВ ВНЕШНЕГО КОНТРОЛЯ

6. Инженер Контроль представленных результатов внешнего контроля

Формирование сообщения в ЦАПК АИС ОМС при

обнаружении ошибок в представленных результатах

Загрузка результатов контроля и экспертиз счетов в

соответствии с категорией пациентов и отчѐтного периода

Формирование отчѐта о произведѐнной браковке






ПОДСИСТЕМА: МОНИТОРИНГ РУКОВОДСТВОМ МО

7. Главный врач Настройка интерфейса мониторинга руководством МО по

составу информации

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

за произвольный период с возможностью фильтрации

Контроль окончания сроков сертификатов медицинских


Формирование отчѐтов по выбранному периоду

ПОДСИСТЕМА: ВЗАИМОДЕЙСТВИЕ СО СМЕЖНЫМИ СИСТЕМАМИ

8. Оператор Обеспечение доступа к РС ЕРЗЛ

Формирование запроса и обработка ответа к Общегородскому

регистру пациентов (РС ЕРЗЛ)

Формирование данных для Единого регистра пациентов

ЕМИАС

9. Инженер Обмен информацией с ЦАПК АИС ОМС

Обмен информацией с СУПП ЕМИАС

Обмен информацией с СУМР ЕМИАС

10. По запросу от СУПП ЕМИАС подготовка и передача

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

По запросу от СИМИ ЕМИАС подготовка и передача

информации об оказанной медицинской помощи

По запросу от СКУУ ЕМИАС подготовка и передача

консолидированной информации об оказанной медицинской

помощи

ПОДСИСТЕМА: АДМИНИСТРИРОВАНИЕ






11. Администратор Ведение списка пользователей системы

Ведение списка ролей пользователей системы

Ведение профилей безопасности пользователей системы

Ведение журнала сообщений об ошибках, выдаваемых

пользователям

12. Инженер Определение начальных настроек конкретной МО

ПОДСИСТЕМА: ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ

13. Инженер Регистрация входа/выхода пользователей в/из Систему/ы

Разграничение доступа к различным функциям

Защита персональных данных и прочей информации

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

информации

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

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

отдельном документе «Перечень выходных сигналов (документов)».

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

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

информации

Входная информация Системы должна быть специфицирована в документе «Перечень

входных сигналов и данных» при разработке технического проекта с учѐтом результатов НИР.

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

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

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

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





связанные с экранными формами должны быть отображены в отдельном документе «Чертеж

формы документа (видеокадра)». Данный документ должен быть согласован и утвержден

заказчиком.

Экранные формы должны проектироваться с учетом требований пункта 4.1.6 «Требования

к эргономике и технической эстетике».

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

манипулятора «мышь».

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

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

Контроль актуального пакета НСИ должен осуществляться в соответствии с «Протоколом

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

сети», утверждѐнным МГФОМС в 2011 году.

Контроль учѐтных данных (персональные данные пациентов и оказанная им медицинская

помощь) должен осуществляться в соответствии с «Временным регламентом организации и

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

по обязательному медицинскому страхованию в городе Москве», утверждѐнным МГФОМС.

Формирование отчѐтов должно осуществляться в соответствии с «Правилами файлового

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

ОМС», утверждѐнного МГФОМС 01.12.2011 г.

Контроль представленных результатов внешнего контроля должен осуществляться в

соответствии с «Порядком информационного взаимодействия между участниками обязательного

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

медицинского страхования города Москвы», утверждѐнным приказом МГФОМС от 01.12.2011 г.

№ 192.

Обеспечение доступа к региональному сегменту ЕРЗЛ должно осуществляться в

соответствии с «Протоколом информационного обмена с региональным и центральным

сегментами ЕРЗЛ», утверждѐнным МГФОМС в 2011 году.

Обеспечение работы с ЦАПК АИС ОМС должно осуществляться в соответствии с

«Интерфейсом универсального почтового шлюза OMSGW», утверждѐнным МГФОМС в 2011

году.





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

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

в Системе

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

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

База данных должна соответствовать требованиям нормализации не ниже 2 нормальной

формы.

Связи между таблицами БД должны обеспечивать заданную ссылочную целостность.

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

Системы

Обмен информацией между подсистемами должен осуществляется путѐм совместного

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

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

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

процессами одновременно.

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

системами

Информационная совместимость со смежными системами, в том числе системами ЕМИАС,

должна обеспечиваться:

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

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

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

использованием единой для ЕМИАС НСИ, Общегородского Регистра Пациентов,

Регистра Медицинских работников, Регистра ЛПУ, единого каталога пользователей

БМИ ЕМИАС.

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

форматов в ходе эксплуатации Системы.





4.3.2.4. Требования по использованию общесоюзных и

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

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

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

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

справочники информации, действующие на Объекте автоматизации (см. Приложение 1).

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

Для хранения данных Системы должна использоваться промышленная система управления

базами данных. При дальнейшем развитии Системы возможен переход на промышленную СУБД

более высокого уровня.

Проектирование структуры БД должно производиться с использованием инструментальных

средств.

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

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

Регламент процесса сбора и обработки данных должен быть разработан на стадии

разработки технического проекта и согласован с Заказчиком и Департаментом здравоохранения

города Москвы перед проведением опытной эксплуатации СПУ ЕМИАС.

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

в электропитании Системы

Мероприятия по обеспечению сохранности данных должны включать:

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

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

резервное архивирование данных средствами промышленной СУБД.

Мероприятия по обеспечению сохранности данных при авариях и сбоях в электропитании

обеспечиваются в рамках БМИ ЕМИАС.





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

восстановлению данных

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

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

необходимых ограничений на таблицы баз данных.

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

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

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

должны применяться также средства СУБД.

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;






Linux® on POWER;

Linux® on x86;Solaris® on SPARC.

Сервер приложений должен обеспечивать совместимость с

СУБД, выбранной для использования при реализации Системы

3. Система управления

базой данных

СУБД должна обеспечивать:

поддержку реляционной модели данных;

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

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

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

сбоях;

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

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

прогнозирования ошибок;

возможность организации кластера СУБД;

поддержку кроссплатформенности;

возможность сжатия данных на уровне СУБД, включая

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

как документы, изображения и мультимедиа, а также

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

копирования;

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

предотвращая «прослушивание» и разнообразные виды

атак;

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

встроенные непосредственно в ядро СУБД;

возможность разбиения таблицы и индексов на более

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

управления, производительности и доступности;

возможность масштабирования, обеспечивающую быстрый

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






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

памяти нескольких серверов;

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

в формате xml;Возможность обеспечивать непрерывный

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

случае сбоев.

Сервер должен поддерживать кроссплатформенность, т.е. как

минимум, следующие операционные системы и платформы:

AIX®;

HP-UX® on PA-RISC;

Linux® on x86;

Linux® on POWER

Solaris® on SPARC

4. HTTP-сервер HTTP-сервер должен обеспечивать:

возможность установления защищенного соединения с

клиентским ПО;

WSDL/SOAP;

возможность кэширования статического контента и

документов;

возможность балансировки внешних запросов;

возможность сжатия ответов сервера методом Gzip.

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

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

существующем оборудовании ЦОД ЕМИАС, в состав которого входят:

группа фронтальных серверов;

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

группа серверов сервисной шины;

группа серверов БД;

система хранения данных;

инфраструктура информационной безопасности.





Требования к параметрам программно-аппаратного комплекса, на ресурсах которого

развѐртывается СПУ ЕМИАС, должны быть уточнены при разработке технического проекта СПУ

ЕМИАС с учѐтом результатов НИР и включены в документы «Описание архитектуры Системы» и

«Описание комплекса технических средств».

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

модернизации здравоохранения города Москвы, создаваемый в рамках проекта Общегородской

информационный сервис Системы персонифицированного учѐта Единой медицинской

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

централизованную информационную систему, размещаемую на обособленных централизованных

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

Информационное взаимодействие Общегородских информационных сервисов между собой и с

другими элементами системы должно осуществляться посредством Единой интеграционной шины

ЕМИАС.

Для целей разработки, запуска и демонстраций прототипа системы (в соответствии с

разделом 5.3 «Содержание работ второго этапа») Исполнителю предоставляются следующие

фиксированные вычислительные мощности: 4 ядра Power7 3.0 ГГц, 64 ГБ ОЗУ, 100 ГБ дискового

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

разделены на несколько виртуальных серверов.

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

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

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

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

постоянное взаимодействие Исполнителя и Заказчика, включая Департамент Здравоохранения

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

вопросов согласования требований к СПУ ЕМИАС к другим системам в составе ЕМИАС.

Эксплуатация Системы обеспечивается эксплуатирующей организацией ЕМИАС.

Ввод Системы в эксплуатацию должен проводиться поэтапно, с последовательным

увеличением количества МО, использующих СПУ ЕМИАС.

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

персонала Системы и программы обучения персонала Системы (см. раздел 5 «Состав и

содержание работ по созданию (развитию) системы»).





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

При разработке СПУ ЕМИАС рекомендуется использовать методические материалы

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

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

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

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





5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СОЗДАНИЮ (РАЗВИТИЮ)

СИСТЕМЫ

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

Процесс создания ИС, согласно ГОСТ 34.601-90, представляет собой совокупность

упорядоченных во времени, взаимосвязанных, объединенных в стадии и этапы работ, выполнение

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

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

Состав работ по этапам приведѐн в таблице 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,

Программа и методика опытной

Не более

110 дней от

начала

работ по

ГК

25





№


Процент

от суммы

ГК

эксплуатации по РД 50-34.698-90,

Программа и методика приѐмочных

испытаний по РД 50-34.698-90 п.2.14,

Ведомость машинных носителей

информации по РД 50-34.698-90 п. 5.4.1,

Акт сдачи-приѐмки отчѐтных

документов

2 Разработка прототипа

Системы

Разработанное программное

обеспечение прототипа на машинных

носителях,



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

прототипа

Не более

100 дней от

подписани

я акта по 1-

му этапу

55

3 Разработка

программного

обеспечения Системы

Разработанное программное

обеспечение подсистем СПУ ЕМИАС

на машинных носителях,



Ведомость эксплуатационных

документов по РД 50-34.698-90 п.2.13,

Паспорт по РД 50-34.698-90 п.2.8,

Общее описание системы по РД 50-

34.698-90 п.2.11,

Описание технологического процесса

обработки данных по РД 50-34.698-90

п.3.5,

Политика обеспечения

информационной безопасности,

Инструкция по обеспечению защиты

информации,

Документация на web-сервисы,

предназначенные для регистрации в

СМЭВ (в соответствии с приказом

Министерства связи и массовых

коммуникаций Российской Федерации

от 27 декабря 2010 г. № 190 «Об

утверждении технических требований к

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

систем в единой системе

межведомственного электронного

взаимодействия»),

Регламент эксплуатации Системы,

Руководство администратора Системы

по РД 50-34.698-90 п. 3.4,

Руководство оператора по РД 50-34.698-

90 п. 3.4,

Руководство программиста по ГОСТ

Не более

200 дней от

подписани

я акта по 2-

му этапу

10





№


Процент

от суммы

ГК

19.504-79,

Программа обучения администраторов

Системы;

Программа обучения операторов,

Акт сдачи-приѐмки отчѐтных

документов

4 Ввод Системы в

действие

Протокол проведения предварительных

испытаний,

Акт приѐмки в опытную эксплуатацию,

Протокол проведения опытной

эксплуатации,

Акт завершения опытной эксплуатации

и допуска системы к приѐмочным

испытаниям,

Протокол проведения приѐмочных

испытаний,

Акт готовности системы к

промышленной эксплуатации

Не более

100 дней от

подписани

я акта по 3-

му этапу

10

Состав документации, предъявляемой Исполнителем по завершении третьего и четвѐртого

этапов, может быть уточнѐн или дополнен по результатам НИР, выполняемой на первом этапе, и

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

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

Первый этап создания Системы «Научно-исследовательские работы, уточнение требований

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

определяет успех проекта в целом.

Результатом выполнения работ первого этапа должны быть отчѐт по НИР, ЧТЗ на

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

подтверждена актом сдачи-приѐмки, подписываемым Заказчиком и Исполнителем.

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

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

содержащий не менее 5 релизов.

5.2.1. Устав проекта

В начале первого этапа работ Заказчиком и Исполнителем должен быть согласован и

утверждѐн Устав проекта.

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

состав проектных групп со стороны Заказчика и Исполнителя, кураторы проекта;





разграничение зон ответственности Заказчика и Исполнителя;

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

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

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

конфиденциальности разработанной проектной документации и информации, которой

обмениваются Стороны в ходе выполнения работ.

Проектная группа Заказчика и Исполнителя должна располагать средствами совместной

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

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

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

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

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

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

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

В ходе первого этапа должен быть выполнен анализ и обобщѐн опыт применения

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

обосновано их применение либо нецелесообразность применения в СПУ ЕМИАС. В качестве

базовых следует рассматривать международные стандарты HL7 (версии 2.х и 3.х), OpenEHR,

LOINC и другие, а также российские ГОСТы по информатизации здравоохранения.

Анализируя стандарты и сложившуюся практику их применения, Исполнителю следует

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

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

По результатам проведения указанных работ должен быть подготовлен отчѐт о НИР,

входящий в состав документации по итогам первого этапа.

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

В ходе выполнения работ первого этапа должно быть проведено уточнение требований, и

разработаны ЧТЗ на следующие подсистемы:

обеспечение работы с НСИ АИС ОМС;

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

контроль учѐтных данных;

формирование отчѐтов, включая компоненты:

o конструктор экранных форм;

o конструктор печатных форм.





мониторинг руководством МО;

взаимодействие со смежными системами;

администрирование;

обеспечение информационной безопасности.

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

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

требования.

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

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

Перед выполнением работ по разработке ЧТЗ на подсистему информационной

безопасности должны быть определены потенциальные нарушители и угрозы информационной

безопасности СПУ ЕМИАС, а также оценены вероятность и последствия реализации угроз. По

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

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

защищенное окружение, так и собственные средства защиты СПУ ЕМИАС. Таким образом, все

направления защиты от угроз информационной безопасности СПУ ЕМИАС должны быть

разделены на две части:

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

окружение;

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

СПУ ЕМИАС.

Соответственно, в отношении направлений защиты, обеспечиваемых за счет средств

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

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

направлений защиты, обеспечиваемых за счет средств СПУ ЕМИАС, должны быть

спроектированы соответствующие модули и компоненты подсистем СПУ ЕМИАС.

Должны быть определены защищаемые объекты Системы, основные угрозы безопасности,

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

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

условий и факторов, создающих опасность нарушения характеристик безопасности объектов,

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

этих возможностей. На основании полученных данных должны быть сформированы Модель угроз





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

документах.

Модель нарушителя информационной безопасности должна определять:

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

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

основные каналы, цели и объекты атак;

предположения об имеющихся у нарушителя средствах.

Модель угроз информационной безопасности должна определять:

защищаемые объекты;

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

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

уязвимости Системы к деструктивным воздействиям.

ЧТЗ на подсистему информационной безопасности должно разрабатываться на основе

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

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

программному обеспечению и аппаратному комплексу СПУ ЕМИАС и систем инфраструктурного

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

минимум, следующие требования:

требования к аутентификации пользователей;

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

требования к мониторингу информационной безопасности;

требования к безопасности сетевой инфраструктуры;

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

требования к антивирусной защите;

требования к средствам обнаружения и предотвращения вторжений и поиска

уязвимостей;

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

требования к физической защите мест размещения средств обработки и хранения

конфиденциальной информации.

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

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

себя следующие документы:

ведомость технического проекта по РД 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.3. Содержание работ второго этапа

5.3.1. Разработка прототипа

В ходе работ второго этапа требуется разработать прототип СПУ ЕМИАС, в котором будут

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

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

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

загрузка НСИ в хранилище Системы;

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

формирование отчѐтов в электронном виде;

загрузка результатов внешнего контроля в хранилище Системы.

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

12.

Таблица 12 – Функции в составе прототипа

Подсистема Функции





Обеспечение работы с НСИ АИС

ОМС

Загрузка НСИ в хранилище Системы;

Обеспечение сохранности всех версий предыдущих

пакетов.

Учѐт медицинской помощи Ввод персональных данных пациентов по категориям;

Ввод данных об оказанной медицинской помощи

пациентам;

Проверка данных при вводе.

Контроль учетных данных Контроль персональных данных;

Выявление дублей по персональным данным;

Контроль данных об оказанной медицинской помощи;

Поиск дублированной информации об оказанной

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

(без функций исправления ошибок, запросов к РС

ЕРЗЛ)

Формирование отчѐтов Формирование отчѐтов в электронном виде;

Формирование отчѐтов на бумажном носителе для

сопровождения счѐта.

(без функций конструкторов экранных и печатных форм,

всей отчѐтности по ОМС)

Импорт результатов внешнего

контроля

Проверка представленных результатов;

Загрузка результатов в хранилище Системы.

(без функций формирования отчѐтности по загрузке)

Мониторинг руководством МО Не входит в состав прототипа

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

системами

Не входит в состав прототипа

Администрирование Регистрация пользователей;

Разграничение прав доступа;

Просмотр журналов событий.

(без функций настройки конкретной МО, управления

режимом работы и оповещения о нештатных ситуациях)

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

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

Регистрация входа / выхода пользователей (включая

администраторов) в Систему;

Регистрация события доступа пользователя к





защищаемым данным.

(только функции компоненты регистрации и учѐта)

В составе прототипа должен быть реализован пользовательский интерфейс для

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

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

требований не предъявляется.

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

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

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

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

Исполнитель обеспечивает развѐртывание ПО Системы на ресурсах предоставленного

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

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

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

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

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

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

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

На третьем этапе проводится разработка программного обеспечения Системы согласно

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

и другим документам первого этапа проекта.

С целью проведения испытаний Системы (см. разделы 5.5 «Содержание работ четвѐртого

этапа» и 6 «Порядок контроля и приемки системы») в составе программного обеспечения должен

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

программой и методикой испытаний работоспособности web-сервисов, обеспечивающих

возможность работы пользователей МО с Системой. К дизайну и удобству использования данного

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

5.4.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;

руководство программиста по ГОСТ 19.504-79.

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

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

отражения (и контроля) различных этапов разработки в соответствии с планом, согласованным на

первом этапе.

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

СПУ ЕМИАС к внедрению; готовность Системы к началу внедрения и сдача-приѐмка отчѐтной

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

Заказчиком и Исполнителем.

5.5. Содержание работ четвѐртого этапа

На четвѐртом этапе проводится ввод в действие СПУ ЕМИАС. На этом этапе:

1. До начала работ по внедрению должны быть разработаны документы:

политика обеспечения информационной безопасности СПУ ЕМИАС. Этот документ

должен регламентировать процессы по обеспечению информационной безопасности

при эксплуатации Системы;

инструкция по обеспечению защиты информации в СПУ ЕМИАС.

2. Должны быть проведены предварительные испытания Системы по утверждѐнной

программе и методике испытаний.

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

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

разработаны скрипты для моделирования промышленной нагрузки. Программное

обеспечение СПУ ЕМИАС будет оптимизировано по результатам испытаний под

проектную нагрузку.

Испытания проводятся с использованием стенда, организованного с использованием

ресурсов программно-аппаратного комплекса, предоставленного Заказчиком.





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

смежных систем для отладки взаимодействия с СПУ ЕМИАС будет определѐн Заказчиком.

Обязательным должна быть проверка взаимодействия с ЦАПК АИС ОМС.

4. Должно быть проведено обучение администраторов и операторов СПУ ЕМИАС; общая

численность слушателей до 50 человек. Обучение проводит Исполнитель на основе

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

расписанию занятий, а Заказчик обеспечивает присутствие на занятиях персонала,

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

5. Должна быть проведена опытная эксплуатация Системы. Порядок опытной эксплуатации

описан в разделе 6 «Порядок контроля и приемки системы».

6. Должны быть проведены приемочные испытания Системы. Порядок проведения

приѐмочных испытаний описан в разделе 6 «Порядок контроля и приемки системы».

Промышленная эксплуатация Системы начинается после успешного завершения

приѐмочных испытаний, подписания акта о готовности Системы к промышленной эксплуатации и

выпуска распорядительного документа Правительства Москвы о вводе Системы в промышленную

эксплуатацию.





6. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ

6.1. Виды, состав, объѐм и методы испытаний

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

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

проверяться на основе утверждѐнных программ и методик испытаний.

Виды, состав, объѐм и методы испытаний должны соответствовать требованиям ГОСТ

34.603-92 «Виды испытаний автоматизированных систем».

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

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

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

в разработанной документации.

Система проходит следующие виды испытаний:

предварительные испытания;

опытную эксплуатацию в пилотной зоне;

приѐмочные испытания.

Проведение испытаний Системы входит в состав работ четвѐртого этапа (раздел 5.5

«Содержание работ четвѐртого этапа»).

Испытания проводятся по утверждѐнным программам и методикам в сроки, установленные

в соответствии с календарным планом работ Государственного контракта. Содержание и

оформление программ и методик испытаний должно соответствовать РД 50-34.698-90 п. 2.14.

Предусмотренные испытания проводятся комиссией, формируемой Заказчиком на

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

проведения испытаний, порядок еѐ работы, место и сроки проведения испытаний.

В состав комиссии включаются представители организаций Заказчика, Пользователя и

Исполнителя, а также могут включаться специалисты, привлекаемые Заказчиком.

Результаты проведения каждого вида испытаний должны быть зафиксированы в

соответствующем протоколе, который подписывают Заказчик и Исполнитель. Перечень

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

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

Технического задания (Частного технического задания). Прочие недостатки могут быть внесены в

протокол как желательные доработки. Наличие желательных доработок не влияет на признание

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





По завершении предварительных и приѐмочных испытаний оформляются соответствующие

Акты, содержащие вывод о соответствии Системы предъявляемым требованиям, а также сроки

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

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

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

Результаты опытной эксплуатации отражаются в документе «Протокол проведении опытной

эксплуатации» и рассматриваются в ходе приѐмочных испытаний.

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

соответствующего вида испытаний.

Условием для передачи системы в опытную или промышленную эксплуатацию является

устранение всех замечаний с высоким уровнем критичности на предыдущих этапах.

Для проведения испытаний Заказчик предоставляет программно-аппаратный комплекс,

характеристики которого соответствуют требованиям, указанным в документе «Описание

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

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

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

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

предоставленного программно-аппаратного комплекса.

Для проведения опытной эксплуатации Системы Заказчик обеспечивает организацию

пилотной зоны. Состав МО пилотной зоны и участников опытной эксплуатации из числа

сотрудников МО для проведения опытной эксплуатации определяется Заказчиком и утверждается

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

Заказчик обеспечивает организацию обучения участников опытной эксплуатации из числа

сотрудников МО и персонала эксплуатирующей организации. Обучение проводит Исполнитель на

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

расписанию занятий, а Заказчик обеспечивает присутствие слушателей на занятиях персонала,

организует выделение помещения и оборудования для проведения занятий.

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

недоступна к срокам проведения опытной эксплуатации СПУ ЕМИАС, то опытная эксплуатация

Системы может быть проведена с использованием пользовательских интерфейсов, разработанных

для демонстрации прототипа Системы на втором этапе (раздел 5.3.1 «Разработка прототипа»).

Объѐм испытаний для каждого вида испытаний определѐн в таблице 13.





Таблица 13 – Объѐм испытаний

Вид испытания Объем испытаний

1 Предварительные испытания Функциональное тестирование.

Тестирование производительности

(нагрузочное тестирование)

2 Опытная эксплуатация Функциональное тестирование.

Тестирование интерфейса.

Тестирование эргономичности (юзабилити)

3 Приѐмочные испытания Функциональное тестирование.

Тестирование производительности

(нагрузочное тестирование).

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

тестирование)

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

стенде, организованном на ресурсах программно-аппаратного комплекса, предоставленного

Заказчиком для проведения испытаний Системы. Методика тестирования, необходимая точность

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

согласованы с Заказчиком. Для моделирования промышленной нагрузки Исполнитель должен

подготовить специализированные скрипты.

Тестирование разрабатываемых в составе Системы пользовательских интерфейсов и их

эргономичности проводит Заказчик в процессе опытной эксплуатации в соответствии с

утверждѐнной программой и методикой испытаний.

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

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

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

ограничением для признания работоспособности Системы.

6.2. Порядок выполнения доработок и устранения допущенных

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

Недостатки и ошибки в реализации Системы, выявленные в ходе проведения испытаний,

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

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

документе «Программа и методика испытаний». Сроки устранения замечаний и реализации





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

испытаний.

6.3. Сведения о гарантийном обслуживании

Исполнитель должен организовать гарантийное сопровождение Системы в течении 18

месяцев с момента подписания акта о готовности системы к промышленной эксплуатации, и

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

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

контрактом.

Исполнитель должен гарантировать, что модернизированное и разработанное программное

обеспечение Системы будет функционировать в соответствие со своим назначением не менее 18

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

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

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

Исполнитель не гарантирует отсутствие недостатков или сбоев в процессе работы,

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

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

характеристикам клиентских мест.





7. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО

ПОДГОТОВКЕ ОБЪЕКТА АВТОМАТИЗАЦИИ К ВВОДУ

СИСТЕМЫ В ДЕЙСТВИЕ

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

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

Для развертывания стендов, требуемых для проведения испытаний (см. раздел 6 «Порядок

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

средства связи.

Опытная и промышленная эксплуатация Системы осуществляется в рамках

инфраструктуры БМИ ЕМИАС. Заказчик должен обеспечить наличие технических средств

(оборудования и инфраструктуры) с характеристиками, обеспечивающими работу в требуемых

режимах функционирования (см. раздел 4.1.1.4 «Требования к режимам функционирования

Системы»), с требуемыми показателями назначения (см. раздел 4.1.3 «Показатели назначения») с

учетом требований, перечисленных в Техническом задании:

по диагностированию;

по надежности;

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

по эргономике и технической эстетике;

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

системы;

по обеспечению безопасности информации;

по сохранности информации при авариях.

Основные характеристики технического обеспечения приведены в разделе 4.3.5

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

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

Требования к численности персонала и режиму его работы см. в разделе 4.1.2 «Требования к

численности и квалификации персонала Системы и режиму его работы».





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

Исполнитель должен принять от Заказчика подготовленное оборудование стенда,

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

сторонних производителей и развернуть разработанные подсистемы СПУ ЕМИАС на стенде.

Работы по переносу разработанных подсистем СПУ ЕМИАС необходимо выполнить для

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

завершения проектных работ по созданию СПУ ЕМИАС Исполнитель переносит разработанное

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

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

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

системами:

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

подсистемами Московского городского фонда ОМС (включая единый реестр

застрахованных);

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

единым каталогом пользователей (БМИ ЕМИАС);

подсистемой НСИ (ЕМИАС);

СУПП ЕМИАС;

другими смежными подсистемами ЕМИАС.

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

разработчиков ЕМИАС.

Исполнитель обеспечивает настройку СПУ ЕМИАС на этапах подготовки к проведению

испытаний, а также в среде опытной и промышленной эксплуатации.

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

действие

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

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

разделах настоящего Технического задания.

Должностные обязанности персонала, участвующего в эксплуатации СПУ ЕМИАС,

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

штатных единиц организации Заказчика.





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

штатной (организационной) структуры организации Заказчика, руководство организации должно

закрепить перераспределение обязанностей персонала в положениях о соответствующих

подразделениях.

Исполнитель должен подготовить методические документы:

для обучения персонала Заказчика (повышения квалификации);

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

инструкциях.

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

администратора, программиста или другой эксплуатационной документации. Допускается

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

и утверждѐн в порядке, общем для всей документации на СПУ ЕМИАС.





8. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ

Требования к документированию каждого из этапов работы приведены в таблице 11

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

Рабочая документация проекта, необходимая Исполнителю на различных стадиях

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

тестирования - не предъявляются Заказчику как итоговые документы этапов работы или для

проведения испытаний.

Вся эксплуатационная программная документация на разработанное ППО должна

соответствовать стандарту РД 50-34.698-90 (исключения указаны в списке документов ниже), и

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

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

соответствующих тестов.

Исполнитель предъявляет и передает Заказчику следующие документы:

устав проекта;

рабочий план-график проекта;

паспорт по РД 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.14;

программа и методика приѐмочных испытаний по РД 50-34.698-90 п.2.14;

общее описание системы по РД 50-34.698-90 п.2.11;





описание технологического процесса обработки данных по РД 50-34.698-90

п.3.5;Документация на web-сервисы, предназначенные для регистрации в СМЭВ (в

соответствии с приказом Министерства связи и массовых коммуникаций Российской

Федерации от 27 декабря 2010 г. № 190 «Об утверждении технических требований к

взаимодействию информационных систем в единой системе межведомственного

электронного взаимодействия»);

руководство администратора Системы по РД 50-34.698-90 п. 3.4;

руководство оператора по РД 50-34.698-90 п. 3.4;

руководство программиста по ГОСТ 19.504-79;

программа обучения администраторов Системы;

программа обучения операторов;

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

инструкция по обеспечению защиты информации;

регламент архивного хранения данных;

регламент эксплуатации Системы;

ведомость машинных носителей информации по РД 50-34.698-90 п. 5.4.1.

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

машинных носителях (на машинных носителях – в формате документов MS Office).





9. ИСТОЧНИКИ РАЗРАБОТКИ

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

«Перечень документов, на основании которых создается Система», а также следующие

документы:

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

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

№364 от 28.04.2011;

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

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

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

Постановление Правительства Москвы от 21 декабря 2011 г. N 604-ПП «Об

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

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

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

государственных функций в городе Москве»;

Постановление Правительства Российской Федерации от 08 сентября 2010 г. № 697 «О

единой системе межведомственного электронного взаимодействия»;

Федеральный закон от 29.11.2010 г. № 326-ФЗ «Об обязательном медицинском

страховании в Российской Федерации»;

ГОСТ 24.208-80 «Требования к содержанию документов стадии «Ввод в

эксплуатацию»;

ГОСТ 34.003-90 «Автоматизированные системы. Термины и определения»;

ГОСТ 34.201-89 «Виды, комплектность и обозначение документов при создании

автоматизированных систем»;

ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания»;

ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы»;

ГОСТ 34.603-92 «Виды испытаний автоматизированных систем»;

РД 50-34.698-90 «Автоматизированные системы. Требования к содержанию

документов»;

ГОСТ 19.301-79 «Программа и методика испытаний. Требования к содержанию и

оформлению»;





ГОСТ Р 52977—2008 Информатизация здоровья. Состав данных о взаиморасчетах за

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

Приказ Министерства здравоохранения и социального развития Российской Федерации

от 25 января 2011 г. N 29н «Об утверждении порядка ведения персонифицированного

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

Приказ Министерства здравоохранения и социального развития Российской Федерации

от 28 февраля 2011 года № 158н (с изменениями от 9 сентября 2011 года) «Об

утверждении Правил обязательного медицинского страхования»;

Приказ Федерального фонда обязательного медицинского страхования от 22 августа

2011 г. № 154 «О внесении изменений в приказ ФОМС от 07.04.2011 № 79» «Об

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

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

медицинского страхования»;

Приказ Московского городского фонда обязательного медицинского страхования от 1

декабря 2011 г. «Регламент информационного взаимодействия Медицинской

организации и МГФОМС при реализации Договора на оказание и оплату медицинской

помощи, оказанной гражданам, застрахованным по ОМС на территории других

субъектов РФ (иногородним гражданам)»;

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

от 1 декабря 2011 г. № 192 «Об утверждении порядка информационного

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

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

страхования города Москвы»;

Приказ Московского городского фонда обязательного медицинского страхования от 13

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

организацией объемов медицинской помощи по Территориальной программе

обязательного медицинского страхования города Москвы на 2012 год»;

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

от 1 февраля 2012 года № 693 «О регламенте приѐма-передачи данных при

информационном взаимодействии в АИС ОМС».





СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. ГОСТ 34.003-90 АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. ТЕРМИНЫ И

ОПРЕДЕЛЕНИЯ.

2. ГОСТ 34.201-89 ВИДЫ, КОМПЛЕКТНОСТЬ И ОБОЗНАЧЕНИЕ ДОКУМЕНТОВ ПРИ

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

3. ГОСТ 34.601-90 – КОМПЛЕКС СТАНДАРТОВ НА АВТОМАТИЗИРОВАННЫЕ

СИСТЕМЫ. АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. СТАДИИ СОЗДАНИЯ.

4. ГОСТ 34.602-89 ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ

АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ.

5. ГОСТ 34.603-92 ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. ВИДЫ ИСПЫТАНИЙ

АВТОМАТИЗИРОВАННЫХ СИСТЕМ.

6. РД 50-680-88 МЕТОДИЧЕСКИЕ УКАЗАНИЯ. АВТОМАТИЗИРОВАННЫЕ

СИСТЕМЫ. ОСНОВНЫЕ ПОЛОЖЕНИЯ.

7. РД 50-682-89 МЕТОДИЧЕСКИЕ УКАЗАНИЯ. ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ.

КОМПЛЕКС СТАНДАРТОВ И РУКОВОДЯЩИХ ДОКУМЕНТОВ НА

АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. ОБЩИЕ ПОЛОЖЕНИЯ.

8. РД 50-34.698-90 МЕТОДИЧЕСКИЕ УКАЗАНИЯ. ИНФОРМАЦИОННАЯ

ТЕХНОЛОГИЯ. КОМПЛЕКС СТАНДАРТОВ И РУКОВОДЯЩИХ ДОКУМЕНТОВ

НА АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ

ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ.

9. Р 50-34.119-90 ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. КОМПЛЕКС СТАНДАРТОВ

НА АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. АРХИТЕКТУРА ЛОКАЛЬНЫХ

ВЫЧИСЛИТЕЛЬНЫХ СЕТЕЙ В СИСТЕМАХ ПРОМЫШЛЕННОЙ

АВТОМАТИЗАЦИИ.

10. Р 50739-95 СРЕДСТВА ВЫЧИСЛИТЕЛЬНОЙ ТЕХНИКИ. ЗАЩИТА ОТ

НЕСАНКЦИОНИРОВАННОГО ДОСТУПА К ИНФОРМАЦИИ.





ПРИЛОЖЕНИЕ 1. СОСТАВ ПАКЕТА НСИ АИС ОМС

№ Наименование таблицы НСИ

1. Кодификатор «Административно-территориальные округа города Москвы»

2. Кодификатор «Этапы МЭК и виды экспертизы счетов ЛПУ»

3. Справочник «Нормативные объемы услуг»

4. Справочник «Допустимые услуги в профильном отделении стационара»

5. Справочник «Основные характеристики медицинских услуг»

6. Кодификатор «Гражданство «

7. Кодификатор «Исход заболевания»

8. Кодификатор «Медицинские должности»

9. Кодификатор «Пол пациента»

10. Кодификатор «Признак прерывания (полноты выполнения) МС»

11. Кодификатор «Медицинские специальности»

12. Справочник «Шифры диагнозов по МКБ-10»

13. Справочник «Соответствие МС и шифров диагнозов»

14. Справочник «Перечень диагнозов, исключающих контроль кода медицинской помощи

по возрасту пациента»

15. Кодификатор «Номенклатура ЛПУ»

16. Кодификатор «Вектор ответа на запрос к ЕРЗ»

17. Кодификатор «Особый случай в реестре пациентов»

18. Кодификатор «Особый случай в счете на пациента»

19. Кодификатор «Ведомства, состоящие в договорных отношениях по ОМС»

20. Кодификатор «Профили коек (отделений) ЛПУ»






21. Справочник «Профиль медицинских услуг»

22. Кодификатор «Профиль медицинской помощи»

23. Справочник «Реестр медицинских стандартов»

24. Справочник «Реестр медицинских услуг»

25. Кодификатор «Результат обращения за медицинской помощью»

26. Кодификатор «Сообщения о результатах экспертизы отчетной информации»

27. Справочник «Совместимые/несовместимые услуги»

28. Справочник «Улицы города Москвы»

29. Справочник «Абоненты АИС ОМС»

30. Справочник «МО системы ОМС города Москвы»

31. Справочник «Страховые медицинские организации системы ОМС города Москвы»

32. Справочник «Элементы НСИ»

33. Кодификатор «Статус абонента»

34. Справочник «Тарифы медицинских услуг»

35. Кодификатор «Территории РФ»

36. Справочник «Перечень СМО, работающих в РФ в системе ОМС»

37. Кодификатор «Тип абонента»

38. Справочник «Перечень недопустимых прерываний лечения по МС»

39. Кодификатор «Тип ответа на запрос ЕРЗ»

40. Кодификатор «Условия оказания медицинской помощи»

41. Справочник «Специализированные медицинские услуги»

42. Кодификатор «Управления здравоохранения административно-территориальных






округов города Москвы»

43. Кодификатор «Виды документов»

44. Кодификатор «Возрастные категории обслуживаемого населения»

45. Справочник «Недопустимые диагнозы раздела Z-код»





ПРИЛОЖЕНИЕ 2. ПЕРЕЧЕНЬ ЗАКОНОДАТЕЛЬНЫХ АКТОВ И

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

ОБЕСПЕЧЕНИЯ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

1. Федеральный закон Российской Федерации от 27.07.2006г. №149-ФЗ «Об

информации, информационных технологиях и о защите информации»;

2. Федеральный закон Российской Федерации от 27.07.2006г. №152-ФЗ «О

персональных данных»;

3. Федеральный закон Российской Федерации от 29.07.2004г. №98-ФЗ «О

коммерческой тайне»;

4. Федеральный закон Российской Федерации от 21.11.2011г. №323-ФЗ «Об

основах охраны здоровья граждан в Российской Федерации»;

5. Указ Президента Российской Федерации от 06.03.1997г. №188 «Об утверждении

перечня сведений конфиденциального характера»;

6. «Положение об обеспечении безопасности персональных данных при их

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

постановлением Правительства РФ № 781 от 17 ноября 2007 г.;

7. «Положение об особенностях обработки персональных данных, осуществляемой

без использования средств автоматизации», утверждено постановлением

Правительства РФ № 687 от 15 сентября 2008 г.;

8. «Методика определения актуальных угроз безопасности персональных данных

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

15 февраля 2008 г.;

9. Приказ ФСТЭК от 5 февраля 2010 г. № 58 «Об утверждении положения о

методах и способах защиты информации в информационных системах защиты

персональных данных»;

10. Приказ Министерства связи и массовых коммуникаций Российской Федерации

от 27 декабря 2010 года № 190 «Об утверждении Технических требований к

взаимодействию информационных систем в единой системе межведомственного

электронного взаимодействия»

11. Методические рекомендации по обеспечению с помощью криптосредств

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

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

ФСБ, 21 февраля 2008 г.





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

информационных системах персональных данных. ФСТЭК, от 15 февраля 2008 г.

13. «Порядок проведения классификации информационных систем персональных

данных», утвержден совместным приказом ФБС России, ФСТЭК России и

Мининформсвязи России от 13 февраля 2008 г. №55/86/20»;

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

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

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

случае их использования для обеспечения безопасности персональных данных

при их обработке в информационных системах персональных данных. ФСБ

России, 21 февраля 2008 г.;

15. «Положение об особенностях оценки соответствия продукции (работ, услуг),

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

с законодательством Российской Федерации информации ограниченного

доступа, не содержащей сведения, составляющие государственную тайну, а

также процессов еѐ проектирования (включая изыскания), производства,

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

реализации, утилизации и захоронения», утвержденное постановлением

Правительства РФ от 15 мая 2010. №330”;

16. «Методические рекомендации по оснащению медицинских учреждений

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

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

здравоохранения, а также функциональные требования к ним», от 14 ноября 2011

г., подготовленные Минздравсоцразвития РФ;

17. «Методические рекомендации для организации защиты информации при

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

сферы, труда и занятости» от 23 декабря 2009 г, утвержденными

Минздравсоцразвития РФ.





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

Дата Версия Описание изменений Автор

s

Documents

ТЗ СПУ ЕМИАС