Page Comparison

...

1. Patient creates an account on the partner app.

2. The app ensures the patient login is associated with a unique app_user_id.

3. From an appropriate screen in the app, the patient is given a link to the PKB “grant access” OAuth2.0 screens.

4. Patient grants access using OAuth 2.0.

   1. Using the patient scoped User Client id, the patient grants access using the Authorization Code Grant workflow.

   2. The url to provide is generated as described in this page of the PKB development wiki, using the user client id and the scope of PATIENT. 

5. Following a successful login, PKB will return an authorization code to the app.

6. The app exchanges the authorization code for an access and refresh token which enable interaction with the PKB APIs specifically for that patient.  

   1. Using the authorization code as a parameter, you’ll swap it for an access / refresh token pair.

   2. Endpoint: POST https://sandbox.patientsknowbest.com/apiToken.action

   3. Further details with parameters and examples are here.The token expiry is set to 1800 seconds (30 minutes).  

   4. The patient will only do this authorization one time.

   5. The app will need to maintain, manage, and associate tokens with the corresponding patient record in the app.

7. Using a valid access token, the partner app pulls the patient’s details. There are a few options, two of which are outlined below, and the best option depends on what the partner use case is.

   1. PKB public id using the FHIR Purview operation on PKB’s Facade FHIR API and stores it as a pair with the app_user_id. Example is here.

   2. Demographic details, including any identifiers (national/local) in the PKB record, using a valid access token and PKB’s REST API. Example is here (/users/self).

...