Вход
Закрыть
Вход
Войти, используя:
Зарегистрироваться Экспертная сеть по вопросам государственного управления

Редакция

Михаил Эльянов

Бизнес6 Июля, 12:54

Полина Давлетшина

Наука и образование3 Апреля, 14:04

Борис Зингерман

Наука и образование6 Октября, 2016 - 07:43
Все редакторы (3) →

Эксперты

Валерий Пулит

Разное22 Июля, 20:47

Наталья Храмцовская

Бизнес21 Июля, 11:56

Станислав Радченко

Наука и образование18 Июля, 09:47

Андрей Столбов

Наука и образование1 Июля, 14:55

Александр Гусев

Бизнес3 Мая, 10:11
Все эксперты (18) →

Активные участники

Михаил Смирнов

Государство21 Июля, 17:03

Николай Стасов

Разное7 Июля, 10:34

Михаил Заглов

Разное4 Июля, 07:38

Евгений Морозов

Государство26 Июня, 12:34

Юрий Мухин

Разное8 Июня, 11:01
Активные участники (75) →
Подтверждение удаления
Отменить
Удалить

Куда ведет «Дорожная карта»?

«Дорожная карта» вскрыла интересный парадокс: чем меньше денег становится, тем более разумные решения принимаются. Стремление «освоить бюджет» перестает доминировать над достижением результата – ведь все уже «освоено до нас».

Новая команда ИТ-департамента Минздрава РФ пока элегантно выходит из доставшейся ей в наследство тупиковой ситуации по информатизации. Помимо появления набора целевых показателей в «Дорожной карте» закрепляются в виде отдельных сущностей медицинские информационные системы регионального и учрежденческого уровня.

Что это означает? В период активного «освоения бюджета» в регионах прошла череда конкурсов на создание универсальной системы ЕГИСЗ, но решение, предложенное одной известной российской компанией, «взлетело» далеко не везде. В большинстве регионов, кроме до сих пор сопротивляющегося Нижнего Новгорода, работы закрыты только на бумаге. Итого: деньги потрачены, результата нет. Повторная покупка регионального фрагмента ЕГИСЗ будет означать признание неэффективного использования средств в первый раз.

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

Регион, попавший в описанную сложную ситуацию, в соответствии с «Дорожной картой», должен принять два отдельных документа:

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

Эти действия приводят к следующим результатам:

  • Универсальная система превращается в портальную МИС (на рисунке ЕМИС - единая МИС) и должна соответствовать требованиям по интеграции с региональным уровнем.
  • Другие МИС, используемые в медицинских учреждениях (на рисунке «наследуемые» и «специализированные») также дорабатываются для взаимодействия с региональным уровнем и получают возможность на равных конкурировать с портальной МИС. В случае, если они будут больше нравиться пользователям, то смогут переключать на себя больницы, подключенные к портальной МИС. Возможен и другой вариант: под давлением локальных конкурентов, разработчики портальной МИС доводят систему «до ума» и ее эксплуатация успешно продолжается.
  • На региональном уровне реализуются компоненты, разрабатываемые одним или несколькими разработчиками на конкурентных началах, т.к. требования по взаимодействию компонентов между собой через интеграционную шину заранее определены.

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

sites/default/files/user_pictures/2015/04/21/rs.jpg


Комментарии (8)

Владимир Громов, Бизнес 

Уважаемый Дмитрий Котохин!

«Новая команда ИТ-департамента Минздрава РФ» - это кто?

Михаил Асташин, Наука и образование 

Ну как же. У команды имеется симпатичное лицо. Не находите?

Евгений Морозов, Государство 

Не могу не согласиться.

Пока осторожно возрадовался последниму выступлению "лица" на Медсофт'е.

Будем наблюдать.

P.S. А картинку и правда надо побольше.

Елена Щепанкова, Бизнес 

Лицо, вселяющее надежду :), хочется верить

Дмитрий Андреянов, Бизнес 

Дмитрий, на рисунке ничего не видно. Можно сделать его покачественнее?

Дмитрий Котохин, Бизнес 

Коллеги, спасибо за комментарии. Добавил схему в pdf, должно быть лучше. Про новую команду - речь шла, конечно, про Е.Л. Бойко.

Евгений Морозов, Государство 

Заметки на полях:

Просмотрел некоторые выступления с Медсофт, прочитал комментарии.

Теперь есть несколько вопросов по схеме. 

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

Поэтому можно увидеть вполне работающую МИС учреждения, работающую систему на уровне минздрава региона, но на взаимодействии всё "ломается". 

Алексей Самойлов, Бизнес 

Дмитрий,

Ваша схема содержит много некооректностей и неточностей. Например, еще в октябре 2014 года на правительственной комиссии по ИТ было определено, что взаимодействие с ГИБДД осуществляется через СМЭВ. У вас же напрямую.

В схеме намешаны функциональные блоки (бизнес процессы) и технологические, отсюда получается винегрет. В Вашей схеме, например, есть региональная транзакционная система по управлению кадрами, и рядом же, но в разделе РИАС-Хранилище данных упоминается Регистр медработников. Вы предполагаете вести 2 системы? Это явно неоптимально. Или преполагается, что транзакционные системы это а-ля интерфейс, а хранилище отдельно? Тогда в хранилище данных нужно прописывать хранилище для всех систем.