InterSystems HealthShare

InterSystems HealthShare
Новые возможности для региональных
интеграционных проектов
Дмитрий Засыпкин
InterSystems Russia
InterSystems HealthShare
Стратегическая медицинская интеграционная
платформа
InterSystems HealthShare – это…
– Платформа обмена медицинскими
данными и документами
– Инструмент для быстрой
интеграции медицинских
систем с применением
международных стандартов
Мобильные
пользователи
Сети ЛПУ
МИС в ЛПУ
HealthShare
– Сервер приложений,
промышленная СУБД
– Аналитическая технология
АРМы
работы с
ЭМК
Лаборатории
– Среда разработки и исполнения
бизнес-процессов
Страховщики
01
Региональный сегмент ЕГИСЗ
01
Задачи, решаемые HealthShare
Региональная интеграция, региональная ИЭМК
• Поддержка информационного обмена с системами,
используемыми в регионе:
–
–
–
–
–
Медицинские, лабораторные, радиологические системы
Региональные системы НСИ
Системы финансового и бухгалтерского учета, системы АХД
Системы, используемые в структурах территориального ФОМС
Региональные информационные порталы
• Создание региональной электронной медицинской карты
на основании данных, собранных из МИС, ЛИС, РИС
• Создание мастер-индекса пациентов и других систем
регионального уровня
• Интеграция с федеральными сервисами
– ФЭР, ИЭМК, НСИ, …
01
IHE = Integrating the Healthcare Enterprise
InterSystems HealthShare – все еще единственная
интеграционная платформа на российском рынке,
имеющая сертификат IHE
01
Задачи, решаемые HealthShare [продолжение]
Аналитика и отчетность
• Предоставление аналитической и статистической
информации, построенной на основе консолидированных
данных
– Проектирование и наполнение многомерных OLAP-кубов
– Возможность синхронизации хранилищ OLTP и OLAP в режиме
реального времени
– Программный интерфейс для работы с многомерными кубами с
использованием стандартного языка запросов MDX
– Быстрая разработка аналитических панелей с использованием
библиотеки визуальных компонентов
– Удобные инструменты для создания ad-hoc отчетов, сводных
таблиц, графиков и диаграмм
– Возможность анализа неструктурированных текстовых данных
– Прогнозная аналитика
01
Региональная медицинская аналитика
01
Интеграция с ФЭР2
Особенности сервисов ФЭР2
• Новая система кодирования МО, медицинских услуг,
специализаций и должностей
– Разные коды в тестовой и в рабочей ФЭР2
• Использование SSL и SOAP 1.2
• Требование подписывать ЭЦП все запросы к сервисам
– Сертификат должен быть выпущен УЦ Минздрава
– ЭЦП запросов и ответов проверяется системой ИПС, через
которую проходят все SOAP-сообщения
01
Особенности сервисов ФЭР2 [продолжение]
• При отправке записи на прием в ФЭР2 требуется указывать
идентификационные данные пациента:
– СНИЛС или ЕНП или номер паспорта
– ФИО, пол и дату рождения
• ФЭР2 не проверяет, соответствует ли запись на прием
расписанию работы врача
– Возможность записаться в несуществующий слот расписания!
• Новая сущность - «врач»
– При создании очереди указывается идентификатор врача
– ФЭР2 извлекает данные врача из Федерального регистра
медработников по СНИЛС
01
Особенности сервисов ФЭР2 [продолжение]
• Для передачи одной записи на прием необходимо выполнить
три вызова сервиса ФЭР2:
– CreateSlot
• Статус “reserved”
– FinishCreateSlot
• Статус “pending”
– AcceptSlot
• Статус “accepted”
01
Особенности реализации: три потока информации
• Расписания приема врачей, поступающие от МИС
• Записи на прием, поступающие от МИС
– А также отмены записей на прием
• Оповещения от ЕПГУ о записях на прием (отменах записей)
01
Особенности реализации: FIFO, очереди сообщений
• Отдельные очереди сообщений для каждой МО (или группы)
01
Особенности реализации: обработка ошибок
• Обработка системных ошибок ИПС/ФЭР2 и сетевых сбоев
• Настройки механизма автоматической отправки повторных
запросов в случае системных и транспортных ошибок:
– Шаблоны для распознавания системных ошибок ИПС/ФЭР2
• Прикладные ошибки обрабатываются «компенсирующими»
алгоритмами, либо направляются администратору системы и в МИС
– Интервал времени между повторными попытками вызова
– Максимальный период времени, в течении которого
осуществляются повторные попытки
– Действие, вызываемое в случае, если все попытки закончились
неудачей
01
Особенности реализации: компенсация сбоев
• Пример «компенсирующего» алгоритма
01
Особенности реализации: оповещения от ЕПГУ
• Обработка SOAP-оповещений о записях на прием,
поступающих от ЕПГУ
– Оповещения от ФЭР2 заработали в августе 2014 г.
01
Спасибо за внимание!
• Дмитрий Засыпкин
[email protected]
10/10/2014
18