Remote Attestation Use Case

Full Title of Use Case

A user with a Smart Phone goes though a series of actions that will provide subsequent statements from that user on that phone with a higher level of assurance.

Context

• To provide Level 2 or Level 3 assurance of a user NIST SP 800-63-3B

Goal

• The primary goal is to enable patient choice in the selection of the types of attestation that they can seek commensurate with the requirements of relying parties with which they desire to establish an enduring, secure channel of communications for the mutual benefit.

Actors

1. A new patient (aka the subject of the EHR - can also act as a user of computer services)
2. The Provider of patient's general health care (the private care provider - PCP) that is creating the EHR which they control for its own and the patient's future reference.
3. Digital Identifier or Attribute providers acting the some of the following roles:
   1. Risk assessment evaluation which may be any insurance or financial provider,
   2. Medical Records at some Qualified Health Information Network (QHIN) web site, (See appendix 3 of the of TEFCA spec for details on QHIN.)
   3. Identity Authentication Provider to evaluate the rights and accuracy of the patient's link to any particular medical records,
   4. Medical providers for consultation or referral. Specifically providers outside of the PCP that might need data interchange agreements.

Distributed Attributes

• This use case assumes that it will not be possible to have a single aggregation of all of a patient's digital records in a single provider. While such aggregation may be possible in smaller countries, 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 based on a fragmented source of patient data.
• As a general rule, a single unified source of data is also a single point of failure that is not responsive to patient concerns. It is considered to be both more resilient and more responsive to provide an ecosystem where patient attributes are distributed among parties that are responsible for the validity and integrity of the attributes.
• In this context patient attributes are considered to include personal and financial attributes as well as medical records.

Preconditions

1. The patient has self-selected to become "known to the practice" where general health care is provided.
2. A trust registry of providers exists (based on TEFCA) which the patient knows and trusts.
3. When accessed online, the private care provider (PCP) presents the user agent of the patient with a Entity Statement which confirms that they subscribe to the privacy regulations of TEFCA and other appropriate regulations to assure the patient that their health care data can be safely stored and accessed at their web site.
4. The PCP give the patient a list of documents to bring with them before the first appointment with the provider in order to initiate the creation of the EHR; for example:
   1. Health Insurance card
   2. Driver's license
   3. Payment card to be used for co-pays or other changes which may occur. (Cash may be possible but is not considered here.)
   4. Other providers will have created an EHR with its own Medical Records Identifier that the patient could potentially bring with them to gather existed EHR rather than rely on their own memory of their health history.
5. Patient can always get their own data, but only after strong authentication. This data will include a list of existing consent grants. The patient always has the right to revoke consent
6. The patient has the right to eliminate some individuals in a practice from seeing their data even when the practice has access.

Optional Conditions

1. The patient has one or more trusted identifiers in cyberspace that can be used to access their health records at any of their care providers.
2. The patient has access to Health IT Record Location Service (Data Aggregation) and brought a locator ID with them.
3. The patient has a smart phone with a health maintenance app that allows them to bring their health records to, or to take their health records away from, the PCP at registration.
   1. The smart phone app may have the data stored locally, or in a web site that supplied the app. In all cases the data is covered by HIPAA regulations.

Scenarios

The goal of this scenario is to test the functionality of the APIs associated with patient trust of the providers and patient consent granting and recording.

Primary Scenario:

1. Patient schedules an appointment with primary care physician and is authenticated at the front desk. (This will typically include a request to grant access held in the EHR at the practice to others - aka a consent form.)
2. As the receptionist collects patient data, an EHR is built up. Before the patient is permitted to see the provider the patient identifiers and attributes are built up into an Attribute Vector, which is combined with a risk profile of the PCP to create a trust vector which is scored by the computer. If the patient does not have sufficient trust score, the computer will direct the receptionist to continue to collect data until the following conditions (inter alia) are met:
   1. The real-world individual is identified,
   2. The real-world health history is sufficient,
   3. Payment has been adequately arranged.
3. Patient sees the provider(s), is re-authenticated (this reauth will be less onerous than that at the front desk) and explains symptoms.
4. The provider and others at the practice continue to collect patient health information and add it the the PCP EHR.
5. The provider may create diagnoses, health care plans, prescriptions or refer the patient to other providers during the visit.
6. At check-out additional actions, like payments or paperwork is provided. Re-authentication would apply at this step as needed by privacy concerns.
7. For new patients, the patient is given, or is mailed, a form the the following pieces of information that can be used to establish an online presence.
   1. A URL to the patient chart on the web. This is the site of the EHR, which may, or may not, be the same as the provider, such as would be the case for a conglomerate of several providers.
   2. An access code that allows them to create an identity proofed sign-in capability at the provider.

Alternate Scenario:

1. Before accessing the EHR the patient will need to follow the instructions on the form provided above.
2. The patient can sign onto the various practices' web sites and perform the actions from the comfort of her living room.
   1. Electronic consents are appropriate whenever additional consent is granted by the patient. Any consent receipts will be renderable to the user in plain language that they can understand.
   2. All sites that display patient data requires strong authentication of the patient and compliant protections of user information.

Following is one example of an online registration ceremony that has worked in the past to provide identity proofing of a patient at a web site.

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 patient is given:
   1. A registration consent receipt for access that they have granted to others (e.g. data processors or providers who have EHRs of their own)
   2. Care plan including POLST and similar declarations that the patient has made to the practice.
   3. Access to their EHR (with sufficiently strong authentication.)
2. The EHR includes followup contact (phone, email, etc) information to inform the patient of care plan milestones that the patient has agreed to accomplish.
   1. This notification capability can be used for other information that needs to be communicated to the patient after the visit and registration.
3. Any referrals to other practitioners might be part of the this PCP, in which case it is covered by these consents and other terms, but referrals to other practitioners possibly need their own EHR.

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

• Stanford University CS259 Project Report - Security Analysis of Remote Attestation by Lavina Jain and Jayesh Vyas

  Remote attestation is a method by which a host (client) authenticates it’s hardware and software configuration to a remote host (server). The goal of remote attestation is to enable a remote system (challenger) to determine the level of trust in the integrity of platform of another system (attestator). The architecture for remote attestation consists of two major components: Integrity measurement architecture and remote attestation protocol.