Month: December 2015

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.

 

Summary

  • 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.

openEHR Modelling with XMind – Part 2

Part 1 of this series can be found here. 

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.

In Part 1 we examined the initial stages of mindmapping. Here in Part 2, we look at the next steps, leading up to archetyping in openEHR.

 

Analysing the data points and identifying overlaps

The 2 images below display the different annotations we can use during the analysis phase. Our convention is to use labels, notes and comments for different functions.

labels notes comments

labels notes comments - labelled

 

Labels

These are added to any datapoint by pressing F3, via the drop down menus at the top of the page (Modify > Label), or by right clicking on a data point (Insert > Label). Only one label can be added per node, but this may contain multiple different tags – these are listed in a box beneath the name of the data point.

labels notes comments

For example, in the image above the data point CR0620 has been labelled with the tags “COSDcore” and “Genomics”. This indicates that the data point is present in both the COSD Core dataset and the Genomics dataset. Using the tags therefore allows us to highlight overlaps in datasets.

To keep things simple, please use single words without spaces for the tags (though you can use concatenated words – eg the terms “COSD” & “core” together become “COSDcore”). The tags are separated by commas, as seen in the image above.

Note:

  1. These tags can then be used to search through or filter down the data points, which is why they are so useful.
  2. The tags are also used for assigning to archetypes – see later.
  3. XMind automatically reorders the tags into alphabetical order.

 

Notes

These are added to any datapoint by pressing F4, via the drop down menus at the top of the page (Modify > Notes), or by right clicking on a data point (> Notes). A small icon Notes icon appears to the right of the data point name, when there is a comment attached. Click on the icon to reveal the notes, as on the image below.

Notes

The “notes” function is used for longer text notes about the data point. We recommend that you put any codes from other data points in this section (eg in the above image CR0620 in COSD is equivalent to 14944.1 in Genomics).

You may also choose to document information about the field type including value sets (eg Male / Female / Other) in the notes section.

 

Comments

These are added to any datapoint by clicking on the icon in the top toolbar Add comments icon , via the drop down menus at the top of the page (Modify > Comments), or by right clicking on a data point (> Comments). A small icon Comments icon appears to the right of the data point name, when there is a comment attached. Click on the icon to reveal the comments, as on the image below.

comments

Multiple comments can be added by different people. This section is therefore used for discussion during collaboration.

comments 2

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

 

Identification of commonality with existing archetypes

We aim to Identify which data points can be collected using archetypes that are already available, and which cannot.

  1. Some data points will be completely covered by archetypes that have already been published (full match).
  2. Some data points will require modification of available archetypes (partial match).
  3. Some data points will require the development of new archetypes (no match).

To document this process we have created a series of markers which can be used in XMind. The markers can be imported by opening the file “openEHR-infogather.xmp” – a zip file containing the file can be found here. The markers should be used in the following way:

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.

The easiest way to use the markers is to open the Markers window – via the drop down menus at the top of the page (Window > Markers). The imported markers are usually at the bottom of the window, under the heading “openEHR tasks”.

Markers window

The markers can be inserted by clicking on the node and then clicking on the required marker. The results will look similar to the image below.

Markers

The name of a relevant archetype can also be added as a label – see the labels under CR0620 on the following image.

archetype

 

And there you are! An outline of how XMind can be used for modelling in openEHR. A summary of the processes outlined in Parts 1 & 2 can be found in Part 3.

openEHR Modelling with XMind – Part 1

Introduction

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:

  1. Define the data points. eg the datasets from different registries; the different variables being collected in a study.
  2. 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).
  3. After identifying the overlaps, we define the unique data points that need to be collected.
  4. Identify which data points can be collected using archetypes which are already available, and which cannot:
    1. Some data points will be completely covered by archetypes that have already been published.
    2. Some data points will require modification of available archetypes.
    3. Some data points will require the development of new archetypes.
  5. Develop the new archetypes and modify existing archetypes as needed.
  6. Model the business process of data collection (eg how data is processed / collected in the context of an MDT).
  7. 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.

Level 1

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.

Level 2

Level 3

Level 4

Below is a close up of the staging section from the image above, containing the data point names.

Level 4 close up

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 Boundary icon , 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:

  1. The data point “Joint” can have a value of “Left elbow”, “Right elbow”, “Left knee”, “Right knee”, “Left ankle” or “Right ankle”.
  2. 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”.

Boundaries

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.

 

OpenCancer is born!

OpenCancer was founded to tackle the problems we face with clinical data collection in cancer. There is universal agreement that good data collection underpins modern medical practice, yet we struggle to achieve this. OpenCancer aims to tackle a few of the root causes:

  1. Develop open data models that match clinical, research and reporting needs.
  2. Share best practice in the development of clinical pathways.
  3. Develop reusable technological elements by providing tools and APIs for use cases such as prognostic scoring and auto-identification of trial patients.

Data Modelling

We pride ourselves on a very detailed level of cancer data collection in the NHS. However, this process has been allowed to proliferate in an uncontrolled manner such that different registries stipulate data items that are confusingly similar, but not the sameBy example for a single cancer patient we are asked / obliged to submit closely related data fields to the following registries:

  • Cancer Outcomes and Services Dataset (COSD)
  • Systemic Anti-Cancer Therapy (SACT)
  • National Radiotherapy Dataset (RTDS)
  • National audits such as The National Prostate Cancer Audit (NPCA) and The British Association of Urological Surgeons (BAUS).

There are also newer projects such as The 100,000 Genomes project and The NIHR Health Informatics Collaborative, which overlap with these datasets and mandate the collection of even more data.

Very few hospitals collect this data in clinically-facing systems. Instead we separate this process into the back office, often employing non-clinical staff using non-clinical systems. This results in a significant overhead to the delivery of clinical care, and invariably leads to inconsistencies in data between the different systems.

“Data collection remains problematic in medicine.”

This has to change.

The only sustainable solution is to collect this data as a consequence of the delivery of care. This would not only address the issues of administrative overhead and data provenance, but would incentivise the clinical team to capture good quality data.

“If the data I enter is useful to me and my patient (and not just used for a registry), I will make sure I enter high quality data.”

The data would be collected once and reused through the clinical journey, but would also feed many different reporting datasets.  To achieve this goal, we must agree one data model for cancer, which needs to extend and be compatible with the data model for the delivery of all aspects of care across the NHS. This data model would be used in all clinical systems which collect cancer data, and would also underpin the structure of the data used for registry reporting and research.

“We need a single information model which underpins clinical care, registry data collection and research.”

Clinical Pathways

To translate the information models to real world use, one must consider the different steps of the clinical pathway, and the role of data at each step. Eg At the point of referral from the GP:

  • What data does the GP need to send to allow initial triage?
    • Can this be extracted automatically from the GP system?
    • Is there extra information (such as patient preference) which needs to be entered manually?
      • Who will enter this data?
  • What additional tests may be useful before the initial clinical visit?
    • Can these be requested automatically?
    • Can we pull these results in automatically?

“This pathway modelling is just as important as the information modelling to ensure good data capture, and most importantly good clinical care.”

With OpenCancer, we aim to document and share exemplars of good clinical modelling, to maximise learning from these projects. These pathway models may act as templates for institutions who are to undergo a similar service redesign.

Reusable Resources (including APIs)

We aim to provide useful web-based resources for both patients and healthcare professionals, including:

  • Prognostic and risk scoring calculators.
  • Clinical trial eligibility checkers.
  • Coded lists for common cancer related classification systems such as the CTCAE (Common Terminology Criteria for Adverse Events).

These will be provided as:

  • Simple web pages and apps for patients and clinicians.
  • APIs for incorporation of this functionality into third party apps, generic electronic patient record systems or specialist systems.

Currently every health IT platform, from single departmental systems to megasuite electronic health records, has to build this functionality for their own system. This is expensive, inefficient and ultimately unsustainable at a national scale.

The provision of these tools at a national level has the potential to improve healthcare in an equitable fashion, and accelerate the benefits of the digitisation of cancer care.