User Agent in the Cloud

Full Title of Use Case

A user with a modern browser on a internet connected computing device can establish an agent on a trustworthy web site to act on their behalf.

Goals

1. The primary goal is to maintain and enforce user preferences with respect to access to user data including user directives.
2. Be a source of secure binding for user identifiers that can be employed by the user from any trustworthy internet connected computing device.
3. Act on the users behalf as a gateway to PHI contained in EHR for both download and upload of user information.
4. Meet the needs of the Healthcare community for identity proofing with dual factor authentication (IAL2) and user credential protection (AAL2) in connecting to a Health Information Network.

Context

• OpenID Connect considers that the Identifier Provider (IdP) should (optionally) host a consent page for release of user information.
• The test use case will be a patient that desires to transfer personal healthcare information (PHI) among their health care providers with Electronic Health Records (EHR).
• To provide Level 2 assurance of a user meeting TEFCA and NIST SP 800-63-3 specifications. (See the references below.)
• This is a companion use case to the Remote Attestation Use Case. In this case the user lets a cloud service be their agent, in that case the user puts the agent on the smart phone.

Goal

• The end goal is to enable to the web site as an agent for the user's actions on the web allowing the user to delegate authority to the agent to consent to release user private information and other actions during an interaction with a collection of trustworthy web sites.

Actors

1. A new user of a relying party who is told that they must acquire the means to establish higher levels of assurance to download or upload data on that relying party.
2. A trustworthy site that can act as an Identifier Provider (IDP) authentication the user and maintaining a list of user preferences.
3. A relying party that has high value data that a user want to see or modify, for example a patient wants to download or upload medical records for a Electronic Health Repository.
4. A trust registry that can verify which web sites have been proven to protect the users data in the domain of interest, for example sites that are covered HIPAA entities.

Distributed Attributes

• This use case does not require e a single aggregation of all of a patient's digital records in a single provider. While such aggregation may be possible in smaller jurisdictions, it will never be possible in any federal system where the individual states have responsibility for the health of their residents, like the US or the EU. So the use cases is designed to be resilient in the face of a fragmented source of patient data.
• In this context patient attributes are considered to include personal and financial attributes as well as user sensitive (e.g. medical) records.

Preconditions

1. The user has self-selected to establish a high level of assurance in order to access highly sensitive, or costly, data on the relying party.
2. The user has possession of a device and its software that can meet the following criteria (in this case possession means that the user has effective control of the functioning of the device):
   1. The device's manufacturer is known and has control of the software that is initially delivered with the device to the user.
   2. The user can use the manufacturer's web browser or supply their own. In either case the user can trust the browser.

Healthcare Specific Conditions

1. A healthcare specific trust registry exists to attest to providers of Electronic Health Record (EHR) and smart phone apps, all of which agree to support the security, privacy, interop and UX of the Health Care Profile.
2. The patient can create one or more trusted identifiers in cyberspace that can be used to access their health records at any of their care providers.
3. The patient has access to Health IT Record Location Service (Data Aggregation) and brought a locator ID or authorization code available on paper or existing PCP web site.
4. The patient has an internet connecting computing device with a browser that is trusted by the user with sensitive data.

Scenarios

The goal of this scenario is to test the functionality of the process of patient acquisition of level 2 assurance for access to patient health records of the PCP and other healthcare providers.

Primary Scenario which includes identity proofing by the PCP:

1. Patient has Primary Healthcare provider with web site.
2. User of web site is either the patient or some trusted guardian of the patients health care interests.
3. User downloads one of the applications that is identified as acceptable on a list provided by the PCP. (Note that it is permissible for the list to include only the one app provided by the PCP.)
4. The user is guided through a process of initializing the application on the phone.
5. The user selects an identifier that will be used for any level 2 assurance.
6. The user is asked for some means to contact them for recovery or redress, typically an email address or phone number.
7. The user enters their authorization code.
8. The app contacts the Remote Authorization Service (aka CSP) and gets back a packet of information that attests to the validity of level 2 assurance.
   1. Note that there could be some back and forth at this point to guide the user to make the correct choices or provide the appropriate data.
9. The user can now sign in to the PCP with their level 2 resources (at this point the only advantage over existing PCP web site access the the ability to download data in bulk.)
10. The user downloads data from the PCP.
11. The user visits (in person on online) to another covered medical provider where their level 2 sign in credentials are accepted.
    1. There most likely will be other information required by the other provider, usually associated with getting payment authorization.
12. The user can transfer the medical information directly from the phone.

Alternate Scenario:

1. User controls access to PHI through a Qualified Health Network (QHIN) which may be one of the providers or a trusted third party.
2. The QHIN is required (TEFCA 6.2.4iii) to perform identity proofing, unless it is also directly connected to the user's PCP it needs some other identity proofing, such as that provided by a phone credential.
3. The QHIN is required (TEFCA 6.2.5) to authenticate the user to AAL2 specs which is part of the phone credential.
4. Since the QHIN is a covered HIPAA entity it will have an entry in the trust registry and so known to the app as trustworthy.
5. The user can create an account to the QHIN using their smart phone as both the source of identity proofing and strong key protection.
6. The application will then be able to track the QHIN as it would any other medical provider and sign seamlessly via their phone.
7. In this case the application will need access to the consents that the user has created that allow access from one provider to another.
8. The phone provides cryptographically secure user consent to one party (typically the receiver of the PHI) that can be passed to another party (the sender).
9. The user can revoke a consent at any time stopping any further transfer from one site to another.

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.

Post Condition:

1. The value add for the patient includes:
   1. The ability to authenticate to a level 2 of assurance using their smart phone with no separate IDP required.
   2. The ability to interact (upload and download) with medical records based on the credentials in their smart phone.
   3. The ability to seamlessly register with any other participating entity (covered entity or QHIN.)

• Covered entities are medical care providers, EHR, pharmacies, payers, laboratories, third party IT providers etc. that are subject to HIPAA rules.
• QHIN is a qualified Health Information Network, which may also be a covered entity with registered individual users.

Examples:

1. tbd

Dependencies:

1. Web Sites must be trusted before any user information is released 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 (like TEFCA) exist to collect needed attributes where-ever they may be.
5. Connections to related providers for financial settlements will need to be enabled. In many cases these will have patient private information that needs protection.
6. Most PCPs will depend on IT support from third party providers. It must be clear to the patient in all cases who holds their data (a data processor) and who controls their data (a PCP or data controller) and where the patient goes for redress. This is not generally true as of (2019-04-29).

Workflow Diagram

TK

References

• The base page for NIST Special Publication 800-63 version 3. Part a deals with Identity Assurance Level or IAL, part b with Authenticator Assurance Level or AAL and part c with Federation Assurance Level or FAL.

  Of most interest in this paper, AAL2 provides high confidence that the claimant controls an authenticator(s) bound to the subscriber’s account. Proof of possession and control of two different authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.

• TEFCA - Trusted Exchange Framework (TEF) and the Common Agreement describes the control of the Qualified Health Information Networks. Some sections of particular interest to this use case go beyond the strict control to address requirements for the user interface devices.

  page 15 - The Cures Act emphasizes the need to improve patients’ access to their EHI. Many non-HIPAA entities, such as developers of smartphone apps, offer useful and efficient services to individuals who elect to use them as a means to access their EHI. These services allow individuals to play a greater role in managing their own health and shopping for coverage or care. It is essential that individuals have trust in these organizations and the use of these technologies that can ultimately enhance the quality of their care. Individuals, health care providers, health plans, and networks may not be willing to exchange data through the Common Agreement if smartphone app developers and other non-HIPAA entities present privacy or security risks because they are not obligated to abide by the HIPAA Rules. In order to meet the goals of the Cures Act as well as to help address these concerns and encourage robust data exchange that will ultimately improve the health of patients, the Common Agreement requires non-HIPAA entities, who elect to participate in exchange, to be bound by certain provisions that align with safeguards of the HIPAA Rules.

  page 17 - It is critical that Individuals have the opportunity to understand and make informed choices about where, how, and with whom their EHI is shared.

• Complying with the FTC’s Health Breach Notification Rule includes the HIPPA covered entities as well as third parties that hold medical data.
• ONC Model Privacy Notice is voluntary, but provides good guidance.