Рекомендуемый рабочий процесс для создания документа FHIR

Мы создали систему для создания записей анестезии.

Сейчас мы пытаемся смоделировать их как документы FHIR.

Я понимаю, что Документ (в терминах FHIR) должен стать своего рода автономным ресурсом.

Но в нашем случае у нас есть процесс, в котором этот документ будет постепенно собираться.

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

Мы хотим использовать FHIR для создания и сохранения различных ресурсов по ходу работы, а затем, в самом конце, собрать документ.

Предположим следующее:

  1. Пациент
  2. Провайдер
  3. История здоровья
  4. Некоторая информация о выполняемой процедуре
  5. Обширный набор наблюдений за жизненно важными показателями
  6. Обширный набор вводимых доз лекарств
  7. Различные процедуры и примечания по восстановлению
  8. Финальная подпись провайдера, который «завершит» отчет.

Я понимаю, что мы можем создавать и сохранять различные ресурсы повсюду. Но мы хотим, чтобы все они были собраны вместе, чтобы мы могли легко получить все, что связано с тем, что в конечном итоге станет этим документом.

Как это будет работать с точки зрения операций RESTful?

  1. POST / Bundle типа «документ» с композицией в качестве первого элемента (для создания документа)
  2. Использовать полученный идентификатор из пакета? Смогу ли я также получить идентификатор для композиции?
  3. Тогда как мне добавлять / обновлять / удалять отдельные элементы из композиции? Мне нужно делать PUT всей композиции, чтобы что-то добавить?
  4. Каждые 5 минут у меня есть целая серия контрольных точек с полными жизненно важными показателями (АД, SpO2, температура, частота дыхания и т. Д.). Могу ли я сначала создать эти наблюдения с помощью POST, а затем выполнить PUT, чтобы обновить композицию со ссылкой на них?

Как я уверен, вы можете сказать, я просто хочу понять, как FHIR ожидает от вас делать такие вещи с точки зрения операций HTTP.

Заранее благодарим за любые рекомендации!


person Henrik Joreteg    schedule 03.06.2020    source источник


Ответы (1)


Вы должны начать с публикации композиции, чтобы у вас была точка фокусировки (оглавление), которую нужно обновлять по мере сбора данных. Затем вы должны РАЗМЕСТИТЬ свои отдельные наблюдения, процедуры и т. Д. И либо ПОСТАВИТЬ, либо ПАТЧИРОВАТЬ композицию, чтобы добавить ссылки на соответствующие данные. После того, как вы собрали всю необходимую информацию и связали ее с композицией, вы должны сгенерировать пакет документов. Вы можете создать Bundle ранее в процессе и обновлять его каждый раз, когда Composition изменяется, если вы хотите иметь возможность визуализировать черновик документа с помощью инструмента визуализации документа FHIR, но в противном случае нет реальной причины для Пакет существует, пока вы не будете готовы заблокировать документ.

person Lloyd McKenzie    schedule 03.06.2020
comment
Это очень полезно. Спасибо, Ллойд! - person Henrik Joreteg; 04.06.2020
comment
то, с чем я все еще борюсь, пытаясь сделать это, - это то, что в Bundle есть запись, с которой я могу начать сбор всех наблюдений и т. д. Но для композиции есть раздел, который, как я полагаю, соответствует части окончательного отчета. Я полагаю, что у каждого из них тоже может быть запись, поэтому, когда вы говорите, что добавление ссылок на соответствующие данные - это именно то место, где вы говорите, что добавляете наблюдения и т. Д.? В составе ›раздел› запись? - person Henrik Joreteg; 27.06.2020
comment
Документ состоит из двух частей: Composition, который определяет навигацию, и Bundle, который объединяет все вместе. Пакет включает в себя композицию, все, на что она указывает, и, возможно, дополнительные ресурсы, так или иначе связанные с этим начальным набором ресурсов. Вы начинаете с определения своей композиции, включая ссылки на ресурсы, связанные с разделами вашего документа. Затем вы создаете свой Bundle, который включает эти ресурсы плюс любые другие, которые, по вашему мнению, понадобятся потребителю документа. - person Lloyd McKenzie; 28.06.2020
comment
Думаю, я начинаю понимать, еще раз спасибо, Ллойд! - person Henrik Joreteg; 28.06.2020