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.

The User Imperative

The web must be available for all healthcare patients; not just those with the latest whizzbang phone.

Success Metrics

1. The value of the Patient Web Experience will be measured not by what it provides to the most capable divice and user, but rather by the net benefit to all patients.
2. As many patients as possible will be supported in their healthcare experience with high assurance identification and guidance to positive, healthy out-comes.
3. While most the Patient Web Experience will be through the web browser as the most common user agent, for security purposes the experience of the native app cannot be sacrificed to a good browser experience.

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 while still enabling the simplest cell phone to provide some benefit.

User Trusted Browsers

The web browser community is working hard to provide security and privacy to users on a browser that is known and trusted by the user. Native Apps and Embed browsers generally do not deserve the same level of user trust. In particular the browser can be used to collect and store user passwords for signing into web sites with an accepted level of security. The following advice is given by the RFC 6819

A malicious application could attempt to phish end-user passwords by misusing an embedded browser in the end-user authorization process, or by presenting its own user interface instead of allowing a trusted system browser to render the authorization user interface. By doing so, the usual visual trust mechanisms may be bypassed (e.g., Transport Layer Security (TLS) confirmation, web site mechanisms). By using an embedded or internal client application user interface, the client application has access to additional information to which it should not have access (e.g., UID/password).

Problems

• The web developers, and especially the web browser developers are drivien by a high level of urgency to enable the power of the web and the smart phone as they continue in their rapid gains in functionality.
• Web developers have focused on giving the Web App the same level of functionality as 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 so that these apps can be given priority whenever the user really needs them to work on the user's behalf.
• 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.
• The smartphone development environment 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.
• The browser and the web apps do not currently provide access to a key store and if they did, that the keys in the store would become available to all javascript down loaded from a web site.

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.

• 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 the capability to report on its own provenance. See the wiki page on Native Apps for US Healthcare'

Trusted Native Apps

A variety of methods have been proposed to signal trust if apps provided to users, for example trust-marks.

Proposed Tests of the Patient Web Experience

1. Create a Service Acceptance Criteria (SAC) and test any app (native or web) that wants to access Patient Health Information (PHI) from an Electronic Health Record (EHR).
2. Provide any certified app with a Mobile Authentication Assurance Statement (MAAS).
3. Ensure that part fo the EHR criteria is to validate the MAAS before releasing PHI to an app.
4. Validate the user experience of the Mobile App
5. Test the performance of the app on the earliest supported version of a smart phone from each os.
6. Load the native browser on the test smartphone with at least 3 complex web sites (perhaps crafted just for the purpose). And retest the performance of the app.