View source for Emergency Contact Information Use Case

==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]].
# Give the contact person ability to impact the record about their own data and availability as a contact.
# Consent experience for user

===Actors===
#User
#Provider of specialized services related to emergency contact and other information.

==Preconditions==
# The user has learned that it is possible to store their contact information which leads them to the site.
# A trust registry exists which the user knows and trusts.
# 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.
# Different providers are unlikely to allow each other, or the user, to write into their [https://tcwiki.azurewebsites.net/index.php?title=EHR EHR], so it is expected that the user will have multiple repositories, each with their own [https://tcwiki.azurewebsites.net/index.php?title=Medical_Records_Identifier Medical Records Identifier].
# User 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
# Contact has right to know that they are in an emergency contract list and can update their contact information.

An optional condition would be for the user 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:

#The user goes to the web site which gives a trusted identifier to the user before asking for any information.
#The site home page assumes not information was given to the user and tries to educate the user.
#The user decides to start the journey and clicks "Start".
#The function of site, the use of the information and the user rights are clearly explained.
#The user is authenticated and given the test.
#The lab has consent and so passes the user data to the emergency responder.
#The doctor asks for user consent to schedule further diagnostics with a doctor in a different practice.
#The user can evaluate the site with respect to competence and compliance with appropriate privacy practices.
#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.
#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:
# The 
# In this case electronic consents are appropriate.
# 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:
#Data transfers involved work within a framework of trust and mutual understand as to the user's wishes with respect to care and privacy.

Post Condition:
#There are now two additional consents steps, lab with sensitive data and secondary provider with sensitive.
#No data is ever shared with any provider that has not been strongly identified to the user.
#The user results are available it is assumed that the consent receipt acknowledged that the data would be sent back to the primary care doctor.

Examples:
#tbd

Dependencies::
#Web Sites must be trusted before any user information is provided to them.
#Trust federations can be used to help users make informed decisions.
#User consent and trust must begin with no user information transferred.
#Standards exist to collect needed attributes where-ever they may be.

==Workflow Diagram==
TK

==References==

[[Category:Use Cases]]
[[Category:Profile]]
[[Category:Health]]