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

1. ОРГАНИЗАЦИЯ ФУНКЦИОНИРОВАНИЯ МЕДИЦИНСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ ЕМИАС  стоматологической клиники 
1.1 Топология медицинской  информационной  системы
1.2 Архитектура медицинской  информационной  системы
1.3  Требования ЕМИАС к ИС 
1.4 Проблемы при организации работы компонентов ЕМИАС в ИС стоматологической клиники (постановка задачи)
1.5. Вывод по главе
    
1.1 Топология медицинской информационной системы
     Топология (конфигурация) характеризует свойства сетей, систем и программ, не зависящие от их размеров. Она изучает структуру, образуемую физическими объектами и множеством связывающих их каналов либо частей каналов.
     Конфигурация соединения элементов более интересна, чем другие характеристики сети. Это связано с тем, что именно конфигурация во многом определяет многие важнейшие свойства сети - надёжность (живучесть), производительность и др.
     Согласно одному из подходов к классификации конфигурации, сети делят на два основных класса:
* Широковещательные.
* Последовательные.
     В широковещательных конфигурациях каждая абонентская система передает сигналы, которые могут быть восприняты остальными системами. К таким конфигурациям относят:
* Общая шина;
* Дерево;
* Звезда.
     В широковещательных конфигурациях должны применяться сравнительно более мощные приемник и передатчик, которые могут работать с сигналами в большом диапазоне уровней. Эта проблема частично решается введением ограничений на длину кабельного сегмента и на число подключений или использованием цифровых повторителей.
     Тип «общая шина» (рис. 1) позволяет значительно упростить логическую и программную структуру сети, снизить расход кабеля.
      
     Рис. 1 тип «общая шина»
     Конфигурация типа «дерево» (рис. 2)  представляет собой более развитый вариант конфигурации типа «общая шина». «Дерево» образуется путём соединения нескольких «шин» активными повторителями или сетевыми концентраторами («хабами»). Оно обладает необходимой гибкостью для того, чтобы охватить средствами ЛС несколько зданий на определённой территории. При наличии активных повторителей отказ одного сегмента не приводит к выходу из строя остальных. В случае отказа повторителя «дерево» разделяется на два «поддерева» или на две «шины».
      
     Рис. 2 тип «дерево»
     Развитием конфигурации типа «дерево» является сеть типа «звезда» (рис. 3), которую можно рассматривать как «дерево», имеющее корень с ответвлениями к каждому подключенному устройству. В центре «звезды» может находиться пассивный соединитель или хаб - достаточно простые и надежные устройства. Звездообразные сети могут быть защищены от нарушений в кабеле с помощью центрального реле, которое отключает вышедшие из строя кабельные лучи. Такая «звезда» требует большого количества кабеля.
      Рис. 3 тип «звезда»
     В последовательных конфигурациях каждый физический подуровень передает информацию только одной из абонентских систем. К передатчикам или приёмникам систем здесь предъявляются более низкие требования, чем в широковещательных, и на различных участках сети могут использоваться разные виды физической среды.
     Наиболее распространённые последовательные конфигурации:
* Произвольная;
* Иерархическая;
* Кольцо;
* Цепочка;
* Звезда с «интеллектуальным» центром;
* Снежинка. (1) (http://bourabai.ru/telecom/nets04.htm)
	Топология МИС представляет собой «Звезду с «интеллектуальным» центром».  
     Топология Звезда –  классическая схема LAN. Используется для построения распределительной сети обработки данных.
     В центре «звезды»  размещается интеллектуальный центр, через который осуществляется коммутация между всеми элементами сети. 
     «Звезда» обеспечивает  более надёжную работу сети, чем топология типа «шинная», т. к. повреждение какого-либо кабеля затрагивает работу только одного компьютера, использующего этот кабель, и не влияет на работу остальной части сети.
      Недостатком звезды является то, что для функционирования локальной сети такой топологии требуется дополнительное устройство — концентратор. При выходе концентратора из строя происходит остановка в работе всей сети. (2)(http://www.tls-group.ru/art/topologija-lokalno-vychislitelnyh-setej_old.htm)
     В работе МИС большую роль играет стабильность функционирования локальной сети. Ведь обеспечение быстрого и качественного обслуживания во многом зависит именно от корректной работы программы. Топология типа «Звезда» идеально подходит к этой системе, во многом из-за своей стабильности. 
     В данной топологии интеллектуальный центр, или же коммутатор или маршрутизатор, позволит исключить неэффективную передачу данных по всем линиям, когда получатель будет подключен только к одной из них. Активное оборудование будет само выбирать путь передачи данных, передавая данные только тому участнику, для которого они предназначены, не перегружая остальные линии. Это достаточно удобно, учитывая то, что системой ЕМИАС пользуется огромное количество врачей и пациентов по всей территории России.
     
1.2 Архитектура медицинской  информационной  системы

     Основываясь на опыте отечественных и зарубежных разработчиков, проектирование и разработка МИС осуществляется на модульном принципе. Отдельные компоненты системы разработаны как самостоятельные приложения, но они тесно объединены друг с другом при помощи специальных программных интерфейсов. Иногда такой способ разработки информационных систем называют методом компонентного проектирования базы данных. 
     Актуальность автоматизации здравоохранения не вызывает сомнения. Как и в любой системе, проектирование начинается с архитектуры этой системы. В случае с МИС при проектировании архитектуры нужно учитывать постоянно ряд ее особенностей: растущий объем информации, поддержка актуальности единого информационного пространства, постоянно растущая база предметной области.
     Архитектура информационной системы - концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы. Существует несколько типов архитектуры.
    Одна из таких архитектур является «Централизованной» (рис. 4) .
     
     Рис. 4 Централизованная архитектура
    В такой архитектуре все компоненты системы располагаются  в централизованном ядре системе. Ядро системы строится на основе нескольких центров обработки данных объединённых соответствующей телекоммуникационной инфраструктурой. 
    Особенности архитектуры состоят в том, что все базовые компоненты реализуются в одном месте, и все пользователи одновременно работают на одном компьютере.
   Работа и доступ с прикладным программным обеспечением осуществляется по модели SaaS. В этом случае для работы с программным обеспечением нужен только браузер.  В медицинских учреждениях строится вычислительная сеть, к которой подключаются рабочие места различных специалистов, различное диагностическое оборудование. Данные загружаются в централизованное хранилище ядра.  В такой архитектуре не выполняется обработка медицинских данных. Возможно предоставление доступа и работа с программным обеспечением авторизованным пользователям и через мобильные устройства. Осуществляется взаимодействие с другими информационными системами.
   Достоинства данной архитектуры выражены в том, что в ней не требуется администрирование рабочих мест пользователей. Также, в этой архитектуре обеспечена централизованная разработка и обслуживание системы.
   К недостаткам централизованной архитектуры можно отнести высокие требования к полосе пропускания и надёжности сети, трудности в использовании уже внедрённых систем, и также зависимость пользователей на программном уровне.
   Другой вид архитектуры носит название «Файл-серверная архитектура» (рис. 5).
   
   Рис. 5 архитектура «файл-сервер»
   В такой архитектуре данные располагаются на файл-сервере и являются пассивным источником. Приложение же отвечает за получение, обработку данных и за поддержание целостности базы данных.
   Недостатки такой системы в том, что все данные хранятся в одном месте, а обрабатываются в другом. Следовательно, их нужно передавать по сети, что приводит к большим нагрузкам на сеть и снижению производительности при большом числе одновременно работающих клиентов.
    Также, одной из распространённых архитектур, является архитектура типа «Клиент-сервер» (рис. 6).
     
     Рис. 6 «клиент-серверная» архитектура
     В данном случае для обработки данных выделяется специальное ядро, сервер базы данных. Он осуществляет обработку запросов пользователей. Приложение-клиент посылает запрос на обработку данных. Сервер в свою очередь обрабатывает данные и отправляет клиенту только требуемую информации.
     Данная архитектура позволяет уменьшить нагрузку на сеть, повышает надёжность логической целостности базы данных, уменьшает требования для компьютеров клиентов.
    Ещё один тип архитектуры носит название «Трёхуровневая» (рис. 7) и содержит в себе три компонента:
* Клиентское приложение
* Сервер приложений
* Сервер базы данных

Рис. 7 «трёхуровневая» архитектура
   Клиент представляет первый уровень, то есть интерфейс для конечного пользователя. Сервер приложений располагается на втором уровне. Здесь сосредоточена бизнес логика. Сервер базы данных - третий уровень, где обеспечивается хранения данных. Обычно это реляционная СУБД.
Достоинства трёхуровневой архитектуры заключаются в масштабируемости, изолированности уровней друг от друга, высокой безопасности, высокой надёжности, низких требований к скорости канала сети между терминалами и сервером приложений, низким требований к производительности и техническим характеристикам терминалов.
    Но тем самым повышается сложность создания приложений, в разворачивании и в администрировании. А так же высокие требования к производительности серверов ведет к высокой стоимости серверного оборудования.
   Из всего этого следует, что для МИС целесообразней всего использовать трёхуровневую архитектуру.
     Архитектура МИС должна состоять из регионального сегмента общесистемных компонентов единого информационного пространства в здравоохранении и регионального сегмента прикладных компонентов единого информационного пространства в здравоохранении.
     Система должны быть рассчитана на хранение в одной БД метаданных и данных с разделением на профили. Под профилями в данном случае понимается отдельное пространство в БД для хранения информации, относящееся к конкретному учреждению здравоохранения.
     Система должна обеспечить работу всех медицинских организаций (региона) на единой региональной базе данных под управлением логически единого экземпляра СУБД. Система должна быть web-ориентированной.
     Региональный сегмент общесистемных компонентов единого информационного пространства в здравоохранении, должен состоять из общесистемного и платформенного программного обеспечения, хранилищ данных, сервисов доступа и обработки данных, а также общесистемных технологических сервисов, необходимых для обеспечения информационного, лингвистического и процессного взаимодействия между прикладными компонентами, защиты данных от несанкционированного доступа и потери.
     Региональный сегмент прикладных компонентов обеспечивает информационно-технологическую поддержку функций управления здравоохранением, непосредственного оказания медицинской помощи, информационного взаимодействия с гражданами и организациями по вопросам медицины и фармацевтики.
   Серверные компоненты Системы размещаются и функционируют в центре обработки данных, реализуя все функциональные возможности Системы и обеспечивая их предоставление в виде информационно-коммуникационных технологических услуг на рабочих местах пользователей и персонала Системы.
    Доступ пользователей к приложению осуществляется через специально предназначенные программные клиенты, в том числе, для мобильных платформ. (3)(Вихман В. В. к.т.н., к.п.н кафедра ВТ НГТУ, Копысов П. Е. инженер-конструктор Nvision Group Архитектура медицинских информационных систем)
1.3 Требования ЕМИАС к ИС
     Основными общесистемными требованиями, предъявляемыми к разработке и реализации информационного пространства в целом, являются: 
* Централизация – ИС должна в своей структуре иметь выделенный центральный элемент обеспечивающий функционирование основной части сервисов, и имеющий в своём составе организованное хранилище данных в котором размещены все данные функциональных систем ЛПУ или их копии; 
* Производительность - система должна обеспечивать необходимую пропускную способность и время ответа на запрос пользователей с учетом пропускной способности сети передачи данных и нагрузки в пиковые периоды; 
* Надёжность - ИС, от которой зависит информационная поддержка процессов деятельности ЛПУ, должна гарантировать допустимое время простоя из-за отказа её элементов. Кроме того, система должна сохранять работоспособность и гарантировать сохранность данных в случае отказа отдельных её частей; 
* Масштабируемость - система должна позволять наращивание производительности при росте нагрузки и наращивании ресурсов (масштабируемость показывает, насколько эффективно повышается производительность при наращивании ресурсов и росте нагрузки); 
* Открытость - система должна быть построена на основе открытой архитектуры, поддерживать современные технологические стандарты, иметь возможность использовать новые стандартные компоненты аппаратного обеспечения и версии программного обеспечения, а также позволять наращивать функциональность, которая может потребоваться пользователю системы в будущем; 
* Защищённость - система должна функционировать в соответствии с установленными требованиями без неприемлемого ущерба; 
* Целостность данных - система должна обеспечивать хранение непротиворечивой информации. Должна быть возможность создания резервных копий и оперативного восстановления требуемой информации в случае её утраты; 
* Конфигурируемость и сопровождаемость - система должна обеспечивать удобный и гибкий интерфейс управления, доступ к аппаратным возможностям, соответствующим специфике её реализации, настройку в соответствии с решаемыми задачами, простоту администрирования и проведения сервисных и профилактических работ. Система должна обеспечивать настройку и внесение изменений в программное обеспечение с минимальными трудозатратами; 
* Совместимость – разрабатываемая система должна быть совместима с современными технологическими стандартами на аппаратное, программное обеспечение и протоколы передачи данных; 
* Стоимость и защита инвестиций – средства автоматизации должны быть конкурентоспособны как по стоимости приобретения, так и по совокупной стоимости владения, и обеспечивать возможность максимального сохранения средств, инвестированных в нее. (4)(КОНЦЕПЦИЯ ТИПОВОГО ПРОЕКТА ЛОКАЛЬНОЙ ВЫЧИСЛИТЕЛЬНОЙ СЕТИ ЛЕЧЕБНО-ПРОФИЛАКТИЧЕСКОГО УЧРЕЖДЕНИЯ)
     В соответствии с назначением СИМИ ЕМИАС и составом автоматизируемых процессов в составе Системы должны быть реализованы подсистемы, назначение и основные характеристики. Данные требования носят не рекомендательный, а обязательный характер. 
     Подсистема хранилища СЭМД должна обеспечивать поддержку процессов загрузки, хранения и извлечения СЭМД. Основными характеристиками данной подсистемы является выполнение форматного контроля и регистрации СЭМД. Также, она производит хранение СЭМД с поддержкой версионности, организует ведение архива. Данная подсистема производить поиск и выгрузку СЭМД по авторизованному запросу, производит ведение аудита загрузки и извлечения СЭМД.  
     Подсистема управления регистром иЭМК должна обеспечивать поддержку процессов создания, поиска, архивации и слияния иЭМК. Данная подсистема создаёт и ведёт иЭМК для пациента, ведёт архив, а также выдаёт возможность слияния сервисов. 
     Хранилище структурированных данных СЭМД служат для обеспечения поддержки процессов разбора СЭМД в соответствии со структурой используемого протокола и хранения структурированных данных.  СЭМД занимается поиском и сведением данных по заданным критериям авторизированных запросов. Основной характеристикой данной подсистемы является контроль ссылочной целостности и корректности данных СЭМД и размещение структурированных данных в реляционных таблицах. Также, СЭМД занимается поиском и извлечением данных по значениям различных параметров протокола, включая идентификаторы пациента, медицинского работника, ЛПУ, случаи и обращения. СЭМД включает в себя возможность группировки данных по нескольким критериям:
* Случаям обращения (амбулаторным и стационарным ИБ);
* Видам обследований.
     Управление НСИ обеспечивает поддержку своих процессов. Основными характеристиками данной подсистемы является первоначальная загрузка, синхронизация со смежными системами в составе ЕМИАС. Также, управление НСИ обеспечивает возможность редактирования внутренних классификаторов СИМИ с обеспечением поддержки версионности и сроков действия, поиском и извлечением необходимой информации.
     Хранилище протоколов, используя Developer Interface,  обеспечивает поддержку процессов создания, редактирования, публикации описаний объектов предметной области, включая протоколы, группы параметров протоколов, шаблоны, а также возможность использования объектов предметной области другими подсистемами СИМИ и смежными системами. К основным характеристикам хранилищ протоколов относят создание и настройку протоколов, параметров протоколов и групп параметров протоколов. Также, хранилище протоколов совершает конфигурирование шаблонов протоколов, конфигурирование печатных форм для протоколов, конфигурирование экранных форм для протоколов, экспорт/импорт протоколов, шаблонов протоколов, параметров протоколов и групп параметров, экранных и печатных форм.
     Администрирование обеспечивает поддержку работы системы. Оно характеризуется управлением в различных режимах работы (таких, например, как производственный, тестовый, аварийный, диагностический). Также администрирование отвечает за управление настройками Системы. 
     Управление доступом и обеспечение информационной занимается идентификацией, аутентификацией и авторизацией пользователей. Эта подсистема создает роли и настраивает права доступа к ним. Она регистрирует согласие пациента на обработку персональных данных, осуществляет антивирусную и криптографическую защиту.
     Интеграция взаимодействует со смежными подсистемами ЕМИАС, также она осуществляет взаимодействие с системой иЭМК, входящей в Федеральный сегмент ЕГИСЗ. Она осуществляет конфигурирование параметров взаимодействия, обеспечивает работоспособность сервисов, обеспечивает взаимодействие с федеральной иЭМК.
     Диагностика Системы должна обеспечивать возможность и выполнение проверок доступности и работоспособности элементов Системы.
     Информационный обмен между компонентами СИМИ должен осуществляться с использованием совместного доступа к базам данных подсистем СИМИ и вызовов сервисов, реализованных в интерфейсах подсистем. 
     В соответствии с проектом «Методических рекомендаций по применению облачных технологий при создании регионального уровня единой государственной ИС в сфере здравоохранения, в рамках реализации региональных программ модернизации здравоохранения в 2011 – 2012 годах» (информация Министерства здравоохранения и социального развития РФ от 30 января 2012 года) СИМИ, как ИС, предназначенная для использования в составе РЕИС, должна иметь открытую сервисно-ориентированную архитектуру. Базовой технологией для реализации архитектуры СИМИ должно быть использование web-сервисов.
     Разрабатываемая система СИМИ является частью ЕМИАС и, в соответствии с общей архитектурой ЕМИАС, предоставляемые Системой сервисы работы с хранилищем СЭМД, хранилищем структурированных данных СЭМД и хранилищем протоколов должны быть доступны для использования следующими смежными системами:
* Подсистемой формирования пользовательского интерфейса ЕМИАС;
* Подсистемой интеграции МИС;
* Информационными системами федерального фрагмента ЕГИСЗ;
* Информационными системами Электронного правительства, включая портал государственных и муниципальных услуг (функций) города Москвы и портал государственных услуг РФ.
     При проектировании взаимодействия с порталом государственных и муниципальных услуг города Москвы и порталом государственных услуг РФ должна быть предусмотрена возможность организации предоставления доступа гражданам (их доверенным лицам) к сведениям их иЭМК.
     СИМИ создаётся на основе БМИ ЕМИАС и должна использовать сервисы, предоставляемые системами в составе БМИ ЕМИАС и ЕМИАС:
Набор базовых сетевых и системных сервисов БМИ ЕМИАС:
* Подсистема единого каталога пользователей;
* Подсистема аутентификации;
* Подсистема резервного копирования и восстановления данных.
     Интеграция СИМИ со смежными системами должна производиться посредством единой интеграционной шины ЕМИАС, реализованной в рамках 1-ой очереди разработки ЕМИАС.
     Взаимодействие Системы с порталом государственных и муниципальных услуг (функций) города Москвы и порталом государственных услуг РФ должно осуществляться посредством единой интеграционной шины ЕМИАС и РСМЭВ, подключенной к СМЭВ. 
     Взаимодействие СИМИ со смежными системами должно строиться на основе web-сервисов. При разработке web-сервисов и выполнении работ по обеспечению информационного взаимодействия необходимо руководствоваться Техническими требованиями к взаимодействию ИС в СМЭВ (Приказ Министерства связи и массовых коммуникаций Российской Федерации от 27 декабря 2010 года № 190 «Oб утверждении Технических требований к взаимодействию ИС в СМЭВ»).
     Для обработки случаев отсутствия связи между Системой и смежной ИС должны быть разработаны методы и алгоритмы взаимодействия систем, позволяющие не прерывать процесс, в рамках которого возникает необходимость изменения данных, как со стороны Системы, так и со стороны смежной ИС. При этом должна сохраняться непротиворечивость и целостность данных во всех взаимодействующих системах. Например, функционирование МИС на уровне ЛПУ не должно остановиться в случае отсутствия связи с СИМИ.
     Характеристики взаимодействия СИМИ и смежных систем, в том числе требования к информационному взаимодействию с внешними ресурсами, должны быть специфицированы в составе документов ЧТЗ по результатам НИР при разработке технического проекта Системы; в частности, в ходе технического проектирования Системы должны быть уточнены, согласованы и утверждены требования к интерфейсам интеграции со следующими системами: 
* Смежные системы в составе ЕМИАС;
* Сервисы федерального сегмента ЕГИСЗ;
* Портал государственных и муниципальных услуг города Москвы и портал государственных услуг РФ;(5)( ВЫПОЛНЕНИЕ НАУЧНО-ИССЛЕДОВАТЕЛЬСКИХ И ОПЫТНО-КОНСТРУКТОРСКИХ РАБОТ ПО СОЗДАНИЮ ОБЩЕГОРОДСКОГО ИНФОРМАЦИОННОГО СЕРВИСА ИНТЕГРИРОВАННОЙ МЕДИЦИНСКОЙ ИНФОРМАЦИИ (СИМИ ЕМИАС)Техническое задание)
    
    1.4 Проблемы при организации работы компонентов ЕМИАС в ИС стоматологической клиники (постановка задачи)

При организации работы компонентов ЕМИАС в ИС стоматологической клиники, возникло ряд проблем, на решение которых были затрачены определенные ресурсы. Самые распространенные проблемы состоят в следующем:
    1. Доступ к системе через общие каналы связи. 
    Одна из часто встречаемых проблем, при работе с компонентами ЕМИАС – проблема с доступом к порталу. Это связано, в большинстве случаев, с тем, что ЛПУ учреждения не предоставило IP-адреса в Минздрав. 
    2. Перебои в работе с сервером. 
    Данная проблема значительно осложняет работу с программой, так как из-за постоянных перебоев врачи тратят лишнее время на выяснение причин данных сбоев и решение проблем. Это связано с тем, что провайдер, предоставляющий интернет-услуги, ограничивает работу серверной площадки. В данное время проводится постоянная работа по улучшению работы серверов. 
    3. Проблемы с введением личных данных пациента.
    С данной проблемой сталкиваются так же часто, как и с двумя предыдущими. Это связано с тем, что сама программа испытывает большие нагрузки на свои БД, но эта проблема решается довольно быстро, так как разработчики ЕМИАС выделяют огромные средства для эксплуатации системы. 
    4. Проблемы с составлением расписания врачей. 
    Данная проблема связана, опять же, с нагрузкой на БД, но с каждым годом эта проблема возникает все реже, и на решение данной задачи тратится все меньше времени. 
    5. Несоответствие справочника. 
    Из-за неточных или ошибочно-внесённых данных о медикаментозных составляющих справочника, возникает проблема получение информации о том или ином наименовании. Такая проблема решается, в первую очередь, постоянным пополнением списка медикаментов в БД, чтобы врачи, вносящие данные, могли ориентироваться на всплывающие подсказки списка. 
    6. Проблемы с безопасностью и сохранностью данных пациентов. 
    Безусловно, это самая важная проблема, которая будет рассматриваться в ВКР.
    Эта проблема остра потому, что защита персональных данных, сохранение врачебной тайны – первостепенная задача любой МИС.
    Необходимость обеспечения безопасности персональных данных вызвана возросшими техническими возможностями по копированию и распространению информации. Уровень ИТ достиг того предела, когда самозащита информационных прав уже не является эффективным средством, способным удалить посягательства на личные данные пациента. 
    Понимая важность и ценность данных больных, а также заботясь о соблюдении прав граждан в целом, государство требует от организаций обеспечение надежной защиты персональных данных. 
    В системе ЕМИАС проблема защиты персональных данных пациента рассматривается со всех сторон и аспектов, а на её решение и последующее улучшение тратятся чуть ли не все силы.

1.5. Вывод по главе

	На основании анализа требований ЕМИАС к безопасности, наиболее полно соответствует дискреционная политика безопасности. Данная политика безопасности осуществляется на основании заданного администратором множества разрешённых отношений доступа. 
     Основа этой политики определяется двумя способами: 
* Идентификация всех субъектов и объектов;
* Права доступа субъекта к объекту системы определяются на основании внешнего по отношению к системе правила. 
    Достоинства данной политики выражаются в относительно простой реализации соответствующих механизмов защиты. 
    Недостаток – статическая система. 
    Стоит отметить, что безопасное хранение данных пациентов — одна из функций ЕМИАС. Существует три основных направления защиты данных. Первое – это физическая защита. Данные хранятся на современных серверах, находящихся в подземных помещениях, доступ в которые строго регламентирован. Второе – это программная защита.  Данные передаются в зашифрованном виде по защищенным каналам связи, их невозможно скопировать и случайно удалить. Кроме того, единовременно можно получить информацию только по одному пациенту. И третье направление защиты – авторизированный доступ к данным. Врач идентифицируется по персональной смарт-карте, для пациента же предусмотрена двухфакторная идентификация по полису ОМС и дате рождения.
    Важно также, что персональные и медицинские данные пациентов хранятся на разных серверах и соединяются визуально только на мониторе врача после его идентификации.
    СИМИ ЕМИАС представляет собой один из Общегородских информационных сервисов в составе ЕМИАС, предназначенный для обеспечения автоматизации процессов: 
* Сбора, хранения (в том числе архивного), обработки и консолидации медицинской информации о пациенте в составе иЭМК пациента – в едином хранилище на основе СЭМД по всем случаям обращения гражданина в медицинские учреждения города Москвы;
* Оперативного авторизованного поиска и извлечения медицинской информации о пациенте из любого государственного медицинского учреждения города Москвы, а также из других регионов РФ через федеральные сервисы (после ввода в эксплуатацию федеральных сервисов и реализации интеграции Системы с ними);
* Накопления в структурированном виде фактографической информации о состоянии здоровья и оказании медицинской помощи;
* Создания, редактирования, публикации протоколов. 
     Основной целью создания СИМИ ЕМИАС является повышение эффективности деятельности системы здравоохранения города Москвы за счёт внедрения современных информационных технологий.
     На различных этапах организации работы ЕМИАС возникало ряд проблем, которые, впрочем, посредством улучшения тех или иных характеристик. Разработанная архитектура Системы позволяет распределить Систему по уровням, и уделить особое внимание безопасности и сохранению персональных данных пациента.
    
.......................