インタラクションを基盤とした医療情報システムの進化

1.8K Views

September 08, 25

スライド概要

従来の医療情報システムは「記録・保管・共有」を中心に設計されてきました。しかし、現代医療は患者と医療者の双方向的な関わりに加え、医療者同士の認知や意思決定の相互作用によって成り立つ複雑な営みへと変化しています。本発表では、こうした変化に応えるべく構築した新しい医療情報基盤 HiPER2.0 を紹介します。

HiPER2.0は、ストリーミング処理によってバイタルサイン・検査値・モニタリングデータ・位置情報など多様なデータストリームを逐次解析し、臨床現場の「今」を映し出す デジタルツイン を形成します。これにより、医療者の時間的認識の齟齬を補正し、必要な情報を「誰に・いつ・どのように」届けるかという課題に応えます。

さらに、SQL型データベースでは困難な逐次状態遷移モデルを、Key-ValueストアとB-tree構造による独自のストリーミング処理基盤で実現。アウトオブオーダー処理の制御やスナップショット保存を組み込み、ACID特性に近い一貫性と再現性を確保しました。

本講演では、リアルタイム処理の技術的課題とその克服、UIへの応用(根拠データのマウスホバー提示、リアルタイム音声プッシュ通知など)、そして臨床現場における実際の活用可能性を具体的に示します。医療情報システムを「記録の器」から「意思決定を支える相棒」へと転換する挑戦を、ぜひ共有したいと考えています。

profile-image

医療とIT、イノベーション、人と人が出会ったときの化学反応が好き。次世代インターフェースを考えて、CDSSにAmbient Intelligenceを掛け合わす。小児科医、アレルギー専門医、TMUG会長

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

ダウンロード

関連スライド

各ページのテキスト
1.

    山本 康仁 都立広尾病院 院長補佐 情報統括センター長 

2.

イントロダクション 医療は、患者と医療者のみならず、より医療者同士のインタラクション(相 互作用)によって成り立つ姿に変化しました。 これまでの医療情報システムは「記録・保管・共有」に重点を置いてきまし た。 今後必要なのは、インタラクションそのものを基盤とし質を高めるシステム ではないでしょうか。 つまり、情報の受け渡しにとどまらず、意思決定・認知のプロセスに寄り添 う仕組みが求められているのです。

3.

リアルタイム処理の意義 ストリーミング処理による遅延のない解析 バイタルサインや検査値、観察項目の逐次解析 医療者の位置情報、システム入力内容から意思決定パターンを描出 数々のデータストリームから予測モデルを生成し、複数のモデルからさらに リアルワールドをミラーリングする「デジタルツイン」 臨床現場で「今」必要な情報提供するために、デジタルツインを活用

4.

REAL-TIME DIGITAL TWIN 網 部門システムを含む 全病院的な情報収集 深 カルテ記載を代表とする、これまで 利用できなかった情報の活用 細 重症系モニタの全パラメータ取り込み など、より詳細な情報 即 データが動いたら、即座に収拾、処理し て実時間で病院全体を掌握、デジタル化 患者情報だけでなく、病院全体で起きる事象と医療従事者の認知空間も含めてデ ジタル化。実際の病院のデジタル模型をコンピュータ空間に構築する。

5.

認知空間の齟齬と時間 情報の発生と医療者が気づくタイミングには必ずズレがあります。 これは時間的認識の齟齬であり、患者リスクを見逃す原因になります。 リアルタイムシステムは即座に検知できるが、全てを通知すると注意散漫に つながります。 重要なのは「どの情報を、誰に、どのタイミングで伝えるか」です。

6.

HiPER2.0 • Enterprise Service BUS 2005 診療判断支援 読影レポート 内視鏡レポート 生理検査レポート 2007 音声合成、位置情報活用 110 160/96 60/ 6 2008 情報収集解析(ESB) 2013 重症系モニタ接続 2015 WIFI位置情報 110 160/96 60/ 6 110 160/96 60/ 6 HiPER 2.0 生体モニタ+重症系 電子カルテ 2023 全生体モニタ接続 検体検査システム 電話交換機 WIFI+Mobility Service Engine

7.

HiPER2.0が採用したStream Processとは SQLは 強い整合性・集計・帳票文化への親和性 一方、リアルタイム処理は? 利点 リアルタイム処理を実装すると ACIDトランザクションで一貫性が強固 同時更新競合が頻発 監査、DPC算定なの再集計に強い 排他ロックが伝播 人材、ツールが豊富 トリガや排他制御の連鎖で スループットが急低下 ストリームは 低遅延・並列性・イベント駆動 が強み イベント駆動で低遅延応答 逐次状態遷移モデルに強い 分散モデルでスケーラブル モデル別に独立演算でスループット向上

8.

SQLとStream Process SQL Stream Process Process Process Process Process Process Process ACID保証だが、状態遷移モデルに対しての データ重複部分が多く、排他が起きやすい。 分散処理に向かない それぞれ独立した空間に状態遷移モデルと関 連データを個別に展開、別モデルとの関係性 は参照が主体で、排他が起こり難く分散処理 ができる。

9.

HiPER Stream Processの高速化について アプリケーション層は Key-Value Store を用いて高速アクセス 複数の医療モデルをKVで即時参照可能 キャッシュ+KV で低遅延化し、RDB照 会より効率的 ビジネスロジックを実現する テーブルは目的別に大量に重複

10.

HSPの弱点と対策 再現性 • ストリーム処理は過去の再現が難しい」と指摘されるが、 適時スナップショットを保存する 仕組みを導入し、イベント発火時の状態を復元可能にすることで解決している。 集計の多重実行 • SQLと異なり、ストリーム処理では集計タスクが重複しコストが高いことが指摘される。こ れに対し、処理遅延を適切に設定し、ストリームの中で先行する重複タスクを抑制する制御 を行い、効率化を図っている。 ACID保証

11.

ACID保証の懸念と対策 課題 • RDBはACID特性 (Atomicity, Consistency, Isolation, Durability) を強固に保証 • 一方、ストリーム処理は分散並列で進行するため、処理順序の乱れ(アウトオブオーダー) が発生しやすく、「結果が破綻するのではないか」と指摘されることがある。 対策 • 本システムでは アウトオブオーダー制御(処理の順番が前後しないようにする仕組み)を組 み込み、イベントの発生時刻や論理順序を考慮することで、結果の確実性を制御している。 • これにより、ACIDと同等の厳密さはないものの、医療業務で必要な一貫性と信頼性を十分に 確保できている

12.

問題点を長所として利用する スナップショット データの根拠となる引用元データや理由をペイロードとして持た せ、例えばマウスホバーで表示させるなどのUIに活用 アウトオブオーダー処理のための確定フラグ作成ロジック リアルタイム警告をバインド高度なアラート発出に転用 正規化されない大量のKey-Value Storeが発生 JSON化してディレクトリ構造(B-tree)に格納、高速UIに活用

13.

HiPER2.0 • Architecture 独自のストリーミング処理による リアルタイムモデル構築 数百万テーブル相当のモデル記述構 造をKey-valueで保存(DataCube) Streaming Processing engin B-treeでステイトフルデータの集合 体でUIを高速化 楽観的UIと非同期処理によるサーバ レスポンスレイテンシーを隠蔽 リアルタイムVoiceメッセージによ Clinical models Stateful JSON data るプッシュ伝達 Voice messages