Текущая задача платформы, заложенная в MVP, – сопровождать реформу финансирования гарантированных государством медицинских услуг, которые будут предоставляться на первичном уровне. В нее также входит создание базиса для дальнейшего внедрения системы, которая бы сопровождала все процессы в сфере охраны здоровья Украины.

eHealth – целый комплекс систем, выполняющих одновременно несколько ключевых функций в процессе реформирования системы здравоохранения Украины, включает в себя:

  1. реестры медучреждений, аптек, врачей, сотрудников (MSP – Medical Service Providers);
  2. реестр пациентов (MPI – Master Patient Index);
  3. реестр деклараций – контрактов между пациентом, медицинским учреждением и врачом на предоставления медицинских услуг;
  4. автоматизацию процессов регистрации медицинских учреждений, аптек, их подразделений, врачей, деклараций и пациентов: все процессы доступны в виде REST API;
  5. автоматизацию формирования биллингового капитационного отчета (финансирование) и будущего администрирования платформы со стороны Национальной службы здоровья.

Система eHealth обеспечивает наличие качественных и верифицированных данных о всех ключевых участниках процесса оказания медицинских услуг и предоставляет REST API для работы с процессами вокруг этих сущностей. Целостность и безопасность данных обеспечиваются электронной цифровой подписью и блокчейн-подобными алгоритмами. Сама система создана с пониманием критичности информации, которой она будет оперировать и поэтому применены все возможные механизмы по защите от утечек данных.

Особенность платформы в том, что она не самодостаточна: eHealth только предоставляет API для работы с реестрами и является “центральным компонентом” всей экосистемы. Любой производитель программного обеспечения для медицинских учреждений (МИС – медицинская информационная система) может интегрироваться с eHealth и предоставить удобный интерфейс для своих пользователей. Руководители клиник могут в любой момент сменить поставщика МИС, так как все данные хранятся в eHealth. Владельцами данных являются сами пользователи. Они авторизируют поставщика МИС, через которого хотят работать с eHealth. Для этого используется oauth2.0 flow.

Схема взаимодействия с eHealth

Почему именно мы делаем платформу

Проектный офис eHealth обратился к пулу разработчиков с предложением создать демо-версию основной функциональности платформы. Потенциальным подрядчикам выдвинули следующие условия:

  1. соответствие техническим условиям;
  2. готовность разрабатывать продукт на открытом коде;
  3. отсутствие конфликта интересов в разработке центрального компонента системы и отдельных медицинских информационных систем;
  4. полная поддержка Меморандумов, описывающих основные принципы взаимодействия всех участников разработки;
  5. готовность разработать MVP на условиях pro bono;
  6. соблюдение сроков разработки MVP, установленных МОЗ.

Портфель реализованных проектов компании EdenLab на момент знакомства с проектным офисом eHealth состоял из десятков реализованных систем высокого уровня сложности. Среди них построение кредитных решений для клиентов с миллионными портфелями, транзакционные сервисы и продукты, в том числе и собственные проекты Pay2You и mBill, специальные сервисы на основе платформы Mastercard Moneysend, CRM и BPM интеграционные проекты.

Проектам Fintech-домена свойственны высокие требования к безопасности, защите систем и данных, нагруженности и устойчивости, которые актуальны и для платформы цифрового здравоохранения. Все это добавило аргументов в нашу пользу. 

EdenLab согласилась со всеми требованиями проектного офиса eHealth и приступила к разработке в марте 2017 года. В первых числах апреля в МОЗ показали  демо-версию, в июне – вышел релиз функциональности MVP с регистрацией клиник и докторов. В ноябре в продакшене находится полный процесс капитации (финансирования), а процесс реимбурсации (англ. reimbursement — выплата компенсаций) готовится к релизу.

Взаимодействие сторон: МОЗ – Проектный офис – доноры – Edenlab

Для реализации такого сложного и масштабного проекта, как eHealth, недостаточно разработать сам программный продукт. Каждое требование проходит большой цикл до того, как будет написана первая строчка кода. Министерство охраны здоровья Украины в этом процессе выступает визионером и видит проблемы здравоохранения в целом. Со стороны МОЗ работу Координационного совета и рабочих групп возглавляет заместитель министра Павел Ковтонюк.

В дальнейшем, когда проблема или точка инновации становится очерченной, в работу вступает команда проектного офиса. Его совместно с министерством создали международная антикоррупционная организация Transparency International и крупнейшая в Украине организация пациентов “Мережа ЛЖВ”. Проектный офис занимается созданием детальных функциональных требований к программному продукту, координирует разработку, отвечает за внедрение новой системы на местах и поддержку пользователей. За работу проектного офиса, который напрямую взаимодействует и с советом, и со всеми рабочими группами, отвечает Юрий Бугай.

Кроме того, Проектный офис занимается работой с донорами, которые должны быть уверены, что проблема по-настоящему важна для реформирования медицины в Украине. Они заинтересованы в том, чтобы система создавалась прозрачно и в соответствии со всеми мировыми стандартами. Как часто бывает в подобных проектах, за все эти пункты отвечают компании большой четверки аудиторов. Создание электронной системы охраны здоровья финансово поддерживают проекты международной технической помощи, в том числе от правительств Канады и США.

EdenLab, который возглавляет Марина Квашнина, уже как разработчик полного цикла, взаимодействует, с проектным офисом e-Health: от помощи в формулировании бизнес требований до сдачи реализованных проектов в эксплуатацию.

Архитектура eHealth

Из вводных проекта:

  1. Opensource – все репозитории должны быть в публичном доступе. Управление требованиями, документация и трекинг задач тоже. Так минимизируется риск vendor lock-in (привязка к конкретному разработчику) и сохраняется возможность развития системы другими командами, в том числе волонтерскими.
  2. Реестр пациентов должен быть независимой системой и к нему стоит относиться как к внешнему сервису.
  3. Решение на начальном этапе хостится в Google Cloud Platorm, но есть возможность относительно простой миграции на on-premise дата-центр. Так как система, в конечном итоге, должна пройти сертификацию КСЗИ. Поэтому использование нативных сервисов облачного провайдера должно быть сведено к минимуму.
  4. Все «важные» действия в системе должны быть подписаны электронной цифровой подписью.
  5. Данные в реестрах должны быть максимально защищены от изменений, в том числе людьми, администрирующими систему.

После более детального анализа требований и начальной фазы дизайна были приняты следующие архитектурные решения.

1. Микросервисная архитектура

  • минимизация зависимости от технологического стека – в случае необходимость, каждый сервис можно переписать на любом языке. А такая необходимость потенциально может возникнуть по многим причинам. Так требования могут развиваться не так как предполагалось, и другая технология справится с новыми задачами лучше;
  • упрощение развития проекта в будущем различными командами;
  • упрощение управлением поставками.

Такое решение помимо преимуществ аукнулось рядом проблем для команды, существенно повлияв на скорость и объем разработки. Но это тема для отдельного рассказа.

2. Elixir – как основной язык для бекенда.

3. React – для фронтенда.

4. PostgreSQL – база данных.

5. Все приложения контейнеризированы с помощью Docker.

6. Kubernetes – автоматизация деплоймента, масштабирования и управление приложениями в контейнерах. Благодаря Kubernetes, при миграции на on-premise дата-центр с точки зрения приложения runtime среда не сильно изменяется. Все сложности сконцентрированы на разворачивании самого Kubernetes, что должно упростить миграцию.

7. Github был выбран в качестве системы контроля версий и трекера задач.

8. Авторизация по oAuth 2.0 flow – практически отсутствует централизованная система управлением доступами. Используется принцип каскадной саморегистрации. Руководители клиник регистрируют клинику с использованием ЕЦП, получают доступ в систему и регистрируют других пользователей.

9. Так как основной результат работы eHealth – работающий API, очень важно качественно управлять его спецификациями. Существенный фактор успеха – возможность одновременной разработки центрального компонента и клиентов  API. Поэтому спецификация была разработана на самых ранних этапах проекта.

Команда использовала Apiary.io для документирования API и публикации для конечных пользователей – производителей информационных систем. Этот инструмент позволяет использовать  markdown и mockserver, а значит аналитики могут легко разрабатывать спецификацию вместе с разработчиками. А потребители сервисов могут легко вести свою разработку используя mock-server.

10. Blockchain. Одной из важнейших сущностей в работе системы, являются декларация сотрудничества между врачом и пациентом. Она защищена работой алгоритма целостности данных на основе blockchain. Все декларации попадают в базу данных и на основе этих данных создаются хеш-ключи, которые зависят от деклараций, уже введенных в систему. Каждый день создается блок хеш-ключей, которые используются дальше в декларациях нового дня. Таким образом система гарантирует, что даже суперадминистратор системы не может изменять данные деклараций.

Архитектура eHealth

Почему Elixir

Elixir очень молодой язык программирования, основанный на уже проверенной годами виртуальной машине Erlang (ErlangVM). Он идеально подходит для высоконагруженных распределенных систем, так как его прародитель Erlang был создан для решения задач такого рода. А проект eHealth – как раз высоконагруженная система, которая требует высоких показателей доступности и минимального времени отклика. Elixir использует все наработки Erlang и добавляет много высокоуровневых абстракций, что позволяет увеличить скорость разработки при этом использовать всю мощь ErlangVM.

Сейчас, после 6 месяцев разработки, более 2 000 комитов в основном репозитории, eHealth находится в продуктиве, где система проходит свой тестовый период с точки зрения становления. Уже успешно прошли программу тестирования и подключены пять медицинских информационных систем (МИС), зарегистрировано более 600 медицинских учреждений, 2 000 врачей, заключено более 2 000 деклараций пациентов. В течение 2017 года система eHealth работает в тестовом режиме. Это означает, что регистрация является добровольной и решение принимает каждое учреждение самостоятельно. Тестовый режим позволит проанализировать обратную связь от пользователей и лучше подготовиться к внедрению следующих этапов реформы.

Планы на будущее

Сейчас в процессе разработки находится процесс реимбурсации, кроме него в 2017 году будут реализованы брокер-менеджмент, инструменты аналитики и целый ряд инфраструктурных задач. Проектный офис вместе с МОЗ, экспертами, донорами активно работает над стратегией развития системы, как части общей реформы здравоохранения Украины, и до конца текущего года получит ответы на основные вопросы развития. Мы планируем, что к развитию системы присоединятся другие разработчики, сервис-провайдеры, поставщики отдельных решений. Задач и вызовов хватит на всех, кто готов работать и делится своей экспертизой.

Автор: Марина Квашнина, руководитель EdenLab