О проекте
В 2018 году к нам обратился наш клиент, группа компаний «Ниармедик», с просьбой разработать новый сайт медицинских клиник.
В ходе проблемных интервью мы выявили одну из главных «болей» заказчика: существующий сайт плохо обновляется и не позволяет записаться на прием, из-за чего колл-центр перегружен звонками, а большая часть посетителей сайта не конвертируется в клиентов.
Одним из барьеров для развития сайта и бизнеса оказалась слабая интеграция с Медицинской информационной системой клиента (МИС).
Мы начали работу, в ходе которой у заказчика появилась новая задача: не только интегрировать сайт с действующей инфосистемой, но и дать возможность новым партнерам подключаться к МИС. Кроме того, существовала вероятность перехода на другую МИС в ближайшем году.
Поэтому вместо прямой интеграции мы приняли решение разработать шину, которая позволяет проще и эффективнее поддерживать и развивать всю инфраструктуру.
Конкретизация задачи
Медицинская информационная система (МИС) в нашем случае выполняет четыре главные роли:
- Хранит полную информацию про всех врачей и все клиники
- Управляет расписанием врачей
- Записывает посетителя на прием на сайте
- Обрабатывает запись с сайта в системе медцентров
При этом запись на прием должна работать не только на главном сайте клиник, но и в сторонних партнерских сервисах (сайты других медцентров, страховые компании, универсальные агрегаторы медуслуг).
Чтобы «клиенты» могли обращаться к МИС за данными, каждому из них нужно предоставить строго определенный доступ к программному интерфейсу (API) информационной системы.
Но текущая МИС «Ниармедика» умела предоставлять доступ только по IP (уникальному числовому идентификатору устройства в компьютерной сети). То есть предоставление доступа конкретного пользователя сети к МИС открывает ему доступ ко всем данным сразу. По такой схеме не получится разграничивать права пользователей — например, закрыть для страховой компании возможность бронировать приёмы в клиниках.
Значит, есть задача разработки 1 — нужно менять схему доступа к МИС.
Чтобы интеграция не нарушалась, API должен оставаться неизменным (иммутабельным). Это означает, что мы должны четко прописать все методы интеграции и закрепить их. Например, если в методе «Список клиник» настроена выдача ответов в виде ID и названия медцентров, этот метод должен остаться таким навсегда. При изменениях в методе интеграция «отвалится». Это негибкое решение.
С учетом этих моментов и планов заказчика подключать к текущей МИС десятки новых пользователей с разными запросами, замена МИС на новую превращается в будущем в очень сложную задачу.
Значит, есть задача разработки 2 — нужен более гибкий вариант, другой подход и технология.
И это шина интеграции
Интеграционная шина — это связующая прослойка между пользователями и внутренними системами Медицинской информационной системы.
Нужно определить задачи, которые возьмет на себя шина.
В случае нашего заказчика они такие.
1. Тонкий контроль и надежная защита доступа
На уровне шины можно не просто контролировать наличие доступа к МИС, но и тонко настраивать, какие данные может получить каждый пользователь.
Здесь доступ к МИС настраивается уже не по IP пользователя. Подключение к шине защищается мощнее — и возможно только при наличии токена (длинного секретного ключа), который в любой момент можно отозвать, закрыв доступ к информационной системе.
При необходимости, МИС можно подстраховать двойной защитой, используя для авторизации и токен (через шину), и IP (через саму МИС).
Для каждого пользователя в шине можно собрать конструктор конкретных прав доступа (отсекая, как в нашем примере выше, страховую компанию от бронирования приема у специалистов). Например, так:
2. Гибкость и адаптивность интеграции
При разработке мы должны были абстрагироваться от текущей Медицинской информационной системы. Во-первых, клиент думал сменить её в ближайшее время. Во-вторых, бизнес-логика заказчика важнее, чем особенности работы существующей МИС.
Поэтому мы применили несколько решений.
1) Адаптер
Это программный код, который умеет соединять любую МИС с рабочей шиной.
Адаптер выполняет роль «переводчика» для конкретной МИС. Запрос пользователей поступает на шину, шина обращается к адаптеру, адаптер трансформирует запрос в понятный МИС язык.
Схема работает и в обратную сторону. МИС отвечает на запрос, он поступает в адаптер, который переводит ответ в универсальный язык. Адаптер передает ответ шине, а она — конечному пользователю.
К шине можно подключить нужное количество адаптеров — «переводчиков» для каждой МИС со своими особенностями. Такие адаптеры также легко заменимы.
2) Версионность методов интеграции
В разделе про задачу клиента мы рассказали о негибкости строго закрепленных методов интеграции API. При внесении изменений в методы интеграция «слетает».
Однако мы договорились о том, что в приоритете — бизнес-логика.
При запросе «клиента» к МИС необходимо получать новый набор данных? — Просто создадим новую версию нужного метода, не меняя структуру существующих методов интерфейса (API) шины.
Пользователь системы сам сообщит шине, какой версией метода он хочет воспользоваться. И шина пропустит запрос именно по этому алгоритму.
Тем самым, интеграция с МИС останется стабильной, а шину можно будет непрерывно развивать под бизнес-задачи клиента и его партнерских систем.
На иллюстрации изображена схема работы метода «Список клиник».
В первой версии метода (на показанном примере) пользователям МИС поступает ответ, содержащий номер телефона клиники, адрес сайта и список филиалов. Например, он удобен страховой компании, с которой сотрудничает «Ниармедик».
Если сайту «Ниармедика» нужно дополнительно получать данные о часах работы и фамилии главного врача каждой клиники, будет создана вторая версия метода «Список клиник». Отправив запрос по версии 002, сайт получит ответ уже не из трёх, а из пяти полей и обновит информацию для посетителей.
3) Логирование событий
Все взаимодействия «клиентов» с шиной и шины с внутренними сервисами залогированы.
Логи — это записи с системной информацией и действиями пользователей. При возникновении проблемы логи помогают быстро разобраться и устранить препятствие в работе шины.
4) Кеширование запросов
Мы организовали кеширование (сохранение ответов на одинаковые запросы) на шине.
Например, «клиенты» МИС часто запрашивают данные о списке клиник и списке врачей. Если сохранять историю ответов прямо на шине, то нагрузка на МИС уменьшится, сэкономится ресурс на другие действия. Пользователи будут быстрее получать ответы на все свои вопросы.
Результаты
Мы выполнили задачу заказчика. «Ниармедик» получил рабочую систему, при которой сайт клиник надежно интегрирован с Медицинской информационной системой.
Схематично новая интеграция работает так:
Данные на сайте всегда актуальны, посетители клиник находят всю нужную информацию и легко записываются на прием, нагрузка на колл-центры снизилась. Время записи фиксируется во внутренней системе клиник — посетителя ждут в медцентре или отправляют к нему врача на дом.
Дополнительно мы обеспечили «Ниармедику» технологическую платформу для развития бизнеса: независимость от текущей МИС, возможность заменить её или дополнительно подключиться к другим инфосистемам, подключать партнеров и настраивать для них свои методы интеграции под конкретные бизнес-задачи.
Познакомиться с полной историей разработки нового сайта для компании «Ниармедик» можно здесь.
Команда проекта
- Руководитель проекта: Евгений Лазарев
- Backend: Роман Шипелов, Константин Василенко, Сергей Никитченко
- Тестирование: Анна Шорина
