30 publicaciones etiquetados con "ai"

Pinned Post | Originally published March 7, 2026

Outcomes research has evolved alongside the broader arc of healthcare analytics infrastructure. Early siloed clinical systems produced fragmented administrative and claims data with limited analytic utility — adequate for billing, but structurally unsuitable for longitudinal cohort construction or comparative effectiveness work. The meaningful use era expanded the availability of structured clinical data, yet interoperability failures meant that patient journeys remained fractured across institutional boundaries, undermining the real-world evidence studies that outcomes researchers depend on. The shift to integrated analytics platforms — particularly the adoption of common data models like OMOP/OHDSI — marked a genuine inflection point: federated network studies, standardized phenotyping, and reproducible retrospective analyses became operationally feasible at scale. Now a fourth generation is taking shape, one in which AI-augmented clinical intelligence moves outcomes research from retrospective description toward prospective, near-real-time evidence generation — enabling dynamic cohort surveillance, treatment heterogeneity detection, and value-based care signal identification that was previously impractical outside of narrow clinical trial settings.

Parthenon is built for this fourth generation.

For a year, every AI feature in Parthenon spoke to a model the same way: build a prompt, send it, get one answer back. Abby answers a question. The publication writer drafts a paragraph. Useful — but fundamentally a vending machine. You put a prompt in, a completion comes out, and the model never gets to look around, use a tool, or change its mind.

This milestone changes that. Parthenon now runs genuine agentic copilots — built on Anthropic's Claude Agent SDK, the same autonomous loop that powers Claude Code — inside two workflows: the Study Designer and the Publication assistant. The agent decides which tools to call, iterates (search → draft → validate → refine), keeps a session across turns, streams its work to the browser, and — critically — asks for permission before it writes anything. It ships on a reusable, profile-agnostic core, behind a super-admin runtime switch, with PHP still holding the pen on every database write.

This post is the full story: the architecture, the four pull requests that built it, the human-in-the-loop approval gate, and the engineering discipline (and bugs) along the way.

Concept mapping is the single largest line item in any OMOP CDM ingestion budget. Published estimates put it at 40–60% of total ETL effort per source system — measured in clinician-weeks, not engineer-hours. Today we landed the architectural piece that's been missing from Parthenon's vocabulary stack since the beginning: Harmonia, an automated decision layer that sits between Hecate (read) and Ariadne (write) and does the cognitive work that's been falling on humans.

The name is deliberate. In Greek mythology, Harmonia is the goddess of agreement, accord, and fitting together — daughter of Aphrodite and Ares, born of love and conflict. That's what concept mapping is: bringing disparate source vocabularies (an ICD-10 code from one EHR, an NDC string from another, a hospital's local lab nomenclature) into harmony with a single canonical OMOP standard. Every approved mapping is a small act of harmony. Until today, Parthenon could show candidates and record decisions but couldn't reach harmony on its own.

This post walks through what we built, why it's an improvement over the existing Hecate + Ariadne pair, and the four real bugs we hit getting a benchmark to actually run.

A landmark day for the Parthenon platform: the Abby Study Design Compiler crossed the finish line and landed in production. Alongside that headline feature, we completed a deep structural refactor of the Study Workbench, patched a collection of critical runtime bugs, and hardened the frontend with accessibility improvements and unsaved-changes guards. Phase 19 smoke testing confirmed everything holds together against the live DEV environment.

A focused day on Parthenon with three distinct threads advancing in parallel: the GIS-backed urban/rural stratification pipeline moved from concept to tested RED-phase scaffolding, the Study Designer received several important bug fixes and UX improvements, and the architectural groundwork for Abby's guided Study Design Compiler workflow was laid out in detail.

Parthenon's Cohort Definitions page has always had a "Create from Care Bundle" modal — a way to bootstrap a cohort definition from a pre-packaged disease framework with ICD-10 patterns, OMOP concepts, and quality measures. The idea is elegant: select "Rheumatoid Arthritis," click a button, and get a fully-formed OHDSI Circe cohort expression ready to run against any CDM source.

But when I opened the modal this weekend, I saw only ten bundles. Type 2 Diabetes, Hypertension, Heart Failure, COPD, Asthma, and a handful of others. Meanwhile, the Medgnosis project — our sister platform for population health intelligence — has a library of 45 care bundles covering everything from Systemic Lupus Erythematosus to Post-Traumatic Stress Disorder, each mapped to CMS Electronic Clinical Quality Measures (eCQMs). The data was sitting there in three SQL migration files. Parthenon just didn't know about it.

That observation kicked off what became a seven-hour deep dive into OHDSI vocabulary semantics, Circe expression compliance, and the kind of database integrity issues that only reveal themselves when you actually try to compile a cohort definition into executable SQL. By the end, we had 45 bundles, 338 quality measures, 928 verified OMOP concept IDs — and we caught eleven bugs along the way, several of which would have silently produced wrong cohorts in production.

This is the story of how we got there.

A dense day on Parthenon with 19 commits focused on three interlocking themes: hardening Abby's ChromaDB knowledge substrate, broadening test coverage across the UI and service layer, and tying up the loose ends needed to ship v1.0.4 cleanly. No single flashy feature today — just the kind of careful, compounding work that makes a platform trustworthy.

Eight days ago, we shipped the Patient Similarity Engine — a multi-modal system that scores patients across six clinical dimensions using weighted Jaccard, z-scored lab distances, and pathogenicity-tiered genomic matching. Two days later, we generated embeddings for a million patients. The engine worked. Researchers could find patients like a seed patient, compare cohorts, and export results.

But it wasn't research-grade. The Jaccard similarity was binary — two patients with Type 1 DM and Type 2 DM got zero credit even though they share the ancestor "Diabetes mellitus" in the SNOMED hierarchy. The cohort comparison showed a radar chart with divergence percentages, but couldn't tell you which covariates were driving the imbalance or how the distributions actually differed. There was no propensity scoring, no temporal analysis, no phenotype discovery, and no way to fuse multiple data modalities into a single principled similarity measure.

Tonight, in a single session, we shipped eight interconnected upgrades that transform the Patient Similarity Engine from a useful clinical tool into a research platform that exceeds the analytical capabilities of OHDSI Atlas, Oracle Healthcare's "Patients Like Mine," and every open-source OMOP similarity system we've been able to find.

This is the story of what we built, why each piece matters, and how they work together.

A landmark day for platform observability and data pipeline reliability. We shipped a fully wired Jobs monitoring page that surfaces all 13+ tracked job types, broke through a major ETL performance ceiling on the SynPUF dataset (17 hours → 14 minutes for drug_era builds), and closed out a cohort generation audit that uncovered eight discrete bugs across the SQL builders, API layer, and frontend.

Two days ago, we shipped the Patient Similarity Engine — a multi-modal system that scores patients across six clinical dimensions on OMOP CDM. The architecture was sound. The algorithms worked. But there was a problem hiding in plain sight: none of our patients had embeddings.

The embedding pipeline had been silently failing since day one. Three type mismatches between our PHP backend and Python AI service meant that every embedding request returned a validation error, was caught by a try/catch block, and logged as a warning that nobody read. The feature vectors were all there — conditions, drugs, measurements, procedures — but the 512-dimensional dense vectors that would make similarity search fast at scale? Zero. For every source. For every patient.

Tonight, we fixed all three bugs, refactored the embedding pipeline from CPU-only SapBERT to GPU-accelerated Ollama, upgraded from 512 to 768 dimensions, introduced batch deduplication that delivered a 123x throughput improvement, and generated embeddings for 1,007,007 patients across three CDM sources. This is the story of what broke, what we built, and what it unlocks.