Patient Web Experience: Difference between revisions

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


* 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.
* 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==
==References==

Revision as of 06:13, 6 September 2020

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

  1. As many patients as possible will be supported in their healthcare experience with high assurance identification and guidance to a positive out-come.

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 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 App the same level of functionality ad 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 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 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

  1. 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