10 comments

  • dataviz1000 16 minutes ago ago

    I'm working on building an AI agent that creates queries over a time-series database focused on financial data. For example, it can quantify Federal Reserve reports and generate a table showing how SPY reacted 30 minutes after, at EoD, at the next day’s open, and at the next day’s EoD. It will plan the database query and then query the data from a materialized view. It is magic!

    How would biomedical researchers use tons of time-series data? A better question is: what questions are biomedical researchers asking with time-series data? I'm a lot more interested in generalized querying over time-series data than just financial data. What would be a great proof of concept?

    • amber_raza 5 minutes ago ago

      That sounds like a fascinating project.

      To answer your question: In the biomedical world, the 'Time-Series' equivalent is Patient Telemetry (Continuous Glucose Monitors, ICU Vitals, Wearables).

      The Question Researchers Ask: 'Can we predict sepsis/stroke 4 hours before it happens based on the velocity of change in Heart Rate + BP?'

      Right now, Evidex is focused on the Unstructured Text (Literature/Guidelines) rather than the structured time-series data, but the 'Holy Grail' of medical AI is eventually combining them: Using the Literature to interpret the Live Vitals in real-time.

  • bflesch an hour ago ago

    Somehow "clerk" is on my ublock origin blocklist and therefore the whole website is not loading. I didn't add "clerk" to the blocklist so it must've been added by one of the blocklists that ublock origin is subscribed to, so there must be a good reason why "clerk" is on that blocklist.

    When building a product for medical audience which might care a lot about privacy maybe don't use components which are shady enough that they end up on blocklists.

    Edit:

    > Why no Vector DB? In medicine, "freshness" is critical. If a new trial drops today, a pre-indexed vector store might miss it. My real-time approach ensures the answer includes papers published today.

    This is total rubbish - did you talk to a single medical practitioner when building this? Nobody will do new treatments on their patients if a new paper was "published" (whatever that means, just being added to some search index). These people require trusted source, experimental treatment is only done for private clients who have tried all other options.

    • amber_raza 18 minutes ago ago

      Thanks for the feedback—this is helpful.

      1. Re: Clerk/uBlock: You were spot on. The default Clerk domain often gets flagged by strict blocklists. I just updated the DNS records to serve auth from a first-party subdomain (clerk.getevidex.com) to resolve this. It should be working now.

      2. Re: Freshness & 'Rubbish': You are absolutely right that standard of care doesn't (and shouldn't) change overnight based on one new paper.

      However, the decision to ditch the Vector DB for Live Search wasn't about pushing 'experimental treatments'—it was about Safety and Engineering constraints:

      Retractions & Safety Alerts: A stale vector index is a safety risk. If a major paper is retracted or a drug gets a black-box warning today, a live API call to PubMed/EuropePMC reflects that immediately. A vector store is only as good as its last re-index.

      The 'Long Tail': Vectorizing the entire PubMed corpus (35M+ citations) is expensive and hard to keep in sync. By using the search APIs directly, we get the full breadth of the database (including older, obscure case reports for rare diseases) without maintaining a massive, potentially stale index.

      The goal isn't to be 'bleeding edge'—it's to be 'currently accurate'.

  • adit_ya1 41 minutes ago ago

    Out of curiosity, what's the prioritization of evidence (RTC Metanalysis > RTC > observational ) etc, and what's the end user benefit over a tool like OpenEvidence? You mention that other tools are expensive, slow, or increasingly heavy with pharma ads, but OpenEvidence for now seems to be pretty similiar with offerings, speed, and responses. What's your pitch as to why one should prefer this?

    • amber_raza 9 minutes ago ago

      Great questions.

      1. Prioritization: I instruct the model to prioritize evidence in this hierarchy: Meta-Analyses & Systematic Reviews > RCTs > Observational Studies > Case Reports. It explicitly deprioritizes non-human studies unless specified.

      2. Why not OpenEvidence? OE is excellent! But we made two architectural choices to solve different problems:

      'Long Tail' Coverage: OE relies on a pre-indexed vector store, which often creates a blind spot for niche/rare diseases where papers aren't in the 'Top 1% of Journals.' Because Evidex queries live APIs, we catch the obscure case reports that static indexes often prune out.

      Workflow: OE is a 'Consultant' (Q&A). Evidex is a 'Resident' (Grunt work). The 'Case Mode' is built to take messy patient histories and draft the actual documentation (SOAP Notes/Appeals) you have to write after finding the answer.

  • eoravkin 29 minutes ago ago

    Out of curiosity, did you actually see any pharma ads on OpenEvidence?

    • amber_raza 8 minutes ago ago

      Great question. I haven't seen banner ads on OpenEvidence yet, but the 'hidden tax' of free tools is often Publisher Bias.

      Users have noted that some current tools heavily overweight citations from 'Partner Journals' (like NEJM/JAMA) because they index the full text, effectively burying better papers from non-partner journals in the vector retrieval.

      My goal is strictly Neutral Retrieval. By hitting the PubMed/OpenAlex APIs live, Evidex treats a niche pediatric journal with the same relevance weight as a major publisher, ensuring the 'Long Tail' of evidence isn't drowned out by business partnerships.

  • neil_naveen an hour ago ago

    FYI, You are using Clerk in development mode

    • amber_raza an hour ago ago

      Oof, good catch! I must have left the test keys active in the deployment config.

      Swapping them to production keys right now. Thanks for the heads up!