Armakuni Contact us
← All case studies

A return-to-play decision shouldn't wait
for someone who knows SQL.

A U.S. concussion-management platform held more than 900,000 assessments, but physicians and athletic trainers couldn't ask it a question without database skills or opening raw files. In a four-to-five-week proof of value, we built a plain-English search that reads both clinical modules, calculates the answer in code rather than in the model, and returns a summary. AWS funded $11,700 of the $13,000 cost.

Before

The answers were in the data, out of the clinicians' reach.

A wrong answer could send an injured player back on the field.

After
Plain Englishquestions answered across both clinical modules, in the proof of value
  • Computed answers, with averages, baseline changes and trends worked out in code.

The answers were in the data, out of the clinicians' reach

The company's platform supports about 3,000 users, with more than 900,000 assessments from 750,000 subjects. Its users are physicians and athletic trainers making concussion decisions.

They couldn't simply ask it things. Structured records lived in MySQL and the assessment data lived in S3 as JSON, so any question meant database access or opening raw files. The symptom checklist and the reaction-time test were stored separately, so a full concussion picture meant consulting both and comparing them by hand. A question like "which players have higher headache scores and slower reaction times over the last 30 days?" had no interface at all.

A wrong answer could send an injured player back on the field

The platform captured the numbers but didn't interpret them: headache severity, emotional symptoms and reaction-time changes from a player's baseline. The clinician worked out what they meant, every time. Whatever we built had to be precise, because an error in symptom severity or reaction-time change could influence a return-to-play decision. Here, an imprecise answer is a patient-safety problem.

The model reads the question and code works out the numbers

From that came the design: the language layer understands the question and writes the summary, and retrieval and computation in ordinary code supply every number, so the model never does the arithmetic on a patient's scores.

How we built it

3 decisions, in the order we made them. Each one says what we did and why, with what it did drawn beside it.

  1. Each question sent to the data that can answer it
  2. The numbers come from code
  3. Prove it without touching the production portal

Each question sent to the data that can answer it

Built withRDSMySQLS3OpenSearchBedrockFastAPI
Reaction time since baseline? Routed to the right data the athlete's numbers
The engineering

A clinician asks in clinical terms while the data is stored in database terms, so each question is classified before anything is fetched:

  • A query classifier extracts the user's intent and decides whether the question is about symptoms, reaction time or both.
  • The application turns that intent into structured retrieval parameters, including the relevant group and timeframe, so every answer is scoped to the right team, affiliate and period.
  • The integration layer combines relational records from RDS MySQL with assessment data from S3.
  • OpenSearch stores vector representations for the search layer, while Bedrock and FastAPI run the language interface.

The numbers come from code

The answer Words: the modelNumbers: code
The engineering

The backend then computes the requested metrics: average symptom severity, change from an individual's baseline and group-level trends. The language layer interprets the question, and the retrieval and computation path supplies the values in the summary. Clinicians read a conclusion, with the figures behind it worked out the same way every time.

Why: language models are good at reading a question and unreliable at averaging a column. In a clinical tool an average has to be right every time, so we kept the arithmetic in code.

Prove it without touching the production portal

Built withStreamlitFargateWAFSecrets ManagerCodePipelineCloudWatch
One affiliate, up to 100 athletes The proofPortal, unchanged the production portal never touched
The engineering

Changing a live clinical system to test an idea is a risk nobody needs. A Streamlit chat interface exposed the proof of concept (POC) without changing the existing Ruby on Rails portal, and Fargate containers handled query execution, filtering and metric assembly:

The deployment design put a load balancer and AWS WAF in front of application services in private subnets, so nothing that reads clinical data faces the internet directly, and Secrets Manager held the credentials for the backend integrations. CodePipeline, CodeBuild, ECR and CodeDeploy gave the containers one release path, and CloudWatch and CloudTrail kept operational visibility and a record of AWS activity.

The proof of value was scoped to one affiliate and up to 100 athletes, keeping validation manageable, with an architecture built to take the full dataset later without structural change.

One clinical question, end to end

  1. An athletic trainer asks: how have headache scores and reaction times changed for my team this month?
  2. The classifier sees both modules and sets the team and the 30-day window.
  3. The integration layer fetches the symptom records from MySQL and the reaction-time assessments from S3.
  4. The backend computes average severity, each player's change from baseline and the team trend.
  5. Bedrock writes the summary from those computed values.
  6. The trainer reads one answer across both modules, instead of two reports compared by hand.

What we'd tell another CTO

1Compute the numbers in code and use the model for the question and the summary. Classifying each question before anything is fetched is what makes that work, because the class decides which data, which group and which period the code runs over.
2Scope every answer to the team, affiliate and timeframe in the retrieval parameters themselves, since an answer that leaks across groups is a clinical error.
3We proved it beside production, in a separate interface on one affiliate's real data. That told the company more than a large synthetic set would have, and the live portal was never at risk.

What else changed

  • A proof of value in four to five weeks, at a net cost to the customer of $1,300, with AWS funding $11,700 of the $13,000 engagement.
  • An architecture ready to scale to the full platform.

What comes next

Integration into the production Ruby on Rails portal, more assessment modules (balance, cognitive and visual-processing tests), HIPAA-aligned role-based access, audit requirements and query refinement from real usage. A wider rollout, with a quantified evaluation of clinical accuracy, still has to follow.

How we'd do it today

This project came before our current offers. Here's how we'd approach the same work now.

The test would come first. A golden set of real clinical questions, each with the answer a clinician confirmed, and a second set kept sealed so nobody tunes to it, would gate every prompt and model change, with a wrong baseline change or the wrong player counted as a critical case that has to pass on every run. Where an AI grades answers, its grades would be checked against the clinicians' own on cases it hasn't seen.

Each AI agent would get its own identity in AgentCore Identity and, acting for a clinician, that clinician's rights through Cedar policies checked outside the model on every call, so a trainer only ever sees their own players and no credential enters the model's context. Axiom would give "baseline", "severity" and "affiliate" one meaning in a catalogue on Amazon DataZone, with row-level access through AWS Lake Formation, and the HIPAA evidence would come from the controls as they run, starting from a data-flow map we approve before any data moves.

Modernize with AI AK AI Factory

More work like this

  1. AIHoursA visitor-management software companysaved per workflow, in the company's own testingThe editor could do anything. Customers left because they couldn't use it.10+ node types in the production editor6 acquired products, one visitor identity, provedOn AWS Bedrock · DynamoDB · RDS · Cognito
  2. AIParallelA Canadian legal software companyreading of every bundle, so throughput is no longer capped by headcountA new law firm arrived with 400 pages. Someone had to read every one before it went live.5–6 weeks to a working prototype that reads onboarding bundles in parallel300–400 pages per bundleOn AWS Bedrock · S3 · ECS · Fargate
  3. AIFirstA U.S. drug testing networklabeled sensor dataset for this kind of testing, and a working prototypeCameras weren't allowed in the room. So we built a way to sense cheating without seeing anyone.24,000+ tests a day the pipeline is sized for120 testing centersOn AWS S3 · Lambda · DynamoDB · API Gateway

All case studies →

Have a problem like this one?

A free workshop: a few hours with the architects who'd do the work, on your own systems. No cost.

Book a free workshop