Why Data Foundation Comes Before Dashboards
A dashboard shows a number. A data foundation tells you where the number came from. Without the foundation, you can’t check the figure, explain it to a reviewer or compare it with last quarter’s. So the foundation has to come first.
What makes a reported figure traceable?
A figure is traceable when you can answer four questions about it, in order.
- Which source? The system the data came from: an electronic health record (EHR), a claims feed, a health information exchange (HIE) or a program report.
- Which record? The specific rows or messages that fed the number, so someone can open them and look.
- Which rule? The definition and grouping logic that turned raw records into a count, including who was included and who was left out.
- Which date? Both the period the figure covers and the date the data was last refreshed.
This is provenance. If any of the four is missing, the figure is an assertion. Someone has to take it on trust.
Why do HL7, FHIR and C-CDA still leave data inconsistent?
Standards define the shape of the data, not its meaning. HL7 messages, C-CDA documents and FHIR resources each give systems an agreed way to package and exchange information. They don’t force two organizations to fill the package the same way.
Two systems can both be fully compliant and still differ. One sends a local code where another sends a standard one. One fills an optional field and another leaves it blank. One records a diagnosis on the problem list and another only in a visit note. The exchange works. The data still doesn’t line up.
This is well documented. When researchers collected 91 sample C-CDA documents from 21 certified health IT technologies, they recorded 615 observations of errors and data expression variation (D’Amore et al., JAMIA, 2014). Exchange keeps improving, but it is still uneven: in 2023, 43% of U.S. non-federal acute care hospitals routinely engaged in all four domains of interoperable exchange, and rural hospitals trailed urban ones, 36% to 47% (ONC Data Brief No. 71, 2024).
A common pattern at integration time: the interface passes testing, and the first dashboard still shows odd counts. The cause is often not the pipe. It is what traveled through it.
Why does one condition have so many names?
Take diabetes. Claims carry it as diagnosis codes. An EHR may hold it as a problem-list entry coded in a different vocabulary. A lab result, a prescription or a free-text note can each point to the same person and the same condition without ever using the same word.
Count each source separately and you get different answers. Add them together and you may count one person several times, or miss them entirely. In a study of 173,503 adult patients, different diabetes definitions identified anywhere from 7% to 13% of the same population, and the patient lists they returned overlapped by only 50% to 86% (Richesson et al., JAMIA, 2013).
That is why clinical grouping matters. Grouping means defining a condition once, with a documented list of codes, results and medications, then applying that definition the same way to every source. Medicaid data and analytics leaders will recognize this as the difference between a measure and an argument about the measure.
How do semantic modeling and provenance work?
Semantic modeling sounds technical. The idea is plain.
First, you write down what your core terms mean: a person, a visit, a diagnosis, a medication, a county. Second, you map every source to those terms. Third, you keep the original value next to the mapped one, so nobody has to guess what changed.
Provenance is the record of that trip. Each figure carries a note of where it started, what was done to it and when. When a number looks wrong, you follow the trail back rather than starting an investigation from scratch.
Two things follow. A dashboard built on this is easier to check. And a rule change, such as a new definition of a condition, can be documented and traced forward. For how CareFlowIQ approaches this, see How It Works.
What does this mean for RHTP reporting?
Under the Rural Health Transformation Program (RHTP), states report quantifiable metrics to the Centers for Medicare & Medicaid Services (CMS). For each initiative, that means at least four metrics, with at least one at the county or community level (CMS RHTP applicant webinar). Those figures will be read by reviewers, legislators and the public. We break down what that asks of your data in What RHTP Measurement Actually Asks of Your Data.
A figure that holds up to review needs more than a clean chart. It needs a trail. A foundation that records source, record, rule and date supports defensible reporting. It doesn’t satisfy a reporting requirement on its own.
There is a longer view too. Modernizing public health data is a standing obligation that outlasts any single program, so a foundation built for one funding cycle stays relevant after it ends. See how this applies to state programs on our RHTP data and measurement page.
What should you ask before you trust a dashboard?
Put these to any vendor, internal team or advisor you are shortlisting.
- Can you show me one figure and trace it to the source records behind it?
- Where is each metric’s definition written down, including inclusions and exclusions?
- How do you group codes, results and medications into a single condition, and who approves the grouping?
- Do you keep the original source value next to the mapped value?
- How do you match one person across systems, and what happens to records that don’t match?
- What date does each figure cover, and when was each source last refreshed?
- What happens to past figures when a definition changes?
- Which data was available for this figure, and which was missing?
A good answer is specific and shows its work. A vague answer tells you where the risk sits.
Want to run these questions against your own data? Start a partner conversation about building a data foundation for your program, starting with the Connect phase.
Common questions
Why do dashboards need a data foundation first?
A dashboard only displays figures. The foundation defines them, connects the sources behind them and records where each one came from.
Doesn’t FHIR solve the consistency problem?
FHIR standardizes how data is exchanged. It doesn’t make two systems code, complete or interpret that data the same way.
What is data provenance?
It is the record of a figure’s origin: the source, the specific records, the rule applied and the date.
How does this help with RHTP reporting?
It lets a state show reviewers how each reported metric was built, which supports defensible reporting.
Sources
- D’Amore J, Mandel JC, Kreda DA, et al. Are Meaningful Use Stage 2 certified EHRs ready for interoperability? Findings from the SMART C-CDA Collaborative. Journal of the American Medical Informatics Association. 2014.
- Gabriel MH, Richwine C, Strawley C, Barker W, Everson J. Interoperable Exchange of Patient Health Information Among U.S. Hospitals: 2023. ONC Data Brief No. 71. May 2024.
- Richesson RL, Rusincovitch SA, Wixted D, et al. A comparison of phenotype definitions for diabetes mellitus. Journal of the American Medical Informatics Association. 2013;20(e2):e319–e326.
- Centers for Medicare & Medicaid Services. Rural Health Transformation Program applicant webinar.
