Создание единой информационной системы - ВОЛГА-МЕД

ООО «Волга-мед»
Построение региональной
системы электронных
медицинских карт
Построение региональной системы электронных медицинских карт
Оглавление
ЧАСТЬ 1. МЕТОДИЧЕСКОЕ ОПИСАНИЕ. ............................................................................................... 5
Сокращения ...........................................................................................................................6
Нормативные документы ......................................................................................................6
Цели проекта и ожидаемые результаты ..............................................................................7
Описание функциональных возможностей системы ...........................................................9
Обзор вариантов построения региональных информационных систем........................... 11
Вариант 1. Централизованная модель данных .............................................................. 11
Вариант 2. Федеративная модель данных (широковещание) ....................................... 12
Вариант 3. Федеративная модель данных (центральный индекс) ............................... 13
Вариант 4. Гибридная модель данных ........................................................................... 14
Выбор решения для построения региональной информационной системы «Флагман
медицина» ........................................................................................................................... 15
Требования, предъявляемые к функционированию РИС.............................................. 15
Выбор технологий при построении подобной системы ................................................. 17
Принципы функционирования ЭМК .................................................................................... 18
Применение аналитических механизмов ........................................................................... 18
Этапы разработки и внедрения региональной системы ................................................... 19
ЧАСТЬ 2. ТЕХНИЧЕСКОЕ ОПИСАНИЕ ..................................................................................................22
Анализ функциональных требований ................................................................................ 23
Требования к технологическим стандартам ................................................................... 23
Анализ технических требований......................................................................................... 23
Отказоустойчивость. ........................................................................................................ 23
Скорость получения данных............................................................................................ 24
Избыточность ................................................................................................................... 25
Масштабируемость .......................................................................................................... 25
Устойчивость к изменениям ............................................................................................ 25
Защищенность ................................................................................................................. 25
Архитектура и топология системы ...................................................................................... 25
Общее описание .............................................................................................................. 25
Общее функционирование системы ............................................................................... 26
Описание функциональных блоков ................................................................................ 27
Распределение информации .......................................................................................... 28
Страница 2
Построение региональной системы электронных медицинских карт
Обеспечение информационной безопасности системы ................................................... 28
Вариант построения архитектуры информационных систем ........................................ 28
Определение требований к безопасности...................................................................... 30
Уровни доступа к информации. Ролевое разграничение. ............................................. 30
Правила доступа в чрезвычайных ситуациях................................................................. 32
Системы идентификации и аутентификации ................................................................. 32
Задачи необходимые для выполнения требований информационной безопасности . 32
Обеспечение доступности и отказоустойчивости .............................................................. 33
Резервное копирование ................................................................................................... 33
Создание резервного хранилища данных ...................................................................... 33
Реализация сетевой инфраструктуры ................................................................................ 34
Общие сведения. ............................................................................................................. 34
Процесс взаимодействия с сетью ЦОД .......................................................................... 34
Расчет технических характеристик компонентов системы ............................................... 34
Центральное хранилище ................................................................................................. 35
Внутренний WEB – сервер для приложения .................................................................. 36
Внутренний WEB – сервер документооборота ............................................................... 37
Медиа-сервер ................................................................................................................... 37
VPN-сервера .................................................................................................................... 38
Резервное хранилище данных ........................................................................................ 38
Индексный сервер управления ....................................................................................... 38
Расчет процессорной нагрузки........................................................................................ 38
Сервер крипто-шлюза в ЛПУ ........................................................................................... 38
Требования к хранилищу данных ....................................................................................... 39
Требования к инженерной инфраструктуре ЦОД .............................................................. 39
Описание программных средств ........................................................................................ 39
СУБД ................................................................................................................................. 39
Веб сервера ..................................................................................................................... 40
Операционные системы .................................................................................................. 40
Специализированное ПО. ............................................................................................... 40
Расчет штатной численности.............................................................................................. 40
Проведение технического аудита ....................................................................................... 41
Объекты технического аудита ......................................................................................... 41
Требования к объектам ИТ-инфраструктуры ................................................................. 42
Методика проведения аудита ......................................................................................... 44
Результаты проведение технического аудита................................................................ 45
Приложение 1. Таблица технических характеристик серверов ............................................................46
Страница 3
Построение региональной системы электронных медицинских карт
Приложение 2. Рекомендуемые требования к каналам связи ..............................................................49
Приложение 3 ............................................................................................................................................49
Приложение 4 ............................................................................................................................................51
Приложение 5 ............................................................................................................................................51
Приложение 6 ............................................................................................................................................52
Страница 4
Построение региональной системы электронных медицинских карт
ЧАСТЬ 1.
МЕТОДИЧЕСКОЕ ОПИСАНИЕ.
Страница 5
Построение региональной системы электронных медицинских карт
Сокращения
БД База данных
ОС
Операционная система
ИС
Информационная система
ЛПУ
Лечебно-профилактическое учреждение
ЦОД
центр обработки данных. В данном документе применяется в контексте единого
программного аппаратного комплекса предназначенного для хранения и обработки
данных
НСИ
Нормативно-справочная информация
ЭМК
Электронная медицинская карта пациента
ЭМЗ
Электронная медицинская запись в электронной карте пациента
РИЦ
Региональный Информационный Центр
OLAP (англ. online analytical processing, аналитическая обработка в реальном
времени) технология обработки информации, включающая составление и
динамическую публикацию отчётов и документов.
Нормативные документы

ФЗ 326 «Об обязательном медицинском страховании в Российской Федерации».
Федеральный закон Российской Федерации от 29 ноября 2010 года

ФЗ 152 «О персональных данных». Федеральный закон Российской Федерации от
27 июля 2006 года

ФЗ 184 «О техническом регулировании». Федеральный закон Российской
Федерации от 27 декабря 2002 года

ФЗ 210 «Об организации предоставления государственных и муниципальных
услуг». Федеральный закон Российской Федерации от 27 июля 2010 года

Приказ ФФОМС 240 «Об утверждении порядка и формы предоставления
отчетности об использовании средств на цели по реализации региональных
программ модернизации здравоохранения субъектов российской федерации в
период 2011 - 2012 годов» от 16 декабря 2010 года

ГОСТ Р 52600-2006 Протоколы ведения больных. Общие положения.

ГОСТ Р 52636-2006 Электронная история болезни. Общие положения.

ГОСТ Р ИСО/TС 18308-2008 Информатизация здоровья. Требования к архитектуре
электронного учета здоровья.
Страница 6
Построение региональной системы электронных медицинских карт

ГОСТ Р 52979-2008 Информатизация здоровья. Состав данных сводного регистра
застрахованных граждан для электронного обмена этими данными. Общие
требования.

ГОСТ Р 52977-2008 Информатизация здоровья. Состав данных о взаиморасчетах
за пролеченных пациентов для электронного обмена этими данными. Общие
требования.

ГОСТ Р 52978-2008 Информатизация здоровья. Состав данных о лечебнопрофилактическом учреждении для электронного обмена этими данными. Общие
требования.

ГОСТ Р 52976-2008 Информатизация здоровья. Состав первичных данных
медицинской
статистики
лечебно-профилактического
учреждения
для
электронного обмена этими данными. Общие требования.
Цели проекта и ожидаемые результаты
Цель предлагаемого проекта: Реализация программы модернизации здравоохранения
и государственной политики государственных гарантий на бесплатную медицинскую
помощь, и повышение эффективности организации и управления процессом оказания
медицинской помощи населению.
В основу проекта положен принцип создания единого Регионального Информационного
Центра (РИЦ), представляющего комплексную систему хранения, обработки и
представления объективной медицинской информации. При создании РИЦ решаются
следующие задачи:





Создание стандарта
классификации
и
кодирования
информации
в
здравоохранении и обязательном медицинском страховании, разработка
нормативных документов, регламентирующих информационное взаимодействие
между организациями
и
учреждениями здравоохранения,
страховыми
медицинскими организациями, структурами Фонда обязательного медицинского
страхования и органами управления здравоохранением региона обработку и
хранение медицинских записей в электронном виде; публикацию нормативносправочной информации;
сбор и хранение данных электронных медицинских записей (ЭМЗ) пациентов,
обслуживаемых ЛПУ региона с учетом требований законодательства об
обработке персональных данных;
обеспечение достоверности и идентичности данных регистра учета сведений о
гражданах в системе обязательного медицинского страхования с регистрами
учета граждан, используемыми в здравоохранении;
Создание процедуры оперативной подготовки и предоставления статистической и
управленческой отчетности в органы государственной власти региона в
автоматизированном режиме.
Обеспечение персонифицированного учета оказания медицинской помощи,
управление затратами на медицинскую помощь, оказываемую гражданам за счет
средств
обязательного
медицинского
страхования,
региональных
и
федерального бюджетов,
переход
на
электронное
взаимодействие
в
Страница 7
Построение региональной системы электронных медицинских карт

здравоохранении при расчетах за оказанную медицинскую помощь, обмене
клинической медицинской информацией;
Обеспечение полной, достоверной и актуальной информацией о состоянии дел в
сфере здравоохранения в разрезе по территориям и классификаторам болезней,
а также предоставление средств и возможностей для оперативной
автоматизированной обработки и анализа указанной информации.
При реализации предлагаемого проекта будут получены следующие положительные
эффекты:















повышение оперативности принятия решений при оказании медицинской помощи;
снижение операционных затрат на обработку, передачу, хранение медицинской и
другой необходимой в работе врача информации;
снижение
количества
искажений
отчетных
данных
в
обязательном
медицинском страховании и управленческой отчетности ЛПУ для органов
управления здравоохранением (ОУЗ);
повышение уровня доступности медицинской информации и образовательных
ресурсов для специалистов и населения;
уменьшение ошибок медицинского персонала, связанных с назначением
лекарственных препаратов и выбором курса лечения (ошибки, связанные с
неразборчивостью рукописных записей в листах назначений, исключаются
полностью);
сокращение
количества
проводимых
дополнительных
консультаций,
обследований и анализов;
сокращение
количества
лабораторных
тестов
и
рентгенологических
исследований,
назначаемых
различными
специалистами
в
отсутствии
информации о ранее проведенных анализах (при наблюдении у специалистов в
различных ЛПУ);
сокращение перерасхода медицинских расходных материалов и лекарственных
препаратов;
сокращение количества повторных госпитализаций после лечения, с
соответствующим общим сокращением количества посещений пациентами
медицинских учреждений (количества приемов у врачей) на один законченный
случай;
сокращение времени, затрачиваемого медицинским персоналом на поиск
необходимой информации;
сокращение времени, затрачиваемого медицинским персоналом на ведение
текущей документации;
сокращение
времени,
затрачиваемого
медицинским
персоналом
на
проведение консультаций, собрание анамнеза и постановку диагноза;
снижение
временной нетрудоспособности
граждан
за
счет
снижения
количества ошибок при постановке диагнозов и доступа врачей к информации по
новейшим методам лечения и новинкам в области лекарственных препаратов;
снижение
смертности и
соответствующее увеличение
средней
продолжительности жизни населения.
Для пациентов сократится время поиска необходимых специалистов, записи к ним
на прием и получения обратной связи от учреждений здравоохранения
Страница 8
Построение региональной системы электронных медицинских карт
Описание функциональных возможностей системы
В рамках первоначальной реализации описанных выше задач предлагается создание
региональной информационной системы, обеспечивающее следующие функции:
Функциональность доступная пациентам (через web-формы):



Поиск врачей заданной специальности в ЛПУ региона
Просмотр расписаний врачей в выбранном учреждении
Управление своим «личным кабинетом», в котором пациент может просмотреть
или распечатать ту или иную информацию из своей амбулаторной карты,
результаты анализов, диагностических исследований. Кроме этого, пациент имеет
возможность настроить доступность определенных параметров своей истории
болезни для просмотра.
Функциональность доступная работникам ЛПУ






Ввод информации о приеме данного пациента в конкретном ЛПУ
Просмотр на приеме врача полной медицинской карты пациента (при наличии
соответствующих прав доступа), в том числе сделанных вне рамок данного
учреждения
Возможность назначать анализы и просматривать их результаты, в том числе
сделанных в других учреждениях
Возможность просматривать видео, аудио и графический контент, относящийся к
истории болезни или ЭМК выбранного пациента (рентгеновские снимки, записи
УЗИ и т.д.)
Возможность установления видео и/или аудио связи для консультаций с врачами
другого ЛПУ (телемедицина)
Получать доступ к сторонним медицинским справочникам и стандартам лечения
для просмотра справочной информации
Функциональность доступная пользователям региональных контролирующих органов



Быстрое получение статистической отчетности
Контроль и анализ медицинской информации по любым, доступным срезам
Мониторинг лечебной деятельности любого отдельного ЛПУ
Общая функциональность системы






Хранение данных ЭМК пациентов в центральном хранилище данных с учетом
требований по защите персональных данных
Регулярная актуализация данных ЭМК
Возможность выгрузки ЭМК пациента в соответствии с утвержденным
государственным стандартом
Связь с диагностическими и лабораторными информационными системами на
основе утвержденных стандартов (DICOM и т.п.)
Хранение видео и аудио медицинской информации
Объединение в единую информационную структуру существующих в регионе
медицинских информационных систем на основе сервисно-ориентированной
архитектуры, в соответствии со утвержденными стандартами, спецификацией HL7
v.3. и с регламентом обмена медицинской информацией
Страница 9
Построение региональной системы электронных медицинских карт

Обеспечение доступа к информационным ресурсам, создание единого
регионального интернет-портала для хранения справочной информации, а также
регламентирующих приказов и распоряжений
Следует отметить, что данный функционал является базовым при создании РИС, над
которым в дальнейшем можно построить и другие информационные ресурсы с
расширенным функционалом. Кроме того, функционал информационной системы
полностью соответствует Требованиям к Медицинским Информационным Системам,
передаваемым в фонд алгоритмов и программ Министерства здравоохранения и
социального развития Российской Федерации, применяемым в Государственной
информационной системе персонифицированного учета в здравоохранении Российской
Федерации.
Логически информационная система представляет из себя структуру, поделенную на два
уровня: уровень ЛПУ и региональный уровень, схематично структура показана на рис 1.
Рисунок 1. Логическая структура системы
Данные элементы решают следующие задачи:


Подсистемы проверки подлинности решают вопросы с аутентификацией и
авторизацией
пользователей
различного
уровня,
предоставлением
соответствующих прав и т.д.
Единая система сбора и хранения информации решает задачи по сбору
информации из локальных ИС ЛПУ, формированию сводных индексов, генерации
Страница 10
Построение региональной системы электронных медицинских карт


запросов по сбору регулярной отчетности с локальных ИС, запуску процедур
репликации НСИ и локальных ИС.
Портал регионального уровня обеспечивает единую точку входа в
информационный ресурс для всех пользователей региональной ИС.
Локальная ИС ЛПУ – информационная система в конкретном учреждении, в
которую пользователи вносят первичные данные.
Обзор вариантов построения региональных информационных систем.
Выбор топологии и модели распространения данных является важнейшей задачей при
проектировании ИС. На данный момент при построении региональных систем подобного
типа (с полным обменом информации) можно выделить следующие модели построения
информационных систем:




Централизованная;
Федеративная;
Федеративная с центральным индексом;
Гибридная.
Вариант 1. Централизованная модель данных
• Все данные передаются в центр и доступны из центрального хранилища
•
Простая и надежная модель
•
Надежная связь с центром нужна для доступа к данным из нижестоящих узлов
•
Можно применять на любом уровне – больница, муниципальное образование,
регион
Рисунок 2. Централизованная модель
В рамках централизованной модели данных вся информация поступает в центральный
репозиторий, который является для всех потребителей единственным источником. Другие
системы более низкого уровня могут являться «питательными каналами»,
предоставляющими и передающими данные в центральный репозиторий.
В зависимости от масштаба системы, данная модель может быть реализована на
различных уровнях: для одного подразделения (больница) с различными
Страница 11
Построение региональной системы электронных медицинских карт
подразделениями или лабораторными системами, которые наполняют данными
центральный репозиторий; для группы или региона с участвующими узлами (клиники,
больницы, кабинеты врачей общей практики), отправляющими данные в региональный
репозиторий; для государственной системы с регионами или другими узлами,
отправляющими данные в государственный репозиторий, и так далее.
Основным преимуществом данной модели является ее простота — полный набор данных
(например, электронных медицинских записей пациентов) доступен из единого, хорошо
известного (центрального) источника. Решения, передающие данные в центральный
репозиторий, могут отличаться от решений для доступа к данным и использовать другие
технологии; к ним могут применяться менее жесткие требования с точки зрения
производительности и времени ожидания (например, асинхронная передача сообщений и
периодическая отправка файлов). Обеспечение ожидаемого качества обслуживания
(доступность, устойчивость), безопасности и управляемости одного центрального
хранилища данных может быть более простой и экономичной задачей, чем управление
несколькими хранилищами данных на участвующих узлах, особенно когда существуют
отдаленные участки, где нет специалистов в области ИТ или службы поддержки
(небольшие клиники или кабинеты врачей общей практики).
Возможность доступа к данным центрального репозитория с клиентских узлов зависит от
доступности, надежности и производительности всех элементов цепи: центрального
хранилища данных, средств связи между узлами и локальных систем. Централизованная
модель больше подходит для небольших локальных систем. В процессе расширения
системы задача обеспечения масштабируемости и производительности может стать
сдерживающим фактором.
При использовании такой модели доступны только те данные, которые уже были
сохранены в центральном репозитории. Они могут создаваться где угодно, но для
клиентов будут доступны только после сохранения в центральном репозитории. Запрос и
получение данных от узлов более низкого уровня невозможен. Часто бывает сложно
определить конкретный перечень данных (и степень детализации), которые необходимо
отправлять в центральный репозиторий: если данных будет слишком мало, можно
упустить детали, которые могут понадобиться в будущем, сохранение избыточного
объема данных приведет к необходимости расширения объема хранилища и может
негативно повлиять на производительность.
Вариант 2. Федеративная модель данных (широковещание)
1. Данные хранятся в нижестоящих узлах
2. Полная запись создается по запросу на основе доступных из всех источников
данных
3. Запрос посылается всем узлам, что не всегда практично
Страница 12
Построение региональной системы электронных медицинских карт
Рисунок 3. Распределенная модель
В рамках распределенной модели данные не собираются на центральном узле, а
распределяются среди большого количества узлов (подсистем). В зависимости от
масштаба системы, это могут быть региональные узлы (в государственной системе),
медицинские учреждения и другие участники системы, хранящие и предоставляющие
данные. В целях предоставления полного набора данных (например, медицинской карты
пациента), соответствующие подмножества должны быть собраны из этих различных
источников, а затем скомпонованы в единую «виртуальную запись». Таким образом,
предоставляется сводный отчет, что способствует принятию обоснованных решений. При
этом соблюдаются правовые нормы и требования к обеспечению конфиденциальности,
поскольку данные не хранятся за пределами определенных границ. Эта модель также
хорошо подходит для обеспечения межподразделенческого или межведомственного
доступа к информации (например, между поставщиками медицинских услуг,
поставщиками услуг в сфере социального обеспечения и другими участниками этой
системы), когда совместное хранение данных редко бывает возможным и политически
приемлемым.
Центральный
узел
(на
котором
данные
не
хранятся)
может
создать
«широковещательный» запрос (с указанием необходимых идентификаторов и других
атрибутов запрашиваемых данных) для всех узлов, а затем обработать и собрать ответы.
Такой подход может применяться в системах с относительно небольшим количеством
участвующих узлов.
Вариант 3. Федеративная модель данных (центральный индекс)
• Центральный индекс “знает” в каких узлах есть данные о лице “X”
•
Запросы отправляются только этим узлам
•
Полная запись создается по запросу на основе данных из этих источников
Страница 13
Построение региональной системы электронных медицинских карт
Рисунок 4. Распределённая модель с "индексом"
Более распространенным является решение, когда центральный узел хранит
«индексную» информацию о том, какие узлы содержат данные о конкретном лице (часто
эти данные называются основным индексом пациента). В данном случае запросы
отправляются только узлам, содержащим необходимые данные; это более рациональный
подход, особенно для систем с большим количеством узлов. Другим преимуществом
является то, что центральный индекс может также обеспечить перевод между
различными идентификаторами, которые могут использоваться участвующими узлами,
т. е. каждый узел получает запросы на своем «языке», независимо от других.
Центральный узел может содержать также соответствующие «метаданные», связанные с
отдельными элементами, хранящимися на узлах (сроки, характер эпизода, тип данных и
т. д.); это позволяет осуществлять поиск и фильтрацию данных, отправлять запросы
только для необходимых элементов (таких как результаты лабораторных анализов), а не
запрашивать всю имеющуюся информацию (полную историю болезни). Для реализации
этой модели, «индекс» (или реестр) должен обновляться каждый раз, когда узел получает
новые данные, это, как правило, осуществляется посредством отправки сообщения от
узла, на котором хранятся данные (репозиторий), центральному узлу (реестр).
Вариант 4. Гибридная модель данных
• Есть и центральное хранилище, и механизм получения данных из других узлов по
запросу
•
Гибкая граница между централизованными и федеративными данными
•
Часто требуемые данные можно централизовать; объемные и детальные данные
можно оставить в нижестоящих узлах и запрашивать при необходимости
Страница 14
Построение региональной системы электронных медицинских карт
Рисунок 5. Гибридная модель
Гибридная модель имеет как централизованное хранилище, так и механизм для
получения данных от участвующих узлов «по запросу», т. е. она представляет собой
комбинацию централизованной и федеративной модели. Фактически, эта модель может
быть максимально приближена к одному из «полюсов»: центральное хранилище может
содержать 100 % (централизованная модель) или 0 % (федеративная модель)
необходимых данных. Одним из основных преимуществ гибридной модели является то,
что ее «централизованность» или «распределенность» может лежать в диапазоне от 0 до
100 процентов, и её легко корректировать с течением времени, по мере изменения
требований, моделей работы и технологических ограничений. Напротив, в
централизованной модели данные, которые находятся не в центральном хранилище,
никогда не могут быть доступны, а в федеративной модели данные не могут быть
получены без отправки запроса на соответствующий узел в реальном времени.
Гибридная модель позволяет реализовать гибкий подход, при котором отдельные
категории (и степень детализации) часто требуемых данных могут храниться
централизованно, с целью обеспечения быстрого и надежного доступа к информации из
единого хранилища, а более подробные данные, которые редко используются или имеют
большой объем, могут оставаться на исходных узлах, доступ к ним предоставляется в
случае необходимости. В зависимости от того, где хранятся данные, качественные
характеристики служб (доступность, скорость доступа) могут изменяться, что часто
побуждает принимать решения о том, какие данные необходимо хранить
централизованно, а какие распределенно.
Выбор решения для построения региональной информационной системы
«Флагман медицина»
При выборе архитектуры и топологии РИС необходимо рассмотреть требования,
предъявляемые к технологическому функционированию информационной системы.
Требования, предъявляемые к функционированию РИС
К системе предъявляются следующие требования:
Страница 15
Построение региональной системы электронных медицинских карт
1.
2.
3.
4.
5.
Отказоустойчивость. Система не должна выходить из строя при отказе одного
из ее узлов. Либо время простоя должно быть минимизировано.
Скорость получения данных. Скорость сбора и получения информации не
должна находиться в сильной зависимости от качества каналов передачи
данных.
Минимизация затрат на инфраструктуру. К инфраструктуре (каналам передачи
данных, аппаратном обеспечении серверов и компьютеров) не должны
предъявляется завышенные требования, выполнение которых повлечет
применение ресурсов, находящихся на пике современных технологий.
Масштабируемость. Система должна быль легко масштабируема при
значительном изменении количества пользователей и контрагентов, с ней
работающих.
Устойчивость к изменениям. При любых, даже значительных, изменениях
методологических требований система должна
иметь
возможность
подстраиваться под них без переделки архитектуры и топологии.
Единого стандарта на принятия того или иного способа хранения не существует и выбор
решения зависит от многих факторов.
В данном решении предлагается использовать гибридную модель, с преимущественным
хранением данных в ЦОД. Основным способом взаимодействия с системой является
доступ через WЕB интерфейс. Данный способ выбран как наиболее перспективный и
имеющий ряд преимуществ, а именно:





Низкие затраты на внедрение системы. Фактически необходимо только обучать
персонал без установки на локальных серверах специфического ПО
Отсутствие необходимости устанавливать в каждом ЛПУ выделенный сервер
приложений. Данное преимущество позволяет снизить требования к
квалификации ИТ персонала в ЛПУ.
Низкие требования к сетевой инфраструктуре учреждений. Необязательно
объединять все здания одного ЛПУ в единую сеть, а достаточно подведенного к
каждому здания интернета.
Легкость обновления системы. При выпуске обновления программного
обеспечения замена исполняемых файлов происходит только в одном месте,
после чего они становятся доступными всем.
Масштабируемость. Решения на базе WEB технологий при соответствующем
проектировании подвергаются легкому масштабированию, что позволяет плавно
распределять нагрузку
Для крупных учреждений, которые уже имеют одну или несколько информационных
систем, предлагается воспользоваться преимуществами гибридной модели. Данные,
вводимые в локальную МИС, по определенным протоколам поступают в центральное
хранилище. Если определенные данные являются специфическими и не рассчитаны на
хранение в ЦОД, то они остаются на хранении в локальных ИС. В ЦОД лишь имеется
запись, что они находятся по определенному адресу и при необходимости получения этих
данных система сделает запрос к определенному серверу.
Таким образом при таком подходе с одной стороны получается полноценное центральной
хранилище с WEB доступом, с другой текущие информационные системы после
определенной доработки легко встраиваются в единое информационное пространство.
Страница 16
Построение региональной системы электронных медицинских карт
Топология с гибридной моделью отвечает всем требованиям, предъявляемым к РИС, а
именно:



При наличии нескольких мест хранения данных выход из строя одного из этих мест
не повлечет за собой отказ функционирования всей системы.
Распределенная модель хранения (как часть гибридной системы) снижает нагрузку
на каналы передачи данных и необходимость в их очень высоком качестве и
скорости отпадает.
Использование топологии с возможностью горизонтального масштабирования
снижает требования к аппаратному обеспечению конкретных серверов, а также
делает ее легко изменяемой при увеличении количества пользователей.
При использовании гибридной модели отношение данные находящиеся в центральном
сервере/данные находящиеся в узлах может легко меняться. Также может меняться и
характер информации, которая хранится в том или ином месте
Таким образом, гибридная модель является компромиссом между другими федеративной
и централизованной моделями. Данные, которые меняются не часто, и должны иметь
высокий уровень доступности, будут храниться в центральной части данной системы, в то
же время данные, которые либо имеют большой объем, либо служат для обеспечения
высокой степени подробности и детальности, могут храниться в конечных узлах и
предоставляться пользователю по запросу ИС.
Когда пользователь редактирует необходимые данные, при их сохранении в индексной
базе ставится отметка о том, что необходимая часть информации находится в локальной
ИС этого пользователя.
Помимо этого, использование данной модели позволит более гибко распределить
нагрузку на каналы связи, уменьшить нагрузку на канал к ЦХ.
Выбор технологий при построении подобной системы
Построение подобной топологии системы не завязано на конкретные продукты и
аппаратные решения и может быть реализовано на множестве технологий, в том числе и
использованием свободного и открытого программного обеспечения.
Рекомендуется
при построении данной архитектуры использовать следующие
программные продукты, как наиболее оптимальные по соотношению цена/качество:


Серверные операционные системы: Microsoft Windows 2008 R2
Серверы БД: Microsoft SQL Server 2008 R2
Выбор данных программных продуктов основывается на следующих соображениях:
Высокое качество и поддержка данных продуктов
Постоянное их развитие и улучшение
Высокая отказоустойчивость и производительность
Наличие успешного опыта эксплуатации подобных систем
Небольшая стоимость поддержки и большое количество
специалистов
6. Легкость освоения.
1.
2.
3.
4.
5.
необходимых
Страница 17
Построение региональной системы электронных медицинских карт
Принципы функционирования ЭМК
Любой врач, допущенный
к использованию создаваемого информационного
ресурса, может с помощью специальной программы либо посредством интернетбраузера подключиться к нему через интернет, используя полученные при регистрации
учетные данные (логин и пароль). После подключения врач может производить поиск
пациента по серии-номеру полиса, и просматривать информацию о предыдущих
посещениях пациента, установленных ему диагнозах, результатах анализов и
исследований, что поможет быстрее и точнее произвести диагностик, поставить текущий
диагноз и назначить лечение. В результате повысится качество лечения пациентов.
Для базового наполнения банка данных предлагается использовать информацию из
ежемесячных реестров ОМС, сдаваемых всеми ЛПУ в страховые компании, а затем в
территориальный фонд ОМС. Изначально необходимо будет произвести загрузку из
реестров за максимально доступный временной интервал (в идеале 10 лет или более).
В дальнейшем, по мере внедрения локальных ИС в ЛПУ, будет организован
двусторонний обмен медицинской информацией между ЛПУ и Центральным хранилищем
данных. Помимо информации о амбулаторных посещениях и стационарном лечении, в
ЭМК будут добавлена информация об анализах и исследованиях пациентов (из ЛПУ или
специализированных лабораторно-диагностических центров).
Применение аналитических механизмов
Одной из основных целей построения региональных информационных систем является
предоставления возможностей получения сводных сравнительных данных, полученных
из различных источников(локальные базы единой региональной системы, сторонние
источники данных и т.д.) для принятия своевременного управленческого решения. В
нашем конкретном случае – это возможность сравнивать и анализировать одинаковые
показатели из разных ЛПУ. На уровне региональной системы большая часть отчетов
предназначается для проведения количественного и сравнительного анализа
объединенных (сгруппированных по какому либо признаку) данных. Основным
ограничением такого анализа при способе построения с изолированными базами
является отсутствие возможности объединения данных ввиду децентрализованного
ведения нормативно-справочной информации.
Целью данного раздела является описание организации центрального хранилища данных
и использования аналитических механизмов доступа к данным для повышения
эффективности контроля над деятельностью лечебных учреждений.
Здесь предоставлено общее описание системы с центральным хранилищем данных
(ЦХД, ХД), обобщенная структура данных ЦХД, приведено описание преимуществ
использование OLAP отчетности и предоставлены примеры нерегламентированных
отчетов и способов их использования.
Нерегламентированная отчетность
Отчетность, которая может быть получена из региональной системы текущей структуры
можно
разделить
на
два
типа:
регламентированную
и
аналитическую
(нерегламентированную, OLAP и т.д.). К регламентированной относится отчетность
утвержденной формы, представляющая в основной своей массе один «срез»
информации и заключенная в форму, пригодную для печати.
Страница 18
Построение региональной системы электронных медицинских карт
Аналитическая отчетность представляет из себя особым образом подготовленную
информацию из хранилища данных, сама по себе которая не предназначена для
отображения. В общепринятой терминологии это называется «кубом». В куб заключена
заранее просчитанная и агрегированная информация, которая по желанию пользователя
может быть просмотрена в любых возможных «разрезах». Причем сочетание этих
«разрезов» может быть также произвольным, что позволяет гибко оценивать хранящиеся
данные.
К основным возможностям аналитических кубов можно отнести следующее:




Возможность объединения данных из гетерогенных источников
Просмотр и анализ данных по различным аспектам и «разрезам», при этом
возможность их сравнения по одному или нескольким параметрам.
Возможность автоматического анализа «тренда» некоторого критического
параметра, законы изменения которого заранее определены
Возможность «предсказания» значения некоторого параметра. Этот механизм, по
имеющемуся массиву данных и указанным зависимостям может с определенной
вероятностью предсказать его значения на определенный промежуток времени.
Преимущества использования нерегламентированной отчетности
Для проведения сравнения и анализа некоторого факта
в регламентированной
отчетности требуется запускать большое количество отчетов с различными параметрами.
Изменения некоторого требования в отчете приводит к тому, что необходимо
переделывать существующие отчеты или дописывать новые. Все это может привести к
так называемому «отчетному взрыву», когда количество отчетов возрастает настолько,
что их адекватное восприятие становится затруднительным – т.к. различные версии
одного и того же отчета могут показывать различные данные. OLAP отчетность лишена
такого недостатка. «Кубы» хранят в себе агрегированные данные в единственном
экземпляре, а вот отображения этих данных может происходить как угодно и в запуске
большого количества отчетов нет никакой необходимости. Кроме того небольшие
изменения в требованиях к подаче информации не приводит к изменения самого куба и
может быть выполнена самим пользователем самостоятельно. Если же требования
изменились настолько, что требуется изменения куба (например добавились новые
«размерности» отчета), то это выполняется один раз в описании куба.
Резюмируя, можно выделить следующие преимущества:




Независимость от средств визуализации
Возможность гибко менять «срезы» информации, уровень их детализации и т.д.
Централизованное редактирование отчетов, в случае изменений требований.
Возможность компактного отображения для улучшения восприятия
Этапы разработки и внедрения региональной системы
Для эффективной реализации проекта по созданию региональной информационной
системы необходимо разделить его на определенные этапы, каждый из которых должен
выделяться в самостоятельный проект с контролем сроков исполнения и ответственными
лицами. При реализации каждого из этапа необходимо должным образом производить
оформление соответствующей документации.
Обобщенно проект можно разбить на следующие этапы:
Страница 19
Построение региональной системы электронных медицинских карт





Этап 1. Запуск пилотного проекта по внедрению ЭМК. Создается центральное
хранилище данных, производится первоначальная загрузка данных о пациентах.
Результаты этапа:
o Врачи, подключенные к системе, могут получить подробную информацию о
прошлых обращениях любого пациента в любое ЛПУ.
o Доступно формирование сводной отчетности по обращаемости и
заболеваемости в масштабе региона
o Из
пилотных
ЛПУ
возможно
автоматизированное
получение
персонифицированной информации об оказанном лечении
Фактом завершения этапа является завершение внедрения ИС во всех пилотных
учреждениях, а также завершение создания инструмента для получения сводной
отчетности.
Этап 2. Создание единого интернет-портала МЗ региона, на котором пациенты и
врачи смогут получить полную информацию о врачах и ЛПУ региона, а также
другую медицинскую информацию, полезную для них
Результаты этапа:
o Улучшение информированности пациентов о деятельности ЛПУ и
доступности специалистов,
o Получение врачами полезной для них медицинской информации о новых
методах лечения, лекарственных средствах и т.п.
Фактом завершения этапа служит окончание создания и базового
информационного наполнения интернет-портала.
Этап 3. Запуск записи на прием к врачам через интернет-портал.
Результаты этапа:
o пациенты получат возможность удаленно записываться к нужным им
врачам на удобное для них время
o Сократятся очереди в регистратуре, повысится качество обслуживания
o Будет автоматизирован процесс получения информации о записи
пациентов также и внутри ЛПУ, подключенных к РИС
Фактом завершения этапа служит завершение создания раздела портала для
предварительной записи, а также получение специализированной отчетности о
произведенной записи посредством созданного портала.
Этап 4. Добавление на интернет-портал дополнительного закрытого раздела для
формирования регламентированной и сводной аналитической отчетности по
деятельности медицинских учреждений региона.
Результаты этапа:
o Получение полного набора сводной статистической отчетности как по
отдельному ЛПУ, так и в масштабах региона
o Получение сводной аналитической отчетности, на основании которой
возможно принятие управленческих решений в масштабах региона.
Фактом завершения этапа служит завершение создания раздела сайта и
получение требуемой отчетности.
Этап 5. Расширение списка ЛПУ, подключенных к РИС. Должно быть охвачены все
ЛПУ поликлинического и стационарного профиля.
Результаты этапа:
o Все
врачи поучают доступ к информации из регионального
информационного ресурса
o Информация в ЭМК становится полной, так как все ЛПУ теперь работают в
системе
Страница 20
Построение региональной системы электронных медицинских карт
Сводная аналитическая отчетность становится более точной
Список ЛПУ, в которых доступна предварительная запись через интернет,
становится всеобъемлющим по всему региону.
o Полное автоматизированное получение информации об оказанном лечении
в масштабе региона
Фактом завершения этапа является завершение внедрения ИС во всех ЛПУ
региона.
Этап 6. Подключение к РИС диагностических и лабораторных ЛПУ, внедрение
механизмов для обмена информацией о результатах анализов и исследований
между этими ЛПУ и центральным хранилищем.
Результаты этапа:
o Информация в ЭМК станет более полной за счет добавления информации
об анализах и исследованиях.
o Станет доступна сводная информация о производимых в регионе анализах
и исследованиях
Фактом завершения этапа является завершение подключения диагностических и
лабораторных ЛПУ и получение отчетов об анализах и исследованиях из РИС.
Этап 7. Внедрение телемедицины во всех ЛПУ региона.
Результаты этапа:
o Возможность
проводить
консультирование
высококлассными
специалистами других врачей
o Повышение качества лечения пациентов в регионе в целом.
Фактом завершения этапа служит запуск сервиса видео-аудио конференций на
базе интернет-портала РИС.
Этап 8. Запуск электронного документооборота на базе интернет-портала МЗ
региона для обеспечения оперативного обмена документами в едином
информационном пространстве.
Результаты этапа:
o Оперативный обмен документами между субъектами информатизации
региона
o Возможность оперативного информирования о новых нормативных актах.
Фактом завершения этапа является подключение всех субъектов автоматизации
региона к единому порталу документооборота.
o
o



Страница 21
Построение региональной системы электронных медицинских карт
ЧАСТЬ 2
ТЕХНИЧЕСКОЕ ОПИСАНИЕ
Страница 22
Построение региональной системы электронных медицинских карт
Анализ функциональных требований
При реализации данного регионального проекта выдвигаются следующие требования:


Система должна функционировать в рамках единого информационного
пространства
Должны обеспечиваться все функции, описанные в документе «Построение
региональной информационной системы здравоохранения»
Требования к технологическим стандартам
При функционировании информационной системы должны обеспечиваться следующие
технологические стандарты:
№
Методика или технология
Технологический стандарт
1.
Электронный документооборот
XML, HL7
2.
Унифицированный обмен информацией между ЛПУ
XML, HL7
3.
Интегрированный обмен с диагностическим оборудованием
DICOM
4.
Защищенные каналы связи и/или защищенные данные
VPN
Таблица 1 Выполнение технологических стандартов
Обязательные поддерживаемые методики и технологии:
№
Методика или технология
Источник
требований
1.
Электронная медицинская карта
ГОСТ Р 52636-2006
2.
Защита персональных данных по ФЗ 152 в соответствии с
методическими рекомендациями Минздрава РФ
ФЗ 152
Таблица 2 Поддерживаемые технологии
Анализ технических требований
При расчете технической составляющей принималось во внимание выполнение
следующих технических требований:






Отказоустойчивость
Скорость получения данных
Избыточность
Масштабируемость
Устойчивость к изменениям
Защищенность
Отказоустойчивость.
В Таблица 3 указано максимальное допустимое время простоя системы при отказе тех
или иных узлов.
№
Наименование узла
Время
1.
Отказ сервера центрального хранилища
0.5 ч
2.
Выход из строя БД центрального хранилища
0.5 ч
Страница 23
Построение региональной системы электронных медицинских карт
3.
Полное уничтожение серверов центрального хранилища в результате
стихийного бедствия или других причин
2ч
4.
Выход из строя сервера управления и/или повреждения его базы
0.5 ч
5.
Выход из строя медиа-серверов
0
ч
простоя
системы в целом,
должен
только
ограничиться
доступ к медиаданным. Время
восстановления
доступа к данным
1 час.
6.
Выход из строя WEB сервера
0.5 ч простоя
системы в целом.
7.
Выход из строя БД и/или сервера ЛПУ(при наличии в ЛПУ отдельной ИС)
0
ч
простоя
системы в целом.
Таблица 3. Требования к отказоустойчивости
Архитектура системы должна предусматривать возможность восстановления после
уничтожения основного серверного помещения в результате стихийного бедствия.
Скорость получения данных
Скорость сбора и получения информации не должна выдвигать специфических
требований к оборудованию.
В Таблица 4 указаны параметры получения необходимой информации в системе по
основным характеристикам.
№
Характеристика
Максимальное
время
1.
Поиск пациента
5 сек
2.
Открытие основной медицинской карты пациента
10 сек
3.
Загрузка полной медицинской карты пациента(без телемедицинских данных)
30 сек
4.
Загрузка информации по выданным лекарствам
30 сек
5.
Открытие одного осмотра пациента
10 сек
6.
Поиск врача пациентом в системе записи на прием
5 сек
7.
Получение (ежедневной) отчетности
5 мин
8.
Получение сводного отчета
10 мин
9.
Получение аналитических срезов
1 мин/срез
Таблица 4. Временные характеристики доступа к информации
Страница 24
Построение региональной системы электронных медицинских карт
Обеспечение адекватной пропускной способности для обработки при максимальной
загрузке в рамках допустимой целевой производительности является критически
важным фактором успешного внедрения служб электронного здравоохранения. Любые
сбои, например, задержки или недоступность службы в период пиковой загрузки могут
вызывать большое замешательство, подорвать доверие общественности к услугам и
отрицательно повлиять на ключевые стимулы к использованию электронных служб
— способность осуществлять электронное взаимодействие быстрее и проще, чем при
использовании традиционных каналов.
Избыточность
Система должна продолжить нормальное функционирование при превышении заданных
параметров (количества контрагентов и пользователей, работающих с ней) в два раза.
Масштабируемость
Система должна быть спроектирована с учетом возможности горизонтального
масштабирования для недопущения низкой производительности и своевременной
реакции на изменение входных условий.
Устойчивость к изменениям
При любых, даже значительных, изменениях методологических требований система
должна иметь возможность подстраиваться под них без переделки архитектуры и
топологии.
Защищенность
Система должна отвечать всем современным требованиям
безопасности, действующему Российскому законодательству и
стандартам в плане безопасности.
информационной
государственным
Архитектура и топология системы
Общая топология системы представлена на Рисунок 67
Общее описание
При построении информационной системы была выбрана WEB ориентированная модель.
В ЦОД развернуто центральное хранилище данных, в которых собираются данные о
пациентах из все ЛПУ. Пользователи, пользуясь специальным веб-приложением,
работают с ЭМК пациента в режиме просмотра и редактирования.
Данная модель имеет ряд преимуществ, а именно:


Кроссплатформенность. На рабочих местах может быть установлено любая
операционная система, важно лишь иметь современный браузер
Легкость установки и разворачивания рабочего места, что позволит удешевить
внедрение
Кроме того, для подключения к системе существующих в ЛПУ локальных
информационных систем, в структуру введен специальный сервер, который на основе
разработанных протоколов обмена забирает данные из локальных систем и загружает их
в центральное хранилище, т.е. разработана так называемая «гибридная модель».
Гибридная модель имеет как централизованное хранилище, так и механизм для
получения данных от участвующих узлов «по запросу». Гибридная модель позволяет
реализовать гибкий подход, при котором отдельные категории (и степень детализации)
Страница 25
Построение региональной системы электронных медицинских карт
часто требуемых данных могут храниться централизованно, с целью обеспечения
быстрого и надежного доступа к информации из единого хранилища, а более подробные
данные( которые редко используются или специфичны для данного ЛПУ) могут
оставаться на исходных узлах, доступ к ним предоставляется в случае необходимости.
Рисунок 6. Архитектура и топология системы
Общее функционирование системы
Основой функционирования является центральное хранилище данных, в котором
сохраняются данные о пациентах всего региона. Основным методом доступа к данным
системы является WEB доступ, предоставляющий возможности поиска ЭМК пациента, ее
открытие, редактирование, внос анализов и их результатов. В дальнейшем планируется
организация ведения персонифицированного учета на основе веб-технологий.
Пользователи в ЛПУ ведут ежедневную работу, пользуясь веб-приложением, и вносят
данные непосредственно в ЦОД. Внесенные данные, становятся сразу доступными всем
пользователям системы, которые имеют соответствующие полномочия.
Региональные пользователи, пользуясь доступом через WEB портал и авторизуясь в
системе, получают доступ к информационным ресурсам, сводным и подробным отчетам и
т.д. Имеют возможность размещать документы в рамках своих полномочий, имеют
возможность оформлять подписки на отчеты, которые будут приходить к ним на
электронную почту.
Страница 26
Построение региональной системы электронных медицинских карт
При наличии в ЛПУ функционирующей медицинской информационной системы
настраивается обмен данными между локальной ИС и ЦОД. Обмен данными происходит
по специальным протоколам, разработанными на основе стандартных протоколов обмена
и с учетом действующего законодательства. При использовании локальной ИС,
пользователи могут продолжать работать с ней, а обмен данными происходит
следующим образом:

При попытке получить доступ к определенной записи пациента система ищет эту
запись в локальной системе. Затем она опрашивает индексный сервер на предмет
наличия изменений по данному пациенту. Если изменений нет, то информация
подается пользователю. Если изменения есть, то по индексной базе система
находит, в каком месте находится новая информация, и подгружает ее из тех
источников.
Пользователи в локальных ИС ЛПУ ведут ежедневную работу по вносу данных, которые
сохраняются в локальных БД. Сервер управления ЦОД периодически опрашивает
локальные сервера ЛПУ на предмет появления новой информации и сохраняет знания о
ней в индексной базе. Кроме того информация предназначенная для хранения в ЦОДе
забирается из ЛПУ по специальным протоколам и сохраняется в хранилище данных.
Пользователи в ЛПУ, имеющие доступ к документообороту, также с помощью штатных
средств получают доступ к порталу для ознакомления с документами и распоряжениями.
Описание функциональных блоков
Центральное хранилище + OLAP сервер
Представляет собой отдельно выделенный сервер с хранилищем данных. На первом
этапе реализации этот сервер выступает основным хранилищем и поставщиком
информации. Данные реестров, получаемые любым способом
импортируются в
хранилище на периодической основе. Доступ к данным осуществляется двумя способами:
через web интерфейс и с помощью программных средств на клиент-серверной основе.
Данный сервер также выполняет функции сервера OLAP отчетов для удобного получения
различных срезов информации региональными пользователями.
WEB сервер приложений
WEB-сервер приложений предназначен для осуществления WEB доступа к данным
центрального хранилища рабочих мест, не имеющих в организации локальных ИС.
WEB сервер для документооборота
Выступает центральным порталом для организации системы документооборота.
Публичный WEB сервер
Данный сервер является основой для функционирования подсистемы «Электронная
регистратура» и запись пациентов на приём через сеть интернет. С целью защищенности
он отделен от внутреннего сервера ЦОДа.
Медиа-сервер
(сервера DICOM коммуникаций). На этом и последующих этапах будет использоваться
для хранения графического и видео контента. К данному серверу выдвигаются
требования по объему хранения и скорости получения доступа. При подключении
дальнейших поставщиков DICOM контента потребуются их горизонтальное наращивание.
Страница 27
Построение региональной системы электронных медицинских карт
VPN – сервера
Переназначены для организации виртуальной сети с использованием шифрования и
сертификатов для обеспечения конфиденциального доступа к данным. Данные сервера
используются при организации защищенной сети на основе программных решений.
Резервное хранилище данных
Зеркало центрального хранилища данных, индексного сервера и т.д. для выполнения
требования надежности и отказоустойчивости. Данные обновляются с помощью
механизма периодической репликации. Часть серверов находится в режиме «холодного»
резерва.
Индексный сервер управления
Центральный сервер управления данными информационной системы. Содержит в себе
«индекс» данных, который хранит в себе информацию о местоположении той или иной
информации при использовании в некоторых ЛПУ локальных информационных систем.
Он выполняет задачи по периодическому обновлению информации в центральном
хранилище из локальных БД.
Распределение информации
Как видно из описания топологии гетерогенной среды, предлагается разделять места
хранения различных типов информации в зависимости от ее структуры, объема и
требований к актуальности.
Предлагаемая структура распределения информации отображена в таблице:
Тип информации
Место хранения
Информация о диагнозах
Центральное хранилище
Информация о посещениях
Центральное хранилище
Информация
анализах
о
проведенных Центральное хранилище
Доп. Информация локальных ИС
Локальное хранилище
Таблица 5. Распределение информационных блоков
При использовании в ЛПУ локальных информационных систем данные, не попадающие в
указанные категории, хранятся на локальных серверах ЛПУ, доступ к ним
организовывается через описанный выше механизм.
В соответствии с этим разделением и рассчитывается нагрузка на узлы системы.
Обеспечение информационной безопасности системы
Вариант построения архитектуры информационных систем
Учитывая, что:
1.
2.
3.
4.
Система относится к ИСПДн первой категории (обработка медицинских данных)
Является распределённой
Объем, обрабатываемых субъектов ПД > 100 000
Наличие подключения к сетям
Страница 28
Построение региональной системы электронных медицинских карт
системе присваивается класс K1 и выдвигаются соответствующие требования к
построению архитектуры. В частности, передача данных должна осуществляться по
защищенным каналам связи, защита которых должна быть организована
сертифицированными СКЗИ.
При организации данной системы предполагается большое число субъектов, работающих
с данной ИСПДн. Поэтому необходимо решение, которое позволит реализовать все
требования защиты данных и в тоже время не потребует наличия специфического и
дорогостоящего оборудования.
Решение на основе программного комплекса VipNet.
Одним из таких решений является комплекс программного обеспечения VipNet,
компоненты которого прошли все необходимые сертификации и могут быть
рекомендованы в качестве основы для построения защищенных распределенных систем.
Т.к. общее число рабочих мест в системе большое, то установка на каждое рабочее
место VipNet клиента нецелесообразно виду большой нагрузки на координирующий
сервер системы и небольшого числа поддерживаемых клиентских ОС(только линейка
Windows).
Предлагается решение, при котором внутри ЛПУ установлен крипто-шлюз, через который
и будет проходить весь трафик. Крипто-шлюз выступает в роли туннеля шифрующего и
дешифрующего данные. В ЦОД установлен сервер-координатор, который является
главным регулирующим и шифрующим сервером системы.
Упрощенно схема представлена на Рисунок 78
Рисунок 7. Организация защищенных каналов на базе системы VipNet
Решение на основе системы «Континент»
Другим решением, позволяющим удовлетворить потребности в организации защищенной
сети, является программно-аппаратный комплекс «Континент». Комплекс «Континент»
является средством построения виртуальных частных сетей (VPN) на основе глобальных
сетей общего пользования, использующих протоколы семейства TCP/IP.
Страница 29
Построение региональной системы электронных медицинских карт
Основой функционирования является аппаратный комплекс, который выполняет роль
шифрующего шлюза, благодаря которому достигается объединение всех рабочих
станций в единое защищенное информационное пространство.
Схематично структура организации информационного пространства представлена на
рисунке.
Рисунок 8 Построение VPN на базе аппаратно-программного комплекса "Континент"
Определение требований к безопасности
При разработке физической структуры распределённой информационной системы
большое внимание необходимо уделять ее безопасности. В данном документе под
информационной безопасностью подразумевается такое состояние защищенной
информации, при котором обеспечивается ее конфиденциальность, целостность и
доступность.
1.
Конфиденциальность: свойство информационных ресурсов, в том числе информации,
связанное с тем, что они не станут доступными и не будут раскрыты для
неуполномоченных лиц.
2.
Целостность: неизменность информации в процессе ее передачи или хранения.
3.
Доступность:
определяющее
свойство
информационных
возможность
их
ресурсов,
получения
и
в
том
числе
использования
по
информации,
требованию
уполномоченных лиц.
Уровни доступа к информации. Ролевое разграничение.
Контроль доступа на основе ролей (популярный подход в большинстве информационных
систем) вполне применим и к сфере здравоохранения. Он позволяет определить права
на доступ на «логическом уровне» по отношению к «роли» и автоматически применить их
ко всем пользователям с этой ролью. Однако, если в большинстве других отраслей
Страница 30
Построение региональной системы электронных медицинских карт
привязка пользователей к ролям относительно постоянна, то в случае сферы
здравоохранения изменения будут иметь место значительно чаще.
В информационной системе такого уровня, когда в одном месте хранится различная
информация необходимо четко понимать и выделять различные уровни информационных
потоков, доступ к которым должен регулироваться выработанными политиками
безопасности.
Каждому пользователю системы в ней назначается определенная роль, в соответствии с
которой он и обладает определенными правами. Обобщенно предлагается выделить
количество ролей по числу субъектов информационной системы, а именно:
1) Правительство РФ.
2) Правительство региона.
3) Министерство здравоохранения и МИАЦ региона
4) Территориальный фонд ОМС региона.
5) Страховые компании.
6) ЛПУ.
7) Врачи.
8) Пациенты.
9) Средний, младший медицинский персонал и вспомогательные службы.
10) Разработчики специализированного ПО.
Все роли назначены исходя из полномочий субъекта и рамках информационной системы
и его функций. Подробное описание функций каждого субъекта выходит за рамки данного
документа.
Наименование
субъекта
Уровень доступа

1.
2.
3.
Правительство РФ


Правительство региона
Министерство
здравоохранения
МИАЦ региона


и


4.
Территориальный фонд
ОМС региона




5.
Страховые компании
6.
Руководство ЛПУ
7.
Врачи




Доступ к статической и обобщенной аналитической информации на
чтение. Доступ реализован через WEB интерфейс.
Доступ на чтение к региональному порталу документооборота.
Доступ к статической и обобщенной аналитической информации на
чтение. Доступ реализован через WEB интерфейс.
Доступ к региональному порталу документооборота на чтение и
размещения информации
Доступ к статической и обобщенной аналитической информации с
возможностью детализации до учреждения на чтение. Доступ
реализован через WEB интерфейс.
Доступ к региональному порталу документооборота на чтение и
размещения информации
Доступ к статической и обобщенной аналитической информации с
возможностью детализации до учреждения на чтение. Доступ к
финансовой информации в рамках ОМС.
Доступ на чтение к региональной информации о посещениях
пациентов всего в рамках ОМС и оказанных ему услугах
Доступ на чтение к региональной информации о оказанном лечении,
выданных ему лекарств для контроля качества лечения.
Доступ реализован через WEB интерфейс.
Доступ на чтение к региональной информации о посещениях
пациентов и оказанным им услугам, имеющих полис данной
страховой компании
Доступ к финансовой информации об объемах финансирования в
рамках договоров, заключенных с данной страховой компанией как
по региону в целом, так и с детализацией до конкретного ЛПУ
Доступ на чтение ко всем данным своего ЛПУ
Доступ по запросу к открытой информации о пациенте на приеме
(чтение и запись).
Доступ к региональному порталу в рамках полномочий
Страница 31
Построение региональной системы электронных медицинских карт
Пациенты
8.
Средний,
младший
медицинский персонал
и
вспомогательные
службы
Разработчики
специализированного
ПО
Технический специалист
по
сопровождению
компьютерной техники
9.
10.
11.
Администратор БД
12.


Доступ к информации о занятости врачей, расписанию.
Возможность записи на прием.

Доступ к разрешенным данным по пациенту для ввода информации
в рамках своего подразделения в ЛПУ


Доступ к информационным ресурсам портала, описывающих
функционирование информационной системы.
Доступ к любой персонализированной информации закрыт

Доступ к информации закрыт

Администратор БД в силу своих производственных обязанностей
имеет самые сильные полномочия в системе и поэтому его
деятельность должна строго регламентироваться.
Таблица 6 Ролевое разграничение
Правила доступа в чрезвычайных ситуациях
Особенным требованием является обеспечение возможности «игнорирования»
ограничений на доступ в чрезвычайных ситуациях, предполагающей доступ к
информации пациента, независимо от ролей и применимых правил доступа, если такой
доступ представляется необходимым работнику здравоохранения. Как правило, такая
возможность касается ситуаций, в которых под угрозой находится жизнь пациента, когда
быстрый и легкий доступ к информации крайне необходим. В то же время
предоставление такой функциональности может открыть возможности для
несанкционированного использования данных (например, использование «чрезвычайного
доступа» в режиме обычной работы просто потому, что сделать так будет проще, чем
следовать стандартным процедурам). Такой доступ предполагает протоколирование
всех действий пользователя на период получения прав «супер пользователя»
Системы идентификации и аутентификации
Доступ к системе и назначение пользователю ролей осуществляется только после его
идентификации. Уровней систем авторизации в системе предполагается несколько:



Уровень ЛПУ. На данном уровне происходит авторизация и получения доступа к
соответствующим ресурсам локального сервера. Права, полученные на этом
этапе, открывают пользователю доступ в соответствии с его ролью в локальной
системе и не распространяются на региональный уровень
Региональный уровень. На данном уровне авторизуются пользователи, которым
необходим доступ к региональным ресурсам (руководство министерств и ТФОМС,
страховые организации и т.д.)
Сервера информационной системы за счет определенного алгоритма могут иметь
доступ, как к региональным ресурсам, так и к локальным. За счет этого и
осуществляется интеграция систем авторизации различного уровня.
Примечание. Возможно построения системы аутентификации с единым
центром.
Задачи необходимые для выполнения требований информационной безопасности
При вводе в эксплуатацию данной системы и на протяжении всего жизненного цикла
должны выполняться определенные мероприятия с целью защиты информации от НСД.
На период разработки и ввода в эксплуатацию необходимо выполнить следующие задачи
1. Разработка политики безопасности, регламентирующей аспекты пользования и
доступа к информации, в частности включающей в себя:
1. Описание работ по обслуживанию БД администраторами
Страница 32
Построение региональной системы электронных медицинских карт
2. Создание инструкций по обеспечению резервного копирования
3. Создание инструкций на случай выхода из строя того или иного узла
системы
4. Порядок ввода нового пользователя
5. Определения политики использования паролей
6. Периодический инструктаж пользователей и администраторов системы на
предмет информационной безопасности
7. Периодическая аттестация сотрудников, обеспечивающих роботу
критических узлов системы.
8. Периодический аудит информационной безопасности.
2. Разработка модели угроз и принятие мер по предотвращению определенных в ней
атак.
Обеспечение доступности и отказоустойчивости
Отказоустойчивость и высокая доступность обеспечивается резервным копированием баз
данных и наличием резервного хранилища.
Резервное копирование
Для обеспечения сохранности данных хранилища необходимо разработать и внедрить
политику обслуживания баз данных, в частности проведение регулярного резервного
копирования данных.
Политика резервного копирования должно выбираться исходя их требований сохранности
информации и скорости резервного восстановления. Предлагается ввести следующий
порядок резервного копирования



Создание полной резервной копии БД один раз в сутки
Создание дифференцированной резервной копии каждые 6 часов
Создание резервной копии журнала транзакций каждые полчаса
Резервные копии первоначально должны сохраняться на локальное хранилище, затем
копироваться на другой дисковый массив и один раз в сутки копироваться на ленту и
переносить в другое помещение (для предотвращения потери в результате стихийных
бедствий).
Данная политика резервного копирования позволит оптимально использовать имеющиеся
ресурсы и минимизировать время восстановления, не затрагивая при таких сбоях
резервное хранилище данных.
Более подробный регламент резервного копирования необходимо разработать при вводе
системы в эксплуатацию.
Создание резервного хранилища данных
Описываемая
информационная
система
является
высоконагруженной,
функционирование которой должно быть в режиме 24/7, соответственно не допустим
полный выход из строя системы даже в результате уничтожения основного серверного
помещения. Для этого в систему введено резервное хранилище данных, которое
является полной копией основного хранилища, включающего в себя и центральное ХД и
копии баз управляющего сервера и медиа-серверов. В основное время оно работает в
режиме репликации всех баз данных. Там же находятся сервера холодного резерва,
Страница 33
Построение региональной системы электронных медицинских карт
которые при наступлении аварийного случая вводятся в строй. Расчетное время
восстановления системы 2 часа.
Реализация сетевой инфраструктуры
Общие сведения.
При доступе через WEB интерфейс работники ЛПУ подключаются с помощью браузера к
веб-серверу ЦОД, предварительно присоединившись к сети VPN
Процесс взаимодействия с сетью ЦОД
С доступом к VPN ЦОД
С использованием VPN организуется внутренняя сеть ЦОД. Такое техническое решение
позволит нам не опираться на физическое расположение основных и резервных
серверов, что в свою очередь позволит разнести их территориально и повысить
безопасность системы в целом.
Без доступа к VPN ЦОД:
Пациенты могут подключаться к системе без входа в сеть VPN, с помощью публичных
WEB серверов. Данные для публичных WEB серверов будут периодически поставляться
компонентами системы, и представлять собой ограниченную версию данных
находящихся в закрытых для публичного доступа хранилищах данных.
Расчет технических характеристик компонентов системы
Для расчета технических характеристик системы необходимо исходить из
предполагаемых объемов информации и количества объектов, с ней работающих. Кроме
того, для выполнения требований избыточности необходимо увеличивать данные
параметры в два раза.
Здесь и далее предполагается, что выбрано решение защиты сети на основе системы
VipNet.
Исходя из этого, примем для расчета следующие параметры.
Наименование параметра
Формула
-
B15
B16
B17
Кол-во жителей региона, чел.
Среднее число посещений на одного жителя в год, раз
Средний размер записи посещения в ЦХ, байт
Средний объем записи по пациенту, байт
Средний размер записи об анализах, байт
Общее число пользователей-врачей системы, чел.
Из них веб пользователей, чел.
Число объектов поставщиков информации, шт.
Примерный объем справочников, Мб
Среднее количество анализов на одного жителя, шт.
Средний размер измененных записей передаваемых из
ЛПУ за один сеанс, байт
Кол-во опросов учреждения в день, шт.
Среднее количество снимков на человека в год , шт.
Средний размер файлов снимка, Мб
B19
Объем дискового пространства ЦХ на 10 лет, Гб
B20
Количество одновременных подключений, шт.
Код
B4
B5
B6
B7
B8
B9
B10
B11
B12
B13
B14
=((B4*B5/365)/B15*B6)/B11
-
Значение
4000000
6
5000
10000
100
10000
5000
300
1000000
4
109589
10
1
5
=(B4*B5*B6*10+B4*B13*B8*10+
B4*B7)/1024/1024/1024
-
1184
10000
Страница 34
Построение региональной системы электронных медицинских карт
B21
B22
B23
B24
B25
B26
B25
B26
Число запросов к индексному серверу на данные в сек.,
шт.
Размер ответа на запрос, байт
Расчет входящего пропускного канала к зданию ЦОД, Мб
Средний размер ЭМК, Мб
Расчет исходящего канала
Кол-во документов в день, шт
Средний размер документа, Мб
=B4*B5/365/10/60/60
1,82
-
100000
≈2
=B21*B22*8/1024/1024
+
(B15*B11*B14*8/86400)/1024/12
04
максималный
-
2
1 Гб
10
5
Таблица 7. Числовые значения основных параметров для оценки планируемой мощности
Центральное хранилище
Расчет нагрузки на канал связи
Т.к. наличие центрального хранилища данных, web-сервера и индексного сервера
предполагается размещать на одной площадке и нагруженным на один канал связи, то
расчетная нагрузка на канал связи составляет из себя сумму значений следующих
параметров





Нагрузкой на WEB – сервер.
Объемом запросов и ответов к индексному серверу
Объемом передаваемых данных при «опросе» ЛПУ индексным сервером
Исходящий трафик по загрузке ЭМК на объекты (если имеется локальная МИС)
Получение отчетности
Т.к. основной метод получение информации – это WEB доступ, то расчет канала к ЦОД
необходимо осуществлять на основе анализа предполагаемой роботы веб-приложения.
Рассчитаем какую максимальную нагрузку может обеспечить выделенный канал со
скоростью 1 Гб/сек.
Пусть в среднем размер одного ответа на запрос пользователя составляет 500 Кб
(включая данные, картинки, скрипты, стили и т.д. что характерно для веб приложения
подобного класса ). Соответственно максимальной количество запросов, который
выдержит указанный канал связи рассчитывается по формуле:
=(канал связи (Гб)*1024/8)/(размер ответа)
и составляет примерно 250 запросов/сек. Это цифра является максимальной и при
реальной оценке должна быть уменьшена за счет постороннего трафика на 10 процентов.
Таким образом максимальной количество запросов со всех рабочих мест региона не
должно превышать 220 запросов в секунду. При проектировании веб приложении
необходимо максимально снижать нагрузку на канал связи(использовать кеширование
данных, динамические страницы и т.д.)
Уменьшение канала связи до меньших показателей становится нецелесообразным ввиду
большого количества рабочих мест.
Расчет процессорной нагрузки
Процессорная нагрузка определена по анализу загруженности процессора при
функционировании системы Флагман-Медицина в учреждениях с числом рабочих мест >
50 с интерполяцией на большее число пользователей, а также из анализа рекомендаций
ключевых производителей серверов:
Страница 35
Построение региональной системы электронных медицинских карт
http://www.dell.com/content/topics/global.aspx/tools/advisors/sql_advisor?c=us&cs=555&l=ru&s
=biz
Рекомендованная конфигурация: 2 х4 от 3 Гц(Intel или AMD)
Расчет оперативной памяти
Оперативная память рассчитывается исходя из количества подключений к серверу БД и
объемом требуемой памяти для непосредственного функционирования сервера БД по
рекомендации производителей серверов
http://www.dell.com/content/topics/global.aspx/tools/advisors/sql_advisor?c=us&cs=555&l=ru&s
=biz.
Расчет приведен в Таблица 8
№ Наименование параметра
1.
Кол-во
ОЗУ
соединение, Мб
2.
Объем памяти для БД
3.
на
Значение
одно 0,5
16000
Кол-во
Значение
10000
5000
1
16000
ИТОГО:
21000
4.
Таблица 8. Расчет оперативной памяти центрального хранилища
Расчет дискового пространства
Дисковое пространство оценивается на основе параметров приведенных в
Код
B4
B5
B6
B7
B8
B9
B10
B11
B12
B13
B14
B15
B16
B17
Наименование параметра
Формула
Кол-во жителей региона, чел.
Среднее число посещений на одного жителя в год, раз
Средний размер записи посещения в ЦХ, байт
Средний объем записи по пациенту, байт
Средний размер записи об анализах, байт
Общее число пользователей-врачей системы, чел.
Из них веб пользователей, чел.
Число объектов поставщиков информации, шт.
Примерный объем справочников, Мб
Среднее количество анализов на одного жителя, шт.
Средний размер измененных записей передаваемых из
ЛПУ за один сеанс, байт
Кол-во опросов учреждения в день, шт.
Среднее количество снимков на человека в год , шт.
Средний размер файлов снимка, Мб
=((B4*B5/365)/B15*B6)/B11
-
Значение
4000000
6
5000
10000
100
10000
5000
300
1000000
4
109589
10
1
5
-
B19
Объем дискового пространства ЦХ на 10 лет, Гб
B20
B21
Количество одновременных подключений, шт.
Число запросов к индексному серверу на данные в сек.,
шт.
Размер ответа на запрос, байт
Расчет входящего пропускного канала к зданию ЦОД, Мб
B22
B23
=(B4*B5*B6*10+B4*B13*B8*10+
B4*B7)/1024/1024/1024
=B4*B5/365/10/60/60
=B21*B22*8/1024/1024
+
(B15*B11*B14*8/86400)/1024/12
04
1184
10000
1,82
100000
≈2
Страница 36
Построение региональной системы электронных медицинских карт
B24
Средний размер ЭМК, Мб
максималный
B25
Расчет исходящего канала
B26
Кол-во документов в день, шт
B25
Средний размер документа, Мб
B26
Таблица 7, оценки мест хранения из Таблица 5 и складывается из
параметров:




2
1 Гб
10
5
следующих
Объемом информации о пациентах
Объем информации о диагнозах и посещениях пациента
Объем информации о анализах пациентов
Объемом справочников
Формула
расчета,
ссылающаяся
на
строки
=(B4*B5*B6*10+B4*B13*B8*10+B4*B7+B12)/1024/1024/1024
из
таблицы:
Значение, рассчитанное по этой формуле, составляет 1184 Гб. Таким образом, с учетом
избыточности объем необходимого дискового пространства составляет 1,5 Тб для
данных. Эквивалентный объем дискового пространства необходимо предусмотреть для
хранения резервных копий БД.
Внутренний WEB – сервер для приложения
При проектировании системы в общем и веб приложений в частности необходимо
заложить возможность горизонтального расширения т.е. увеличения количество вебсерверов, обслуживающих одно веб-приложение.
Расчет нагрузки на канал связи
Расчет приведен в описании ЦХ и составляет 1Гб/сек
Расчет процессорной нагрузки
Значение получено из конфигурации типичного выделенного веб-сервера, предлагаемого
поставщиками площадок. 2x4 от 2 Гц
Расчет оперативной памяти
Значение получено из конфигурации типичного выделенного веб-сервера, предлагаемого
поставщиками площадок. От 16 Гб.
Расчет дискового пространства
На веб сервер приложения в данной информационной системе не ложится критических
функций, требующих большого дискового пространства, т.к. данные пациентов физически
содержатся в другом хранилище.
Внутренний WEB – сервер документооборота
Расчет нагрузки на канал связи
Расчет приведен в описании ЦХ и составляет 1Гб/сек
Расчет процессорной нагрузки
Значение получено из конфигурации типичного выделенного веб-сервера, предлагаемого
поставщиками площадок. 2x4 от 2 Гц
Страница 37
Построение региональной системы электронных медицинских карт
Расчет оперативной памяти
Значение получено из конфигурации типичного выделенного веб-сервера, предлагаемого
поставщиками площадок. От 16 Гб.
Расчет дискового пространства
На веб сервер в данной информационной системе ложится функция хранилища
документов для системы документооборота, поэтому объем дискового пространства
стоит оценивать, исходя из среднего размера документа и их количеств. Расчет приведен
по следующей формуле из строк
Код
B4
B5
B6
B7
B8
B9
B10
B11
B12
B13
B14
B15
B16
B17
Наименование параметра
Формула
Кол-во жителей региона, чел.
Среднее число посещений на одного жителя в год, раз
Средний размер записи посещения в ЦХ, байт
Средний объем записи по пациенту, байт
Средний размер записи об анализах, байт
Общее число пользователей-врачей системы, чел.
Из них веб пользователей, чел.
Число объектов поставщиков информации, шт.
Примерный объем справочников, Мб
Среднее количество анализов на одного жителя, шт.
Средний размер измененных записей передаваемых из
ЛПУ за один сеанс, байт
Кол-во опросов учреждения в день, шт.
Среднее количество снимков на человека в год , шт.
Средний размер файлов снимка, Мб
=((B4*B5/365)/B15*B6)/B11
-
Значение
4000000
6
5000
10000
100
10000
5000
300
1000000
4
109589
10
1
5
-
B19
Объем дискового пространства ЦХ на 10 лет, Гб
B20
B21
Количество одновременных подключений, шт.
Число запросов к индексному серверу на данные в сек.,
шт.
Размер ответа на запрос, байт
Расчет входящего пропускного канала к зданию ЦОД, Мб
B22
B23
=(B4*B5*B6*10+B4*B13*B8*10+
B4*B7)/1024/1024/1024
=B4*B5/365/10/60/60
=B21*B22*8/1024/1024
+
(B15*B11*B14*8/86400)/1024/12
04
-
1184
10000
1,82
100000
≈2
B24
Средний размер ЭМК, Мб
2
максималный
B25
Расчет исходящего канала
1 Гб
B26
Кол-во документов в день, шт
10
B25
Средний размер документа, Мб
5
B26
Таблица 7 : =B26*B25*365*10/1024 и составляет, с учетом избыточности, 500 Гб.
Медиа-сервер
Расчет нагрузки на канал связи
Данный параметр является критичным для этого сервера, т.к. объем данных
передаваемых может быть большой.
Расчет строится на основе требований к скорости загрузки данных пациента, примерным
объемом одного снимка и количестве одновременно запрашиваемых данных.:
=((B4*B5/365)*B16*B17*8)/10/60/60
что, с учетом пиковых нагрузок результат составляет примерно 100 Мб/сек.
Страница 38
Построение региональной системы электронных медицинских карт
Примечание:
Т.к. нагрузка на канал данного сервера будет большой, то его
желательно разместить на отдельном канале связи, а также для равномерного
распределения лучше использовать несколько серверов.
Расчет процессорной нагрузки
Нагрузка на процессор данного сервера небольшая, т.к. он выступает в качестве
файлового хранилища.
Расчет оперативной памяти
Оперативной памяти необходимо такое количество, достаточное для нормального
функционирования сервера с учетом операционной системы
Расчет дискового пространства
Дисковое пространство вычисляется исходя из требований, указанных в документе
«Концепция создания информационной системы в здравоохранении на период до
2020 года» о сроке хранения графической информации и средним объемом снимков по
формуле: =B4*B16*B17/1024*10, что составляет примерно 10 Тб.
VPN-сервера
Расчет нагрузки на канал связи
Приведен в расчете на центральное хранилище и составляет 1 Гб/сек.
Расчет процессорной нагрузки
Процессорная нагрузка на VPN сервер достаточно высока, так как на нем происходит
шифрование. Анализ практик использования показал, что для заданных параметров
оптимально выделять отдельные VPN сервера на каждые 500-700 подключений.
Резервное хранилище данных
Резервное хранилище данных представляет собой копию конфигурации центрального
хранилища.
Индексный сервер управления
Сервер управления испытывает большой объем запросов в небольшие промежутки
времени и поэтому является критически важным узлом в плане быстродействия.
Оценка количества запросов на единицу времени приведена в
Код
B4
B5
B6
B7
B8
B9
B10
B11
B12
B13
B14
B15
B16
B17
Наименование параметра
Формула
Кол-во жителей региона, чел.
Среднее число посещений на одного жителя в год, раз
Средний размер записи посещения в ЦХ, байт
Средний объем записи по пациенту, байт
Средний размер записи об анализах, байт
Общее число пользователей-врачей системы, чел.
Из них веб пользователей, чел.
Число объектов поставщиков информации, шт.
Примерный объем справочников, Мб
Среднее количество анализов на одного жителя, шт.
Средний размер измененных записей передаваемых из
ЛПУ за один сеанс, байт
Кол-во опросов учреждения в день, шт.
Среднее количество снимков на человека в год , шт.
Средний размер файлов снимка, Мб
=((B4*B5/365)/B15*B6)/B11
-
Значение
4000000
6
5000
10000
100
10000
5000
300
1000000
4
109589
10
1
5
Страница 39
Построение региональной системы электронных медицинских карт
-
B19
Объем дискового пространства ЦХ на 10 лет, Гб
B20
B21
Количество одновременных подключений, шт.
Число запросов к индексному серверу на данные в сек.,
шт.
Размер ответа на запрос, байт
Расчет входящего пропускного канала к зданию ЦОД, Мб
B22
B23
B24
Средний размер ЭМК, Мб
B25
Расчет исходящего канала
B26
Кол-во документов в день, шт
B25
Средний размер документа, Мб
B26
Таблица 7
=(B4*B5*B6*10+B4*B13*B8*10+
B4*B7)/1024/1024/1024
=B4*B5/365/10/60/60
=B21*B22*8/1024/1024
+
(B15*B11*B14*8/86400)/1024/12
04
максималный
-
1184
10000
1,82
100000
≈2
2
1 Гб
10
5
Расчет нагрузки на канал связи
Приведено в расчете на центральное хранилище и составляет 1Гб/сек
Расчет процессорной нагрузки
Исходя из оценки количества запросов в минуту и числу пользователей рекомендуемая
конфигурация процессора 2х4 с возможностью расширение до 4х4.
Сервер крипто-шлюза в ЛПУ
Описание типичного сервера защиты приведено в приложении 1.
Оценка необходимого канала связи
Основным критерием оценки пропускной способности канала связи к ЛПУ является
количество рабочих мест, предполагаемых в данном ЛПУ. Необходимо учитывать
следующие показатели:



Среднее количество запросов информации (страниц веб приложения) при
осуществлении одного приема (процедура/анализа)(6 шт. за 10 мин).
Средний размер одного ответа(500 Кб)
Количество пользователей в ЛПУ
Формула расчета:
=(среднее количество
пользователей)*8)/1024
запросов
за
10
мин)/600*(размер
ответа
Кб)*(кол-во
Полный перечень ЛПУ с рекомендованным пропускным каналом находится
приложении 2
в
Требования к хранилищу данных
Дисковые массивы центрального хранилища должны быть выполнены в отдельных (от
серверов) аппаратных комплексах (SAS, FC) , обеспечивающих горячую замену и
наращивание дискового массива, а также прозрачную перестройки RAID массивов.
Требования к инженерной инфраструктуре ЦОД
Требование к построению помещения ЦОД изложены в документе «СН 512-78
Инструкция по проектированию зданий и помещений для электронно-вычислительных
машин» и продиктованы также соображениями безопасности и требованием
отказоустойчивости.
Страница 40
Построение региональной системы электронных медицинских карт
В частности доступ в здание ЦОД должен быть строго регламентированным, помещение
должно быть оборудовано резервными источниками питания, системой охлаждения и
пожаротушения, соответствующими принятым стандартам в отрасли, кроме того
необходимо обеспечить:










Высокий гарантируемый уровень доступности выделенного канала связи и интернет
соединения.
Наличие системы резервного копирования, соответствующей требованиям по уровню
сохранности данных и скорости их восстановления.
Наличие системы мониторинга аппаратно-программных средств (включая настройку,
диагностирование и оперативный контроль).
Круглосуточная квалифицированная техническая поддержка оборудования и систем.
Наличие средств обнаружения и противодействия сетевым вторжениям.
Наличие системы защиты от несанкционированного доступа во внутренние помещения
ЦОД.
Охрана внешнего периметра.
Электростатическая защита всего оборудования и пола.
Наличие резервированной системы кондиционирования и вентиляции.
Наличие системы обнаружения возгорания и газового пожаротушения.
Описание программных средств
В предлагаемой системе использован широкий набор программных
Представлено как коммерческое так свободное программное обеспечение.
средств.
СУБД
В качестве СУБД центрального хранилища выбран Microsoft SQL Server как наиболее
оптимальное решение для систем подобного масштаба. В качестве аргументов для
выбора данной системы послужило:





Наличие встроенных механизмов, поддерживающих доменную авторизацию
Возможность построение отказоустойчивых кластеров с автоматическим
восстановлением работоспособности
Наличие технических решений, ускоряющих доступ к
большому объему
информации (индексированные представления, разделение данных по файловым
группам и т.д)
Наличие мощного встроенного аналитического механизма для построения OLAP
кубов
Встроенный отчетный механизм
В менее нагруженных местах (веб сервера, документооборот) используются СУБД,
принадлежащие к классу СПО
Веб сервера
В качестве веб серверов используются сервера Apache 2.2.
Операционные системы
На серверах центрального хранилища и локальных серверов, где используется СУБД
Microsoft SQL Server, установлены редакции Windows Server 2008, на серверах,
отвечающих за работу сетевой инфраструктуры, установлена операционная система
FreeBSD .
Страница 41
Построение региональной системы электронных медицинских карт
В качестве операционной системы локальных рабочих мест выбрана ОС Ubuntu 10.04
LTS, с установленным компонентом Wine для запуска системы «Флагман-Медицина»
Специализированное ПО.
Система резервного копирования и восстановление для критических узлов:
Microsoft Data Protection Manager
Система управления ИТ инфраструктурой: System Center Configuration Manager,
предназначенный для систем на основе Microsoft Windows и смежных устройств.
Configuration Manager предоставляет такие основные возможности: управление
обновлениями, развёртывание ПО и операционных систем, инвентаризация аппаратного
и программного обеспечения, удалённое управление.
Учетная медицинская система: Программный комплекс «Флагман-медицина»,
включающий в себя подсистемы «Поликлиника», «Стационар», «Персонифицированный
учет» и т.д.
Антивирусная защита: Антивирус Касперского.
Система организации VPN и защиты данных: VipNet.
Подробный перечень программных средств перечислен в приложении 1.
Расчет штатной численности
Для
обеспечения
бесперебойного
функционирования
системы
квалифицированные кадры, работающие на постоянной основе, а именно:





необходимы
3 системных администратора, в функции которых входят обеспечение
непрерывной работы дата-центра, серверов, каналов связи и т.д., а также
обеспечение восстановление серверов при сбое.
3
системных
администратора
БД.
Обеспечивают
бесперебойное
функционирование
баз
данных
комплекса,
выполняют
периодическое
обслуживание БД, резервное копирование и т.д. Обеспечивают круглосуточное
дежурство внутри ЦОД.
Специалист по защите персональных данных. Роль данной штатной единицы
заключается в выполнении работ по организации процесса защиты персональных
данных, согласно закону № ФЗ-152 и получению лицензии на данный вид
деятельности, что существенно сэкономит затраты на выполнение требований
данного закона.
Специалист по информационной безопасности, в функции которого включены
постоянный мониторинг угроз безопасности, обучение и консультация
пользователей по вопросам, связанным с информационной безопасностью,
составление политик безопасности и т.д.
Для обслуживания БД ЛПУ требуется штатный специалист на месте, если
количество рабочих мест превышает 20. На небольшие учреждения можно
рассмотреть вариант с одним специалистом на 2-3 учреждения. В случае
использования системы System Center Configuration Manager следует рассмотреть
возможность удаленного управления серверами ЛПУ из ЦОДа. В случае
использования System Center Configuration Manager дополнительно необходимы в
штате ЦОДа администраторы БД 2-3 специалиста и старший администратор.
Страница 42
Построение региональной системы электронных медицинских карт
Проведение технического аудита
Технический аудит IT инфраструктуры представляет собой системный процесс,
состоящий в получении и оценке объективных данных о текущем состоянии IT систем
ЛПУ. Основными целями аудита IT являются проведение анализа информационной
инфраструктуры на соответствие требованиям подключения к единой информационной
системе.
Квалифицированное
и
своевременное
осуществление
аудита
IT
инфраструктуры, характеризуемое высоким качеством всех проводимых процессов, дает
гарантию надежного и эффективного функционирования элементов IT систем и всей
инфраструктуры в целом.
Объекты технического аудита
Для полноценного функционирования ЛПУ в рамках единой информационной системы
необходимо оценить ИТ-инфраструктуру по следующим объектам:








Рабочие станции. Оценивается производительность рабочих станций, объем
оперативной памяти и жесткого диска;
Серверное оборудование, задействованное в ИТ-инфраструктуре
предприятия. Оценивается его наличие, производительность, процент
загруженности текущими задачами
Физическая и логическая структура корпоративной локальной сети.
Активное сетевое оборудование. Оценивается метод доступа в сеть интернет,
размер пропускного канала.
Системное программное обеспечение. Описываются операционные системы,
установленные на рабочих станциях и серверах.
Периферийное оборудование. Оценивается количество принтеров.
Информационная безопасность серверов. Оценивается имеющиеся
программное обеспечение, предназначенное для защиты информации от НСД.
Наличие, принципы функционирования и возможности локальных
медицинских информационных систем. Исследуется наличие и функционал
имеющихся медицинских информационных систем.
Требования к объектам ИТ-инфраструктуры
В Таблица 99 приведены минимальные требования к объектам ИТ-инфраструктуры,
предназначенным
для
функционирования
в
рамках
единой
региональной
информационной системы.
Таблица 9. Минимальные требования к объектам
Наименование объекта
Рабочие станции
Параметр
Значение
Процессор
Pentium III 600 MHz
Оперативная память, Мб
256
Жесткий диск, Гб
4
Видеоадаптер и монитор
SVGA (800 x 600)
Устройства
пользователем
взаимодействия
с
клавиатура и мышь
Страница 43
Построение региональной системы электронных медицинских карт
Локальный сервер БД до 20
пользователей
Локальный сервер БД до 50
пользователей
Локальный сервер БД до 200
пользователей
Локальный сервер БД от 200
пользователей
Физическая и логическая
структура корпоративной
локальной сети
Процессор
1x2
Оперативная память, Гб
2
Жесткий диск, Гб
160
Процессор
1x4
Оперативная память, Гб
4
Жесткий диск, Гб
160
Процессор
1x4
Оперативная память, Гб
4-6
Жесткий диск, Гб
160
Процессор
2x4
Оперативная память, Гб
8
Жесткий диск, Гб
160
Все рабочие станции, предназначенные для работы в единой
региональной системе, при наличии в организации выделенного
сервера, должны иметь постоянное подключение по локальной сети
со скоростью не менее 100 Мб/сек между рабочей станцией и
сервером при организации прямого доступа. При терминальном
соединении между рабочей станцией и сервером необходимо
обеспечения канала связи не менее 1 Мбит/сек.
В случае территориального разнесения зданий
необходимо
соединение
между
ними
для
вышеназванных условий.
Активное сетевое
оборудование
Периферийное
оборудование
одного ЛПУ
выполнения
Оборудование, ответственное за соединение с сетью интернет
должно обеспечивать скорость не менее 2Мб/с (5 Мб/сек при
количестве активных пользователей больше 200)
шт.
см. таблицу 3
Системное программное
обеспечение
Рабочие станции –Ubuntu 10/ Windows XP, серверы – Windows 2003
Standart
Информационная
безопасность серверов
Серверы учреждения должны иметь установленное антивирусное
программное обеспечение. Серверы, предназначенные для
непосредственной работы в региональной ИС, должны иметь
установленное программное обеспечения для защиты от НСД
(межсетевые экраны) и организации сети VPN. Программное
обеспечение должно иметь необходимую сертификацию для работы
в рамках ИСПД.
Страница 44
Построение региональной системы электронных медицинских карт
В таблице 2 приведены рекомендуемые требования к объектам ИТ-инфраструктуры, для
полноценного функционирования в рамках единой информационной системы.
Таблица 10. Рекомендуемые требования к объектам
Наименование объекта
Рабочие станции
Параметр
Значение
Процессор
От 1,5 MHz
Оперативная память, Гб
1
Жесткий диск, Гб
80
Видеоадаптер и монитор
SVGA (1024 x 768)
Устройства
пользователем
Локальный сервер БД до 20
пользователей
Локальный сервер БД до 50
пользователей
Локальный сервер БД до 200
пользователей
Локальный сервер БД от 200
пользователей
Физическая и логическая
структура корпоративной
локальной сети
взаимодействия
с
клавиатура и мышь
Процессор
1x2
Оперативная память, Гб
2
Жесткий диск, Гб
160
Процессор
1x4
Оперативная память, Гб
4
Жесткий диск, Гб
160
Процессор
1x4
Оперативная память, Гб
4-6
Жесткий диск, Гб
160
Процессор
2x4
Оперативная память, Гб
8
Жесткий диск, Гб
160
Все рабочие станции, предназначенные для работы в единой
региональной системе, при наличии в организации выделенного
сервера, должны иметь постоянное подключение по локальной сети
со скоростью не менее 100 Мб/сек между рабочей станцией и
сервером при организации прямого доступа. При терминальном
соединении между рабочей станцией и сервером необходимо
обеспечения канала связи не менее 1 Мбит/сек.
В случае территориального разнесения зданий
необходимо
соединение
между
ними
для
вышеназванных условий.
Активное сетевое
оборудование
одного ЛПУ
выполнения
Оборудование, ответственное за соединение с сетью интернет
должно обеспечивать скорость не менее 2Мб/с (5 Мб/сек при
количестве активных пользователей больше 200)
Страница 45
Построение региональной системы электронных медицинских карт
Периферийное
оборудование
шт.
См. таблицу 3
Системное программное
обеспечение
Рабочие станции –Ubuntu 10/ Windows 7, серверы – Windows 2008
R2 Standart
Информационная
безопасность серверов
Серверы учреждения должны иметь установленное антивирусное
программное обеспечение. Серверы, предназначенные для
непосредственной работы в региональной ИС, должны иметь
установленное программное обеспечения для защиты от НСД
(межсетевые экраны) и организации сети VPN. Программное
обеспечение должно иметь необходимую сертификацию для работы
в рамках ИСПД.
Таблица 11. Количество принтеров
Подсистема
Количество принтеров
Электронная регистратура
1 принтер А4 на 1 рабочее место
Статистика
1 принтер А4 на 1 кабинет
Врач
ЭМК)
поликлиники(заполнение 1 принтер А4 на 1 кабинет
Персонифицированный учет
3 принтера на 1 отделение
Методика проведения аудита
В связи с небольшим количеством анализируемых объектов в каждом ЛПУ применение
автоматизированных средств анализа нецелесообразно. Для оценки параметров
существующей инфраструктуры достаточно визуального метода (объезд ЛПУ и осмотр
имеющийся в наличии техники и сетей). Аудит проводится либо силами самого
учреждения, либо силами подрядных организаций.
При оценки информационных систем, анализируются следующие показатели:





Количественный состав
Парк задействованных рабочих мест
Вид информационной системы (локальная/распределенная)
Возможность модернизации. Если да, то какими силами
разработчиков ПО)
Пересечение функционала с региональной системой
(своими
или
Итогом
анализа
информационных
систем
должно
стать
решение
о
возможности/невозможности интеграции ИС в единое информационное пространство
либо полный отказ от использования данной ИС и замене ее функционалом
региональной системы. Таблица результатов приведена в приложении 6.
Страница 46
Построение региональной системы электронных медицинских карт
Результаты проведение технического аудита
В результате проведения технического аудита создаются сводные таблицы проверок.
Кроме того к каждому случаю аудита должна прилагаться физическая схема и топология
локальной сети данного учреждения. На основе этих данных должны формироваться
технические задания на прокладку и модернизация локальной вычислительной сети и
планироваться закупки компьютерной техники. Данные таблицы описаны в приложениях
1, 2, 3.
В техническом задание на прокладку ЛВС должно быть указано количество
подключаемых рабочих станций, их расположение на плане здания, количество
межсетевого оборудования и т.д., а также прилагаться полная смета модернизации.
Монтаж сетей должен производиться согласно принятым российским и международным
стандартам.
Страница 47
Построение региональной системы электронных медицинских карт
Приложение 1. Таблица технических характеристик серверов
Центральное хранилище данных + OLAP сервер(основной + резерв)
Аппаратное обеспечение
Процессор
Оперативная память, Гб
Доступное дисковое пространство, Гб
Канал связи, Мб
Программное обеспечение
2х4 ядра
21
3000
20
Операционная система
Сервер базы данных
Программное обеспечение для VPN
Антивирусная защита
Дополнительное ПО
Примечание
Microsoft Windows 2008 R2
MSSQL Server 2008 R2 Enterprise Edition
DPM 2010, SQL Master Data Services
-
WEB сервер приложений (основной+резерв)
Аппаратное обеспечение
Процессор
Оперативная память, Гб
Доступное дисковое пространство, Гб
Канал связи, Мб
Программное обеспечение
Операционная система
Сервер базы данных
Программное обеспечение для VPN
Антивирусная защита
Дополнительное ПО
2х4 ядра
16
160
20
Free BSD 8.1
PgSql, Mysql
Apache 2.2 + система документооборота
WEB сервер документооборота (основной+резерв)
Аппаратное обеспечение
Процессор
Оперативная память, Гб
Доступное дисковое пространство, Гб
Канал связи, Мб
Программное обеспечение
Операционная система
Сервер базы данных
Программное обеспечение для VPN
Антивирусная защита
Дополнительное ПО
2х4 ядра
16
160
20
Free BSD 8.1
PgSql, Mysql
Apache 2.2 + система документооборота
VPN сервер на каждые 500 подключений
Аппаратное обеспечение
Процессор
Оперативная память, Гб
Доступное дисковое пространство, Гб
Канал связи, Мб
Программное обеспечение
2х4
4
160
20
Страница 48
Построение региональной системы электронных медицинских карт
Операционная система
Сервер базы данных
Программное обеспечение для VPN
Антивирусная защита
Дополнительное ПО
Free BSD 8.1
mpd, IPSec
-
Сервер индексов(управления)(основной + резерв)
Аппаратное обеспечение
Процессор
Оперативная память, Гб
Доступное дисковое пространство, Гб
Канал связи, Мб
Программное обеспечение
Операционная система
Сервер базы данных
Программное обеспечение для VPN
Антивирусная защита
Дополнительное ПО
2x4 с возможностью расширения
16
2000
20
Microsoft Windows 2008 R2
MSSQL Server 2008 R2 Enterprise Edition
Разработанная служба индексов и управления
Медиасервер(основной+резерв)
Аппаратное обеспечение
Процессор
Оперативная память, Гб
Доступное дисковое пространство, Гб
Канал связи, Мб
Программное обеспечение
Операционная система
Сервер базы данных
Программное обеспечение для VPN
Антивирусная защита
Дополнительное ПО
2х4
8
5000
100
FreeBSD
PgSQL
Служба передачи данных по защищенному
каналу
Сервер крипто-защиты ЦОД
Аппаратное обеспечение
Процессор
Оперативная память, Гб
Доступное дисковое пространство, Гб
Канал связи, Гб/сек
Программное обеспечение
Операционная система
Сервер базы данных
Программное обеспечение для VPN
Антивирусная защита
Дополнительное ПО
2х2
8
160
1
Microsoft Windows Standart 2008 R2
ViPNet Administrator, ViPNet StateWatcher
Сервер крипто-защиты ЛПУ
Аппаратное обеспечение
Процессор
Оперативная память, Гб
Доступное дисковое пространство, Гб
Канал связи, Мб
Программное обеспечение
1х2
4
160
Зависит от кол-ва пользователей
Страница 49
Построение региональной системы электронных медицинских карт
Операционная система
Сервер базы данных
Программное обеспечение для VPN
Антивирусная защита
Дополнительное ПО
Рабочее место
сервером
с
ОС Linux с ядрами 2.4.2/31-2.6.2/32
ViPNet Coordinator
Антивирус Касперского
Компоненты системы "Флагман-медицина"
локальным
Аппаратное обеспечение
Процессор
Оперативная память, Гб
Доступное дисковое пространство, Гб
Канал связи, Мб
Программное обеспечение
Операционная система
Сервер базы данных
Программное обеспечение для VPN
Антивирусная защита
Дополнительное ПО
1x1/1x2
2
160
Локальная сеть
Ubuntu 10
Wine+Система "Флагман-Медицина"
Рабочее место с WEB доступом
Аппаратное обеспечение
Процессор
Оперативная память, Гб
Доступное дисковое пространство, Гб
Канал связи, Мб
Программное обеспечение
Операционная система
Сервер базы данных
Программное обеспечение для VPN
Антивирусная защита
Дополнительное ПО
1x1/1x2
2
160
2
Ubuntu 10
Встроенные компоненты
Web браузер
Публичный WEB сервер
Аппаратное обеспечение
Процессор
Оперативная память, Гб
Доступное дисковое пространство, Гб
Канал связи, Мб
Программное обеспечение
Операционная система
Сервер базы данных
Программное обеспечение для VPN
Антивирусная защита
Дополнительное ПО
1х4 ядра
16
160
10
Free BSD 8.1
PgSql, Mysql
Apache 2.2
Страница 50
Построение региональной системы электронных медицинских карт
Приложение 2. Рекомендуемые требования к каналам связи
Количество одновременно работающих пользователей
От 1 до 10
От 10 до 50
От 50 до 100
От 100 до 200
От 200
Минимальный
канал связи,
Мб
1
4
8
10
20
Приложение 3
Таблица соответствий объектов аудита требованиям
Наименование объекта
Количество
объектов,
всего
Количество
объектов,
удовлетворяю
щих
минимальным
требованиям
Количество
объектов,
удовлетворяю
щих
рекомендуемы
м требованиям
Необходим
ое
количество
.
Рабочие станции, в т.ч. ноутбуки
Локальный сервер
Физическая и логическая структура
корпоративной локальной сети
Активное сетевое оборудование
Системное программное обеспечение
Периферийное оборудование
Информационная
серверов
безопасность
Методика заполнения.

Графа «Рабочие станции». В столбце «Количество объектов, всего» указывается
соответствующее число компьютеров, находящихся на балансе учреждения всего,
в том числе для нужд бухгалтерии, кадров и т.д. В столбце «Количество объектов,
удовлетворяющих. минимальным требованиям» указывается количество
компьютеров из предыдущего столбца, которые подходят под минимальные
требования. В столбце «Количество объектов, удовлетворяющих рекомендуемым
требованиям» указывается количество компьютеров, которые подходят под
рекомендуемые требования. В столбце «Необходимое количество» указывается
количество рабочих станций, которые необходимо закупить для ввода систему в
Страница 51
Построение региональной системы электронных медицинских карт






эксплуатацию. Количество оценивается, исходя из плана автоматизации больницы
и возможности использования существующей компьютерной техники.
Графа «Локальный сервер». Принцип заполнения аналогичен графе «Рабочие
станции»
Графа «Физическая и логическая структура корпоративной локальной сети».
В столбце «Количество объектов, всего» указывается количество рабочих станций
и серверов, находящихся на балансе учреждения. В столбце «Количество
объектов, удовлетворяющих минимальным требованиям» указывается количество
объектов из предыдущего столбца подключенных к локальной сети согласно
минимальным требованиям. В столбце «Количество объектов, удовлетворяющих
рекомендуемым требованиям» указывается количество объектов из предыдущего
столбца подключенных к локальной сети согласно рекомендуемым требованиям. В
столбце «Необходимое количество» указывается количество дополнительных
точек подключения к локальной сети, с учетом вновь закупаемых рабочих станций.
Графа «Активное сетевое оборудование». В столбце «Количество объектов,
всего» указывается количество точек выхода в сеть интернет. В столбцах
«Количество объектов, удовлетворяющих минимальным требованиям» и
«Количество объектов, удовлетворяющих рекомендуемым требованиям»
указывается количество точек выхода в сеть интернет, удовлетворяющих
соответствующим требованиям. В графе «Необходимое количество» указывается
«1» если выход в сеть отсутствует или не удовлетворяет требованиям.
Графа «Системное программное обеспечение». В столбце «Количество
объектов, всего» указывается число операционных систем, установленных на всех
рабочих станциях и серверах. В столбце «Количество объектов, удовлетворяющих
минимальным требованиям» указывается количество операционных систем из
предыдущего столбца, которые подходят под минимальные требования. В столбце
«Количество объектов, удовлетворяющих рекомендуемым требованиям»
указывается количество операционных систем, которые подходят под
рекомендуемые требования. В столбце «Необходимое количество для закупок»
необходимо указывать количество операционных систем для функционирования
серверов, т.к. на рабочие станции рекомендуется устанавливать операционную
систему Ubuntu, которая относится к классу СПО.
Графа «Периферийное оборудование». В столбце «Количество объектов,
всего» указывается число принтеров, находящихся на балансе учреждения. В
столбце «Количество объектов, удовлетворяющих минимальным требованиям»
указывается количество принтеров из предыдущего столбца, которые подходят
под
минимальные
требования.
В
столбце
«Количество
объектов,
удовлетворяющих рекомендуемым требованиям» указывается количество
принтеров, которые подходят под рекомендуемые требования. В столбце
«Необходимое количество для закупок» необходимо указывать количество
принтеров, необходимых для закупки в рамках реализации проекта подключения к
региональной ИС. Оценивается исходя из плана автоматизации больницы и
возможности использования существующей техники.
Графа «Информационная безопасность серверов». В столбце «Количество
объектов, всего» указывается число программных средств, установленных на
серверах и предназначенных для защиты информации от НСД. В столбце
«Количество
объектов,
удовлетворяющих
минимальным
требованиям»
указывается количество объектов из предыдущего столбца, которые подходят под
минимальные требования. В столбце «Количество объектов, удовлетворяющих
Страница 52
Построение региональной системы электронных медицинских карт
рекомендуемым требованиям» указывается количество объектов, которые
подходят под рекомендуемые требования. В столбце «Необходимое количество
для закупок» указывается количество лицензий на программные средства,
необходимые для выполнения требований по безопасности.
Приложение 4
Таблица износа и загруженности серверов
Сервер, его предназначение
Степень износа, %
Степень использования, %
Методика заполнения.
В столбце «Сервер, его предназначение» указывается общее описание существующего
сервера. В столбце «Степень износа, %» указывается оценочный процент износа
оборудования. В столбце «Степень использования, %» указывается оценочный процент
использования оборудования исходя из показания занятости процессора, жесткого диска
и т.д.
Приложение 5
Таблица закупок компьютерной техники
Наименование
Ед.
измерения
Количество
Заполняется по результатам технического аудита. В таблицу заносятся все позиции
(аппаратного и программного обеспечения), необходимые для дополнительной закупки в
рамках создания региональной информационной системы.
Страница 53
Построение региональной системы электронных медицинских карт
Приложение 6
Таблица 12. Аудит информационных систем
Название ИС
Краткое описание
функционала
Вид
информационной
системы, кол-во
рабочих мест
Решение об
использовании
(оставить как
есть/модификация
до работы в
региональной
системе/отказ от
использования)
Страница 54