This week, I was invited to attend a BRIDGE Summit at Stanford. I was there to represent Ushahidi’s work and wasn’t particularly sure what to expect… But it turned out to be a very interesting brainstorming session for a new product/service in the health space: BRIDGE.

Dr. Stephen Friend (M.D. and PH.D., president/co-founder/director of Sage Bionetworks) ran the show. What you will read below are just my notes, ideas, and understanding of what we were trying to do. I’m sure others at this summit came away with a whole different set thoughts, but, in the interest of advancing my own understanding and sharing of ideas in general, it seemed worth putting together a narrative of the product we were designing.

So what is BRIDGE? After a two day discussion, we settled that BRIDGE is a platform (rather than an app) that will strive to:

• help gather medical information;
• crowdsource algorithms that would act on collected data with an aim to make medical advances;
• provide services to patients (information, education, support);
• facilitate research and make it easier for scientists to get access to data and to post requests for crowdsourcing projects;
• ease communication between all individuals and organizations working to advance medical knowledge;
• encourage citizen activism in the area of health;
• allow patients and their loved ones to get control over their treatments;
• ease funding solutions to micro and macro projects;
• and, in general, create a new paradigm in how medical research is being done and be a positive contribution to the whole medical/health ecosystem.

So we were thinking BIG!

Current Problems

It’s good to start any product development by thinking about the problems we are trying to solve. Stephen and Paul (Paul Tarini, Senior Program Officer, Pioneer Portfolio, Robert Wood Johnson Foundation) outlined what was currently not working and what they were hoping BRIDGE could help accomplish.

One big problem is data. Currently, patient information (medical records and genetic data) is collected by doctors and researchers. We have laws that prevent doctors from freely sharing their patients’ records. And we have strong incentives and laws in place to encourage researchers to hoard their data. A researcher at Harvard finds it very difficult to take a look at DNA samples collected at Stanford. And as patients form communities, their insights and experiences (and medical records) get stored at yet another “data silo”, isolating them from access by researchers not associated with that group.

When I was a teen working with other teens as a programmer at a publishing company, we had a saying: “If it was hard to write, it should be hard to understand.” We safeguarded our code by making it obscure and difficult to read. There is something similar going on with medical data. People compete over access to data, and what BRIDGE wants to encourage is free access and collaboration.

Open medical data would help us understand medical conditions far more clearly and deeply by virtue of providing many more cases and examples than a single “data silo” can possibly do. And open data would also allow individuals currently on the periphery of medical research to lend their intuition and skills to solving complex health problems.

BRIDGE would crowdsource the data and allow people to crowdsource the solutions. And as a practical benefit, BRIDGE would serve as a cognitive, social, and psychological support to patients and their caregivers facing very difficult medical situations.

In a sense, BRIDGE would give the power to individuals to create or be part of the solution, to move past being a passive cog in the healthcare system, and to become a Bridge to Health.

Bridge to Health

So the main goal of the BRIDGE project is to help people get involved in becoming part of the solution to our health care problems. Initially, Sage Bionetworks is working with five communities, including ones focused on Melanoma and Parkinsons Disease. They started with these communities because they were already organized, had funding, and were enthusiastic to explore the possibilities. So at a minimum, BRIDGE has to do something these communities/individuals find useful and that advances their goals and those of Sage Bionetworks.

So what are the different communities of users that BRIDGE could potentially serve? What are their defining characteristics? What are their goals? How can BRIDGE support the many different cultures of its participating user groups? What problems are these people trying to solve by using BRIDGE? These questions are those I would ask of any product design effort at its initial stage of development. And below are my thoughts of the user groups for BRIDGE and what defines them. Obviously, other people at the summit might have come away with different views.

Patients and Caregivers Uber Group

The most obvious defining characteristic defining this group is their medical condition — this is personal for them. These are people in the midst of a health crisis. Patients are experiencing the ravages of the disease and are managing the ups and downs of the cure. Their caregivers have the responsibility and burden of managing the treatments and their side-effects. Caregivers also tend to be very emotionally involved with the patients.

On the first pass of characteristics that define these subgroups, I have the following:

Patients:

1. physical: some would have limited physical stamina;
2. cognitive: some might have compromised cognitive abilities (be it by the disease, treatment, or the experience of being sick);
3. emotional: obviously, there’s an emotional toll of being sick (which will effect memory, attention controls, etc.);
4. privacy: in U.S., the acknowledgement of disease can lead to loss of financial stability and social isolation;
5. computer expertise: while some patients might happen to be expert computer users, as a group they will have a full range of computer skills and thus would need technical support;
6. domain knowledge expertise: while some patients might happen to be expert medical professionals users, most will require domain-specific support (and even medical professionals might not have skills in the precise area of the affliction);
7. geo-location: while some patients might share a geographic area, most will be scattered all over the world (this has an impact on communication and group cohesion);
8. language skill: while English will be the default language of the platform, not everyone will be fluent (and fluency will also spread along the receptive and expressive abilities, as well as along the continuum of technical language);
9. legal: not all individuals are able to make legal decisions about care and quality of life;
10. financial: not all patients have access to the same financial resources (i.e. not only will the treatment be impacted by lack of resources, but access to computers and Internet may vary significantly from patient to patient).

Caregivers:

All but the first three criteria are shared between caregivers and patients. Caregivers are emotionally affected by the experience of providing day-to-day support; their expertise in computer use may vary significantly from individual to individual; they have variable domain knowledge; as they are physically present with the patients, their location relative to other caregivers and patients is indeterminate; their language skills vary; they might or might not have legal authority over treatment; and there’s great variability in financial resources. But caregivers differ from patients in that they are not sick — they don’t suffer the physical and cognitive side-effects of treatment.

Regardless of all else, this combined group of patient and caregiver members would join BRIDGE because they want to solve a problem, they want to share data, they want to make a difference. Maybe it isn’t for themselves, but for those coming after them. This combined group is the most enthusiastic member group of BRIDGE, with the most to gain and the most to lose. And while this group might lack in expertise, it more than makes up for it in passion!

What this group has to offer are intimate details of their personal experiences with the disease. What they want in return is to see that their “gift” mattered — made a difference to research or to others. They want to feel connected to a community with shared experiences and be able to share and support others in the same situation. Ultimately, of course, they want a cure.

Doctors and Medical Researchers Group

These are the domain knowledge experts. Both the doctors treating the patients and the researchers looking to find new treatments are the thought leaders for a particular disease. They are also passionate about finding solutions, but it’s not personal for most of them. Cures will advance careers and win awards, but they don’t have to watch loved ones suffer. As with all user groups, there will be cross overs between categories. There will be sick doctors and researchers with sick family members — life is curious that way.

Below is a quick and very incomplete list of characteristics of this group.

1. deep expertise: detailed knowledge of the disease, treatments, and research;
2. access to technical support: most researchers have structured technical support from the organizations they work for (hospitals, universities, research centers, and corporations);
3. legal and professional restrictions: human subject protocols, grant specs, corporate contracts, etc. — all of which can put many restrictions on what’s possible and what kinds of data they are free to collect and share;
4. competitive attitudes towards data: this is all about “data silos”, extensively discussed during our summit — what provides incentives for one research group to share their data and findings with others?
5. location: doctors and researchers tend to work in groups, allowing for synchronous communication and flow of information and built-in peer support structures;
6. language: while not every researcher is fluent in English, all have technical language fluency in their area of expertise;
7. emotional: while researchers are emotionally involved in their professional work, this is clearly very different from the emotional involvement of patients and their direct caregivers (with some exceptions, of course);
8. financial: research requires financial support. Part of every researcher’s job is obtain continuous funding (and be bound by the financial arrangements of the funding source);
9. professional reputation: one of the currencies of medical research is professional reputation — it provides access to funds and projects.

To succeed with this group, BRIDGE needs to carefully align the goals of its members with the goals of BRIDGE. Find the pain points for this group and make it easier for them to do their jobs. Make sharing of data and information the price of admission to the project. Make participation in BRIDGE a financial and professional boon for participants.

Amateur Scientists and Technologists

This is an interesting group. One of the promise of BRIDGE, as I see it, is the opening up of medical research to amateur scientists — people who have interest, expertise, and time to devote to solving a particular problem but who do not belong to a traditional medical research institution, and thus are barred from doing such work. BRIDGE can change that. And this is an amazing premise and promise for this project.

Opening up the system/platform to technologies is another exciting opportunity. Once the platform is up, there will be many opportunities to extend it and to provide additional services by opening up BRIDGE API to the world. Individuals and technology companies can plug into this ecosystem and develop applications, targeting various user groups. Some of this would be done as a non-profit type ventures, some as a commercial businesses. The model, as discussed during our summit, would follow that of Amazon — a well-developed, well-documented, well-designed platform that allows developers to leverage its existing resources to develop new uses.

BRIDGE Supporting Staff

We shouldn’t overlook the group of individuals that will have to run BRIDGE. They too have goals, limitations, and strengths that we would need to advance, support, and encourage. But I will leave the description of the characteristics of this group to others.

Administrators, Regulators, Reporters, and Backers

Again, this is an important group and covers many different individuals that would be involved with BRIDGE. I would like to quickly focus on financial backers — people who are interested in investing in research, or to donate money for a particular cause, or to finance a new technology application, etc. What do these people need? What are their goals and incentives? And how can BRIDGE leverage and support this group of users?

One interesting subgroup is individual donors — can we micro-finance a project? Can we crowd-finance a research effort or a study? BRIDGE should make it easy to do by design.

What’s Hard?

One way to tackle the design of BRIDGE is to ask “What do these different user groups find difficult to do on their own?” This is the “sweet” spot for BRIDGE — BRIDGE can deliberately design cognitive, legal, financial, social, reputational, and technical support structures that make its users engage with the platform as an obvious choice and in preference to starting from scratch. We call these scaffolding. So what scaffolding do users of BRIDGE need to help them succeeded in reaching their goals?

Obviously, each user group and sub-group has its own pain points. But we can broadly specify the following needs:

• Legal: doctors, researchers, technologists, and patients are not lawyers. BRIDGE can provide legal support to promote data gathering and sharing of information. One of the things we talked about at the summit is a system that would be able to create custom and pre-approved patient consent forms from a normalized library of legal code. This would greatly streamline the research process and ease both the financial and administrative burdens.
• Technical: just as legal is hard, so are some aspects of running a large web-based medical research platform. I thought it would be helpful to pull out the ones that I know are particularly thorny:
  1. Login and Individual Profiles: BRIDGE should provide easy, secure, and standardized login systems for all its users. One login and user profile system for the entire BRIDGE ecosystem.
  2. User Privileges: there will be many different levels of access privileges. BRIDGE should take on all matters having to do with the design, creation, and maintenance of such a system.
  3. Database Structures: at its heart, BRIDGE is a massive relational database. Database systems have to be designed, and BRIDGE is in a unique position to do so in this case, with vision for flexibility and usability.
  4. Search: with luck, BRIDGE will have millions of records. Comprehensive search solution will be a big part of what BRIDGE will offer to its users.
  5. Ease of Forming Groups: BRIDGE can make it easy to form groups and subgroups that could communicate and share information; that can easily come together and just as easily drift apart.
  6. Storage: again, hopefully there will be millions of records. These need to be stored and maintained and backed up on regular basis.
  7. Security: there will be hacker attacks on BRIDGE.
• Design: as a platform, BRIDGE will need a set of design guidelines and a way of communicating and enforcing them.
• Library/Wiki: to support the educational needs of the BRIDGE community of users, there will need to be a library of documentation, repository of research, glossary of ideas, history of the project, etc. Users should be able to contribute and expand this system similar to Wikipedia.
• Reputational System: as are done in Wikipedia and Amazon, BRIDGE will need to be able to award reputational tokens to its users. Partly, this will provide a way to gamify some aspects of the system. But it will also be necessary to keep track and reward positive behaviors and discourage negative ones.
• Financial System: Amazon makes it easy for individuals to buy products from small mom & pop outfits. BRIDGE can take the burden of working with banks and credit institutions and provide a financially reputable and stable platform into which other services can plug in.
• Trust System: BRIDGE, as Amazon and Wikipedia, is in a unique position to help “lend” trust to its users. Through its reputation, stability of platform, ease of use, BRIDGE can provide credibility to researchers and technologies that work with in the system.
• Marketing: again, this is a matter of scales. PR and marketing are hard work and are not in the sweet spot of domain expertise of medical research and technologist or patients, for that matter. BRIDGE can help raise awareness of research, disease, need for volunteers or additional data.

And one final notion — Design only what’s necessary for success! BRIDGE should remove barriers to entry for individuals and organizations doing medical research. It should allow each user, each individual, to be the bridge between what she knows and can contribute and others seeking that information and that solution.

Any thoughts?