IHE 臨床検査テクニカルフレームワーク - IHE-J

IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
GMSIH, HL7 France H’, HL7 Germany, IHE-J, JAHIS, SFIL, IHE Italy
Integrating the Healthcare Enterprise
IHE 臨床検査
テクニカルフレームワーク
サプリメント 2005-2006
臨床検査情報の整合性確保
Laboratory Information Reconciliation
(LIR)
2005 年 10 月 10 日
トライアル・インプリメンテーション用ドラフト版
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
1/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
はじめに（Foreword）
インテグレーティングヘルスケアエンタープライズ（IHE, Integrating the Healthcare Enterprise）は、現代
の医療機関を支える情報システムの統合を促進するための取り組みである。その基本的な目標は、患者の治
療において、診断に必要な全ての情報が、医療関係者に対し、正確かつ有効であることである。 IHE 活動は
統合を促進するためのプロセスおよび討議の場である。具体的な臨床的目標を達成するため、確立されたメッ
セージ規格を実装するための技術的枠組み(framework)を定義する。この枠組みを実施するための厳格なテ
ストプロセスを含み、教育セッションを開催し、この枠組みの利点を提示し業界およびユーザーによる導入を奨
励するために医療専門家の主要ミーティングにて公開する。
IHE 活動に使用されているアプローチは新しい統合標準を定義することなく、必要に応じて構成の選択肢を明
確にしながら、統合された形のなかで既存の標準（HL7、DICOM、IETF）の使用をサポートすることである。
既存の標準の明確化あるいは拡張が必要な場合は、IHE は関連する標準化団体（HL7、DICOM）に意見を
照会する。
様々な医療専門分野や地域からのスポンサー及び協力団体により先導されている。北米における主要ス
ポンサーは、以下の団体である。
・American College of Cardiology (ACC)
・The Healthcare Information and Management Systems Society (HIMSS)
・The Radiological Society of North America (RSNA)
IHE Canadaの活動も開催された。
IHE Europe(IHE-EUR)は、協力団体の連合により援助されている。連合に含まれる団体は以下に記す。
・the European Association of Radiology (EAR)
・European Congress of Radiologists (ECR)
・the Coordination Committee of the Radiological and Electromedical Industries (COCIR)
・Deutsche Röntgengesellschaft (DRG)
・the EuroPACS Association, Groupement pour la Modernisation du Système d'Information Hospitalier (GMSIH)
・Société Francaise de Radiologie (SFR)
・Società Italiana di Radiologia Medica (SIRM)
・the European Institute for health Records (EuroRec)
・the European Society of Cardiology (ESC)
日本におけるIHE-Jスポンサーは、以下の団体である。
・経済産業省
・厚生労働省
・MEDIS-DC
協力団体は以下の団体である。
・日本画像医療システム工業会(JIRA)
・保健医療福祉情報システム工業会(JAHIS)
・日本医学放射線学会(JRS)
・日本放射線技術学会(JSRT)
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
2/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
・日本医療情報学会(JAMI)
他の医療専門の団体も学問、地域を越えたIHE活動の発展に参加することを期待されている。
各部門のIHEテクニカルフレームワーク（ITインフラ、循環器、臨床検査、放射線など）では、的確な
医療情報共有による最善な患者の治療をサポートするため、確立した規格固有の手法を定義している。
本書は公開レビュー期間の後、正誤表の確認と修正を通じて定期的に見直され、毎年更新される。これらの
テクニカルフレームワークの最新版は、www.rsna.org/IHE および http://www.himss.org/IHEから入手可能で
ある。
IHEテクニカルフレームワークは、医療規格の機能構成集合であるアクターを選定し、構成要素の相互
作用をトランザクションで特定する。本書は、トランザクションを段階的に掘り下げて説明を行う。第
一部はIHEでの主要な機能性を紹介し、トランザクションが構成されている統合プロファイルと呼ばれ
る機能要素を紹介する。統合プロファイルとは、特定の医療ニーズに取り組むことに焦点をあてている
機能要素である。次の章からは、それぞれのトランザクションについての詳細な技術的解説を行ってい
る。
Document production
Principal editor:
Last update:
Nicola Ferrari – Omnilab
June 15, 2005
概論
臨床検査情報の整合性確保(LIR)は、新規の統合プロファイルであり、2005年のIHE臨床検査テクニカル
フレームワーク第1部に加えられた。LIRではすでにLSWF及びLDAで作成され説明されているトランザ
クションのみを使用し、このプロファイルに関連する新規トランザクションはない。したがって、新規
に説明及び章をIHE臨床検査テクニカルフレームワークの2章に付加する必要はない。
未解決問題及び質問事項
患者情報が医療システム上になく、オーダーがOPにより直接入ることで、OPがADTトランザクシ
ョンを開始する。しかし、多くの手法ではこの情報はADTアクターによるものであり、下位のシス
テムがADT患者基本情報の更新を開始することは推奨されていない。
OFはどのようにしてOMLメッセージを通して患者情報詳細を更新するのか。AMはどのように患者
情報の更新であると認識するのか。
解決済み問題点
ケース３：AMによって作成された検査オーダーに関しては、患者情報が存在しないために技術的
検証が実施されない場合、LAB5を行うことができない。この問題は、技術的及び臨床的検証を行
うOFに結果を送信することで解決する。
プロファイル概要
臨床検査情報の整合性確保プロファイルは、臨床検査においてスタッフが一般的に扱う毎日の特殊事例
を管理目的とするLSWFを拡張することを目的とする。例えば、外傷事例や匿名/誤認患者の分析及び未
確定のテスト結果である。
このプロファイルは、正規の患者情報と、匿名/誤認患者から採取した検体の臨床検査記録の整合性確保
を目的としている。典型的な外傷事例において、患者に関する確実な詳細が入手不可能であり、仮の一
般情報がADTに入力された場合に起こりえる。
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
3/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
このプロファイルは、主要なアクター（ADT、OF、OP）から正規/仮患者情報を取得できず、検査科の
要求が行えない緊急な検査分析にも対応する。
このプロファイルで示す検体から入手された未確定の臨床検査記録と、後に作成されたオーダーは、AM
もしくはオーダー実施者アプリケーションで整合され、オーダー依頼者やオーダーリザルトトラッカで
共有される。
最後に、この統合プロファイルは仮登録や一般登録されていない患者に対し、身元が確認される前の検
査結果及び患者情報の整合性をサポートするために設計された。それにより検査記録が作成され、検証
され、即時使用でき、患者の本登録とオーダー情報が臨床検査の主要アクターに送信された時、その身
元情報は以前に入手された結果と整合される。
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
4/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
解説
LDA: Laboratory Device Automation profile
（検査機器オートメーションプロファイル）
LIR: Laboratory Information Reconciliation profile
(臨床検査情報の整合性確保プロファイル)
LIS: Laboratory Information System
(臨床検査情報システム)
LSWF: Laboratory Scheduled Work Flow profile
（臨床検査スケジュール済みワークフロープロファイル）
ADT: Admit, Discharge, Transfer
（入院、退院、転院）
OP: Order Placer
（オーダー依頼者）
OF: Order Filler
（オーダー実施者）
AM: Automation Manager
（オートメーションマネージャ）
ORT: Order Result Tracker
（オーダーリザルトトラッカ）
LD: Laboratory Device
（検査機器）
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
5/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
第1部―統合プロファイル
<このセクションは、この統合プロファイルを含めた結果によりおこるテクニカルフレームワーク第1
部の変更について説明する。>
セクション１−１．Xでの変更点
<変更される各章/小章に対する章を含む>
1.6 年鑑例年変更履歴
次の項目をセクション1.7にあるリストの最後に追記する
スケジュール化されていないワークフローを考慮するためにLSWF及びLDAを拡張した臨床検査情
報の整合性確保プロファイルを追加した。誤認又は未確認患者が検査分析を行うことができ、緊急
の場合オーダー発行されていない分析を行うことができる。
2.1 範囲
次の内容を段落末尾のいずれかに追記する：
LIRプロファイルは、患者が病院情報システムで正確に登録されない又は患者情報が入手不可能であり
検査分析に必要なオーダーが発行できないような、予測はできないが典型的な状況に対応する。このプ
ロファイルは、LSWFでは管理できない事例の大多数に対応するが、それはLIRがスケジュール化されて
いないワークフローと位置づけられているからである。
2.3 統合プロファイル概要
次の文を既存の表に追記する：
統合プロファイル
依存
Laboratory Information
Reconciliation
Laboratory Scheduled
Workflow
（臨床検査情報の整
合性確保）
（臨床検査スケジュール済み
ワークフロー）
Laboratory Device Automation
（検査機器オートメーショ
ン）
コメント
臨床検査情報の整合性確保は、プロセスを全て
サポートする為にLSWプロファイルを拡張し
たものである。
検査情報の整合性確保は、LDAの全てのトラン
ザクションに依存する。
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
6/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
2.4 臨床検査テクニカルフレームワークにおけるアクター
このプロファイルでは、新規アクターの追加は行わないが、いくつかのアクターに対して追記
する必要がある。
AMに対し、次の文を追記する。
オートメーションマネージャは、妥当な検査オーダーと、分析機器により得られた予測し得なかった結
果との適合、もしくは、不確かな検査記録を当てはめOFに送信する為の新規検査オーダー作成が可能で
ある。
OFに対し次の文を追記する。
実施者オーダーを作成するため、OFは新規患者のローカルID(検査室におけるID)を作成することが緊急
分析の場合のみ可能である。このローカル患者IDは、検査部門内に限定され、AMを伴うトランザクシ
ョンのみ可能とし、この患者の詳細情報がADTシステムに入力されADTにより配信されるまで、この患
者に関するトランザクションをOPやORTに対し行うべきではない。施設において定義されたIDとローカ
ルIDとの整合が取られる。
OFは、予め作成されたすべての実施者オーダーを照合するか若しくは、AMからの予測しえなかったオ
ーダー結果を管理し新規実施者オーダーを入力する。
X 臨床検査情報の整合性確保
X.1 ユースケース
X.1.1 未確認患者のADTにおける登録
このユースケースは、医療機関で誤認又は未確認患者の頻繁に起こりえる事例に対するシンプルで具体
的な解決策を与える。このユースケースはLSWF3.5.3章の拡張であり、最も重大な事例をサブケースと
して表す。
患者情報はオーダーの重要な要素であるため、このユースケースは依頼者オーダー及び実施者オーダー
に関わる2つのシナリオに対して影響を持つ。
- オーダー依頼者で発行される臨床検査テスト
- オーダー実施者で発行される臨床検査テスト
X.1.1.1 オーダー依頼者で発行される臨床検査テスト
シナリオの初期部分
a) オペレーター(許可されたスタッフ)が、誤認/匿名患者をADTで登録する。
b) 情報がオーダー依頼者, オーダー実施者, 及びオーダーリザルトトラッカに送信される。
シナリオの中間部分
c) オペレーター(病棟スタッフ)がオーダー依頼者にオーダーを入力する。
d) オーダーがオーダー実施者に送信され、その結果としてオートメーションマネージャや検査機
器などの他の受け取り側へ必要時に送信される。
シナリオの最終部分
e) オペレータ(許可されたスタッフ)が、ADTで患者情報を更新する。このプロセスの間、患者情報
として、
（パターン１）名前、住所その他の誤認情報を修正する必要がある。
⇒患者情報更新を行う。
（パターン２）すでに登録された患者として認識される。
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
7/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
⇒元の患者IDと対象患者IDのマージを行うか若しくはリンクを張る。
f) この情報は、オーダー依頼者, オーダー実施者やオーダーリザルトトラッカに送信される。検体
検査が終了していない場合や、最終結果がまだ返ってきてない場合は、AMはオーダー実施者を
通して患者の新規詳細情報を入手する。(LAB-4)
g) 受信側は、更新・マージ依頼を行うか若しくは、情報の統合をする必要がある。
注釈１：OFによって患者情報が更新またはマージが行われていた場合、LD(検査機器)はAMの内部規約
に従って、患者の新規詳細情報を転送される可能性がある。
X.1.1.2 オーダー実施者で発行された臨床検査テスト
このシナリオの初期部分及び最終部分は、前記ユースケースと同様であり、中間部分のみ拡張されてい
る。
シナリオの中間部分
c) オペレータ(臨床検査スタッフ)は、オーダー実施者でオーダーの入力を行う。
d) オーダー依頼者はオーダーを受信し依頼者オーダー番号を返信する。オーダーが作成されたこ
とをオートメーションマネージャに対し通知する。
注釈１：X.1.1.1の注釈１と同様である。
X.1.2 患者がADTで登録されていない。
このユースケースは、オーダー入力システムの病棟スタッフ又はユーザーが、患者未登録時に緊急検査
実施を行うため検査要求を行う状況を考慮する。患者ID及び詳細情報の入手が可能でないため、オーダ
ーは入力が行えない。
X.1.2.1 オーダー依頼者で発行された臨床検査テスト
IHE臨床検査委員会は、ADTで患者情報が常に作成され、ID、名前、誕生日などの患者基本情報が、違
う施設や複数の部門若しくは分離した医療体制の間で情報共有されるべきと仮定する。
したがって、OPは検査部門特有のアクターではなく複数部門のアクターなので、OPオペレータによる
新規ローカル患者が登録できない。この解釈は医療情報システム間においてADTに登録されていない患
者のID又は詳細情報が拡散するリスクを回避する為である。
この制限内で機能するために、病棟スタッフや検査スタッフはADTアプリケーションを使用して患者レ
コード作成を行い、この患者情報を使って新規検査オーダーを発行する必要がある。
X.1.2.2 オーダー実施者で発行された臨床検査テスト
このユースケースでは、新規ローカル患者レコード作成における制限事項はない。なぜならこのローカ
ルIDは検査アクターのみ使用可能と制限するからである。
ADTアクターから任意のタイミングで患者登録情報が送信されるが、ワークフローには影響しないワー
クフローでは一連の流れは。なぜなら、OFに結果が格納される若しくは臨床的検証を行っている間に、
新規の患者詳細情報と検査ID(ローカルID)の整合性確保が行われるからである。
この場合、患者詳細情報と実施者オーダーは、検査部門内で整合される。
シナリオの初期部分
a) 未登録患者の検体検査が行われる。
b) オーダー実施者にて、患者登録がローカルIDで行われる。
シナリオの中間部分
c) オペレーター(検査スタッフ)がOFに対し実施者オーダーを入力する。
d) AMへの検査オーダー送信。
e) AMは検査オーダーをいくつかのステップオーダーに分割し、分析機器や分析前/後処理装置など
の検査機器に送信する。
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
8/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
f) 分析機器によるAMへのテスト結果送信。
g) AMからOFへの結果送信。
シナリオの最終部分
h) 正確な患者詳細情報入手後、検査スタッフやLISなどの専門システムにより実施者オーダーが正
確な患者情報と整合される。この手順は臨床的検証（Step i）前もしくは同時に行われる。
i) 臨床的検証を行う。
j) 実施者オーダー管理トランザクション(LAB-2)の一環として、実施者オーダーがOPに送信される。
k) 実施者オーダー及び結果がORT（Order Result Tracker）に送信される(LAB-3)
注釈１：LAB-2(ステップ j)とLAB-3(ステップ k)トランザクションは、臨床的検証前に実施することも
可能であるが、患者とオーダーの整合前に実施されることはない。このユースケースは厳密な仮定によ
り定義されたものである。ADTでの患者登録実施前であり、ADTによる検査ID(ローカルID)の患者IDと
の整合前である場合、OP又はORTへのトランザクションは実施されない。
注釈２：ローカルID規定は、唯一の責任者である検査部門内で定義される。患者IDは複数の状態を持つ
ことができる検査ID (＝ローカルID)、正規ID （＝有効な）、その他検査権威者が決定したもの。
注釈３：患者の検査IDと正規IDが自動若しくは手動により整合された後、優先して送信する情報が検査
結果かオーダーかは、検査部門で決定する。
注釈４：ローカルと正規患者情報の整合性確保は、最終結果発行後に行われることを強く勧める。この
推奨は、検査室内のAMやLDといった技術的アクターに新規患者IDを提示する必要性を排除し、整合プ
ロセスが成功しなかった場合のLAB-4トランザクションを繰り返し行うことを回避する。
X.1.3 オーダー作成前に検査機器によって臨床検査試験が行われる。
緊急で行う検体検査の典型的な事例。検査システムがアクティブ状態でない場合に検査依頼がある可能
性があり、その場合プロセスは検査機器または、可能であればAMから開始する。
X.1.3.1 分析機器からの開始
シナリオの初期部分
a) 検体IDがスキャン又は手入力された検体を、分析機器に配置する。
b) 検査技師が検査項目を選択する。
シナリオの中間部分
c) 分析機器で結果が処理され、その結果がオートメーションマネージャに送信される。
d) AMはこれらの結果を「この結果は、検査オーダーと整合されていない」とフラグづけし格納す
る。
シナリオの最終部分：X.1.3.3章を参照。
X.1.3.2 オートメーションマネージャからの開始
シナリオの初期部分
a)
検査オーダーが手動で作成され、AMにて「未確定の検査オーダー」としてフラグづけされる。
b) WOS(Work Order Step)クエリー(LAB-22)が可能である、またはAMからのWOSダウンロード
(LAB-21)待ちである検査機器に検体が配置される。
シナリオの中間部分
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
9/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
c) 分析機器が結果を処理し、その結果がオートメーションマネージャに送信される。
d) 手動で作成された検査オーダーに対し、AMが結果を格納する。
シナリオの最終部分：X.1.3.3章を参照
注釈１：フラグづけという記述は、これらの検査オーダーのために特別に必ず記述をする必要があると
いう意味ではなく、システム規定に従っているのであれば、単純に依頼者オーダー番号を明記しないだ
けでもよい。最終目的は、未確定の検査オーダーが簡単に識別できることである。
X.1.3.3 シナリオの最終部分
一度AMが検査機器から結果を取得すると、最終的な課題は技術的検証を行い、臨床的検証のためにOF
に対し結果を送信することである。この最終ステップは、通常業務フローを基に2つの方法により実施
される。最初の方法は、事前にOF検査オーダーがない場合、AMはトランザクションを開始しない受動
的なアクターとする考えである。二つ目は、事前に検査オーダーが到達していない場合でも、AMはOF
に対し実施者オーダーの作成要請を行う能動的なアクターとする考えである。
オプション：
1) AMは検査オーダーが到着するのを待つ。
e) OFは実施者オーダーをスケジュールし、AMにとって適切な検査オーダーを作成する。
f) AMは検査オーダーを受信し、フラグづけされた格納済み結果又は検査オーダーと受信し
た検査オーダーとの整合をとる。
g)
AMは、オーダー結果をLSWFに記されているような通常運用で動作するOFに送信し、
OFからOPとORT両方に対し結果の伝達を行う。
注釈１：これは実施者オーダーがOP/OFのどちらから作成されたかを問題にしていない。OFは
両方の事例に対処するため、新規の検査オーダーを持つ。
2) AMは検査オーダーがない状態で結果を送信する。
e) AMはシナリオの初期部分に関連した技術的検証を行う。
- 未確定の検査オーダーは、通常通り技術的に検証される。
- 「検査オーダーと整合されていない結果」とフラグづけされている格納済み結果に適合さ
せるため、新規検査オーダーを作成する。この検査オーダーは検証され「未確定検査オーダ
ー」とフラグづけされる。
f) AMはOFに対してオーダー結果を送信する。この時点から、LSWFプロファイルに記載さ
れているプロセスに従う。
注釈１：このアプローチに対する結果として、AMからOFへのOULメッセージのOBR-2とORC-2
のフィールドはセットされなくなる。
注釈２：既存の実施者オーダーを事前にチェックすることで、入手した結果が既存のオーダー
と整合できるか確認できる。これは、不必要な実施者オーダーの作成を回避するために有効で
ある。
注釈３：患者情報がないために技術的検証が行えない場合でもAMは結果を送信する。そうす
ることで技術的・臨床的検証はOFで実施される。この場合、OULメッセージのPIDセグメント
は存在しない。
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
10/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
X.2 トランザクション/アクター
この統合プロファイルでは、アクター及びトランザクションの新規定義は行わず、図X.2-1で示すように
LSWFとLDAプロファイルの全てのアクターを使用する。
Figure X.2-1. LIR Actors and Transactions Diagram
LDAボックスに記述している分析前/後処理装置や分析機器は、１つの特有なアクターである検査機器に
集約されている。従って、LAB-23は分析機器として、LAB-26は分析前/後処理装置として明確に分けら
れるのに対し、LAB-21及びLAB-22は、分析機器又は分析前/後処理装置を表すLDアクターとして表現さ
れる。
だがこのプロファイルでは、LD（検査機器）は通常分析機器のことを表している。今回のような一般的
な表記では、分析前/後処理装置と相互作用を行うOFも考慮するほうがいい。
LSWFとLDAがサポートされている間のみこのプロファイルはサポートされるため、トランザクション
のオプションは、LSWFやLDAプロファイルと同様である。
テーブルX.2-1は、LDAプロファイルにおけるアクター毎のトランザクションをリスト化している。この
統合プロファイルをサポートするために、アクターの実装において必須であるトランザクションをRで
表記する。
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
11/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
Table X.2-1. LIR Integration Profile - Actors and Transactions
アクター
ADT
患者管理
Order Placer
オーダー依頼者
Order Result Tracker
オーダーリザルト
トラッカ
Order Filler
オーダー実施者
Automation Manager
オートメーション
マネージャ
トランザクション
選択性
参照文書
RAD-1 : Patient Registration
RAD-1 : 患者登録
R
Radiology TF sect 4.12
RAD-12 : Patient Update
RAD-12 : 患者更新
R
Radiology TF sect 4.12
RAD-1 : Patient Registration
RAD-1 : 患者登録
R
Radiology TF sect 4.12
RAD-12 : Patient Update
RAD-12 : 患者更新
R
Radiology TF sect 4.12
LAB-1 : Placer Order Management
LAB-1 : 依頼者オーダー管理
R
Laboratory TF sect 4
LAB-2 : Filler Order Management
LAB-2 : 実施者オーダー管理
R
Laboratory TF sect 5
RAD-1 : Patient Registration
RAD-1 : 患者登録
R
Radiology TF sect 4.12
RAD-12 : Patient Update
RAD-12 : 患者更新
R
Radiology TF sect 4.12
LAB-3 : Order Results Management?
LAB-3 : オーダー結果管理
R
Laboratory TF sect 6
RAD-1 : Patient Registration
RAD-1 : 患者登録
R
Radiology TF sect 4.12
RAD-12 : Patient Update
RAD-12 : 患者更新
R
Radiology TF sect 4.12
LAB-1 : Placer Order Management
LAB-1 : 依頼者オーダー管理
R
Laboratory TF sect 4
LAB-2 : Filler Order Management
LAB-2 : 実施者オーダー管理
R
Laboratory TF sect 5
LAB-3 : Order Results Management?
LAB-3 : オーダー結果管理
R
Laboratory TF sect 6
LAB-4 : Work Order Management
LAB-4 : 検査オーダー管理
R*
Laboratory TF sect 7
LAB-5 : Test Results Management
LAB-5 : 検査結果管理
R*
Laboratory TF sect 8
LAB-4 : Work Order Management
LAB-4 : 検査オーダー管理
R
Laboratory TF sect 7
LAB-5 : Test Results Management
LAB-5 : 検査結果管理
R
Laboratory TF sect 8
LAB-21 : WOS Download
LAB-21 : WOSダウンロード
R
Laboratory TF sect X
LAB-22 : WOS Query
LAB-22 : WOSクエリー
R
Laboratory TF sect Y
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
12/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
LAB-23 : AWOS Status Change
R
Laboratory TF sect W
LAB-23 : AWOS状態変更
Laboratory Device
検査機器
LAB-26 : SWOS Status Change
LAB-26 : SWOS状態変更
O
Laboratory TF sect Z
LAB-21 : WOS Download
LAB-21 : WOSダウンロード
O
Laboratory TF sect X
LAB-22 : WOS Query
LAB-22 : WOSクエリー
O
Laboratory TF sect Y
LAB-23 : AWOS Status Change
LAB-23 : AWOS状態変更
R
Laboratory TF sect W
LAB-26 : SWOS Status Change
LAB-26 : SWOS状態変更
R
Laboratory TF sect Z
注釈１：LSWFとLDAのテーブルを参照
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
13/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
X.3 統合プロファイルオプション
この統合プロファイルで選択できるオプションは、テーブルX.3-1に使用するアクターと共に表記する。
Table X.3-1 Evidence Documents - Actors and Options
アクター
オプション
参照文書
ADT
患者管理
オプション未定義
--
Order Placer
オーダー依頼者
オプション未定義
--
Order Filler
オーダー実施者
オプション未定義
--
Order Result
Tracker
オーダーリザルト
トラッカ
オプション未定義
--
Automation
Manager
オートメーション
マネージャ
結果と整合するために、OFからの検査オーダー待ち
Vol. 1 Ch. X.1.3.3
option 1
OFに対し未確定結果の動的送信
Vol. 1 Ch. X.1.3.3
option 2
Laboratory Device
検査機器
オプション未定義
--
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
14/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
X.4 LIR統合プロファイルプロセスフロー
このセクションで示されているワークフロー図は、X.1章で記述されたユースケース毎に表現されてい
る。これはすでに明記された章を、図を用いて説明した高レベルなワークフローである。
X.4.1 身元不明患者登録がADTで行われた。臨床検査試験は、オーダー依頼者によりオーダー発行(検査
依頼)される。
このプロセスフローは、ユースケースX.1.1.1を基にしている。
Figure X.4-1. LIR Profile: process flow for unidentified or misidentified patient
この関連図では、AMが検体処理を終了し、検査結果がすでにOFアクターによって最終的な状態
（OBX11=F若しくはC）で格納された後、患者情報更新／マージが行われると仮定する。
AMの処理が終了する前に患者情報更新／マージを行った場合、次のセクションで説明されている状態
になる。
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
15/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
X.4.2 身元不明患者登録がADTで行われた。臨床検査試験は、オーダー実施者によりオーダーが発行さ
れる。
このプロセスフローは、X.1.1.2章のユースケースを表している。
Figure X.4-2. LIR Profile : process flow for unidentified or misidentified patient
このプロセスフローは、AMがまだ検体処理を行っている最中であるか、検査結果がOFアクターに届い
ていない場合の患者情報更新／マージに関して説明している。
AMアクターはADTシステム(患者管理システム)に直接接続されてはいないため、OFにより患者の新規
情報や詳細が送信されなければならない。逆を言うと、検査オーダー処理が終了するまで、同一患者の
新規検査オーダーが正確な患者属性と共に検査部門に到達しない限り、検査室の技術的アクターは患者
属性を意識しない。
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
16/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
X.4.3 ADTにおいて患者が登録されていない。臨床検査試験は、オーダー実施者によりオーダー発行が
される。
この処理フローは、X.1.2.2章のユースケースを基にしている。
Figure X.4-3. LIR Profile : local patient Id reconciled with enterprise Id
分析機器は、WOSのダウンロードを待つことなくWOSを問い合わせることができる。このシーケンス
図は、ローカル患者情報と施設内で登録されている患者情報が手動で整合性の確保が行われることを表
している。人的介入が必要であるため、臨床的検証を行っている最中が最も整合性確保を行うタイミン
グとして適している。
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
17/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
X.4.4 臨床検査試験がオーダー作成以前に検査機器で行われる。分析機器から開始する。
次の２つの図はX.1.3.1のユースケースを基にし、シナリオにある２パターンの最終部分を分離して考え
ている。
X.4.4.1 1つ目のシナリオの最終部分
X.1.3.1章のユースケースとX.1.3.3章の1つ目のオプション
Figure X.4-4. LIR Profile: process started on Analyzer and reconciliation at AM
ここでは、実施者オーダーはOPの依頼により作成される。技術的検証プロセスは、AMでの受信検査オ
ーダーと未確定結果の整合が行われる際に実施される。
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
18/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
X.4.4.2 2つ目のシナリオの最終部分
X.1.3.1章のユースケース及びX.1.3.3章の２つ目のオプション
Figure X.4-5. LIR Profile : process started on Analyzer and reconciliation at OF
ここでは、OFで受信テスト結果と整合可能である既存オーダーが発見できないため、新規実施者オーダ
ーが必然的に作成される。
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
19/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
X.4.5 オーダーが作成される以前に検査機器により臨床検査試験が行われる。オートメーションマネー
ジャから開始される。
次の２つの図は、X.1.3.2のユースケースを基にし、シナリオにある２パターンの最終部分を分離して考
えている。(X.1.3.3章を参照)
X.4.5.1 １つ目のシナリオの最終部分
X.1.3.2章のユースケース及びX.1.3.3章の1つ目のオプション
Figure X.4-6. LIR Profile : process started on AM and reconciliation at AM
AMに検査オーダーが存在するため、検査機器が読み込んだ検体に対しどのような操作を行うべきか判
断できない場合、WOS取得のための問い合わせ（LAB-22）を行う。
この場合、実施者オーダーはOF（X.1.3.3オプション１注釈１を参照）で作成される。このプロセスは、
X.1.3.2で定義されたシナリオ初期部分に影響は及ぼさないが、実施者オーダー作成のための更なるオプ
ション付加が必要である。
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
20/21
IHE Technical Framework Supplement – Draft for Trial Implementation
______________________________________________________________________________
X.4.5.2 ２つ目のシナリオの最終部分
X.1.3.2章のユースケース及びX.1.3.3章の2つ目のオプション
Figure X.4-7. LIR Profile: process started on AM and reconciliation at OF
AMで検査オーダーを手動で作成し、検体を検査機器に設置する。検査機器は検体に対し適切な処置を
実施するためにAMに問い合わせを行うことのできるアクターである。
一度結果が送信されると、その結果と整合可能な既存オーダーが OF 上に存在するため、実施者オーダ
ーの新規作成は行われない。（X1.3.3 オプション 2 の注釈 2 を参照）
Copyright © 2005: GMSIH / HL7 France H’ / HL7 Germany /IHE-J / JAHIS / SFIL / IHE Italy
21/21

Download Report