Integrating the Healthcare Enterprise

The IHE Initiative Worldwide「SWF」を採用したシステム構築の実際
日本IHE協会 普及推進/放射線企画委員会

松田 恵雄
埼玉医科大学総合医療センター

日本ＩＨＥ協会 普及推進委員会

113

IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

本日のポイント
IHEを採用すれば、システム構築は完了でしょうか？
「IHEでいけるもの」については、「テクニカルフレームワーク通り」に実装すればシステム連携は完璧でしょうか？

IHEの採用で満足度の高いシステム導入になるのでしょうか？
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

埼玉医科大学総合医療センター
埼玉県にある私立医科大学
・医学部/保健医療学部/大学院/研究施設
・県内に医療機関を四拠点運営

埼玉医科大学総合医療センター
埼玉県川越市
病床数/外来患者数 913床/約2000人/日
平成17年3月（約6年前）
電子カルテ稼働開始

EG-MAIN-EXWeb版「医療情報システムにおける相互運用性の実証事業」
JAHIS放射線データ交換規約を採用

IHE-Jを用いた国内初のシステムが稼働
放射線オーダーIHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

IHEを採用するということIHEを採用すれば、システム構築は完了でしょうか？
それは違います。

IHEの採用は、システム構築上の一部を肩代わりしてくれますが、全てを担保してくれません。
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

システム構築に必要な作業
適切なベンダの選定と契約………… △システム個別の機能要件定義…….. ×
ワークフロー洗い出しとシステム設計 ○システム構成と機器調達…………… ×
システム間の連携仕様策定……….. ◎システム間の連携項目策定……….. ×
連携する値（マスタ）の策定………… ×
システムの運用対策・管理規定……. ×
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

IHEを採用したシステム導入ではテクニカルフレームワークで規定された機能やシステム間連携」について改めて仕様調整する必要がない。
→「SWFでお願い」といえば、概ね大丈夫
IHEに規定されていない機能や連携従来通り正しく指定しないと実現しない
IHEの「テクニカルフレームワーク」で規定されている仕様と、指定されていないが必須な要件を、切り分けてそれぞれ発注する必要がある。
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

IHEを指定することで減る負担
部分的ではあるものの最低限の接続性保証
標準的技術への包括対応
マルチベンダ間の連携仕様に関する綱引き調
整が不要に→ベンダに詳細調整を任せられる変換インターフェース再発注からの解放

業務フロー見直しのたたき台作成作業

IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

IHE-Jの指定では減らない負担
実際の業務フローの洗い出しと見直し
連携手法が保証された上での、「どの項目を連携させればよいか」、「現在の策定項目数で十分かどうか」の検討
 フリーコメントの種類
 依頼日の定義
 職員名は漢字氏名なのか職員コードなのか 連携情報のサイズ連携が保証されているのは、連携のための手法や技術仕様であり、項目や内容ではない
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

IHE-Jが定義していない実装
1.

電子カルテからの画像連携（呼び出し）方法

2.

画像診断報告書（レポート）の電子カルテへの返信仕様

3.

MWM（Order FillerからAcquisition Modalityへの検査情報送信）の構文詳細

4.

レポーティングシステムにおけるImage Displayとの画像連携手法

5.

マスタの構築方法

6.

非IHEオーダとのオーダ情報整合方法
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

IHEにして不便になったことの例【例】透視検査室で行う透視下内視鏡検査
内視鏡検査のオーダと合わせて放射線検査オーダの発行（撮影室予約）が必要
IHE単独では実装できないがローカル仕様

では実装可能電子カルテ全体が均質な標準的技術で実装されるに至らず、個別の拡張としてIHEを組み込む場合に発生（IHEというシステム非標準の発生）
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

Order Placerにおける連携情報種別の設計
HL7による情報の連携は、IHE-Jの性質上Order Placer上での入力情報が、各システムに連携されることで重複入力などの煩雑な操作を回避可能な反面、Order Placer上で入力漏れが発生すると、下流のシステムで必要な情報項目が届かない可能性がある。

つまり、Order Placer（電子カルテ）で、どの様な情報を取り扱うか（Order Placerで何を入力してもらうか）の検討にかなりの時間を要する。
IHE Workshop in Tokyo

2011.06.11 Tokyo-Midtown

IHEを採用するということ「IHEでいけるもの」については、「テクニカルフレームワーク通り」に実装すればシステム連携は完璧でしょうか？
いいえ、そうはいきません。

IHEは「あるべき姿」を追求しています
ので、理想ではありますが、最終的には、自施設の現状に合わせて部分的に変更する必要があります。
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

IHEはそのまま使えるのか？
…
患者登録システム

OrderFiller

Order Placer
エビデンス
クリエータ

Viewer

PPS
マネージャ

画像サーバ

モダリティ

IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

埼玉医大の「SWF統合プロファイル」
患者登録

読影室

オーダ発行
報告書作成端末（Report Creator）（Report Reader）
医事システム（ADT）

画像表示装置（Image Display）

電子カルテシステム（HIS）

実施
受付
画像報告書システム（Report Manager）（Report Repository）
放射線情報システム（RIS）

検査開始
検査終了

透視（DR）装置（Acquisition Modality）

画像サーバ（Image Manager・Image Archive）

IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

ADTの実装状況は？
…

IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

埼玉医大の「SWF統合プロファイル」
患者登録

読影室

オーダ発行
報告書作成端末（Report Creator）（Report Reader）
医事システム（ADT）

画像表示装置（Image Display）

電子カルテシステム（HIS）

実施
受付
画像報告書システム（Report Manager）（Report Repository）
放射線情報システム（RIS）

検査開始
検査終了

透視（DR）装置（Acquisition Modality）

画像サーバ（Image Manager・Image Archive）

IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

埼玉医大の「ADT実装状況」
患者登録
ADT機能

医事システム

電子カルテシステム（HIS）

放射線情報システム（RIS）

IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

ADTについて…
本来（TF)のATDは独立したサブシステムとして定義

現在の国内における病院情報システムで純粋な「ADT」を実装するのは枠組み的に困難 医事（会計）システム→電子カルテ→部門システム

 部門システム→電子カルテ→医事（会計）システム

患者の移動情報等
 ADTの連携としては、そのまま担保されない。

ITIではPAM（Patient Administration Management ）を推奨
 ADTの機能は、SWFだけでなくPIRでも使用されるが、IHE-ITIではPAMによる実装を推奨。→国内展開が鍵。

IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

例：患者移動情報について
放射線オーダが発行された後に患者が所在を変更
 転科による病棟変更
 病状等の理由による病室移動

オーダ時の患者所在情報は発行時点での情報
 発行と同時に過去の情報となりえる 【対策】ADTにより常に患者所在情報を更新する
 【問題点】ADT側から対象患者様に放射線検査オーダが発行されるかどうかは不明→全ての患者様の移動情報をOrder Placerに送信するか？→部門システム側の負荷が非常に増大

最新の患者所在情報をリアルタイムに取得する方が良いという考え方もある PAMの様な患者情報照会での情報連携
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

IHEを採用すれば導入が成功するか？
IHEの採用で満足度の高いシステム導入になるのでしょうか？
いいえ、それは疑問です。

IHEはシステム構築や連携、更新時にその威力を発揮しますが、通常の評価には現れません。
当たり前のことが簡単にできるだけ。
当たり前のことには評価が伴わない。
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

味付けのない「標準」はブーイング
IHEでは、そのシステムにおけるアクタ（正に役割）定義とその連携定義しかない。
当然、「スコープ外」となる、現実業務との差分に関し、問題解決の方法を考える必要がある。
このとき、 「スコープ外」の解決法を整理してアクタと共存させるか独立させるかを判断することが重要！
 【製品単位での綺麗な切り口が、IHE採用において、最も効果的。】
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

埼玉医大のシステム構成
独自開発

パッケージ製品
医事

医事システム

電子カルテ

RIS

検像システム

PACS

出力入力

入力

出力

電子カルテ
標準出力

標準入力

標準入力

標準出力

RISRISパッケージ本体
標準出力

標準入力

標準入力

標準出力

検像
標準出力

標準入力

標準入力

標準出力

PACS
標準出力
標準入力

報告書システム

標準規格（IHE等）

標準入力
標準出力

報告書

IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

埼玉医大が何を独自開発したか「コンテンツ」の整合を図る
 DICOMのタグ情報を均質にする•

受付番号の整合・日本語補完

画像自体の品質を向上する
 確定保存のためのツール•

最終処理と真正性の概念保持

 検像システム•

画像の確認・並び替え・編集

医療安全に資する
 医療安全••確定保存画像の安全確保
患者情報の自動チェック
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

標準が全てを解決してくれる訳ではない
HL7やDICOMだけに頼った構築では、解決できない問題もある。→解決できないことが殆ど。
（というか誇大な妄想は捨てる潔さが重要。）

1. IHEが何を解決してくれるのか正確に把握することでスコープ範囲を同定する。
2. JAHIS放射線データ交換規約の正確な知識を得、連携パラメータの洗い出しに務める。
3. 病院内の業務を標準化する努力を惜しまない。
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

当然 連携項目や値の策定もスコープ外標準的なマスタ（の構造）を採用出来るかどうかも、そのシステムにおける保守上の重要な判断となる。
放射線領域においては、JJ1017の採用が業務自体の大きな標準化を生み出す。
 施設拡張が多くても構わないので、とにかくJJ1017を採用することが重要。

付帯情報の整理を進め、人間系の処理条件を考慮するなど項目や値の効率化が必要。
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

埼玉医大のJJマスタ
3種類のマスタを実装
 JJ1017変換マスタ 放射線検査オーダ指示画面マスタ 診療会計用マスタ

実際の指示展開用内部コードとJJ1017コードとの変換マスタは実に17029レコードにも及んでおり、マスタ作成作業そのものについての作業工数負担はかなりのものであった。
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

JJ1017コードの課題について
JJ1017コードの定義外でマスタをコントロール
 【例】Order Placer → Order Filler連携で、乳児・幼児・小児・成人で別々のマスタを選択したい場合
 年齢はJJ1017コード以外の連携項目
 オーダ時に明示的に乳児・幼児・小児・成人を選択して指示する運用（手技または施設拡張でオーダ自体を分離）以外に対応の方法がない

撮影に直接関係ない放射線オーダの存在
 【例】○○先生コール・・・等
 JJ1017コードにおける対応は困難→ローカル

将来的に新しい検査が増えた場合や会計の算定方式が大幅に変更された場合
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

SWFは？
…

IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

IHE（SWF）は住まいでいう屋台骨
屋台骨が堅牢でも、使いにくい住まいでは意味がない。
医療という、「人の流れが作り出すサービス」と、「システムという工業製品」では、決定的に概念が異なる。
両者を融合するためには、医療（という業務→ワークフロー）のシステム化が鍵。
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

まとめ
IHEを採用した情報システムの導入は、同じ完成図を見ながら、同じ理解で進むことが出来るというメリットを享受可能です。
しかし、IHEに任せて「全て手放し」という訳にはいきません。
特に、コンテンツの整合や値の策定は、IHEとは異なるレイヤのスコープです。
この解決には、IHEで出来るものと出来ないものの分類が重要です。
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

まとめ
また、IHEのSWF実装では、アクタもしくは製品単位でのコンポーネント化（独立性）が重要です。
コンポーネント化を進める場合、それぞれのアクタが吸収できない（IHEスコープ外の）ソリューションをどの様な形で解決するかがポイントです。
この問題解決手法を誤ると、IHEを採用する価値が低くなってしまいます。「IHEならでは」の、高次なユーザの最終判断が、必要なところです。
これらスコープ外の対応を経て、はじめてIHEは開花するのではないでしょうか。
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

まとめ
IHEの採用は負担軽減に有効
 システム間相互の仕様確定に向けた調整事項が、大枠では終了しており、細部の微調整を済ませればよいと言う状況にかなり近似している。
 結果的に、「完成形は皆が把握しているので、完成にたどり着くプロセスの検討にリソースを費やせばよい」と言う品質向上指向に転換可能。
 ベンダ側の負担軽減にも十分資する。
 枠組み調整や、実装技術の選別調整など本質を協議する前段階の調整にエネルギーを費やす必要がない。
IHE Workshop in Tokyo
2011.06.11 Tokyo-Midtown

IHE-Jの今後に期待したいこと“スコープ外”という問題を解決すること 現在、「過去のIHE-J委員会で何らかの検討が行われた全統合プロファイル」をもってしても、放射線部門が臨床稼動に必要な全ての技術仕様や情報連携をカバーできる訳ではない。
 これら「用意されていない連携項目・連携手法」（スコープ外）や、用意こそされているものの、「日本の臨床現場で利用可能とするための検討」が十分にされていない手法については、従来通り医療機関側主導で仕様を確定し、連携のための調整を行う必要がある。IHE Workshop in Tokyo

2011.06.11 Tokyo-Midtown

IHE-Jの今後に期待したいこと
古い「仕組み」と「機械」を統合する仕組みの提示
 IHE-Jのガイドラインを純粋に採用するためには、医事会計システムを含む、古いシステムとの融合が問題となる。
•

患者様の新規登録を医事会計システムが行っている以上、「ADTと呼ばれる患者様の基本情報を登録する仕組み」を独立したシステムとして構築するのはPAMを含め難しい。

 IHE-Jに対応していない放射線機器はもちろん、DICOMにすら対応していない機器をどの様に融合するかは、施設のポリシーとなっているが、将来的にはこれら機器への統合も視野に入れた検討が必要。
 IHEを採用することで、部分的負担軽減は期待されることから、全体集約的観点から、大きな負担軽減を実現可能。
IHE Workshop in Tokyo

2011.06.11 Tokyo-Midtown