Look at your DSRIP project plan. Find the metrics you haven't moved the needle on in two years. If a metric has a 98% compliance rate (floor) or a 2% rate (irrelevant), stop collecting it at full frequency. Move it to a quarterly sample, not a monthly census.
Write specific code to strip out non-Medicaid patients at the point of ingestion , not at the point of reporting. Use a lightweight ETL (Extract, Transform, Load) process that drops irrelevant records before they ever hit your analytics server. The Bottom Line DSRIP was never meant to be a permanent state of chaos. It is a reform program. But reform requires agility.
The “Bloat” in DSRIP: When Value-Based Care Metrics Get Too Heavy to Lift bloat dsrip
Stop joining five tables. Pick one system as your master patient index for DSRIP. If your EHR is the source for clinical measures, do not let the billing system override it. Bloat happens when two systems argue. Pick a winner.
But recently, a new term has crept into the lexicon of Medicaid transformation: Look at your DSRIP project plan
To satisfy DSRIP, you need to pull claims data, EHR data, and social determinant (SDOH) data. The bloat happens in the middleware . Your interface engines are processing millions of duplicate ADT messages just to confirm a patient is still "attributed" to your PCP. This bloat slows down real-time dashboards to a crawl, making your November report look like it was written in July.
As states transition from traditional fee-for-service to Value-Based Payments (VBP), DSRIP has been a critical bridge. But for many organizations, the very mechanism designed to reward innovation is now drowning in redundant metrics, legacy reporting, and “just in case” data collection. Move it to a quarterly sample, not a monthly census
Why your DSRIP dashboard feels sluggish and how to fix the data weight problem.