Perspective
The same name starts to mean different things when each report defines the concept for itself.
In a reporting tool, a semantic model is often built for a single set of reports. The next set defines a visit, a care episode or a patient again, slightly differently.
What this is about
A semantic model is a chain that ties an operational concept to the data that a figure ultimately comes from. The chain has four parts: concept, definition, calculation and physical data. Rather than an individual report, the model describes the organisation's work: its visits, care episodes and patients. That is why shared concepts should be defined on the data platform, where every report reads the same definitions.
We start with the chain because “semantic model” is used in the industry to mean three different things: the data model and measures in a reporting tool, the metrics layer on a data platform, and semantics in the literal sense of the word. In reporting tools the term usually means the data model that reports are built on, and each set of reports often ends up with a model of its own. The meaning is most prominent in Power BI, where Microsoft renamed datasets “semantic models” in 2023.
When the chain holds, the same metric gives the same figure whether it is read by a report, an API or an AI agent. A change to a definition is then an event with a date and an author, and past figures can be recalculated. Every figure can be traced back to its rule, to its data and to the person who approved the definition.
What goes wrong
At worst the model is being built in two places at once, in the reporting tool and on the data platform, with neither side aware of the other. If modelling on the data platform starts from existing reports, their contradictions are copied across with them.
- The same figure differs from report to report, and the difference is reconciled by hand every time.
- Trust shifts from figures to people because only one or two of them know how the metric is actually calculated.
- A separate official report is produced for management because the others are not trusted.
- A change to a definition does not show up anywhere, and past figures cannot be recalculated.
- The logic has to be read from the formula, and the knowledge leaves with the person who wrote it.
- An AI agent answers convincingly, but the answer cannot be trusted.
Behind all six lies the same gap: the concept has no owner. When nobody has been named to decide, the person closest to the code decides. A data engineer then ends up deciding on definitions, and those decisions belong to a subject-matter expert.
How we think
The reporting tool stays, the definition moves to the data platform
In the target state the reporting tool stays in use. The definition moves out of the tool and onto the data platform, where it has three parts: a conceptual model with its transformation rules, a data contract and a metrics layer. The data contract states the concept's meaning, owner, quality rules and lifecycle stage. In the metrics layer every metric is managed as an object in its own right, and reports, APIs and AI agents read it from there.
The boundary shows which figure is official
A boundary is drawn around the three parts on the data platform. A metric inside the boundary is the organisation's figure. A metric calculated in a report stays outside the boundary, and it is that report's own figure. Existing reports do not have to be taken apart.
The aim is for every concept to have an owner outside the data team
A definition with no owner looks official but is not. So we aim for a subject-matter expert to be responsible for an important concept and its data contract before the concept is modelled.
One use case and a few metrics at a time
Johannes Hovi writes (in Finnish) that the hardest part of a semantic layer is not the technology. He too describes the connection from concept to physical data, and advises starting with one use case and a few metrics. We agree. Not all concepts are defined in one go: the first metrics are implemented, and then we see whether the result holds up. That way, defining concepts becomes part of everyday work.
The definition is taken all the way into code
To Hovi's advice we add one requirement. The definition is written as a data contract that travels with the code and is checked automatically. The contract is versioned and tested in the same pipeline as the data. A data catalogue is a view onto the chain, and the definition itself is in the code. The aim is for a concept to hold true even when the systems underneath it change.
For this we use Data as Software, a method in which data production is done like software. At Western Uusimaa Wellbeing Services County, data contracts define quality rules and ownership for the core data, and they travel with the code from development into production. The Western Uusimaa case study shows that a definition can be written into code. It says nothing about a metrics layer or about who owns the concepts.
What we do
| Service | What it means here |
|---|---|
| Definition | Named owners and a decision cadence, applied here to concepts: who decides on a definition and how a change is approved |
| Data as Software | A concept is defined in one place, the data contract travels with the code, and the tests run every time |
| Data platform | The platform can be designed so that reports, APIs and AI agents read the definitions from the same place |
Related pages: AI into production
Who this is for
For heads of data, data architects and those responsible for management reporting in wellbeing services counties, hospitals and national health and social care bodies. The subject becomes relevant when a data platform is being built alongside reporting, or when an AI agent is expected to give the same figures as the management report.
Expert: Antti Brunni, Chief Executive Officer
In 30 minutes we go through one metric that matters to you: where its definition sits, who decides on it and where the figure comes from.