Patient Journey as seen by the Browser - Revision history

Tomjones: /* Journey */

2021-04-07T15:03:46Z

Journey

← Older revision		Revision as of 15:03, 7 April 2021
Line 60:		Line 60:
	# Alternatively the user could download the data and then upload it in a separate step.		# Alternatively the user could download the data and then upload it in a separate step.
	# Alternatively the user could provide a delegation authority to one site to acquire the data from the other.		# Alternatively the user could provide a delegation authority to one site to acquire the data from the other.
	# In this journey it wold be possible for the user to establish bi-~~taleral~~ sharing between the sites so the future updates are pre-approved by the user.		# In this journey it wold be possible for the user to establish bi-lateral sharing between the sites so the future updates are pre-approved by the user.

	==References==		==References==

Tomjones: /* Journey */

2021-04-07T15:03:21Z

Journey

← Older revision		Revision as of 15:03, 7 April 2021
Line 51:		Line 51:
	# 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, registration journey.		# The user is given the choice to continue with the identifier discovered or rejects that and skips to item 2 on the above, registration journey.
	# The user continues onto the authentication steps.		# The user continues onto the authentication steps.

Line 57:		Line 57:
	# The patient is at a patient portal and wishes to share data between to physician groups not on the same EHR community.		# 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 EHR whose portal the user is authenticated.		# The patient picks whether to share out or share into the EHR whose portal the user is authenticated.
	# These both require that the user be authenticated at both sites simultaneously.		# These both require that the user be authenticated at both sites simultaneously if the user is mediating the transfer.
			# Alternatively the user could download the data and then upload it in a separate step.
			# Alternatively the user could provide a delegation authority to one site to acquire the data from the other.
			# In this journey it wold be possible for the user to establish bi-taleral sharing between the sites so the future updates are pre-approved by the user.

	==References==		==References==

Tomjones: /* Journey */

2021-04-07T14:58:00Z

Journey

← Older revision		Revision as of 14:58, 7 April 2021
Line 39:		Line 39:
	# The user clicks on one sign in option . At this point there is a fork in the journey based on the cookie.		# 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)~~		A registration journey is the fork taken if there is no cookie and the user itreated as a new user.
	# 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.)
Line 48:		Line 48:
	# 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 (A return journey)~~		A return journey is the fork taken if a cooke is found for this RP.
	# 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.
Line 57:		Line 57:
	# The patient is at a patient portal and wishes to share data between to physician groups not on the same EHR community.		# 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 EHR whose portal the user is authenticated.		# The patient picks whether to share out or share into the EHR whose portal the user is authenticated.
			# These both require that the user be authenticated at both sites simultaneously.

	==References==		==References==

Tomjones: /* Journey */

2021-04-06T16:26:06Z

Journey

← Older revision		Revision as of 16:26, 6 April 2021
Line 43:		Line 43:
	# 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.)
	# User browser receives an HTTP 302 redirect message and the dip sign in page is displayed.		# User browser receives an HTTP 302 redirect message and the dip sign in page is displayed.
	# The user completes a sign in process at the ~~dip~~ (which may have found its cookie on the user browser, or not)		# The user completes a sign in process at the IdP (which may have found its cookie on the user browser, or not)
	# Port of the IdP message to the user is a list of the attributes (claims) tnat will be passed from the dip to the patient portal.		# Port of the IdP message to the user is a list of the attributes (claims) tnat will be passed from the dip to the patient portal.
	# The IdP issues a redirect to the user browser with shows the patient portal home page customized for that users.		# The IdP issues a redirect to the user browser with shows the patient portal home page customized for that users.

Tomjones: /* Context */

2021-04-06T16:24:25Z

Context

← Older revision		Revision as of 16:24, 6 April 2021
Line 9:		Line 9:
	\|-		\|-
	\|User \|\| An organic human being operating a computing device, typically a smartphone or laptop.		\|User \|\| An organic human being operating a computing device, typically a smartphone or laptop.
			\|-
			\|User Agent \|\| a software application that interfaces between the user and the internet. Typically a browser.
	\|-		\|-
	\| OIDC \|\| OpenID Connect as per [OIDC.Core]		\| OIDC \|\| OpenID Connect as per [OIDC.Core]

Tomjones: /* Journey */

2021-04-06T16:23:03Z

Journey

← Older revision		Revision as of 16:23, 6 April 2021
Line 33:		Line 33:
	==Journey==		==Journey==
	# 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		# 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
	# This journey assumes that the user is not already in communications "session" with the relying party website.		# This journey assumes that the user agent is not already in a communications "session" with the relying party website.
	# 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)		# 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)
	# The user clicks on one sign in option . At this point there is a fork in the journey based on the cookie.		# The user clicks on one sign in option . At this point there is a fork in the journey based on the cookie.

Tomjones: /* Journey */

2021-04-06T16:22:34Z

Journey

← Older revision		Revision as of 16:22, 6 April 2021
Line 33:		Line 33:
	==Journey==		==Journey==
	# 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		# 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
			# This journey assumes that the user is not already in communications "session" with the relying party website.
	# 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)		# 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)
	# The user clicks on one sign in option . At this point there is a fork in the journey based on the cookie.		# The user clicks on one sign in option . At this point there is a fork in the journey based on the cookie.

Tomjones: /* Journey */

2021-04-01T22:01:21Z

Journey

← Older revision		Revision as of 22:01, 1 April 2021
Line 53:		Line 53:
	Sharing journey.		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 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.		# The patient picks whether to share out or share into the EHR whose portal the user is authenticated.

	==References==		==References==

Tomjones: /* Context */

2021-04-01T21:58:41Z

Context

← Older revision		Revision as of 21:58, 1 April 2021
Line 29:		Line 29:
	\|-		\|-
	\|Trusted Wallet \|\| code trusted by one or more Trust Authorities to protect user secrets and perhaps to validate user presence.		\|Trusted Wallet \|\| code trusted by one or more Trust Authorities to protect user secrets and perhaps to validate user presence.
	\|-
	~~\|JAM session \|\| The period of time from when the user clicks on a link in the RP until the UI for the wallet is accepted by the user.~~
	\|}		\|}

Tomjones: /* Context */

2021-04-01T21:58:10Z

Context

← Older revision		Revision as of 21:58, 1 April 2021
Line 29:		Line 29:
	\|-		\|-
	\|Trusted Wallet \|\| code trusted by one or more Trust Authorities to protect user secrets and perhaps to validate user presence.		\|Trusted Wallet \|\| code trusted by one or more Trust Authorities to protect user secrets and perhaps to validate user presence.
	\|-
	~~\| Identity Wallet \|\| An application that is under the control and acts on behalf of the key credential holder. aka identity agent. can be a mobile app, browser extension/ plugin etc.~~
	\|-		\|-
	\|JAM session \|\| The period of time from when the user clicks on a link in the RP until the UI for the wallet is accepted by the user.		\|JAM session \|\| The period of time from when the user clicks on a link in the RP until the UI for the wallet is accepted by the user.