第１１回 IHE Workshop in 大津

XDS（施設間情報共有統合プロファイル）を使った病診連携
有限責任中間法人 日本IHE協会
京都医療科学大学
細羽 実

IHEによる病診連携• 連携の仕組みが標準化されている• 連携情報が標準化されている• セキュアな基盤の上に構築されている• 情報の管理責任を明確にできる• 広域に展開可能• EHRへの展開
2

IHEの手法による病診連携とは• 相互運用したいテーマ(シナリオ）を特定する(例：○○についての病診連携を行う）– 共通の業務の流れ（ワークフロー）をとらえる– 共通の文書（コンテンツ）を定義する– 共通インフラ（セキュリティ基盤、医療連携の情報共有・交換）を整備する
3

IHE手法のキーワードと病診連携
統合プロファイル
(病診連携のどのソリューションか？）問題(テーマ）の解決例（臨床の現場はOK！）
アクタとトランザクションで構成する（実装できる！）

アクタ (レジストリ、リポジトリ、ソース、コンシューマ．．．）（情報を処理の機能単位（システム、装置）を特定する）必要なトランザクションを実行する単位

トランザクション（詳細情報のやりとりを記述）
標準規格（HL7、DICOM、ebXML、Webなど）を採用
4

医療連携の共有の仕組みを特定する
管理台帳(レジストリ)
情報インデックスの登録

共有情報の保管庫（リポジトリ）

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

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

患者ID
管理

医療機関C
長期診療

情報の検索
共有情報の保管庫（リポジトリ）

共有情報の保管庫（リポジトリ）

共有情報の利用者

医療機関D診療所など
5

共有について同意したコミュニティ機能単位を定義する→アクタ
患者IDソース(患者IDの提供）

ドキュメントレジストリ(管理台帳）

アクタ

アクタ

リポジトリ

ドキュメントソース(データ提供）アクタ

ドキュメント
リポジトリ（データ保管）
アクタ

ドキュメント
利用者(コンシューマ ）アクタ

6機能単位間の通信（トランザクション）を記述
標準規格の適用
統合プロファイル：XDS（Cross-Enterprise Document Sharing)
患者ID

トランザクション（HL7,ebXML）

ソース(患者IDの提供）

ドキュメントセットの提供と登録(Provide and Register
ドキュメントソース(データ提供）アクタ

XDS.b 2007-2008↓患者IDの供給（Patient ID Feed)

Document Set)

アクタ

アクタ

ドキュメントの問い合わせドキュメントレジストリ(台帳）（Regisry Stored Query)↑ドキュメントセットの登録（Register Document Set)

ドキュメントリポジト(データ保管）
アクタ

ドキュメント
利用者(コンシューマ ）ドキュメントの読み出し（Retrieve Document Set)

7

アクタ

XDS(施設間情報共有･統合プロファイル）の実装例
ドキュント
ドキュメントドキュント
ドキュメント
リポジトリ
リポジトリ(データ管理）(データ管理）ドキュメントドキュメントソース
ソース（データ提供）（データ提供）

院内電子
カルテシス
テム

レジストリセンタ
ドキュメントドキュメント
リポジトリ
リポジトリ(データ管理）(データ管理）ドキュメントドキュメント
利用者
利用者

ドキュント
ドキュント
利用者
利用者

院内電子カルテシス
テム

ドキュメントドキュメントレジストリ(台帳）
レジストリ(台帳）

医療機関B
急性期 診療（入院）

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

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

ソース
ソース
(データ提供）(データ提供）8

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

医療機関C
診療所など
（診断 サービス）A実装形態の他の例
ドキュメントソース(データ提供）登録

ドキュメント
リポジトリ(データ保管）ドキュメントソース(データ提供）ドキュメントレジストリ
ドキュメント
レジストリ
（台帳）

A

問い合わせ
ドキュメント
利用者利用者

読み出し

登録

B

ドキュメントレジストリ
ドキュメント
レジストリ
（台帳）

問い合わせ

ドキュメント
リポジトリ（データ保管）

読み出し

提供と登録
ドキュメントドキュメントソース(データ提供）ソース
9

ドキュメント
利用者

ドキュメント
利用者
ドキュメントドキュメントレジストリ（台帳）
ドキュメント
リポジトリ（データ保管）CIHEにより連携できる情報• 連携したいデータをドキュメントと呼ぶ• ドキュメントはコミュニティで定義できる– 人が読める、マシンが処理できる、署名ができるもの(色々なレベルで）• ドキュメントを定義する統合プロファイル– 画像– 退院時サマリ（アレルギー、投薬）– 臨床検査– 個人健康・医療情報– 救急部門– 患者同意文書– 手術前情報• 標準規格でコンテンツを定義

XDS-I
XDS-MS
XD＊-LAB
PHR
EDR
BPPC
PPHP

– CDA R2
– HL7 Care Record Summary– ASTM/HL7 Continuity of10Care Document情報検索キーとなるデータ（Meta Data)（（レジストリ(台帳）に登録）

１．作成者： ・所属施設 ・名前 ・役割 ・専門性
２．承認者
３．タイトル、コメント、作成時間、サービス開始、終了時間
４．利用ステータス： 発行、承認、不可
５．ID ： 患者ID,Unique ID,UUID
６．患者情報７．診療行為関連・診療行為種類コードと名前（盲腸炎手術、結腸鏡検査…）
・施設種類コードと名前（クリニック、専門病院…）
・診療科コードと名前 (検査ラボ、放射線科…）
８．Code値
・提供施設タイプ、守秘コード
９．ドキュメントの種類
・classCode（一般的カテゴリ）・typeCode（詳細）11・eventCodeList（主な臨床イベントなど）

検討中のテーマ、運用の問題• ダイナミックな情報（アレルギー、投薬、プロブレム）• オーダの発行、追跡（処方：ePrescription, 照会：eReferral)• コミュニティ間共有• セキュリティ運用は各コミュニティで– 他の統合プロファイルを利用して構築する• コミュニティ内の管理運用

12

連携（共有・交換）の形
施設間情報共有
XDS
電子カルテシステム

ドキュメントセットの提供と登録
ドキュメ ント
リポジトリ

ドキュメン トソース

施設間情報高信頼性交換
XDR（Reliable Interchange)
ドキュメントセットの提供と登録

電子カルテ
システム

ドキュメ ント受信

ドキュメン トソース

13

施設間メディア交換 XDM（Cross enterprise Document Media interchange）
メディア（CD-R,USB）,によるドキュメントの配信
PortableMediaCreatorPortableMediaImporterPMC• ドキュメントを患者に提供• 手渡しによるドキュ
メントの転送• CD,USB,メールも含むPMIWebコンテンツへのエントリ提供するドキュメントセットへのエントリ
その他のコンテンツ（XDMには関係ない）

14

メディアのディレクトリ構造

IHEによる医療情報連携 ３つの方式
構造をもつ
オブジェクトXDS
PublishCross Enterprise Document
SharingXDR Send to

Pull

Pull

SwitchSend toInterchange
Media

Inport

XD Reliable Interchange

XDM Export
XD Media Interchange
ワークフロー
管理

情報要求Transactions
Query / Response15

ワークフロー
管理

データ
リポジトリ

IHEによる連携基盤
各にン
イメ
ド

関

係

ドキュメントの内容（コンテンツ）を決める統合プロファイル
外科手術
PPHP

画像
XDS-I

イン

フにラ

関

同意文書
BPPC

臨床検査
XD*-Lab

救急
EDR

スキャン文書XDS-SD

退院サマリ
XDS-MS

PHR交換
XPHR係

ドキュメント共有

ドキュメント交換 1対1

メディア交換

XDS

XDR

XDM

ドキュメント連携のための統合プロファイル
セキュリティ基盤 16統合プロファイル

IHE インフラ ・ドメイン• 世界で100を超えるベンダ• 8 テクニカルフレームワーク• 58 統合プロファイル

Veterinary
Endoscopy
Pathology
Pharmacy
Quality•臨床部門:•放射線, 循環器, 臨床検査,…

Patient Care Devices (1)Patient Care Coordination (5)Radiation Oncology (1)•部門、あるいは病院の壁を越えて•EHRを可能にするもの

Eye Care (3)Laboratory (6)Cardiology (7)IT Infrastructure for Healthcare (17)17Year 9(2007)

Year 8(2006)

Year 7(2005)

Year 6(2004)

Year 5(2003)

Year 4(2002)

Year 3(2001)

Year 2(2000)

Year 1(1999)

Radiology (18)

ITI(インフラ） 統合プロファイル
施設間ユーザアサーション（XUA)

患者基本情報の問い合わせ（PDQ）

ドキュメント電子署名（DDS)

スキャン文書XDS-SD

監査証跡とノード認証（ATNA）

患者IDを異なるIDドメイン間でマッピング

セキュアなドメインを形成するための監
ドキュメント 共有 ドキュメント 交換 メディア 交換
査証跡とノード間認証

1対１

時刻の整合性（CT）
ネットワーク接続されたシステムにおける時刻の整合

医療機関職員の登録簿
（PWP）
施設内
ユーザ認証（EUA）

ユーザに単一の名前と全システムにわたる集中認証プロセスを提供

MPIのための患者ID相互参照
（PIX）

XDS

XDR

XDM

ドキュメント交換のための統合プロファイル

コミュニティ間アクセス

ドキュメント利用可能通知（NAV）

フォームデータの読み出し（RFD)
アプリケーション内データを外部利用するフォームデータの読み出し

施設内だけの利用表示のための情報検索（RID）
18

患者管理（PAM)
患者同期
アプリケーション（PSA）
一患者に対する複数アプリケーションのデスクトップ上での同期

セキュリティへの対応 統合プロファイル• 正しいユーザか– ユーザのID → PWP（職員の登録）– ユーザ認証 → XUA（ユーザ認証）– アクタ（機器、ノード）認証 → ATNA（監査証跡とノード認証）– アクセス制御 → 将来

• 誰がアクセスしたか– 監査証跡 → ATNA

• 改ざんはないか– データ完全性 → CT(時刻の整合）, ATNA,DSG(ディジタル署名）• 秘匿されているか

19– データ秘匿 → ATNA,BPPC（同意文書）

監査証跡と認証、時刻の正当性
ATNA（Audit Trail & Node Authentication) & CT(Consistent Time)の利用

電子カルテPMS
救急部門

開業医
リポジトリ
ドキュメント
レジストリ

PACS

リポジトリ
ドキュメントの問い合わせドキュメントの登録
PACS

セキュアなメッセージ交換
ドキュメントの読み出し

ドキュメントの読み出し
時刻の同期

電子カルテ
ドキュメントセットの登録

臨床検査
時刻の監査証跡の中核病院
時刻の同期
コミュニティ システ 記録
ATNA監査 同期
ムCT タイムサーバ
クリニック
記録
監査証跡の監査証跡の記録
リポジトリ
記録
20

XDS コミュニティ

施設間でのユーザ認証
XUA（Cross-Enterprise User Assertion)

ユーザ認証のプロバイダ

施設間Assertionのプロバイダ

ユーザを認証する

SAML:一度の認証で複数のWebサイトやサービスが利用できるシングル
サインオン
施設間Assertionの検証

施設間Assertionの入手
ドキュメントの読み出し
ドキュメントの問い合わせ

施設間サービスのユーザ

施設間Assertionの提供
21

施設間サービスのプロバイダ(レジストリ、リポジトリ）

施設間で患者IDを相互に参照する 仕組み アクタ
PIX（Patient ID Cross referencing)
患者IDソース（IDの提供）Patient Identity Feed

患者ID
利用者

Patient Identity Feed HL7 V3

PIXV3 QueryPIX Query

患者IDの問い合わせ

患者IDの提供
PIX Update Notification

患者ID相互参照
マネージャ

22

PIXV3 Update Notification

患者IDの更新通知

患者IDの相互参照
PIX（Patient ID Cross referencing)
患者ID
相互参照
-患者ID相互参照
マネジャドメイン

B:X456B:
X456 C:2RT
C: 2RT
A:123 B:Y921 C:3TY
B:D456
A:235 B:DF45
A:678

患者IDソース

Id=123
Id=235
Id=678
患者 ID
ドメイン A
患者IDソース

Id=X456
Id=Y921
Id=D456
Id=DF45
患者IDドメイン B

Id=3TY
Id=2RT
患者IDソース

患者IDドメイン C23

B:X456
C: ?

B:X456
C: 2RT
患者ID
相互参照

患者ID
利用者

患者ID相互参照と患者情報の問い合わせ
PIX & PDQ(Patient Demographic Query)の利用
PDQ による 患者 IDの問い合わせ
患者ID相互参照マネージャ

患者ＩＤ 提供
患者ID提供A87631
M8354673993
M8354673993

M8354673993

14355
L-716

L-716

電子カルテ

患者ID ソース
M8354673993

開業医
患者ＩＤ提供

患者ID

救急部門提供ドキュメント
レジストリ

リポジトリ
L-716

患者IDの問い合わせ

臨床検査システム

患者IDの問い合わせ

PACS
A87631

リポジトリ

ドキュメント問い合わせ (Pt Id)

PACS

コミュニティ
クリニック

A87631

ドキュメント登録(Pt ID)

ドキュメントの読み出し

電子カルテ
ドキュメントの提供と登録

中核病院
ATNA監査記録
ATNA監査記録
リポジトリ

CT タイムサーバ

24

XDS コミュニティ

コミュニティ（Affinity Domain)の連携
XCA（Cross Community Access)
コミュニティ B

Receiving
Gateway

コミュニティ A

ドキュメントレジストリ
ドキュメントリポジトリ

ドキュメントの問い合わせ（RegisryStored Query) Initiating

Cross
Gateway
Query

Gateway

Cross
Gateway
Query

ドキュメントの読み出し（RetrieveDocument
Set)
ドキュメント
利用者

ドキュメントの問い合わせ（RegisryStored Query)

ドキュメントの読み出し（RetrieveDocumentSet)
25

ドキュメントレジストリ

ドキュメントの問い合わせ（RegisryStored Query)ドキュメント
リポジトリ

コミュニティ C

ドキュメントの問い合わせ（Regisry StoredQuery)

Receiving
Gateway
ドキュメントの読み出し（RetrieveDocumentSet)

ドキュメントレジストリ
ドキュメントリポジトリ

コミュニティ （Affinity Domain）のチェックリスト•ドメイン外との接続性•システム仕様• 組織規程– 構成、設立者、運営者– 経済的、税務的検討– 透明性– 責任機関（支払い、利用権、セキュリティ）– 法的事項の管理– 債務– 免責事項–レジストリ、リポジトリ、ソース、利用者、–PIXマネージャ、PIX利用者、–PDQソース、PDQ利用者、監査
証跡リポジトリ、–ドメイン間トランザクション•メタデータ (辞書）
•患者同意•セキュリティ技術• 運用規程– サービス契約– 日常管理– トラブル– メンテナンス（追加、更新、バックアップ）– 災害復旧–承認–認証–アクセス–完全性–倫理–監査証跡–リスク解析

• 会員規程26

IHEによる病診連携• 連携の仕組みが標準化されている• 連携情報が標準化されている• セキュアな基盤の上に構築されている• 情報の管理責任を明確にできる• 広域に展開可能• EHRへの展開

27

28

名古屋プロジェクト
疾患別地域医療情報連携システムの標準化及び実証事業
救急車ー急性期病院間情報伝達フォーマット
（診療・検査・画像情報）

地域連携クリティカルパス
手術支援
ネットワーク

救急車

急性期病院ーリハ病院間情報伝達フォーマット
（診療・検査・画像情報）

急性期病院
救急医療
ネットワークレジストリーシステム

リハ病院ー療養型施設・かかりつけ医間情報伝達フォーマット
（診療・検査・画像情報）

回復期
リハ病院

HPKI
CA局
患者の レジストリ リポジトリ
地域ID 共有情報 共有情報
管理簿 登録簿
保管庫

療養型施設
かかりつけ医療養型施設・かかりつけ医ー在宅間情報伝達フォーマット
（診療・検査情報）

かかりつけ医ネットワーク
基幹病院
ネットワーク

在宅29

東海ネット医療フォーラム・NPO

粒子線治療連携デモンストレーション
施設間連携用
情報管理サーバ

CyberRAD2007

ドキュメントレジストリ(台帳）

一般病院

診療情報・画像情報の提供

ドキュメントリポジト(データ保管）

放射線治療専門病院
ドキュメント問合せ・参照
ドキュメント
利用者(コンシューマ ）画像ドキュメント
利用者(コンシューマ ）ドキュメントソース(データ提供）画像ドキュメント
ソース(データ提供）DICOM画像、キー画像取得

Clinical Affinity
Domain30

IHEによる病診連携の現状と問題点• 実証試験（名古屋、放医研：18年～20年）– 運用体制の確立– ビジネスモデルの確立• 普及のためには– IHEの枠組みによる推進• 必要な国内拡張と国際整合• コネクタソンの実施– アクタのオープンソース化– テスト環境の支援• 大きな枠組みへ
31– 病診連携 → 地域連携
→ EHR

公開情報・オープンソース• IHE Wiki
– http://wiki.ihe.net/• オープンソース– Source Forge project ‘IheOs’• 公開レジストリ– ‘IheOs’• http://ihexds.nist.gov– XDSテスト

32

接続テスト会• ePHDS委員会によるXDS接続テスト（放医研）– 2007年 10月29日、30日– 基本アクタのオープンソース– テスト用のレジストリ、レポジトリの立ち上げ来年のコネクタソンのプレテスト– 参加にはJPACS(日本PACS研究会）への会員登録が必要• www.e-rad.jp/xoops/

33おわります。
ご清聴ありがとうございました。
http://www.ihe.net/
http://www.ihe-j.org/