Patient Journey as seen by the Browser: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
Line 18: Line 18:
# The user may need to locate their patient records on the patient portal which may ask the user for additional attributes (claims).
# The user may need to locate their patient records on the patient portal which may ask the user for additional attributes (claims).


Fork two the user device is recognized by the appearance of a cookie
Fork two the user device is recognized by the appearance of a cookie (A return journey)
# A cookie is found which represents a current (unexpired) sign in session (ie the user is "signedin"). The user is immediately redirected to the portal patient page.
# A cookie is found which represents a current (unexpired) sign in session (ie the user is "signedin"). The user is immediately redirected to the portal patient page.
# A cookie is found which is expired or just has the user ID. The user is directed to a sign in Experience.
# A cookie is found which is expired or just has the user ID. The user is directed to a sign in Experience.
# The user rejects the ID proffered and skips to item 2 on the above journey.
# The user rejects the ID proffered and skips to item 2 on the above journey.
# The user continues onto the authentication steps.
# The user continues onto the authentication steps.
Sharing journey.
# The patient is at a patient portal and wishes to share data between to physician groups not on the same EHR community.
# The patient picks whether to share out or share into the current EHR.


==References==
==References==

Revision as of 19:14, 1 April 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 it is 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 . At this 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.
  7. The user may need to locate their patient records on the patient portal which may ask the user for additional attributes (claims).

Fork two the user device is recognized by the appearance of a cookie (A return journey)

  1. A cookie is found which represents a current (unexpired) sign in session (ie the user is "signedin"). The user is immediately redirected to the portal patient page.
  2. A cookie is found which is expired or just has the user ID. The user is directed to a sign in Experience.
  3. The user rejects the ID proffered and skips to item 2 on the above journey.
  4. The user continues onto the authentication steps.

Sharing journey.

  1. The patient is at a patient portal and wishes to share data between to physician groups not on the same EHR community.
  2. The patient picks whether to share out or share into the current EHR.

References