IT Infrastructure（IT基盤） 2
具体説明

IHE-J ベンダーワークショップ 2006
大島 義光（株）日立製作所 医療事業統括本部1

目次
IHE IT Infrastructureとは?
個別統合プロファイルの紹介
関連臨床部門でのXDSの応用¾ XDS-I、患者ケア連携（PCC）、XDS-LAB

関連、実装状況（IHE ITI オープンソース等）
ロードマップ2

IHE IT Infrastructureとは?
IT Infrastructureとは...
¾ コンピュータ・アプリケーションの実行を可能にする
オペレーティング・システム• コンピュータ言語• ハードウェア• ネットワーク•

application

application

application

application¾ 多種のアプリに役立つ

Infrastructure

セキュリティ
• データベース• インタフェース•

3

IHE IT Infrastructureとは?
IHE IT Infrastructureとは...
¾ 標準をベースにした IT infrastructure の実装ガイド、テクニカルフレームワークの一つ¾ 関係委員会
企画委員会（Planning）– 各年の作業の承認と今後のロード
マップ作成• 技術委員会（Technical）– テクニカルフレームワークの執筆とメンテナンス•¾ 提供サービス
関係者への教育活動• 各種の標準化機関やコンソーシアムとの協力• IHE内の各分野委員会との協力•

4

IHE IT Infrastructureとは?
IHE IT Infrastructure 部門で生成されるもの...
¾ IHEの各臨床部門に依存しない（つまり共通の）ワー

クフロー記述に用いられるプロファイル•

例： セキュリティ、記録の保存、患者管理¾ 基礎的な実装仕様の基盤。これは臨床部門で拡張される•

例： 文書コンテンツの基本仕様、データ収集のための取り出
し形式¾ 現在の作業項目に対する白書•

例： 施設間利用者認証、Webサービス、リスク管理

5

IHE IT Infrastructureとは?
統合プロファイル – 診療情報 1¾ Document Sharing（文書共有）
XDS – Cross-Enterprise Document Sharing（施設間文書共有）
 XDS Stored Query – XDSへの追加統合プロファイル
 XDS-SD – XDS Scanned Documents（XDSスキャン文書）
 XDP – Cross-Enterprise Document Interchange（施設間文書交換）• NAV – Notification of Document Availability（文書入手可能通知）• RID – Retrieve Information for Display•（表示のための情報検索）•注） 「★」は2006年新規追加
6

IHE IT Infrastructureとは?
統合プロファイル – 診療情報 2¾ 患者管理PAM – Patient Administration Management（患者情報管理）• PDQ – Patient Demographics Query（患者基本情報の問合せ）• PIX – Patient Identifier Cross-referencing（患者IDの相互参照）• PSA – Patient Synchronized Applications（患者アプリケーション同期）•

 RFD – Retrieve Form for Data Capture（データ収集のための取り出し形式）注） 「★」は2006年新規追加
7

IHE IT Infrastructureとは?
統合プロファイル – セキュリティ¾ ATNA – Audit Trial and Node Authentication（監査証跡とノード認証）¾ CT – Consistent Time
（統一時刻）¾ DSG – Document Digital Signature（文書電子署名）¾ EUA – Enterprise Use Authentication（施設内利用者認証）¾ PWP – Personnel White Pages（職員登録簿）

8

IHE IT Infrastructureとは?
次のステップ¾ XDS 連合化（地域間連携）¾ PIX、PDQ のHL7V3化¾ トランスポートレイヤーでのWebサービスの利用¾ XUA – Cross-Enterprise User Authentication（施設間利用者認証）¾ リスク管理計画の白書

9

IHE IT Infrastructureとは?
救急時紹介状患者作成のサマリ
Format of the Document Content

and associatedcoded vocabulary
心電図報告
Formatof the Document
Content
and associated coded vocabulary
検査結果文書コンテンツ
Format of the Document Content
and スキャン文書
associated coded vocabulary
Format of the Document Content
and associatedcoded vocabulary
Formatof画像情報the Document
Content

診療サマリ

Format of the Document Content, アレルギー, 問題)
and(投薬
associatedcodedvocabulary
文書コンテンツの書式と関連する語彙コード

患者基本情報の問合せ

患者同意
文書電子署名真正コピーまたは原本の証明

患者IDの相互参照
独立した複数のID領域にわたって
患者IDを対応付ける

文書入手可能通知
新情報について知る

施設間文書共有（XDS）
患者EHRを構成する診療文書の、医療機関間の登録、配布及びアクセス

施設間文書交換

監査証跡とノード認証

RHIOの
支援

セキュアなドメインを形成するための集中化した個人情報監査証跡とノード間認証

統一時刻
複数のネットワークシステムにわたり、時刻を合わせる

CD/USBメディア、及び電子メール送付

10

IHE IT Infrastructureとは?
Electronic Health Record
放射線部門

循環器部門

14 統合プロファイル

4 統合プロファイル

臨床検査部門
5 統合プロファイル

IHE
IT Infrastructure

患者ケア連携1 統合プロファイル

13 統合プロファイル

将来領域

患者ケア機器

病理学部門

眼科部門

腫瘍学部門

11

個別統合プロファイルの紹介
文書共有¾ XDS – 施設間文書共有⋆ XDS Stored Query⋆ XDS-SD – スキャン文書⋆ XDP – 施設間文書交換¾ NAV – 文書入手可能通知¾ RID – 表示のための情報検索

患者管理

セキュリティ
¾ ATNA – 監査証跡とノード認証¾ CT – 統一時刻
¾ DSG – 文書電子署名¾ EUA – 施設内利用者認証¾ XUA – 施設間利用者認証¾ PWP – 職員登録簿¾ PAM – 患者情報管理¾ PDQ – 患者基本情報の問合せ注） 「★」は2006年新規追加¾ PIX – 患者IDの相互参照¾ PSA – 患者アプリケーション同期⋆

RFD – データ収集のための取り出し形式
12

施設間文書共有（XDS）
異なる医療施設間にわたる診療文書の共有（登録、配布とアクセス）のサポート
IHE IT Infrastructureで、施設間用の中心となる
統合プロファイル
文書トレジストリ（診療録登録簿）と、文書リポジト
リ（診療録保管庫）を中心に構成
レジストリの実現には ebXML の Registry 規格を利用（ebXML RIM, RS）
適用中の国: イタリー、フランス、カナダ、オースト
リア、近いうちに米国?
13ebXML
XMLをベースとした電子商取引の標準仕様を提供することを目的とした団体。また同団体によって規定される技術標準。
XMLによる取引情報のフォーマットだけでなく、ビジネスプロセスや通信プロトコル、取引先検索のためのレジストリやリポジトリなど幅広い内容を定義している。
制定規格：RIM, RS, MSG, CPPA, BPSS, 等
http://www.ebxml.org/
14

地域医療情報連携システムのイメージ
レジストリセンター
診療情報の在りかを格納（情報登録簿あるいは目録）

119

レジストリ

診療所
急性期病院
診療所

大学病院
救急患者
紹介

診療所
在宅ケア

リハビリ病院
診療所

療養型施設

急性期病院

在宅ケア

急性期

維持期
回復期
15

IHE-XDS : 2005年のHIMSSで紹介
地域社会、もしくはサブネットワーク
診療所の診療録

専門医の診療録

病院の診療録
文書リポジトリ

診療録の参照

3-診療録を戻す

4-医師に患者
データを提示診療所のITシステム
集められた
患者情報
受診

文書リポジトリ

共有システム

診療録の索引(文書レベル)2-照会したい
診療録を参照 16

医療情報交換の相互運用性:
施設間文書共有
施設間文書共有は、ＩＴ基盤による臨床データ管理の負担を減らす。
透明性 = 発展の容易性
患者にとってデータの持ち運びが可能となり、医療提供者にとってはデータ収集のエラーを気にせず情報共有が可能となる。
電子文書 = 患者 と 医療提供者 双方の 能力向上
集中、非集中、両方式のリポジトリ・アーキテクチャのサポート。国レベルでのネットワーク連結の容易化。
柔軟な個人情報保護、システム構成の柔軟性
次のステップではより簡便な方法でワークフローに取り組んでいる。

ワークフロー管理に適した２地点間のメッセージ交換

17

施設間文書共有 (XDS)

トランザクション図
Patient
Identity Source
患者ID供給Document
Registry

文書の照会

Document
Consumer

文書セットの登録
Document
Source

文書セットの提供と登録

Document
Repository

文書の検索

18

施設間文書共有 (XDS)

アクタ
Document Source
文書に関するメタデータと文書のソース

Document Repository
文書の格納、 Document Registry（診療録登録簿）へ索引付けを要求、検索の支援

Document Registry
文書の索引付け、探索の支援

Patient Identity Source
既知の患者のIDをDocument Registryに供給するDocument Consumer
探索の開始と、利用者の文書の検索
19

施設間文書共有 (XDS)
使用規格
医療コンテンツ規格
HL7 CDA, CEN EHRcom
HL7, ASTM CCR
DICOM …

電子ビジネス規格
ebXML Registry, SOAP …

インターネット規格
HTML, HTTP,
ISO, PDF, JPEG …

世界で30以上のベンダー/オープンソースで実装されている。
最新版は2005年8月発行

いくつかの国家プロジェクトないし地域プロジェクトで採用（イタリア、フランス、カナダ、オーストリア、米国、等）
米国のEHR Vendor Associationの相互運用性ロードマップで利用

IHE XDS: 40,000 “Google” ヒット (2006年6月)
20

施設間文書共有 (XDS)
使用規格二つの”範疇”の規格が使用されている• 診療サマリXDS文書コンテンツ(HL7 CDA/CRS+V3)• 画像 (DICOM)• 心電図報告 (PDF+)• 次は、臨床検査報告、
看護記録、等

XDS基盤(Document sources, consumers,
registries, repostories)

21

文書入手可能通知（NAV）
XDSの利用地域で、所望の文書がリポジトリに登録され、利用可能となったことを自動的に通知する
電子メールの仕掛け（SMTP）を利用

22

施設間文書共有（XDS）で機能する
文書入手可能通知（NAV）
医療施設 B

共有するドキュメント
の登録

施設間
レジストリ
1 ドキュメントの照会

2 共有するドキュメントの登録

3 文書入手可能通知（NAV）
4 ドキュメントの提供
診療所

医療施設 A23

表示のための情報検索（RID）
簡便かつ迅速な、しかし読み出し専用の患者情報アクセス手段の提供¾

専用のアプリがない場合の補完

現在使用中のアプリ中で、しかしそのアプリの外にある患者情報を見られるようにする。
¾

例：放射線部門から臨床検査結果をアクセス

二つのアクセス機能
1.

保存文書の検索と表示•

2.

CDA、PDF、JPEG等、ポピュラーな形式で表示… 概ね任意の端末で表示可能

特定情報の検索と表示–

アレルギー、処方情報、診療サマリ、など
24

RIDの背景は？
例えば、¾ 診療科で放射線検査画像や読影レポートを参照したいとしても、

DICOM環境を用意するのは負担が大きい¾ DICOMの画像やレポートでなく、手元のパソコン環境で簡便に表示できる形式で診療情報が欲しい
え？DICOM
なの？

CDA*/PDF/JPEG(CDA: Clinical Documents Architecture (HL7))より簡便な方法で、他部門の情報を「一時的に」参照した
いというニーズがある☆ ＩＨＥ－Ｊベンダーワークショップ 2005/9/8 (C) Copyright 2005 T.NAKASHIMA より引用

25

表示のための情報検索（RID）
トランザクション図
ディスプレイ表示のための特定情報の検索 [11]情報源

表示のための文書検索 [12]

リクエスト
のタイプ

すべてのリポートの検索
臨床検査リポート・サマリ
処方サマリ
放射線リポート・サマリ
循環器リポート・サマリ
手術リポート・サマリ
集中治療リポート・サマリ
救急リポート・サマリ
退院リポート・サマリ
アレルギー・リスト
投薬リスト
保存文書
26

表示のための情報検索（RID）
使用規格 :¾ Webサービス(WSDL for HTTP Get).
¾ 汎用のIT表現形式：XHTML, PDF, JPEG, CDA L1 (HL7)¾ クライアントソフトは市販のブラウザかディスプレイ・アプリ

ケーション

27

患者情報管理（PAM）
全臨床部門での、患者の登録、更新、移動に関する情報
交換の調整
情報は、各臨床部門の利用アプリケーションで受信ない
し処理可能
入院と外来の両方の個人情報/受診情報の追跡調査
患者の受診状況や居場所も管理患者だけでなく、身元保証人の情報も管理する
既存の数種のIHE統合プロファイルの患者管理プロファ
イルを発展¾ 放射線SWF、カテーテル検査SWF、エコーSWF、

臨床検査SWF、PIX
28

患者情報の問合せ（PAM）
ユースケース
患者情報Source

ICUの看護師が、 現在のベッド番号を検索キーとして患者IDと氏名を問合せ

診察室の医師が、一部の患者情報を検索キーとしてカルテの一覧を問合せ

検査技師が、 患者情報を問合せ、および、他ドメインの患者IDを問合せ

ICU ベッドサイドシステム

診察室システム

臨床検査システム

29

患者情報管理（PAM）
使用規格
HL7 Version 2.5¾ ADT 登録、更新、患者移動トリガーイベント
入院/登録• マージ、更新、関連付け/関連付け解除• 移動管理•30

患者基本情報の問合せ（PDQ）
患者基本情報とは：¾ 患者ID情報¾ 患者氏名、住所、電話番号、生年月日、受診歴(オプション)

31

患者基本情報の問合せ（PDQ）
特長¾ 患者氏名、ID、連絡先および受診歴(オプション)を含

む患者一覧を素早く検索することが可能¾ 完全なID情報が利用できないときも、正しい患者を選択することが可能¾ 全てあるいは一部のデータの検索可¾ クライアントは検索要求に（対応する患者IDドメインにより）情報ソースを指定可¾ 類似探索に照合アルゴリズム (例：Soundex) を使用
可•アルゴリズムや操作の詳細はIHEテクニカルフレームワーク
の範囲外

32

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

トランザクション図
患者属性情報 Supplier

患者情報
問合せ

登録システムで管理されている患者
情報レポジトリへのアクセスができるシステム

患者情報および
来院歴の問合せ

患者属性情報Consumer

様々なシステム：ベッドサイドモニタ、診察室システム、検査システム、モバイル血液
バンク登録システム等々を含む(診療現場における如何なるシステムでも良い)33

患者基本情報の問合せ（PDQ）
使用規格
HL7 Version 2.5¾ 2章 – コントロール¾ 3章 – 患者管理
¾ 5章 – 照会

34

患者IDの相互参照（PIX）
部門ごとに異なるIDを持つ同一患者の情報を検索する。
同一患者の複数のＩＤを「Patient Identifier
Cross-reference Manager」が対応させる¾ 部門毎に患者ＩＤを管理する米国の環境をベースに作られた統合プロファイル•

日本では院内の用途はほとんどない¾ IT Infrastructureの守備範囲が地域に広がったので、拡張して利用されている
35

患者IDの相互参照（PIX）
特長¾ 施設の全職員はおのおのの部門内で使用している患者IDで登録可能¾ 各部門で維持している一つ以上の患者インデックスを継続して使用可能¾ 患者の他システムでのIDの問合せを部門システムの問合せとしてサポート¾ オプションとして、他システムで患者のIDが更新されたとき、部門システムに通知する機能を持つ¾ 1患者に対する全システムでの識別子を1ヶ所でメンテする¾ 異なるIDドメイン間での合致する患者の探索に、（カプセル化されている）任意のアルゴリズムを使用可¾ 複数システムにわたるデータ同期のコストを削減•

既存システムのIDや書式の変更を強いる必要なし¾ IHEで使用中の標準とトランザクションを活用する

36

患者IDの相互参照（PIX）
トランザクション図

患者 ID Source

患者ID供給 [ITI-8] ↓患者 ID Consumer↑ PIX 問合せ [ITI-9]↑ PIX 更新通知[ITI-10]

PIX Manager

37

患者IDの相互参照（PIX）
使用規格
トランザクション：患者ID供給 [ITI-8]
HL7 Version 2.3.1¾ 2章 – コントロール¾ 3章 – 患者管理

トランザクション：PIX問合せ [ITI-9]、
PIX更新通知 [ITI-10]
HL7 Version 2.5¾ 2章 – コントロール¾ 3章 – 患者管理
¾ 5章 – 照会

38

患者IDの相互参照（PIX）
IDドメインとトランザクションを示すプロセスフロー図
PIX Domain
患者ID供給患者ID供給

L-716

14355
A87631

患者ID相互参照要求

患者登録

超音波検査
システム

患者ID相互参照要求
患者登録

35424

14355

L-716

診療情報システム

PIX Manager
患者IDドメインA

患者IDドメインB

患者ID供給患者ID供給A8763135424

患者ID相互参照
通知
患者登録

患者ID相互参照
通知

患者登録

PACS
EHRシステム

患者IDドメインC

患者IDドメインD

39

患者IDの相互参照(PIX)
サービス: PIX問合せと通知
PIX Domain
L-716

14355

患者登録
超音波検査
システム

A: S1763
B: ?
D: ?
A: S1763
B: Y-456
D: A74630

S1763 Y-456 A87631
A7463014355 L-716 A87631 35424
D-776
63452
35424
14355
98532 DF-45
23511
L-716

患者登録

臨床情報システム

PIX Manager

患者IDドメインA

患者IDドメインB

PIX 問合せ
A: 98532
B: DF-45
C: 23511

35424

A87631

患者登録

患者登録

EHRシステム

患者IDドメインC

PIX 通知PACS

患者IDドメインD

40

MPI（マスター患者索引）を使用した
患者IDの相互参照（PIX）
PIX Domain
14355

患者ID供給患者ID供給L-716
A87631
M8354673993

患者登録
超音波検査
システム

35424
35424
L-716

患者登録

A87631
14355
14355
L-716

診療情報システム

PIX Manager

患者ID供給35424

患者IDドメインB

患者ID供給患者IDドメインA

患者ID供給A87631

患者登録

患者登録

EHRシステム

Master Patient
Index (MPI)
M8354673993

PACS

患者IDドメインMPI
患者IDドメインC

患者IDドメインD

41

XDS環境で患者識別サービスを提供する
PIX / PDQアプリケーション

用語¾ XDS: 施設間文書共有¾ アフィニティドメイン: 共通のポリシーセットで連携したり、リポジトリやレジストリの共通インフラを共有するのを合意した医療機関のグループ

42

IHE ITI 統合プロファイル XDS:RHIOにおける臨床情報の共有
XAD
患者ID Source
M8354673993
A87631

14355

ドキュメン
超音波検査 ト問合せ

患者ID供給

システム

救急入院
ドキュメン
ト問合せ

診察室
ドキュメント取得

ドキュメント取得

登録

ドキュメントレジストリ

ドキュメント
リポジトリ

L-716

登録
提供 & 登録提供& 登録
EHRシステム

ドキュメント問合せ

PACS

PACS

登録

ドキュメントリポジトリ
提供 & 登録

ドキュメント取得
検査シス
テム

地域のクリニック

XDSアフィニティドメイン(XAD)においてクリニカルドキュメ
ントを公開したり問合せするために、アプリはローカルの患
教育病院
者情報(例：ローカルドメイン内の患者IDと属性)を用いてXADの患者IDを検索する必要がある
XDSクリニカルアフィニティドメイン
43

ローカルPIXサービスによる
XDSアフィニティドメインの患者ID検索
XAD
患者ID Source
M8354673993

患者ID供給患者ID供給A87631
M8354673993

14355

患者ID供給
超音波検査
システム

救急入院

患者ID供給診察室

A87631

患者ID供給14355
M8354673993

患者ID供給L-716

ドキュメントレジストリ

ドキュメント
リポジトリ

L-716

PACS

PIX問合せPIX問合せEHRシステム

ドキュメント問合せ

PACS

登録

ドキュメントリポジトリ
提供 & 登録

ドキュメント取得
検査シス
テム

地域のクリニック

教育病院

XDSクリニカルアフィニティドメイン

44

アフィニティドメインPIXサービスによる
XDS アフィニティドメインの患者ID検索
患者ID供給A87631
M8354673993
M8354673993
L-716

14355

超音波検査
システム

M8354673993

診察室

14355
L-716

A87631

A87631

XAD
患者ID Source

救急入院

患者ID供給患者ID供給ドキュメントレジストリ

ドキュメント
リポジトリ

L-716

患者ID供給14355

PIX問合せPIX問合せEHRシステム

ドキュメント問合せ

PACS

PACS

登録

ドキュメントリポジトリ
提供 & 登録

ドキュメント取得
検査シス
テム

地域のクリニック

教育病院

XDSクリニカルアフィニティドメイン

45

XDSアフィニティドメイン患者ID問合せのための
アフィニティドメインPDQサービス
患者属性情報Supplier

14355

超音波検査
システム

M8354673993

診察室

A87631

XAD
患者ID Source

救急入院

患者ID送信ドキュメントレジストリ

ドキュメント
リポジトリ

L-716

XADの患者IDを取得するためにPDQ問合せ

XADの患者IDを取得するために
PDQ問合せドキュメント問合せ

PACS

PACS

EHRシステム

ドキュメントリポジトリ
登録提供 & 登録

ドキュメント取得
検査シス
テム

地域のクリニック

教育病院

XDSクリニカルアフィニティドメイン

46

患者アプリケーション同期（PSA）
デスクトップ上の複数の異なるアプリケーションの対象データを同一患者に維持する
PIXプロファイルとつなぐと、複数患者IDドメイン
にわたる患者アプリ同期が可能となる
EUAプロファイルとつなぐと、シングルサインオン（SSO）機能を提供する

47

患者アプリケーション同期（PSA）
利点
利用者の便宜:¾ アプリケーションごとに繰り返し行う患者選択作業の省略¾ なじみの、また対象の臨床ワークフローに適したアプリケーション

で患者を選択することを可能にする

患者安全:¾ 複数アプリケーションにわたって見ているすべてのデータが同一患者のものであることを保証する

単一開発環境の利用:¾ ベンダーに対して、複数アクタをサポートするために単一のCCOW環境を利用可能にする••

患者関係のアプリ (PSA)
利用者関係のアプリ (EUA)48

患者アプリケーション同期（PSA）
使用規格
HL7 Context Management “CCOW”
Standard, Version 1.4:
¾ CCOW : もともとは “Clinical Context Object

Workgroup” の略だが、今は単にCCOWと言う

Support for both Windows and Web
Technology
Support of “Patient Subject”

49

CCOW（シーカウ）とは(The Clinical Context Object Workgroup)※Sea cow : ジュゴン

Visual Integration の規格としてHL7で検討され、
ANSI標準としても承認されている
Visual Integration とは¾ サーバ間で情報のやり取りをするのではなく、操作端末のデスクトップ上で見掛けの情報の統合・連携を行う¾ 画面上の独立したアプリケーションウィンドウの中に表示あるいは入力される情報を連携させる¾ 解決すべき問題点は、情報の連携を管理する仕組みと、ユーザ操作の通知とそれに伴う同期の管理である¾ CCOWではその仕組みを標準規格化している☆ ＩＨＥ－Ｊベンダーワークショップ 2005/9/8 (C) Copyright 2005 T.NAKASHIMA より引用

50

ＰＳＡでのCCOWとは...

()• 同一デスクトップ画面上で、独立したアプリ
ケーションに対して、同一患者に同期させる
仕組み
レポート参照画像参照

電子カルテ参照

同一患者の情報が表示される☆ ＩＨＥ－Ｊベンダーワークショップ 2005/9/8 (C) Copyright 2005 T.NAKASHIMA より引用

51

解決しようとする問題()

従来の方法では、あるアプリケーションが表示するウィンドウの患者を変更しても、他のウィンドウが表示する情報は以前のまま

電子カルテサーバ

患者変更
レポートサーバ

画像サーバ☆ ＩＨＥ－Ｊベンダーワークショップ 2005/9/8 (C) Copyright 2005 T.NAKASHIMA より引用

52

患者アプリケーション同期()

ひとつのウィンドウで患者を変更したら、他のウィンドウでもその患者の情報を表示する

Context
Manager☆ ＩＨＥ－Ｊベンダーワークショップ 2005/9/8 (C) Copyright 2005 T.NAKASHIMA より引用

53

IHE IT Infrastructureのセキュリティ関係統合プロファイル
ユーザー識別 Æ PWP、EUA
ユーザー認証 Æ EUA
ノード認証 Æ ATNA
セキュリティ監査証跡 Æ ATNA
データ完全性管理 Æ CT、ATNA TLSオプション
データ機密性 Æ ATNA TLSオプション
アクセス制御 Æ （RBAC）

54

セキュリティ要件
理由：臨床での使用と個人情報保護¾ 医療従事者は患者の診療情報にアクセスしなくてはならないが、その情報を他に開示してはならない¾ 許可されていない人が業務の邪魔をしたり、データを変更したりすることができないようにすべきである

運用とセキュリティ機構により、以下を保証する¾ 機密性（Confidentiality）¾ 完全性（Integrity）¾ 可用性（Availability）¾ 信頼性（Authenticity）
55

セキュリティ施策
認証：ユーザとシステムのアイデンティティを確立する。

「あなたは誰？」という質問に答える

ATNAの規定：ネットワーク接続をどのように認証するか• ATNAのサポート：認証メカニズム 例：施設内利用者認証（EUA） または施設間両者認証（XUA）．．
•

権限付与とアクセス制御：

ユーザのできることを明確にする。たとえばデータへのア
クセスで、「あなたが誰かは知っているけど、何をしていいの？」という質問に答える
ATNAの規定：どのようにネットワーク接続を許可するか• ATNAの要求：ローカルとネットワーク双方からのアクセスに対応するシステム内部メカニズム•56

セキュリティ施策
説明責任と監査証跡：
ユーザまたはシステムの一定期間の動作履歴を確定させる。「あんた、何をしたの？」という質問に答える•

ATNAの規定：監査メッセージ形式とト通信のプロトコル57

監査証跡とノード認証（ATNA）
集中監査証跡とノード間認証によりセキュアなドメインを形成する
医療機関のセキュリティ環境と個人情報保護環境の一部として使用する個々のシステムについて、基本的なセキュリティ機能を定義する
IHE放射線部門用の基本セキュリティプロファイル（2002年に定義）を他の医療部門に適用できるように拡張した
ホストレベルの認証を実施する。この認証は、EUAとXUAによるユーザー認証と連携して使用する

58

監査証跡とノード認証（ATNA）
信頼できるノードの構築• ローカルアクセス制御（利用者認証）• リモートノードの強力な認証（デジタル証明書）• ネットワーク通信時の暗号化はオプション、必須ではない• 監査証跡：• リアルタイムアクセス• 時間的同期

セキュアなシステム
セキュアなシステム
セキュアネットワーク
システムB

システムA

中央
監査証跡
リポジトリ
59

ATNA
ノード認証
X.509証明書をノードの識別と鍵として使用する
TCP/IPトランスポート層セキュリティプロトコル（TLS）をノード認証と、オプションとして暗号化に使用する
アソシエーションの確立時に双方のセキュア･ハ
ンドシェイク･プロトコルを使用する¾ 暗号化プロトコルの識別¾ セッション鍵の交換

アクタは許可されたノードの証明書リストを作れなければならない
ATNAは現時点では、HTTP、DICOM、HL7に対するメカニズムを指定する
60

なぜ、ノード認証なのか？
CTシステムなど、多くのシステムはアクセスを共用しており、セキュリティ目的としてはオペレータの識別よりマシンの識別の方が重要である•

CTの操作者に許されているのは、CTシステムからCT記録を更新することだけである

PACSアーカイブなど、自律的に動作するシステムもある•

PACSの動作内容をモニターするとき、勤務中のPACS管理者を知っても意味はない。たいてい誰もログインしていない。

機器のアクセスは通常、施設全体管理者によって管理されている•

許可されたユーザーであっても、個人のマシンを使用してアクセスすることは許されない

61

ATNA
監査システム
法的な利用よりも監視の目的で設計されている2種類の監査メッセージ形式¾ IHE放射線部門用暫定形式。放射線部門用と下位互

換¾ IETF/DICOM/HL7/ASTM形式。将来拡張可能
DICOM Supplement 95• IETF Draft for Common Audit Message• ASTM E.214• HL7 Audit Informative documents•

両形式ともXMLメッセージであり、XML規格の拡張メカニズムを使用して拡張可能である
62

監査証跡
関連する国内・海外状況¾ 相互運用性実証事業•

監査証跡のフレームワークについて検討¾ JAHIS/JIRA合同 監査証跡WG•

監査証跡メッセージ標準規約を策定中¾ ISO TC215•

韓国済州島会議（2006.4）で新しいタスクグループを立上げ“Audit trails for electronic health records”

63

時刻の整合性（CT）
ネットワークタイムプロトコル（NTP）バージョン3（RFC 1305）を時刻の同期に使用
する
アクタは手動での調整をサポートすること
要求精度：1秒
オプションとしてセキュアNTPを使用できる
ATNA、EUA、XUAを使用する場合はCTが必須である64

文書電子署名（DSG）
電子署名の目的¾ 説明責任（Accountability）¾ 文書の完全性（Document Integrity）¾ 否認防止（non-repudiation）¾ 著作者、承認、レビュー、認証に対する十分なエビデ

ンスの提供

65

文書電子署名（DSG）
IHE DSGの特長¾ XDS文書基盤の利用¾ XDSレジストリを使用しない他の分野での活用•

電子処方箋、電子紹介状

66

文書電子署名（DSG）
電子署名の原理¾ PKI（Public Key Infrastructure : 公開鍵基盤）の利用•

非対称アルゴリズムによる暗号化技術の利用– 暗号化は簡単だが、鍵がないと復号は困難（実用的時間内に解けない）。
– 素数を利用した方式、楕円関数を利用した方式、など

•

公開鍵方式
– 公開鍵と秘密鍵– 公開鍵を相手に渡し、秘密鍵は自分で保持する– 秘密鍵で暗号化、公開鍵で復号•

PKIは、VPN（Virtual Private Network）やSSL（Secure
Socket Layer）など、通常のインターネット通信でも広く使わ
れている。
67

文書電子署名（DSG）

署名の実施
結合して、署名済み文書を作る

文書
原本

イコール

ハッシュ関数非対象
アルゴリズム

署名用秘密鍵68

文書電子署名（DSG）
文書
原本

検証
メッセージ・ハッシュEAdfj78oXWq
ハッシュ関数

署名
文書

イコール

署名者の
公開鍵

非対称アルゴリズム
署名

EAdfj78oXWq
オリジナル・ハッシュ(署名者作成)69

文書電子署名（DSG）
一般用電子署名¾ ITUの勧告X.509V3による公開証明書、それに基づくIETFの

RFC3280基本プロファイルにより規定¾ 認証局（CA）が発行する公開鍵証明書により署名の真正性を保証する
ISO TS17090 (Health Informatics - Public key
infrastructure）¾ 一般用電子署名を拡張。医療分野における役割を規定するエク
ステンション（hcrole）を定義している¾ IS（国際標準）化見込み

IHE DSG（Digital Signature）¾ ISO TS17090準拠¾ W3C XML署名¾ XML長期署名規格（XaDES）に対応

70

文書電子署名（DSG）

主要技術
W3C XML 証明の構成¾ 証明書、タイムスタンプ、その他の署名属性（署名の目的など）XDSに格納された文書の参照
ISO TS17090 準拠デジタル証明書
メッセージの完全性を保証
署名済み文書の有効性の検証
多重署名機能の提供
71

文書電子署名（DSG）
日本における医療用電子署名の状況¾ H13.4 電子署名法施行¾ H15年度、MEDIS-DCでTS17090に基づくHPKIの実

証実験を実施¾ 厚労省医療情報ネットワーク基盤検討会で「HPKI認証局 証明書ポリシ」を作成（H17.4）¾ その後「HPKI認証局の整備と運営に関する専門家会議」を開催（H18.3までに2回）¾ H18年度、厚労省ルートCA局及び日医CA局、
MEDIS CA局を構築、認証業務のフィージビリティ検証を行う
72

タイムスタンプ
タイムスタンプ¾ あるアクションが正しい時間に実施されたことを証明するために必要。特に電子署名文書では必須¾ 正しい時間を保証するためには、ネットワークに散在するマシンの時間の同期をとる必要がある

国際規格¾ IETF RFC3161（PKI Time-Stamp Protocol）¾ IETF RFC1305（Network Time Protocol）、等IHE¾ CT（Consistent Time）： RFC1305によるネットワーク上の時刻一貫性維持

日本における状況¾ H16.11 総務省「タイムビジネスに係る指針（ネットワークの安心な利用と電子データの 安全な長期保存のために）」¾ H17.2 (財)日本データ通信協会が「タイムビジネス信頼・安心認定制度」創設¾ 現在、アマノ、セイコーインスツルメンツ、PFUなど数社がサービス提供中73

利用者認証現状は個別の医療情報システムベンダーが、ID＋パスワー
ドやカード等のデバイス、生体認証などによる独自の認証手段を提供している一つの施設内でもマルチベンダーシステムを導入している
施設は、ログインの手間を省くため（SSO：シングルサインオン）共通の認証手段が必要となる地域連携では当然共通の認証手段が必要
IHE IT Infrastructureテクニカルフレームワークでは、以下の二つの統合プロファイルを提供している¾ EUA（Enterprise User Authentication）：施設内利用者認証¾ XUA（Cross-Enterprise User Authentication）：施設間利用者認証

74

施設内利用者認証（EUA）
施設内の一元的利用者認証¾ 単一のセキュリティポリシィ、共通のネットワークドメインが前提

シングルサインオンをサポート
認証Kerberos＋利用者アプリ同期CCOWを利用¾ Kerberos： MITで開発された分散環境向け利用者認証方式。利用者はKerberosサーバに問い合わせることにより認証を得る。このときチケットと呼ばれる信用証明書が与えられる。以後この証明書を使用してネットワーク上のリソースを利用する。
DCE及びWindows 2000 Server標準装備¾ CCOW： HL7 コンテキスト管理規格75

Kerberos（ケルベロス）とはAthenaプロジェクトで、MIT、IBM、DECが研究開発したネッ
トワーク認証システムである (1983)「信頼された第３者機関による認証方式」(Trusted Third Party Authentication)

IETF（Internet Engineering Task Force）認定のオープン
標準
設計方針¾ 双方向認証

サーバによるクライアント認証、または、その逆¾ パスワードは認証後消失¾ 暗号の鍵は寿命あり☆ ＩＨＥ－Ｊベンダーワークショップ 2005/9/8 (C) Copyright 2005 T.NAKASHIMA から引用

76

Kerberosの基本概念･用語
発行局 KDCKey Distribution Center

王国（領域）Realm（レルム）¾ KDC が支配する複数のクライアントとサーバを含む領域

秘密鍵

共有鍵という表現が適切か？

チケット

サービス供給元へのアクセス許可証

セッション鍵 一時的な通信暗号鍵
証明書
たもの

チケットとセッション鍵がセットになっ☆ ＩＨＥ－Ｊベンダーワークショップ 2005/9/8 (C) Copyright 2005 T.NAKASHIMA から引用

77

基本的な認証の手順
Client１）ターゲットに対するチケットを要求する

KDC(Key Distribution Server)

２）チケットを含んだ証明書を返すクライアントの秘密鍵

クライアントの秘密鍵
ターゲットの秘密鍵

３）チケットを送信する

証明書

Application Server(Target)４）認証完了クライアントの秘密鍵で暗号化セッション鍵（一時的な暗号鍵）
チケット
ターゲットの秘密鍵で暗号化

ターゲットの秘密鍵

サーバー名、クライアント名、クライアントのIPアドレス、タイムスタンプ、
有効期限、ランダムなセッション鍵（一時的な暗号鍵）78☆ ＩＨＥ－Ｊベンダーワークショップ 2005/9/8 (C) Copyright 2005 T.NAKASHIMA から引用

従来の情報システムの例()

電子カルテクライアント

電子カルテサーバ

データ伝送・交換
レポートサーバ

画像サーバ☆ ＩＨＥ－Ｊベンダーワークショップ 2005/9/8 (C) Copyright 2005 T.NAKASHIMA から引用

79

Web版情報システム()

Web クライアント

Web Access
各Window にlogin/logoutする必要がある、
電子カルテサーバ
各Windowが表示している情報は同期すべきである
Web Accessなどの問題が生じる
レポートサーバ

Web Access

画像サーバ☆ ＩＨＥ－Ｊベンダーワークショップ 2005/9/8 (C) Copyright 2005 T.NAKASHIMA から引用

80

CCOW が解決しようとする方式 ()

電子カルテクライアント

Context
Manager

電子カルテサーバ

User Link,
Patient Link etc.
レポートサーバ

画像サーバ☆ ＩＨＥ－Ｊベンダーワークショップ 2005/9/8 (C) Copyright 2005 T.NAKASHIMA から引用

81

EUAでのCCOWとは...

()• 同一デスクトップ画面上で、独立したアプリ
ケーションに対して、同一ユーザに同期させる仕組み
レポート参照画像参照

電子カルテ参照

Single Sign on☆ ＩＨＥ－Ｊベンダーワークショップ 2005/9/8 (C) Copyright 2005 T.NAKASHIMA から引用

82

解決しようとする問題()

従来の方法では、この端末のユーザが代わる時には全てのアプリケーションとＰＣに対してlogoutとloginが必要であった

電子カルテサーバ

logout/login
レポートサーバ

画像サーバ☆ ＩＨＥ－Ｊベンダーワークショップ 2005/9/8 (C) Copyright 2005 T.NAKASHIMA から引用

83

ユーザアプリケーション同期()

一度loginすれば全てのWindowに同一ユーザでloginできる
login後に起動するWindowも同一ユーザで自動的にloginされる

Context
Manager☆ ＩＨＥ－Ｊベンダーワークショップ 2005/9/8 (C) Copyright 2005 T.NAKASHIMA から引用

84

施設内利用者認証（EUA）
EUA = Kerberos + CCOW(☆ ＩＨＥ－Ｊベンダーワークショップ 2005/9/8 (C) Copyright 2005 T.NAKASHIMA から引用)

85

施設間利用者認証（XUA）
概要と範囲
施設間にまたがるユーザー認証の提供
認証強度情報の提供
オプションとして連絡先情報の提供
利用者IDの開示メカニズムはIHEのプロファイ
ルで指定される。また地域ドメインのポリシーにより制約を受ける。

86

施設間利用者認証（XUA）
特長
利用者IDの地域ドメインへの拡張¾ 任意の施設間トランザクションをサポート¾ 連携型、または集中型

必要な情報を提供し、XDSアクタがアクセス制御の決定を行えるようにする¾ アクセス制御のメカニズムは含まない

必要な情報を提供し、XDSアクタが詳細かつ正確なセキュリティ監査証跡を生成できるようにする
87

施設間利用者認証（XUA）
2 認証要求(この利用者が誰であるか)

XDS
リポジトリ

5 認証結果

1X
DS
検
索

ATNA
監査
リポジトリ

監査
事象の
記録

3利

用

4利

者

用

ID

者

の

ID

要

の

求

提

ID
提供元

供

88

施設間利用者認証（XUA）
使用規格
SAML2.0プロファイルを採用
SAMLブラウザのSSOプロファイルの利用を指定、クライアント/プロキシ・プロファイルを拡張した
SAMLプロファイルをXDS（すなわちebXML
レジストリ）と一緒に使用することを指定¾ SAMLの使用がebXML 3.0 と両立すること

SAML2.0の仕組みを拡張してHL7に合わせる¾ 将来はDICOMも

89

SAML
SAML: Security Assertion Markup Language
標準化団体OASISによって策定された、IDやパスワードなどの認証情報を安全に交換するためのXML仕様。一
度の認証で複数のWebサイトやサービスが利用できるSingle Sign-On（SSO）を実現。
¾ OASIS:ビジネスにおける情報交換用技術標準を作成する国際団体。XMLやSGMLなどの標準技術をベースに活動。

従来のSSOと異なり認証クッキーを使用しないので、クッ
キードメインの制限がなく、グローバルなSSOを実現できる。
現行版はSAML 2.0
90

施設間利用者認証（XUA）

アクタ
利用者認証提供者 – 仕様にはな
利用者いが必要である。EUAないし他
認証の認証システムでよい提供者
X-ID提供者 – SAML ID 提供者
X-サービス利用者 – 利用者と相互作用する任意のIHE アクタ
で、 “利用者認証提供者”を用いて利用者の認証を行った
X-サービス提供者 – XUAを要求する任意のIHEアクタ
X-サービス
利用者
破線 – 既存のトランザクション
実線 – XUA

X-ID
提供者

X-サービス
提供者

91

施設間利用者認証（XUA）
実装例
EHR (ATNA セキュア・ノード)
XDS 利用者

XDSレジストリ(ATNAセキュア・ノード)

X-サービス
利用者

利用者
認証提供

X-ID
提供者
Key:

患者
データ

監査
ログ

利用者
認証

Original Transaction
XUA Assertion
TLS Protections92職員登録簿（PWP）
White Page：個人別電話帳⇔ Yellow Pages ：職業別電話帳
病院スタッフの基本情報へのアクセス手段を提供する
PWP（職員登録簿）を見つける方法を定義
問合せとアクセス方法の定義

93

PWP – トランザクション

職員登録簿
の探索
職員
登録簿
利用者

医療職員
情報の
問合せ

DNS
サーバ

職員
登録簿
ディレクトリ

標準の方法でシステムに医療職員情報をアクセスする手段の提供
94

XDS シナリオ + ATNA と CT の利用

EHR System PMSED Application

Physician Office
XDS
Document
Repository

XDS
Document
Registry

PACS

XDS
Document
Repository
Query Document

Register Document

Secured Messaging

PACS

EHR System

Retrieve Document
Maintain TimeLab Info.
SystemCommunity Clinic

Record Audit
Event

MaintainTime
ATNA Audit
CT Time serverrecord repository

Record Audit
Event

MaintainTime

Provide & Register Docs

Teaching Hospital

Record Audit
Event

XDS Affinity Domain (NHIN sub-network)

95

XDS シナリオ + PIX と PDQ の利用
PDQ Query to Acquire Affinity Domain
Patient ID

Patient Identity XRef Mgr

Patient Identity Feed
Patient Identity Feed

A87631
M8354673993
M8354673993

M8354673993

L-716

L-716

Physician Office
Patient Identity Feed

M8354673993

ED Application

Patient Identity Feed
PIX
Document
Query
Registry

XDS
Document
Repository

L-716

A87631Affinity Domain Patient
Identity Source

EHR System

PIX
Query

Lab Info.
System

PACS
A87631

XDS
Document
Repository

Query Document (using Pt Id)

PACS
PACS

14355

Register (using Pt ID)

Retrieve Document

EHR System
Provide & Register Docs

Teaching Hospital
Community Clinic
ATNA Audit
record repository

CT Time server

XDS Affinity Domain (NHIN sub-network)

96

XDSドメインと非XDSドメインの連結
Leverage Connecting for Health RLS – 2006-2007 Development
State RHIO

CrossCross-state IDN

Cancer Treatment

XDS Affinity Domain (NHIN sub-network)
A87631
Pati
M8354673993
M8354673993
ent14355
L-716
L-716 Iden
A87631Affinity Domain Patienttity
EHR System Identity Source
M8354673993
XRe
f
Mgr
A87631
Pati
M8354673993
M8354673993
ent14355
L-716
L-716 Iden
A87631Affinity Domain Patienttity
EHR System Identity Source
M8354673993
XRe
f
Mgr
A87631
Pati
M8354673993
M8354673993
ent14355
L-716
L-716 Iden
A87631Affinity Domain Patienttity
EHR System Identity Source
M8354673993
XRe
f
Mgr
L-716Patient
Identity
Feed PIX Query
PA
PA
CS
CS

ED
Applic
ation

PA
PA
CS
CS

L-716Patient
Identity
Feed PIX Query

A87631
Pati
M8354673993
M8354673993
ent14355
L-716
L-716 Iden
A87631Affinity Domain Patienttity
EHR System Identity Source
EHR System
M8354673993
XRe
f
Mgr

PA
CS

L-716Patient
Identity
Feed PIX QueryED
Applic
La
ationb
PA Inf
A87631
CS o.
Sy
ste
XDS
Affinity Domain (NHIN sub-network)
EHR
mSystem

EDPA
PA
Applic
CS
La
CS
ation
b
XDS Affinity Domain (NHIN sub-network)
Inf
PA
A87631
o.
CS
Sy
ste
XDS
EHR Systemm Affinity Domain (NHIN sub-network)

A87631

L-716Patient
Identity
Feed PIX QueryED
Application
PACS

A87631
Pati
M8354673993
M8354673993
ent14355
L-716
L-716 Iden
A87631Affinity Domain Patienttity
EHR System Identity Source
M8354673993
XRe
f
Mgr

A87631EHR System

PA
PA
CS
La
CS
b
XDS Affinity DomainInf(NHIN sub-network)
o.
Sy
ste
XDS
m Affinity Domain (NHIN sub-network)

PA
PA
CS
CS

La
b
Inf
o.
Sy
ste
XDS
m Affinity Domain (NHIN sub-network)

PACS
PACS

ATNA
Audit
recordrepository

CT Time server

XDS Affinity Domain (NHIN sub-network)

A87631

Sub-Network

CT Time server

XDS Affinity Domain (NHIN sub-network)

A87631ED Application

EHR System
PACS
PACS

PACS
A87631

XDS
Docu
ment
Repo
sitor
y

PIX Query

Teaching
HospitalCommunity
Clinic

L-716

Docu
ment
Regi
stry

XDS
Docu
ment
Repo
sitor
y

L-716

Lab Info.
SystemATNA
Audit
recordrepository

Patient
Identity
Feed

PACS

XDS
Docu
ment
Repo
sitor
y

EHR System

Teaching
HospitalCommunity
Clinic

La
b
Inf
o.
Sy
ste
XDS
m Affinity Domain (NHIN sub-network)

14355

M8354673993

Physician
OfficeEHR System

Lab Info.
SystemTeaching
HospitalCommunity
Clinic
ATNA
Audit
recordrepository

CT Time server

XDS Affinity Domain (NHIN sub-network)

ED
Application
PACS

A87631EHR System

PA
PA
CS
CS

Affinity Domain Patient
Identity Source

EHR System
ED Application

PIX Query

Lab Info.
System

L-716

A87631

Docu
ment
Regi
stry

XDS
Docu
ment
Repo
sitor
y

L-716
XDS
Docu
ment
Repo
sitor
y

PACS

Patient
Identity
Feed

A87631

L-716

M8354673993

Physician
Office

PACS

Docu
ment
Regi
stry

XDS
Docu
ment
Repo
sitor
y

L-716Patient
Identity
Feed PIX Query

A87631
M8354673993
M8354673993

14355

Affinity Domain Patient
Identity Source

EHR System
ED Application

PIX Query

PACS

L-716

A87631Affinity Domain Patient
Identity Source

Patient
Identity
Feed

A87631
Pati
M8354673993
M8354673993
ent14355
L-716
L-716 Iden
A87631Affinity Domain Patienttity
EHR System Identity Source
M8354673993
XRe
XDS Affinity Domain (NHIN sub-network)
f
Mgr

La
b
Inf
o.
Sy
ste
XDS
m Affinity Domain (NHIN sub-network)

Patient Identity XRef Mgr

A87631
M8354673993
M8354673993

14355

M8354673993

L-716

Sub-Network

Patient Identity XRef Mgr

A87631
M8354673993

L-716

La
b
Inf
o.
Sy
ste
XDS
m Affinity Domain (NHIN sub-network)

La
b
Inf
PA
A87631
o.
CS
Sy
ste
XDS
EHR Systemm Affinity Domain (NHIN sub-network)

Registry
Locator service

Sub-Network

Patient Identity XRef Mgr

L-716

L-716Patient
Identity
Feed PIX Query
PA
PA
CS
CS

A87631EHR System

PA ED
PA
CS Applic
CS ation

Which regisry holds

Sub-Network
EHR System

ED
Application

ED
Application
PACS

L-716Patient
Identity
Feed PIX Query

Registry
records for a patient ?
Locator service

State RHIO

Physician
OfficeA87631
Pati
M8354673993
M8354673993
ent14355
L-716
L-716 Iden
A87631Affinity Domain Patienttity
EHR System Identity Source
M8354673993
XRe
f
Mgr

PA
A87631
L-716PatientCS
Identity
XDS Affinity Domain (NHIN sub-network)
Feed PIX QueryEHR System

NHIN
Backbone

Registry
Locator service

M8354673993

A87631
Pati
M8354673993
M8354673993
ent14355
L-716
L-716 Iden
A87631Affinity Domain Patienttity
EHR System Identity Source
M8354673993
XRe
f
Mgr

Registry
Locator service

Integrated
Delivery
Network
XDS Affinity Domain (NHIN sub-network)97

2006-2007の新プロファイル
Supplements
パブコメ締め切り： 2006年7月5日¾ XDS Stored Query¾ XDS-SD – スキャン文書¾ XDP – 施設間文書交換

98Flexible Infrastructure:
共有、送付、交換
Health Information Exchange or RHIO

XDS
PublishStructured
objects

Pull

Pull

Workflow
Mgr

Send to
XDP

SwitchSend to

Write

Interchange
Media

Read

Workflow
MgrTransactions
99

XDSの応用
XDS-I
PCC
XDS-LAB100

施設間画像情報共有（XDS-I）
施設間で画像情報を共有する
画像情報とは以下のものを含む¾ 広義のDICOMインスタンス

画像、evidence documents、presentation states¾ （表示用の）読影レポート¾ レポートに関連したキー画像

101

RHINにおける放射線レポート・画像の共有
RHIN：
地域医療情報ネット
ワーク

放射線施設 B

PACS B

放射線施設－放射線施設

診療所－放射線施設
PACS A
診療所

放射線施設 A102

RHINにおける放射線レポート・画像の共有
RHIN：
地域医療情報ネット
ワーク

放射線施設 B

PACS B
患者Id= 3547F45

施設間
レジストリ

• レポート 5/21/1998 : CT頭部 ÎB• 検査画像 5/21/1998 : CT頭部 ÎB• レポート 2/18/2005 : 胸部X線 ÎA• 検査画像 2/18/2005 : 胸部X線 ÎA

PACS A
診療所

放射線施設 A103

通常の画像検査の紹介ケース～ RHINにおける診療医と医療のしくみ～
地域医療情報ネット
ワーク

放射線施設 B①共有する画像情報の
登録

施設間
レジストリ
患者Id= 3547F45• レポート 5/21/1998 : CT 頭部 ÎB②ドキュメント• 検査画像 5/21/1998 : CT 頭部 ÎB 検索

診療所

③過去の
レポートと
④共有する画像情報の 検査画像
登録

放射線施設 A104

通常の画像検査の紹介ケース～ RHINにおける診療医と医療のしくみ～
地域医療情報ネット
ワーク

放射線施設 B

共有する画像情報
の登録

施設間
レジストリ

④共有する画像情報の登録⑤文書入手可能通知

診療所

放射線施設 A105

通常の画像検査の紹介ケース～ RHINにおける診療医と医療のしくみ～
地域医療情報ネット
ワーク

放射線施設 B

患者Id= 3547F45
⑧過去の
レポートと
検査画像

• レポート 5/21/1998 : CT頭部 ÎB
施設間 • 検査画像 5/21/1998 : CT頭部 ÎB
レジストリ • レポート 2/18/2005 : 胸部X線 ÎA• 検査画像 2/18/2005 : 胸部X線 ÎA⑥ドキュメント検索⑤文書入手可能通知⑦画像レポート &検査

診療所

放射線施設 A106

XDS-I とXDSの関係
XDS-I はXDSをベースにしている。
アクターはXDSと同じ¾ Document Source¾ Document Consumer¾ Document Registry¾ Document Repository

画像検査データ（画像とレポート）のサポートを追加し
ている

107

XDS-I アクタとトランザクション
Patient
Identity Source
患者ＩＤのフィード

Document
Registry

ドキュメントの問い合わせ

Document
Consumer

ドキュメント・セットの登録
Document
SourceImage Manager
Image Archive

ドキュメント・セットの提供＆登録

Document
Repository

ドキュメントの取り出し
画像の検索
Retrieve Presentation States
Retrieve Key Image Note
Retrieve Evidence Documents
WADO Retrieve

108患者ケア連携（PCC）
2005年に導入された新しいテクニカルフレーム
ワーク
ケアの連携
¾ 医療提供者間で¾ 患者の複数の問題にわたって¾ 時間を越えて

XDSの成功の上に構築
データ型の混在¾ 現状は構造化されていないテキストが主¾ +/- 構造化されたデータの混在109

患者ケア連携（PCC）
コンテンツ統合プロファイル
2005-2006
2006-2007
病歴聴取と
身体診察

処置前
病歴聴取と
身体診察

PPHP

XDS-MS
診療ドキュメント

診療
サマリ

同意

BCCP
検査報告

PHR抜粋
PHR抜粋

PHR更新
PHR更新

紹介状

退院時
サマリ

救急部門
紹介状

EDR

XPHR
XDS-LAB110

患者ケア連携（PCC）
統合プロファイルロードマップ
Year 2005-2006 (試行実装)¾ 診療サマリ [MS] – 急性期医療からかかりつけ医への退院時サマリ、かかりつけ医から専門医への紹介状¾ 非構造化文書 – CDAで包んだPDF

Year 2006-2007 (開発と試験)¾ 診療サマリ [MS] – 救急部門紹介状 [EDR]¾ 手術前の病歴聴取と身体診察 [PPHP]¾ 基本的な患者プライバシー同意 [BPPC]¾ 患者カルテ交換 [XPHR]¾ 検査部門との連携 [XDS-LAB]

将来 (プロファイル文書 / 白書)¾ 診療サマリ [MS] – LTCに向けての退院時サマリ¾ データ取得の書式表示 (例 臨床研究)
111

患者ケア連携（PCC）
診療サマリ・プロファイル
文書移送 (統合プロファイル)¾ XDS/XDP 文書共有用.
¾ NAV 通知用.
¾ 組織をサポートするXDS フォルダ.
¾ パッケージ化をサポートするXDS 登録セット.
¾ 「主要」文書もしくは目録の同定

文書コンテンツ (コンテンツプロファイル)¾ CDA Release 2.0¾ Care Record Summaries 実装ガイド112

患者ケア連携（ＰＣＣ）
コンテンツ統合プロファイル
特定の標準を使用するコンテンツ¾ CDA Release 2.0¾ HL7 Care Record Summary (CRS)¾ ASTM/HL7 Continuity of Care Document (CCD)¾ 必要に応じて他も (e.g., ASTM CCR, DICOM …)

再利用可能な部品のライブラリ¾ 文書タイプ¾ セクション
¾ 入力

113

患者プライバシーの基本同意（BPPC）XDS-MS
診療ドキュメント

病歴聴取と
身体診察

診療
サマリ

同意
同意

BCCP

処置前
病歴聴取と
身体診察

PHR抜粋
PHR抜粋

BCCP

PPHP

検査報告

紹介状

退院時
サマリ

E

PHR更新
PHR更新

XPHR
XDS-LAB114

患者プライバシーの基本同意（BPPC）
患者プライバシーの基本同意 (BPPC) プロファ
イルは、以下の機構を提供する:¾ 患者プライバシー同意の記録、¾ 公開を許可するのに用いられる患者プライバシー同意付きでXDSへ公開された文書の印付け、¾ 使用に適切なプライバシー同意の強制

115

IHE IT Infrastructure ロードマップ
EHR サポート

ステージ0

2004年コネクタソンに向けた2003年プロファイル
開発成果

ステージ1

2005年コネクタソンに向けた2004年プロファイル
開発成果

ステージ2

2006年コネクタソンに向けた2005年プロファイル
開発成果

ステージ3

2007年コネクタソンに向けた2006年プロファイル
候補

ステージ4

2008年コネクタソンに向けた2007年プロファイル
候補

ステージ5

2009+年コネクタソンに向けた2008+年プロファ
イル候補

セキュリティ

・表示のための情報検索 (RID)・患者IDの相互参照 (PIX)
・患者同期アプリケーション (PSA)

・施設内利用者認証 (EUA)
・統一時刻 (CT)・施設間ドキュメント共有 (XDS)
・患者情報の問合せ (PDQ)

・監査証跡とノード認証 (ATNA)
・職員登録簿 (PWP)

・ドキュメント入手可能通知 (NAV)
・患者情報管理 (PAM)

・施設間利用者認証 (XUA)・ドキュメント電子署名 (DSG)– 2005年11月に決定
・テンプレート・レジストリ
・患者情報の問合せ - 複数施設
・連合XDSレジストリ
・XDSとRIDのドキュメント検索能力整合– 2005年11月に決定
・RBAC (Role Based Access Control) – 施設
内適用
IHE PCC (患者ケア連携）分野関連
・患者同意

共通データ

– 2005年11月に決定
・LDAP 情報源の拡張
・処理誤りの管理 (TFM)
・RID 構成調整情報のディレクトリ
・サービス発掘
他のIHE分野ニーズに依存する項目
・マスターファイルのメンテナンス
・参照コードセットのメンテナンス

IHE PCC (患者ケア連携）分野関連
・診療計画作成 – 施設内適用
・EHRの動的データ

・診療計画作成 - 複数施設適用
・国家／地域EHRの指令書および計画への対応（今後決定）・RBAC – 複数施設適用
・広域患者アクセス・モバイルアプリケーション
・患者を個別識別したセキュリティ

・ワークフロー管理の選好性
・SNMP MIBS (Simple Network
Management Protocol, Management
Informations Bases)
・LDAP機器ディレクトリのサポート

・複数診療領域の要素からなるXDS複合ドキュ
メント・遠隔サービスアクセス・匿名化（anonymization）
・仮名化（pseudoanonymization）
・患者主導のアクセス

・機器の自動認識と自動装備
・自動構成可能なRIDとXDS☆ 2005年
2005年6月時点の計画

116

IHE IT Infrastructure
開発、実装状況
オープンソース¾ IHE XDSのオープンソース公開中。他の統合プロファイルも予定• NIST（米国国立標準技術局）とSourceForge.net（オープンソース開発のサイト）から公開• JavaとJSP（Java Server Pages）で記述• 関連ＵＲＬ：– http://hcxw2k1.nist.gov/wiki/index.php/IheOs、
http://sourceforge.net/projects/iheos/¾ NISTはXDSのテスト仕様／ツールも公開• 関連ＵＲＬ：– http://hcxw2k1.nist.gov/wiki/index.php/XDS_-_CrossEnterprise_Document_Sharing

テスト実装¾ HIMSS（米国医療情報管理システム協会）展示会（毎年2月開催）¾ Eclipse（米国ソフトウェアベンダによるオープンソース団体）のOHF（Open

Healthcare Framework）プロジェクト•

関連ＵＲＬ：– http://hssp.wikispaces.com/、http://www.eclipse.org/ohf/

117

ご清聴
ありがとうございました

118