.png)
Pillow Pharmahealth (Pillowᴾᴴ) processes claims, eligibility, and pharmacy data from a nationwide network of ~70,000 pharmacies. The work depends on strict PHI handling, consistent master data, and predictable reporting used for billing and benefit-plan updates.
Before MEV’s involvement, data movement relied on manual steps, inconsistent partner feeds, and a legacy setup that made it difficult to scale.
MEV built an AWS-based platform that ingests multiple healthcare data feeds, aligns ~600-field objects, resolves entities, and generates scheduled reporting through a microservices structure. Several years later, the same system supported a PBM vendor transition using encrypted feeds without disrupting active operations.
This article outlines how the platform was assembled, how it ran over several years, and what other regulated data environments can take from the experience.
Business Drivers, Initial Objectives, and Early Constraints
Pillowᴾᴴ needed a platform that could absorb large volumes of heterogeneous healthcare data, merge it into consistent entities, and maintain regulatory alignment throughout the processing lifecycle. Several factors defined the initial design approach:
- Claims, eligibility, pharmacy, and MediSpan data needed to be combined in one environment to replace manual aggregation.
- The system had to keep up with continuous inputs from ~70,000 pharmacies performing real-time checks.
- Early workflows used sequential loading and mock datasets; automation had to be introduced gradually.
- HIPAA obligations applied to storage, ingestion paths, transformation steps, and all reporting routines.
- Each data domain followed its own structure and cadence, requiring coordinated normalization.
- Incoming inputs often carried ~600 fields and arrived in variable formats, which required flexible mapping logic.
- Entity-resolution rules were needed to produce unified records for downstream reporting.
- PBM and EHR integrations needed predictable access patterns.
- The legacy setup lacked components that would allow new partners or data sources to be onboarded efficiently.
These constraints shaped both the platform's structure and its development sequence.
System Architecture and Platform Design
The system was built around clear separation of ingestion, transformation, storage, and reporting. Each layer evolved independently, which later helped during partner expansion and the PBM feed transition.
Key Shifts in Data Operations
As automation replaced manual routines, the system shifted in several important ways.
Shift 1 — Manual Routines → Automated Pipelines
Operator-triggered imports gave way to scheduled ingestion that pulled new claims, eligibility, pharmacy, and MediSpan feeds as they arrived. Transformation and merging ran without operator involvement, removing sequencing delays.
Shift 2 — Independent Inputs → Coordinated Flow
Claims, eligibility, and pharmacy feeds follow different cadences. A coordination layer routed each input to the correct path and prevented domain-specific timing differences from affecting unified records.
Shift 3 — Ad-Hoc Fixes → Structured Verification
Validation steps checked structure, field completeness, and domain rules. Automated retries handled partial or late files, strengthening data quality for reporting and billing tasks.
PBM Vendor Transition: Technical and Operational Scope
Years after launch, Pillowᴾᴴ needed to add a new encrypted PBM feed on a strict timeline while keeping the existing system active. The work required a controlled way to integrate the new source without modifying the database schema or interrupting reporting.
Infrastructure Review and Modernization Planning
The PBM migration exposed several infrastructure friction points—not because the system was failing, but because it had been running on the same setup for years. Three areas stood out:
1. Version Drift Across Core Components
ArgoCD, ALB Ingress, and EKS were several major versions behind. They still functioned, but the gap limited safe upgrade paths and made controlled rollouts harder when processing PHI-heavy ETL workloads.
2. Pipeline Growth Outpaced the Original Cluster Envelope
The platform now handled more data domains and more partner-specific variations than the cluster was originally tuned for. Stable processing depended increasingly on predictable partner data rather than infrastructure flexibility.
3. PHI Requirements Restricted the Upgrade Window
HIPAA requirements limited where, when, and how updates could occur. Encryption compatibility, key-management handling, and controlled rollout steps reduced the number of safe modernization sequences.
Multi-Year Operational Management
The platform continued running for several years as partners changed formats, expanded their data feeds, and introduced new requirements. Long-term stability came from ongoing work in three areas:
- Keeping ingestion and transformation rules aligned with evolving partner inputs.
- Monitoring data behavior—timing, throughput, and batch patterns—to catch upstream irregularities early.
- Adjusting mappings, schedules, and output rules to support new partners without interrupting daily reporting.
This approach allowed the system to stay dependable despite partner and feed variability.
Key Takeaways for Regulated Data Platforms
The Pillowᴾᴴ project demonstrates that multi-feed healthcare platforms remain stable over time when fast-changing external inputs are isolated from the workloads that must remain predictable.Teams working in regulated environments often catch issues faster by watching how partner data behaves than by watching infrastructure metrics.
The PBM migration highlighted the importance of controlled integration paths where encryption differences and schema constraints can be tested in a safe environment before cutover.
The infrastructure review reinforced that version drift may not cause immediate outages, but it reduces a platform’s ability to absorb future changes.
.png)
