We built COMPASS — a clinical research data collection and analysis platform for autism researchers at Ball State University. The platform replaced paper-based data collection with a structured digital workflow that works in clinic, in classroom, and in the field.
Longitudinal autism research generates a specific kind of data problem. You're not collecting a survey once — you're tracking the same participants across months or years, with observations recorded by clinicians in sessions, by families at home, and by researchers reviewing outcomes. Every data point has to be tied to a participant, a time point, a study protocol, and an observer. The relationships matter as much as the values.
The team at Ball State was doing this on a mix of REDCap forms, spreadsheets, and paper session logs. REDCap is a capable tool for basic clinical data collection, but it wasn't designed for the kind of structured longitudinal workflows COMPASS needed — where a session observation by a clinician needs to link automatically to a family-reported measure from the same week, and a research coordinator needs to see both without having access to identifiable clinical notes.
The access problem was real. Researchers need aggregate data and study-level views. Clinicians need individual participant histories. Families need to see their own data and complete assigned measures. Admins need audit logs. These aren't just different UI preferences — they're different data views with different compliance implications. HIPAA requires that access to protected health information is limited to what's necessary for each role. A system that shows everyone everything isn't compliant, regardless of how the data is stored.
Beyond HIPAA: IRB approval for the study required demonstrating that data collection procedures met specific security and consent standards before a single participant was enrolled. The platform had to be designed to pass that review, not retrofitted after.
The first conversation was with the research team's IRB coordinator, not the lead developer. We needed to understand what the IRB had approved before we designed anything — because the approved protocol defines what data can be collected, who can see it, how long it can be retained, and what consent mechanisms are required. Build something that doesn't match the approved protocol and you don't just have a software problem; you have a research ethics problem.
The data model is built around participants and study enrolments, not users. A participant has enrolments across one or more study protocols, and each protocol has a defined set of measures and time points. Observations are always attached to a specific enrolment at a specific time point — there's no free-form data entry that can produce records outside the study structure.
Role-based access is enforced at the query layer, not just the UI. A clinician's session token cannot retrieve aggregate study data even if they craft a direct API call. A family account can only read records tagged to their own participant ID. Researchers see de-identified data by default; access to identifiable records requires an explicit permission granted per study. Audit logs record every access event with timestamp, user, role, and record identifier.
We built accessibility into the UI from the start rather than auditing against WCAG at the end. Families using the platform include neurodivergent users, users with low digital literacy, and users on mobile devices in home settings. Contrast ratios, keyboard navigation, screen reader labels, and touch target sizing were specified in the design system before any screens were built.
Offline capability matters in clinical settings. Session observations happen in therapy rooms that don't always have reliable wifi. The data entry interface uses a local-first model — observations are written to local storage immediately, synced to the server when connectivity is available. Clinicians don't need to think about connectivity during a session.
Data at rest is encrypted. Transfers are over TLS. Backups run daily with point-in-time recovery. [NestJS + Angular + MongoDB + AWS based on enterprise/clinical context, update if different.]
COMPASS is live at Ball State University and in active use across the autism services research programme.
The platform is currently supporting 12 active research participants across 4 study protocols. Families complete assigned measures through the portal on a schedule defined by the study protocol — measures that previously required a research coordinator to mail paper forms, chase returns, and manually enter data are now completed digitally and appear in researcher dashboards automatically.
The transcription work that used to sit between observation and analysis is gone. A clinician records a session observation in COMPASS; it's in the researcher's dataset immediately, correctly attributed, and already structured for the statistical tools the team uses.
The IRB compliance posture has held through re-reviews. The platform's audit logging and access controls have been reviewed as part of ongoing IRB oversight and passed without remediation.
The research team has published work using data collected through the platform.
For us: COMPASS is the project we point to when someone from healthcare, education, or clinical research asks whether we understand their compliance environment. We do — not because we read a checklist, but because we built around the constraints from day one.
Every project starts with a conversation. Tell us what you're working on — we'll tell you honestly if we can help, what it would take, and roughly what it would cost. No pitch. No pressure.
Free 30-min scoping call
Book →