About Currently
Turning fragmented data
into shared standards.
Healthcare runs on HL7 V2 messages from the 1990s, CCDA documents that vary by vendor, and data locked in silos. Currently automates the translation to FHIR R4 and OMOP CDM 5.4 so the data can finally move.
The Problem
Healthcare data is
stuck in translation.
Every hospital, EMR, and health system speaks a slightly different dialect of HL7. Every HIE has spent years building custom parsers, one-off integrations, and brittle pipelines to normalize data. When a new provider joins the network, the cycle starts over.
Meanwhile, researchers and analysts need the same data in OMOP CDM format — which means a separate project, separate budget, separate timeline. The interoperability team and the analytics team are solving the same problem twice.
Currently replaces both. One ingestion pipeline that parses, cleans, and validates your data, then simultaneously produces FHIR R4 bundles for interoperability and OMOP CDM 5.4 tables for research — using Athena/OHDSI vocabularies with a documented ~92.5% terminology mapping rate.
Before & After
What changes
with Currently.
Custom integrations for every data source. Separate projects for FHIR and OMOP. Manual quality tracking. Per-facility engineering work that doesn't scale.
One pipeline that handles both standards. Six connectivity types configured in minutes. Quality scoring built into every processing run.
Without Currently
Custom HL7 parsers per facility, maintained by hand
With Currently
Auto-detect HL7 V2 or CCDA, parse with a single pipeline
Without Currently
Separate FHIR conversion and OMOP conversion projects
With Currently
Simultaneous FHIR R4 + OMOP CDM 5.4 from one ingestion
Without Currently
Manual connectivity setup per provider organization
With Currently
Six connectivity types (GCS, S3, Azure, FTP, SFTP, API) with real connection testing
Without Currently
Quality tracked in spreadsheets after the fact
With Currently
Per-record completeness scoring and per-source quality reports, inline
Without Currently
One dashboard for everyone, no data isolation
With Currently
Four scopes (platform, HIE, provider, patient) with automatic data filtering
Platform
What we've built.
Terminology Mapping Rate
OMOP CDM 5.4 Tables
FHIR R4 Resource Types
Connectivity Types
Technology
How it's built.
Dual-Database Architecture
PHI lives in an isolated database with its own access controls. The platform database stores only de-identified data. Shared UUIDs link records without exposing patient information.
Python Orchestration Pipeline
Seven processing stages — ingest, parse, normalize, optional NLP, clean export, FHIR conversion, OMOP conversion — with Athena/OHDSI vocabulary resolution and AI-assisted cleaning.
Session-First Access Control
Clerk manages authentication and RBAC. Every request resolves a session with scope, permissions, and data filter. Four scopes — platform, HIE, provider, patient — see different data from the same codebase.
Get started
Transform your
healthcare data infrastructure.
Start processing HL7 messages, ensure data quality, and enable FHIR-based interoperability — all from one platform.