Difference between revisions of "Health Care Native Application"

Revision as of 17:03, 15 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, not necessarily to those from a provider web site.

Goal

• The patient has the capability to exercise their right to select an Identifier or Attribute Provider.
• The patient can easily create an IAL2 authentication with their Primary Care Practice (PCP) which enables downloads of data from their EHR.
• The patient can easily use that IAL2 authentication with other sites that known to be trustworthy members of the HIPAA community.
• The patients health information (PHI) it protected while it moves from a HIPAA compliant site to the patient and back to a HIPAA compliant site.

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

The following are the roles that are described in this use case. Note that more than one role may be supplied by the same Web Site/

1. Patient (or perhaps the guardian of the patient)
2. User Agent which accepts responsibility for protecting the Patient Credential
3. Primary Care Provider (PCP) is the place where the patient goes for care as well as for Identity Proofing.
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.
6. Credential Service Provider is the role that determines that the patient has established an IAL2 authentication method.

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 some other provider (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 they 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 a Native 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. In this journey the term patient refers to the actions where the patient's direct presence is required, the term user refers to the actions where the actor may be a guardian or the patient.

1. The patient has recently visited the PCP and acquired an Authorization Code to give them the ability to load the Patient Credential. After starting the app, the user indicates that they have a Patient Credential and want to register it to obtain access to the EHR.
2. While there are multiple ways to provide the user with such a Authorization Code this use case will consider the case where the patient is given a piece of paper with instructions for installing a Native App from a Trusted Third Party and the Authorization Code.
3. The user navigates to the Web Site indicated on the paper and installs the Native App on their phone.
4. The app starts and shows the main page which asks the user to create an identity to use with the patient's health care records.
5. Each User Device operating system will have their own unique method to authenticate the user locally. This method will always require some proof-of-presence of the user. While the exact method produces a use case peculiar to that User Device, that method's requirements may have been met by the user with some other app, like payments. If the user has not enabled local authentication, that will need to happen before proceeding. Some details about authenticating user access to the Trusted Execution Environment can be found on that page.
6. While multiple choices may be available to the patient, the easiest will be to use the Smart Phone camera to input the QR code.
7. This will permit the Native App to download a Patient Credential which has the information to build an identity with a private key that is well protected. The result will be that the Credential Service Provider can bind the Identity Proofing of the PCP with the Patient Credential installed on the Smart Phone running the Native App by the user.
8. Subsequent visits to the EHR with the data from the PCP will work with only local Authentication of the user to the Native App (with the help of the phone's operating system.)

Journey 5 - The patient or the PCP wants to use the Trusted Third Party (TTP) from Journey 4 as storage for User Owned Information. In other words, information provided by the user that they can change on their own initiative. In most cases the information does not need a doctors approval, but some patient directives do need approval.

1. The user has established an IAL2 certificate with the Credential Service Provider as described in Journey 4.
2. The user signs into the TTP at IAL2 level of assurances.
3. The user creates contact information for themselves, note that if the PCP physician has included their ID in the Patient Credential it will already be a part of this record. The user has the ability to remove that as a valid contact.
4. Medical directives can be included, but will be directed to the PCP of record (the issuer of the credential) for approval.
5. A patient will be able to add or delete any contact at any time.
6. Any contact is able to accept or reject a request to include them in the record. (Default is accept.) If these contacts do not include medical directives in their record, then IAL1 authentication will be sufficient for them to update their information.
7. All of this information is available on FirstNet to authorized First Responders.
8. Some Smart Phones will allow users to add information to their lock screen that can be used by First Responders to access their records.

Journey 6 - The patient visits some other Web Site associated with (eg) a specialist with a referral from the PCP.

1. The most difficult case is where the patient has on gone through Identity Proofing at the specialist, but want to see the EHR at the specialist's web site.
2. When accessing the specialist's Web Site the browser on the patient's web sites recognizes the identifier from the specialist and redirects the user to the Native App. This identifier will have a prefix that enables this recognition.
3. The Native App will verify that the specialist's Web Site is trustworthy by verifying the site's identity with the trust registry.
4. The consent page of the Native App will give the patient the power to select the Identifier that has an IAL2 assurance to continue sign-in.
5. If the specialist is part of the Health Care Community that recognizes the standard protocols, the patient is allowed access the the EHR.
6. If both the specialist's Web Site and the Native App are agreed that each is trustworthy, the patient will be able to upload PHI to the specialist's Web Site.

Journey 7 - The patient is unwilling to accept the site's conditions, or the site is unwilling to accept the user's stipulations. No sharing of patient data is possible.

Results

Accepted Risks:

1. Data transfers involved work within a framework of trust and mutual understand as to the patient's wishes with respect to care and privacy.
2. Patient Health Information (PHI) is resident on the User Device. That user may be the patient or the patient's guardian.
3. 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. There are several possibilities, including some sort of access code on the phone's sign-in screen that can be used by the First Responder.

Post Condition:

1. There are now two additional consents steps, lab with sensitive data and secondary provider (aka specialist in this use case) receiving and creating sensitive data.
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.
4. Notifications to the user will be addressed in the near future.

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

• Some of the details on this page are proprietary or covered by US patents.