From Medicaid Claims Code to Enterprise Data Warehouse: How Vikram Reddy Built Healthcare Data Management from Both Sides

I was three years into writing C# code for Florida's Medicaid claims system when I realized something that changed the direction of my career.

Every reporting team pulling data from my application was producing different numbers for the same patients. The claims team had one count. The compliance team had another. The finance team had a third. All pulling from systems I had helped build. None of them wrong, exactly. But none of them agreeing.

The problem wasn't in the application. The problem was that patient data lived in five different systems — SQL Server databases, third-party APIs, a CRM platform, an ERP system, and flat files from state agencies — and nobody had built the layer that makes them talk to each other.

Three years later, I was the one building that layer. Same system. Different company. Completely different side of the stack.

I spent seven years inside FLMMIS — the Florida Medicaid Management Information System — serving 5 million beneficiaries. First as a .NET developer at Hewlett Packard Enterprise, writing the code that processes claims, eligibility, and provider enrollment. Then as a data analyst at DXC Technology, designing the enterprise data warehouse and ETL pipelines that turn that raw data into compliance reports and executive dashboards.

Most data professionals see one side. I built both.

This is what healthcare data management actually looks like from the inside — the integration nightmares, the architectural decisions, and the mistakes I've watched break projects across healthcare and insurance.

Expert Insight by

Vikram Reddy

Data Analyst / Power BI Developer at AIG Insurance

Healthcare & Insurance Data AnalyticsLinkedIn

Vikram Reddy has 8+ years of experience designing enterprise data systems across healthcare and insurance. He spent 7 years inside the Florida Medicaid Management Information System (FLMMIS) — first as a .NET developer at Hewlett Packard Enterprise building claims processing applications, then as a data analyst at DXC Technology designing the star schema data warehouse and ETL pipelines that power Medicaid reporting for 5M+ beneficiaries. He now leads Power BI development and data integration at AIG Insurance, where he unified SQL Server, SAP BW, Oracle, and Azure SQL into centralized enterprise analytics and improved reporting performance by 40% through data model restructuring.

Verified Expert

FLMMIS — the Florida Medicaid Management Information System — is one of the largest state-level healthcare data systems in America. It handles eligibility determination, claims adjudication, provider enrollment, and reporting for over 5 million Medicaid beneficiaries. Every doctor visit, every prescription fill, every hospital admission for a Medicaid patient in Florida flows through this system.

I spent seven years inside it. Not as a consultant passing through. Not as a vendor running demos. As someone who wrote the code and then designed the data architecture.

Chapter 1: Building the Machine (HPE, 2016–2019)

At Hewlett Packard Enterprise, I was a .NET developer on the FLMMIS platform. ASP.NET MVC applications. C# business logic. RESTful Web APIs handling claims processing and provider enrollment. Entity Framework talking to SQL Server on the backend. Stored procedures, triggers, performance-tuned views — the full stack that makes a Medicaid claims system run.

What I didn't fully understand at the time was where the data went after my application created it.

I'd write code that validated a claim, applied business rules, and committed the result to SQL Server. Job done. But downstream, five different teams were pulling that data into five different reporting systems, applying five different transformation rules, and producing five different versions of the truth.

The data wasn't wrong. It was fragmented. And fragmentation in healthcare data doesn't just mean inconsistent dashboards — it means compliance reports that regulators question.

Chapter 2: Building the Brain (DXC, 2020–2023)

When I joined DXC Technology in 2020, I switched from building the application to building the analytics layer for the same FLMMIS ecosystem. Now I was on the receiving end of the data my previous code had generated.

The difference was immediate. I could look at a claims table and understand not just what the columns meant, but how the application populated them, which business rules affected which fields, and where the edge cases lived. Most data analysts inherit a schema and read the documentation. I had written the business logic that created the schema.

That dual perspective shaped how I designed the data warehouse. I built star schema dimensional models with conformed dimensions and scalable fact tables, using Informatica PowerCenter and SSIS for ETL orchestration against a Teradata backend. The warehouse had to ingest from SQL Server, third-party APIs, CRM and ERP systems, and state-agency flat files.

The result was a unified data layer that powered SSRS dashboards for Medicaid analytics, compliance reporting, and stakeholder visibility. One version of the truth, not five.

Job descriptions make healthcare data management sound clean: "integrate clinical and administrative data sources to support reporting and analytics." Twelve words. Twelve words that skip over the hardest parts.

Here's what it actually means when you're staring at five source systems in a Medicaid context:

Healthcare data management means taking data that was designed to support individual applications — a claims processing system, a provider enrollment portal, an eligibility determination engine — and making it behave as if it were designed for analytics. It wasn't. It was designed for transactions.

Transaction systems and analytics systems want completely different things. A claims processing application wants normalized tables, referential integrity, and fast single-record lookups. An analytics dashboard wants denormalized star schemas, pre-aggregated measures, and fast scans across millions of rows. You cannot serve both from the same schema.

The gap between what job descriptions say and what the work looks like is enormous. Nobody tells you that the "integration" part means spending weeks reconciling how "Provider" is defined across five systems. Nobody mentions that the "reporting" part means building SSRS dashboards that regulators will scrutinize line by line. Nobody warns you that the "data quality" part means building validation gates into your ETL pipeline because one bad date format from a flat file can cascade into a compliance violation.

The Medicaid data warehouse at DXC had to ingest from five source categories: SQL Server databases running the core claims application, third-party APIs from state agencies, a CRM system for provider relationships, an ERP system for financial data, and flat files from external entities.

Each source had its own schema. Its own update frequency. Its own definition of every entity.

The worst offender was "Provider."

Five systems, five definitions of "Provider," and every one of them was correct within its own context. The problem was that a compliance report might need to show "claims by provider" — and the answer depends entirely on which definition of "provider" you use.

Building that conformed dimension took weeks. Mapping NPI to internal codes to TINs to DEA numbers to legacy state codes required cross-referencing five lookup tables, handling many-to-many relationships (one NPI can map to multiple TINs), and building exception-handling logic for records that didn't match anything.

The Day the Date Format Broke Everything

ETL pipelines are fragile. Not because the tools are bad — SSIS and Informatica PowerCenter are robust platforms. They're fragile because they depend on source systems behaving consistently. And source systems don't always cooperate.

We caught it the next morning when the compliance dashboard showed zero claims for the previous day. Zero. The ETL pipeline didn't fail — it successfully loaded corrupted data. That's worse than a failure, because a failure triggers an alert. Silent corruption triggers nothing until someone looks at the output.

After that, I built validation gates into every ETL pipeline. Before any data moves from staging to the warehouse, automated checks verify format consistency, null rates, referential integrity, and value range constraints. If any check fails, the pipeline stops and sends an alert. The data stays in staging until a human investigates.

When I joined AIG Insurance in 2024, one of the first problems I inherited was reporting performance. Executives were waiting minutes for Excel reports to refresh from Power BI datasets. The IT team had already scoped a server upgrade. New hardware, more RAM, faster storage. The estimate was six figures.

I asked to look at the Power BI data model first.

What I found was a model with dozens of table relationships, many of them unnecessary. Tables that should have been star-schema dimensions were connected in circular patterns. Measures that should have been calculated at the fact-table level were computed at query time across multiple joins. The model was doing ten times more work than it needed to for every single report refresh.

The fix wasn't hardware. It was architecture.

I restructured the backend Power BI data model. Removed circular relationships. Collapsed redundant lookup tables into proper star-schema dimensions. Moved expensive calculations from query-time DAX to pre-computed columns where appropriate. Re-indexed the underlying SQL Server views.

Reports ran 40% faster. No server upgrade. No new hardware. The same data, the same reports, the same Power BI Service deployment — just a model that stopped fighting itself.

At AIG, I also integrated SQL Server, SAP BW, Oracle, and Azure SQL into one centralized enterprise BI platform. Four different database engines, four different query languages, four different data models — all feeding into Power BI dashboards that executives treat as a single source of truth. The integration pattern was the same one I'd learned at DXC: conformed dimensions, star schema design, ETL pipelines that validate before they load.

When I designed the Medicaid data warehouse at DXC, the first architectural decision was schema design. Star schema or snowflake. It's the kind of decision that sounds academic until you're sitting in front of a Teradata instance that needs to process millions of Medicaid claims records and produce compliance reports before the morning shift starts.

I chose star schema for Medicaid. The reasoning was specific, not theoretical:

The exception at AIG was provider hierarchies. Insurance providers have complex organizational structures: individual practitioners belong to group practices, which belong to networks, which belong to regional organizations. That kind of deeply hierarchical data is where snowflake schema actually earns its complexity — each level of the hierarchy is a separate normalized table, allowing drill-down queries without storing every combination.

In practice, most healthcare data warehouses use both. Star schema for the core fact tables (claims, encounters, prescriptions). Snowflake extensions for hierarchical dimensions (provider, facility, organizational structure). The mistake is treating it as an either/or decision.

Nobody writes LinkedIn posts about SSIS packages. Nobody gives conference talks about Teradata FastLoad vs MultiLoad trade-offs. Nobody gets excited about Informatica PowerCenter mappings.

But these are the tools that keep healthcare data moving. Every Medicaid compliance report, every executive dashboard, every claims analysis depends on ETL pipelines that run overnight and load data before the first analyst logs in.

FastLoad vs MultiLoad: The Monday Morning Problem

On the Medicaid data warehouse, we used Teradata as the backend. Loading millions of records nightly required choosing between two utilities: FastLoad and MultiLoad. Both move data from source to target. They are not interchangeable.

FastLoad is faster. It bypasses the transactional log, streams data directly to the Access Module Processor, and can load millions of rows in minutes. The trade-off: it only works on empty tables. No updates. No upserts. No existing rows.

MultiLoad handles updates and mixed operations. It can insert, update, delete, and upsert. The trade-off: it's slower, and it has overhead for error handling and transaction management.

Pick the wrong one and the consequences are concrete. Use FastLoad on a table that has existing records, and the load fails. Use MultiLoad on a large initial load, and the batch window runs long. If your ETL batch window ends at 6 AM and the load finishes at 7 AM, your Monday morning compliance reports run on Saturday's data.

SQL Profiler: Finding the Query That Ate 60% of ETL Time

At DXC, the Medicaid ETL pipeline was running close to its batch window limit. Not failing — just taking longer each month as data volume grew. I used SQL Profiler to trace every query in the pipeline and found a single stored procedure that consumed over 60% of total processing time. The procedure was doing a full table scan on a fact table with no index on the join column. Adding the right index dropped that procedure's runtime from 45 minutes to under 3. The entire pipeline gained back an hour of headroom.

Performance tuning is not glamorous. But that one index change is the reason the compliance team had fresh data on Monday mornings for the next two years.

The Shift to Azure Databricks

At AIG, the ETL paradigm is evolving. Azure Databricks processes high-volume datasets using distributed Spark clusters. IBM DataStage handles large-scale healthcare dataset transformations. The traditional SSIS packages still run, optimized with checkpoints and event handling for reliability.

The cloud isn't replacing on-premise ETL everywhere. It's supplementing it. Many healthcare organizations run hybrid stacks: SSIS for internal SQL Server pipelines, Informatica for cross-platform integration, and Databricks for the workloads that exceed what a single server can handle.

I've seen these across two industries and three employers. Different organizations, different tools, same patterns. Every one of these mistakes turns a solvable architecture problem into a six-figure remediation project.

Mistake 1: Treating the Warehouse as a Data Dump

The fastest way to build a useless data warehouse is to load every table from every source system without dimensional modeling. You end up with a staging area that someone relabeled "data warehouse." The data is all there. Nobody can query it efficiently because there's no star schema, no conformed dimensions, and no fact-to-dimension relationships.

A data warehouse is not a backup of your source systems. It is a dimensional model designed to answer specific business questions fast.

Mistake 2: Building Dashboards Before Fixing the Model

This is the "pretty charts, wrong numbers" trap. A team spends months building Power BI or Tableau dashboards on top of a poorly modeled warehouse. The dashboards look great. The numbers don't reconcile. When someone finally checks, the problem isn't the visualization — it's the data model underneath.

At AIG, the dashboards were fine. The data model behind them had circular relationships that made reports slow and some calculations incorrect. Fixing the model fixed everything downstream.

Mistake 3: Skipping Data Quality Gates in ETL

When the state agency flat file changed its date format, our ETL pipeline didn't fail. It loaded corrupted dates into the warehouse. No alert. No error. Just silent corruption that showed up 12 hours later when a compliance dashboard showed zero claims for an entire day.

After that, every pipeline I build has validation gates between staging and production. Format checks, null rate thresholds, referential integrity verification, value range constraints. If any check fails, the pipeline stops. Bad data stays in staging until a human investigates.

Mistake 4: Ignoring Conformed Dimensions

Five systems. Five definitions of "Provider ID." If you don't reconcile them into one conformed dimension, you get five different answers to the question "how many providers submitted claims last month?" This isn't a theoretical risk. It's what happens in most healthcare organizations that skip the dimensional modeling step.

Conformed dimensions are boring. They take weeks to build. They require mapping tables, cross-referencing multiple identifier systems, and handling edge cases. But they are the only thing that makes cross-system reporting trustworthy.

Mistake 5: Betting on the Tool Instead of the Architecture

"We're evaluating Power BI vs Tableau." I've heard this in every organization I've worked for. It's the wrong conversation. Power BI and Tableau are both excellent tools. Neither one will save a data warehouse that's a pile of denormalized tables with no fact-dimension relationships.