Release 4

FHIR Infrastructure Рабочая группаУровень зрелости: 2Статус стандарта: проект

Implementation Note: асинхронный FHIR API и операция $export находятся в активной разработке :

  • Посетите Draft FHIR Bulk Data Repository для получения самой последней черновой документации и открытых вопросов
  • Участвуйте в обсуждении разработки в чате chat.fhir.org

Все взаимодействия, определенные в RESTful API , описываются как синхронные операции, то есть клиент делает запрос и ждет, пока сервер вернет результат в HTTP-ответе. Этот шаблон не подходит, если требуется значительная обработка на стороне сервера или когда необходимо вернуть значительные объемы данных.

Хорошим примером этого является операция $export , при которой простой поиск может привести к большим объемам данных.

Шаблон асинхронного запроса, основанный на rfc 7240 , подходит для этого варианта использования и применим для всех определенных взаимодействий и операций , хотя для многих из этих применений он не приносит никакой пользы. Серверы могут выбирать, для каких взаимодействий шаблон должен поддерживаться (если вообще), а серверы могут выбрать поддержку только некоторых операций, использующих асинхронный шаблон.

Запрос будет иметь URL-адрес и другие параметры, которые обычно применяются, но должен включать заголовки, описанные ниже.

GET [FHIR API Request]

  • Prefer (обязательно)

    Определяет, будет ли ответ немедленным или асинхронным. Установка этого параметра на response-async запускает асинхронный шаблон.

  • Accept (обязательно)

    Определяет формат дополнительного ответа OperationOutcome на запрос о запуске. Поддерживаются любые представления формата сериализации.

  • _outputFormat (строка, необязательно, по умолчанию используется application/fhir+ndjson)

    Формат сгенерированных файлов массовых данных. В настоящее время должен поддерживаться ndjson , хотя серверы могут также поддерживать другие форматы вывода. Серверы должны поддерживать полный тип содержимого application/fhir+ndjson, а также сокращенные представления, включая application/ndjson и ndjson .

3.1.6.2.0.3 Ответ - Успех
  • Код состояния HTTP 202 Accepted
  • Content-Location заголовок с URL для последующих запросов статуса
  • Необязательно: FHIR JSON OperationOutcome в теле запроса
3.1.6.2.0.4 Ответ - Ошибка (например, неподдерживаемый параметр поиска)
  • Код состояния HTTP 4XX или 5XX
  • Необязательно: FHIR JSON OperationOutcome в теле запроса

После запуска массового запроса данных клиенты могут отправить запрос на удаление по URL-адресу, указанному в заголовке Content-Location , чтобы отменить запрос.

DELETE [polling content location]

3.1.6.3.0.2 Ответ - Успех
  • Код состояния HTTP 202 Accepted
  • Необязательно: FHIR JSON OperationOutcome в теле запроса
3.1.6.3.0.3 Ответ - статус ошибки
  • Код состояния HTTP 4XX или 5XX
  • Необязательно: FHIR JSON OperationOutcome в теле запроса

После запуска массового запроса данных клиенты могут опросить URL-адрес, указанный в заголовке Content-Location , чтобы получить статус запроса.

Примечание. Клиенты должны следовать подходу экспоненциальной отсрочки при опросе статуса. Серверы могут предоставлять заголовок Retry-After с датой http или время задержки в секундах. Если эта информация предоставлена, клиенты должны использовать эту информацию для определения времени будущих запросов на опрос.

Примечание. Заголовок Accept для этого запроса должен быть application / json . В случае, если из-за ошибок экспорт не завершился, ответ будет содержать ресурс FHIR OperationOutcome в кодировке JSON.

GET [местоположение опроса контента]

3.1.6.4.0.2 Ответ - статус "Выполняется"
  • Код состояния HTTP 202 принято
  • Необязательно заголовок X-Progress с текстовым описанием статуса запроса, длина которого не превышает 100 символов. Формат этого описания определяется по усмотрению сервера и может представлять собой процентное значение завершения или более общий статус, например «в процессе». Клиенты могут попытаться проанализировать это значение, отобразить его пользователю или зарегистрировать его.
3.1.6.4.0.3 Ответ - статус ошибки
  • Код состояния HTTP 5XX
  • Необязательно JSON FHIR OperationOutcome в теле
  • Даже если некоторые ресурсы не могут быть успешно экспортированы, общая операция экспорта все равно может быть успешной. В этом случае массив Response.error ответа завершения должен быть заполнен (см. Ниже) одним или несколькими файлами в формате ndjson, содержащими ресурсы OperationOutcome , чтобы указать, что пошло не так. .
3.1.6.4.0.4 Ответ - полный статус

  • HTTP-статус 200 OK

  • Заголовок Content-Type из application/json

  • Необязательно заголовок Expires , указывающий, когда перечисленные файлы больше не будут доступны.

  • Тело, содержащее объект json, содержащий метаданные и ссылки на сгенерированные файлы массовых данных.

    Обязательные поля:

  • transactionTime - мгновенный тип FHIR, который указывает время сервера, когда выполняется запрос. В ответе не должно быть ресурсов с измененными данными после этого момента.

  • request - полный URL-адрес исходного запроса на передачу массовых данных

  • requiresAccessToken - логическое значение, указывающее, потребуется ли для загрузки сгенерированных файлов токен аутентификации. Примечание. Это может быть неверно в случае подписанных URL-адресов S3 или внутреннего файлового сервера в брандмауэре организации.

  • output - массив элементов файла массовых данных с одной записью для каждого сгенерированного файла. Примечание. Если запрос на запуск не возвращает никаких данных, сервер должен вернуть пустой массив.

  • error - массив элементов файла ошибок, имеющих ту же структуру, что и массив output . Примечание. Если ошибок не произошло, сервер должен вернуть пустой массив. Примечание. В настоящее время поддерживается только тип ресурса OperationOutcome , поэтому сервер будет генерировать файлы ndjson, каждая строка которых является ресурсом OperationOutcome .

    Каждый элемент файла должен содержать следующие поля:

  • тип - тип ресурса FHIR, который содержится в файле. Примечание. Каждый файл может содержать ресурсы только одного типа, но сервер может создать более одного файла для каждого возвращаемого типа ресурсов. Количество ресурсов, содержащихся в файле, может различаться на разных серверах. Если данные для ресурса не найдены, сервер не должен возвращать элемент вывода для него в ответе.

  • url - путь к файлу. Формат файла должен отражать то, что запрошено в параметре _outputFormat начального запроса запуска.

    Каждый элемент файла может дополнительно содержать следующее поле:

  • count - количество ресурсов в файле, представленное в виде числа JSON.

    Пример текста ответа: 

    {
  "transactionTime": "[instant]",
  "request" : "[base]/Patient/$export?_type=Patient,Observation", 
  "requiresAccessToken" : true,
  "output" : [{
    "type" : "Patient",
    "url" : "http://serverpath2/patient_file_1.ndjson"
  },{
    "type" : "Patient",
    "url" : "http://serverpath2/patient_file_2.ndjson"
  },{
    "type" : "Observation",
    "url" : "http://serverpath2/observation_file_1.ndjson"
  }],
  "error" : [{
    "type" : "OperationOutcome",
    "url" : "http://serverpath2/err_file_1.ndjson"
  }]
}

Используя URL-адреса, указанные в завершенном теле запроса состояния, клиенты могут загружать сгенерированные файлы массовых данных (по одному или несколько для каждого типа ресурса). Примечание. Эти файлы могут обслуживаться файловым сервером, а не конкретным сервером FHIR. Кроме того, если для поля requiresAccessToken в теле статуса установлено значение true , запрос должен включать действительный токен доступа в заголовке Authorization в этих запросах. (Т.е. Authorization: Bearer {{token}} ).

.

GET [url from status request output field]

  • Accept (необязательно, по умолчанию application/fhir+ndjson)

Задает формат возвращаемого файла. Необязательно, но в настоящее время поддерживается только application/fhir+ndjson.

3.1.6.5.0.3 Ответ - Успех
  • HTTP-статус 200 OK
  • Content-Type заголовок application/fhir+ndjson
  • Тело FHIR ресурсов FHIR в формате json с разделителями новой строки ndjson
3.1.6.5.0.4 Ответ - Ошибка
  • Код состояния HTTP 4XX или 5XX