A Standardized Information Governance Label for apps and services

A Standardized Information, Governance, Label for Apps & Services

Tuesday 2G

Convener: Adrian Gropper

Notes-taker(s): Thomas Berry

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Link to PPR Information Governance Label Doc: bit.ly/PPR-IGL

Formed from work on Patient Privacy Rights (PPR)

• Shift risk to consumer or service provider (supplier)
  • Facebook/Cambridge analytics
  • Nutrition information on food
• Variation on Privacy by Default (e.g., HIPAA)

Service App ranks 0-5 √

• 1. No sharing: The data is never shared with any external entities. It is not even shared in de-identified form.
• 2. No aggregation: The data is never aggregated with other types of input or data from external sources. This includes mixing the data gathered via The Device with other data, such as patient-reported outcomes.
• 3. Always voluntary self-identification: The user of The Service is able to choose their own identity, the user does not need to have their identity verified unless required by law.
• 4. Digital Agent Support: The user is able to specify a digital agent, trustee, or equivalent information manager, and this specified agent will not be subject to certification or censorship.
• 5. No vendor lock-in: This service is easily and conveniently substitutable, so the user can easily move their data to another vendor providing a similar services. This prevents vendor lock-in and is often accomplished using Open Standards.
• [6. Differential Privacy] removed because it could be gamed.

Indications for Use: The five separately self-asserted statements on the PPR information Governance Label are subject to legal enforcement as would the privacy policy associated with The Service

Objections:

A. Could decrease sharing which could be damaging to community benefit (e.g., science)

B. Aggregation may restrict functionality

++C. Does not state how data will be used (stated positive purpose of use)

D. Not useful if no choice

E. Too “strong” or “rigid”

F. Privacy by default is [could be] antisocial

G. Needs ordinal checkboxes (red-yellow-green)

H. 5. No vendor lock-in is too loose to be useful

H2. Bundling of service is discouraged

 Vendor lock-in has to be “loose”

I. Too philosophical