Concept Dictionary — How it works
Overview
The concept engine is the platform's controlled vocabulary (OpenMRS-style): the single source of coded meaning that clinical data, form fields, program outcomes, and attributes bind to. Concepts are system-wide (centrally curated, with imported/provided ids), named in multiple locales, answerable and set-organised, and mapped to external standards. A read-only validation API lets other engines confirm a concept id/code is valid and active.
Data model & ownership
| Table | Purpose |
|---|---|
concept | The core concept (class + datatype), system-wide id. |
concept_class / concept_datatype | Reference types (seeded). |
concept_name | Names/synonyms per locale; preferred name. |
concept_answer | Allowed answers for a coded question (CODED only). |
concept_set | Set membership (self/duplicate guarded). |
concept_mapping | Mapping to external standards. |
concept_version | Append-only version snapshots. |
Key rules & invariants
- Concept ids are system-wide and stable (imported/provided) so coded references are portable.
- Answers apply only to CODED questions; set membership rejects self/duplicate.
- Versions are append-only; voided concepts fail validation — a consumer binding to a voided concept is rejected.
API
See the API Reference. Endpoint groups under /api/v1/concept: concepts, classes,
datatypes, names, answers, sets, mappings, versions, and read-only concept validation (resolve by
id / source+code / mapped code, with deterministic reasons).
Configuration & feature flags
None.
Related features
- Clinical, Form, Program, and
Demographic attributes all bind to concept ids. Domain plug-ins read via
exchange.client.concept(ConceptClient).