Error Handling
The API will always return sensible HTTP status code.
There are 2 types of API errors:
- 400 series status codes for client issues
- 500 series status codes for server issues.
Common HTTP Status codes returned on errors:
- 400 Bad Request - search could not be processed or failed basic FHIR validation rules
- 401 Not Authorized - authorization is required for the interaction that was attempted
- 404 Not Found - resource type not supported, or not a FHIR end-point
- 422 Unprocessable Entity - resource was rejected by the server because it "violated applicable FHIR profiles or server business rules"
- 500 - Internal Server Error
Along with the Status Code the API will return an OperationOutcome resource as response containing details about the error. Here is an example of OperationOutcome object:
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "processing",
"diagnostics": "Invalid request: The FHIR endpoint on this server does not know how to handle GET operation[Patient] with parameters [[wrong_parameter]]"
}
]
}
Table of Error Messages
This table contains common error codes and error messages.
Status Code | Message | Comments/Solutions |
---|---|---|
400 | No error message | Check the endpoint that has been called. Look for extra characters such as 2 slashes, or incomplete endpoint URL. |
400 | This operations can be executed in asynchronous mode only... | Some operations in Health Gorilla can take significant time to complete and must be done asynchronously. More detail can be found in the Async section |
400 | Subject validation failed | When calling the Oauth endpoint, a check is done against the sub in the JWT. This message indicates the subject is not a valid user or the Oauth client is not bound to the tenant containing the user. Check the credentials to insure the subject in the JWT is correct. |
400 | Invalid Request | The syntax of the call is incorrect. |
401 | Invalid Token | The access token used in the header.Authorization field is not valid. |
403 | Insufficient access rights to perform the operation | This is usually caused by a user attempting to call an incorrect version of FHIR not associated with their Oauth client. Insure the correct FHIR version URL is being called. STU3 = /fhir/resourceName R4 = /fhir/R4/resourceName |
403 | Tenant has no license to execute this method. | User is trying to access an API method that is not licensed for their tenant. |
404 | Not found | The resource being searched for cannot be found. This could mean the resource ID is incorrect or does not exist in the current tenant. |
404 | rejected_www-request | User is trying to call the API's using the www domain in the URL. Correct API domain is api.healthgorilla.com. |
405 | method not allowed | The method being used (PUT, POST, GET) is not allowed on the API being called. |
415 | no error message | Usually occurs due to an unsupported media type being uploaded. |
422 | Case specific | a 422 will contain a specific message describing the error in the payload being sent to Health Gorilla. Examples: Missing content, required fields missing, invalid format in some fields, etc. |
422 | Record with supplied ID2 already exists | MRN must be unique within a user's tenant. This error means a patient is being created with an external MRN that has already been associated with an existing patient in the tenant. |
422 | Empty content attachment supplied | Occurs when a DocumentReference is posted without an attachment. |
422 | Supplied record duplicates the existing one.;Failed to create duplicate | The resource being created is considered a duplicate based on Health Gorilla's deduplication logic. |
422 | Supplied performer is unknown | When placing a lab order via the RequestGroup API, the lab vendor the user included is empty or not valid. |
422 | Supplied AuthorizedBy is unknown or cannot be used with the specified Author. | When placing a lab order via the RequestGroup, the tenant location or ID is incorrect or does not match to the Author (the provider). |
429 | Too many requests | This error represents the user being throttled. The specific throttle will be described in the respond payload. This throttle could be the RPS or the number of concurrent p360 async processes. |
454 | No error message | This is usually caused by trying to call a temporary link that has expired. |
504 | Gateway Timeout | This usually occurs when a synchronous call takes longer the 60 seconds to complete. |
Updated 7 months ago