Purpose

This WS is used to describe patient sign-up flow to using Patient Information System (PIS).

Key points

1. This flow is based on current Auth Sign-up UI FE page with existing and modified back-end calls.

2. Patient registration is performed using pre-signed request on PIS side.

Sequence diagram

title Auth Sign-Up with DS

participant User as user
participant PIS FE as pis_fe
participant PIS BE as pis_be
participant Auth UI as auth
participant mithril + BE as be

user->pis_fe: Go to "Register patient in eHealth"
opt Prefill some data
    pis_fe<-->pis_be: Get patient's data
    pis_fe->pis_fe: Prefill form
end
pis_fe-->pis_be: Prepare data to sign
pis_be-->auth: Get nonce
auth-->pis_be: <<Response>>
pis_be-->pis_fe: Return data to sign
note left of pis_be: JWT
pis_fe->user: Show registration form
user->pis_fe: Change or confirm patients data
pis_fe->user: Prompt to sign registration request
user->pis_fe: Sign registration request
pis_fe-->auth: Redirect to auth service with signed request
note right of pis_fe: scopes\nredirect_uri\nsigned request
auth-->be: Validate signature
be-->auth: <<Response>>
opt Invalid signature
    auth->pis_be: <<Error response>>
end
auth<-->be: Search user
note right of auth: tax_id
opt User found
    auth-->pis_be: <<Error response>>
end
auth-->be: Search patient
note right of auth: tax_id + name
be-->auth: <<Response>>
alt Patient found
    note left of auth: found only one record
    auth<-->be: Create user
else Not found or found more than one
    auth->user: Show form with patient data to confirm
    alt Reject
        user-->auth: Reject form
        auth-->pis_be: <<Error response>>
    else Confirm
        user-->auth: Confirm form
        auth<-->be: Create patient
        auth<-->be: Create user
    end
end
auth->user: Show prompt to approve scopes
alt Reject scopes
    user->auth: Reject scopes
    auth-->pis_be: <<Reject response>>
    pis_be-->pis_fe: Show error
else Approve scopes
    user->auth: Approve scopes
    auth<-->be: Create/update approvals
    note left of be: grant_code
    auth-->pis_be: <<Success response>>
    note left of auth: grant_code
    pis_be-->be: Exchange code grant to access token
    note right of pis_be: code_grant + secret
    be-->pis_be: <<Access token>>
    note left of be: access_token\nrefresh_token
end

Patient sign-up flow

PIS: Prepare patient sign-up data

1. Obtain nonce (one time JWT) from RC Get nonce endpoint

2. Prepare filled patient registration request

3. Sign patient registration request, patient consents and nonce with patients digital signature

4. Submit pre-signed patient sign-up content to https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/17525606455 eHeath Auth page as query parameter according to table:

Auth UI: Validate query parameters

1. Validate query params, obtained from PIS.

   1. check client_id exists and is not empty

      1. in case of error - return 'Не вказаний ідентифікатор додатку для авторизації'

   2. check redirect_uri exists and is not empty

      1. in case of error - return ‘Не вказано адресу зворотнього визову’

   3. check user_data exists and is not empty

      1. in case of error - return ‘Не вказано дані для реєстрації’

Auth UI: Initialize sign-up request validation

Submit sign-up content to https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/17525606470 endpoint, fill in fields according to table:

Validate methods response:

• in case 200 with patien data and jwt is returned - proceed to ‘Show patient data to confirm’, save jwt

• in case error is returned - show error page with error message from endpoint response

Auth UI: Show patient data to confirm

In case sign-up request validation step completed successfully, Auth UI front-end renders patient data from sign-up validation endpoint response to confirm registration in the system with button ‘Accept and proceed’.

All rendered fields must be read-only.

Auth UI: Validate phone number

Submit patients phone number from sign-up content to Verify phone number endpoint, fill in fields according to table:

Add Authorization header with jwt.

Validate methods response:

• in case 200 with result = ‘OTP sent’ and next_step = ‘REQUEST_OTP’ - add field for patient to input OTP, obtained from SMS, after code is submitted - proceed to ‘Confirm patient sign-up form’

• in case 200 with result = ‘Verified’ - proceed to ‘Confirm patient sign-up form’

• in case error is returned - show error page with error message from endpoint response

Auth UI: Confirm patient sign-up form

Submit patients sign-up content with optional OTP to https://e-health-ua.atlassian.net/wiki/spaces/EH/pages/17525606489 endpoint, fill in fields according to table:

Add Authorization header with jwt.

Validate methods response:

• in case 201 with patient data, user data and session token is returned - proceed to ‘Show consent page’

• in case error is returned - show error page with error message from endpoint response

Auth UI: Show consent page

1. Obtain list of scopes, that must be approved by patient (from query params or based on user roles and global user roles).

2. Obtain translations for list of scopes.

3. Show consent page with user and client data, as well as list of scopes translations with button ‘Accept and proceed’.

Auth UI: Accept scopes

Submit content to Authorize an Approval endpoint, fill in fields according to table:

Add Authorization header with session token.

Validate methods response:

• in case 201 with session token is returned - redirect grant code to client

• in case error is returned - show error message at Show consent page

Auth UI: Redirect grant code to redirect_uri

1. Redirect user with grant_code to redirect_uri from Authorize an Approval response

PIS: Obtain access and refresh token

Submit content to RC Exchange oAuth Code Grant to Access Token endpoint, fill in fields according to table:

Validate methods response:

• in case 201 with access and refresh tokens is returned - save their values to PIS back-end

• in case error is returned - show error message at PIS FE