What electronic health records don’t know just yet. A privacy analysis for patient communities and health records interaction

Abstract

The advent of Web 2.0 has resulted in the emergence of a new generation of user-centric applications. Healthcare too follows this trend and a whole range of health-related applications are being introduced. Electronic health record (EHR) systems are being developed to enable electronic storing and sharing of medical data between health practitioners. Recently, initial steps have been taken to evolve toward cross-border sharing of EHR data. Patients also become more involved in their healthcare and start storing their health data online in personal health record (PHR) systems or look for online support and medical advice from other patients with similar diseases or treatments. The consolidation of these different systems is described as a promising approach to bring healthcare to a higher level. A consequence of this evolution is the rise of new privacy threats to the patient’s medical data, as more data becomes easily accessible to more people. Not only the treating physicians have access to the health data, the patient himself will have direct access to it and even be in control of his data and the access to it. As a first step in the answer to this trend, this paper presents a legally-founded analysis of the privacy issues emerging from the integration of EHR and patient communities. First, a taxonomy of health data types and user roles that have a key role in integrated health record systems is proposed. Second, privacy-preserving access rights are discussed and a set of privacy-aware access levels are suggested. Finally, ethical, legal, and technically challenges are highlighted, and a set of high-level privacy-enhancing technical requirements are presented.

Appendices

Appendix A: Classification of existing systems

This section briefly discusses a number of existing systems and applications that were classified according to the taxonomy presented in this paper. The classification is visualized in Table 5. The summary of this classification is presented in Section 3.3.

Table 5 Categorization of existing systems (R: read; W: write; R^W: read+requests modification; X: owner/controller; X^O: only accessible by owner/controller)

EHR/HIS systems

Currently no full-fledged EHR systems exist. Some initiatives that focus on a specific document type are running, like the EPSOS project²⁶ which focuses on patient summaries and electronic prescriptions. NHS introduces care records²⁷ which also contain the patient’s summary. Recip-e ²⁸ is another local initiative that allows online transfer of prescriptions between prescriber and care provider. All these systems can be classified as storage and exchange of medical EHR data between doctors of medicine. Recip-e and EPSOS also allow medical staff (like pharmacists, physiotherapists, etc.) to access prescriptions. Also, several projects exist that try to bridge the gap between existing HIS and EHR systems. For example, the local Share4Health project²⁹ aimed at combining data from different hospitals, GP offices, and pharmacies into one big virtual record, accessible by treating doctors and pharmacists. Other projects focus on the collection of data from both doctors and medical staff, like InterRai ³⁰ and BelRai ³¹ which aim at integrating all health data to improve (home) care for elderly and disabled patients. In this case, medical staff is considered a subtype of doctors as they can access and update the patient’s EHR data.

Of course, also basic medical software solutions should be considered. As so many suppliers exist, we only considered two locally well-known software packages. The first one is MediBridge,³² which focuses on hospitals and GP practices and their collaboration and which can also be used by medical staff to exchange doctor-controlled health data. A second one is MediDoc,³³ which is developed explicitly for GPs and provides a complete package to store both medical and administrative data. Note that, whenever medical, raw or administrative data are involved, also the corresponding biographical data should be considered.

As an example of patients who get access to their EHR data, we examined the Boston Children’s Hospital patient portal,³⁴ where patients can access their medical data, manage their demographics (biographical data) and maintain their billing and appointment data (administrative data). The portal also enables the access for trustees.

PHR systems

Even though the main purpose of PHR systems is the patient’s personally maintained health history, systems nowadays support more functionalities. If the patient allows additional services or extensions to be integrated in his PHR, not only will a patient be able to keep track of his own health, he can also share it with trusted friends and treating doctors and content can be updated and extended by these treating doctors. Both Google Health³⁵ and Microsoft HealthVault³⁶ support all these extensions and broaden the meaning of PHR to an integrated view on health data created by both the patient himself as his treating doctors.

Google Health’s main purpose was to store and manage the patient’s own medical data. It could also be used to share data with others on a read-permission basis (entire profile can be shared with someone the patient trusts, e.g. friend, physician, semi-medical staff). When adding “services” to your Google Health profile, you could add applications of your health providers (hospitals, GPs, pharmacies, etc.) which in their turn could access and sometimes even update your information. Additional data generated by the patient’s doctor (medical EHR data) could also be accessed via the application. When medical staff generates additional data, it was assumed these are stored in the PHR (although in the future this might merge with EHR data). Trustees were only very limitedly supported. A Google Health user had the possibility to create a profile for other users (e.g. children, elderly parents, etc.) but no further support was provided for trustees. Sharing data with physicians was supported in three ways: when the physician supports Google Health and data is shared through a service; when the physician is invited as a friend to the patient’s profile; and when the patient simply prints out his PHR and brings this paper version to his consultation. Updating PHR data was also supported in three ways: the patient fills it out manually; a registered service (e.g. connected to the patient’s hospital or treating physician) alters the data; or the patient can upload and integrate medical files from supported formats (e.g. if the treating physician mails a lab report in a supported digital format to the patient). Unfortunately, Google has decided to discontinue this service.

Microsoft HealthVault has access settings which are more advanced than those in Google Health. When a patient creates PHR data, he can decide to completely share or partially share his data (determined by record type). Possible sharing rights are: view (corresponding to friends access rights), view+modify (corresponding to medical staff access rights), and custodian: same rights as patient (corresponding to trustee access rights). It is also possible to classify a record as personal. This means that it will not be shared with anyone else. Similar to Google Health, it is also possible to integrate parts of the patient’s EHR (like prescription/medication history) in his HealthVault profile by including the appropriate services.

A more elaborate comparison between Google Health and Microsoft HealthVault is described by Sunyaev et al. [1].

An application that combines EHR and PHR systems is HelloHealth.³⁷ It combines online doctor-patient communication, practice management and health record storage. In summary, doctors can store and maintain their patients’ EHR records and manage their appointments and billing. Patients can make doctor appointments, either a classical consultation or an online consultation via chat or webcam, and manage their PHR. The platform allows the patient to access his EHR data from his treating doctor(s), as well as it keeps the doctors informed on the patients’ updates.

Also, the Czech Electronic Health Book ^{(EHB) 38} [2] can be seen as a combination of EHR and PHR systems. D7octors add medical data as in EHR systems; however, the patient is fully in control of the access rights toward the doctors. He can either share his data with all doctors in the system or can create a set of confidential healthcare professionals. The patient can also alter administrative data and certain medical data, or request (partial) removal of a certain item. Similar to PHR systems, patients can add their own (subjective) entries in the system which can be shared with the doctor as well.

Patient communities

When examining patient communities for this paper, we only focused on the data produced by the patient himself. Clearly, when a patient posts a message on a discussion board, the responses can also be relevant to the patient. We however do not consider these responses as “input” to the health data about the patient. In our classification, only the patient himself (or his trustee) will create non-structured patient data.

Patientslikeme ³⁹ is a highly popular patient community site with over 100 000 users.

It is focused on sharing health data with the entire community and even non-members. Sharing with friends or trustees is not explicitly supported as the website has an openness philosophy. Patientslikeme believes that sharing healthcare experiences and outcomes results in collaboration on a global scale. Privacy is thus of less importance. Two privacy settings are supported: visible (for community members), and public. Although users are not obliged to fill in any personal identifiable data, they are encouraged to do so. Medical, lifestyle and biographical data is all combined into one patient profile. Registered users also have access to the online forum.

MedHelp ⁴⁰ is another online patient community, which calls itself “the world’s largest online community with over 12 million monthly visitors”. MedHelp connects people with medical experts and others who have similar experiences. They provide forums (both support groups and ask-a-doctor forums) and health related tools (e.g. weight tracker, sleep tracker, PHR, …). Any information shared in a personal page, message board, or online discussion is by design open to the public. Some features however, such as journals, photos, and personal pages can have their access set by the patient. Three privacy settings are supported: private, friends, and public.

MDJunction ⁴¹ is also a patient community site, although less advanced than the previously discussed ones. It contains several online support groups in a forum-like fashion and allows each user to keep a diary and post articles (and thus only represent non-structured data). MDJunction supports 4 privacy settings: private, friends, members, public (although forum posts always are public).

SugarStats ⁴² is a community aimed at diabetes patients. As stated on its homepage, it provides online diabetes management, community support and collaborative sharing to motivate and improve health. It allows the patient to visualize his progress, meet other diabetics with community groups and discussion forums, share statistics with family, friends or doctors, and track and manage medication, food and activities. Four privacy settings are supported for an account: private, friends only, members only, and public. The default setting for all new accounts is "members only". Although SugarStats claims that it supports sharing with treating doctors, this is just a specific implementation of the “friends only” sharing property. Therefore, we did not include this application in the table for doctor-PHR access.

One example of a patient community where doctors and medical staff are more involved is WebMD.⁴³ This website provides useful information in the form of blogs and allows patients to ask questions in the corresponding health forums. These questions can be answered by other patients, medical staff and doctors. As indicated earlier, this paper does not focus on communities moderated by healthcare personnel. We consider these users merely a subgroup of community members, as they are not the patient’s “treating” doctors or medical staff. Therefore WebMD is only included in Table 5 between brackets for medical staff and doctors.

Finally a very promising application is the IBM patient empowerment portal [4].⁴⁴ It is a good representation of how IHR systems should work. It combines medical and social data as it allows patients to share their medical data with other patients. It is beneficial for the patient as he gets an integrated overview of all his medical data and he can communicate with his treating doctors. Doctors can also use the system to keep their patients informed on medical-related events. Also trustees are supported, for example, a mother can use the system both for herself and her children. As it is currently an ongoing R&D project, no technical information is available yet, and it is unclear how EHR is integrated in this portal and who is responsible for the creation and maintenance of the data. It is therefore not included in the overview table.