電子カルテへの対応
IHEーＩＴインフラストラクチャを使用すると
５/14/2005 IHE-J in 金沢
細羽 実
IHE-J 運営委員会
京都医療技術短期大学

電子カルテとEHR,EMR• EHR：Electronic Health Record– 患者の健康時の記録も含む電子的な保健診療記
録の集積• EMR：Electronic Medical Record– 患者の受診時の診療記録の集積• 電子カルテ：医療情報学会やJAHISなどからいくつかの定義が出ている– カルテという言葉からの印象が強い。カルテの電子化
21

IHE: ドメインベースの段階的アプローチ
患者管理
オーダ管理

患者IDのリンク、 登録簿、セキュリティ
患者IDのリンク、

Electronic Health Record
その他 (例：アクセス制御、 eHealthワークフロー
eHealthワークフロー)

放射線部門

臨床検査

薬局、…
薬局、…

循環器部門

3

EHRの構築を支援するIHE
IHE-EHR 長期記録
IHE

医療施設間ITインフラストラクチャ
医療施設内

IHE

IHE

9 Integration Profiles

放射線部門

循環器部門
3 Integration Profiles

14 Integration Profiles

IHE

IHE

将来追加される部門

臨床検査部門IHE
5 Integration Profiles

将来追加される部門

42

テクニカルフレームワーク（2004-2005）
Radiology Technical Framework

Radiology Technical Framework (Supplement)

Rev 5.5 2003/11/20
Final Text Version

vol. 1:
vol. 2:
vol. 3:
vol. 4:

2004-2005
Trial Implementation

統合プロファイル
トランザクション
トランザクション（続き）
各国の拡張

Laboratory Technical Framework
Revision 0.9
October 15, 2003 Draft for Public Comment

vol. 1 (LTF-1): 統合プロファイル
vol. 2 (LTF-2): トランザクション

IT Infrastructure TechnicalFramework

IT Infrastructure TechnicalFramework(Supplement)

Revision 1.0 Final Text VersionAugust 5, 2003

vol. 1 (ITI TF-1): 統合プロファイル
vol. 2 (ITI TF-2): トランザクション

2004-2005
Draft for Trial Implementation

Cardiology Technical Framework
Year1:2004-2005
Revision 1.0

Vol.1
Vol.2

Trial implementation

統合プロファイル
トランザクション

5

IHE IT インフラストラクチャ
統合プロファイル 2004-2005
施設間
ドキュメント共有（XDS）
XDS）
施設間にわたる
診療ドキュメントの登録、配布、アクセス表示のための情報検索
（RID）
RID）
依頼ユーザに直ちに提示できるようなフォーマットの患者の臨床情報とドキュメントにアクセス

監査証跡とノード認証（ATNA）
ノード認証（ATNA）
MPIのためのMPIのための患者ID
相互参照
患者ID相互参照（PIX）
PIX）
患者IDを異なるIDドメ
イン間でマッピング

セキュアなドメインを形成するための監査証跡とノード間認証

時刻の整合性（CT）CT）

ネットワーク接続されたシステムにおける時刻の整合医療機関職員の登録簿
（PWP）
PWP）
職員情報へのアクセス

患者情報の問い合わせ（PDQ）
問い合わせ（PDQ）
患者同期
アプリケーション（PSA）
アプリケーション（PSA）
一患者に対する複数アプリ
ケーションのデスクトップ上での同期

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

IHE IT インフラストラクチャ
情報共有関連施設間
ドキュメント共有（XDS）
XDS）
施設間にわたる診療ドキュメントの登録、配布、アクセス表示のための情報検索
（RID）
RID）
依頼ユーザに直ちに提示できるようなフォーマットの患者の臨床情報とドキュメントにアクセス

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

MPIのためのMPIのための患者ID
相互参照
患者ID相互参照（PIX）
PIX）
患者IDを異なるIDドメ
イン間でマッピング
7

IHE IT インフラストラクチャ
セキュリティ関連
医療機関職員の登録簿
（PWP）
PWP）
職員情報へのアクセス

監査証跡とノード認証（ATNA）
ノード認証（ATNA）
セキュアなドメインを形成するための監査証跡とノード間認証

時刻の整合性（CT）CT）

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

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

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

表示のための情報検索(RID)
Clinical Document
Architecture
ＨＬ７ (XML)• 患者情報への簡単で迅速なアクセス• よく使われる表示フォーマット（CDA、PDF、JPEGなど）により保存されたドキュメントへのアクセス• 医師へ提示するためのキーとなる患者中心の情報（アレルギー情報、現在の服薬情報、レポートのサマリなど）へのアクセス
9表示のための情報検索(RID)• ユーザの利便性– 医療提供者は情報を「見る」ことができる。重要な統合のステップ。
– ユーザのスクリーン上のワークプレースやアプリケーションからのワークフロー。
パソコンのディスクトップから– 患者同期アプリケーション（PSA)に対して複数かつ同時のアプリケーションワークフローを補完する。

• 医療機関にわたる広範な情報へのアクセス：– クライアントに対してWeb技術を適用– 臨床データを保有する情報源（部門、機関）では当然と考えられる臨床データの操作が他の部門、機関で可能！
105

表示のための情報検索(RID)
トランザクション図
表示アクタ

表示のために特定の情報を検索 [11]（たとえば、特定の患者に関する情報）情報源

表示のためにドキュメントを検索（一意的に定まるドキュメントの検索）
全てのレポートのサマリ
臨床検査レポートのサマリ
画像検査レポートのサマリ
循環器レポートのサマリ
手術レポートのサマリ
集中治療レポートのサマリ
救急レポートのサマリ
退院レポートのサマリ
アレルギーリスト
処方リスト
保存ドキュメント

依頼のタイプ11

問い合わせキー – トランザクション
表示のために特定の情報を検索
パラメータ名

必要性

記述

RequestTypeR

Patient ID

R

依頼のタイプは、どのようなタイプの情報が検索されるべきかを指定。このパラメータは常に値をもっていなければならない。
この属性は問い合わせされる結果の主題を識別する。その値は認証局によるＩＤを持つ。

lowerDate
TimeO

情報生成の最も前の日時の条件を示すために使用。

upperDate
TimeO

情報生成の最も最近の日時の条件を示すために使用。

MostRecent

R

応答に含まれる最も直近の結果の数を指定するための数値。すなわち、１は最も最近の結果を提供することを意味する。

Results126

問い合わせキー – トランザクション
表示のためのドキュメントの検索
パラメータ名

必要性

記述

RequestTypeR

このパラメータは、“DOCUMENT”なる値を持つことが要求される。

Document
UID

R

両アクタの双方に既知のドキュメントのＵＩＤ。

PreferredContent
TypeR

このパラメータは、提供されるべきドキュメントのフォーマットを指定するために必須。 (たとえば MIME content type).

13

患者ID相互参照機能(PIX)• 院内の医療従事者が、それぞれの領域（のシステム）で患者のために利用するIDを登録することを可能とする• 患者の診療サービスの目的のために、システムに他のシステムのIDを問い合わせることをサポートする• オプションで、他のシステムが患者のIDを更新した場合にそのシステムへ通知を行うことも可能
147

患者ID相互参照機能(PIX)• ある患者の全てのシステム内のIDを保守• 別々にIDを発行された各領域にわたり、患者のマッチングを行う任意のアルゴリズムを利用することは可能• システムにまたがり、データの同期・共有を図るためのより低コストで得られる機能• 既存システムにIDとフォーマットの変更を求めない
15

患者ID相互参照機能(PIX)
ID ドメインとトランザクション

IDの付け方が異なる

患者ID
ドメインA

患者の同一性の提供と患者の同一性の参照

患者

患者同一性
提供

患者同一性
患者同一性
相互参照
提供者
内部ドメイ
ントランザ
クション

他 の IHE
アクタ

患者ID
相互参照領域患者の同一性
相互参照
マネジャ

患者ID
ドメインA

患者同一性
利用者
患者ID
ドメインB

同一性
提供

患者の同一性の提供と患者の同一性の参照

患者の同一性
患者同一性
相互参照
マネジャ
提供者

内部ドメイ
ントランザ
クション他の IHE
アクタ

患者同一性相互参照
患者同一性利用者
患者ID
ドメイン C
168

患者ID相互参照機能(PIX)
患者同一性相互参照
マネジャ

患者ID
相互参照
-ドメイン

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

Id=123
Id=235
患者
ID
ドメイン A

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

Id=3TY
Id=2RT

B:X456
C: ?

B:X456
C: 2RT

患者同一性相互参照

患者ID
ドメイン C

患者同一性
利用者

17

患者ID相互参照機能(PIX)
キーとなる効果• マスタ患者IDを必要としない (法的制約を容易にする、分散的に対応可能)• PIXマネジャは統合した患者情報を生成する必要がない（患者情報そのものは各ドメインで管理）• どの患者IDドメインもマスタ患者IDを生成しているとみなすことができる• 患者情報はADTアクタの責任範疇に入る。患者登録が分散化（たとえば、RadとLab)する場合は、患者情報問い合わせ統合プロファイル
189

EHRの施設間文書共有(XDS)
経時的見方が可能なEHRへの第一歩
フォーカス:
さまざまな診療場面、組織でのEHR間のドキュメント共有をサポート
19

一般的に、患者は様々な診療の状況で一連の診療を受けることになる
長期療養
急性期診療
(入院)
他の特定診療(検査診断を含む)

一般医、診療所(救急)診療の連続性確保：

患者の継続的記録

2010

診療シナリオ
clinicalaffinity
domainECGの過去のデー
タを参照、ECG検査を実施

地域病院
地域病院

55

診療所医師
診療所医師

臨床検査を受けて循環器の医師の所へ行くよう指示

111010

リハビリ
リハビリ
介護士
介護士

ECGの過去、現在のデータ、臨床検査結果を参照、超音波を実施

循環器
循環器検査
検査

循環器医師
循環器医師

3&9
3&9

臨床検査
臨床検査

22

救急治療室
救急治療室

核医学検査を受けるよう指示

病棟
病棟
検査室
検査室 カテラボ
カテラボ

77

ＥＲで
診断
カテラ
ボで
IVR

88

6&8
6&8
循環器治療
循環器治療

フォルダ
フォルダ

44
放射線検査
放射線検査

投稿
投稿
セット
セット
XDS
XDS
文書
文書
21

核医学スト
レス検査

発行されてる記録を共有する
コミュニティ
コミュニティ
clinicalaffinity
domain検査センタの結果

専門医の記録

病院の記録

記録を参照
４−医師に患者のデータが提示

臨床
IT
システム
暫定的に集められた患者の受診歴受診３−記録が返却

共有システム
１−患者の承認を得た照会

患者の記録の目録(報告書レベル)２−照会のために記録を参照 22

11

ドキュメントの構築とアクセス
EHR-LR:

文書の登記簿

長期記録
診療の度に参照
される記録としてDocument
Registry

長期診療ドキュメント
保管庫

急性期診療(入院)

初期治療、診療(救急)他の専門的診療または診断サービス

EHR-CR: 診療記録 診療をサポートするシステム
参照文書の投稿
選択文書の検索23

施設間ドキュメント共有(XDS)
保健医療分野のITインフラの基礎: コミュニティ、地域内な
clinical affinity domain
どで電子的な診療録を共有
保健医療機関間の臨床文書へのアクセスや寄与の有効な手段
さまざまな臨床ITシステムを持つ、医師、診療所、療養施設、薬局、救急診療施設間で、文書の広域的共有化
簡便なアクセス： 診療提供者は関心のある臨床文書を問い合わせ、検索する手段を提供される

24

12

施設間ドキュメント共有(XDS)
分散化： それぞれの診療体は他の組織体に対して臨床情報を「発行」する。実際の文書は元々のEHR-CRに残っている。
clinical affinity domain

施設間： “登記簿”が、発行された情報の目録を承認された組織体に対して提供する。それぞれの組織体は同一の臨床的関連のあるドメイン（たとえば、LHII）に属している。（LHII：
Local Health Information Infrastructure）

文書中心： 発行された臨床データは「臨床文書」として組織化。それらは合意された標準的な文書タイプを用いている。
（たとえば、HL7-CDA、ASTM-CCR、PDF、DICOM、その他）
Continuity of Care Record

文書の内容には中立： 文書内容は発行元と利用側のITシステ
ムによってのみ処理される。
標準化された登録属性： 重要な属性をベースとした問い合わせによって確定的な探索を保証する。
25

XDS ： キーとなる概念• XDS文書• XDS投稿セット(Submission Set)
• XDSフォルダ
2613

XDS： キーとなる概念
XDS文書：確認された臨床情報の集合（構造化されている場合、されてない場合がある）、共有される患者記録の最小単位。
それは既に発行源となるITシステム（施設ごと）に存在している。

XDS投稿セット(Submission Set)：同じ発行源における医師（のチーム）が、関連する協力者に対して利用させると決定した、患者に関するXDS文書の集合

XDSフォルダ：目的ごとに文書をグループ化する手段：• 複数の医師の間でチーム作業を行う、• １回の受診に関連する診療、• 患者の救急情報、その他XDSは協力関係にあるドメインの医師に対してオープンにされる。
clinical affinity domain
27

EHRの施設間での文書共有に対して、IHEは何を提供するか• 実用的なシナリオのセット： 文書の投稿、投稿セット、フォルダ、臨床的関連のドメインなどがユースケースシナリオから導かれている。例：循環器疾患に関する診療ネットワーク• 関連するアクターの定義： XDSは、関連するITシステムによって実装される５つのアクタによって定義される。
• 関連するトランザクションのまとまった仕様： XDSは複数の標準に基づくメッセージの交換を明確にする５トランザクションを含む。 XDSは、最も適切に標準を利用（HL7、ebXML、W3C、など）。
多くの実装シナリオが討議された。
28

14

統合モデル１：

発行元に保管庫があるEHR-CR
患者の診療フェーズが以下のような状況で完了する場合のEHR-CR：¾ 保管庫（Repository）アクタとしてこれらの文書を持っている。
¾ 登録簿（Registry）アクタで文書を登録する。
他のさまざまなEHR-CRは登録簿アクタに問い合わせ、これらの内のいくつかの文書を保管庫アクタから検索して選択する。

EHR CREHR CR
Ｄｏｃｕｍｅｎｔ
発行源Register
2

文書
登記簿

3 Query
Document
利用者

Document
保管庫

4 Retrieve
29

統合モデル２：

第三者の保管庫によるEHR-CR
患者の診療フーズが以下のような状況で完了する場合のEHR-CR：¾ 保管庫アクタを選択して文書を提供する。
¾ 文書は、登録簿アクタで登録される。
他のさまざまなEHR-CRは、登録簿アクタに問い合わせ。また、任意の保管庫アクタからこれらの文書のいくつかを検索し選択する。
EHR CREHR CR
Document
Source文書
登記簿

3 Query

Register
2 Document 4 Retrieve

Document
利用者

保管庫3015

統合モデル 3:

EHR-CRがEHR-CR/EHR-LRハブにEHR-CRは、以下のような状況で患者の診療を完結している：¾ EHR-CRの文書保管庫で文書セットを登録する。
EHR-CRの利用者アクタは文書を持っていて、問い合わせに対して応答し、他の文書利用者に文書を提供する。

EHR CREHR CR
Provide&Register
Ｄｏｃｕｍｅｎｔ
発行源

Document
利用者
文書
登記簿

Document
保管庫
31

患者情報の問い合わせ(PDQ)• 共通の患者名、識別子、関係、および来院情報を含む患者リストの迅速な検索を可能とする。
• 完全な識別データを得ることができないとき、正しい患者の選択を可能とする。
• 患者情報と来院情報の部分的なものだけに制限する。
32

16

患者情報の問い合わせ(PDQ)
トランザクション
患者情報
提供者
患者情報
問い合わせ

オンデマンドに登録システムに接続している部門システム

患者情報と来院情報の問い合わせ

患者情報
利用者

ベッドサイドモニタ、医師のオフィスシステム、検体検査、移動血液銀行登録、などを含むコンタクトポイ
ントにある様々なシステム
33

施設内ユーザ認証(EUA)• 単一の施設は、単一のセキュリティポリシのセットで管理され、共通のネットワークドメインを持つようサポートする• 診療施設の全ての機器やソフトウェアで有効な一ユーザ一氏名を保証• 集中化されたユーザ認証管理を提供• ユーザにシングルサインオン機能を提供
34

17

施設内ユーザ認証(EUA)
Kerberos認証
Request TGT（Ticket
Granting ticket)

初期ユーザ名,パスワード“kinit”
Kerberos サーバ

Response(contains TGT)TGTCache

サービスチケッ
トを要求

TGT

サービスチケッ
トを返す

アプリケーション

認証者としてサー
ビスチケットを利用してプロトコル
特定通信

シングルシステム環境

アプリケーションサーバ

35

IHE IT 統合プロファイル間の相乗効果
EUA/CT & PIXとのRID

マルチアクタ／プロファ
イルをサポートした例①

ディスプレイ④

クライアント
認証エージェ
ント②

時間クライアン
ト

患者同一性相互参照マネジャ
⑧

情報源

⑦

患者同一性
利用者

⑥

⑤

③時間
サーバ

Kerberos
認証
サーバ
36

18

患者同期アプリケーション(PSA)• 複数の様々なアプリケーションについて患者同期を取る• 単一の患者を選定• 患者ID相互参照プロファイルとともに利用されたとき、患者を指定して情報を利用する部
門間の同期が得られる。

37

IHE アクタの概念
ＨＬ７
ＣＣＯＷ
Clinical Context
Object Working
Group

患者コンテクスト参加アクタ（アプリケーション）

コンテク
スト管理
アクタ

38

19

患者同期アプリケーション(PSA)
トランザクション図
コンテクストへの参加 [5]患者コンテク
患者コンテク →スト参加
スト参加
コンテクストの変更
[6] →
アクタ
アクタ

コンテクスト
コンテクスト
管理
管理
アクタ
アクタ

← コンテクストへ
追随 [13]
コンテクストから離脱 [7] →39

患者コンテクスト
参加アクタ

患者コンテクスト
管理アクタ

患者コンテクスト
参加アクタ２

コンテクスト
参加

患者選択Ａ患者が変わる Ｂ
アプリケー
ション終了

コンテクスト変更

コンテクスト追随

コンテクスト
参加
コンテクスト
追随

患者が変わる Ａ

コンテクスト追随

患者変更
Ｂ

コンテクスト
離脱

アプリケー
ション終了

コンテクスト離脱

4020

患者同期アプリケーション(PSA)• ユーザの利便性：– 各アプリケーションで患者を選択するという繰り返しの作業が必要なくなる– 診療のワークフローにおいて、最も適切に、最もなじむように、操作をサポート• 患者安全：– 同一の患者に対してアプリケーションにわたる全てのデータの参照を保証

41

監査証跡とノード認証（ATNA）• 患者の個人情報保護とシステムセキュリティ– 倫理的、あるいは法的規制に対応• 医療機関内での便宜– 統一的で、一様な監査システム– 複数のベンダからの共通のアプローチは医療機関ポリシーとプロトコルの定義を簡素化する。
– 共通のアプローチは管理を簡素化。

• コードの再利用による開発サポートコスト低減– ベンダは複数のアクタのサポートに一度の開発努力でよい。
– 異なった（病院の）セキュリティポリシーと規制環境の要求をサポートするため一度の開発努力でよい。
4221

監査証跡とノード認証（ATNA）
概要• Secure Node(安全なノード)の特徴を設定する。
• ノードに対して想定されるセキュリティ環境(ユーザID、認証、許可、アクセス制御など)を記述する。
• TLSまたは同等の機能を用いるノードの通信に対する基本的なセキュリティ要件を定義する。
• ノードに対する基本的な監査要件を定義する。
• Secure Nodeと、監査情報を収集するAudit
Repository (監査リポジトリ)ノードの間の監査メッセージの通信に関する特性も設定する。
43

監査証跡とノード認証（ATNA）
目的１• ユーザのアカウンタビリティ(監査証跡)– セキュリティ担当者が、活動を監査、セキュアドメインのポリシーに対する準拠を評価、準拠しない動作のインスタンスを検出して、Protected Health Information （PHI）の不正な作成、参照、変更、削除の検出を容易にする。
– PHIは、患者の識別が可能な情報記録(登録、オーダー、検査/手続き、レポート、イメージ、プレゼンテーション状態など) 。ユーザがアクセスしたり、システム間で交換したりできる。セキュアドメイン内のすべてのセキュアノードとの間でエクスポートおよびインポートされる情報が含まれる。
– 監査証跡（トレール）には、次の質問に答えられる情報が含まれる。
• あるユーザについて、どの患者のPHIにアクセスしたか。
• ある患者のPHIについて、どのユーザがアクセスしたか。
• どのようなユーザ認証の失敗が報告されたか。
• どのようなノード認証の失敗が報告されたか。

4422

監査証跡とノード認証（ATNA）
目的２• アクセス制御• ノード間のネットワークアクセスを制限、各ノードに対するアクセスを許可されたユーザだけに制限する。
• セキュアドメイン内のセキュアノード間のネットワーク通信は、そのドメイン内の他のセキュアノードのみに制限される。
• セキュアノードは、ローカル認証およびアクセス制御ポリシーによる指定に従って、許可されたユーザだけにアクセスを制限する。
45

監査証跡とノード認証（ATNA）
目的３• 集中的監査レコードリポジトリ• センタ監査レコードリポジトリを提供する。
• 可能であれば、すべてのIHEアクターから監査レコードリポジトリへの監査レコードの即時転送。
• 不正操作の危険性が減少し、部門の監査が容易• PHIデータの整合性• PHI情報の生成から消滅までを追跡し(作成、変更、削除と位置)、このプロセスの間のデータの整合性を維持する。
4623

セキュアドメイン:信頼のあるノードの統合
他のアクタ
OtherActors
セキュアノード
アクタ

他のアクタ
OtherActors
セキュアノード
アクタ

センター
監査証跡
リポジトリ

他のアクタ
Other Actors

他のアクタ
Other Actors
セキュアノード
アクタ

タイム
サーバ

セキュアノード
アクタ

47

IHE 監査証跡イベント
IETF とDICOM のイベントリスト
アクタやアプリケーションの開始と終Actor-start-stop
了

Audit-log-used

保存された監査ログの読み出しや編集

Begin-storinginstances
Health-service-event

DICOMインスタンスなどのオブジェクトのImages-availabilityquery
Instances-deleted

オブジェクトのインスタンスへの問い合わ
せInstances-stored

オブジェクトの保存完了

保存開始他の保健医療サービス関連の監査イベ
ント

オブジェクトの削除

48

24

時刻維持のためのトランザクション• 時刻同期アクタのためのネットワークTime
プロトコル(NTP)バージョン3(RFC1305)• アクタは、手動の場合もサポート• 要求精度を１秒程度に• オプショナルにSecure NTPの使用も可

49

医療機関職員の登録簿(PWP)• 職員、作業者の基本情報へのアクセス手段の提供– 患者は含まない• ＰＷＰを見つける方法を定義• 問い合わせとアクセス方法を定義• 関心のある属性の定義
50

25

医療機関職員の登録簿(PWP)• ただ一つの正式の知識ベース– 二重のデータベースやコネクションのないユー
ザのデータベースをなくす– 唯一の更新箇所とする• 名前の変更• 新しい電話番号• 追加のアドレス• ワークフローと通信の機能を高める– コネクションするために必要な情報を提供• 電話番号• メールアドレス• 住所51

PWP トランザクション
保健医療機関職員の情報に標準的にアクセスする方法を提供する
ＰＷＰを見つける

DNS
ServerＰＷＰ利用者
医療機関職員の登録情報の問い合
わせＰＷＰ
台帳
5226

PWPが含むもの• ログインID

johnmk, q1234
moehrkj@krb.local• Last Name,• Display Name,Moehrke
John F. Moehrke• その他のユニークID (e.g. professional).

53

セキュリティ関連ITIの利用• 医療情報の安全な管理– 操作者認証– 職員情報の管理– 時刻の維持• 保存義務のある医療情報の電子保存– 真正性の確保• 標準セキュア基盤として利用可能！
54

27

IHE と HIPAA セキュリティ• User Identity Æ PWP, EUA• User Authentication Æ EUA• Node Authentication Æ ATNA
• Security Audit Trails Æ ATNA
• Data Integrity Controls Æ CT, ATNA TLSoption• Data Confidentiality Æ ATNA TLS option• Access Controls Æ Future item in IHE roadmap
55

情報共有関連ITIの利用• 病院内：異なるシステム間（部門間）での患者情報、文書の共有• 施設間での文書共有：地域医療連携など
への応用→電子カルテの施設間共有へ発展

5628

二つのタイプの統合 :EHR-CR: 診療に際して利用される健康管理記録
EHR-LR: 施設間で利用されるものとしての健康管理記録
EHR-LR

EHR-LR

EHR-LR

読込

読込

生成
更新

EHR-CR
情報の識別と選択診療に対する要求へのアクセスの意志決定

オーダ
行為

アクション

診療目的の プラン
定義の定義

診療の終了

診療提供のプロセス
EHRソリューション=
EHR-LR (長期記録：Longitudinal Record) + EHR-CR (診療記録：Care Delivery Record)

XDS

5729