京都医療科学大学 細羽 実

「つながる」ことの必要性
 「つながる」ためのアクタとトランザクション
 「つながる」を確保する統合プロファイルの事例紹介

コンテンツの意味で、
 インフラの意味で ワークフローの意味で

まとめIHEの手法
 テクニカルフレームワークあなたは以前、○○○の病気にかかったことがありますか？

紙カルテやX線フィルムで「つながる」（情報を得ること）ことができますか？
えっ！？
わからない・・
どうだったかな？

昔のカルテやＸ線フィルムを探し出すことは、非常に大変な作業で、殆ど不可能に近い。
高齢の患者が過去の病歴を忘れているケースが多い。
4

いろいろな病院の履歴をつないで診療ができると、医療の質の向上が期待できます。

B病院

A病院
----------------------------------○○------------------------------▲▲▲▲

xxxxxxxxxx

医療情報医●●●●●●●●●●●●●●●●●●●●●●
A病院 ・・・・・・・・・
B病院 ●●●●●●
C病院 △△△△△

報
情療

はい、そう言われればそうです。

あなたはＡ病院、Ｂ病院でこんな治療をしましたね

C病院

5つながっても 。。。

B病院

A病院
-------------------------------------------------○○----○○---xxxxxxxx
xxxxxxxx

ネットワーク
WEBアクセス

当病院は医療情報を安全に
ネット公開
しています

-------------------------------------------------------------------○○----○○---xxxxxxxx
xxxxxxxx------------------------------------------------------------▲▲▲▲▲▲▲▲
xxxxxxxxxxxxxxxxxxxx------------------------------------------------------------▲▲▲▲▲▲▲▲
xxxxxxxxx
xxxxxxxxx

当病院は医療情報を安全にネット公開しています比較しにくいなあ。
標準的な見え方はないの？
情報が取得されて、診療の現場で比較できるように提示されないと危険です。
6

「人が見てわかる」だけではなく、「コンピュータが利用できる」標準的な形式で、相手に正確に伝えられることです。
標準的な形式とは情報の再現性（表示の一貫性など）の条件も含みます。
標準規格：ＨＬ７(文字情報）DICOM(画像情報）-------------------------------------------------------------------○○----○○---xxxxxxxx
xxxxxxxx----------------------------------------------------------------xxxxxxxx
xxxxxxxx

標準的な形式でデータのやり取りをします

標準がなければ、つながるとはいえません！

xxxxxxxx
xxxxxxxx7

HL7やDICOM規格などの標準規格が制定されています。



しかし、病院では、標準規格で接続しても、正しくつながらない場合があります。その原因は、メーカー毎に規格の解釈が違うこと等です。

規格の解釈を統一することが必要です。



そのためには、前提条件(利用される環境）を揃えなければなりません。



接続性を担保するには標準規格は必要ではあるが、十分ではないということです。

8

医療の現場でどのような時に、「つながる」ことが必要かを調べます。



例えば病院間の連携では、『診察時に他の病院の情報を入手して診察する典型的な場面』１）を特定し、つなぐべきシステム２）を決め、情報の形式と内容３）を定義します。



できあがったものを仕様書4)としてまとめます。



医療のあらゆる場面での「つながり」を確保するには、これらの作業を次々と行わないといけません。

1)統合プロファイル

2)アクタ

3)トランザクション

4)テクニカルフレームワーク
9標準に準拠しているか調べるための接続テスト５）を実施する必要があります。
 中立な立場による実施が必要です。
 接続テスト実施の環境整備が必要です。
 なぜなら、つながることの信頼性は医療安全に関わるからです。
５）コネクタソン
10統合プロファイル

アクタ

アクタ

統合プロファイル

11

AＣ仕様によるRISPACS接続
in Z病院

ベンダーC社のPACS

ベンダーB社のHIS

ＡＢ仕様によるHISRIS接続
in Z病院

ベンダーA社のRIS発注目的(Z病院業務シナリオの実装）

DＣ仕様による
Modality-PACS接続
in Z病院
ベンダーD社
ＡＤ仕様によるRIS- のModality
Modality接続
in Z病院

12

AF仕様によるRISPACS接続
in Z病院
ベンダーE社のHIS

ＡE仕様によるHISRIS接続
in Z病院

ベンダーF社のPACS

DF仕様による
Modality-PACS接続
in Z病院

ベンダーA社のRIS発注目的(Z病院業務シナリオの実装）

ベンダーD社
ＡＤ仕様によるRIS- のModality
Modality接続
in Z病院

13

DICOMによるRISPACS接続
in Z病院
ベンダーE社のHIS

DICOMによるHIS-RIS ベンダーA社のRIS
接続
in Z病院

発注目的(Z病院業務シナリオの実装）

ベンダーF社のPACS

DICOMによる
Modality-PACS接続
in Z病院

ベンダーD社
DICOMによるRIS- のModality
Modality接続in Z病院

14ベンダによらない接続(ユーザのメリット）！
ユーザによらない接続(ベンダのメリット）！

アクタ(共通の機能）間の接続

PACS

HIS

標
準通信通準標

信標準通信

RIS通信
準標

Modality

発注目的(病院共通業務シナリオ）15

●製品間の接続から、アクタ(共通の機能）間の接続へ！
●標準接続＝標準規格接続＝トランザクション●製品の接続を標準化することは難しいが、アクタであれば可能！
PACS

HIS

トラン

仕様を限定した標準規格の適用
ザ
クシ

トランザク
ション

ョント

病院 共通業務シナリオ

ショ
クザ
ラン

トランザク
ション

ン

Modality

RIS

16

ベンダーC社の製品

ベンダーB社の製品

トランザク
ション
トランザク
ション

ベンダーA社の製品

トランザ
クシ
ョン

トランザクション

ベンダーD社の製品

17



ＡＢ仕様によるHIS-RIS接続 in Z病院
ベンダA社ーベンダB社
 HIS-RIS接続
 Z病院仕様
多大なコスト(ユーザ、ベンダ）


標準規格によるHIS-RIS接続 in Z病院
HIS-RIS接続
 Z病院仕様
規格解釈の不統一による病院ごとのばらつき

標準仕様によるオーダ発行アクタ（HIS)-オーダ実施アクタ（RIS)の接続
オーダ発行とオーダ実施というHIS、RISの仕事の一部を接続 ベンダー、病院に依存しない接続！
製品Aと製品Bがつながる？
ABの接続仕様
システム

Ａシステム

Ｂ

「つながる」とは、発注システム全体が稼働すること！
発注システムを動かす目的のシナリオ

19



アクタ

： 業務を行うシステムの共通の機能

トランザクション： アクタ間の通信を標準規格で行う



統合プロファイル ： 共通業務シナリオ
発注システムを動かす
共通業務シナリオ

20

核医学画像（というコンテンツ）を保存して表示するプロファイルのケース

ベンダーD社の製品
モダリティ 撮影装置

標準規格
DICOMによるModality-PACS
接続

ベンダーC社の製品
PACS(表示装置）？

●DICOM規格では、画像種類ごとに付帯する特定の情報を定義しています。 → 選択して実装することが必要です。
●解決には、打ち合わせして実装仕様を確定するか、伝送画像の内容を共有化する必要があります！

DICOM規格による核医学画像の通信に必要な情トランザクション
報を追加します
画像の問い合わせと取得トランザクション
画像伝送表示アクタ

保存アクタ

モダリティ
アクタ
RAD8 （Modality ImagesStored）（DICOM Store)を基本に

RAD14（Query Image）
RAD16（Retrieve Image）
DICOM Q/Rを基本に●シナリオに必要な情報(タグ情報）を実装の仕様にします。
（つまり「つながる」を確保します）

標準規格には、書式、内容が書いてあります。
実装時に詳細な(以下の）内容を決める必要があります。これをプロファイルとして定義します。
マルチフレーム/マルチベクタ画像

複数画像セット同時シネ表示

グレースケール表示とカラー表示



ダイナミック/スタティック表示

オリジナル解像度での表示ウィンドウレベル；上と下を別々に調整

擬似カラーのテーブル

新たなカラーテーブルの追加



画像シリーズの説明タグの表示24

CDで画像やレポートなどを交換する
インフラとなるプロファイルのケース

病院BのPACS製品

可搬型媒体(メディア）を通じて、相手に正しく情報を伝えます。
病院AのPACS製品

表示

メディア
作成
アクタ

画像表示

メディアに情報を書く機能をもつアクタ

トランザクション
RAD-47 ：メディアでの情報の配信

媒体上の関連情報の表
示機能をもつアクタ
媒体上の画像を表示するアクタ

レポート
表示

媒体上のレポートを表示するアクタ

印刷

媒体上の画像を印刷するアクタ

メディア
インポータ
アクタ
26

施設にあるシステムに画像データを取り込むアクタ

●ルートディレクトリは右の構造をもつこと●ISO9660レベル１に準じたファイル名を使用すること。
・数字、英大文字、アンダース
コアのみ
・8文字以内・ディレクトリは8階層まで●DICOMファイルには拡張子をつけないこと。
・.dcmをつけない
・SOP Instance UIDに基づく
名前をつけない●DICOMファイルはExplicit
VR Little Endianであること。

DICOMDIRDICOM ファイルのディレクトリINDEX.HTM
README.TXT

IHE_PDI
Webファイルのディレクトリ
その他のディレクトリ

その他のファイル
27

メディアの内容を見ることのできるエントリーポ
イントWeb コン
テンツ

その他のコンテンツ

画像検査のワークフローのプロファイルのケース

患者受付

ＨＩＳ
画像検索
患者登録

画像観察装置

ＰＡＣＳ
オーダー発行
画像保管・
管理

実施完了
患者情報

検査情報リスト

検査オーダ

画像保存
部門：
オーダ実施

ＲＩＳ

撮影進行中または、撮影完了

撮影完了

モダリティ

29

患者受付
ＨＩＳ

患者情報

後処理、レポート作成など、別の業務フローへ
患者登録

画像検索
画像観察装置ＰＡＣＳ

データの利用可能性通知
オーダー発行

予約状況の通知

実施完了
患者情報
検査オーダ
部門：
オーダ実施

ＲＩＳ

検査（プロシージャ）が画像保管・予約された管理
検査情報リスト
画像保存
撮影進行中または、撮影完了

撮影完了
モダリティ

30

例えば、３種類５個のアクタ間で、患者情報、検査情報や、関連するコードの共有（共通のオーダ番号)ができます。

検査（プロシージャ）が予約された
Procedure Scheduled

検査情報リスト
Modality Worklist
部門：
オーダ実施

画像保管・管理

患者情報、検査情報

画像保存
Image Stored
DICOM/Store

患者情報、検査情報
撮影完了
モダリティ
撮影進行中または、撮影完了

31

画像情報、患者情報、検査情報

施設間で情報連携するインフラとなる
プロファイルのケース

医療情報共有について合意したコミュニティ

所在情報の登録

共有情報の保管

医療機関C
長期診療

患者ID管理
所在管理

医療機関B
急性期診療
(入院)

情報の検索
共有情報の
保管
共有情報の利用者

共有情報の保管？
患者

医療機関A
初期治療、診療 (救急)

医療機関D
診療所など

医師

33

患者ID管理所在管理台帳共有情報の保管

共有情報の保管

医師

患者提供共有情
報の保管

提供共有情報の保管

34

所在の問い合わせ所在管理台帳（Regisry Stored Query)
共有情報の利用者
医師

患者

共有情報の保管庫

共有情報の読み出し（Retrieve Document Set)

35

所在管理台帳

共有情報の提供と登録(Provide and RegisterDocument Set) →↑所在の登録（Register Document Set)

共有情報の保管庫
医療機関内の電子カルテシステム
製品
36

患者IDソース↓患者IDの供給（Patient ID Feed)
ドキュメント
レジストリ(文書登録簿）
ドキュメントセットの提供と登録(Provide andRegister DocumentSet)
ドキュメント
ソース（文書生成源）↑ドキュメントセットの登録（Register Document Set)

ドキュメント
リポジトリ（文書保存庫）ドキュメントの問い合わせ（Regisry Stored Query)

ドキュメントコンシューマ（文書利用者）
ドキュメントの読み出し（RetrieveDocument Set)

37

医療連携システムの構成アクタを実装する

ドキュメントソース

ドキュメント
リポジトリ

PACS

画像ドキュメント
ソース

ドキュメント
利用者

EHR中央レジストリ
セキュリティ管理センター

ドキュメントリポジトリ

ドキュメントソース

画像ドキュメント
ソース

PACS

患者IDソース

ドキュメント
利用者
画像ドキュメント
利用者

ドキュメントレジストリ

医療機関B急性期診療（入院）画像ドキュメント
利用者

院内電子カルテシステム
医療機関A
初期治療、診療(救急)院内電子カルテシス
テム

ドキュメント
利用者
画像ドキュメント
利用者

診療所電子カルテシステム

医療機関C
診療所など
（診断サービス）38

どんな「つながり」が業務に必要かを決めます。
 業務単位で情報化する場面を取り出します。→シナリオの作成
 シナリオの種類

業務フロー（ワークフロー）を書きます 取り扱う情報の中味（コンテンツ）を書きます 基盤(インフラ）として共通するものを書きます

どんな機能=アクタで構成すべきかを決めます。


アクタは単純で、どこでも共通の機能とします。

シナリオを統合プロファイル：Integration Profileとしてまとめ、文書に記述（テクニカルフレームワーク）します。

40



シナリオ (統合プロファイル：Integration Profile）


インフラ (画像共有）
ワークフロー (検査）コンテンツ (画像表示）

アクタ （Actor)


シナリオを構成する機能

所在管理台帳、共有情報保管、利用者
モダリティ、オーダ発行、オーダ管理、画像表示トランザクション （Transaction）


機能単位間の情報のやりとり
RAD8,RAD47,….

統合プロファイル
アクター
Transaction…

Transaction

…

…

アクター
Transaction

アクターTransaction

トランザクション

…
41

①臨床現場で共通となる業務の行われるシナリオを特定 （問題の解決となる）②システムが提供すべき業務の全体を、既存システムの枠を越えたいくつかの小業務のフローに分割、整理③個々の機能を実現するために必要なユニット（アクタ）の抽出④アクターが協調して相互接続運用を行うために必要な通信方法（トランザクション）を定義、DICOM,HL7などの標準規格で記述⑤ワークフロー、コンテンツ、インフラなどの業務シナリオを実現する枠組みを統合プロファイルIntegration Profileと名付けて確定し、テクニカルフレームワーク
technical framework文書として記述、公開42

Volume 1:
プロファイル
 臨床ニーズとユースケースの記述

アクターとトランザクションの概要

Volume 2
トランザクション
 コンテンツの実装仕様
ユースケース/プロセスフロー

統合プロファイル：¾ アクター¾トランザクション

アクター トランザクション

トランザクションに対して：¾ 標準規格の参照¾ 明確な規格の選択