Emergency Contact Information Use Case

From IDESG Wiki
Jump to navigation Jump to search

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.
  • First responder or other emergency access of patient health information (PHI) in an Electronic Health Repository (EHR) is call a "brake-the-glass" emergency in the sense of the common fire alarm or heart defibrillator in the hallway that cannot be used without some destructive act, like breaking a glass seal, that can clearly be seen and heard and cannot be repaired by the perpetrator.
  • This use can can easily be extended to other sources of user-provided information, but it is likely that the solution would not change much.

Goal

  • The user has full capability to exercise their right to participate in the selecting the people that are notified in an emergency.
  • Extensibility 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 the user, both the subject and the person listed as a contact.

Examples of Problems to be Addressed

In early 2017, Seema Verma, then the country’s newly appointed CMS administrator took trips to hear about the problems of the EHR systems. "...one summer day in 2017, when her husband, himself a physician, collapsed in the airport on his way home to Indianapolis after a family vacation. For a frantic few hours, [Verma] fielded phone calls from first responders and physicians — Did she know his medical history? Did she have information that could save his life? — and made calls to his doctors in Indiana, scrambling to piece together his record, which should have been there in one piece. Her husband survived the episode, but it laid bare the dysfunction and danger inherent in the existing health information ecosystem."

Fred Schulte and Erika Fray, Death By 1,000 Clicks: Where Electronic Health Records Went Wrong. (2019-03-18) Forturne https://khn.org/news/death-by-a-thousand-clicks/

Demonstration Sample

A working example of this use case is now available at http://controls.azurewebsites.net


Actors

  1. User
  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 user knows and trusts to tell her whether any healthcare web site can be trusted with her data.
  3. The providers of health care and lab services present the user 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 user, to write into their EHR, so it is expected that the user will have multiple repositories, each with their own Medical Records Identifier.
  5. Users can always get their own data, but only after strong authentication. This data will include a list of existing consent grants. The user or contact always has the right to revoke consent.
  6. Contact has right to know that they are in an emergency contract list and can update their own contact information.

An optional condition would be for the user to have a trusted (AAL2) identity in cyberspace that can be directly targeted to provide needed information to the First Resonders.

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 displays a trusted identifier to the user before asking for any information.
  2. The site home page assumes no information was given to the user prior to opening the app and tries to educate the user.
  3. The user decides to start the journey and clicks "Start".
  4. The function of site, the use of the information and the user rights are clearly explained.
  5. The user is authenticated and given the test.
  6. The lab has consent and so passes the user data to the emergency responder.
  7. The doctor asks for user 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 user may or may not also get the results.
  10. The user 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. There are two path that they could take, the deliberately chose to register or they try to navigate to a page that requires sign in.
  2. Take them to a registration page that explains why registration is important before they can use the site (redress, recovery, etc.)
  3. -- open question, should we create a mailing list for people that want to say informed? - seems like a short term thing, but who knows?
  4. In this case electronic consents are appropriate.
  5. In this case the consent receipts will be renderable to the user in a clear user experience.

Journey 3 - The user has already been done identity proofing with their PCP physician and has an IAL2 credential from that site.

Results

Accepted Risks:

  1. Data transfers involved work within a framework of trust and mutual understand as to the user's wishes with respect to care and privacy.
  2. It is not clear how a non-responsive user can provide sufficient details to the First Responder. Presumably the existing First Responder network can provide some guidance on that challenge.

Post Condition:

  1. There are now two additional consent steps, both of which provide a consent receipt to the user.
  2. No data is ever shared with any provider that has not been strongly identified to FirstNet (which would include emergency rooms).
  3. The user results are available it is assumed that the consent receipt acknowledged that the access information would be sent back to the primary care doctor as well as to the user for later reference.
  4. Access by the emergency medical technician or physician is covered by sovereign immunity and not privacy law. (Break-the-glass access.)

Examples:

  1. In operation whenever a user's EHR is accessed by "breaking the glass" that protects the user data, the user will be notified of the access.
  2. A reasonable extension of this use case is for all people on the emergency contact list getting notification whenever emergency access is requested.

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

Retrieved from "https://wiki.idesg.org/index.php?title=Emergency_Contact_Information_Use_Case&oldid=13828"