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.
Clinical modelling can appear daunting at first. To reduce the complexity, we break the process down into different steps:
- Define the data points. eg the datasets from different registries; the different variables being collected in a study.
- Identify if data points from the different sources overlap. For example demographic details are usually collected in lots of different registries. e.g. COSD, SACT and RTDS all collect demographic data for the same patient, though the details may vary slightly (eg address at diagnosis vs address during treatment).
- After identifying the overlaps, we define the unique data points that need to be collected.
- Identify which data points can be collected using archetypes which are already available, and which cannot:
- Some data points will be completely covered by archetypes that have already been published.
- Some data points will require modification of available archetypes.
- Some data points will require the development of new archetypes.
- Develop the new archetypes and modify existing archetypes as needed.
- Model the business process of data collection (eg how data is processed / collected in the context of an MDT).
- Produce templates (corresponding to the forms needed to collect at each point of the pathway) using the archetypes.
This is a wide variation in the way that people approach steps 1 to 4. A mindmapping tool is often used for this purpose – we recommend XMind, available on Windows, Mac and Linux, as well as portable packages. In this series of articles, we describe a standard process for using XMind to model in openEHR.
Defining the data points
The aim of the mind map is to give a good overview of how the data is structured, such that other modellers or domain experts can understand the relationship of the data points.
In urological cancer, we began by listing the different registries and data repositories as well as the needs of the different medical specialties – we plotted these as different nodes on the mindmap.
We then explored each of these areas to define the datasets. Below we expand on the different sections of the COSD dataset, forming subsets of further daughter nodes until we get to the data points themselves.
Below is a close up of the staging section from the image above, containing the data point names.
Our convention is to document any codes for the data points within the node name – eg in the image above, “T category (final pretreatment)” has a code of CR0520 in the COSD core dataset.
Note: the text in yellow are labels attached to each datapoint (see below).
The data point name is usually the lowest level node in the tree – ie no further “daughter nodes” to the right of the data point name.
However, some modellers like to document the value sets for some data points on the next level down using a “boundary” function. Boundaries are boxes surrounding a group of nodes – a boundary can be created by highlighting the nodes and pressing Ctrl-B, by clicking the icon on the top toolbar , via the drop down menus at the top of the page (Insert > Boundary), or by right clicking on a data point (> Boundary).
The example below shows the use of boundaries to define value sets:
- The data point “Joint” can have a value of “Left elbow”, “Right elbow”, “Left knee”, “Right knee”, “Left ankle” or “Right ankle”.
- The data point “Duration” can have a value of either “0: No swelling or less than 6 months” or “1: Greater than or equal to 6 months”.
This latter approach (using boundaries) can be very useful when dealing with small projects / mindmaps. However they can result in a more cluttered appearance in larger mindmaps. Therefore some modellers break down the large mindmap into smaller mindmaps in the later stages of the project.
Part 2 of this series can be found here. In Part 2 we discuss how to categorise the data points, identify links between different datasets and use the mindmap to guide archetyping in openEHR.