James Bryan — posts

Why Your EZ-CAP Database Is Slow (And It's Not Because You Need More Indexes)

2025-11-16T00:00:00.000Z

Every database analyst has heard this mantra: "Slow query? Add an index." But what if I told you that removing indexes—not adding them—improved one of my production ETL processes by 40%? Here's what 15 years of healthcare database work taught me about the hidden costs of over-indexing.

The Problem Nobody Talks About

When a query runs slowly, the first instinct is always to add an index. And yes, proper indexing is critical for read performance. But here's what many database analysts miss: every index you add creates maintenance overhead.

In EZ-CAP systems handling claims data, submissions data, and member information, we're constantly writing to tables. Every INSERT, UPDATE, and DELETE doesn't just modify the table—it has to update every index on that table too.

The reality: More indexes = faster SELECT queries but slower INSERT/UPDATE/DELETE operations. In ETL-heavy healthcare environments, this trade-off often works against you.

The Wake-Up Call: A Real Production Example

I was working with a health plan's claims processing database. Their nightly ETL jobs were taking progressively longer—what started as a 2-hour process had stretched to over 3 hours. The data team had been adding indexes every time someone complained about a slow report, and now the main claims table had 47 indexes.

Yes, 47.

The symptoms were classic over-indexing:

ETL processes taking longer despite no increase in data volume
Transaction log growing faster than expected
Increased CPU usage during data loads
Complaints about "the database being slow" from multiple departments

Finding the Culprits: Identifying Unused Indexes

SQL Server tracks index usage through DMVs (Dynamic Management Views). Here's the query I use to identify indexes that are costing more than they're worth:

-- Find indexes with high writes but low reads
SELECT
    OBJECT_NAME(s.object_id) AS TableName,
    i.name AS IndexName,
    i.type_desc AS IndexType,
    s.user_seeks,
    s.user_scans,
    s.user_lookups,
    s.user_updates,
    s.user_updates - (s.user_seeks + s.user_scans + s.user_lookups) AS WriteToReadRatio
FROM sys.dm_db_index_usage_stats s
INNER JOIN sys.indexes i
    ON s.object_id = i.object_id
    AND s.index_id = i.index_id
WHERE OBJECTPROPERTY(s.object_id, 'IsUserTable') = 1
    AND s.database_id = DB_ID()
    AND i.type_desc != 'HEAP'
ORDER BY s.user_updates DESC;

This query reveals indexes that are being updated constantly but rarely used for queries. In the claims table I mentioned, we found:

12 indexes that had never been used for any query since the last server restart
8 indexes with a write-to-read ratio above 100:1 (being updated 100+ times for every query that used them)
Multiple redundant indexes covering nearly identical columns

The Fix: Strategic Index Removal

I didn't just drop indexes randomly. Here was my process:

Step 1: Document Everything

Before touching anything, I scripted out all existing indexes. This gave us a rollback plan if needed.

-- Script out all indexes before making changes
SELECT
    'CREATE ' + CASE WHEN i.is_unique = 1 THEN 'UNIQUE ' ELSE '' END +
    i.type_desc + ' INDEX [' + i.name + '] ON [' +
    SCHEMA_NAME(t.schema_id) + '].[' + t.name + '] (' +
    STUFF((SELECT ', [' + c.name + ']' +
        CASE WHEN ic.is_descending_key = 1 THEN ' DESC' ELSE ' ASC' END
        FROM sys.index_columns ic
        INNER JOIN sys.columns c ON ic.object_id = c.object_id
            AND ic.column_id = c.column_id
        WHERE ic.object_id = i.object_id AND ic.index_id = i.index_id
        ORDER BY ic.key_ordinal
        FOR XML PATH('')), 1, 2, '') + ');' AS CreateIndexScript
FROM sys.indexes i
INNER JOIN sys.tables t ON i.object_id = t.object_id
WHERE i.type > 0  -- Exclude heaps
    AND t.name = 'YourTableName';

Step 2: Start with Clear Wins

We removed indexes that were:

Never used (0 seeks, 0 scans, 0 lookups)
Completely redundant (exact duplicates)
Clearly abandoned (old date range filters no longer relevant)

Step 3: Test Before Full Rollout

Each removal was tested in our staging environment first, monitoring query performance and ETL execution times.

⚠️ Critical Note: Don't drop indexes in production without testing. Some indexes might be used by poorly-documented stored procedures or third-party reporting tools. Always check execution plans and monitor for a few days in lower environments first.

The Results

40% faster ETL processing — the nightly claims load dropped from 3+ hours back to under 2 hours.

After removing 23 unused or redundant indexes, here's what improved:

ETL performance: 40% reduction in processing time
Transaction log: 25% less log file growth
Storage: 15GB freed up (indexes consume space too)
CPU usage: Noticeably lower during peak data loading times

And here's the kicker: no queries got slower. Not one. Because we were removing indexes that weren't being used anyway.

When Over-Indexing Happens

How did this health plan end up with 47 indexes? It's surprisingly common in healthcare IT environments:

"Just in case" indexing: Someone creates an index for a one-time report, then never removes it
Panic indexing: A critical report is slow, so an index gets added without analyzing if it's actually needed
Legacy accumulation: EZ-CAP implementations evolve over years, and nobody ever audits old indexes
Vendor recommendations: Implementation guides suggest indexes that may not fit your specific workload
Copy-paste solutions: Indexes are copied from another environment without understanding the differences in query patterns

Best Practices for Index Management

Here's how I approach indexing now, particularly for write-heavy EZ-CAP tables:

1. Start Conservative

Begin with minimal indexes (primary keys and critical foreign keys). Add more only when you have evidence they're needed.

2. Regular Index Audits

Schedule quarterly reviews of index usage. I set calendar reminders to run usage queries and identify candidates for removal.

3. Document Index Purpose

When creating an index, include a comment explaining WHY it exists:

-- Index created for monthly HEDIS reporting queries
-- Used by sp_GetMemberUtilization stored procedure
-- Review if report is ever deprecated
CREATE NONCLUSTERED INDEX IX_Claims_MemberDate
    ON Claims(MemberID, ServiceDate);

4. Monitor Write vs. Read Ratios

If an index has a write-to-read ratio above 10:1, it's worth investigating whether it's providing enough value.

5. Consider Filtered Indexes

Instead of indexing an entire table, use filtered indexes for specific subsets of data that are frequently queried:

-- Only index active claims, not the entire historical table
CREATE NONCLUSTERED INDEX IX_Claims_ActiveOnly
    ON Claims(ClaimID, MemberID)
    WHERE ClaimStatus = 'Active';

Red Flags Your Database Might Be Over-Indexed

Watch for these warning signs:

ETL jobs taking progressively longer despite stable data volumes
High transaction log growth during data loads
Increased CPU during INSERT/UPDATE operations
More than 10-15 indexes on heavily-written tables
Index names like "IX_temp" or "IX_test" still in production
Multiple indexes with very similar column combinations

The Balance

To be clear: I'm not anti-index. Proper indexing is essential for query performance. But like any tool, indexes need to be used strategically.

In healthcare databases like EZ-CAP systems, where you're constantly processing claims submissions, eligibility updates, and encounter data, the write volume is often higher than in pure reporting databases. Every index you add slows down those write operations.

The principle: Index for the workload you have, not the workload you imagine you might have someday. And regularly audit to remove indexes that aren't earning their keep.

Practical Takeaways

If your EZ-CAP database or healthcare data warehouse feels sluggish:

Run the index usage query above to identify unused indexes
Document what you find—you'll need this for rollback if necessary
Start with clear wins: remove indexes with zero usage
Test in staging before touching production
Monitor performance after changes
Schedule regular audits going forward

In my experience, most production databases have at least 10-20% of their indexes doing more harm than good. Finding and removing them isn't just about reclaiming storage—it's about letting your database breathe during those critical ETL windows.

Sometimes the best optimization isn't adding something new. It's removing what you never needed in the first place.

What 15 Years as an EZ-CAP Specialist Taught Me About Healthcare Data Integration

2025-11-08T00:00:00.000Z

When a Claims Director tells you their monthly submission is "wrong," they're not just pointing out a data issue—they're highlighting a potential compliance risk that could cost the organization millions.

After 15 years working with EZ-CAP systems across multiple healthcare organizations—from supporting clients who use it, to working directly for healthcare plans, to managing the backend infrastructure—I've learned that successful data integration isn't really about the technology. It's about understanding what the data means to each stakeholder.

Here are four lessons that fundamentally changed how I approach healthcare IT:

Lesson 1: The Real Integration Challenge Isn't Technical—It's Translational

The hardest part of integrating EZ-CAP with third-party systems like PCG, DataWing, or Cozeva isn't writing the SQL queries or mapping the data fields. It's sitting in a room with Claims, Finance, and UM teams who all use different language to describe the same data.

Claims talks about submission timelines and encounter data. Finance wants reconciliation and capitation tracking. UM needs utilization patterns and authorization workflows. They're all looking at the same database, but they need different stories told in different ways.

I've spent countless hours serving as a translator between technical teams and business stakeholders—including offshore development groups who brought their own communication challenges. The ability to break down complex technical concepts into clear, accessible explanations isn't just a nice-to-have skill. In healthcare IT, it's essential.

The lesson: Your job isn't just to move data—it's to ensure everyone understands what that data is telling them, in the language they speak.

Lesson 2: Documentation Is Your Integration Insurance Policy

Early in my career, I built plenty of "quick fixes" that worked perfectly... until the person who requested them left the organization. Then suddenly, no one knew why that specific trigger existed, what business rule it was enforcing, or what would break if we removed it.

Now, I approach every integration with the assumption that I won't be there to explain it. That means:

Detailed process flows — I swear by Microsoft Visio for creating visual documentation that both technical and non-technical stakeholders can understand
Commented SQL code that explains the why, not just the what — future developers need to understand the business logic, not just the syntax
Clear handoff documentation for vendor coordination — when you're managing integrations with multiple third parties, everyone needs to know who owns what
Standard operating procedures that capture tribal knowledge before it walks out the door

My graphic design background actually became a competitive advantage here. Good documentation isn't just accurate—it's visually clear and easy to follow.

The lesson: If you can't document it clearly enough for someone else to maintain it, you haven't finished the job.

Lesson 3: HEDIS Measures Taught Me That "Close Enough" Doesn't Exist

There's no room for "approximately correct" when you're submitting HEDIS data. A decimal point in the wrong place, a date range off by one day, or a misunderstood exclusion criterion can invalidate months of work and directly impact Star Ratings—which affects funding, reputation, and member access to benefits.

Working on monthly and quarterly HEDIS submissions taught me to build validation into every step of the process:

Automated checks that flag anomalies before they become problems
Reconciliation queries that verify data integrity at each stage
Secondary review processes that catch what automation might miss
Clear audit trails that document every transformation

I've learned to treat every data point with the respect it deserves, because in healthcare, data isn't abstract—it represents real patients, real providers, and real compliance obligations.

The lesson: In regulated healthcare environments, precision isn't perfectionism—it's professional responsibility.

Lesson 4: The Best Integrations Make Themselves Invisible

When I design automated SQL jobs or custom data loads, success means nobody notices they're running. The Claims team gets their reports on time. Finance sees accurate reconciliation. UM has the utilization data they need for decision-making. Data flows seamlessly from EZ-CAP to third-party applications and back.

The moment an integration becomes visible is usually when something's gone wrong—a job fails, data doesn't match, or a vendor connection drops.

Over the years, I've designed and scheduled countless SQL jobs that automate repetitive tasks, optimize workflows, and enhance data management processes. The goal is always the same: create systems that work reliably in the background, freeing people to focus on using the data rather than chasing it.

The lesson: Great healthcare IT infrastructure should fade into the background, reliably supporting the organization's mission without requiring constant attention.

Looking Forward

Healthcare data integration is becoming more complex, not less. More vendors, more regulatory requirements, more data sources to coordinate, and increasing expectations for real-time data access.

But the fundamentals haven't changed:

Understand your stakeholders and speak their language
Document everything as if you won't be there to explain it
Prioritize accuracy and compliance over speed
Build systems that work quietly and reliably

As someone who's been called the "go-to resource" for EZ-CAP-related queries, technical guidance, and troubleshooting, I've seen firsthand how these principles create value. The best technical solutions are the ones that enable healthcare organizations to focus on their real mission: serving patients and members.