I worked on the backend data layer for Cylinder Health - a specialized GI care platform that has now helped over 145,000 patients manage digestive conditions through clinician-backed, personalized care plans.

My piece of the stack: the clinical records layer and the EHR ingestion pipeline.

━━━ What "FHIR-compliant" actually means when you build it ━━━

FHIR (Fast Healthcare Interoperability Resources) is the standard that lets healthcare systems talk to each other. In theory it's clean. In practice, every EHR vendor - Epic, Athena, Cerner - sends you data in their own dialect of FHIR, with custom extensions, missing fields, and inconsistent date formats.

So the ingestion pipeline wasn't just "normalize JSON into Postgres." It was:

→ Model the core FHIR resources correctly: Patient, Observation, Condition, CarePlan - each with the right cardinality and relationships

→ Write normalization logic that could handle what real EHRs actually send, not what the spec says they should send

→ Output a PostgreSQL schema queryable by both the application layer (fast, indexed, relational) and the clinical team (human-readable, auditable, filterable by condition/patient/date)

━━━ Why this matters beyond healthcare ━━━

Any platform where multiple data sources feed a single operational layer - fintech aggregators, multi-ERP SaaS, IoT pipelines - hits the same problem: you don't control the upstream data quality, but downstream users expect consistency.

The FHIR normalization pattern translates directly.

Building something in healthtech, or dealing with messy multi-source data ingestion? Happy to talk through the architecture.