среда, 31 августа 2016 г.


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

Перевод оригинальной статьи из блога Дэвида Хэя от 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).

Комментариев нет:

Отправить комментарий