Можно ли использовать любой элемент ресурса FHIR в качестве параметра поиска?

Ограничено ли использование параметров поиска общими параметрами поиска (например, _id, _text) и теми, которые определены в конце каждого определения ресурса? Например, семья, определенная на ресурсе пациента @ https://www.hl7.org/fhir/patient.html#search.

Я хотел бы знать, можно ли использовать какой-либо элемент ресурса непосредственно в качестве параметра поиска? Например:

  1. для поиска ImagingStudy по более чем 3 сериям: / ImagingStudy? numberOfSeries> 3
  2. для поиска ImagingStudy по любым сериям, доступным ОНЛАЙН: /ImagingStudy?series.availability=ONLINE. Это похоже на фильтр сложного типа от Odata (http://www.odata.org/getting-started/basic-tutorial/#filter), где тот же запрос можно записать в OData как / ImagingStudy? $ filter = series / any (s: s / availability eq 'ONLINE')

Следующее добавлено 28 ноября 2015 г .:

Наш сервер - это сервис только для чтения, который объединяет данные из различных исходных систем и реализует API на основе FHIR. Вот несколько интересных фактов и проблем, связанных с инфраструктурой:

  • Большинство исходных систем могут обеспечивать только примитивные запросы, например, фильтрацию по дате.
  • Мы не можем создавать индексы, поскольку не владеем репозиторием данных.
  • В типичном сценарии мы сначала извлекаем фильтр даты из запроса клиента и используем его для уменьшения количества данных, которые должны быть возвращены исходной системой. Затем наш сервис обработает оставшийся фильтр, сортировку и пейджинг агрегированного результата.

Например, у нас есть требование реализовать строковый поиск по ImagingStudy.procedure.code.coding []. Display.

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

Это мотивация, которая породила мой вопрос: поскольку клиент и сервер FHIR уже имеют четко определенный контракт, определенный через ресурсы FHIR, можно ли будет расширить этот контракт для параметров поиска, где клиент и сервер смогут использовать существующие граф объектов ресурса FHIR в качестве параметров поиска без необходимости определять отдельный список.


hl7-fhir
person Martin Liu    schedule 27.11.2015    source источник
comment
В первом примере запрос должен быть / ImagingStudy? NumberOfSeries = gt3.   -  person Stef Heyenrath    schedule 20.01.2016

Ответы (1)


arrow_upward
2
arrow_downward

Параметры поиска определяются отдельно и сопоставляются с фактическими путями в ресурсах, чтобы серверы могли поддерживать индексы с помощью чего-то вроде map / reduce, а не выполнять длинные запросы к неиндексированному содержимому. Вы не можете просто запрашивать произвольные пути в ресурсах. Примечание. Сюда входит параметр поиска _filter.

Однако серверам разрешено определять свои собственные параметры поиска и сопоставлять их с произвольными путями в ресурсах. Если сервер предоставляет параметр поиска, он должен объявить его в заявлении о соответствии, и тогда вы узнаете, можете ли вы его использовать или нет.

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

person Grahame Grieve    schedule 28.11.2015
comment
кстати, здесь вы можете предложить добавить новые стандартные параметры для ресурсов: gforge.hl7.org/gf/project/fhir/tracker/ - person Grahame Grieve; 28.11.2015
comment
Цените ваши комментарии, @Grahame. У меня есть дополнительная информация к вопросу. Из-за ограничений по длине в комментариях я добавил их к исходному вопросу выше. - person Martin Liu; 29.11.2015
comment
Это не меняет моего ответа. Вы потенциально можете указать тем или иным способом, что вы поддерживаете запрос по любому пути в заявлении о соответствии, но вы, вероятно, на самом деле не можете этого сделать - какова семантика? Вы, вероятно, захотите выполнять поиск только по листовым узлам, за исключением случаев, когда вы хотите варьироваться, например. Как работает токен. Поэтому я думаю, что лучше всего объявить, по какому запросу вы отправляете запрос. И добавление нового поиска Paramus не должно быть хрупким; не меняет существующий функционал - person Grahame Grieve; 29.11.2015