Difference between revisions of "Health Care Native Application"

Revision as of 19:21, 8 July 2019

Full Title of Use Case

Health Care Native Application Use Case is created to show the user scenarios in a Health Care setting.

Context

To provide a good user experience for a patient interacting with a Native App on their Smart Phone.

Goal

• The user has the capability to exercise their right to select an Identifier or Attribute Provider.

Examples of Problems to be Addressed

The user wants to view and download information from their Electronic Health Records (EHR).

Actors

1. Patient
2. User Agent which accepts responsibility for protecting the Patient Credential
3. Primary Care Provider
4. Electronic Health Record, which is assumed separate from the PCP for full generality
5. Trusted Provider of services related to Authentication or Patient Credential sharing.

Preconditions

1. The user wants to control access to their own User Information.
2. At least one Identifier or Attribute Provider exists that is acceptable to both the User and the Relying Party.
3. The user will be able to use the registered account later at the Relying Party, see wiki page Relying Party Authentication Use Case.

Scenarios / User Journeys

The goal of these scenarios is to test the functionality of any web site were the user access and update their information.

Journey 1 - the user's comes to the site to learn what ... really is:

Journey 2 - the user is directed to the site as they do want to start to collect private data:

Journey 3 - The user has already registered with the site.

Journey 4 - The user is unwilling to accept the sites conditions, or the site is unwilling to accept the user's stipulations.

Results

Accepted Risks:

1. Data transfers involved work within a framework of trust and mutual understand as to the user's wishes with respect to care and privacy.
2. It is not clear how a non-responsive user can provide sufficient details to the First Responder. Presumably the existing First Responder network can provide some guidance on that challenge.

Post Condition:

1. There are now two additional consents steps, lab with sensitive data and secondary provider with sensitive.
2. No data is ever shared with any provider that has not been strongly identified to the user.
3. The user results are available it is assumed that the consent receipt acknowledged that the data would be sent back to the primary care doctor.

Examples:

1. tbd

Dependencies::

1. Web Sites must be trusted before any user information is provided to them.
2. Trust federations can be used to help users make informed decisions.
3. User consent and trust must begin with no user information transferred.
4. Standards exist to collect needed attributes where-ever they may be.

Workflow Diagram

TK

References