These concepts are often described with abstract language. This demonstrator starts with the practical questions that each service answers, then follows example data fields through a working registry, the dictionary published from it, a data catalogue and the data contracts that apply them.
The easiest way to understand the architecture is to stop thinking about products and start with the question a user is trying to answer. The services overlap, but they are not interchangeable. Each has a different job.
A human-readable publication of agreed data definitions. It helps clinicians, analysts, programme teams and suppliers understand a field consistently.
The controlled system of record for metadata. It gives the definition an identifier, version, status, provenance and formal relationships to other metadata.
A terminology service manages controlled clinical vocabularies, value sets and maps. It is where the meaning of clinical codes is maintained and versioned. The binding recorded in the registry or a contract decides which of them are permitted in a particular field.
A reference-data service supplies reusable lists such as organisations, facilities, countries, care settings or service types. These values may be used by many systems.
A context-specific agreement for a data product, feed or API. It reuses governed definitions and then adds obligations such as required fields, quality rules and timeliness.
A catalogue helps people discover feeds, datasets, tables and reports, with their owners, locations, access routes and sensitivity. It points to registry definitions for the meaning of each field rather than defining fields itself.
A common cause of confusion is that the same data item appears in several places. That is intentional. Each service holds a different kind of information about the same thing. The test is not “where does the field appear?” but “which service is authoritative for this aspect?”
The dictionary explains what diagnosis means in this organisation. The terminology service supplies the permissible diagnosis concepts and codes. Copying the entire diagnosis terminology into the dictionary would create a second, quickly outdated source.
The concept “date of birth” is independent of whether one interface sends YYYY-MM-DD and another system stores a database date type. The registry can separate the concept from each technical representation while the dictionary presents the common meaning.
The dictionary may say what “discharge destination” means. A specific discharge feed may make it mandatory, require delivery within five minutes and limit it to a particular value set. Those are contract rules, because they apply to that specific exchange.
Choose an answer. Some organisations may implement the boundary differently, but the explanations show the preferred separation of concerns.
The abstract terms become easier when we follow a single field. Select an example below. The same field is shown as a plain-language definition, a governed registry record, a controlled-value binding and a contract obligation.
A registry can model a data element as several related objects rather than as one long spreadsheet row. This may look unnecessarily formal until definitions have to be reused across hundreds of systems. The separation lets the same business concept use different representations without redefining the concept.
This tab shows how a registry works in practice. Every record has a persistent identifier, version, registration status, steward, value-domain binding, relationships, implementation mappings and change history. The Dictionary and Data catalogue tabs read from these records; they do not hold their own copies.
| Registry ID | Data element | Version | Status | Steward |
|---|
A date, integer, decimal, Boolean or text value. The registry defines datatype and format. No external code list may be needed.
date of birth discharge date and timeThe field carries a concept selected from a controlled clinical vocabulary or value set managed by a terminology service.
diagnosis laboratory testThe field selects from an authoritative operational list such as an organisation, facility, country or care setting.
organisation identifier care settingThe meaning depends on several linked elements, such as a measured value plus unit, method and effective time.
laboratory result blood pressureThe dictionary is generated from the registry. It publishes only records at Standard or Qualified status, and it presents the same record at the level of detail each reader needs. Change the reader below: the definition stays the same and the detail around it changes.
A catalogue describes data assets: feeds, datasets, tables and reports. It tells users what exists, who owns it, where it is held and how to get it. It does not define what the fields mean. Instead, each asset maps its local fields to registry elements, so anyone who finds a dataset can see which governed definitions it uses and how well each field matches.
A data contract is the point where shared definitions become obligations for a particular data product, feed or API. It is not the place to invent new meanings. It should reference the registered definitions, then add the rules that a producer and consumer need in that context.
Note: “contract” here means a governed data agreement. Procurement or legal documents may reference it, but the concept is broader than a legal contract.
Every interface document contains its own definition of “care setting”, copies a list of codes into an appendix and uses locally invented names. Six months later the values differ between interfaces and no one can tell which list is current.
Result: semantic drift, duplicated maintenance and expensive reconciliation.
The contract references registered data element DE-CARE-SETTING and value-set binding VS-CARE-SETTING. The registry records provenance and status. The terminology or reference-data service supplies the current permitted values.
Result: one definition, one governed value source and many controlled uses.
The technology is the easy part. The hard part is agreeing who can define, approve, change and retire metadata. A registry is valuable because it makes those decisions explicit and traceable.
A programme, service or analyst needs a shared definition.
Agree the business meaning before choosing a technical format.
Assign persistent ID, steward, provenance and initial status.
Datatype, cardinality, units and value-domain pattern.
Reference terminology or authoritative reference data where required.
Check semantics, safety, legal constraints and technical feasibility.
Expose human-readable dictionary views and machine-readable metadata.
Use registered IDs in APIs, feeds, datasets and procurements.
Version changes, deprecate safely and preserve history.
Persistent identifier, preferred name, definition, synonyms, domain, object class, property and usage context.
Datatype, format, unit, cardinality, conceptual domain, value domain and any terminology or reference-data binding.
Steward, registration status, version, approval date, effective date, provenance, evidence, change history and retirement status.
Broader and narrower concepts, component fields, aliases, maps, equivalence claims and relationships to datasets or contracts.
How local database columns, message fields, API properties or legacy codes correspond to the registered element.
Validation rules, known limitations, quality expectations, jurisdiction, sensitivity and constraints on reuse where appropriate.
Do not attempt to register every database column in the enterprise on day one. Start with the data that is exchanged, reused, regulated, reported nationally or required by major transformation programmes.
A clinician, analyst and integration engineer may need different detail, but they should be looking at views of the same registered metadata rather than separate definitions.
If an authoritative terminology or reference-data source exists, the registry should point to it. Copying lists into spreadsheets creates unmanaged forks.
Contract rules are more useful when validation can be automated. Required fields, datatype, code bindings and quality rules can often be tested at build and run time.
Standardising metadata does not require every system to have the same physical schema. Register mappings from local fields to shared concepts and assess whether the mapping is exact, broader, narrower or lossy.
The registry, dictionary, terminology and reference-data capabilities need owners, APIs, support, release management and service levels. A static spreadsheet is a useful seed but not a sustainable enterprise service.
