Запрос FHIR Search Slots

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

<Schedule xmlns="http://hl7.org/fhir">
<id value="1234" />
<actor>
    <display value="Cooper Thompson, MD" />
    <reference value="http://host/api/FHIR/DSTU2/Practitioner/1234" />
</actor>

Our Slot search ends up looking like this (with some edits for brevity and clarity, specifically around the slottype):

http://host/api/FHIR/DSTU2/Slot?Schedule.actor:Practitioner=1234&Schedule.actor:Patient=5678&slottype=urn:oid:1.2.3|Cardiology&start=2016-07-21

Обратите внимание, что это технически недопустимо, так как слот может иметь только одно расписание, и мы включаем несколько параметров поиска в цепочку для расписания. Мы также используем расширения для отправки назад пациента, практикующего врача и местоположения, связанного со слотом, поскольку Slot.schedule равен 1: 1. Однако это «преднамеренное неправильное использование» - лучший вариант, который я нашел, не заставляя клиента становиться системой планирования и заниматься выравниванием слотов для каждого ресурса.

Есть несколько элементов отслеживания (9989, 9208) в FHIR gforge о создании Обновления в Слоте, чтобы они были более удобными для «простых клиентов». Будем признательны за ваш вклад :).

Я могу что-то здесь упустить, но не уверен, как вы определяете разницу между слотом и расписанием?

Ресурс Schedule просто определяет период времени, в течение которого могут существовать слоты, и для какого другого ресурса. Он не определяет и не раскрывает встречи, которые могут существовать в это время.

параметры поиска слотов не определяют никаких параметров поиска, как вы подразумевали. Все они находятся в ресурсе расписания, с которого он ссылается.

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

Исходя из моего понимания того, что вы пытаетесь сделать (создание FHIR Façade перед системой управления практикой), я думаю, вам нужно будет предоставить следующие ресурсы:

• Практик: раскрыть подробности практикующего (интересно, могут ли ваши практикующие работать в нескольких местах)
• Расписание: чтобы просто показать диапазон дат, в который вы принимаете встречи (и будет определена доступность слотов), и практикующий связан с этим ресурсом, если они работают в нескольких местах, у вас будет один из этих диапазонов для каждого места, где работает практикующий специалист. . (Если ресурсы местоположения имеют собственное расписание, тогда необходимо будет дополнительно рассмотреть его и то, где выполняется согласование доступных слотов)
• Слот: для определения доступных слотов, в которые можно запланировать встречи. (примечание: это не встречи)
• Встреча: для получения созданных встреч (не уверен, как вы собираетесь справиться с этим, если у вас нет доступа к расписанию)
• Пациент: Предполагается, что вы хотите назначать пациентов на приемы;)

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

Это был отличный вопрос, и Администрация пациентов планирует написать руководство по внедрению этой функции в различных средах (общая практика, стационар, амбулатор, сообщество, лаборатория и т. Д.)