第30回 ＩＨＥ勉強会（初級編）in仙台

Integrating the Healthcare Enterprise

The IHE Initiative Worldwide
なぜＩＨＥ活動がはじまったか奥田保男
日本IHE協会/普及推進委員会

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

1

IHE Workshop in Sendai
Oct. 1, 2011

今日のお話の内容
標準規格の歴史 （DICOMを例に)
なぜ標準化が必要か？
問題発生！

そして、ＩＨＥ．．．

IHE Workshop in Sendai
2Oct. 1, 2011

標準化の歴史（ＤＩＣＯＭ）：デジタル機器の登場
撮像装置のデジタル化が始まる
デジタル画像データが生成され始める
 １９７０年代 Ｘ線ＣＴ、ＭＲＩ １９８０年代 デジタルＸ線（ＣＲ）．．．

画像の観察や処理や保存
撮像装置から観察装置への２点間の通信機能

ハードやデータ形式や通信方式が各社独自であった
IHE Workshop in Sendai
3Oct. 1, 2011

標準化の歴史（ＤＩＣＯＭ）：接続仕様の問題発生
各社独自仕様だったため・・・ 異なるメーカの機器の接続が困難
 システム拡張や機器のリプレースが困難 必要に応じ専用の開発が必要となりコスト負担増

Ａ社

Ｂ社
IHE Workshop in Sendai
4Oct. 1, 2011

何を決めればいいのか？
ハードウェア（コネクタ、ケーブルなど）
データ構造
 画像の形式

 画像付帯情報（患者氏名、生年月日、依頼医師など）
 画像パラメータ（ＷＷ／ＷＬなど）

通信プロトコル 通信手順 同期、エラー処理

IHE Workshop in Sendai
5Oct. 1, 2011

標準化の歴史（ＤＩＣＯＭ）：最初の標準規格登場

ＡＣＲ－ＮＥＭＡ規格 1983年：ACR （米国放射線学会）と NEMA （米国電気機器工業会)が合同でACR-NEMA委員会設立
 1985年：ACR-NEMA規格 第１版 発表
 1988年：ACR-NEMA規格 第２版 発表

ACR-NEMA規格
は２点間通信の規格
IHE Workshop in Sendai
6Oct. 1, 2011

標準化の歴史（ＤＩＣＯＭ）：ＤＩＣＯＭ登場
ＤＩＣＯＭ
 Digital Imaging and COmmunications in Medicine
 1990年代の時代の変化
複数の機器接続によるネットワークの時代• 医用機器の扱うデータが多様化•

 ACR-NEMA規格の大幅な変更をし、第３版とはせず、

DICOMと命名し、1993年にDICOM規格として正式に発行

IHE Workshop in Sendai
7
Oct. 1, 2011

医療情報の標準規格の例
DICOM
 Digital Imaging and Communications in Medicine
 放射線部門の画像情報システムに使用される
 主に、画像情報関連の通信仕様とデータ形式を定義する

HL7
 Health Level Seven
 病院情報システムと各部門サブシステムに使用される

 主に、文字情報のデータ形式を定義する

IHE Workshop in Sendai
Oct. 1, 20118

電子カルテシステム(EMR)

EMR Server

患者情報
検査オーダ情報

システム間の情報の流れに標準規格を適用

検査実施情報HL7

放射線部門情報管理システム(RIS)

Image/Report Viewer

RIS 端末画像管理システム（PACS)RIS Server

DICOM

DICOM

モダリティ
患者情報
検査オーダ情報

レポート情報

画像情報

DICOM

検査実施情報Report Server
画像情報

Modality

DICOM
Image Server
IHE Workshop in Sendai
Oct. 1, 20119

なぜ標準化が必要かマルチベンダーシステムが導入しやすくなる ベンダーの得意分野の活用（餅は餅屋）
 必要に迫られた部門ごとの段階的システム導入・更新

長期間にわたり情報を保存できる
 医療情報の保存期間は情報システムの寿命より長い• 情報システムは６年から１０年
 更新システムで受け継ぐための「標準情報形式」• 独自形式は特定ベンダーと運命共同体

施設間連携をやりやすく

IHE Workshop in Sendai
Oct. 1, 201110

様々な医療情報システム
医事会計システム

病棟システム給食システム薬局システムレポート

電子カルテ
オーダリングシステム

ナースセンター

システム
管理室オーダリハビリ室システム

処方
オーダ検査
結果

画像

受付端末

外来診察室

手術室システム

放射線システム
検体検査
システム

病理検査システム

引用：ＪＡＨＩＳ資料
IHE Workshop in Sendai
Oct. 1, 201111

ここまでのまとめ・・・歴史の勉強中心
背景 デジタルの医療情報が生成される環境
 情報をいろいろなシステムで活用したいというニーズ

課題
 ベンダーや装置によって仕様が違うため情報伝送が困難
 情報の有効活用や長期間保管に障害• 装置間移動、業務支援、診断支援、システム導入、情報保管など

解決方法
 ハード、データ構造、通信方式を共通にする
 標準規格の登場 ・・・ DICOM、HL７

IHE Workshop in Sendai
Oct. 1, 201112

ところが・・・・

標準規格だけでシステムが作れるか？
・・・という懸念が
IHE Workshop in Sendai
Oct. 1, 201113

標準規格に問題あり？
医療情報の標準規格には“あそび”がある 各国の事情（制度、慣例）などの為、きちっと決められない 規格は入れ物、何を入れるかは実装や運用次第
 一応、やりたいことが何でも出来る仕様となっている“あそび”があると問題もある
 解釈の仕方

その規格をどう解釈するか
 利用方法 どういう実装の時にどの規格を使うか 一貫性
情報項目の定義や目的は同一か

IHE Workshop in Sendai
14
Oct. 1, 2011

標準規格の問題が相互運用性に影響する
ＨＬ７やＤＩＣＯＭは実装時の融通を利かせるために曖昧な点があり、様々な解釈ができる選択したり運用するとき様々な方式が可能
要するに、どうにでも作れるという部分がある
それらが相互運用性に対する問題を発生させる

IHE Workshop in Sendai
15
Oct. 1, 2011

問題をもう少し掘り下げてみる
解釈の仕方
 ベンダー側の問題
 規格の解釈が開発会社によって異なる場合がある これを回避するために打合せや改造開発で工数が掛かる
 改造に伴うコストや品質に問題を起こす可能性がある

一貫性 規格は情報の一貫性を担保していない
 定義の違いや曖昧さは常に存在する 標準規格の版問題がある

IHE Workshop in Sendai
16
Oct. 1, 2011

解釈の仕方問題（ＤＩＣＯＭ）
DICOM 情報項目
１

患者識別番号

２

患者氏名

３

発行側オーダ番号｢オーダ番号」は４“３．発行側オーダ番号”
項目として送ろう ５

Ａ社製の情報システム

部門内オーダ番号
部門受付番号｢オーダ番号」は“５．部門受付番号”に入っていると思ってるよ

DICOM MWM
１ 患者識別番号

１ 患者識別番号

２ 患者氏名

２ 患者氏名３ オーダ番号

３

４

４

５

５ オーダ番号

Ｂ社製の撮像機器

IHE Workshop in Sendai
17
Oct. 1, 2011

解釈の仕方問題（PIDセグメント）
00105 Patient ID

00106 Patient Identifier List
00107 Alternate Patient ID
患者IDはどの項目に設定するの？
00110 Date/Time of Birth00111 Administrative Sex
生年月日や性別はHL7では省略可能？
「Health Level Seven, Version v2.5」から引用

IHE Workshop in Sendai
18
Oct. 1, 2011

システム運用で利用するタグは必ず存在する

but データが存在するとは限らない

IHE Workshop in Sendai
Oct. 1, 2011

解釈問題の解決方法
システム構築時の「選択」と「解釈」のガイドが必要

IHEは標準規格の使い方の「ガイド」を作る活動
 標準規格を実装で確実に利用する対策 「何をするとき、どの規格を、どう使うか」を決める
 規格自体を決めているわけではない

IHE Workshop in Sendai
20
Oct. 1, 2011

問題をさらに別の方向にも掘ってみる「何をする時に」を決める？
 利用方法の問題であり、ユーザ側の問題
 現状の施設毎に異なる運用は、一部でも共通化できないものだろうか？
 同じ業務を、同じ手順で、同じ言葉で・・・標準業務フローはできないの？
 何をシステムに入力するか？はユーザに依存する最近話題の強制的な情報の書き換え
 施設毎の独自運用に合わせたカスタマイズ 地域連携で、施設外に情報が出ると、問題が顕在化

施設毎向けの改造は高額で、品質問題の可能性あり
IHE Workshop in Sendai
21
Oct. 1, 2011

IHEは何が嬉しいか？
「こうする時はこのやり方で」というガイドなので、実装方法や規格の解釈の議論が少なくてすむ ベンダー間の仕様の議論と検討が少なくなる 業務ワークフローの標準化検討のきっかけになる

ＩＨＥによってユーザとベンダーの意思疎通が図れる
 ユーザは「何をやりたい」、ベンダーは「何がやれる」
 ユーザはIHE用語で必要なワークフローを示す
 ベンダーはIHEに従った実装をする

IHE Workshop in Sendai
22
Oct. 1, 2011

ユーザとベンダーの意思疎通【専門領域に対する知識差】
施設の医療従事者
 医療に関しては専門性の高い知識を持っているが、システムエンジニアの話す用語には不慣れ。
ベンダのエンジニア
 システム開発の専門家だが医療に関する教育は受けていない。

？？？

Αγ漢，￥＠＝Ｒ＃＊

伝えたつもり分かったつもり【医療従事者A】※♪Ψ◎×□

伝えたつもり分かったつもり【エンジニアB】【医療従事者C】
IHE Workshop in Sendai
23
Oct. 1, 2011

ユーザとベンダーの意思疎通
SWFですね。了解です。
（技術的な説明は不要ですね）
ＳＷＦをお願いします。
(ワークフローの詳細説明は不要ね)

伝わる、分かる【医療従事者A】

ＳＷＦが出来てるんだ。
（何が出来るか分かりやすいな）

伝わる、分かる【エンジニアB】【医療従事者C】

ＩＨＥを利用することで意思疎通↑
IHE Workshop in Sendai
24
Oct. 1, 2011

IHEは万能ではない！
現在のIHEで、情報システム構築の全ての問題が解決するわけではないが、全てをゼロから解決する必要はない

IHE Workshop in Sendai
25
Oct. 1, 2011

今日のお話の内容
標準規格の歴史 （DICOMを例に)
 撮像装置と観察・処理・保管装置の間の情報伝送

なぜ標準化が必要か？
 マルチベンダーシステムと情報の長期保存と施設間連携問題発生！
 規格の選択と解釈の曖昧さ
 様々な業務フロー

そして、ＩＨＥ．．．
 業務フローを定義し、規格の選択と解釈を決めてみよう！

IHE Workshop in Sendai
26
Oct. 1, 2011

Questions ?

WWW.IHE-J.ORG
IHE Workshop in Sendai

27

Oct. 1, 2011