在複雜的臨床數據成為模型之前，先將其可視化
血壓讀數看似簡單，直到 Ian McNicoll 提出這在病歷中代表著什麼。它應該支援哪些單位？患者當時的姿勢如何？還有哪些上下文資訊需要隨數字一同傳遞？對於身為臨床資訊學家且曾任蘇格蘭全科醫生的 Ian 來說，此類問題正處於醫學與軟體之間的交界地帶。
作為 freshEHR Clinical Informatics 的創辦人兼執行長，以及 openEHR International 的董事會成員和前共同主席，Ian 協助將臨床知識轉化為可重複使用的數據模型。早在這些模型進入技術系統之前，他和更廣泛的 openEHR 社群就已經使用 Xmind 來讓其結構可視化。
立即體驗 Xmind，為複雜的專家知識勾勒出大家可以共同檢視的具體結構。
單一測量值背後可能包含決策的整棵樹
當 Ian 解釋臨床數據建模時，他通常會從大家熟悉的事物開始：體重。記錄體重似乎只需要一個數字。但隨後問題接踵而至。模型是否應該同時接受公斤和英制單位？兒童量體重時是否有穿衣服？這個測量值需要備註嗎？相同的概念在不同的語言中要如何運作？
血壓也帶來了其分支問題：收縮壓和舒張壓數值、患者的姿勢、量測時的情況，以及周圍的臨床背景。每一個答案都可能揭示另一個需要被清晰呈現的決策。
Ian 將醫療數據和想法描述為樹狀且具分形特徵。其意義不僅取決於單一的數據點，還取決於這些數據點之間如何相互關聯。對於建構共享臨床模型的人來說，挑戰不僅在於收集資訊，而是在將任何內容固定在軟體中之前，找到一個臨床醫生能夠理解、質疑和完善的結構。
心智圖架起電子表格與系統之間的橋樑
Ian 的導圖在建模過程中佔據了特定的位置。它們介於臨床醫生提供的需求與軟體系統最終將使用的正式模型之間。
從臨床需求到可視化結構
工作通常始於臨床小組提供的電子表格。例如，眼科專家可能會列出所有需要收集的青光眼相關資訊。這些行記錄了需求，但並不一定能揭示背後的臨床結構。
Ian 在 Xmind 中重構這些材料。結合了多種結構——頂部使用組織架構圖，下方使用樹狀圖——這讓他能夠從數據集的宏觀組織深入到更詳細的臨床分支。他可以將要求的數據點與現有的 openEHR 模型連結，並找出哪些地方可能需要新的工作。
每個視覺選擇都帶有實用意義：
標記顯示哪些數據點已準備就緒，哪些仍需要關注。
外框將相關的代碼列表歸類在一起。
筆記保留了原始來源的解釋說明。
大綱模式在便於檢視時，以線性形式呈現相同的結構。
這些細節共同幫助 Ian 將扁平的電子表格轉化為反映臨床醫生如何理解數據的結構。
從工作導圖到正式數據模型
導圖並非最終的臨床模型。它是一個準備空間，社群在這裡解讀電子表格、整理其關係，並決定每個部分如何在更大的臨床情境中定位。
一旦結構清晰，就會使用專用的 openEHR 工具來建立軟體系統可以運作的正式原型和模板。然後，這些模型可以被審查、翻譯、版本化，並添加到共享庫中。
Xmind 並不取代臨床專業知識或技術建模。它為雙方提供了一個共同的空間，在將含義表達為代碼之前，先決定該模型應該代表什麼。
一個結構演變為社群的共同語言
至少在十年前，社群嘗試了另一款心智圖工具後，Ian 首次將 Xmind 引進了工作流程。結合多種結構的能力非常適合其模型的發展方式。在沒有任何強制使用的官方要求下，Xmind 逐漸成為 Ian 所稱的社群在工具鏈初期階段的「事實標準」。
openEHR 社群是國際化且協同合作的。臨床醫生和建模人員在討論論壇中分享 .xmind 檔案、審查模型、進行翻譯，並將完成的工作交回公共庫。當新手詢問使用什麼工具時，資深成員可能會推薦 Xmind，但該工具之所以重要，是因為其結構實用，而不是因為參與必須依賴它。
這種共享的視覺語言幫助擁有不同背景的人們達成共識。臨床醫生不需要閱讀技術建模語言，即可檢視這些分支是否反映了實際情況。建模人員也可以追蹤每個需求欄位在更廣泛的臨床情境中是如何定位的。
透過這一更廣泛流程產生的正式模型，支援了多個國家的醫療保健專案，包括倫敦的 Universal Care Plan 以及德國、斯洛維尼亞和愛爾蘭的 openEHR 計劃。規模化是後話，第一步仍然是一群人確保他們理解的是同一件事。
模型始於一個大家都能看見的問題
對 Ian 來說，心智圖在答案尚未定案之前最為有用。它讓臨床假設保持可視狀態，此時這些假設仍可被質疑、重組和改進。當一個模型進入數據庫時，其大部分含義早已被決定。
最終的系統可能包含血壓、體重或患者的意願。在每個欄位後面，都是一棵必須由某人明確做出的選擇之樹。Ian 的工作，正是從為這些選擇提供一個臨床醫生和技術人員可以共同看見的具體形式開始。
