Patient Journey as seen by the Browser
Jump to navigation
Jump to search
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-taleral sharing between the sites so the future updates are pre-approved by the user.