We analyze, review and redesign your organization's data model so clinical information keeps its meaning as it moves from one system to another — with a terminology strategy, a target model and a migration plan that does not interrupt operations.
When two systems fail to understand each other, it is almost never because the message did not arrive. It is because each stores the same clinical fact differently: a free-text field where the other has a code, a homegrown diagnosis table, a date that is sometimes the collection date and sometimes the report date, an identifier that repeats across facilities. Standardizing the exchange without sorting out the model only moves the problem one layer up. This service works where the problem starts: we analyze the current model, review its design, agree on how far the scope reaches and propose a target model with the terminologies, normalization rules and migration plan needed to get there.
All five exist whether or not anyone decided them. When one is skipped, the decision still gets made — by whoever is writing the code at that moment, with no record of it.
Who owns each data point, who approves a model change, how often it is versioned and how a decision is documented so it still makes sense three years from now.
Every project spawns its own variant of the same concept, no change can be reversed, and understanding the model becomes archaeology.
Exactly what each data point means: which terminology it binds to, at what binding strength, in which units it is expressed and what happens to values that have no code.
Systems share identical structures and incomparable data. Analytics aggregates different things under one name and nobody notices.
How information is structured: what is a resource and what is an attribute, how observations nest, which cardinalities apply and what an absent value actually means.
Every integration needs its own translator, no mapping can be reused, and the cost of connecting grows with each new system.
How it is persisted and queried: physical schema, indexes, record versioning, historization, and the performance of both the clinical query and the analytical one.
The model is correct on paper while the query a clinician needs takes minutes, so someone builds a parallel table and the single model stops being single.
Which rules turn real data — the data already loaded, with duplicates, abbreviations and free text — into data that conforms to the model, and what happens to what does not fit.
The new model coexists with years of data that does not comply, and the migration turns out to be unworkable after a date has already been promised.
Five stages. The first one looks at the real data, not just the diagram.
We gather what exists: schemas, dictionaries, homegrown code tables, forms and the structures each system actually uses. And we profile the loaded data — distributions, nulls, free text, duplicates — because the documented model and the production model rarely match.
OutputsWe assess the model against explicit criteria rather than opinions: clinical expressiveness, traceability of who recorded what and when, extensibility for a new domain, queryability for both care and analytics, and the ability to sustain the exchange the organization needs.
OutputsWe agree how far it reaches: which clinical domains are in scope now, at what granularity, what is represented in a structured way and what is accepted as text for the time being. Where the domain already has a WHO SMART Guidelines DAK, its core data elements are the starting point for that scope rather than a list built from scratch. An honest scope is what makes everything else executable.
OutputsWe design the destination model and express it in the artifacts of the chosen approach: archetypes and templates, profiles and extensions, or an internal canonical model. With identifiers, terminologies and conformance rules decided, not pending.
OutputsA model without a change process diverges again on the first urgent project. We define who approves a modification, how it is versioned, how it is communicated and what compatibility is guaranteed between versions.
OutputsopenEHR and FHIR are sometimes presented as mutually exclusive. They are not: they solve different problems, and in more than one ecosystem it makes sense to use both.
Models and persists clinical information with the model kept separate from the software: archetypes define the maximal dataset of a clinical concept, templates constrain it for a specific use, and queries are written against the model rather than a physical schema. Clinicians govern the content, not the development team.
ArtifactsModels how information leaves one system and enters another: resources at a granularity meant for transport, profiles that constrain them to a specific use case and APIs with defined searches and operations. It is the contract with the outside world.
ArtifactsThe common model the organization uses across its own systems, analytics and processes. It does not always need to be an external standard, but it does need to be a single one: it is where differences between sources get resolved before anything is exposed outward.
ArtifactsChoosing one does not rule out the others. The usual path runs from the clinical model to the exchange contract, and the canonical model is what keeps each end from speaking a language of its own.
Downloading SNOMED CT is not adopting it. Each terminology forces decisions about scope, maintenance, licensing and versioning that, left unmade at the start, end up being made by default and badly.
Reference clinical vocabulary for diagnoses, procedures, findings and clinical context.
Decisions it forcesIdentification of observations, laboratory tests, panels and clinical variables.
Decisions it forcesClassification for statistical reporting, morbidity, mortality and regulatory obligations.
Decisions it forcesThe country's own catalogs — facilities, services, practitioners — and the ValueSets national guides impose.
Decisions it forcesThe catalogs the organization already has and that will not disappear overnight.
Decisions it forcesWe work with these terminologies as a technical frame of reference. Licensing and affiliation, where they apply, rest with the organization or the country adopting them.
A new model is worth nothing if the data that already exists never reaches it. Migration is designed as a project of its own, with phases, acceptance criteria and a way out.
Measure what is actually there: volumes, quality, free text, duplicates, out-of-range values and data that never met the rule it was said to meet.
Define the transformations and quality criteria: what gets cleaned, what gets deduplicated, what gets enriched with terminology and what gets flagged as non-conformant.
Map field by field and code by code, declaring the equivalence type of each mapping. Whatever does not map is documented as an exception; it is not silently dropped.
Old and new models run side by side for an agreed period, through dual writes or compatibility views, so no system depends on a single cut-over date.
History is migrated in batches and validated by equivalence: volume reconciliation, aggregate comparison and clinical review by sampling. Validation is what authorizes the cut-over.
The flow to the old model is cut and the model is retired once nobody is shown to read it, keeping the traceability of every transformation so a data point's origin can be explained later.
Documents used during the redesign and after it — not a report that gets filed away.
Inventory of sources, consolidated dictionary and profiling of the real data.
Findings per layer, risks, model debt and the decisions still outstanding.
Domains, granularity and what is explicitly out of scope for this iteration.
The logical model and the artifacts of the chosen approach: archetypes and templates, profiles or a canonical model.
Bindings per element and declared equivalences with the local codes.
Transformations, quality criteria and explicit handling of exceptions.
Sequence, acceptance criteria, coexistence and the conditions that authorize cut-over.
Versioning, change process and owners per domain.
The modeling and terminology work behind implementation guides that are published and in use today.
Profiles and ValueSets for the clinical terminologies shared across the country's health ecosystem: deciding which vocabulary applies to each element, at what binding strength, and who maintains the catalog.
Structure and conformance rules for reporting results: what is represented as an observation, how tests are coded and how units, reference ranges and interpretation travel with them.
Profiles for exchanging imaging study reports: the translation between what the equipment produces and what the clinical record needs.
Reporting of notifiable diseases, vaccines and laboratory results: aligning what the source system records with what the national guide requires, and receiving it on the first national FHIR server.
These cases cover the modeling and terminology work inside national implementation guides. The openEHR approach is part of the service and is assessed case by case; it does not appear here because it was not part of these projects.
What changes from one organization to the next is not the method, but how expensive it is to keep going without an agreed model.
Several clinical systems recording the same fact in different ways. The common model is what makes a single patient view possible.
Ecosystems that must agree on the model before requiring conformance, so the national guide rests on a decision rather than an assumption.
Homegrown catalogs that must map to LOINC or national codes without losing the detail the laboratory needs to operate.
Products whose schema grew by accretion and that now must expose conformant data without rebuilding the database from scratch.
Teams that depend on data meaning the same thing across every source for an indicator to be comparable between facilities.
Exchange with many providers where each codes its own way and equivalence has to be declared, not assumed.
If several of these describe your organization, the problem is not in the interfaces: it is in the model underneath them.
Before exposing APIs or committing to a national guide, it is worth knowing what the model actually represents and what is missing to get where you need to be.