Что такое SMART и почему он так крут?

В этой статье будет подведен итог всем высказанным и невысказанным мыслям Дэвида Хэя о SMART. Оригинальный текст статьи можно найти здесь.

Введение

Все, кто по каким бы то ни было причинам связан с обменом данными в здравоохранении (с точки зрения обеспечения его интероперабельности, прежде всего), слышали о FHIR, стандарте HL7 "нового поколения" с явным приоритетом на реализацию. Практическое применение стандарта упрощается тем, что HL7 FHIR использует подходы, неспецифические для здравоохранения. Например, для представления клинических концепций ("аллергии", "препараты", "заболевания" и т.д.) используются "ресурсы" (resources), а для взаимодействий используется популярный сейчас (даже у таких игроков рынка как Google, Twitter и Facebook) REST API.
FHIR настолько "хорош собой", что на него переходят серьезные разработчики решений в области медицины - Epic, Cerner, Allscripts и Orion Health - не говоря уже о государственных агентствах, чья деятельность связана с обменом данными в здравоохранении (ONC США, NHI Великобритании, новозеландская HINZ и австралийская NEHTA).
Помимо FHIR всех нас также взволновала и новая аббревиатура, SMART, которая "разворачивается" в название "Совместимые медицинские приложения и технологии многократного применения" (Substitutable Medical Applications and Reusable Technologies). SMART пока что не так популярен как FHIR, но в некоторых организациях он вызывает все больший практический интерес.

Говоря простым языком, SMART добавляет к FHIR-интерфейсу прослойку безопасности (layer of security). Для аутентификации и авторизации используется протокол OAuth2, а OpenID Connect обеспечивает идентификацию пользователей, контроль за выдачей прав доступа к данным и выполнения операций над ними. SMART также определяет процедуру запуска внешних медицинских приложений "центральной" системой для работы с иЭМК. Важным условием при этом является сохранение контекста и обеспечение безопасности доступа к данным иЭМК.

А теперь подробнее...

Стэк технологий SMART первоначально рассматривался как стандарт, обеспечивающий защищенный обмен данными между системой ведения иЭМК и внешними узкоспециализированными медицинскими приложениями. Суть подхода заключалась в стандартизации взаимодействия медицинских приложений по типу "центр - периферия". Иными словами, создавалась целая "экосистема" из приложений и хранилищ данных, аналогичная той, в которой функционируют мобильные приложения, разделяющие ресурсы устройства (например, камеру, список контактов и т.д.).
Первые версии SMART использовали собственные определения данных и кастомные API, но, после "признания" FHIR, SMART был переориентирован на архитектурные решения HL7.
Проблема, которую призван решить SMART, заключается в следующем: значительное кол-во медицинской информации, сосредоточенной в системах ведения иЭМК, является замкнутой (в этих системах). Ранее, любое специализированное приложение, которое в процессе работы обращалось к данным EHR-системы, полноценно функционировало только в том случае, если и приложение и EHR-система были разработаны одним и тем же поставщиком. Соответственно, никаких стимулов и условий для разработки узкоспециализированных медицинских приложений не было. Разделив роли приложений на "поставщика данных" (data supplier) и "потребителя данных" (data supplier), мы обеспечили разработчиков приложений всеми условиями для создания специализированных медицинских приложений, пользующихся данными различных хранилищ. С течением времени описанный подход эволюционировал в некий "обобщенный" стандарт, обеспечивающий защищенный доступ к FHIR-ресурсам.
Стэк технологий, входящих в SMART, решает следующие задачи:

• Идентификация клиентского приложения и выдача прав доступа к данным иЭМК. Для данных целей используется стандарт OAuth2.
• Определение данных, к которым предоставляется доступ. Для этой цели используются FHIR-ресурсы и профили, уточняющие ресурсы (по факту, профили позволяют "уточнить" сами медицинские данные). В качестве механизма запросов используется FHIR REST API.
• SMART позволяет запускать внешние приложения из "центральной" EHR-системы с сохранением контекста приложения (т.е. информации о текущем пациенте и пользователе).

Идентификация клиента и получение прав доступа

Из стандарта OAuth2 в SMART был заимствован целый набор "ролей":

1. "Поставщик ресурсов" (resource provider). Данную роль выполняет система, которая через FHIR-интерфейс предоставляет клиентскому приложению доступ к данным.
2. "Сервер авторизации" (authorization server) - это компонент инфраструктуры, который обеспечивает идентификацию и авторизацию как клиентского приложения, так и пользователя, запрашивающего доступ к данным. Сервер авторизации может быть реализован в составе "resource provider", хотя это и не обязательно.
3. Приложение (app) - это приложение, требующее доступа к информации (например, мобильное приложение).
4. Пользователь (user) - человек, использующий приложение.

Хотя, с точки зрения деталей, реализации SMART могут существенно отличаться ввиду локальных особенностей здравоохранения или технических требований, на наивысшем уровне абстракции все выглядит достаточно просто и "стандартно". Обязательным условием является регистрация внешнего приложения сервером авторизации (внесение в список доверенных) и получение идентификационного ключа.
Когда пользователь с помощью приложения запрашивает доступ к данным:

• Сервер авторизации проверит наличие приложения в списке доверенных (для этого приложение предоставляет серверу тот самый ключ). Наличие ключа позволяет серверу авторизации изменять свое поведение в зависимости от возможностей приложения.
• Затем сервер авторизации выполняет идентификацию пользователя приложения, которая может быть простой проверкой логина и пароля или выполняться другим доверенным способом.
• Сервер авторизации определяет набор данных, доступный для конкретного пользователя и приложения, а также доступные для пользователя операции (read, insert, update, delete). В этом пункте также многое зависит от деталей реализации. Доступные пользователю данные и операции над ними определяются как "область видимости" (scope) приложения и SMART предусматривает способы формализованного описания такой области видимости. Например, в "область видимости" может входить только "чтение информации о пользователе" (имя, дата рождения, адресе и т.д.).
• После идентификации пользователя и определения области видимости, сервер авторизации предоставляет клиентскому приложению токен (access token), который он затем будет запрашивать у него каждый раз при запросе доступа к данными.
• В самом конце приложение отправляет FHIR-запрос дата-серверу (Resource Server), помещая в запрос токен доступа (access token).
• Дата-сервер проверяет подлинность токена, наличие у пользователя прав на выполнение запрашиваемой операции над запрашиваемыми данными. В случае успешного прохождения аутентификации, пользователю выдается разрешение на выполнение соответствующей операции.

Описанный выше процесс в форме диаграммы:

Детали этого процесса сильно зависят от реализации "центральной" части. Например, сервер авторизации (Authorization Server) может вставить описание "области видимости" (scope) доверенного приложения (для обеспечения безопасности - в зашифрованном виде и подписанное цифровой подписью) в токен доступа (access token). Или, токен доступа может быть произвольным ключом, который дата-сервер будет запрашивать при получении каждого запроса к данным и перенаправлять серверу авторизации для проверки его подлинности. Вне зависимости от того, как именно будет реализована серверная часть, процедура обращения клиентских приложений к серверу всегда будет одинаковой.

API и содержание данных

Еще одной важной особенностью SMART является использование стандартного подхода к представлению данных (через FHIR-ресурсы). Стандарт FHIR сам определяет внутреннюю структуру (т.е. набор элементов, типы данных и т.д.) значительного кол-ва ресурсов (например, такого ресурса как Allergy), однако все "стандартные" ресурсы имеют слишком "общее" содержание (т.е. не могут полностью описать всю специфику конкретных ситуаций их применения). Ресурсы могут быть "адаптированы" для удовлетворения конкретных клинических требований, через профили. Данный процесс называется "профилированием ресурсов" (resource profiling). Хотя это и не является условием обеспечения интероперабельности, желательно, чтобы и клиентская и серверная стороны однообразно понимали профили, поэтому, SMART дает определение "стандартного профиля" (standard profile).

По факту, вопрос профилей в стандарте SMART все еще не решен: уже существует "SMART-профиль", однако в США набирает обороты проект Data Access Framework (DAF), цель которого - стандартизация методов доступа к данным о здоровье (стандартизация запросов, API и сервисов, предоставляющих доступ к данным). В рамках этого проекта также идет определение национального набора и формата профилей, операций, наборов значений и заявлений о совместимости (conformance statements), которые должны поддерживать все MU2-совместимые системы и приложения (Meaningul Use Stage 2). Наблюдается некоторое движение по созданию аналогов DAF в других странах мира (в первую очередь в Канаде), поэтому, скорее всего в будущем SMART позволит клиентской стороне указывать список поддерживаемых профилей в процессе установления взаимодействия (negotiation process) с центральной системой.

Запуск приложения

SMART предусматривает "варианты" запуска приложений:

• "автономный запуск" (standalone launch). Автономный запуск можно описать так: внешнее (периферическое, специализированное) приложение запрашивает доступ к данным через внешний API (в соответствии с вышеописанным процессом).
• "из приложения" (запуск системой ведения иЭМК). "Запуск EHR-системой" представляет собой запуск приложения, поддерживающего SMART, с сохранением текущего "контекста" (данных о текущем пользователе и пациенте).

Как происходит запуск приложения системой ведения иЭМК:

• Пользователь вызывает запуск доверенного внешнего приложения (например, щелчком по ссылке, помещенной на одной из рабочих панелей приложения).
• "Центральное" приложение хранит "контекст" и создает токен запуска (launch token), который ссылает на место хранения "контекста". Альтернативным решением было бы хранение контекста в самом токене (для безопасности предварительно зашифровав данные и подписав их цифровой подписью).
• Затем приложение проходит аутентификацию (по ранее описанной процедуре).
• После аутентификации, приложение предоставляет дата-серверу токен запуска (access token) при каждом обращении к нему. Дата-сервер использует токен для определения контекста, в котором происходит запрос: токен может использоваться в качестве ключа к некоторому внутреннему хранилищу или дешифруется сам токен и читается содержащийся в нем контекст. Это уже детали реализации.

Сразу следует отметить, что и другие аспекты реализации SMART (речь именно идет о серверной части) могут также значительно отличаться. Но, до тех пока сохраняется и соблюдается набор правил взаимодействия (SMART-интерфейс) клиентского приложения и серверной части, все это не имеет такого уж большого значения.

SMART : перспективы развития

SMART (как и FHIR) - это развивающийся стандарт, и, скорее всего, он еще будет неоднократно изменен и расширен. Нам же следует ждать следующего:

• SMART станет фактическим стандартом обеспечения безопасного взаимодействия по FHIR-интерфейсу. FHIR не дает определения каким-либо механизмам защиты, оставляя этот вопрос на усмотрение разработчика. Учитывая то, что сам SMART базируется на широко распространенных стандартах, вполне вероятно, что именно он и станет общепризнанным механизмом защиты.
• Поддержка профилей. Уже сейчас SMART стремиться к тому, чтобы пользователь мог самостоятельно описывать набор поддерживаемых профилей.
• CDS Hooks - новый подход, стандартизирующий вызов функций поддержки принятия решений в ходе выполнения стандартных операций, предусмотренных FHIR-интерфейсом. Стандарт SMART (особенно, если он станет широко распространенным) поможет облегчить доступ к средствам поддержки принятия решений для систем ведения иЭМК и ЭМК.