Currently

Currently is a healthcare data platform built for Health Information Exchanges and the member facilities they serve. It ingests raw clinical records in the formats those systems actually produce — HL7 v2 messages, CDA and CCDA XML documents — and transforms them into research-ready, interoperable output: validated FHIR R4 bundles and OMOP CDM 5.4 datasets.

The platform runs as a multi-tenant web application backed by an async pipeline on GKE, with strict dual-database architecture that keeps PHI in a dedicated Cloud SQL instance, completely separated from platform operational data. Terminology resolution runs against the OMOP Athena vocabulary (6.3 million concepts), covering LOINC, SNOMED CT, ICD-10-CM, and RxNorm at ingestion time rather than as a post-processing step.

Currently ships with 16 validated HL7 v2 message type profiles, a configurable de-identification rule engine, per-organization API keys, and a TypeScript CLI with 18 commands. Four distinct dashboard scopes serve platform administrators, HIE network operators, member facility staff, and patients — each with isolated access controls managed through Clerk.

Health Information Exchanges aggregate clinical data from dozens or hundreds of member facilities, but that data arrives in formats — HL7 v2, CDA/CCDA — that are operationally locked inside source systems. Converting those formats to FHIR R4 or OMOP CDM requires custom parsers for many message types, crosswalks against millions of vocabulary concepts, HIPAA-compliant data segregation, and audit-ready access controls. Most HIEs do not have the engineering capacity to build or maintain that infrastructure.

Existing ETL vendors tend to offer proprietary intermediate formats, limited vocabulary fidelity, or single-tenant deployments that do not fit the multi-member structure of an HIE network. The result is that research-grade, interoperable data products remain out of reach for most regional exchanges — not because the underlying data does not exist, but because the transformation layer is too expensive to build and too fragile to operate.

• HL7 v2 and CDA/CCDA ingestion: Parses 16 validated message type profiles (ADT, ORU, ORM, MDM, RDE, SIU, VXU, DFT) and CDA/CCDA XML documents from member facility uploads or direct feeds.
• FHIR R4 bundle generation: Maps parsed clinical data to standard FHIR resources — Patient, Observation, Condition, MedicationRequest, AllergyIntolerance — validated against the production FHIR validator.
• OMOP CDM 5.4 transformation: Converts FHIR bundles to OMOP tables (person, measurement, condition_occurrence, drug_exposure, visit_occurrence) with Athena vocabulary resolution across 6.3 million concepts.
• HIPAA-compliant PHI isolation: Dual Cloud SQL architecture keeps all clinical content in a dedicated PHI instance; the platform operational database contains zero PHI fields by design and by enforced schema annotation.
• Multi-tenant network management: Separate dashboard scopes for HIE operators, member facilities, clinical researchers, and patients — each with role-scoped access, audit logging, and per-organization API keys.
• On-premise and air-gapped deployment: Pipeline workers ship as Docker images deployable on GKE or inside facility networks without external connectivity requirements.

Federal interoperability mandates and the expansion of TEFCA have increased pressure on HIEs to deliver standardized data products to public health agencies and research institutions. At the same time, the research community has converged on OMOP CDM as the common data model for multi-site clinical studies, creating direct demand for OMOP-conformant exports that most HIEs cannot currently produce.

The combination of regulatory pressure, research demand, and the engineering gap at most regional exchanges defines a clear and immediate market. Currently is built specifically for that gap — not as a general-purpose ETL tool, but as infrastructure designed around the HL7-to-FHIR-to-OMOP transformation chain that HIEs need to run reliably, at scale, and in compliance.