Emergency Contact Information Use Case: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
Line 6: Line 6:


===Goal===
===Goal===
* The patient has full capability to exercise their right to participate in the selecting the people that are notified in an emergency.
* The user has full capability to exercise their right to participate in the selecting the people that are notified in an emergency.
* Extendibility to provide access to patient care stipulations that would help First Responders provide care.
* Extendibility to provide access to user care stipulations that would help First Responders provide care.
* Provide the privacy and other considerations as described in the [[Health Care Profile]].
* Provide the privacy and other considerations as described in the [[Health Care Profile]].
# Give the contact person ability to impact the record about their own data and availability as a contact.
# Give the contact person ability to impact the record about their own data and availability as a contact.
# Consent experience for patient
# Consent experience for user


===Actors===
===Actors===

Revision as of 20:17, 12 March 2019

Full Title of Use Case

Any person that wants First Responders to be able to contact specific people in case of emergency.

Context

To provide good assurance that a user contact data is kept as private as possible consistent with emergency access.

Goal

  • The user has full capability to exercise their right to participate in the selecting the people that are notified in an emergency.
  • Extendibility to provide access to user care stipulations that would help First Responders provide care.
  • Provide the privacy and other considerations as described in the Health Care Profile.
  1. Give the contact person ability to impact the record about their own data and availability as a contact.
  2. Consent experience for user

Actors

  1. Patient
  2. Provider of specialized services related to emergency contact and other information.

Preconditions

  1. The user has learned that it is possible to store their contact information which leads them to the site.
  2. A trust registry exists which the patient knows and trusts.
  3. The providers of health care and lab services present the patient with a trusted identity which confirms that they subscribe to the privacy regulations of the trust provider.
  4. Different providers are unlikely to allow each other, or the patient, to write into their EHR, so it is expected that the patient will have multiple repositories, each with their own Medical Records Identifier.
  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.

An optional condition would be for the patient to have a trusted identity in cyberspace that can be used to access their health records at any of their care providers.

Scenarios / User Journeys

The goal of these scenarios is to test the functionality of any web site were the user access and update their information.

Journey 1 - the user's comes to the site to learn what emergency access really is:

  1. The user goes to the web site which gives a trusted identifier to the patient before asking for any information.
  2. The site home page assumes not information was given to the user and tries to educate the user.
  3. The patient decides to start the journey and clicks "Start".
  4. The function of site, the use of the information and the patient rights are clearly explained.
  5. The patient is authenticated and given the test.
  6. The lab has consent and so passes the patient data to the doctor's practice.
  7. The doctor asks for patient consent to schedule further diagnostics with a doctor in a different practice.
  8. The user can evaluate the site with respect to competence and compliance with appropriate privacy practices.
  9. The user gives consent, schedules a consultation and the lab results are passed to the other practice. The patient may or may not also get the results.
  10. The patient receives a consent receipt from the primary doctor as to the transfer of health records to that other practice

Journey 2 - the user is directed to the site as they do want to start to collect contact data:

  1. The
  2. In this case electronic consents are appropriate.
  3. In this case the consent reciepts will be renderable to the user in understandable user experience.

Journey 3 - The user has already registered with the 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. There are now two additional consents steps, lab with sensitive data and secondary provider with sensitive.
  2. No data is ever shared with any provider that has not been strongly identified to the patient.
  3. The patient results are available it is assumed that the consent receipt acknowledged that the data would be sent back to the primary care doctor.

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