Sami Laine has worked with data quality for two decades — at Turku University Hospital, in doctoral research at Aalto University, and as a consultant and educator. It left him with a conclusion that sits awkwardly with how most organisations approach the subject: a data quality dashboard can be entirely green and still tell you very little about whether your data supports good decisions — and the same dashboard can flag millions of errors that nobody has a reason to fix. Both, he argues, are symptoms of measuring data against rules without establishing whether those rules reflect what the business actually needs.
We spoke about why chasing errors can become a permanent occupation, what prevention really involves, and where organisations should begin.
What hospitals teach you about data quality
Sami Laine joined Turku University Hospital in 2005, having already worked with the hospital during his master’s thesis. His early work involved helping chief medical officers develop strategic indicators covering service quality, finances and patient services. He later moved into data collection and data warehousing, coordinating between IT and healthcare leaders.
The work exposed him to a difficult reality: healthcare data describes an evolving understanding of a patient’s condition. Diagnoses change as clinicians investigate, and different specialties work in very different ways.
The consequences of misunderstanding that data extend well beyond reporting.
“If you have wrong data for a clinical purpose, you might kill the patient.”
And at the other end of the scale, problems in productivity statistics can distort decisions about how healthcare is funded.
Even apparently straightforward comparisons between hospitals can be misleading. A hospital treating younger, healthier patients may report better outcomes and lower costs than one treating older patients with more complicated conditions. Without understanding those differences, the numbers can reward the wrong things.
Laine recalls chief medical officers challenging statistics that had been prepared for ministry officials and used in public funding decisions: “You can’t compare like that.”
Those experiences led him to begin dissertation research at Aalto University on healthcare data quality — and to a question that still shapes his work: what does the data actually allow us to conclude?
Fit for purpose — and measured against meaningful requirements
For Laine, good data quality starts with fitness for purpose. Does the data help someone make the decision or achieve the outcome they need?
But that alone does not tell an organisation how to improve it. For that, it also needs explicit requirements.
He sees these as complementary. Fitness for purpose establishes whether the data works in practice. Requirements make it possible to investigate, measure and improve the properties that matter.
The difficulty comes when organisations assume fitness for purpose and conforming to requirements are interchangeable. They are not — and treating them as if they were is where the two most often come apart.
“You might have really good validity, completeness and accuracy scores, but your measurements are not grounded in real business, in real decisions,” he says.
Laine is also careful about one thing: there is never just one requirement.
“People talk about a data quality requirement for a purpose, as if a single rule maps to a single purpose, something you can write down and check,” he says. “In practice it’s always a collection – and often many-to-many relations between rules and purposes. To achieve a purpose, you need the right actor, the right task, the right tool, the right environment, the right context — and each of those brings its own requirements for what needs to be captured in your data.”
No organisation can list all of them in advance. What actually gets built is a smaller set — the requirements someone judged to matter most, given time and cost.
“You always end up choosing a subset,” Laine says. “Hopefully the ones that matter most. If you guessed wrong, someone downstream often finds out — a clinician, a customer, an auditor. Sometimes nobody recognizes that, and organisations keep living in a false reality, making the same mistakes and forcing everyone to repeat them.”
Data may work for a particular purpose despite failing a requirement — because the requirement was irrelevant to the purpose, or because enforcing it caused harm of its own. Equally, data may satisfy every requirement in the set and still fail the purpose, because something the purpose depended on was never specified as a requirement at all.
“The requirements and metrics themselves need scrutiny — not just whether data passes them, but whether the set was ever the right set to test against.”
In healthcare, Laine argues, the aim of evidence-based medicine is not to stop at checking whether data conforms to the rules, but to track whether the decisions made from it actually improve patients’ health.
“A green dashboard tells you the data passed,” Laine says. “It doesn’t tell you whether decisions based on that data made anyone better.”
The dashboard that nobody uses
This disconnect helps explain two patterns Laine encounters in organisations.
The first is false confidence: quality indicators look healthy, so people assume the data can be trusted. The second is disengagement. “I have seen a huge amount of these dashboards. Most large organisations have built them. And when you ask who is using them — nobody cares.”
Consider a metric showing that 20% of the data is missing. That figure raises questions rather than answering them. Is the missing information needed? Should the expected proportion actually be 5%, or 40%?
If something is wrong, the metric does not explain why. A pipeline may have failed. A join may be incorrect. Staff may record an initial diagnosis but never update it when the patient’s situation changes.
Each explanation calls for a different response — and each takes time to trace through long pipelines and integrations. Sometimes the conclusion is that the data correctly reflects a changed situation and nothing needs fixing. “You just wasted thousands of euros and weeks of human work to find out that nothing is wrong.”
“This error focus is one of the big problems in the whole data quality and data management industry,” Laine says.
“They think that finding errors and correcting them is the point.”
The result is a firefighting organisation: plenty of activity, with too little attention to why the problems keep appearing.
Prevention starts before the data platform
Moving quality checks earlier in development helps. Laine welcomes the emphasis in data engineering on testing pipelines and assessing downstream effects before changes reach production.
His argument is that this still stops too late. The pipeline is not where the data goes wrong; it is where the damage becomes visible. By then the problem has usually propagated well beyond the point where it started.
Once data reaches a platform, the original opportunity to capture it correctly may be gone. Prevention needs to reach into the source systems, interfaces and working practices through which the information first enters the organisation.
His own data quality work has involved customer journey mapping, process design, application integrations and modelling source systems. Those are where the controls belong.
A hospital example illustrates how closely this connects to organisational change. The hospital wanted to move from specialty silos towards clinical pathways spanning multiple specialties. Connecting the visits required an additional pathway code in the source system.
On screen, it was a small addition. Behind it sat a much larger change in how the hospital organised care — and a shared software development queue, spanning four university hospitals, that made even a small system change take years.
Designing data quality therefore means working through how the business operates, how its systems support that work, and what information needs to be captured along the way.
Governance needs decisions to govern
When governance becomes bureaucratic, Laine often sees the same starting mistake: organisations establish roles and structures before understanding the decisions those people need to make.
They can end up assigning responsibility to someone who lacks either the authority or the expertise to act.
His preferred approach starts with a concrete business need and follows it through the work required to deliver it. Which decisions concern the source process? Which concern data models, shared definitions or how the information will be used? Which can a team make locally, and which require wider agreement?
Only then can the organisation identify the right people.
“You need to find the people who have authority. You need to find the people who have the expertise,” he says.
Specialisation also carries a cost. Every additional role creates another boundary across which work and decisions must travel. Sometimes that boundary is necessary, but it needs to be considered deliberately.
The practical question is how to keep decisions moving through the organisation.
Responsibility belongs with the ability to change the business
Laine’s principle for responsibility is straightforward: authority should sit with those who receive the benefits and suffer the consequences.
That often points towards senior business leadership, particularly operational leadership. Preventing a recurring quality problem may require changing how the organisation serves customers or runs a process. A data team cannot necessarily make those decisions.
“The data should be a representation of your business,” he says. “It’s exactly what happened in the business.”
Correcting a dataset after the event has limits if the underlying operation continues to produce the same problem. The person responsible needs the authority to change what happens in practice.
This is also the belief he most wants leaders to reconsider: that data quality is essentially a database or IT issue. Whether data supports a lending decision or a fair comparison between hospitals depends on understanding the business question and the context behind the records.
Where to begin
For organisations starting out, Laine recommends identifying the business problems that poor data is causing, then investigating their origins.
The appropriate response will depend on what they find. Some problems require stronger engineering practices. Others require better access to context, more meaningful comparisons or redesigned processes.
“Find the meaning, find the business case and start from there,” he says.
He also recommends involving at least one person who can connect the whole journey: the business problem, the processes, the architecture, the implementation and the changes employees will need to make. Specialists remain essential, but someone needs to understand how their contributions fit together.
Note! The content on this blog reflects my personal opinions and does not represent my employer. As the publisher, I am not responsible for the comments section. Each commenter is responsible for their own posts.