Provenance и Audit: друзья-товарищи!
Данная статья не принадлежит Дэвиду Хэю, однако очень тесно связана c предыдущим постом нашего блога (к тому же Дэвид сам очень рекомендует с ней ознакомиться), в связи с чем ее и публикуем. Оригинал статьи можно найти здесь.
 |
| Модель W3C в теории |
Все же, между этими ресурсами имеется некоторое различие. Обсуждение в рамках этой статьи идет в первую очередь о стандарте FHIR, хотя на высоком уровне абстракции сами концепции "аудита" (audit) и "происхождения данных" (provenance) выходят за рамки стандарта и действительно имеют много общего.
Согласованием предложенной консорциумом 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" (о нарушении конфиденциальности данных).
В стандарте FHIR понимание концепции "происхождение" (provenance) несколько отличается от "вышколенной теории" выше. Причина следующая: представленные стандартом FHIR концепции стремятся к объективному отражению системы здравоохранения. Вторая причина: в здравоохранении понятие "provenance" имеет вполне устоявшееся значение, ему уделяется внимание во многих стандартах, связанных с оказанием медицинской помощи. В наследуемых системах данные о происхождении (provenance data) и журнал аудита (audit log) часто существуют как часть базы данных учреждения. Из всего этого можно сделать вывод, что домен, в котором сосуществуют оба вышеуказанных понятия для нас далеко не нов.
В стандарте 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 (место совершения некоторого действия) и т.д.
Ресурс AuditEvent позволяет фиксировать данные, которые будут использоваться при проведении аудита, более детально (а, значит, лучше), чем практические реализации W3C-модели. Ресурс AuditEvent, входящий в состав FHIR, может, в сущности, описать любое событие, а не только относящее к категории "provenance". AuditEvent описывает любое событие, имеющее отношение к обеспечению конфиденциальности и защищенности данных, а не только операции совершаемые над данными. Большое преимущество этого ресурса в том, что он может фиксировать одинаково хорошо как успешные, так и неудавшиеся попытки доступа. Такой функционал особенно нужен в здравоохранении: к большому сожалению, во многих информационных системах, доступ к данным предоставляется на основании аутентификации пользователя, а не с помощью корпоративного сервиса аутентификации (SAML, OAuth и т.д.). AuditEvent записывает информацию о совершенном запросе, что выпадает за рамки provenance-данных (+ некоторые другие события). Также как и абстрактное понятие "provenance", абстракция "AuditEvent" хорошо ложится на модель FHIR (используются fhir-представления понятий "agent", "entity", location, organization и т.д.)
Журнал аудита, как правило, составляется так, что содержит много избыточных данных: простая операция по созданию ресурса (create) приводит к генерированию большого количества записей в журнале аудита (не менее двух). Избыточность неслучайна, т.к. она необходима для проверки корректности работы системы. Поэтому, для проведения анализа журнал аудита приходится тщательно "подчищать", используя различные фильтры, отчеты, оповещения и выгрузки.
Т.о. provenance-ресурс может быть создан для любого из фрагментов данных ил сам может являться частью определенного фрагмента данных. Provenance-ресурс может быть создан для любого фрагмента данных. График показывает количественное соотношение "всех записей" (enrtries of data) к записям в "журнале аудита" (audit log) к "provenance-записям" (provenance record). Он не отражает всей картины, однако, является в достаточной степени репрезетативным.
Для каждого события обращения к данным (access to data event) будет создан т.н. AuditEvent. Обращение к данным, содержащимся в ресурсе AuditEvent также повлечет за собой создание генерирование нового ресурса AuditEvent. AuditEvents генерируются для каждой операции авторизации в системе, для запуска и завершения работы системы и т.д., что делает AuditEvent "самым часто встречающимся" fhir-ресурсом.
Provenance
Существуют и (редкие) исключения из описанного шаблона. Обе категории информации являются равнозначно важными. Надеюсь, что в этом посте я достаточно подробно объяснил, почему модель W3C не подходит в нашем случае.
Начнем с теории
 |
| Модель HL7 в теории |
"Provenance" (происхождение) - это сведения (записи) о сущностях и процессах, участвующих в создании, обновлении и перемещении ресурсов или иным образом воздействующих на ресурс. Данные, относящиеся к категории "provenance" обеспечивает проведение оценки аутентичности, надежности и прослеживаемости некоторого объекта (сущности). Иными словами, информация, подпадающая под понятие "происхождение" (provenance) отвечает на вопросы: "кто автор?", "зачем была зафиксирована информация?", "кто внес обновления?", "зачем данные были обновлены?", "когда были обновлены данные?", "что послужило причиной обновления данных?". Если место хранения данных изменилось, информация об их первоначальном месте хранения также можно считать информацией о происхождении. Согласно модели W3C, к данного рода информации также следует относить данные о запросах доступа или адресатах при пересылке данных.
Аудит (и аудиторские данные) - это более широкое понятие, в семантическое поле которого также включаются понятия и концепции, связанные с обеспечением конфиденциальности (privacy) или безопасности (security) и набор действий над данными (CRUD). Аудит данных - это ведение журнала о всех действиях над данными, но также о действиях, которые были совершены над другими защищенными ресурсами. Журнал аудита ведется в качестве документального подтверждения того, что система работает должным образом и, следовательно, смысл аудита заключается в обнаружении ситуаций, когда система ведет себя некорректно. Реализация политики безопасности, и, в частности, ведение аудита позволяет выявлять существующие проблемы с обеспечением конфиденциальности (confidentiality), целостности данных (integrity) и их доступности (availability) в системах. На основании таких "аудиторских данных" составляются отчеты типа "Accounting of Disclosures" (о нарушении конфиденциальности данных).
(Иная) реальность
 |
| Исторический подход к понятиям provenance и audit |
 |
| Подход в стандарте 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С-модели |
Что "шире" - "provenance" или "AuditEvent"?
Ресурс provenance используется для описания (большого) события, которое в свою очередь может составляться из ряда других событий, каждое из которых представляет интерес с точки зрения проведения последующего аудита. Например, для создания заказа на процедуру (order for procedure) врачу потребуется просмотреть несколько записей в ЭМК пациента, связать направление с конкретным обращением (encounter), возможно, создать несколько fhir-ресурсов, которые необходимы для данного заказа (например, данные по заказу передаются также в ресурсе Specimen). Для описанного случая будет создан ресурс "provenance" со ссылкой на ресурс DiagnosticOrder (DiagnosticOrder будет указан в элементе "provenance.target"). (Вообще-то, это не самый удачный пример, т.к. данные, которые можно отнести к категории provenance, и так содержатся в ресурсе DiagnosticOrder, ну да ладно...) Provenance в нашем случае будет содержать данные, которые врач посчитал важными при просмотре ЭМК (разница в Provenance.entity от всех зафиксированных AuditEvents).
Т.о. 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 не подходит в нашем случае.
Комментариев нет:
Отправить комментарий