Anyone who has worked on a national or international specification knows the failure mode: a Word document describes the intended constraints, a spreadsheet lists the value sets, an example file shows what a message should look like, and a separate Schematron tries to check conformance. Six months later, none of them quite agree with each other.
ART-DECOR® exists to remove that gap. It is an open framework and methodology for authoring and maintaining the artefacts that make up a healthcare specification — data sets, templates, value sets, code systems, scenarios, questionnaires and business rules — in one governed, computable place.
A single source of truth
Instead of prose that humans must interpret, ART-DECOR captures constraints as structured, machine-readable definitions. The narrative implementation guide, the example instances and the validation artefacts are then generated from that single model, so they cannot silently drift apart. When a constraint changes, everything downstream changes with it.
From specification to computable artefacts
Because the model is computable, it can produce what implementers actually need: HL7 CDA templates and FHIR artifacts, value sets bound to the right elements, Schematron for validation, and worked examples. That shortens the distance between "the committee agreed on X" and "a vendor can build and test X."
What actually lives in a project
It helps to see the pieces ART-DECOR keeps in step, because they mirror the roles on a real specification team:
Datasets & scenarios
A dataset is a technology-independent, hierarchical glossary of clinical concepts — groups and items with data types, value domains, choice lists, ranges and rationale — capturing the caregiver's need for data before any wire format is chosen. It is deliberately readable by healthcare professionals rather than engineers: a set of vital signs, say, with body weight and body height as items, each carrying its required units and allowable ranges. Concepts and whole datasets are versioned and can be inherited, even from foreign repositories, so a national project can build on an internationally agreed base instead of redefining it.
Scenarios then tell the story of data exchange: use-case-driven transactions between actors that select concepts from the dataset and add cardinalities, conformance rules and conditions. That selection is where a plain glossary becomes an implementable specification — the scenario fixes which concepts are mandatory, which are optional, and under what circumstances each applies. A single scenario can be derived directly into a template or profile and even into a FHIR questionnaire, keeping the use case, the semantic scope and the implementable artefact tied together as one coherent whole.
![Example EHDSPatient dataset: a hierarchical tree of concepts including identifier, name, dateOfBirth, deceased[x], administrativeGender, address and telecom](dataset-example.png)
Terminology: coded concepts, value sets, code systems
Terminologists give the plain-language concepts their meaning. A coded concept is, at minimum, a code plus the code system it comes from; value sets collect the valid answer codes and bind to a concept's choice list, so a field like "blood group" accepts only the codes that make clinical sense. Release 3 adds a dedicated code-system editor alongside the value-set management browser, letting teams maintain their own code systems rather than only consuming external ones.
The cross-terminology browser is the everyday workhorse: a Google-like search across multiple stable terminologies — LOINC, SNOMED CT, ICD-10, RadLex, ORPHAcode, HPO, HL7 and more — served from centralized terminology services with rapid expansion sets for quick results. It exposes hierarchies (parent and child codes) and is used directly to author value sets both extensionally, by picking individual codes, and intensionally, by describing a query such as "all descendants of this SNOMED concept." For finer-grained needs, a post-coordination editor builds SNOMED expressions using SNOMED's own Expression Template Language, so even compound clinical ideas get a single, computable code.
Terminology associations & concept maps
Associations are the links between the real-world and the coded worlds, and they are what turn a dataset into a semantically anchored specification. There are three kinds: a concept association ties a dataset concept to a possible code from a proper terminology, a value set association ties a concept to a whole set of answers, and a value-set-code association pins an individual answer to a specific code. In practice these are created by drag-and-drop annotation in the browser — dragging, say, ICD code R11.0 onto the concept "Nausea" — which keeps terminologists productive without hand-editing identifiers.
Concept maps go a step further, expressing qualified mappings between and among clinical concepts, coded concepts and technical elements — for instance relating a "body temperature" dataset concept to both LOINC 8310-5 and a SNOMED code, or mapping one terminology to another. Because a mapping is rarely a perfect one-to-one match, ART-DECOR classifies the quality of each relationship along the lines of ISO/TR 12300, the standard on principles of mapping between terminological systems, so downstream users know whether a mapping is exact, broader, narrower or merely related.
CDA templates
Templates are where the clinical model meets a real wire format. HL7's Clinical Document Architecture (CDA) is a single, general document model — a header of patient and provider metadata over a body of human-readable sections that may hold machine-processable entries — so broad that you must profile it for a use case, and in CDA that profiling is done with templates: sets of further constraints on the base model, captured in HL7's normative Templates Exchange Format so they stay computable rather than buried in prose.
Specifications nest templates at four levels — document, header, section and entry — and ART-DECOR speeds authoring with ready-made prototypes and shared libraries (C-CDA, epSOS, IHE, IPS) from its Building Block Repositories. Best of all, it generates ISO Schematron from the templates, so you can upload a CDA instance, pick the scenario, and validate against exactly the agreed rules.
FHIR features
On the technical side, ART-DECOR exposes version-aware FHIR endpoints that render its content as native FHIR resources: datasets and transactions become logical models, templates become StructureDefinitions, value sets and code systems come out as FHIR ValueSets and CodeSystems, transactions become Questionnaires, concept maps become ConceptMaps, and the OID registry is served as a NamingSystem. In other words, the same governed model that produces CDA templates also drives a FHIR implementation guide, with no second source of truth to keep in sync.
A dedicated questionnaire panel manages both generated and hand-edited questionnaires together with their responses — you can create one directly from a scenario, import an existing one, or start from scratch, then prototype, render, test responses and publish it. FHIR profiling is handled much like the CDA template editor, starting from base resources or existing profiles and refining them, and support for the popular FHIR Shorthand (FSH) route together with Git integration is on the roadmap. The result is that questionnaires, profiles and logical models all trace back to the same dataset concepts that anchor the rest of the specification.
Publication
Publication is the deliberate life-cycle midpoint where frozen specifications are elevated to the public awareness level — a conscious decision by the authors, and one that publications themselves carry a status for. Every definition in ART-DECOR is two-dimensional: it has a status that matures from draft to active and eventually to retired or deprecated, and a version, where creating a new version clones the original (which may still be in use) and adds the changes, so history is never lost.
When a release is published, ART-DECOR compiles the datasets, scenarios, terminologies, templates, associations, profiles and concept maps into consistent electronic guides. Output formats span standard and next-generation HTML, MediaWiki and PDF, with newer targets such as Confluence and WordPress, and a release can be filtered by scenario to control exactly which artefacts ship. The same run can emit a full implementation guide and downloadable packages, so a stakeholder reads the narrative while a developer pulls the machine-readable artefacts from the very same publication.
Governance and reuse
Standards work is rarely a one-off. Templates, value sets and other artifacts defined once should be reusable across projects and versions, with a clear history of what changed and why. ART-DECOR treats governance — versioning, review status, reuse across projects — as a first-class concern rather than an afterthought, which is exactly what long-lived national programmes require.
Where it fits in a project
In practice we use ART-DECOR from the first modelling workshops through to conformance testing: to agree the data set with clinical experts, to publish an implementation guide stakeholders can read, and to hand developers artefacts they can validate against. The result is fewer surprises late in the project, when they are most expensive.
If you are starting a specification and expect to maintain it for years, the question is less "should we use tooling like this?" and more "how much rework will we accept if we don't?"