在复杂临床数据转化为模型之前，实现其可视化
直到 Ian McNicoll 询问血压读数在医疗记录中必须代表什么含义时，这个看似简单的读数才变得复杂起来。它应该支持哪些单位？患者当时的姿势是怎样的？该数值需要随之传输哪些背景信息？对于临床信息化专家及前苏格兰全科医生 Ian 而言，诸如此类的问题正处于医学与软件的交界地带。
作为 freshEHR Clinical Informatics 的创始人兼首席执行官，以及 openEHR International 的董事会成员和前共同主席，Ian 致力于帮助将临床知识转化为可重用的数据模型。在这些模型进入技术系统之前很久，他和更广泛的 openEHR 社区就已经在使用 Xmind 来使其结构可视化了。
尝试使用 Xmind，让复杂的专家知识呈现出人们可以共同检视的清晰形态。
一个测量值可能包含一整棵决策树
当 Ian 解释临床数据建模时，他通常会从大家熟悉的事物开始：体重。记录体重似乎只需要一个数字。但随后问题就接踵而至：该模型是否应该同时接受公斤和英制单位？儿童称重时穿着衣服吗？该测量值需要备注吗？同一个概念在不同的语言中将如何应用？
血压也带来了其自身的分支：收缩压和舒张压数值、患者的姿势、测量时的环境以及周围的临床背景。每一个答案都可能揭示出另一个需要被清晰呈现的决策。
Ian 将医学数据和想法描述为树状的和分形（fractal）的。它们的意义不仅取决于单个数据点，还取决于这些数据点之间是如何相互关联的。对于构建共享临床模型的人来说，挑战不仅仅在于收集信息，更在于寻找一种结构，让临床医生在软件中固定任何内容之前，能够理解、质疑并完善它。
导图桥接了电子表格与系统
Ian 的思维导图在建模过程中占据着特定的位置。它们介于临床医生提供的需求与软件系统最终使用的正式模型之间。
从临床需求到可视化结构
这项工作通常始于临床小组提供的电子表格。例如，一位眼科专家可能会列出所有需要收集的关于青光眼的信息。表格的行记录了这些需求，但它们不一定能揭示其背后的临床形态。
Ian 在 Xmind 中重构了这些材料。一种混合结构——顶部使用组织结构图，下方使用树状图——使他能够从数据集的宽泛组织层面深入到更详细的临床分支。他可以将所需的数据点连接到现有的 openEHR 模型中，并观察哪些地方可能需要新的工作。
每一个视觉选择都承载着实际意义：
标记显示了哪些数据点已准备就绪，哪些仍需关注。
外框将相关的代码列表聚集在一起。
笔记保留了来自原始来源的解释。
在更易于复阅时，大纲以线性形式呈现相同的结构。
结合这些细节，Ian 成功将一份扁平的电子表格转化为了反映临床医生如何理解数据的结构。
从工作导图到正式数据模型
思维导图并不是最终的临床模型。它是一个准备空间，社区在这里解读电子表格、整理其关系，并决定每个部分如何归属于更大的临床图景。
一旦结构清晰，就会使用专门的 openEHR 工具来创建软件系统可以运行的正式原型（archetypes）和模板。然后，这些模型可以被复阅、翻译、进行版本控制，并添加到共享库中。
Xmind 并不能取代临床专业知识或技术建模。它为双方提供了一个共同的空间，以便在将这些模型含义用代码表达之前，决定其应该代表什么。
一个结构成为社区的语言
至少在十年前，在社区尝试了另一种思维导图工具之后，Ian 首次将 Xmind 引入到了工作流中。结合不同结构的能力非常契合其模型的开发方式。在没有任何正式使用要求的情况下，Xmind 逐渐成为了 Ian 所说的该工具链早期阶段社区的“事实标准”。
openEHR 社区是国际化且通力协作的。临床医生和建模人员在讨论论坛中分享 .xmind 文件，复阅模型、翻译它们，并将完成的工作返回到公共库中。当新手询问他们使用什么工具时，资深成员可能会推荐 Xmind。但该工具之所以重要，是因为其结构实用，而不是因为参与必须依赖于它。
这种共享的视觉语言帮助具有不同背景的人们找到了契合点。临床医生不需要阅读技术建模语言来检视这些分支是否反映了真实的临床实践。建模人员可以追踪每一个需求字段如何归属于更广泛的临床图景。
通过这种更广泛的流程生成的正式模型支持了多个国家的医疗项目，包括伦敦的 Universal Care Plan，以及德国、斯洛文尼亚和爱尔兰的 openEHR 计划。规模化是后话，第一步依然是让一群人确保他们所指的是同一件事。
模型始于一个人们看得见的问题
对于 Ian 来说，思维导图在答案看起来最终确定之前最为有用。它让临床假设保持可见，以便人们仍然可以对其进行质疑、重组和改进。当一个模型到达数据存储库时，其大部分含义早已被决定。
最终的系统可能包含血压、体重或患者的意愿。每个字段的背后都有一棵选择树，必须有人将其明确化。Ian 的工作始于将这些选择转化为临床医生和技术人员可以共同看到的直观形式。
