Social Networking in Health Care

1. Social Networking in Health Care Towards secure, privacy-preserving systems James Williams, BA, BSc, JD, Privacy Officer, Ontario Telemedicine Network. PhD candidate, University of Victoria.

2. Goal This presentation is an introduction to an understudied area in health informatics. We will address the following issues: • What are social networking applications for health care? • What unique security and privacy issues exist? • What techniques can address them? • What remains to be done?

3. OUTLINE Background • Basics of Social Networking (SN) applications. • Social Networking for Health Care • Examples Security/Privacy Issues • Issues with SN apps in general. • Unique features of the healthcare domain. • Current work. Future work.

4. Basics of Social Networking • The term ‘Web 2.0’ has been used to refer to internet architectures that permit content to be easily generated and published by users • Users are enabled to act both as readers and writers, generating content and creating a visible history of their activities. • Key notions include: • interpersonal networking, • personalization • individualism • empowerment The social web

5. Basics of Social Networking • First generation web applications like bulletin boards allowed users to communicate and collaborate. • Socialnetworking (SN) applications expand upon Web 1.0 apps by: • providing a persistent, explicit and publically visiblerepresentation of social networks. • providing a variety of mechanisms by which users may organize themselves. (ie: groups) • incorporating privacy protection. Online networks

6. Basics of Social Networks • A social network involves: • A set of users, represented by individual user profiles. • A set of mechanisms for exchanging information, such as message boards, email, and wall posts. • A set of binary relationshiptypes. • A set of searchfunctions, to locate user profiles. • A siteoperator, who controls the site. • A social network is naturally represented as a dynamicgraph in which an edge between two vertices represents a relationship between two user profiles.

7. . Basics of Social Networks Model of an SN

8. Social Networks in Health Care • ‘Healthcare 2.0’ has been used to denote the use of social software, with an emphasis on its ability to promote collaboration between patients, caregivers and medical professionals. • Patientempowerment may be a critical factor in achieving sustainability of the health care system. • Traditionally, the physician-patient relationship has exhibited a degree of information asymmetry. • SNAHC systems emphasize collaboration and independence. • User communities are springing up around ailments. • Active management may make patients more health conscious. Rationale

9. Social Networks in Health Care • In the case of health care, we have more than one type of user: • Patients • Providers • Care givers • Support staff • Family members • Substitute decision makers. Differences

10. Social Networks in Health Care • Basic social networking features are found in personal health record (PHR) systems, including Google Health, Microsoft HealthVault, and Dossia. • Google Health: • Allows users to store/manage PHI, including medical conditions, allergies and medication histories. • Users can search for information about medical conditions or adverse drug interactions. • Information in the health record can be shared. Users invite others to view their profile through email. Examples: PHRs.

12. Social Networks in Health Care Microsoft Healthvault: • Platform that provides basic services for PHR and social networking products. • Vendors can build customized products on top of it. • Each individual owns his or her record. • Others can be granted access to it, if desired. • The mapping between records to users is many-many, allowing for substitute decision makers and other scenarios. Examples

14. Social Networks in Health Care Healthy Circles • Patients can store emergency contacts, insurance plans, medications, immunizations, past procedures, test results, medical conditions, allergies and family histories • Users can enter basic health metrics and view reports. • Programs are interactive applications that typically require users to enter personal information in order to provide diagnoses or recommend treatment regimens or health management strategies. • users can purchase consultation or monitoring services from registered health care providers Examples

15. Social Networks in Health Care Patients Like Me • Patients can store a wide array of information. • The site operator encourages users to share as much information as possible. • Pharmaceutical companies are partners, using the site as a repository for voluntarily contributed data on outcomes. • Uses a more advanced social networking model. Examples

17. Security / Privacy Issues in SN • Awareness of Risk: Empirical studies show that users: • do value informational privacy. • typically do not change default settings. • are inclined to disclose information freely online. • often restrict their information only after breaches have occurred. • Users may lack a method for assessing risks in social networks. Social cues are missing. • They may also be unaware of the mechanisms for reducing risk.

18. Security / Privacy Issues in SN Ease of Network Formation: • An individual’s online social network tends to be more expansive, (containing more weakties), than the same individual’s offline network • users often misjudge the extent, activity and accessibility of their online social networks • Complex Workflows: • In general, social networking applications offer complex, many-to-many communications mechanisms. • The workflows are not easy to grasp, which makes the task of risk assessment more difficult.

19. Security / Privacy Issues in SN Trust: • Attackers may create fake profiles, and site operators may not follow their privacy policies. • Trust is a ‘social glue’ in a SN system. • Data Lifecycle: • Users have little knowledge about retention periods, backups, and the like. • Information posted on a SN may have ramifications for the user.

20. Security / Privacy Issues in SN Unauthorized Uses and Disclosures: • Site operators may use or disclose the data. • As an example, SN operators report increased demands for bulk data from governments. • Leakage to Applications: • Applications typically draw data from the system in order to deliver personalized experiences. • In many early architectures, they could retrieve quite a lot of information, including information about one’s friends.

21. Security / Privacy Issues in SN Aggregation by Third Parties: • Third parties (ie: ad servers) can receive personal information. • Since 70% of the market is controlled by a small number of firms, these companies are in a position to aggregate data from various sources. • Users typically are not aware that disclosures on one site may be linked to disclosures on another site.

22. Security / Privacy Issues in SN Complex Privacy Policies: • Because of the complex user scenarios, privacy policies for SN systems tend to be complex. • Studies indicate that some are inaccessible to users. • Enforcement is more difficult. Unlike ecommerce, a user may see another’s activities. • Market lacks competition for comprehensible privacy policies. • There are few methods for negotiating policies on a user’s behalf.

23. Security / Privacy Issues in SN Sunken Costs: • In Ecommerce, it is fairly easy to switch service providers. • In SN settings, the costs associated with switching providers are fairly severe. • Users may stay with an insecure and non-private system. • Shared Content: • Shared content creates privacy risks for users, since information may be linked to their profile without consent or knowledge

24. Features of the Heath Domain • Sensitivity of Information: • Tends to be very high, and protected by law. • Motivated Data Recipients: • Employers, insurers, researchers. • Secondary Damage: • Since many serious health concerns are genetically based, information about an individual can convey information about a family member.

25. Features of the Heath Domain • Community Interests: • Individuals sharing information on health trends can, if their submissions are aggregated, reveal information about the health issues affecting groups. • Motivated Data Recipients: • Employers, insurers, researchers. • Signaling: • The mere act of making an inquiry about a condition can be a signal that the individual in question has the condition. The same is true of an individual’s connections.

26. Features of the Heath Domain • Compensability: • Difficult to value PHI. • Indemnification and compensation is much more difficult. • Dynamic Networks: • Health teams form around episodes. • They are ephemeral.

27. What can we do (as software engineers, developers and systems architects) to alleviate some of these issues?

28. Current Work • Restrict information flowing to apps: • Privacy by Proxy. • User-to-application policies. New Access Models: • ‘proof’ to access particular resources. • Social Access Control List. • Walk through trusted nodes in the network structure. Securing the Framework

29. Current Work • Anonymizing Users • Use encryption and various key exchange mechanisms. • FlybyNight: uses client side javascript. • Respondent k-anonymity. • Fake data. • NOYB: map operations on fake data back to real data. Avoid ciphertext. Replace values pseudonoymouslyfrom a dictionary. Keys distributed out of band. Only works for small # of users. • FaceCloak: another approach using dictionary techniques. Securing the Framework

30. Current Work • Social network data can be extracted for processing or data mining. • Attacker may have background information, including knowledge of certain properties of the network. • Most of the techniques are based on anonymization. • Tabular algorithms don’t work well with network data. • Need to know privacy risk model, background knowledge, and intended use of data. • Two camps: • Clustering based. • Graph modification Dealing with Extracts

31. Future Work • Improved Privacy Controls: • Current social network applications allow the construction of hierarchies, including groups. • We need efficient, concise and usable controls for this. • Taking advantage of automation or group knowledge: • Agents • Automatically assigning trust to users/resources. • Heuristics (weighting), voting, reputation mechanisms. • Better user interfaces for privacy control management. • Show the effects of privacy control decisions. • Show what other users tend to do.

32. Future Work • Network Visualization Tools: • Some of the uncertainty surrounding privacy risks could be dispelled if users were able to visualize their networks. • To this end, user interfaces for displaying a user’s profile accessibility would be highly useful • increase the utilization of privacy options by clear representations of social networks, friend proximity, and availability of profile features.

33. Future Work • Detecting Attacks: • Future software architectures for health care could include facilities to discourage or detect common attacks. • For instance, prototypes could be developed that scan for fake user profiles • Also, search functionality can serve as a form of querying that can reveal both user identities and protected user information. • Find heuristic approaches for limiting queries.

34. Future Work • Security in the Architecture: • We need to do further work on secure architectures, along the lines of the efforts we have discussed above. • In particular, we should develop architectures that: • Work for all users (not just a subset) • Provide anonymity against the platform. • Make it easy to exchange keys.

35. Future Work • Shared Content Management: • We need mechanisms for assigning permissions to shared content. • This is particularly relevant in the health domain, where secondary disclosures may cause information to be revealed about the health of family members.

36. Future Work • Policy Negotiation and Representation: • Continue the development of tools and languages for representing policies. • Many privacy policy tools were developed with a single organization’s behaviour in mind. We also need tools for data exchange. • Methods for evaluating formal requirements in the context of policies would be highly useful.