Patient Journey as seen by the Browser

Full Title

How the Patient journey is seen by the user agent (browser) on a user device.

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.

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.