View source for Patient Web Experience

==Full Title or Meme==
The [[Patient Web Experience]] needs to be created in such a way that improves long-term patient out-comes for the entire duration of their life.

===Goals===
# The value of the [[Patient Web Experience]] will be measured not by what it provides to the most capable divide and user, but rather by the net benefit to all patients.
# As many patients as possible will be supported in their healthcare experience with high assurance identification and guidance to positive, healthy out-comes.

==Context==
* The [[Patient-centric]] view of this Identity Wiki extends to the use cases across a range of use cases. This wiki page focuses on the interactions of the patient and their guardians with the web and with their devices that act as agents giving them access to the web.
* The majority of the focus will be on the use of a smart phone by the patent to provide a high assurance identifier from the patient to the healthcare provider and 

==Problems==
* The web developers, and especially the [https://www.youtube.com/watch?v=y3EZx_b-7tk web browser developers] are driving by a high level of urgency to enable the power of the web and the smart phone as it continues in their rapid gains in functionality.
* Web developers have focused on giving the [https://tcwiki.azurewebsites.net/index.php?title=Progressive_Web_App|Web App] the same level of functionality ad [[Native Apps for US Healthcare|Native Apps]]. Since the patient cannot often tell the differences between these, this page will not speak to it expect to point out some case where the security of [[Native Apps for US Healthcare|Native Apps]] are better.
* In particular as web apps consum more of the smartphone resources, native apps may be staved for the performance that they need to give the user a good experience. Allowing such a conflict to play out will harm users.
* The users have no simple way to tell the smartphone which apps are actually critical to their safety and well-being.
* At some level they grant a small amount of effort to assure [[Usable Req 7|Accessibility]] for users with some physical impairment, but there has been little attention given to the long term use of patient identifiers and devices.

* OpenID understood that the web browser was likely to be the best choice that a user could hope to make in terms of a ux that would honor the user's intentions.

* The phone is even uses the language of intention to describe the choices it makes on behalf of the user as to the specific piece of code to invoke to achieve those intensions.

==Solutions==

# This page is designed as an '''Explainer''' of healthcare issues so that architect of both native and web app solutions can discover the best solutions. So these solutions are really just suggestions as to the way to form the solutions.
* The browser doesn't provide access to a key store and if it did, that resource would become available to all javascript down loaded from a web site.
* Code that is able to handle user secrets is hard to get right. It is imperative that such code is strongly vetted by trusted validators.
* For web sites to know that the code is validated the code needs to report on its own provenance.

==References==

[[Category: Health]]
[[Category: User Experience]]