Provenance и Audit: друзья-товарищи!

Данная статья не принадлежит Дэвиду Хэю, однако очень тесно связана c предыдущим постом нашего блога (к тому же Дэвид сам очень рекомендует с ней ознакомиться), в связи с чем ее и публикуем. Оригинал статьи можно найти здесь.

С какой-то точки зрения может показаться, что fhir-ресурсы, используемые для представления

Модель W3C в теории

таких понятия как "provenance" (дословно переводится как "происхождение [данных]") и "audit" (т.е. входные данные для проведения аудита учреждения здравоохранения) используются для передачи очень схожего, если не абсолютно одинакового набора данных. 

Все же, между этими ресурсами имеется некоторое различие. Обсуждение в рамках этой статьи идет в первую очередь о стандарте FHIR, хотя на высоком уровне абстракции сами концепции "аудита" (audit) и "происхождения данных" (provenance) выходят за рамки стандарта и действительно имеют много общего.

Начнем с теории

Модель HL7 в теории

Согласованием предложенной консорциумом W3C модели для формализованного представления происхождения данных и исторически устоявшихся интерпретаций таких понятий как "audit" и "provenance" в непосредственной привязке к отрасли здравоохранения всерьез занялся консорциум HL7. (Модель W3C называется "provenance model" и позволяет дать формальное описание происхождения некоторой сущности.) Стоит отметить, что и сама модель W3C родилась не "на голом месте", т.е. уже существовали более-менее оформившиеся подходы к понятию "происхождение" или "источник [данных]", которые и были проанализированы W3C. Нельзя сказать, что модель W3C является неполной, однако, она не полностью соответствует модели и принципам HTTP REST, в то время как нам требуется именно такая модель. Поэтому, ее созданием и занялся консорциум HL7.

"Provenance" (происхождение) - это сведения (записи) о сущностях и процессах, участвующих в создании, обновлении и перемещении ресурсов или иным образом воздействующих на ресурс. Данные, относящиеся к категории "provenance" обеспечивает проведение оценки аутентичности, надежности и прослеживаемости некоторого объекта (сущности). Иными словами, информация, подпадающая под понятие "происхождение" (provenance) отвечает на вопросы: "кто автор?", "зачем была зафиксирована информация?", "кто внес обновления?", "зачем данные были обновлены?", "когда были обновлены данные?", "что послужило причиной обновления данных?". Если место хранения данных изменилось, информация об их первоначальном месте хранения также можно считать информацией о происхождении. Согласно модели W3C, к данного рода информации также следует относить данные о запросах доступа или адресатах при пересылке данных.

Аудит (и аудиторские данные) - это более широкое понятие, в семантическое поле которого также включаются понятия и концепции, связанные с обеспечением конфиденциальности (privacy) или безопасности (security) и набор действий над данными (CRUD). Аудит данных - это ведение журнала о всех действиях над данными, но также о действиях, которые были совершены над другими защищенными ресурсами. Журнал аудита ведется в качестве документального подтверждения того, что система работает должным образом и, следовательно, смысл аудита заключается в обнаружении ситуаций, когда система ведет себя некорректно. Реализация политики безопасности, и, в частности, ведение аудита позволяет выявлять существующие проблемы с обеспечением конфиденциальности (confidentiality), целостности данных (integrity) и их доступности (availability) в системах. На основании таких "аудиторских данных" составляются отчеты типа "Accounting of Disclosures" (о нарушении конфиденциальности данных).

(Иная) реальность

Исторический подход к понятиям provenance и audit

В стандарте FHIR понимание концепции "происхождение" (provenance) несколько отличается от "вышколенной теории" выше. Причина следующая: представленные стандартом FHIR концепции стремятся к объективному отражению системы здравоохранения. Вторая причина: в здравоохранении понятие "provenance" имеет вполне устоявшееся значение, ему уделяется внимание во многих стандартах, связанных с оказанием медицинской помощи. В наследуемых системах данные о происхождении (provenance data) и журнал аудита (audit log) часто существуют как часть базы данных учреждения. Из всего этого можно сделать вывод, что домен, в котором сосуществуют оба вышеуказанных понятия для нас далеко не нов.

Подход в стандарте FHIR

В стандарте FHIR отражено "свое" представление понятия "происхождение данных" (provenance), которое учитывает особенности здравоохранения. С позиции FHIR provenance-ресурс это т.н. W5-report или отчет, отвечающий на 5 w-вопросов ("кто, что, где, когда, зачем", на английском языке - "Who, What, Where, When, Why"). Данные, которые наполняют данный ресурс и отвечают на эти вопросы, можно найти в элементах любого клинического или "финансового" ресурса. Отсюда можно сделать вывод, что использование provenance-ресурсов означает, по сути, дублирование данных, содержащихся в полях базовых элементов других ресурсов (и мало кому в голову придет вообще такое делать!). Но, делают же! Provenance-ресурсы предусмотрены в стандарте FHIR на тот случай, когда требуется явная запись о происхождении данных, касающихся объекта или сущности.

provenance-ресурс фиксирует кто, где, когда и зачем совершал crud-операции "create" и "update". provenance-ресурсы позволяют опознать источник данных при их передаче (transfer). Однако, (что обидно) никак не фиксируется, кто, когда и зачем получал доступ данным ресурса (если выполнялась операция read). Вот "классический случай" использования provenance-ресурса: чаще всего это происходит при импорте данных (ресурсов) на сервер, когда известно, что некоторые данные полей ресурса уже не являются актуальными. С помощью provenance-ресурса подписываются цифровой подписью ресурсы, информацию о которых он в себе содержит (ресурсы provenance существуют в привязке к другим ресурсам). Кроме того, с помощь этого ресурса может быть представлена информация о том, как ранее использовался набор интересующих нас данных. Часто provenance-ресурс предоставляет данные о том, кто обновил данные в ресурсе. Все вышеописанное хорошо ложится на модель FHIR, в которой используются стандартные понятия, такие как target ("цель", в данном случае в элементе "provenance.target" указывается ресурс, который описывается настоящим provenance-ресурсом), agent (поле "provenance.agent" содержит информацию о том, кто несет ответственность за те или иные действия), entity ("provenance.entity" содержит сущности, участвующие в данном событии), location (место совершения некоторого действия) и т.д.

Так  выглядит практическая реализация W3С-модели

Ресурс AuditEvent позволяет фиксировать данные, которые будут использоваться при проведении аудита, более детально (а, значит, лучше), чем практические реализации W3C-модели. Ресурс AuditEvent, входящий в состав FHIR, может, в сущности, описать любое событие, а не только относящее к категории "provenance". AuditEvent описывает любое событие, имеющее отношение к обеспечению конфиденциальности и защищенности данных, а не только операции совершаемые над данными. Большое преимущество этого ресурса в том, что он может фиксировать одинаково хорошо как успешные, так и неудавшиеся попытки доступа. Такой функционал особенно нужен в здравоохранении: к большому сожалению, во многих информационных системах, доступ к данным предоставляется на основании аутентификации пользователя, а не с помощью корпоративного сервиса аутентификации (SAML, OAuth и т.д.). AuditEvent записывает информацию о совершенном запросе, что выпадает за рамки provenance-данных (+ некоторые другие события). Также как и абстрактное понятие "provenance", абстракция "AuditEvent" хорошо ложится на модель FHIR (используются fhir-представления понятий "agent", "entity", location, organization и т.д.)

Что "шире" - "provenance" или "AuditEvent"?

Ресурс provenance используется для описания (большого) события, которое в свою очередь может составляться из ряда других событий, каждое из которых представляет интерес с точки зрения проведения последующего аудита. Например, для создания заказа на процедуру (order for procedure) врачу потребуется просмотреть несколько записей в ЭМК пациента, связать направление с конкретным обращением (encounter), возможно, создать несколько fhir-ресурсов, которые необходимы для данного заказа (например, данные по заказу передаются также в ресурсе Specimen). Для описанного случая будет создан ресурс "provenance" со ссылкой на ресурс DiagnosticOrder (DiagnosticOrder будет указан в элементе "provenance.target"). (Вообще-то, это не самый удачный пример, т.к. данные, которые можно отнести к категории provenance, и так содержатся в ресурсе DiagnosticOrder, ну да ладно...) Provenance в нашем случае будет содержать данные, которые врач посчитал важными при просмотре ЭМК (разница в Provenance.entity от всех зафиксированных AuditEvents).

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

Т.о. provenance-ресурс может быть создан для любого из фрагментов данных ил сам может являться частью определенного фрагмента данных. Provenance-ресурс может быть создан для любого фрагмента данных. График показывает количественное соотношение "всех записей" (enrtries of data) к записям в "журнале аудита" (audit log) к "provenance-записям" (provenance record). Он не отражает всей картины, однако, является в достаточной степени репрезетативным.

Для каждого события обращения к данным (access to data event) будет создан т.н. AuditEvent. Обращение к данным, содержащимся в ресурсе AuditEvent также повлечет за собой создание генерирование нового ресурса AuditEvent. AuditEvents генерируются для каждой операции авторизации в системе, для запуска и завершения работы системы и т.д., что делает AuditEvent "самым часто встречающимся" fhir-ресурсом.

Обозначим разницу между обозначенными ресурсами:

Audit

• информация данной категории предназначается для службы безопасности, отдела конфиденциальности (privacy office) и отдела информатизации организации (IT Office);
• анализ данной информации занимает ограниченное кол-во времени (минуты / часы / дни);
• аудиторская информация может быть отфильтрована, переслана, на ее основе могут составляться отчеты;
• часть аудиторской информации впоследствии может быть уничтожена или перемещена в автономное хранилище данных.

Provenance

• предоставляется медицинским специалистам, специалистам, отвечающим за расчет стоимости оказанных услуг (биллинг), специалистам по качеству и безопасности;
• на provenance-данные нельзя ссылаться или опираться при подготовке отчетов,
• однако, эта категория данных является частью ЭМК и существует столько же, сколько и сами записи ЭМК, которые они описывают
  provenance-данные - это метаданные, которые сопровождают некоторый набор данных.

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

"Откуда данные?"

Перевод оригинальной статьи из блога Дэвида Хэя от 18 февраля 2016 года.

Этот серьезный вопрос был задан одним из аналитиков "в недрах" Orion Health, где Дэвид занимает должность product strategist. Сейчас компания Orion Health разрабатывает и встраивает FHIR-интерфейсы для своих программных продуктов, которые уже "выложены на прилавок". Кроме того, они также встраивают FHIR-интерфейсы в используемые хранилища данных.

Репозиторий данных OrionHealth принимает потоки данных (data feeds) из самых разнообразных источников, по большей части в форме v2-сообщений, но также и в виде C-CDA-документов, извлекая из них определенный набор клинических данных об обращениях, процедурах, заболеваниях и т.д. Из-за такого разнообразия источников мы даже используем отдельный элемент данных, в котором записывается информация об источнике информации (например, медучреждение или программное обеспечение). (При всем том, что нам хочется в первую очередь узнать о враче, который принимал участие в том или ином клиническом событии, такая информация, к сожалению, никак не представлена в v2-сообщений).

В общем, Дэвиду задали такой вопрос - "хорошо, а во что же нам "обернуть" информацию о происхождении данных, если мы будем хранить их в формате FHIR?"

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

Дальше больше. Как только мы стали погружаться в этот вопрос, все стало не так однозначно.

Связь между источником данных и самими данными выражается связью (ссылкой) между "provenance"-ресурсом и ресурсом, который используется для представления интересующих нас данных (связь provenance-ресурса с ресурсами, которые он описывает, определяется через ссылку в элементе "provenance.target"). Этот принцип также согласуется с другим "основополагающим" принципом FHIR: "связи всегда исходят от тех ресурсов, которые были созданы позднее к тем, которые были созданы ранее". В противном случае требуется обновление ресурсов (ведь приходится добавлять ссылки в ранее созданные ресурсы), а это существенно усложняет работу как сервера, так и клиента. Приведу пример: процедура (ресурс procedure) "ссылается" к пациенту (ресурс patient), а не наоборот. Только представьте весь ужас необходимости обновлять ресурс "patient", при добавлении каких-либо данных на сервер, касающихся этого пациента!

Ресурсы типа "provenance" должны быть представлены в связке ресурсов (bundle) отдельно. Для того, чтобы в интерфейсе приложения (вроде нашего ClinFHIR) информация об источнике данных также отображалась вместе с другими данными, оно должно будет найти и прочитать "provenance"-ресурс каждого ресурса в связке. Сложно, но можно! А нужно ли...

Было бы намного проще, если бы provenance-ресурс был "упакован" в тот ресурс, на который он ссылается. Но! Возникает другой вопрос - "кто на кого теперь ссылается?" Ресурс-контейнер всегда ссылается на вложенный в него ресурс, поэтому мы нарушаем вышеупомянутый "основополагающий" принцип FHIR.

Но это еще пол беды: provenance -ресурса оказалось недостаточно для решения конкретной поставленной нами задачи. Казалось, что элемент "agent" provenance-ресурса - самое подходящее место для хранения информации об источнике данных. Однако, согласно спецификации, этот элемент реализован как ссылка на другой fhir-ресурс (в частности "practitioner", "relatedPerson", "patient", "device", "organization"), который мы не идентифицируем кроме как в provenance-ресурсе. Конечно, можно также поместить информацию в элементе "display" (в нем содержится обычный текст, предназначенный для отображения человеку), но и это не самое подходящее место для информации о происхождении данных ресурса!

Т.е. огромный потенциал, которым обладают ресурсы типа "provenance", оказался просто ненужным!

Когда поставленный в самом начале вопрос перерос "в большую проблему", мы внесли его в рассылку по FHIR и получили очень полезный ответ от John Moehrke.

Как оказалось, на самом деле все это время мы строили некоторую модель на основании данных v2-сообщений. Когда речь шла, например, о процедуре, мы получали данные из сегмента PR1. Все что нам необходимо было сказать на счет происхождения данных можно было уместить в одной фразе - "эти данные получены из GoodHealth Clinic" (а такая информация стандартно содержится в сегменте MSH). И, конечно же, нам совершенно не нужна ссылка на исходное v2-сообщение, из которого мы получили данные о происхождении.

Вот если бы нам нужно было явно ссылаться на источник данных, то разумно было бы применить следующий подход:

• Сохранить где-то v2-сообщение, создать URI-ссылку на него;
• Создать набор производных их него ресурсов (также может потребоваться явно указать ссылки, существующие между ресурсами);
• Создать provenance-ресурс, который:
  
  • ссылается на все производные (от v2-сообщения) ресурсы через элемент "target" (Provenance.target).
  • ссылается на исходное v2-сообщение через "Provenance.entity.reference".
  • указать отправителя сообщения (вот то, что нам надо!) с помощью элемента Provenance.entity.agent (если помните, в этом поле содержится ссылка на fhir-ресурс);

Рекомендую ознакомиться с информацией об отображении данных v2-сообщений в ресурсы FHIR, которую разместил в своем блоге Рене Спронк (Rene Spronk).

Что такое 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 (особенно, если он станет широко распространенным) поможет облегчить доступ к средствам поддержки принятия решений для систем ведения иЭМК и ЭМК.