Difference between revisions of "Health Care Native Application"

Revision as of 08:33, 9 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.
• This use case applies to Native Apps that are available from a Trusted Third Party.

Goal

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

Examples of Problems to be Addressed

1. The patient wants to view and download information from their Electronic Health Records (EHR).
2. The patient wants to send the PHI to some other party who may, or may not, be a HIPAA covered entity.

Actors

1. Patient (or perhaps the guardian of the 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 Native App that interacts with Patient Health Information (PHI) held in an Electronic Health Record (EHR) accessible over the Web.

Journey 1 - the (potential) patient comes to the site to learn what access is available and what the privacy implications are.

1. loading the Health Care Native Application should be simple if the patient can find the Web Site that hosts it.
2. the Web Site is able to prove their identity and trustworthiness to the patient by logos that will need to be defined and protected.
3. the Health Care Native Application loaded on the User Device (eg a Smart Phone) and will ask for no User Private Information at this time.
4. the patient navigates around the web site at will, there is no information collected about the patient other than the pages they access.
5. it may be necessary for the patient to enter some demographic information to get the information they need. This is all flushed at the end of the session.
6. the patient may decide to create a sign-in account and they then pass into Journey 2.

Journey 2 - the patient is directed to the site when the ask to access their medical records

1. the patient needs to create a sign-in account with the site.
2. it may be possible for remote Identity Proofing as some point in the future, but IAL2 assurance will not be available in this journey in the first stage.
3. some interactions with the site, eg setting appointments, will be available, but the patient will not be able to down load PHI.

Journey 3 - It is certainly probable that some PCP will help the patient to install the app on their phone, but that is more likely to occur for apps that they supply and so will not be considered further in this use case which is for apps supplied by a Trusted Third Party.

Journey 4 - The patient has already been through Identity Proofing at their Primary Care Physician (PCP) and want to access their medical records.

1. the patient has recently visited the PCP and acquired an Access Code to give them the ability to load the [[[Patient Credential]] the patient indicates that they have a Patient Credential and what to register it with the EHR web site.

Journey 5 - The patient 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