A massive day on the Parthenon platform: we shipped the full six-chapter Cohort Wizard UI from scratch in a single push, and completed a methodical, non-destructive migration of Imaging, Genomics, GIS, and Oncology extension structures into the localhost OMOP schema. These two workstreams — one facing researchers building cohorts, one facing the data layer powering them — represent a significant leap forward in Parthenon's end-to-end outcomes research story.

v1.0.5 — Data Quality & Validation​

v1.0.5 is the second stabilization release in the v1.0.x arc. With test infrastructure in place from v1.0.4, this release focuses on data integrity across the platform — programmatic audits that verify correctness of SQL generation, schema routing, vocabulary resolution, FHIR transformation, migration safety, and cross-schema referential integrity.

Every research platform hits the same inflection point. You build a powerful cohort builder. Researchers love it. They create cohorts for Study 1, Study 2, the rare disease project, the pancreatic cancer corpus. Each study gets its own "All-Cause Death" outcome. Each gets its own "MACE" composite endpoint. Before long, you're staring at 89 cohort definitions in a flat, unsorted list where a meticulous seven-concept-set new-user design sits next to an auto-generated stub with one concept and no generations. A Rett syndrome genotype-stratified trial cohort is sandwiched between a SynPUF cardiometabolic triad and a never-run hypertension bundle. The list is technically complete and practically useless.

Today, Parthenon ships a cohort categorization system that solves this. We audited every cohort definition in the database, identified and consolidated 9 duplicates and orphans, assigned 80 surviving cohorts to 8 clinical domains, computed a quality tier for each one, and rebuilt the Cohort Definitions page with collapsible domain-grouped sections and quality filter pills. Researchers can now browse by clinical domain, filter to study-ready phenotypes, and find what they need in seconds instead of scrolling through a flat table.

This post describes the problem in detail, explains how we analyzed and scored the inventory, walks through the architecture, and shows what the result looks like.

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.

The Patient Profile's Labs Panel has been one of Parthenon's persistent frustrations: a table with Ranges and Status columns that were perpetually empty, and a display format that forced clinicians to mentally reconstruct a lab value's trajectory from a column of numbers. Today we shipped the fix — a Recharts line chart with a shaded reference-range band, status-colored measurement dots, and a hybrid data layer that finally makes lab reference ranges work across every CDM source.

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.

We shipped eight analytical upgrades to the Patient Similarity Engine last week — hierarchical concept similarity, Love plots, distributional divergence, propensity score matching, UMAP projections, temporal DTW, consensus clustering, and similarity network fusion. The engine is now, arguably, more analytically capable than anything in the OHDSI ecosystem for cohort-level comparison.

But the UI was still the original five-tab layout we built in the first sprint. And no amount of analytical horsepower matters if a researcher opens the page, sees five tabs without context, and doesn't understand the order of operations.

Tonight we replaced it entirely.

v1.0.4 — Test Coverage & CI Hardening​

v1.0.4 is the first stabilization release in the v1.0.x arc. No new features — only refinement of what exists. This release fills the test coverage gaps identified during the v1.0.3 launch and hardens the CI pipeline so every subsequent release starts from a trustworthy baseline.

Parthenon's Vocabulary Search now provides 100% navigational coverage of all 105,324 standard SNOMED CT Condition concepts through 27 curated clinical groupings — achieving functional parity with MedDRA's System Organ Class navigation while preserving SNOMED's superior clinical granularity. This is the story of diagnosing the SNOMED-OMOP domain boundary problem, engineering a cross-domain hierarchy builder, curating a clinically intelligent grouping layer, and systematically closing every coverage gap until no standard concept was left behind.

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.