Patient Journey as seen by the Browser: Difference between revisions
Jump to navigation
Jump to search
| (11 intermediate revisions by the same user not shown) | |||
| 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] | ||
| Line 24: | Line 26: | ||
| CP || Claims provider, Certificate Provider, Credential Provider, Credential Service Provider, etc. | | CP || Claims provider, Certificate Provider, Credential Provider, Credential Service Provider, etc. | ||
|- | |- | ||
| | | Identifier 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. | ||
|- | |- | ||
| Trust Authority || A URL endpoint that contains the references that define, inter alia, the operation of the picker and of the wallets | | Trust Authority || A URL endpoint that contains the references that define, inter alia, the operation of the picker and of the wallets | ||
|- | |- | ||
|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. | ||
|} | |} | ||
==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 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. | ||
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.) | ||
# 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 | # 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. | ||
# 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). | ||
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. | ||
# The user rejects | # 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. | ||
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 | # 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 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-lateral sharing between the sites so the future updates are pre-approved by the user. | |||
==References== | ==References== | ||
Latest revision as of 15:03, 7 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.
| Term | Description |
| 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] |
| OAuth client | Used synonymously with Relying Party (see RP) |
| IdP | Identifier Provideer (may also include attributes or claim of the subject) |
| OP | OpenID Provider (one form of IdP) as per [OIDC.Core] |
| SIOP | Self-Issued OpenID Provider as per [OIDC.Core] section 7. |
| RP | Relying Party, as used in [OIDC.Core] for any website the relies on claims produced by a CP for example an OP. |
| CP | Claims provider, Certificate Provider, Credential Provider, Credential Service Provider, etc. |
| Identifier 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. |
| Trust Authority | A URL endpoint that contains the references that define, inter alia, the operation of the picker and of the wallets |
| Trusted Wallet | code trusted by one or more Trust Authorities to protect user secrets and perhaps to validate user presence. |
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
- 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)
- The user clicks on one sign in option . At this point there is a fork in the journey based on the cookie.
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.
- 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.
- 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.
- The IdP issues a redirect to the user browser with shows the patient portal home page customized for that users.
- The user may need to locate their patient records on the patient portal which may ask the user for additional attributes (claims).
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 is expired or just has the user ID. The user is directed to a sign in Experience.
- 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.
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 EHR whose portal the user is authenticated.
- 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-lateral sharing between the sites so the future updates are pre-approved by the user.