Data Checkers: A Grid-Based UI for Managing Patient-Generated Data Sharing to Support Collaborative Self-Care

Chronic health conditions are becoming increasingly prevalent. As part of chronic care, sharing patient-generated health data (PGHD) is likely to play a prominent role. Sharing PGHD is increasingly recognized as potentially useful for not only monitoring health conditions but for informing and supporting collaboration with caregivers and healthcare providers. In this paper, we describe a new design for the fine-grained control over sharing one's PGHD to support collaborative self-care, one that centers on giving people with health conditions control over their own data. The system, Data Checkers (DC), uses a grid-based interface and a preview feature to provide users with the ability to control data access and dissemination. DC is of particular use in the case of severe chronic conditions, such as spinal cord injuries and disorders (SCI/D), that require not just intermittent involvement of healthcare providers but daily support and assistance from caregivers. In this paper, after providing relevant background information, we articulate our steps for developing this innovative system for sharing PGHD including (a) use of a co-design process; (b) identification of design requirements; and (c) creation of the DC System. We then present a qualitative evaluation of DC to show how DC satisfied these design requirements in a way that provided advantages for care. Our work extends existing research in the areas of Human-Computer Interaction (HCI), Computer-Supported Cooperative Work (CSCW), Ubiquitous Computing (Ubicomp), and Health Informatics about sharing data and PGHD.


INTRODUCTION
Chronic health conditions are prevalent in the U.S. 1 and across the globe 2 . Supporting people with chronic conditions in conducting self-care is critical to their quality of life (Anderson, 1995). Consumer devices such as mobile phones, fitness trackers, and Internet of Things (IoT) devices, as well as in-home medical sensor networks allow people to generate a vast amount of data that characterize their health and daily activities. These patientgenerated health data (PGHD) could be useful for monitoring one's health, behaviors, and daily activities. Sharing such data is increasingly recognized as potentially useful not only for monitoring one's own health but also for informing and supporting collaboration with caregivers and healthcare providers.
Sharing PGHD, however, should be under the control of people with health conditions 3 or their caregivers. We want to investigate ways to allow people to control their own data sharing, instead of putting it under the purview of large corporations or healthcare systems. If data sharing is to be under the purview of people with health conditions, we need to keep the task from being overwhelming. With severe chronic conditions, a person with a health condition is likely to need to change sharing settings as their health deteriorates, a time in which they may not be able to focus or find the energy to do so. Moreover, this will become an increasingly difficult problem for users as healthcare sensors become cheaper and proliferate. We need to find ways to make it simpler and easier for people with health conditions to control their data sharing.
In this paper, we present a prototype solution to an important aspect of this problem, creating settings that will control sharing PGHD. While our overall agenda is large, we have begun to investigate this issue in the context of working with people with high-level spinal cord injuries and disorders (SCI/D) 4 and other neurological disorders, such as cerebral palsy 5 . As people with SCI/D experience increasing levels of impairments, they begin to require assistance from others to perform activities of daily living (ADLs), including activities such as getting dressed, having a meal, taking a bath, or using the bathroom (Meade, 2009;Ackerman et al., 2018).
Recently, the research community has started to examine how to support individuals with severe chronic conditions, such as SCI/D, within the context of a care team at home (Consolvo et al., 2004;Tixier et al., 2009;Tixier and Lewkowicz, 2016), since care for people with chronic conditions with more severe levels of impairment is usually a team-based effort (Nunes and Fitzpatrick, 2015). While some researchers use "care networks" (e.g., Consolvo et al., 2004) to denote a broader collectivity of involved others, Gronvall and Verdezoto (2013) use "intimate care network" to include only family and the closest friends who participate in health management. In this paper, we use "care team" to denote an at-home care team that includes only the person with a health condition, caregivers (primary, secondary, hired/paid, and volunteers), and clinicians-those most immediately bound up in day-to-day care or in the necessary clinical care (Meade, 2009;Büyüktür et al., 2017Büyüktür et al., , 2018, and PCT to refer to a person with a health condition requiring a care team.
Using PGHD generated from sensing devices can facilitate collaboration within a care team outside of the hospital environment, but it also raises a number of issues. The combination of technical complexity, changing health conditions, and social dynamics make it challenging to share data, as PCTs need to consider with whom to share data, what data to share, the contexts in which to share, how much detail to share, and the degree of control desired as a care-receiver.
On the social side, the co-existence of different relationships (e.g., parent-child and caregiver-receiver) (Toscos et al., 2012;Büyüktür et al., 2018) and health conditions that are constantly evolving may require nuanced considerations by PCTs , including the sharing of data. Sharing data could support collaborative monitoring, but could also create challenging tensions, as people need to be allowed to make developmentally appropriate decisions about their lives and health management even as they rely on others' assistance with ADLs (Hong et al., 2016). For instance, while a primary caregiver (e.g., a mother) may take on the responsibility to oversee care, her parent-child relationship with the PCT (the child) might affect the types of information the person is willing to share with her. The person might feel the need to maintain independence by controlling the data being shared with the parent, since having control over data is potentially a way for PCTs to obtain a sense of control over their lives (Unruh and Pratt, 2007;Nafus and Sherman, 2014;Büyüktür et al., 2018). At the same time, deterioration in the person's health might require sharing more data for the sake of safety.
The Human-Computer Interaction (HCI) and Ubiquitous Computing (Ubicomp) communities have recognized the complexity and challenges of allowing users to manage the sharing of sensor data to support chronic care. While usable privacy and security research in these fields has proposed a number of designs for authoring privacy settings and sharing settings (or policies), these designs are not suitable for care: they do not support fine-grained control over data details or do not take into consideration the chronic care context (Reeder et al., 2008;Lipford et al., 2010). We will return to the context of care below, detailing requirements, but as an example, existing systems do not include support for dynamically changing care teams, the fine-grained control necessary to support personalized sub-groups within care teams, or the support necessary for the long term. As such, this paper reports our investigation into a user interface design that addressed these concerns to better support data sharing within care teams.
In this work, we have sought to find a middle ground technical solution that is comprehensive enough to allow finegrained control of data sharing without overwhelming users with complex representations. We did so by co-designing with a person with a health condition to create an application with a grid-based visual interface. After developing our prototype Data Checkers (DC), we performed a qualitative evaluation to understand its potential.

Collaborative Self-Care for Chronic Conditions
Chronic medical conditions vary widely. Some may cause only small concern on the part of a person with a health condition (e.g, mild allergies); some may require only self-management of the condition, at least in some forms (e.g., mild depression). Other medical conditions, and some disabilities, may require a team of clinicians (e.g., congestive heart failure or oncology), and yet others may require an at-home care team to help with self-care and self-management along with a team of clinicians. We use as our example in this paper Spinal Cord Injuries/Disorders (SCI/D) and related conditions, which require an at-home care team.
Self-care has been identified as critical for managing all kinds of chronic conditions (Anderson, 1995). Self-care includes the everyday activities that people do to take care of themselves, manage their health, and allow for involvement and participation in life. For people with a severe chronic condition, such as people with SCI/D 6 , self-care becomes incrementally complex as it expands to consciously integrate the additional activities needed to maintain health. These activities could include maintaining specific types of diet, taking medication, cleaning one's environment and the medical equipment being used, bathing, or even monitoring pain . In the HCI literature, self-care and self-management as terms are usually used interchangeably. Here, we will use self-care to include self-management tasks performed by people with chronic conditions and disabilities (Nunes and Fitzpatrick, 2015).
One of the early, yet on going, streams of research has been to design technology to help medical professionals to monitor people' health, facilitating medication adherence (Botella et al., 2013) or, more broadly, assisting individuals in following and executing the steps recommended by trusted professionals (Lee and Dey, 2015). Another major direction examines how to empower people with health conditions by designing technological support for them to monitor their self-care practices, with the ultimate goal of achieving better health. Research has found it beneficial to do so, as it could trigger reflection, while also increasing a sense of control when managing a health condition (Mamykina et al., 2008).
Specific to different individuals, care teams might have different compositions and communication structures (Consolvo et al., 2004). These teams of family members, hired caregivers, and medical professionals collaborate in a loosely-coupled manner (Birnholtz and Jones-Rounds, 2010) to address health changes and develop care routines (Büyüktür et al., 2017;Ackerman et al., 2018). It is through collaboration among care team members that an individual can slowly develop her own independence (Birnholtz and Jones-Rounds, 2010;Caldeira et al., 2017;Büyüktür et al., 2018). Our work explores designs that can support individuals with chronic conditions to work with care teams while maintaining control over their care through data.

Patient-Generated Health Data
Information needs vary widely among chronic medical conditions. Significant research has examined the information needs and information sharing among people with chronic medical conditions and disabilities. For example, people want to share their status with their relatives, friends, and larger social network. People readily seek both information (Civan et al., 2009;Klasnja et al., 2011b; and emotional support (e.g., Feng et al., 2004) from these sources, including non-healthcare professionals. For instance, Skeels et al. (2010) reported that people with breast cancer seek and receive help from family members, other people with health conditions, community members, and professional connections. Valdez and Brennan (2015) and Valdez et al. (2017) highlighted getting support and information within the person's social network. In short, people with chronic medical conditions as well as people with disabilities engage in considerable information work (Hogan and Palmer, 2005;Kaziunas et al., 2013;Strauss et al., 2017), a kind of work done by patients and people with health conditions .
Part of that information work, increasingly, is data work (Kaziunas et al., 2018), a term that extends the concept of information work to involve raw data, including data from sensors, medical devices, and consumer electronics. People with health conditions and their caregivers must understand the uses of data, understand how to understand data, and know when to share data (and with whom) (Kaziunas et al., 2017).
In this paper, we focus on an important source of data for healthcare PGHD. The term PGHD is defined to include health-relevant data captured by the person with a health condition or other care team members outside of a medical environment (Figueiredo and Chen, 2020). PGHD include data that are captured by devices (e.g., sensors or medical equipment), those captured manually by people (e.g., journal entries), or a combination of both [e.g., semi-automated tracking (Choe et al., 2017)]. With the proliferation of consumer sensing devices, a massive amount of data can be gathered that describe the physiological, behavioral, emotional, social, and other factors that could be relevant to health. These data hold great potential for supporting the collaboration of care teams to improve selfcare at home, as they can be used to support individual care team members as well as between-member interactions. At the individual level, research has shown that tracking and use of PGHD allow people to understand their conditions (Mamykina et al., 2008), maintain a sense of control (Mamykina et al., 2008;Gronvall and Verdezoto, 2013;Ayobi et al., 2017), and make plans for self-management (Mamykina et al., 2008;Felipe et al., 2015). At the social level, PGHD can empower people with health conditions to have a voice in conversations with clinicians (Bagalkot and Sokoler, 2011;Murnane et al., 2018), as well as allow clinicians to gain a more holistic view of their self-care practices during clinic visits (Chung et al., 2019).
Using and sharing PGHD show great promise, but there are issues that need to be considered in designs that aim to support chronic care. PGHD, as the definition suggests, could contain a variety of data that reveal details about one's life. Collecting detailed data could be valuable in diagnostic tracking, as people with health conditions could then investigate the association of potential triggers with symptoms (Rooksby et al., 2014;Karkar et al., 2017). Sharing these data within a care team could certainly be helpful so people (PCTs) can work with caregivers and clinicians to collaboratively problem-solve (Raj et al., 2017). However, people with health conditions might not know how to understand and interpret each data type (Choe et al., 2014). Furthermore, revelations from the data could create undesirable impressions of them and affect their relationships with their care team members (Murnane et al., 2018). Privacy issues could be a major concern if these data are not handled properly Murnane et al., 2018;Chung et al., 2019). In addition to impression management and privacy concerns, prior research also suggests that maintaining fine-grained control over data is important for PCTs to negotiate the desired level of independence, namely the ability to fine-tune the details for sharing and how data are shared. This is particularly important, since they often want to acquire decisional independence and a sense of control over their lives . Without such support, PCTs might be in a vulnerable position and lose control of their data to others or large institutions, such as healthcare systems. In this paper, we propose a design to facilitate the sharing of PGHD while allowing PCTs to maintain their sense of control and independence.

Data Sharing Control and Support
Researchers investigating controlling data sharing have focused on two different research streams to mediate between users and the underlying access control mechanisms. The two research streams align with the major two factors that people consider in controlling data sharing (Bahirat et al., 2018): person (recipient) and data.
The first stream of effort focuses on the person dimension, with specific support for using meaningful groupings to help users categorize data-receivers. One prominent application area is to select who should receive data on social network platforms (e.g., Facebook) where users need to decide who or which social circles should receive a status update. For instance, PViz (Mazzia et al., 2012) provided views with different granularity (e.g., group, sub-group, sub-group of sub-group) for users to understand how their profile information would be shared with their friends based on group memberships. Privacy Wedges (Raber et al., 2016) proposed a user interface to allow users to interactively select audiences with certain attributes (e.g., tie strength or friend group) so as to control social media sharing.
The other stream of effort focuses on the data dimension. Since data need to be presented for human consumption, it is important that a user can exert control over how the data are presented. Existing work has explored the use of user interface (UI) designs and interactive data manipulations to prepare data for sharing. For example, Epstein et al. (2013) and Wang et al. (2015) proposed interactive techniques and applications for users to manipulate visualizations to prepare personal data for sharing. Vescovi et al. (2014) and Schaub et al. (2014) proposed allowing users to vary the level of details they wished to reveal using anonymity and summarization semi-automatically.
There have also been designs that accommodate the need to control both factors. For instance, Reno (Iachello et al., 2005) supported computer-assisted semi-automatic location data sharing through location-based and recipient-based rules. Reeder et al. (2008) used a matrix representation to enable access control through describing relationships between files and people's data access. Könings (2015) employed a similar matrix representation with reduced complexity on a mobile platform through rulebased mechanisms. Bahirat et al. (2018) designed a data-driven layered mobile UI for users to control IoT data sharing, from coarse-grained (e.g., whose device and what data) to fine-grained (e.g., purpose and frequency of sharing) control.
The designs introduced above have different focuses on people and data in terms of the audience size and the types of control. The audience size ranges from a family, an office unit, contacts, an organization, social media, to the Internet. Most designs provide only coarse-grained control, and only a few support finegrained control (Epstein et al., 2013;Könings, 2015;Bahirat et al., 2018). The scenarios considered include personal data control for sharing with digital devices/services, social media sharing within social circles, and office sharing with colleagues. Less is known about how to design UIs for people to exert fine-grained control over sharing, especially within healthcare. There is a need for a design that allows PCTs and their caregivers to control PGHD sharing while taking into consideration the needs of a care team and of the conduct of their chronic care. Our design offers one such prototype.
We next turn to our design process, a representative scenario of care, and a set of design requirements.

Co-designing the Prototype Application
In order to create a person-centered solution for managing PGHD sharing, we adopted a co-design approach to work with a person (PCT) with similar care needs as SCI/D patients to explore the design space and develop an application concept.
We first describe the process of collaborating with this person on designing DC.
Co-design is an effective way for participants to organize and illustrate their experiences (Hieftje et al., 2014;McCarthy et al., 2017;Hong et al., 2018) and bring them into the design process. Co-design also allows participants to join in the research in a way that can be dynamically adjusted to a participant's level of energy and comfort in taking the lead, both of which are particularly important for participants who are dealing with illness (Lindberg, 2013).
Our research team formed a partnership, based on prior research interactions, with a person with congenital muscular dystrophy, a condition that in this case has resulted in severe physical disability and requires complex care management. Muscular dystrophy is a progressive and degenerative condition, and he has diminished use of his limbs. In addition to muscle weakness, his respiratory system is also affected and requires additional care and monitoring. As a result, he uses a power wheelchair and requires assistance from caregivers to navigate different aspects of everyday life such as commuting, monitoring heart rate and fluid intake, assistance during the night, and using a ventilator when required. He has a team of people who assist him with self-care, including parents as his primary caregivers, a sibling as a secondary caregiver, 10-15 hired caregivers, and clinicians.
The partnership was beneficial as our co-design partner has the perspective of a person with a severe chronic condition working with a care team and is passionate about the potential of technology to improve the life of PCTs like himself. As a codesign partner, he was instrumental in shaping the design of DC and provided valuable insights on the life of a PCT.
During an eight-month engagement with weekly working sessions, the first author and the co-design partner worked to collaboratively explore the design space of PGHD sharing applications, based on prior research and personal experience.
Our co-design process followed the Cooperative Inquiry method proposed by Druin (1999) and subsequently extended by Garzotto (2008). Druin argued that researchers should systematically involve users as design partners to participate in the entire research, design, and development process.
The first step of Druin's process is contextual inquiry, a form of user-centered design (UCD) (Cooper et al., 2012). We conducted observations and reflections on the chronic care process as well as stakeholders' involvement (e.g., caregivers and medical professionals). We iteratively discussed our findings and created representations such as personas and scenarios to document stakeholders' experiences of collaborating on care. These personas and scenarios also made explicit potential concerns and issues in sharing PGHD. This step mapped out an understanding of the lived experience of a person with a severe chronic condition that could be used to ground the design and to examine what features were needed, in our case, for a system to facilitate data sharing with care team members in a way that respects a person's need for control.
Druin's second step is technology immersion, to allow design partners to get suitable exposure to technology, in our case, sensor data and sensing devices. We surveyed commercially available sensing devices and techniques so that our co-design partner understood what data could potentially be captured to characterize different aspects of people's health.
Druin's third step, participatory design, consists of collaboratively exploring potential designs through an iterative process. Based on the personas, scenarios, and understandings of sensor data (the previous two steps), the first author and co-design partner investigated potential design requirements. They also created design artifacts such as sketches, lo-fidelity paper prototypes (Snyder, 2003), and hi-fidelity interactive mock-ups to iteratively design a software system that could be used to manage PGHD sharing with care team members while being mindful of PCTs' concerns about independence and privacy.
Exploring different designs including the basic user interface. The co-design partner is passionate about games in general, and often brought up his observations about games as examples of visual interfaces that would allow him to exert control. Examples of games we examined ranged from poker cards, board games, to 3D games. The design exploration, therefore, moved away from a typical smartphone app with a hierarchy of lists and toggles to a more visually-oriented user interface featuring elements that could be viewed at a glance. The design exploration also started examining designs where users could easily change states by rearranging different visual elements (as in games). The first author, and the co-design partner brainstormed ideas, and the first author drew sketches that served as a medium for both authors to collaboratively iterate on designs.
Overall, the co-design process between the first author and the co-design partner led to three outcomes. The first was scenarios of use. The second was a set of design requirements, based on standard usability concerns and in care requirements. The third outcome was an application concept, DC. In the end, the first author implemented the agreed-upon design as a web application, DC, that featured a grid-based interface, as shown in Figure 1.
At the end of the co-design process, we invited our co-design partner to be a co-author (the second author) to acknowledge his contributions to the research.

Care Scenario
Here, we present one of the scenarios envisioned for our design. The scenario uses a person with SCI/D to ground the design requirements and the evaluation of our design.
The care scenario: Peter is a 19-year-old college student with spinal cord injuries due to a car accident that happened 3 years ago. With quadriplegia, Peter's upper limbs, trunk, and lower limbs are paralyzed, with only limited control over some parts of his upper body. As a result, Peter has a limited range of motion and physical activity without assistive devices. Peter, like others with quadriplegia (tetraplegia), also lost the ability to sense his body. For instance, he does not feel thirsty even if needing water, and so he cannot maintain proper hydration. Peter, therefore, needs assistance to perform various self-care activities to keep himself healthy. These activities include both doing and monitoring fluid intake, stretching, executing a bowel/bladder program, checking his heart rate, checking his body temperature, and moving his body during sleep to prevent pressure sores.
Such assistance comes from a dynamic team of family members, hired caregivers, and clinicians. Peter's mother is his primary caregiver who oversees his care. Peter and his mother hire 10-15 caregivers who are college students to take shifts and assist him day and night. Sometimes, a caregiver cannot make their shift or has to leave the position permanently for school or work. Peter's father and brother then have to jump in to assist until more caregivers can be found or hired. Similarly, adjustments need to be made when Peter's health changes. The primary and hired caregivers will then monitor more factors, including heart rate, fluid intake, sleep quality, and physical activity, in order to investigate potential causes and to develop care routines to manage any health contingencies. Clinicians from different clinics and health systems, including his primary care provider (family physician) and his Physical Medicine and Rehabilitation (PM&R) doctor, are involved when their medical expertise is needed, especially when Peter's health worsens. All these care team members would benefit from seeing data about Peter's health and care.

Design Requirements
Based on the prior literature, observations and interviews from our and others' prior work (Büyüktür et al., 2017Ackerman et al., 2018) and our co-design process, we formulated five requirements necessary to adequately support the control of PGHD data sharing for people (PCTs, such as Peter) to share with their care teams. While these requirements were developed within the context of SCI/D care, we believe they are true for other conditions that require similar care. This list of requirements is not exhaustive. Other requirements may be uncovered in the future, but we believe if these are not satisfied at a minimum, an application will not adequately address the data sharing needs of people in severe chronic care settings such as SCI/D.
These five requirements build on each of the previous ones. The requirements are: Require1: Provide a user-friendly interface for specifying sharing settings. As a basic requirement, a system should provide a user-friendly interface that people without technical expertise can use (Demiris et al., 2008). Users should be able to navigate what Norman (2013) called the "gulf of execution, " the alignment of system capabilities and what users perceive to be achievable through the system. Users (i.e., PCTs) should be able to quickly learn how to use the system to efficiently accomplish what they intend to do (Rubin and Chisnell, 2008). With the goal of controlling their data sharing, users should be able to create and modify sharing settings easily, without having difficulty in using the interface to achieve their goal (Kuniavsky, 2003;Cooper et al., 2012;Bevan et al., 2015).
Require2: Support sending data to multiple members of a sufficiently-sized care team. Self-care is often a collaborative effort (Nunes and Fitzpatrick, 2015;Ackerman et al., 2018;Büyüktür et al., 2018). Care team members may need to have access to the same set of data to support day-to-day collaboration, including monitoring. Research has shown that such collaborative monitoring is beneficial or even critical (Birnholtz and Jones-Rounds, 2010;Caldeira et al., 2017). A system to support data-sharing within a care team must be able to support sharing specific types of data with multiple care team members. Our co-design process revealed that a size ranging from 10 to 20 is necessary for SCI/D, which includes family caregivers (1-5), hired caregivers (5-10), and clinicians who closely work with the person with a health condition (around 5). Users (PCTs or their proxies) should be able to express how they want to share different data with each care team member, as opposed to a one-size-fits-all setting for everyone.
Require3: Support understanding of sharing settings. A system should present sharing settings for the care team in a way that is easy to comprehend. Users should be able to answer basic questions , such as "Who has access to the heart rate data?, " simply by looking at what is shown. PCTs and caregivers should be able to navigate Norman's (2013) "gulf of evaluation, " letting users assess the state of the sharing. In the context of care, a system should also support users in answering questions such as "How do my data look like for my father?" so PCTs or their helpers can understand how sharing settings have affected the resultant data flows.
Require4: Support PCTs (or their primary caregivers) having fine-grained control over their data. In collaborative self-care, one should be able to control how much PGHD could reveal about one's life by having fine-grained control over the sharing of PGHD within the care team. In addition to users being able to choose recipients (Require2) and understand what the sharing settings are (Require3), they should be able to closely control how much detail is shared with each recipient (Prasad et al., 2012;Büyüktür et al., 2018;Murnane et al., 2018). This could include, but is not limited to, hiding or manipulating certain data (Epstein et al., 2013) and presenting summary instead of raw data . For example, through the co-design process, we identified four kinds of tools, which we termed "controls, " that can help PCTs control the level of detail (e.g., daily summary), length of history (e.g., up to 7 days or 3 h), the shape of data (e.g., remove outliers), and visibility of data (e.g., temporarily suspend sharing).
Require5: Support long-term sharing management by addressing health and care team changes. Chronic care is a long-term process (perhaps a lifetime), where the care team continuously creates and re-creates care routines to manage health contingencies (Büyüktür et al., 2017;Ackerman et al., 2018). This process requires monitoring different health indicators and care activities (Rooksby et al., 2014;Karkar et al., 2017). Members of a care team come and go for various reasons, such as having multiple responsibilities and priorities (e.g., other jobs), relocating for job or school, and accommodating changes in a person's health (e.g., new symptoms or co-morbities) (Consolvo et al., 2004;Büyüktür et al., 2018). A system designed to support care should make it easy to manage data sharing to accommodate different occasions (i.e., health or team changes). This includes capabilities to tailor sharing settings for a particular set of data or people through understanding and re-purposing existing sharing settings.
Data Checkers was designed to fit these requirements. We stress that while this list of requirements is by no means exhaustive, it includes a range of considerations that are critical for PCTs (i.e., people with SCI/D). We believe these requirements will also be true for many people with severe care needs who are involved with making care management decisions.

Data Checkers System Overview
Data Checkers was designed, based on the design requirements outlined above, to manage PGHD sharing. As shown in Figure 2, DC contains two features, the grid-based interface and a preview, which are particularly important to allow users to implement fine-grained control and support ongoing management of self-care.
The grid-based interface, similar to what is usually seen in checkers and chess, allowing users to strategically express data sharing preferences for different stakeholders. Users can (a) place different blocks on the grid to specify how they prefer to share data with different care team members. Users can (b) dynamically adjust the location of blocks to change sharing settings in reaction to changing health conditions and changing relationships among care team members. After specifying sharing preferences, users can (c) preview data according to stakeholders' perspectives so as to understand how data sharing is regulated by any given sharing setting.

Create Sharing Settings
In DC, one configures sharing settings by laying out visual blocks on a board. As shown in Figure 3, there are three types of blocks: person (yellow), data (green), and control (blue) blocks. The lists of data, person, and control blocks can be extended if necessary.
• Person: DC currently supports sharing within a moderate sized care team, including family caregivers, hired caregivers, and clinicians (e.g., occupational therapist, doctor, nurse).
• Control: There are four categories of controls (12 in total), tools that tailor the details of data being shared (e.g., share data only as an aggregated daily summary). These were the outcome of the co-design process described in section 2.1.
There are two simple rules in DC that define how different blocks work together.
• Rule 1: a type of data (as a block) can be received by any person (as a block) on the right in the same horizontal row.
• Rule 2: any control block being placed along that segment between a data block and a person block regulates how the person receives the data.
With these two simple rules, DC supports three basic operations that make it easy to create, modify, and extend sharing settings through visual composition. Figure 4 shows one example for each of these actions. First, to create a sharing setting to give a person access to certain data, a user can simply put a person block (e.g., Dr. White) on the right of a data FIGURE 2 | DC: On the left is (a) a grid-based interface for specifying sharing settings, and on the right (c) is a panel that shows the preview of data being shared in a recipient's view (Profile photos by Julian Wan and Leon Ell' on Unsplash).
FIGURE 3 | Essential elements in DC: On the left are blocks that represent different data sources (e.g., Heart Rate and Sleep Quality). On the right are yellow blocks that represent different people (e.g., Johnny and Doris Novak) with whom to share data. In the middle are blue blocks that represent different controls (e.g., Daily Summary) that can tailor the details being shared.
block (e.g., Heart Rate). Second, to modify a sharing setting such as adding a restriction (i.e., limiting access to data to the past week), a user can simply put a control block (e.g., Past Week) between the data and person blocks. Lastly, to allow an additional person (e.g., the nurse Johnny) to have the same sharing setting for an existing person (e.g., Dr. White), a user can simply add the desired person (Johnny in this case) to the right of people already included in the sharing setting. Following these two rules, users can strategically use the three basic operations to add and remove blocks on the board to allow or disallow people to receive different data sources. DC also allows users to enable and disable sharing settings within a selected row.
Note that laying out a set of blocks (e.g., Heart Rate, past week, Dr. White) in the first row has the same effect as laying out the same blocks in any other row. By doing this, DC offers users the flexibility to arrange sharing settings in a personalized manner.
To support managing data sharing with different care team members, DC also supports creating sharing settings using roles such as "primary care professional, " "nurse, " or even "medical professional, " (similar to the use of roles in role-based access control, Ferraiolo and Kuhn, 1992;Sandhu et al., 1996). With both the individual and role blocks, it is possible that users could FIGURE 4 | DC supports three basic operations that make it easy to specify and reuse sharing settings: create (top), modify (middle), and extend (bottom).
create sharing settings that are conflicting. Currently, DC honors the most specific (e.g., for the individual) sharing decision when a conflict exists. This resolution mechanism also enables users to create exceptions for a specific individual (e.g., Patrick).
As the number of sharing settings increases, it is expected that users will need support to find sharing settings involving a specific person or data type. DC allows users to re-layout sharing settings through "sort by data" and "sort by person" features, so that it is easier to locate sharing settings about a specific data type or care team member.
Note that in the remaining part of this paper, we will use "sharing setting" to refer to a data-controls-recipients tuple that specifies "I want to share what data (data) to whom (recipients) after some data processing (controls)."

Previewing Data From the Stakeholders' Perspectives
The other major feature of DC is the ability to see a preview of data flows from the perspective of the data's recipients. As prior work  suggests, allowing PCTs to see how data will be presented is important; users want to understand the effect of sharing settings. In DC, users can see the effects of sharing settings when viewing different care team members (Figure 6). This feature is designed to allow users to 1) experiment with different combinations of person, control, and data blocks while learning about the effects, and 2) verify whether data sharing settings have been configured as intended.
For instance, if a user indicates that she wants to share both sleep quality and pain with her physician, Deborah White, she can use the data preview capability to examine whether this physician will receive data as planned. As shown in Figure 5, this user can select Deborah White on the board, and the panel on the right (shown in Figure 6) will display information about Deborah White, including profile photo, name, and roles, as well as the different data, presented in visualizations, for which Deborah has access, given the current set of sharing settings.

RESULTS
To examine whether DC allows users to better control data sharing within care teams, we invited people with chronic conditions or disabilities as well as caregivers to help evaluate DC. The goal of our evaluation study was to examine the design features of DC, including its grid-based interface and the capability to preview data, to determine whether they offered advantages over a conventional design in supporting data sharing for care.
To do this, we evaluated DC against a state-of-the-art design, which we will call Reference Design (RD). As our comparison, we chose a design that used a hierarchical design that is standard for organizing settings and options on all major desktop, web, and mobile platforms. This hierarchical design uses a list as the main layout for organizing different options. Such a conventional design allows users to progressively navigate through layers of options to execute a specific action through, for example, buttons or toggles -as seen in settings within iOS or Android applications.
We chose to adopt the state-of-the-art application described in Bahirat et al. (2018) for the following reasons. First, their use case was for fine-grained control over the the Internet of Things data collection, including the use of sensing devices to generate data characterizing an individual's life at home, which is similar to what is needed for PGHD. Second, the design uses a conventional design that features standard GUI widgets, such as lists and toggles, which provide familiarity to users and allowed us to examine the feasibility and advantages of using the grid-based interface offered by DC. Third, Bahirat et al.'s design can accommodate people, data, and controls, while giving different elements equal presence. To the best of our knowledge, there were not any individual-facing applications (i.e., for people with health conditions) designed to support finegrained control over PGHD sharing with care teams for the long-term. Existing consumer health apps lack the capability of fine-grained control (e.g., Apple Health 7 , Fit 8 by Google, and HealthMate 9 by Withings) and thus were not suitable for comparison. As a result, we chose the design used in Bahirat et al. as our Reference Design.
However, we found it necessary to modify Bahirat et al.'s design slightly. It was originally designed for mobile platforms with limited screen space, and we felt that comparing our web application on a browser with a mobile app on a handheld device would create confounds from different device screen sizes and potentially different interaction techniques such as swiping. For a fair comparison, we implemented a web version of RD that provided more screen space and allowed users to see layers of options simultaneously, as commonly seen in Windows or Macintosh desktop software. We structured sharing settings in the following order, person-data-control, as shown in Figure 7. This followed research findings where person and data had been found to be the dominant parameters people considered regarding privacy risks in sharing (Lederer et al., 2003;Bahirat et al., 2018). The order of different persons, data, and controls were randomized to reduce the effect of ordering on study results. The same order was used by both DC and RD. We followed the design by Bahirat et al. as faithfully as possible, including the use of toggle position and color scheme as indicators of further options. 7 https://www.apple.com/ios/health/ 8 https://www.google.com/intl/en_us/fit/ 9 https://www.withings.com/us/en/health-mate

Evaluation Participants
The target users of DC are people with severe chronic conditions, such as people with SCI/D, and their caregivers. In addition to supporting people with health conditions requiring care teams (PCTs) to gain independence through sharing control, we recognize that caregivers might need to assist with data sharing when people's health fluctuates and thereby might have limited capacity for self-managing their data. As a result, we recruited people with chronic conditions as well as people with caregiving experience who were 18 years and older. Participants were recruited through university mailing lists. Our study included fifteen participants, with 13 women and 2 men. Participants' backgrounds were varied (shown in Table 1 for more details). At least 8 participants had direct experience with conditions that were likely to require care teams at some point in care, including caregivers or nursing professionals who had provided care for individuals with autism, stroke, neurological impairments, and SCI/D.

Study Procedure
The study was conducted remotely through video-conferencing software (Zoom 10 ) with screen-sharing enabled. Each study session took 60-90 min and was recorded. Consent was obtained through email prior to each study session. During each study session, participants first filled out a biographical questionnaire and watched two videos that explained the design and features of DC and RD, respectively, to learn about how to use both applications. The videos were created to provide consistent training across participants. We then provided participants with a tutorial task so that participants could ask questions to clarify their understanding of how to use the two applications.
After the tutorial tasks, each participant was then asked to complete four tasks (shown in the following section) that involved creating and modifying sharing settings using both DC and RD. The instructions for each task was displayed above the interface.
After participants finished tasks and acquired experience using DC and RD, the first author conducted a semi-structured interview with each participant to probe how DC supports or hinders users' capabilities to control PGHD sharing with care teams.
Participants who successfully completed the study were compensated for their time with a $20 gift card. The Institutional Review Board at our university reviewed this study. All data  reported here have been anonymized; we have done some light editing of quotes for readability.

Evaluation Tasks and Semi-structured Interviews
We designed four tasks that involved viewing, changing, and finding special cases among data sharing settings. These are three of the fundamental policy-authoring operations proposed by Reeder et al. (2008). We left Reeder et al.'s operation of viewing group membership (e.g., a person is a member of a hospital system) to future work.
During these tasks, a participant assumed the role of an individual with a severe chronic condition, who received assistance from a care team (e.g., as a PCT like Peter in the scenario described in section 2.2), and is actively considering how to share a set of data (shown in Table 2) with members of her care team (shown in Table 3).
These tasks were designed to verify whether a design could satisfy the 5 design requirements from section 2.3. The tasks we asked participants to solve were as follows: • T1 -create a set of sharing settings to share data with care team members.
• T2 -modify a set of sharing settings to accommodate changes in a care team.
• T3 -reuse a set of sharing settings recommended by health professionals in reaction to changes in health, and tailor the settings to one's care team.
• T4 -make maintenance changes to sharing settings after sharing data with a care team for a period of time to accommodate the varying time commitments of care team members. Each participant was asked to complete T1-T3 using both DC and RD, where the order of designs was counter-balanced to reduce any learning effects. Using RD allowed participants to have a basis for comparison to ground the discussion about why DC might or might not be a promising design. Participants were asked to complete T4 two times, first without and second with  the preview feature, to facilitate the discussion on whether the preview feature is helpful for controlling PGHD sharing. These scenario-task combinations which exemplify the characteristics of data sharing in care and in care team collaboration, allowed us to examine whether DC's design sufficiently supports data sharing. Note that in the evaluation, we used "the grid" to refer to DC and "the list" to refer to Reference Design so that participants had easy-to-understand and consistent vocabulary when discussing and comparing the two designs. This will be reflected in some of the quotations below.
After a participant completed each task, a follow-up question examined how useful a given design was for completing the task: • Which of these designs (grid or list) is more useful for you to control data sharing for this task? Why?
If necessary, this was followed with the probe: • How did the features or characteristics of each design helps support the task? Hinder the task?
After all tasks were completed, a semi-structured interview was conducted to examine the overall experience of using both designs (DC and RD), as well as to investigate the potential of supporting data sharing over the long term to manage change. The questions were posed as comparing the two designs so as to tease out the dimensions participants might use for evaluation and comparison. The semi-structured interview schedule consisted of the following: • Which of these designs, grid or list, was more useful for you to control data sharing for care? Why?
• Which of these designs do you think would be more useful for controlling data sharing among multiple caregivers and clinicians? Why?
• Chronic care is a long-term process. Which of these user interfaces do you think would help people with health conditions or caregivers to control data sharing with care teams over a long period of time? Why?
Below, we present only qualitative data from the evaluation study. While the study was non-probability based, we believe the qualitative data are sufficient, however, to show the feasibility of DC's design for supporting care.

Data Analysis
We recorded both what the participants did and said through video and audio capture and answers to interview questions were transcribed. We used Situational Analysis (Clarke, 2005), an updated version of grounded theory, in our analysis. Situational Analysis recognizes the importance of Symbolic Interactionism (Strauss, 2008) in the interpretivist analysis of qualitative data; it also incorporates practice theory, among other additions. Situational Analysis can be seen, in Clarke's terms, as a theory/method package. This perspective was critical as background for our analysis. We see the problem and the application presented here as part of patients' and caregivers' data work (Kaziunas et al., 2017), which in turn is an increasingly important aspect of patient work  and more broadly of interaction work (Strauss, 2008;Strauss et al., 2017). In our evaluation, we examined how our participants weighed potential changes in care practices in light of the data work.
In Situational Analysis, iterative cycles of data collection and analysis inform one another. Initial interviews were transcribed and analyzed using open coding to identify significant themes, utilizing Atlas.ti 11 . The coded interviews were then discussed by the first and last authors in weekly data analysis sessions. New codes were generated collaboratively, as important concepts were identified, compared, and revised. These codes were later used as the basis for probes in future interviews. The process was repeated iteratively. Prior interviews were recoded to maintain consistency, and over time, new and recoded interviews led to important themes that emerged from the data. As part of the process, analytical memos were written and discussed as theoretical insights emerged from the ongoing data collection and analysis.

Findings
In general, our participants were able to perform the evaluation tasks. DC was praised for enabling users to easily grasp how data were currently shared within care teams through the grid-based interface. Moreover, our participants found that DC enabled them to make changes to existing settings intuitively through visual composition. The data preview feature was well-received for allowing users to confirm their understanding of sharing settings and to learn about the effect of applying controls. In comparison, RD, with a design that participants could instantly recognize and were familiar with, was considered not as useful for performing data sharing within care teams. The evaluation results showed that RD's hierarchical design, while technically allowing users to achieve the same goals, was useful only in simple cases. RD's design made it challenging for users to consider multiple care team members simultaneously in the process of creating and modifying sharing settings for care teams. We 11 https://atlasti.com/ were surprised, but delighted, by how much our participants generally found DC to be better for the requirements of complex care than RD.
In the rest of this section, we elaborate on how the design of DC satisfies each of the requirements from section 2.3 in turn. Note that an interactive system such as DC provides an integrated experience through the combination of different features. The same feature, in combination with others, could offer a utility that satisfies multiple requirements. We present how aspects of DC support each requirement by our participants. These results, we believe, show why DC is a promising design for sharing PGHD in a care context, while also identifying room for improvement.

(Require1) DC Is Usable and Useful for Specifying Sharing Settings
Our participants generally found DC to be usable with its gridbased interface and its features to support the expression and use of sharing settings. All participants (15 out of 15) reported that DC was easy to use.
However, DC's interface and capabilities were offered through a novel grid-based interface, and some participants needed time to learn it. All participants reported that DC was easy to use, but only five considered DC easy to use up-front. The other 10 stated they needed a period of learning how to use DC, and then creating or modifying sharing settings was easy. For example, P03 suggested that once she understood how to use DC, by "getting the hang of it, " it was effective for controlling sharing: I think, yeah, once you get the hang of it, it's pretty intuitive to use. I don't think I've seen [the grid of DC] before. It's not something that people normally see. But I don't think it's something that's hard to learn. I think it's definitely a better alternative than the list [RD] -P03 (person with a chronic condition) The novelty of DC's interface did not appear to be a huge hindrance. All our participants were able to use DC to control the required data sharing in the evaluation tasks.
Acceptance, however, was not uniform. All participants thought DC would be useful for chronic care that dealt with complex care situations. One participant added that DC's unconventional design was effective but intimidating and overwhelming; this appeared to be from the novelty of DC's interface. However, some participants (6 of 15) stated they would prefer RD for simple cases that consisted of only one or two care team members or a small number of PGHD data streams. We note that DC was not designed for these simple cases; it was an attempt to handle near-future scenarios with moderate sized care teams and a number of data streams. We will return to this issue in the Discussion, because it suggests a relatively simple modification that can handle all cases.
There were several other usability issues mentioned by participants. These are relatively minor issues; none kept our participants from finishing the evaluation tasks. DC uses a clickto-focus (because of accessibility); a few participants wanted drag-and-drop as an additional user interface focus mechanism. One participant wanted a more recognizable format for the trash/delete area as can be found in Windows or Macintosh OS.
There were several complaints about the use of screen real estate in DC; those participants wanted a tighter use of the screen.
Our participants were also able to use the conventional design of RD to complete the tasks. However, since the tasks assumed moderate complexity in a care team, participants noted the difficulty of creating or modifying settings using RD's user interface. All participants mentioned the burden of too much clicking to navigate or how sharing settings are visually hidden, which made it difficult when creating sharing settings involving multiple care team members. We will discuss these issues further below.
In summary, our participants found DC even with its nonconventional design to be usable. Participants noted that a learning curve was required, but within the context of complex care tasks, as embodied by tasks T1 through T4, DC was sufficiently usable for specifying sharing settings. P13 stated:

(Require2) DC Is Effective for PGHD Sharing Involving Multiple Members of a Sufficiently-Sized Care Team
Data checkers was designed to support a care team with up to 20 members, currently a reasonable size suggested by prior work and our co-design process. All our tasks, from T1 to T4, were designed to involve different numbers of care team members ranging from 3 to 20, including family caregivers, hired caregivers, and different clinicians, so as to examine this requirement. We found that all participants who started T1 through T4 were able to complete the tasks (14 out of 15). (One participant was unable to start T4 because of Internet difficulties, but completed T1 through T3). More importantly, every participant stated that DC was capable of supporting sharing settings that could involve multiple care team members.
Participants expressed this capability in terms of either the utility resulting from being able to add or remove a care team member to/from a group (12 participants) or the utility resulting from being able to group relevant care team members together (13 participants) (Ten participants mentioned both benefits). Five participants used their own experience to highlight the value of grouping care team members together. P08, one of the five, stated that DC would allow her to express sharing settings involving multiple doctors at the same time: While supporting a moderately-sized care team was also possible with the conventional interface of RD, all participants found it repetitious to create sharing settings involving multiple care team members. They had to individually specify settings for each care team member (and data type), as opposed to including multiple care team members simultaneously in the process of creating sharing settings. For them, DC's ability to have meaningful groupings of data and persons was valued when having sharing settings involving multiple care team members.

(Require3) DC's Presentation of Sharing Settings Facilitates the Understanding of Sharing Within a Care Team
All of our participants (15 out of 15) expressed the belief that DC's grid-based interface would allow them to understand sets of sharing settings easily. They stated the ability to read sharing settings in one screen, as opposed to navigating through a hierarchy (as in RD), allowed them to quickly understand how the data was currently shared within the care team. There were three types of participant comments about their sense of understanding, all of which pointed to the advantages of the visual style of DC. Many comments were about taking in the team visually: being able to see everything at once or being able to form an overall picture (12 comments), not forgetting an individual (2), or seeing the entire team especially with changes and dynamics (6). (Participants could make multiple comments about understanding). Other comments included not needing to rely on one's short-term memory but instead on visual perception, including not relying on short-term memory when creating or modifying settings (13), modifying one individual's settings by being able to see another's (3), and being able to visually doublecheck one's actions (4). A few made general statements about preferring visuals (2). All of these point to the efficacy in visually handling care situations where there are multiple recipients, each of which has multiple data types and perhaps multiple types of data flows (controls). I think if...God forbid, my mom has a mobility-related accident and she needs a care team for 24-hour support and assistance, I really, really love the grid [DC] because, yeah, it gives you that blueprint outline of who has access to what. It gives you that zoom out view... like the full picture. -P05 (caregiver) In addition to the evaluation of the grid-based design, we asked participants to use and then discuss the data preview feature in DC. In T4, data preview was enabled to investigate whether it could assist participants in creating sharing settings and understanding their effects. Almost everyone (13 participants, with the other 2 participants missing data) stated the data preview was helpful for strengthening their understanding of the settings. However, two of the 13 positive participants commented that they could complete the task without using the preview but still thought it was useful. As to why the participants thought the preview was helpful, more than half (8) stated that the preview enabled them to view what a care team member would see, as P06 expressed. I like the fact that you're letting the user of the tool to see, like, oh, that's how granular that the information is like, that's what I'm really sharing. I think that's really important. -P06 (caregiver) Additionally, nine participants said that the preview helped them confirm the effects of the sharing setting, with two specifically stating that the preview helped them verify the effect of controls, as P07 stated. (Four participants mentioned both benefits.) ...if I was a newer caregiver...I could imagine it [DC with preview] being useful to trust that... when I toggle a setting, I can see it [the data preview] change right away and know that it worked....It [data preview] lets me trust myself and the system that I did the right thing to adjust the settings. -P07 (caregiver) The data preview feature solidified their understanding of sharing settings, and it also gave users enough feedback to make them confident that they were doing fine-grained control correctly (which supported Require4 as well). This was in contrast to the state-of-the-art interface in RD, which hid an overview of settings behind a cascade of menus and toggles and which provided no feedback about whether data would be accessible appropriately.

(Require4) DC Enables PCTs (or Their Primary Caregivers) to Perform Fine-Grained Control Effectively
In our evaluation, we examined whether DC would allow users to exert fine-grained control by applying types of controls: level of detail, length of history, the shape of data, and visibility of data (refer to section 2.3). We found that DC supports fine-grained control through the combination of directing data flows between groups of PGHD and recipients, and the ability to simultaneously apply controls to each of these data flows. While doing Tasks T1 to T3, which required participants to apply controls to finetune how data were shared with members of a care team, nearly all of the participants (14 out of 15) explicitly acknowledged the usefulness of DC to efficiently fine-tune these data flows between groups of PGHD and care team members. Specifically, of the 14 participants, three valued DC's ability to apply controls to groups of PGHD and recipients, two reiterated the same point by stating that applying controls using RD is individual-based, and nine mentioned both characteristics. The ability to apply controls to affect multiple PGHD and recipients was considered helpful, as P04 stated: Their examples also demonstrated that DC's controls, developed in our co-design process, are useful and practical for complex chronic care processes. For instance, P07 commented on how she would apply controls to share only summaries with specialists but could share more with people with whom she was close.
A lot of people who were close [to me] might get a good amount of data, but then specialist might just...need to get the summaries, and that might not need to get changed all the time. [For cases that need frequent changes,] being able to affect them quickly with just [a visual block representing a control] really was a nice idea. -P07 (caregiver) 3.5.5. (Require5) DC Supports Health and Team Changes in the Long-Term by Allowing Reuse, Reflection, and Customization As we argued earlier in section 2.3, a suitable design should support PCTs and caregivers in adapting to changes in health conditions and care teams over the long term. While the longterm benefits and tradeoffs of a design can only be validated through field deployments or randomized control trials, we adopt the approach recommended by Klasnja et al. (2011aKlasnja et al. ( , 2017: to focus our investigation on how the design features of DC support simple tasks (proximal goals) that could be essential for the long term.
When asked about which design (DC or RD) was preferred to control data sharing over a longer period of time after finishing all of the tasks. Eleven participants (out of 15) thought DC would be suitable for long-term use, based on their experience of participating in chronic care (We are missing explicit answers for the other four participants as the question was not asked due to lack of time). However, six participants said stated that RD would be useful when dealing with the simple case of having one recipient.
Participants noted the ability to get a quick overview of settings (refer to section 2.3) would be of significant help. This, we believe, led participants to state that DC's grid-based interface provided three unique advantages over a conventional design (as in RD) for adapting to changes in the care.
First, nearly all of the participants (ten of the 11 participants answering the long-term question) felt that the ability to visually compose sharing settings would enable PCTs to reference or reuse existing sharing settings, which is essential for long-term use. All of these participants commented that DC allowed them to add (or edit) elements in existing settings to create a new sharing setting. As we noted above, participants valued the ability to visually reference existing settings during the creation of new settings or the modification of prior settings when making adjustments, such as allowing additional data to be seen by care team members or adding controls to regulate data access. On the topic of reusing settings, P06 commented that DC allowed him to create settings confidently, knowing that he was accurately reusing what had been done before (which had previously worked). Second, some participants (4) noted that DC's way of displaying sharing settings in one screen created opportunities for reflection about their prior sharing decisions, which is important over the long term. As PCTs and caregivers will adjust sharing settings only when necessary, such stimulation for reflection is likely to be critical in making healthcare decisions (Mamykina et al., 2006(Mamykina et al., , 2008Owen et al., 2015). P06 stated this point by saying that DC allowed him to rethink the big picture and prior decisions, which was not offered by the hierarchical design of RD, where details of sharing settings were buried inside the hierarchy: The grid [DC] is really good because it shows you what decisions you made in the past....let's say a new relative, Tom, moves closer and has more care-giving responsibilities, you give him more data... When looking at the grid to remove or add privileges for Tom, you might say, oh, Crystal was my other caregiver that we forgot to take the permissions off for or, oh, why isn't Uncle Rob seeing that? -P06 (caregiver) Third, a person's health situation will vary over the long term. Some participants (4) specifically noted that DC's organization would allow them to create sharing settings for special cases (e.g., an event or healthcare crisis), which would be useful for adapting to changes in life. As P07 commented, DC, which does not have a strong restriction on how sharing settings are arranged and provides the capability to turn on/off sharing settings, would allow her to manage sharing settings for different use cases in a personalized way: ... For a person in maintenance mode for spinal cord injury... [DC] empowers me to make the data on one side and all the recipients on the other. I can imagine...three or four examples [of use cases] and a row for each use case. I could kind of turn it off right away and then add it again when I was ready. -P07 (caregiver) Data checkers, then, offers three important capabilities that participants found likely to be beneficial for PCTs and caregivers throughout PCTs' health journeys: supporting the reuse of sharing settings, providing stimulation for reflection, and allowing personalized arrangements of sharing settings for different use cases. These capabilities were substantially more difficult to achieve in RD.
In summary, participants in our evaluation found DC, because of its design, was able to fulfill the five requirements discussed in section 2.3. These requirements, we argued above, are necessary in supporting chronic care-especially in chronic care situations like SCI/D. It was gratifying but surprising to us how uniformly our participants noted the advantages of DC over RD in meeting these requirements. DC's ability to meet the requirements was in sharp contrast, for our participants, with RD, a current state-ofthe-art conventional interface for managing data access.

DISCUSSION
This paper presented the design and evaluation of DC, a gridbased prototype application that allows people with health conditions requiring care teams (PCTs) and caregivers to share patient-generated health data effectively with an at-home care team while still maintaining control and enhancing privacy. Results from our qualitative evaluation, based on a scenario of care for SCI/D, indicate that DC meets the five design requirements outlined in section 2.3, and therefore DC is likely to be usable and useful for SCI/D care.
Results from this study highlight the importance of the identified design requirements and systems like DC which are built upon them. The results also argue for additional work in this area to meet the expanding need for managing PGHD and integrating it into the care management paradigm.
More work will be necessary to fully consider the promise of DC. There were a number of limitations of this study that have to be recognized. We developed the scenario and the initial designs around SCI/D. SCI/D often requires a medium sized care team (e.g., 5-20 care team members) and 20 data sources that include both sensor-generated and self-report data. While a focused setting allowed us to contextualize the design as well as ground the evaluation of DC with our participants, future work will be necessary to determine whether additional considerations are necessary for different sized care teams and different numbers of sensors.
Because of the prototype and evaluation site, we also constrained the care network. We did not consider important information sources and recipients, such as casual friends, church members, and social network acquaintances (Consolvo et al., 2004;Skeels et al., 2010;Gronvall and Verdezoto, 2013). Future work will be required to understand whether DC can be extended to include these groups and in what ways.
In addition, the evaluation study for our prototype was qualitative in nature. As with any interpretivist study, generalization is difficult. While the need for assistance can also be seen in care for conditions such as Alzheimer's disease, Parkinson's, dementia, bipolar disorders, and a broad range of other complex health conditions, further studies will be needed to confirm our findings for other health conditions.
To demonstrate DCs' effectiveness and cost-efficacy, with particular considerations of other health conditions, we will need to verify how our findings generalize. While the associated resources for conducting this type of analysis were beyond the scope of the current project, the data and findings will be important for pushing for the integration of programs such as DC into healthcare systems.
Furthermore, our participants consisted of mainly people with chronic conditions or caregiving experience who were young and educated, whose experience might affect the feedback on the user experience of an unconventional design such as DC. Future studies would benefit from larger sample sizes and appropriate analyses.
There are also a number of potential avenues for future work, in addition to those suggested above. First, with more specialization in the healthcare system and increasingly available Internet of Things (IoT) and smart home solutions, supporting an increasingly more complex care team structure and more diverse data sources will be required. One line of future work will be finding additional UI mechanisms to support increasing numbers of sharing settings, more complex teams, and a larger diversity of data sources.
Second, our participants wanted several usability additions. They wanted better use of screen real estate. More importantly, they felt that DC lacked an easy ability to find and change a single recipient's settings; this could be seen in the preference for RD in simple cases. DC currently has the ability to sort settings; adding the capability to filter for recipients would be an easy addition and would likely solve this issue for users.
Third, PCTs or caregivers will need to intermittently engage with sharing settings to accommodate changes throughout a person's health journey, a theme that emerged from our findings. While DC's grid-based presentation allows users to be more aware of other sharing settings and provides an opportunity for users to reflect on existing sharing settings, future work will be needed to facilitate such re-engagement over the long term.
Fourth, our study highlighted the visual benefits provided by the grid-based UI of DC, which relied on vision and mouse interaction (e.g., moving and clicking). Additional consideration will be needed to support individuals with different constraints, such as visual impairments or fine-motor issues. Conforming to Web Content Accessibility Guidelines (WCAG) 12 would ensure that DC is perceivable and operable.
Finally, we plan to integrate machine assistance with DC as small intelligent agents, or "critics" (Fischer et al., 1990) that can work independently to identify and solve problems. For example, critics could be developed for DC to assist with re-engagement. A critic could also help people with health conditions and caregivers examine settings that might need adjustments to accommodate changes in health and care conditions. Such assistance could be particularly beneficial when PCTs have a reduced capacity for sharing management as a result of illness.

Concluding Remarks
This paper presented DC, an application for enabling users with chronic and complex health management needs to have finegrained control over their sharing of PGHD with a care team. DC offers a grid-based user interface that utilizes people's familiarity with other grid-based designs such as checkers. DC also visualizes the effects of sharing settings by presenting data from the perspective of the data's receivers, helping people understand the implications of their sharing settings. Using a scenario based in the care of SCI/D, our evaluation study showed that the combination of DC' fine-grained control over data sharing, as well as its ability to preview outcomes, was usable and useful. These findings suggest Data Checkers has considerable potential to better support people with health conditions requiring care teams (PCTs) in sharing PGHD.

DATA AVAILABILITY STATEMENT
The raw data supporting the conclusions of this article will be made available by the authors, without undue reservation.

ETHICS STATEMENT
The studies involving human participants were reviewed and approved by the University of Michigan Health Sciences and Behavioral Sciences Institutional Review Board. The patients/participants provided their written informed consent to participate in this study.

AUTHOR CONTRIBUTIONS
P-YH and DC designed the presented idea with feedback from MM and MA. P-YH developed the proposed system, recruited participants with the help of MM, carried out the user study in discussion with MA, and wrote the manuscript with support from DC, MM, and MA. P-YH and MA analyzed the data. MM provided expertise related to self-management and disability health. MA supervised the project. All authors contributed to the article and approved the submitted version.

FUNDING
This project was funded by the Craig H. Neilsen Foundation (grant no. #324655), the National Institute on Disability, Independent Living, and Rehabilitation Research (grant no. #90RE5012), and the University of Michigan School of Information.