Personal tools
User menu



Jump to: navigation, search

Scenarios and datasets are the area of the healthcare providers: they know what data they want to see, what data they want to exchange and they know about the scenarios: when information is exchanged and between what actors.

A dataset is a list of (hierarchical) concepts. A DECOR project contains one or more datasets. When there are multiple datasets, they are different versions of the same dataset. It is not recommended to create datasets for different healthcare projects in the same DECOR project.

A dataset consists of (healthcare) concepts. You can see a DECOR dataset as an hierarchical concept repository. Concepts should be well-defined and can be demonstrated with the following examples:

  • Female
  • Body length
  • Heart rate
    • Result measurement
    • Heartbeat regularity
  • Diabetes
  • Monochorionic

Datasets and, more specifically the concepts that they contain, are the target of references from other areas inside DECOR. One of those areas are scenarios, which refer to concepts defined in a dataset. Another important area is terminology. Terminologists provide the knowledge about datasets, code systems (official ones and self-made ones) and they associate their terminology and terminology codes with the concepts that they healthcare provider has.

A project may have more than one dataset, but if that happens, those datasets should be different versions and should (ideally) not cover different areas. Dataset versioning is based on the effectiveDate attribute and can make use of inheritance mechanisms. For more details, see the section about Dataset versioning below.


The concepts inside a dataset can contain a value domain, which is a typed description of the values that a concept can have. For more information about datatypes, refer to the page about DECOR datatypes.

Dataset versioning

  • New dataset versions get a new @id and a new @effectiveDate
  • The concepts in the new dataset version keep their @id, but get a new @effectiveDate and inherit from the original concept. If a concept needs changes it may be disconnected (deinherit) from its source concept so editing is possible
  • The name and other properties of a concept constitute its definition. This definition should be governed. This means that any property in any language is under governance. When project wants to reuse (inherit) these concepts they inherit this definition as-is, and only comments are allowed additions. These comment cannot in any way shape or form alter the semantics of the original concept
  • Multi lingual setting: when a project wants to reuse concepts from a building block repository (BBR) that does not have defining properties in the same language as the project, then the project can do one of the following things:
    • Accept the BBR concept as-is, potentially adding a comment
    • Talk to the BBR governance group and work out an agreement whereby translations may be submitted
      The recommended procedure for a BBR governance group for submitted translations is to create a new version of the dataset that adds the translations. The governance group could, but this is not recommended, decide to add the translation to the original dataset. ART will not support this as BBR datasets should be final, and final objects cannot be edited.
  • This page was last modified on 1 October 2021, at 13:47.
  • This page has been accessed 36,358 times.