Pain Guide Platform
Pain Guide began as a design I made for a symptom-tracking site and grew into the platform behind about ten clinical trial sites. I led the move from markdown to Sanity, and I'm now building a shared base for the next sites, three of which are launching now.
One platform, many sites
Each Pain Guide site is a clinical research tool with its own symptom-tracking domains (sleep, pain, affect, cognitive function, energy/fatigue, mental health, and more) and its own authentication model (public, limited, or fully gated), configured per site. The sites share a design and, increasingly, a codebase.
-
Gen 0: The original
painguide.com. I did the original design, and a colleague built the patient-facing application on top of it.
-
Gen 1: ~10 clones, built without me
While I was away from Michigan Creative, the same design and Vue 2 tracker pattern were cloned for about ten clinical research conditions, including BACPAC (chronic pain), PASC (long COVID), sickle cell disease, and lupus.
-
Gen 2: CMS modernization, my return
I started with Pancreatitis Pain Guide, then led the migration from markdown content to Sanity Studio. Gen 2 is live in production on PRISM (adapt-prism.com) and INTERACT ADAPT (adapt.painguide.com).
-
Gen 3: A shared base, and three new sites
painguide-baseis the new foundation: an 11ty marketing site and Sanity content model, plus an 11ty and Alpine tracker meant to replace Vue 2. The Alpine tracker hasn't shipped in a site yet, and the next instance will be the first to use it. Three new sites built on it are launching in the meantime: Alleviate-C, MCPain, and Eye Pain. MCPain and Eye Pain launch with the existing Vue 2 tracker. Alleviate-C skips the tracker and instead enrolls participants from a Qualtrics survey and sends them scheduled emails. Between them they've added English and Spanish content, clinician accounts that can add patients, and a study locations map.
Deciding what goes in the base
Each site keeps its own Firebase backend, isolated by design, so a change for one trial can't touch another trial's data. The cost is that every site is a fork. When a client asks for something the other sites will want too, like clinician accounts with an add-patient flow, a custom Studio navigation bar, or headings that can be linked to directly, it gets built in one instance and then has to reach the base and the other instances.
I carry those features into the base so the next site starts with them. The ongoing judgment call is what belongs in the base and what stays specific to one study. The base also has to be right before a site forks from it, because once a trial launches there's no shared codebase to patch it through later.
- Powers real clinical trials: BACPAC, PASC, sickle cell disease, lupus, and more
- Per-site configurable symptom domains and auth model
- Alpine tracker built in the base, with the next instance set to be the first to ship it
- Original design authored solo; platform lineage spans 4 architecture generations