複雑な臨床データをモデル化する前に可視化する

血圧の測定値はシンプルに見えますが、Ian McNicoll 氏が「カルテの中でのその意味」を問い直すと、その見方は一変します。サポートすべき単位はどれか？患者の姿勢はどうだったか？数値とともにどのようなコンテキストを維持すべきか？臨床情報学者であり、元スコットランドの一般開業医でもある Ian にとって、このような問いは医療とソフトウェアの境界線上に存在します。

freshEHR Clinical Informatics の創設者兼最高経営責任者（CEO）であり、openEHR International の理事および元共同議長でもある Ian は、臨床知識を再利用可能なデータモデルへと変換する支援を行っています。それらのモデルが技術的なシステムに組み込まれるはるか前に、彼と openEHR コミュニティは Xmind を使用してその構造を可視化しています。

複雑な専門知識を、人々が共に検証できる形にするために Xmind をお試しください。

1つの測定値に、意思決定のツリー全体が含まれている

Ian が臨床データモデリングについて説明する際、よく身近な例として挙げるのが「体重」です。体重の記録は、単一の数値を入力するだけで済むように思えるかもしれません。しかし、そこから問いが始まります。モデルはキログラムとヤード・ポンド法の両方を受け入れるべきか？子供は服を着たまま体重を測定されたか？測定値にコメントは必要か？同じ概念を異なる言語間でどのように機能させるか？

血圧測定においては、さらに多くの分岐が生じます。収縮期および拡張期の数値、患者の姿勢、測定時の状況、そしてそれを取り巻く臨床的コンテキストです。それぞれの答えが、明確に表現されるべき新たな意思決定を浮かび上がらせます。

Ian は、医療データやアイデアを「ツリー状」で「フラクタル」なものであると表現します。その意味は、個々のデータポイントだけでなく、それらのポイントが互いにどのように関連しているかによって決まります。共有の臨床モデルを構築する人々にとって、課題は単に情報を収集することではありません。ソフトウェアに固定される前に、臨床医が理解し、疑問を投げかけ、洗練させることができる構造を見つけ出すことなのです。

マップがスプレッドシートとシステムを橋渡しする

Ian のマップは、モデリングプロセスにおいて特定の役割を担っています。それらは、臨床医から提供される要件と、最終的にソフトウェアシステムが使用する正式なモデルの間に位置しています。

臨床要件から目に見える構造へ

仕事は多くの場合、臨床グループから提供されるスプレッドシートから始まります。例えば、眼科専門医が緑内障に関して収集する必要のあるすべての情報をリストアップすることがあります。行には要件が記載されていますが、それだけではその背後にある臨床的な全体像が必ずしも見えてくるわけではありません。

Ian はその資料を Xmind で再構築します。上部には「組織図」、下部には「ツリー図」を組み合わせたハイブリッドな構造を使用することで、データセットの広範な構成から、より詳細な臨床の分岐へと進めるようになります。要求されたデータポイントを既存の openEHR モデルに関連付け、どこに新しい作業が必要かを見極めることができます。

それぞれの視覚的な選択には、実用的な意味があります。

マーカーは、どのデータポイントの準備ができており、どれにまだ対応が必要かを示します。
囲みにより、関連するコードリストをまとめて維持します。
ノートは、元の情報源からの解説をそのまま保存します。
アウトライナーは、リニア（線形）な形式でレビューする方が簡単な場合に、同じ構造をテキストリストで表示します。

これらの詳細を組み合わせることで、Ian は平坦なスプレッドシートを、臨床医がデータをどのように理解しているかを反映した構造へと変換することができます。

動的なマップから正式なデータモデルへ

マップは完成された臨床モデルそのものではありません。それは、コミュニティがスプレッドシートを解釈し、その関係性を整理し、各部分がより大きな臨床像の中でどのように位置づけられるかを決定するための準備スペースです。

構造が明確になると、openEHR の専用ツールを使用して、ソフトウェアシステムが処理できる正式な「アーキタイプ」や「テンプレート」が作成されます。その後、これらのモデルはレビュー、翻訳、バージョン管理が行われ、共有ライブラリに追加されます。

Xmind は臨床の専門知識や技術的なモデリングに代わるものではありません。それは、モデルが何を意味すべきかをコードで表現する前に、双方が共通の場所で意思決定を行うための場を提供します。

1つの構造がコミュニティの言語になる

Ian がワークフローに初めて Xmind を導入したのは、コミュニティが別のマインドマップツールを試した後、少なくとも10年前のことです。複数の構造を組み合わせられる柔軟性が、モデルの発展プロセスにマッチしていました。使用を義務付ける正式なルールがなかったにもかかわらず、Xmind は次第に、Ian がツールチェーンのこの初期段階における「事実上の標準（デファクトスタンダード）」と呼ぶものになりました。

openEHR コミュニティは国際的で協調的な組織です。臨床医やモデラーは、ディスカッションフォーラムで .xmind ファイルを共有し、モデルをレビュー・翻訳して、完成した成果物を共通のライブラリに戻します。経験豊富なメンバーは、新規参入者から使用ツールについて尋ねられた際に Xmind を勧めることがありますが、このツールが重要視されているのは、参加条件だからではなく、その構造化の仕組みが極めて有用だからです。

この共有された視覚的言語は、異なる専門背景を持つ人々が歩み寄る手助けをします。臨床医は、ツリーの分岐が実際の医療現場を反映しているかを検証するために、技術的なモデリング言語を読む必要はありません。モデラーは、要求された各フィールドがより広い臨床像の中でどのように位置づけられているかを視覚的に追うことができます。

この広範なプロセスを通じて作成された正式なモデルは、ロンドンの Universal Care Plan や、ドイツ、スロベニア、アイルランドにおける openEHR イニシアチブなど、数カ国の医療プロジェクトを支えています。システムのスケールアップは後からついてきます。最初のステップは常に、関係者全員が「同じことを意味しているか」を確認することから始まります。