User Agent in the Cloud

Full Title of Use Case

A user with a modern browser on an internet connected computing device can establish an agent on a trustworthy web site to allow access to information 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 user's behalf as a gateway to PHI contained in an 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

• These are the real-world entities that have a direct interest in the user's information. Support organizations are not listed here.

1. A user that has information that they want to keep private, for example, a patient and their health information.
2. A user acting as a Guardian of the data on behalf of the owner of the data, for example, the parent of an under-age child.
3. An organization that needs to acquire a user's information to function well, for example, a medical practitioner to which a patient has been refereed.

Digital Roles

• These are abstract roles that can be aggregated in any way that is appropriate for the community of interest.

1. A new computer 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 trust registry that can verify which web sites have been proven to protect the user's data in the domain of interest, for example sites that are covered HIPAA entities.
   1. From the user's perspective the most important part of this role is to give the user the confidence that they need to upload the private information.
3. A trustworthy site that can act as an Identifier Provider (IDP) authenticating the user and maintaining a list of user preferences. In other words, an agent empowered by the user.
4. An application level network that understands the meaning of a request for data and can find and move the data between the source and sink.
5. A relying party that has high value data that a user wants to keep private, for example, medical records in an Electronic Health Repository . The source of the user data.
6. A relying party that needs to upload user private information, for example, medical records for an Electronic Health Record service. The sink of the user data.
   1. Any provider of services that is trusted with user data within the community of interest, for example a medical provider that is registered with the government.
   2. An emergency or legal authority that has statutory right to obtain the user's data. In other words, an emergency provider that can "break the glass" that is protecting the user data from release.

Distributed Attributes

• This use case does not require 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 is unlikely to be possible in any federal system where the individual states have responsibility for the health of their residents, like the US or the EU. To accommodate this reality, the use case is designed to be resilient in the face of distributed sources 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 (and must) trust the browser for the use case to work.

Healthcare Specific Conditions

1. A healthcare specific trust registry exists to attest to providers of Electronic Health Record (EHR) and software applications, 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. There is a publicly accessible, free API to query the trust registry in a user-friendly manner.
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. While this use case does not preclude the deployment of a web app by the agent, it is the most likely scenario. The web app IS NOT dependent on any native app running on the user's computer or embedded in the user browser. Web browser plug-ins are not excluded, just not required. Native code applications are NOT considered for this use case.

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 patient's health care interests.
3. User can access the records on the PCP EHR web site.
4. User navigates to any web site that has sufficient trust as per the site's entry in the trust registry.
5. The user selects or creates an identifier on the agent. (It is expected that sites will provide the user options in this selection.)
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 is guided through a process of acquiring identity proofing from the PCP. This could be any of:
   1. A QR code on a piece of page on of the PCP web site.
   2. An API that can be called by the trusted user agent.
   3. others?
8. The user agent contacts the PCP (EHR) and gets back a packet of information that attests to the validity of level 2 access.
   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 into their cloud agent with their level 2 resources (at this point the only advantage over existing PCP web site access is the ability to download complete user information in machine-readable format.)
10. The user downloads data from the any site supported by the user agent.
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 enable transfer the medical information between providers for any period of time that is appropriate for the user and for any category of data that is supported by the network.

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, which can be delegated to the user agent
3. The QHIN will then be able to query the user agent for permissions rather than as the user directly.

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 to their agent.
   2. The ability to seamlessly register with any other participating entity (covered entity or QHIN.)
   3. Trust in their user agent to approve background transfers mediated by the various approved and HIPAA covered entities.

• 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 are effective in helping users make informed decisions.
3. User consent and trust must begin with no user information transferred other than some method to notify the user of any problems.
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 HIPAA covered entities as well as third parties that hold medical data.
• ONC Model Privacy Notice is voluntary but provides good guidance.