3 publicaciones etiquetados con "fhir"

v1.0.9 — Protocol-to-Publication, FHIR Interoperability, and Copilots Everywhere​

Where v1.0.8 grew the research surface (Publish, Library Lifecycle, the first copilots), v1.0.9 is the release that makes that surface trustworthy and reproducible. It lands the deterministic protocol-to-publication pipeline (ADR-0020) — provenance, empirical calibration, scientific gates, and manuscript synthesis — brings FHIR ingestion to Medgnosis parity and proves it against the live Epic sandbox, puts the Abby copilot on every page with a local-model backend so Community Edition can run it on-prem, and closes a long list of production-readiness items: RBAC on every PHI route, R/HADES analytics proven end-to-end, no "coming soon" in primary workflows, and a fresh-machine install that starts cleanly from docker compose up.

When we introduced Vulcan, our FHIR ingestion engine, it could do something impressive and something frustrating at the same time. It implemented the full SMART Backend Services client flow — sign a JWT, exchange it for a token, kick off a Bulk Data $export, poll for completion, download NDJSON, map it into OMOP CDM. Every step worked. Every test passed.

Against a mock server.

A mock server is a generous conversation partner. You hand it a signed assertion and it hands back a token without looking too closely. A real electronic health record system — Epic, in particular — is not so generous. Before Epic issues you a token, it wants to verify the signature on your assertion. And to do that, it needs something Vulcan had never been built to provide: a way to find our public key.

This is the story of building the missing half of that trust relationship, and of the moment Vulcan stopped talking to mocks and completed its first live handshake with the Epic on FHIR sandbox.

Healthcare data does not arrive in neat packages. It streams — continuously, chaotically, from dozens of transactional systems that were never designed to talk to each other. EHR encounters appear as HL7 ADT messages. Lab results materialize through OBX segments hours after the draw. Radiology reports surface from PACS archives with inconsistent coding. Claims trickle in from clearinghouses days or weeks after the visit. Genomic panels arrive as VCF files from external laboratories with their own nomenclatures and timelines.

Transforming this unruly sea of clinical data into a coherent, research-ready OMOP Common Data Model is the central engineering challenge of any outcomes research platform. And until now, Parthenon handled it the same way most platforms do: as a series of one-time bulk loads. Upload a file. Map the concepts. Write the CDM. Move on.

That era is over.

Today we introduce two new engines to the Parthenon pantheon — Vulcan and Poseidon — purpose-built for the reality of continuous healthcare data integration.