Personal Preferences Approach


An approach to reducing barriers to virtual healthcare is to consider the greater context of an individual and not just the tasks they are required to perform. This approach, called the "Personal Preference Approach" herein, is intended to help individuals discover and express their personal needs and preferences, and the contexts in which those preferences work best. The Personal Preferences Approach does not prescribe any specific technologies, but illustrates how someone can discover and express their needs and preferences; allowing for the personalization of complex systems. The system incorporating a Personal Preferences Approach should be designed so it can scale, expand / contract, and have a flexible number of parts that can be orchestrated together based on the individuals own personal needs and preferences. All the while, respecting the individual's control over which pieces are connected and what information each has access to.

This Personal Preferences Approach is informed by the Guide for Reducing Barriers to Virtual Healthcare and demonstrates the use of values, principles, and guidelines from the Guide:

The Personal Preferences Approach is also informed by a history of applied research on personal preferences on projects such as Floe, GPII, and more. In future research and development, the Personal Preferences Approach should be informed by inclusive co-design activities and additional tasks as mentioned on the Future Considerations page.


An example of implementing the Personal Preference Approach can be assembled using components and frameworks developed by the Fluid Project: Preferences Framework, Personal Data Server. A Preferences Framework instance, such as UI Options, provides direct setting and enacting of preferences, making use of local storage for later re-application. To help achieve scale and facilitate the expression of personal preferences across multiple applications/systems/platforms, a Personal Data Server can be used to store and share preferences.

The Scenarios and Explorations pages include additional examples and ideas about applying the Personal Preferences Approach to virtual healthcare platforms.


Often systems are designed for the hypothetical average, but in actuality there is a range of diverse needs that people experience. These needs may be context dependent; varying across time, place, activity, etc. While a system designed for the hypothetical average may seem more cost effective to implement, it will create barriers for those that are outside of the "average", and is ultimately less sustainable by nature of being less adaptive to change. The optimal inclusively designed system provides flexible one-size-fits-one configuration and considerations. This does not mean a system that automatically adjusts to how it thinks the user should experience it, but one that respects the self-determined choices of the user and adapts to meet the user's needs and preferences.

Personal Preferences Approach in One or More Platforms

Single Platform

A single platform may consist of one or more communication modalities within a single domain. For example, a virtual healthcare platform may consist of a web site, desktop application, mobile application and telephone system that the patients and practitioners may access with the same account information.

Using the Personal Preferences Approach, a patient interacts with the virtual healthcare platform, preferences and other data may be stored in their account/dossier for use by the system and healthcare practitioners. The system would adapt each modality to match the user's preferences.

A user interacts with a single virtual healthcare platform. Access is available across modalities such as over the web, mobile app, and telephone.

Multiple Platforms

The Personal Preferences Approach can also be used in typical healthcare settings where there are multiple platforms. Using a central repository for storing and retrieving preferences, like a Personal Data Server, can be used to facilitate sharing of preferences across different systems. This includes the patient's own personal devices, providing a way for them to interact and share their own needs, preferences, and contexts with their other systems they are connected too. In addition to sharing the preferences between systems, it could also provide additional security and privacy by allowing the user to decide which preferences are shared with which services.

Ultimately, the centralized repository for preferences would connect disparate systems together to share user preferences.

Example scenarios:

  • Using different systems or interfaces across different healthcare practitioners, e.g. family doctor, specialists, labs, paramedical services
  • Moving to a different healthcare practitioner or clinic
  • When the healthcare practitioner migrates to another virtual healthcare platform
  • Sharing preferences established in another system. For example an e-book reader application may have preferences that are useful to be shared with another application or system.

Contextualizing Information Through Aggregation and Analysis

Pulling in isolated information may be helpful at times (e.g. heart rate), but it may also benefit from being analyzed in relation to other information to provide context. For example, a heart rate monitor paired with location data and a personal calendar may provide more insight into interpreting the measured heart rate data.

One way to accomplish contextualization is to aggregate data from a variety of sources to provide rich information. These sources can be wearable devices, online services, social media networks, or other sources where the individual has recorded some personal information. With the Personal Preferences Approach, the user should have the ability to connect to a variety of personal information sources, and decide what information is shared to other services. Once information is shared, that data can be used to create reporting and analysis with contextual information. Continuing with the heart rate data example, a user may wish to share their heart rate data and distance travelled information from their GPS data. This may still give enough details to infer that they were moving or being stationary, without exposing their exact GPS location.

Data aggregation by itself is not enough to be useful, there should be some analysis on that data to help convey meaning. The analysis can be  automated through software similar to how fitness applications / services utilize user's data to detect types of activity and provide optimizations for workouts and routines. Data analysis can also be a manual process where someone may examine their data in relation to information from other services, like a weather service, to see how the environment may have impacted their wellbeing. The results of the analysis could be used in a person's healthcare such as making personal changes, sharing the insights with their circle of care, and inferring / generating preferences that can be used to personalize healthcare interactions.

An interaction diagram depicting discovery and use of preferences. Information about the individual can be introspected upon and synthesized into preferences. These can inform the Circle of Care and beyond.

The preferences discovery interaction diagram above illustrates how information may flow between different hypothetical platforms, and is not representative of all possible interactions. In this illustration, an individual can manually compare their personal journal entries alongside their medication routine. They may notice that journal entries related to being more irritable and having difficulty concentrating on conversations occurs within a couple hours of taking their medication at lunch. By comparing journal and medication information (aggregation of data), and noticing a pattern (analysis), they can use this information to block out meetings in their calendar in the afternoon and reschedule medical appointments around this time. They can also make a note to bring to their doctor, and discuss possible alternative medication or therapies. Additionally they can setup their playlist with soothing music to play during this time, and try different herbal teas recommended by friends.

Example Integrations of the Personal Preferences Approach with Virtual Healthcare

Preferences with UI Options

As mentioned in the example in the Overview, the Personal Preference Approach can be accomplished using UI Options and a Personal Data Server. In the diagram below, the "Virtual Healthcare Platform" provides a web application for patients and practitioners, and can provide some personalization of the user interface by using preferences the patient has permitted to be shared through the Preferences Server. A patient could use the same information to inform the practitioner of their preference. For example, the individual may prefer large text size for both web text and on printed material.

Personalization Preferences Approach using UI Options

Walkthrough of the above diagram:
  1. The patient accesses the Virtual Healthcare Platform via a web application.
  2. The web site provides an instance of UI Options which allows the patient to adjust the site to their own needs and preferences.
  3. They are provide with an option to save those preferences into the Preferences Server for future use on this site and potentially others. 

Preferences shared across systems

A more complex example where the Virtual Healthcare Platform is made of multiple systems orchestrated together: web, mobile and desktop applications. Each of these applications may have their own way of handling preference setting and enacting those preferences, but would share the same preferences with the other applications within the platform. For example, a preference for larger text size may be a preference stated by a patient, and both the web and mobile applications would access the same preference, but respond (enact that preference) differently due to different display size and pixel density.

A deeper example would be a patient may specify a preferred language to use on the web application. If a practitioner is permitted to access this preferences information, the practitioner could use the same information to also provide customized care for the same individual. For example, the doctor's office could provide print material in both English / French and the preferred language. Going further, knowing this language preference could help matching the patient with referrals who might be able to communicate in the patient's preferred language.

Integration of Personal Preferences Approach into a multi-system platform.

Walkthrough of the above diagram:
  1. The patient accesses the Virtual Healthcare Platform via the web application.
  2. The web site provides allows the patient to adjust the site to their own needs and preferences using a combination of account settings and UI Options.
  3. These preferences are stored in the user account for the Virtual Healthcare Platform. Additionally, these preferences may be propagated to a Preferences Server to potentially be shared with other platforms, and/or stored there (instead of in the Virtual Healthcare Platform's own database).
  4. The patient uses the Virtual Healthcare Platform via the mobile application. The same preferences configured through the web application are now present in the mobile application.
  5. The practitioner uses the Virtual Healthcare Platform via the web application and customizes their care based on the preferences specified by the patient.

Preference Discovery through Journalling

Preferences discovery can happen outside of exploring an interface, they can also be generated through a self-reflective processes. Using a digital journal, the patient may reflect on past events, envision future goals / plans, track habits and behaviours, contextualize data pulled from devices and services, and note conversations with others. Through this process of aggregating and self-reflecting, new understandings may be generated to be shared with others and/or synthesized into preferences that can be applied to the virtual healthcare platform.

Preference generation through self-reflection (journalling) shared with virtual healthcare platform.

Walkthrough of the above diagram:
  1. In a journal, the patient logs their medication schedule noting which prescriptions are taken, in what doses and at what times. The patient also starts a mood tracker and long form journal for their day. After a few days, they notice a co-relation between an irritable mood and their medication. It seems that for the first few hours after taking the medication, their mood deteriorates.
  2. They send some of the data collected by their smart watch to a 3rd party (could be a service provided by a company, or simply a family member who is a "whiz") to see if there are any correlations between physiological state (e.g. heart rate, activity, etc.) and time they are more irritable. The information gathered is logged back into the journal. They make a note in the journal to bring this up with the doctor at their next appointment.
  3. With the information gathered, a preference to block meetings and appointments, during the period after taking the medication, is generated and saved the Preferences Server.
  4. When the patient connects to the virtual healthcare platform, they see that appointment bookings for their blocked times are flagged, and other times recommended instead. A suggestion is made to talk to the doctor about their medication.
    1. The virtual healthcare platform, connected to the preferences server, was able to automatically pull in the patient's scheduling preferences.
    2. The virtual healthcare platform is connected to the digital journal and is sent notes directed to the doctor.
  5. The patient imports the medication tracking information, from their digital journal, into the virtual healthcare platform and links that to the appointment they are booking, so the doctor is aware of their concerns and can see how it is affecting them.