Patient Journey as seen by the Browser: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
Line 9: Line 9:
# The user clicks on one sign in option . A his point there is a fork in the journey based on the cookie.
# The user clicks on one sign in option . A his point there is a fork in the journey based on the cookie.


Fork one: User is apparently new as there is no existing cookie
Fork one: User is apparently new as there is no existing cookie (A registration journey)
# Legacy journey would have the user sign into the portal using a local user name and password. That would be an and to the user journey.
# Legacy journey would have the user sign into the portal using a local user name and password. That would be an and to the user journey.
# User selects to use a federated sign in process. (Note that this process may be a related hospital group or some other federated idp.)
# User selects to use a federated sign in process. (Note that this process may be a related hospital group or some other federated idp.)

Revision as of 16:06, 31 March 2021

Full Title

How the Patient journey is seen by the user agent (browser) on a user device.

Context

Patient journey, writing a proposal to present to BlinkDev, browser render engine people.

Journey

  1. User navigates to Relying Party Web site, for this journey a patient viewing a patient portal. The patient portal may receive a cookie from a prior visit
  2. RP displays one or more sign in options for the user (note that the patient view may be determined by the existence of a valid cookie)
  3. The user clicks on one sign in option . A his point there is a fork in the journey based on the cookie.

Fork one: User is apparently new as there is no existing cookie (A registration journey)

  1. Legacy journey would have the user sign into the portal using a local user name and password. That would be an and to the user journey.
  2. User selects to use a federated sign in process. (Note that this process may be a related hospital group or some other federated idp.)
  3. User browser receives an HTTP 302 redirect message and the dip sign in page is displayed.
  4. The user completes a sign in process at the dip (which may have found its cookie on the user browser, or not)
  5. Port of the dip message to the user is a list of the attributes (claims) tnat will be passed from the dip to the patient portal.
  6. The IdP issues a redirect to the user browser with shows the patient portal home page customized for that users.

Fork two the user device is recognized by the appearance of a cookie

References