ESAVI FHIR Implementation Guide (IG)
0.1.45 - ci-build International flag

ESAVI FHIR Implementation Guide (IG), published by ESAVI -. This guide is not an authorized publication; it is the continuous build for version 0.1.45 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/PanAmericanHealthOrganization/ESAVI-IG-FHIR-EN/ and changes regularly. See the Directory of published versions

Security

Authorization/Authentication

The regional center implements oAuth2-based security with tokens, so the first call from authorized applications must be made to the url that provides the token ([auth]).

Server authentication diagram

Application Registration

Prior to using the authentication service, the requesting application must request the regional center administrators:

Register a fixed URI for the application in the Regional Center In the case of using a digital signature: Register an RSA public key (SHA-256) Once the application is registered, a trust relationship is established between the application and the regional center, that is, the application is considered 'pre-authorized' to register in AEFI

The Regional Center will assign the client an identifier called client_id

At run time, the service must obtain an access token in order to access the information. These access tokens can be generated automatically, without the need for human intervention, with a recommended expiration of 15 minutes.

Generation of the Authentication Token

[SecretWord] Keyword given by the regional center [urlAuth] Authorization URL

Step 1: JWT Token Generation

The client application must generate a JWT token signed with the DNSIS-granted keyword with the following information

JS Code Example

function CreateJWTToken()
{
    var jwt = require('jsonwebtoken');
    c = authc.authConfig();
    var myTokenContent=
    {
        iss: c.iss,
        iat: Date.now(),
        exp: Date.now() + 6000000 ,
        aud: c.aud,
        sub: c.sub,
        name: c.name,
        ident: c.ident,
        role: c.role
    }
    var token = jwt.sign(myTokenContent, c.secretWord);
    return token;
}

Step 2: Post AuthorizationRequest

The client application must POST the AuthorizationRequest JSON to [urlAuth]

AuthorizationRequest

element content example
grantType clientCredentials fixed value
scope SEE Table of Scopes Bundle.write
clientAssertionType urn:ietf:params:oauth:client-assertion-type:jwt-bearer fixed value
clientAssertion [jwt token created in step 1]

Table of Scopes

Operation Scopes
AEFI Registry Bundle/*.write
Terminological Consultation ValueSet/*.read,CodeSystem/*.read,ConceptMap/*.read

AuthorizationRequest: JS Code Example

    InitialToken=CreateJWTToken();
    var authRequest={
        "grantType": "client_credentials",
        "scope": "Bundle/*.write",
        "clientAssertionType": "urn:ietf:params:oauth:client-assertion-type:jwt-bearer",
        "clientAssertion": initial token
    };

Response to AuthorizationRequest

The response will be a JSON object with the following properties AuthorizationResponse

element description details
scope Access Level Granted View scopes table
access_token Token Granted by Server This is the token you must include in all requests to the CER
expires_in Number of seconds of token expiration 900 (fifteen minutes) is suggested
token_type Token Type Fixed value: bearer

JSON Response Example


{ "access_token": "m7rt6i7s9nuxkjvi8vsx", "token_type": "bearer", "expires_in": 900, "scope": "Bundle/write" }

###  Inclusion of the Token in the Header of HTTPS Requests

In all invocations to the Regional Center, the token obtained must be included as the header of the HTTPS request.

Name: Authorization Value: Bearer: [access_token]

The token will be validated by the Regional Center