openEHR Modelling with XMind – Part 3 (Summary)

Part 3 is a quick reference summary of the more detailed descriptions in Part 1 and Part 2.

In this series of posts we document how we began the process of modelling our data using mindmaps. The aim is to document our processes in an open and reproducible manner.



  • Mindmap nodes:
    • The registry code for a data point is documented within the name of the node – eg “CR0520 – T category (final pretreatment)”.
    • The data point name is the often lowest level node in the tree – ie there are no further “daughter nodes” beneath the data point name.
      • However some modellers list the constrained value set of the data point using daughter nodes, grouped together with a boundary box.


  • Labels:
    • These are used as tags for searching. There can only be one label per node, but this can contain multiple tags.
    • Tags should be one word long (but words can be concatenated eg “COSDcore”) and separated by commas.
    • Document the different datasets / registries in which the datapoint resides via these labels.
      • Eg if a datapoint is in both “COSD core” and “Genomics”, it would be listed under both parent nodes (with the correct corresponding field code in each section), and would be tagged with both “COSDcore” and “Genomics” each time – ie “COSDcore, Genomics”.
    • Also document the chosen archetype with a label corresponding to the archetype name – eg “CLUSTER.tnm_staging_7th-prostate.v1”.


  • Notes:
    • Used for longer text notes about the data point.
    • We recommend that you put any codes from other data points in this section (eg “CR0620 in COSD is equivalent to 14944.1 in Genomics”).
    • You may also choose to document information about the field type, possible candidate archetypes, or background information including definitions of terms. If boundary boxes have not been used, the constrained value set may be defined here (eg Male / Female / Other).


  • Comments:
    • The comments section should only be used for discussion between different people working on the project. If any aspect of the data point needs to be changed, it should be documented within the name field, the labels, comments or markers.


  • Markers:
    • Please use the custom markers we have provided (“openEHR-infogather.xmp” – a zip file containing the file can be found here).
    • full_match  Full match – available archetype usable without modification.
    • no_match  No match – new archetype needed.
    • partial_match  Partial match – available archetype usable, but will require modification.
    • indeterminate  Indeterminate – further analysis required.


More detailed descriptions can be found in Part 1 and Part 2 of this article.

Leave a Reply