Building a scalable, HIPAA-aware data pipeline at the intersection of senior care and nutrition
Case Study | Data Engineering | Senior Living | Healthcare Analytics
The "Silver Tsunami" of baby boomers entering their 80s presents unique challenges for analytics practitioners, particularly in the senior care industry. More than almost any other sector, senior care demands scalable data architecture built from loosely coupled components — because the volume of patients, complexity of their needs, and regulatory scrutiny only keep growing.
One fast-growing segment within senior care is medically tailored meals (MTM). Seniors often carry multiple co-morbidities or chronic illnesses, requiring meals tailored to their specific medical needs. MTMs provide a convenient, affordable alternative to medication-only management of chronic disease — and offer insurers a real opportunity to reduce hospital visits and long-term costs.
The Challenge
For a company like Heritage Meals operating in the MTM sector, the data engineering problem is essentially this: how do you connect patient health data with operational delivery data and translate it into actionable insights — without compromising PHI security, blowing up your storage budget, or building something that can't scale?
The data lives across multiple disconnected systems:
- Electronic Health Records (EHR) — diagnoses, medications, dietary restrictions, clinical outcomes
- CRM / Patient Care systems — intake, referrals, discharge planning, patient feedback
- Meal Management systems — meal plans, special diet tracking, kitchen load, delivery routing
None of these talk to each other by default. And in a thin-margin food business serving a medically vulnerable population, bad data isn't just an analytics problem — it's a patient safety problem.
The Solution: A Five-Stage Data Pipeline
The architecture I proposed for Heritage Meals follows a classic modern data stack pattern, adapted for the specific constraints of the MTM space: HIPAA compliance, cost sensitivity, and the need to serve both clinical and operational audiences.
Stage 1: Generate
Data originates from three primary source systems: Patient Records (EHR), Meal Management, and Patient Care (CRM). Each operates independently, on its own schedule, and with its own data model. The engineering challenge starts here — getting clean, timely extracts out of systems that weren't designed with analytics in mind.
Stage 2: Ingest
Raw data lands in a Raw Lake via two ingestion paths:
- API Gateway for systems that support real-time or near-real-time integration (typically EHR and CRM platforms)
- Secure FTP for batch file transfers from legacy or less API-friendly systems
Tools like Fivetran or Estuary handle the heavy lifting here — managed connectors that abstract away the complexity of each source system and handle incremental loads reliably. The Raw Lake is append-only and untransformed, providing a full audit trail of everything that came in.
Stage 3: Transform
This is where the real engineering work happens, in three sequential steps:
PHI Security — Before anything else, protected health information is flagged, masked, or encrypted according to HIPAA requirements. This is a non-negotiable first step; no downstream process ever touches raw PHI.
Cleaning — Unstructured and semi-structured data is normalized into columnar formats suitable for SQL. Duplicate records are resolved, date formats are standardized, and referential integrity between patient, meal, and delivery records is enforced.
Modeling — Analytics engineering tools like dbt define the business logic: how a "compliant meal delivery" is defined, how diet adherence is calculated, how patients are attributed to care partners. This layer is version-controlled and tested, making it auditable and maintainable.
The output lands in a Warehouse (Snowflake, BigQuery, or similar) — the single source of truth for all downstream analytics.
Stage 4: Serve
From the warehouse, data is shaped for its audience:
- Data Marts — purpose-built views for specific business functions (clinical outcomes, kitchen operations, delivery logistics)
- Metadata layer — data catalog and lineage documentation so users know what they're looking at
- Analytics API — for reverse ETL back into operational systems, closing the loop between insights and action
Stage 5: Analyze
The final layer is where data becomes decisions — dashboards for executive leadership, operational reporting for management, and data feeds for third-party partners or payers. The north star throughout the entire pipeline is this step: if the insight isn't actionable, the pipeline hasn't done its job.
What the Output Looks Like
Here's a mock-up of the executive dashboard built for Heritage Meals, pulling from the data marts described above.
A few things worth noting about the design:
- Active Patients, Meals Delivered, and Compliance Rate are the three headline KPIs — chosen because they reflect clinical outcomes (compliance), operational throughput (meals), and program health (census) in a single view
- Compliance Trend tracks diet adherence over time, giving leadership early warning of degradation before it shows up in clinical outcomes
- Meal Distribution breaks volume by diet type (Regular, Diabetes, Low-Sodium, Renal) — directly tied to kitchen planning and procurement
- Priority Alerts surface operationally urgent items that require human action today: dietary plan updates, low inventory, delivery route issues
The dashboard is intentionally lean. MTM operators don't need 40 metrics — they need the five that tell them whether patients are being served safely and whether the business is running efficiently.
Key Design Principles
Regulatory compliance is the foundation, not an afterthought. PHI security is the first transformation step — not a checkbox at the end. Every architectural decision gets evaluated through the lens of HIPAA before anything else.
Cost discipline matters in thin-margin businesses. Storage costs in the Raw Lake are managed carefully. Data that doesn't drive decisions doesn't get warehoused indefinitely. Columnar storage formats and aggressive partitioning keep query costs low.
Loose coupling is a strategic choice. With baby boomer volumes continuing to grow, any component of this pipeline needs to be replaceable without taking down the whole system. Swapping a meal management vendor or adding a new EHR integration shouldn't require a rebuild.
The pipeline exists to serve the dashboard, not the other way around. Every modeling decision traces back to a business question someone needs answered. If we can't name the decision the data will inform, it doesn't get built.
If your organization is working through data infrastructure challenges in senior living, home health, or medically tailored meals, I'd be glad to talk. Reach out at hello@terlina.com.