HL7 PT FHIR Implementation Guide: Visita do Utente
1.0.0 - STU1
HL7 PT FHIR Implementation Guide: Visita do Utente
1.0.0 - STU1
HL7 PT FHIR Implementation Guide: Visita do Utente, published by HL7 Portugal. This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/hl7-pt/workflow-ep-ig/tree/master and changes regularly. See the Directory of published versions
Um pedido que falha normalmente retorna um OperationOutcome .
No entanto, há muitas situações atípicas em que a resposta pode conter outros tipos de informações. Nem sempre é possivel detectar e descrever todas as situações de erro que podem ocorrer, mas os métodos de tratamento de erros mencionados mais abaixo, tentam resumir como podemos processar as informações dos erro retornados de uma forma simples e adequada.
O impacto na gestão de erros depende da informação retornada pelo servidor onde ocorreu o erro. Desta forma, devemos ter em atenção o seguinte:
Verificar a resposta HTTP, por exemplo, HTTP/1.0 503 Service Unavailable é a informação mais importante sobre o resultado de um pedido feito pelo utilizador. Caso a resposta do pedido receba algo semelhante a 2XX indica sucesso, caso contrário, indica insucesso. Na tabela mais abaixo, há mais informações sobre os códigos HTTP possiveis e mais comuns.
Identificar o tipo de dados no headers, verificando o campo Content-Type. Por exemplo, Content-Type: "text/html" indica que ocorreu um erro na camada de transporte, porque normalmente numa resposta FHIR está marcada com application/fhir, como por exemplo Content-Type: "application/fhir+json; charset=UTF-8". Respostas que nãpo sejam do tipo FHIR devem ser tratadas como erros de sistema. Cabe ao responsável do serviço decidir a mensagem de erro apropriada para o utilizador em caso de erros de sistema.
Identificar o tipo de recurso FHIR no corpo da resposta. Na maioria dos casos, será uma das opções: vazio, um OperationOutcome, um Bundle ou o recurso solicitado. O conteúdo depende do que o sistema definiu como preferência no cabeçalho Prefer. Se não estiver especificada, deverá ser validado com o sistema qual o Prefer. No entanto, um erro deverá retornar sempre um OperationOutcome, independentemente do resultado.
Analisar o que o OperationOutcome diz sobre o erro.
Os códigos na tabela em baixo são os mais comuns nos sistemas:
| Código | Definição | Comentário |
|---|---|---|
| 200 | OK | Pedido bem sucedido |
| 201 | Created | Pedido bem sucedido. Um ou mais recursos foram criados |
| 304 | Not Modified | GET condicional recebido, mas as pré-condições foram avaliadas como falsas |
| 400 | Bad Request | Erro no cliente, por exemplo falha na estrutura do pedido |
| 401 | Unauthorized | Credenciais inválidas ou falha na autorização |
| 403 | Forbidden | Operação não autorizada |
| 404 | Not Found | Recurso/Elemento não encontrado |
| 409 | Conflict | Conflito, geralmente devido ao estado inesperado do recurso |
| 422 | Unprocessable Entity | Estrutura válida, mas não está em conformidade com a definição do recurso |
| 500 | Internal Server Error | Erro inesperado no servidor |
| 503 | Service Unavailable | Servidor temporariamente indisponível |