LRA Configuration
Once you have received your client credentials (client ID and client secret), you will then be ready to register and connect to LRA. Depending on your authentication method, you will need to register your client application appropriately.
Authentication & Authorization
LRA supports two external methods to register your client application:
- User Authentication – Client application will request an access token from the DHS LRA Auth Server which will enable the user to authenticate through one of the authorized Identity Providers.
- System Authentication with Confidential Client (Client Secret) – Client application will use a Client Secret as a method to authenticate itself.
Environments & Endpoints
There are several environments within the LRA Platform. Clients will eventually have access to three environments:
- Sandbox
- Conformance
- Production
LRA environments are hosted in a private VPC in AWS and exposed to the Internet via several layers of networking infrastructure including a WAF or API Gateway, and Application Load Balancer (ALB).
Note: The environments may be refreshed; this will be communicated to all clients until we have a set schedule.
Environment | Server | Module | URL |
---|---|---|---|
Sandbox | Resource | baseURL | https://sbx1.dev.api.healthcarebc.ca |
Sandbox | Auth | baseURL | https://auth.sbx1.htk.healthcarebc.ca |
Conformance | Resource | baseURL | https://uat.test.api.healthcarebc.ca |
Conformance | Auth | baseURL | TBC |
Production | Resource | baseURL | https://api.healthcarebc.ca |
Production | Auth | baseURL | TBC |
Resource Server Endpoints
For example: The Sandbox FHIR Gateway would be: https://sbx1.dev.api.healthcarebc.ca/fhir
The following endpoints will be accessible in all environments:
End Point | Description | URL | Authorized/Public |
---|---|---|---|
FHIR Gateway | This is the primary entry point for all FHIR-related interactions. It handles requests for FHIR resources and operations. | /fhir | Authorized |
Health-check | Used to check the health and status of the FHIR server. It can provide basic information about server availability. | /fhir/endpoint-health | Public |
Retrieve Capability Statement | Returns the CapabilityStatement resource, which describes the capabilities of the FHIR server, including supported FHIR versions, available resources, operations, and more. | /fhir/metadata | Authorized |
SMART Config | Provides the SMART on FHIR configuration. This includes URLs for authorization, token services, and other capabilities required for SMART on FHIR apps. | /fhir/.well-known/smart-configuration | Public |
Open ID config endpoint | Provides the OpenID Connect server's configuration information, such as issuer, authorization endpoint, token endpoint, etc. | [baseURL]/realms/dht/.well-known/openid-configuration | Public |
Auth Server End Points
For example, the Sandbox Auth Server baseURL would be: https://auth.sbx1.htk.healthcarebc.ca/
The following endpoints will be accessible in all environments:
End Point | Description | URL | Authorized/Public |
---|---|---|---|
System Authentication | Token – The token endpoint for the OAuth2 framework. It exchanges an authorization grant for a token, which can be used for authenticated requests to the FHIR server. | [baseURL]/realms/dht/protocol/openid-connect/token | Public (with authorized headers) |
User Authentication | Authorization – The authorization endpoint for the OAuth2 authorization framework. It’s used to interactively authenticate a user and obtain an authorization grant. | [baseURL]/realms/dht/protocol/openid-connect/auth | Public |
Token | The token endpoint for the OAuth2 framework. It exchanges an authorization grant for a token, which can be used for authenticated requests to the FHIR server. | [baseURL]/realms/dht/protocol/openid-connect/token |
HTTP Headers
Required HTTP Headers
The following headers are required when using the LRA Platform:
Header Name | Header Value |
---|---|
Authorization | Bearer Token |
UserID | [user id of the user in the application] |
Note: UserID is ONLY required for System Service Accounts.
Optional HTTP Headers
X-Request-ID: Clients may supply a Request ID by using the X-Request-ID header (for any interactions such as GET, POST, and PUT). The following example shows a FHIR search request with a client-supplied Request ID:
GET Patient/123
X-Request-ID: 8dUEj34hwkDNd (provided by clients)
Example Connection Test
Verify LRA Sandbox Health
The following can be entered on the address line of a browser or using a special purpose HTTP query and retrieve tool such as cURL, HTTPie command line utilities, or the PostMan application:
GET [baseURL]/endpoint-health
Response
{
"status": "OPERATIONAL"
}
Discussion
Needs a demonstration of using the Client-ID and Client-Secret in the HTTP Header and also the authorization handshake.