Common Errors
This page documents common errors and troubleshooting guidance for the Provider Patient Access API. Understanding these error scenarios will help you build more robust integrations and resolve issues quickly.
Authentication Errors
401 Unauthorized
HTTP Status: 401 Unauthorized
Common Causes:
- Missing Authorization header
- Invalid or expired access token
- Malformed Bearer token format
- Token issued for different API endpoint
Example Response:
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "security",
"diagnostics": "Invalid or missing authorization token"
}
]
}
Solutions:
- Ensure Authorization header is present:
Authorization: Bearer {access_token} - Verify token is not expired and refresh if necessary
- Confirm token was issued for the correct API endpoint
- Check that token includes required scopes for the requested resource
403 Forbidden
HTTP Status: 403 Forbidden
Common Causes:
- Insufficient scopes in access token
- Patient has not consented to data access
- Requesting data outside of authorized patient context
- Application not authorized for requested operation
Example Response:
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "forbidden",
"diagnostics": "Insufficient scope for requested resource"
}
]
}
Solutions:
- Verify your application has requested appropriate scopes during authorization
- Ensure patient has provided consent for the requested data access
- Check that you're only accessing data for the authorized patient
- Review your application's registered permissions
Resource Errors
400 Bad Request
HTTP Status: 400 Bad Request
Common Causes:
- Invalid search parameters
- Malformed FHIR query syntax
- Unsupported search parameter combinations
- Invalid date formats or ranges
Example Response:
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "invalid",
"diagnostics": "Invalid search parameter: 'invalid-param'"
}
]
}
Solutions:
- Review the CapabilityStatement for supported search parameters
- Validate date formats (YYYY-MM-DD for dates, YYYY-MM-DDTHH:MM:SS for datetimes)
- Check parameter spelling and case sensitivity
- Ensure parameter values are properly URL encoded
404 Not Found
HTTP Status: 404 Not Found
Common Causes:
- Resource ID does not exist
- Resource exists but is not accessible to the current patient
- Incorrect resource type in URL path
- Typo in resource ID or endpoint URL
Example Response:
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "not-found",
"diagnostics": "Resource not found or not accessible"
}
]
}
Solutions:
- Verify the resource ID is correct and exists
- Ensure you're using the correct resource type in the URL
- Check that the resource belongs to the authorized patient
- Confirm the full endpoint URL is correct
410 Gone
HTTP Status: 410 Gone
Common Causes:
- Resource has been deleted
- Resource has been archived or moved
- Historical data no longer available
Solutions:
- Check if resource has been replaced with a newer version
- Use search parameters to find current/active resources
- Contact support if you believe this is an error
Rate Limiting
429 Too Many Requests
HTTP Status: 429 Too Many Requests
Common Causes:
- Exceeded API rate limits
- Too many concurrent requests
- Bulk operations without proper throttling
Example Response:
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "throttled",
"diagnostics": "Rate limit exceeded. Please retry after 60 seconds."
}
]
}
Response Headers:
Retry-After: 60- Seconds to wait before retryingX-RateLimit-Limit: 1000- Requests per time windowX-RateLimit-Remaining: 0- Remaining requests in current window
Solutions:
- Implement exponential backoff retry logic
- Respect the Retry-After header value
- Reduce request frequency or implement request queuing
- Contact support if you need higher rate limits
Server Errors
500 Internal Server Error
HTTP Status: 500 Internal Server Error
Common Causes:
- Unexpected server-side error
- Database connectivity issues
- Temporary service disruption
Solutions:
- Retry the request after a brief delay
- Check system status page for known issues
- Contact Netsmart support if error persists
- Implement proper error handling and logging in your application
502 Bad Gateway
HTTP Status: 502 Bad Gateway
Common Causes:
- Upstream service unavailable
- Network connectivity issues
- Load balancer configuration problems
Solutions:
- Retry the request after a brief delay
- Check if the issue is widespread or isolated
- Contact support if problem persists
503 Service Unavailable
HTTP Status: 503 Service Unavailable
Common Causes:
- Scheduled maintenance
- System overload
- Temporary service disruption
Response Headers:
Retry-After: 300- Seconds to wait before retrying
Solutions:
- Respect the Retry-After header if present
- Check system status page for maintenance announcements
- Implement circuit breaker pattern for resilience
FHIR-Specific Errors
Invalid FHIR Accept Headers
HTTP Status: 406 Not Acceptable
Common Causes:
- Unsupported Accept header format
- Missing FHIR content type specification
Solutions:
- Use
Accept: application/fhir+jsonfor JSON responses - Use
Accept: application/fhir+xmlfor XML responses - Avoid generic
application/jsonfor FHIR endpoints
Unsupported Operations
HTTP Status: 405 Method Not Allowed
Common Causes:
- Using unsupported HTTP method (POST, PUT, DELETE) on read-only API
- Attempting operations not supported by the resource
Solutions:
- Review CapabilityStatement for supported operations
- Use only GET requests for Patient Access API
- Check resource-specific operation support
Troubleshooting Tips
General Debugging Steps
- Check CapabilityStatement - Always start by reviewing what's actually supported
- Validate Tokens - Ensure tokens are valid and have appropriate scopes
- Review Request Format - Verify URL structure, headers, and parameters
- Check Response Details - Read OperationOutcome diagnostics for specific guidance
- Test in Preview - Use preview environment to isolate issues
Common Integration Patterns
Error Handling Best Practices:
// Example error handling pattern
try {
const response = await fetch(fhirUrl, {
headers: {
'Authorization': `Bearer ${accessToken}`,
'Accept': 'application/fhir+json'
}
});
if (!response.ok) {
const errorBody = await response.json();
console.error('FHIR Error:', errorBody);
// Handle specific error types
switch (response.status) {
case 401:
// Refresh token and retry
break;
case 429:
// Implement backoff and retry
break;
case 500:
// Log error and notify monitoring
break;
}
}
return await response.json();
} catch (error) {
console.error('Network error:', error);
}
Logging and Monitoring
Recommended Logging:
- Request/response correlation IDs
- HTTP status codes and response times
- Error details from OperationOutcome resources
- Token refresh events and failures
Monitoring Alerts:
- High error rates (>5% of requests)
- Authentication failures
- Rate limiting events
- Server errors (5xx responses)
Getting Help
Before Contacting Support
- Review this error documentation for common solutions
- Check the CapabilityStatement to verify supported operations
- Test in preview environment to isolate the issue
- Gather relevant information:
- Request URL and headers
- Response status code and body
- Timestamp of the error
- Correlation ID if available
Contact Information
- Technical Support - Contact Netsmart support for integration assistance
- Documentation Issues - Report documentation problems or suggestions
- System Status - Check status page for known issues and maintenance
Related Resources
- Authentication Guide - OAuth 2.0 implementation details
- CapabilityStatement - Supported operations and parameters
- Patient Access Tutorial - Step-by-step integration guide