Create Jira Ticket
This idea cannot be sent to Jira.
LymeSignal AI by Ace
Ace Web Optimization, Inc. built LymeSignal AI by Ace, led by CEO/POC Sulamit Berkovits and Lead Developer/Final MVP Presenter Sam Berk. During the Sprint, the product was shaped by patient discovery, target-user testing, an earlier clinician Page 1 exercise, and TOPx Office Hours. LymeSignal is a deployed 10-screen, non-diagnostic web application for patients and caregivers preparing for complex clinical visits. It turns fragmented records into a source-linked clinician-facing Visit Brief while preserving provenance, contradictions, and unresolved uncertainty. AI organizes the evidence; it does not decide what the evidence proves. The competition MVP uses synthetic records only.
Solution Overview (MVP Demonstration):
User-facing Application
Live demo, prototype, or working product
Access instructions (if needed)
No login is required. Select “Try a sample case.” On the Demo Notice, check “I understand: use sample or fictional information only,” then select “Open sample case.” The competition MVP is for synthetic/sample data only; do not enter real patient information.
Results for the American People:
LymeSignal serves patients and caregivers preparing for complex clinical visits; clinicians are downstream users of the Visit Brief. Four patient discovery interviews grounded the workflow in lived experience: records are scattered, patients become the “human router,” and uncertainty is hard to carry accurately into the next visit. In our canonical synthetic case, four records disagree about when persistent fatigue began. LymeSignal does not ask the patient to decide which record is right. It surfaces both sources, allows an approximate recollection or “I’m not sure,” keeps any clarification separately attributed, and carries unresolved uncertainty into a source-linked brief. In five target-user sessions, four completed and one exposed a task-blocking clarification failure. We treated that failure as design evidence, redesigned the interaction, and one fresh unprimed participant on the refined candidate completed without blocking confusion. In a separate controlled exercise using an earlier Page 1 artifact, 3/3 clinicians found all four predefined targets: reason for visit, chronology, prior testing/treatment, and the unresolved issue. The result is a patient-centered preparation workflow with a clinician-readable payoff. This demonstrates workflow completion and information findability—not clinical effectiveness, time saved, improved diagnosis, or outcomes.
Data, Tech & Evidence Driven Approach
LymeSignal uses AI to connect fragmented records without asking the model to make a clinical judgment. The deployed pipeline is: extraction → AI-supported record analysis → evidence/source verification → deterministic chronology composition. Source-derived items retain traceability to the originating record, with page references where applicable. Unsupported dates remain unsupported; conflicting records remain visibly conflicting. Evidence classes are intentionally separate: source medical evidence, patient-provided information, patient clarification, unresolved conflicts, and federal population context. Patient clarification never overwrites source evidence. This creates an inspectable chain from record to chronology to Visit Brief rather than a black-box summary. For U.S. Open Data, LymeSignal uses CDC/NNDSS Lyme surveillance dataset x5j9-wybp as a separate Federal Context layer. The New York sample distinguishes the 2023 surveillance reporting year from current retrieval/update metadata, shows national and state population context, and states surveillance limitations. Population data is never converted into an individual patient’s exposure, diagnosis, disease probability, or personal risk. All four workflow completers in formal target-user testing understood that distinction. The same safety discipline applies to records: a source “last updated” date is not reinterpreted as a medication start date. AI accelerates structuring; provenance, verification, deterministic composition, and explicit boundaries constrain unsupported conclusions while leaving clinical interpretation to clinicians.
Execution, Efficiency & Delivery
LymeSignal is a working, deployed 10-screen MVP, not a slide concept. In the canonical synthetic case, the end-to-end workflow turns four fragmented records into a source-linked six-event chronology, surfaces one needs-review conflict, preserves patient clarification separately, adds CDC population context, and generates a deterministic two-page Visit Brief. The near-term value is concrete: organized evidence, visible uncertainty, and a clinician-facing starting point before the visit. Production verification covered real processing through the deployed API, provenance, clarification save/edit/reopen, unresolved continuation, patient/source separation, federal context, and PDF generation with no clipping or truncation. Human testing changed delivery. Five target-user sessions exposed one task-blocking clarification failure; follow-up regression still found “referee” confusion, so the interaction was refined again and retested. In a separate earlier Page 1 exercise, 3/3 clinicians found all four predefined information targets. The core workflow functions now. A bounded real-PHI pilot requires privacy/security readiness and pilot governance—not fundamental additional AI research—followed by measurement of task completion, clinician-defined workflow usefulness, and burden. We do not claim HIPAA compliance, clinical effectiveness, quantified time savings, or ROI before those are demonstrated.
Scalability, Reuse & Societal Impact:
LymeSignal’s reusable asset is not Lyme-specific diagnostic logic; it is a modular evidence-preparation architecture for fragmented longitudinal records. Record ingestion, extraction, provenance, chronology, uncertainty, patient clarification, federal population context, and clinician-facing summarization are separated so condition-specific data and policies can change without rebuilding the core. That creates a credible reuse path for other chronic or invisible illnesses in which patients carry records across disconnected providers and important uncertainty is buried in documents. The same Federal Context pattern can support condition- or agency-specific U.S. Open Data while keeping population context separate from patient evidence. Next steps are privacy/security readiness, a bounded clinician/patient-advocacy pilot, measurement of clinician-defined workflow usefulness and distribution, then standards-based exchange where partner workflows require it. Future integrations can align with CMS interoperability efforts, HL7 FHIR, USCDI+, or TEFCA as deployment requirements justify them; these are not current implementation claims. We have not yet demonstrated real-PHI operation, cross-condition validation, health-system deployment, or EHR integration. The current evidence supports a source-linked MVP with a credible path to reuse across conditions, care settings, and data ecosystems while preserving provenance, uncertainty, and clinician judgment.
Sulamit, what I appreciate most in LymeSignal is the rule that a patient’s clarification never overwrites source evidence: two records can disagree about when fatigue began, and the tool shows both without forcing a choice. I also admire how openly you report your testing, including the task-blocking failure, the redesign and the retest, and the plain list of what you don’t yet claim.
There’s published evidence for why reading the record, not just its codes, matters. Azhir et al. (Med 2025) studied 85,364 COVID-19 cases at one Massachusetts health system: an algorithm applied to health-record data flagged 24,360 Long COVID patients, against 6,340 with the Long COVID code (U09.9), and chart review confirmed 79.9% of the algorithm’s flags and 77.8% of the coded cases (chart attached). It’s Long COVID in one health system, so it says nothing about your Lyme tool directly, but it shows how much evidence sits in records without reaching a code, and why source-linked verification like yours matters.
My entry turns published papers into simulators you can change and check against federal data, so a reader can see how each number moves: https://invisibleillness.crowdicity.com/post/896844
Bryan’s LymeBridge also keeps patient-reported information separate from clinical evidence, and Kimberly’s WholeContext AI also lets patients correct their history while each source stays attached. Bryan, Kimberly, I’d be glad to hear what you’ve each learned about testing these designs with real users.
Wishing you a successful pilot.
Users tagged:
Reply 1
Uri, thank you for such a thoughtful comment. You picked up on one of the design principles we cared most about: when the records disagree, LymeSignal should preserve that disagreement rather than allow AI to quietly decide which version is correct.
I also appreciate the Long COVID example and, especially, the way you framed its limitation. Evidence from another condition does not validate LymeSignal, but it does help illustrate the broader problem of important information living inside longitudinal records rather than being captured cleanly in codes.
Our goal has been to make that underlying evidence easier to use while keeping provenance, patient clarification, and unresolved uncertainty clearly separated. The next step we care about most is learning how clinicians define a genuinely useful pre-visit evidence brief in real workflows without overstating what the system proves.
Thank you again for taking the time to look at the project so carefully.
Reply 1
What impressed me most is that LymeSignal does not force conflicting medical records into one “answer.” It preserves the disagreement and makes it visible for the clinician to review. That feels like a very responsible way to use AI in healthcare.
Reply 2
What stood out to me is that LymeSignal doesn’t force certainty where the record itself is uncertain. When four records disagree about when fatigue began, the patient isn’t asked to pick a winner. They can give an approximate recollection or say “I’m not sure,” and that clarification is stored separately from the source evidence rather than overwriting it.
That discipline shows up throughout the pipeline. AI helps with extraction and analysis, but the chronology is assembled deterministically, unsupported dates stay unsupported, and a record’s “last updated” date is never read as a medication start date. The CDC surveillance data is kept in its own layer and never turned into personal risk. These are small choices that block the most common ways AI summaries go wrong in healthcare.
I also respect the honesty about limits: the task-blocking failure in testing, the redesign, and the clear list of what isn’t claimed yet (HIPAA compliance, time saved, clinical outcomes).
Reply 2
From a technical architecture perspective, what stands out to me is the restraint built into LymeSignal. The system is not simply using an LLM to summarize records and hoping the output is correct. It preserves immutable source evidence, keeps patient clarification separately attributed, surfaces conflicting records instead of silently reconciling them, and uses deterministic chronology assembly after the AI-supported extraction and verification steps.
That separation of concerns is important. It makes provenance and uncertainty inspectable rather than hiding them behind a polished AI answer.
I also appreciate that the team documented a task-blocking usability failure, redesigned the workflow, and retested it rather than presenting only successful results. Combined with the source-linked Visit Brief and clear boundary that AI organizes evidence rather than deciding what the evidence proves, this feels like a thoughtful approach to building AI for a high-stakes healthcare workflow.
The architecture also appears reusable beyond Lyme disease because the core problem—fragmented longitudinal records, conflicting documentation, and important context spread across multiple sources—is not disease-specific.
Reply 1
I spent some time going through LymeSignal and what impressed me most is the discipline behind the design.
A lot of AI healthcare tools seem focused on producing the fastest possible summary. LymeSignal takes a more careful approach: the original source evidence stays traceable, conflicting records are preserved instead of being silently “resolved,” patient clarification is kept separately attributed, and uncertainty remains visible for the clinician.
That distinction matters. In a complex longitudinal record, the goal should not be for AI to invent a single clean story. The goal should be to make the underlying evidence easier to understand without losing the context that gives it meaning.
I also appreciated the transparency around testing. The team did not just present successful results. They documented a task-blocking usability failure, redesigned the workflow, and retested it. That kind of iteration gives me more confidence in the product than a polished demo alone.
What is especially interesting to me is the broader potential. Lyme is the use case here, but the underlying problem of fragmented records, conflicting documentation, and important information buried across multiple sources exists across many chronic and complex conditions.
This feels like a thoughtful example of using AI to support better evidence organization without trying to replace clinical judgment.
Reply 2
Really interesting project I like how you’re addressing a real problem that many patients face when dealing with multiple doctors and scattered medical records. The idea of bringing everything together in a way that helps both patients and clinicians prepare for a visit could make a real difference. I also appreciate that you’ve tested the product with users and continued improving it based on their feedback. Looking forward to seeing how LymeSignal evolves and how it might eventually help people dealing with other chronic illnesses as well. Great work!
Reply 2
As a full-stack developer, what stood out to me is that LymeSignal is not treating AI as a black-box summarizer.
The architecture appears intentionally separated into layers: source records remain traceable, AI helps extract and organize information, conflicting evidence is preserved instead of silently reconciled, patient clarification stays separately attributed, and the final chronology is assembled in a more deterministic way.
That separation is important in a system dealing with medical records because it makes the output easier to audit and reduces the risk of a polished AI response hiding where information actually came from.
I also like that the team tested the workflow, documented a task-blocking failure, changed the design, and retested it. From a software engineering perspective, that kind of feedback loop is much more meaningful than simply showing a polished demo.
The underlying architecture also seems reusable beyond Lyme disease. Any workflow involving fragmented longitudinal records, conflicting documentation, and the need for clear provenance could potentially benefit from the same pattern.
Very thoughtful implementation of AI as an assistive layer rather than an authority.
Reply 2
I had the opportunity to try your product firsthand—truly impressive! Excellent work, and wishing you continued success!
Reply 1
One question we've been thinking about as LymeSignal moves beyond the competition setting:
If you were a clinician receiving a pre-visit brief generated from a patient's longitudinal records, what would make you trust it enough to actually use it?
For us, provenance, visible uncertainty, conflicting records, and separately attributed patient clarification are important pieces. But I'm curious what others would want to see before relying on something like this in a real workflow.
Would love perspectives from clinicians, technologists, patients, caregivers, or anyone working with complex records.
Reply 0
Exactly what is needed for us patients a place to organize perfectly all of our past records so we can have peace of mind and organized when visiting any doctor we chose to.
Reply 1
What I like most about LymeSignal is that it does not try to make messy medical records look cleaner than they really are. If two records disagree, that conflict stays visible. If the patient adds clarification, it is kept separate from the original source. And the AI helps organize the evidence without pretending to decide what the evidence proves.
That combination of provenance, uncertainty, and practical usability feels especially important for people dealing with long, fragmented medical histories.
I also appreciate that the team showed the parts that did not work perfectly during testing and then redesigned and retested the workflow. That makes the project feel much more grounded than a typical AI demo.
Reply 0
I have been thinking about something that keeps nagging at me as LymeSignal moves past the demo stage, and I would love to hear from people who have actually wrestled with this.
What happens when the record changes after a brief already exists? Say a lab result lands late, or a patient corrects a date, or someone flags an earlier entry as wrong. If the brief just updates quietly, a clinician who already read the first version has no idea anything changed. If you keep every version, it could get messy fast.
My gut says the older version should stay visible, with a short note about what changed and why, because erasing it feels like rewriting history after someone may have already acted on it. But I am not sure how much detail belongs in that note before it becomes noise.
Uri, Umer, Navisoft, you have all pushed on the provenance and evidence side of this, so I am curious: if you received an updated brief, what would you want to see first? A simple change log, a clear superseded stamp on the old one, or something else?
Users tagged:
Reply 0
As a Flutter developer, what impressed me about LymeSignal is that the product thinking goes well beyond the interface.The workflow has to take fragmented records, keep the original evidence traceable, preserve conflicting information instead of hiding it, and still present everything in a way that feels simple enough for a clinician to use quickly. That is a much harder engineering problem than just building a polished front end.I also like the separation between AI-assisted analysis and the parts of the experience that need to stay deterministic and auditable. From a development standpoint, that kind of boundary makes the system easier to reason about, test, and evolve safely.The result feels like a thoughtful example of using modern app development and AI together without letting the AI become the authority.
Reply 1
This is very cool!
Reply 0
What a smart easy way to prepare for a doc visit not only for Lyme.
Reply 1
I keep thinking about the distance between a good brief and a good visit. We can build something clear and source linked, but then it lands in a ten minute appointment, and I honestly do not know what happens next. Does the clinician skim it, does the patient walk them through it, does it end up in the chart or forgotten on the chair? My worry is that the same conflicts we preserved so carefully in the brief get flattened the moment someone has sixty seconds to look at it. For those of you who have been on either side of that room, what actually made a summary useful in the visit itself, and what got in the way?
Reply 0
Hi Sulamit, I like that the Visit Brief keeps contradictions and open questions visible instead of smoothing them over. Have the clinicians you tested with said which part of the brief helps most in a short visit, and about how long does it take a patient to put one together?
Reply 0