Медицинские организации активно адаптируют технологии микросервисной архитектуры под свои задачи. Происходит это, потому что современное здравоохранение всё больше фокусируется на повышении качества медицинских услуг и улучшении клинических результатов, стремится предоставить максимально быстрый доступ к информации о пациенте. В статье разбираем особенности использования микросервисов в здравоохранении и рассуждаем, смогут ли они стать технологическим стандартом для этой сферы.
Об интеграции в сфере здравоохранения
IT-среда здравоохранительной организации представляет собой совокупность множества систем, которым нужно обмениваться данными. Система передачи информации о поступлении/выписке, система планирования, лабораторная система, радиологическая система — все они должны обмениваться данными, и эти данные могут оказаться критически важными при оказании неотложной медицинской помощи.
Проблема интеграции медицинских систем уходит корнями в 1987 год, когда был принят Health Level Seven — глобальный стандарт для передачи клинических и административных данных. После того, как был создан этот общий язык, индустрии здравоохранения понадобился способ подключения приложений, который бы позволил им общаться через HL7.
Первой интеграционной технологией, принятой поставщиками медицинских услуг, оказалась Interface Engine. Затем спустя примерно 20 лет появилась интеграционная шина ESB. Подобно EI, она выступала центром для обмена данными между приложениями здравоохранения, в основном использующими HL7. ESB обеспечивала преобразование данных, преобразование протоколов, маршрутизацию и поддержку веб-служб, JMS, HTTP и SOAP, а также простое управление и мониторинг.
На протяжении последних лет ESB считается популярным решением для интеграции как в здравоохранении, так и в других отраслях.
Проблемы ESB
С момента внедрения ESB разработка приложений значительно эволюционировала. Одно из наиболее важных изменений — переход к Agile и DevOps.
DevOps представляет собой набор практик, направленных на сокращение жизненного цикла разработки систем и обеспечение непрерывной поставки программного обеспечения высокого качества. В эпоху DevOps характеристики, которые сделали технологию ESB популярной, теперь служат препятствием.
Среди основных ограничений ESB выделяют:
Несовместимость с инструментами DevOps: многие из сегодняшних «new» разработчиков проходят обучение в среде DevOps. И наибольшую продуктивность они демонстрируют, когда используют новейшие DevOps-инструменты. Однако интеграционная шина ESB не была разработана для поддержки этих инструментов.
Изменения влияют на всю систему: чтобы внести изменения в правила ESB, нужно приостановить работу всего движка. Это значит, что любое приложение, взаимодействующее с ESB, периодически будет подвергаться сбоям и простоям. А любая ошибка, вызванная изменением, потенциально может повлиять на все интеграции.
Единая точка отказа: поскольку все интеграции маршрутизируются через один и тот же хаб, ESB представляет собой единую точку отказа. Если ESB выходит из строя, все интеграции выходят из строя.
Невозможность автоматизировать тестирование: в DevOps каждое обновление тестируется независимо, поэтому оно не нарушает процесс разработки. Это достигается с помощью автоматизации. Однако в ESB автоматизация тестирования невозможна.
Здравоохранение, как и другие отрасли, приняло новые методы разработки микросервисов, DevOps и Agile. Разработчики хотят контролировать свои интеграции вместе с другим разрабатываемым ими кодом и упаковывать все изменения в развёртываемые модули, которые проходят через CI/CD. Однако приведенные выше ограничения препятствуют достижению этой цели.
Почему интеграция на основе микросервисов идеально подходит для DevOps
Микросервисная архитектура — будущее разработки. Разбивая приложения на независимые модули, вы получаете возможность легче разрабатывать, тестировать, вносить изменения, снова тестировать, исправлять, развёртывать, тестировать в рабочей среде, обновлять и так далее.
«Микросервисы: проектирование и интеграция на Go»
Поскольку микросервисы представляют собой небольшие компоненты, они легко помещаются в контейнеры, которые могут автоматизировать процесс тестирования и облегчить непрерывную интеграцию и непрерывную доставку (CI/CD). Что касается ESB-монолита, он слишком велик, чтобы поместиться в контейнер, и не может быть разбит на компоненты. Как следствие — не может быть протестирован таким же образом.
Но, возможно, самая важная причина внедрения интеграции на основе микросервисов заключается в поддержке agile-разработчиков и предоставлении им возможности использовать любимые DevOps-инструменты. Без ESB разработчикам не нужно обучаться работе с проприетарной системой, вместо этого они могут сосредоточиться на более продуктивном подходе к разработке.
Микросервисы демократизируют интеграцию, позволяя разработчикам исследовать свои собственные потребности в интеграции, а не ограничивать интеграцию изолированной командой специалистов ESB. Это имеет больше смысла, потому что никто не понимает требования к данным приложения лучше, чем разработчик приложения.
Кроме того, микросервисы также поддерживают управление API. При необходимости вы можете осуществлять интеграцию на основе API.
Case study: как микросервисная архитектура помогла увеличить скорость доставки проектов в 4 раза
Sutter Health — ассоциация врачей и больниц, обслуживающая более 100 населённых пунктов в Северной Калифорнии. Представляет собой идеальный пример того, как организация здравоохранения может ускорить внедрение инноваций с помощью микросервисов. До внедрения микросервисной архитектуры IT-команда Sutter Health изо всех сил старалась не отставать от растущей сложности своего ландшафта данных: более 28 миллионов сообщений HL7 ежедневно поступали из более чем 3000 различных приложений. Подход к интеграции point-to-point создавал проблемы с взаимодействием данных между системами, увеличивая время разработки. А неспособность поддерживать связь в режиме реального времени между разными сервисами оказывала прямое влияние не результаты лечения — врачи не всегда получали доступ к актуальной информации о состоянии пациентов.
Тогда команда Sutter Health приняла решение внедрить микросервисную архитектуру на базе платформы Anypoint от MuleSoft. Это позволило на системном уровне ускорить подключение медицинских карт. Теперь данные представляются с помощью отдельных сервисов, которые вызываются API-процессами. Например, API-интерфейс Patient Demographics предоставляет единый объект данных пациента из Epic, Allscripts и других медицинских систем. API-интерфейсы процессов затем сами вызываются нижестоящими приложениями для предоставления необходимых данных конечным пользователям. Благодаря продуманному созданию и повторному использованию API на всех уровнях системы, проекты, которые раньше занимали восемнадцать месяцев в Sutter Health, теперь занимают менее четырех.
Преимущества интеграции на основе микросервисов
Комплексный мониторинг и управление. Вы можете управлять микросервисами с помощью современных инструментов: Kibana, Elasticsearch, Grafana, Prometheus и др. Они позволяют точно определять точки сбоя и решать проблемы до того, как те начнут влиять на бизнес.
Автоматизированное тестирование. Одно из самых больших преимуществ микросервисов и DevOps — возможность проводить автоматизированное тестирование. Каждая интеграция рассматривается как независимый компонент по мере прохождения тестирования без нарушения работы других компонентов приложения.
Качество программного обеспечения. В конечном счете, более эффективные процессы и улучшенное тестирование приводят к более высокому качеству программного обеспечения.
Ускоренная разработка. Оптимизируя процесс интеграции с помощью DevOps и автоматизации и устраняя ранее выполняемые вручную процессы, вы ускоряете жизненный цикл разработки.
Масштабируемость. Поскольку приложения состоят из независимых модулей, каждый сервис можно масштабировать независимо, не затрагивая остальные части приложения.
Инновации. Микросервисы и DevOps вместе позволяют разработчикам внедрять инновационные интеграционные решения. Это позволяет организации внедрять новые услуги и повышать качество обслуживания клиентов.
Гибкость бизнеса. Гибкая разработка естественным образом ведёт к гибкости бизнеса, способности быстро реагировать на вызовы рынка.
Коротко о главном
Микросервисная парадигма — одна из важнейших тенденций в индустрии разработки программного обеспечения. Она имеет ряд преимуществ по сравнению с предыдущими архитектурными подходами. Внедрение микросервисной архитектуры в здравоохранении обусловлено её гибкостью и легкостью развёртывания. Однако при неправильном подходе такая архитектура может привести к дезорганизации и отсутствию управления.
Продукты и процессы, разработанные с использованием микросервисной архитектуры, часто приходится интегрировать с устаревшими технологическими стеками. И если сделать это неправильно, можно спровоцировать возникновение технологического долга и увеличение операционных расходов для IT-команды.
Внедрение микросервисов с целью создания конкурентного преимущества компании выходит за рамки простого выбора продуктов и программного обеспечения. Важно учитывать людей, процессы и культуру внутри организации. Именно поэтому рекомендуют использовать целостный платформенный подход к микросервисам, основанный на подключении через API. Такой подход обеспечивает уникальную операционную модель, позволяющую LoB и ИТ-командам создавать, внедрять инновации и предоставлять новые решения везде, где это необходимо.