Patient Registration with Distributed Attributes

Full Title of Use Case

Patient at private care provider (PCP) on-boarding ceremony to create initial EHR.

Context

• To provide good assurance that a patient data records are as accurate as possible and relate to a real live person.

Goal

• The patient in the very near future has full capability to exercise their right to participate in the care plan and see who has access to their medical records.
• Provide apis as described in the Health Care Profile.

1. Trusted Identifiers for all providers with clear terms of service.
2. Consent experience that gives the patient rightful ownership of their data and where it is shared.y
3. Collection of Attributes that can be validated by a health care provider to validate the patient.
   1. This may be extended in the future to patient provided medical record locators for EHR data.

Actors

1. Patient (aka the subject of the EHR - can also act as a user of computer services)
2. Provider of patient's general health care (the private care provider - PCP)
3. Digital Identifier or Attribute providers acting the some of the following roles:
   1. Risk assessment evaluation.
   2. UHIN
   3. Identity Authentication Provider

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 the 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 be 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. The private care provider (PCP) presents the patient with a Entity Statement which confirms that they subscribe to the privacy regulations of TEFCA and other appropriate regulations.
4. The PCP give the patient a list of documents to bring with them 30 minutes before the first appointment with the provider; for example:
   1. Health Insurance card
   2. Driver's licence
   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

• 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.
• The patient has access to Health IT Record Location Service (Data Aggregation) and brought a locator ID with them.

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 arraigned.
3. Patient sees the doctor, is reauthenticated (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.

Alternate Scenario:

1. The patient can sign onto the various practices' web sites and preform the actions from the comfort of her living room. In this case electronic consents are appropriate.
2. In this case the consent receipts will be renderable to the user in plain language that they can understand.

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. Consent receipt for access that they have granted to others.
   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.

Examples:

1. tbd

Dependencies::

1. Web Sites must be trusted before any user information is released.
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