Patient Journey as seen by the Browser: Difference between revisions
Jump to navigation
Jump to search
| (36 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
==Context== | ==Context== | ||
Patient journey, writing a proposal to present to BlinkDev, browser render engine people. | Patient journey, writing a proposal to present to BlinkDev, browser render engine people. | ||
{|border="1" padding="2" width="799px" | |||
| 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== | ==Journey== | ||
# User navigates to Relying Party Web site, for | # 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 | # 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. | |||
==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.