Making complex clinical data visible before it becomes a model
hannah
A blood pressure reading looks simple until Ian McNicoll asks what it must mean inside a medical record. Which units should it support? What was the patient’s position? What context needs to travel with the number? For Ian, a clinical informatician and former Scottish general practitioner, questions like these sit between medicine and software.
As founder and chief executive officer of freshEHR Clinical Informatics and a board member and former co-chair of openEHR International, Ian helps turn clinical knowledge into reusable data models. Long before those models reach a technical system, he and the wider openEHR community use Xmind to make their structure visible.
Try Xmind to give complex expert knowledge a shape people can examine together.
One measurement can contain a whole tree of decisions
When Ian explains clinical data modeling, he often starts with something familiar: body weight. Recording it might appear to require a single number. Then the questions begin. Should the model accept kilograms and imperial measurements? Was a child weighed with clothes on? Does the measurement need a comment? How will the same concept work across different languages?
Blood pressure brings its own branches: systolic and diastolic values, the patient’s posture, the circumstances of the reading, and the surrounding clinical context. Each answer can reveal another decision that needs to be represented clearly.
Ian describes medical data and ideas as treelike and fractal. Their meaning depends not only on individual data points, but also on how those points relate to one another. For the people building shared clinical models, the challenge is not simply collecting information. It is finding a structure that clinicians can understand, question, and refine before anything is fixed in software.
A map bridges the spreadsheet and the system
Ian’s maps occupy a specific place in the modeling process. They sit between the requirements supplied by clinicians and the formal models that software systems will eventually use.
From clinical requirements to a visible structure
The work often begins with a spreadsheet from a clinical group. An eye specialist, for example, may list all the information that needs to be collected about glaucoma. The rows capture the requirements, but they do not necessarily reveal the clinical shape behind them.
Ian rebuilds that material in Xmind. A mixed structure—an Org Chart near the top and a Tree Chart further down—lets him move from the broad organization of a dataset into its more detailed clinical branches. He can connect requested data points to existing openEHR models and see where new work may be needed.
Each visual choice carries practical meaning:
Markers show which data points are ready and which still need attention.
Boundaries keep related code lists together.
Notes preserve explanations from the original source.
Outliner presents the same structure in a linear form when that is easier to review.
Together, these details help Ian turn a flat spreadsheet into a structure that reflects how clinicians understand the data.
From a working map to a formal data model
The map is not the finished clinical model. It is the preparatory space where the community interprets a spreadsheet, arranges its relationships, and decides how each part belongs within a larger clinical picture.
Once the structure is clear, dedicated openEHR tools are used to create formal archetypes and templates that software systems can work with. These models can then be reviewed, translated, versioned, and added to a shared library.
Xmind does not replace clinical expertise or technical modeling. It gives both sides a common place to decide what the model should mean before that meaning is expressed in code.
One structure becomes a language for a community
Ian first brought Xmind into the workflow at least a decade ago, after the community had tried another mind-mapping tool. The ability to combine structures suited the way its models developed. Without any formal requirement to use it, Xmind gradually became what Ian calls the community’s “de facto standard” for this early stage of the tool chain.
The openEHR community is international and collaborative. Clinicians and modelers share .xmind files in its discussion forum, review models, translate them, and return the finished work to a common library. Experienced members may recommend Xmind when newcomers ask what they use, but the tool matters because the structure is useful, not because participation depends on it.
That shared visual language helps people with different backgrounds meet in the middle. A clinician does not need to read a technical modeling language to examine whether the branches reflect real practice. A modeler can trace how each requested field belongs within the wider clinical picture.
The formal models produced through this broader process support healthcare projects in several countries, including the Universal Care Plan in London and openEHR initiatives in Germany, Slovenia, and Ireland. The scale comes later. The first step is still a group of people making sure they mean the same thing.
The model starts with a question people can see
For Ian, a mind map is most useful before the answers look final. It keeps clinical assumptions visible while they can still be challenged, reorganized, and improved. By the time a model reaches a data store, much of its meaning has already been decided.
The finished system may contain a blood pressure, a body weight, or a patient’s wishes. Behind each field is a tree of choices that someone had to make explicit. Ian’s work begins by giving those choices a form that clinicians and technologists can see together.
