ろは病院内の各サブシステム間でのスムースな情報交換であるしかしながら欧米の IHE テクニカルフレームワークを調査した結果既に日本国内の多くの施設で採用されているシステム連携の仕組みや業務運用とは異な

(1)

３．システムの相互接続性

３．１欧米のIHE テクニカルフレームワークによる相互接続性確保の確認

１９９９年から米国に於いて始まった Integrating the Healthcare Enterprise （IHE）の活動は、欧州や日本、韓国、台湾などにその輪を広げつつあり、着々と実績を上げつつある。 IHE の活動の中心は、テクニカルフレームワークと呼ぶ実装仕様書の発行と、コネクタソンと呼ぶ対応ベンダを集めて行う総合接続性の検証試験であると言える。テクニカルフレームワークでは、それぞれの分野での統合プロファイルとその統合プロファイルを実装する際に必要なトランザクションの定義が記載されている。現状では、米国が中心になってまとめているテクニカルフレームワークが全世界でのコアになっており、各国の事情による変更部分については、それぞれの地域ごとの拡張仕様として別巻にまとめられている。ここでは、コアとしたまとめられた欧米のIHE テクニカルフレームワークについて検討を行い、我が国の臨床現場に適用した際に、運用上の問題が生じないかどうか、我が国での通常の実装においてテクニカルフレームワークでの仕様との齟齬がないかどうかの検討を行い、相互接続性が確保できるかどうかの観点での確認を行った。今年度までに、IHE のテクニカルフレームワークとしては次の４つの分野・部門のものが発行されている。・放射線部門（Radiology）・臨床検査部門（Laboratory）・情報技術共通基盤（IT Infrastructure）・循環器部門（Cardiology）それぞれについて検討を行い、成果物としてNational Extention を作成した。３．１．１放射線部門３．１．１．１ HIS-RIS メッセージ標準化（１）はじめに

１９９９年に米国で始まった、IHE（Integrating the Healthcare Enterprise）では、すでに制定されている標準規格（HL7、DICOM など）に基づくシステム構築をめざし、その適用ガイドラインを示す活動を行っている。その日本版として２００１年に発足したIHE-J では、日本画像医療システム工業会（JIRA）と保健医療福祉情報システム工業会（JAHIS）、日本医学放射線学会（JRS）、日本放射線技術学会（JSRT）、日本医療情報学会（JAMI）が参画して、わが国の病院情報システム（HIS）と放射線画像部門システム（RIS、PACS、モダリティなど）との効果的かつ効率的な情報伝達の仕組みを検討してきた。IHE のめざすとこ

(2)

ろは、病院内の各サブシステム間でのスムースな情報交換である。しかしながら、欧米のIHE テクニカルフレームワークを調査した結果、既に日本国内の多くの施設で採用されているシステム連携の仕組みや業務運用とは異なる部分があり、そのまま適用できないことが判明した。HL7 部分に限定しても、IHE では PID-18（患者会計番号）や PV1-19（通院回数）を必須項目としているが、わが国の実情には合わない。患者到着確認も臨床検査分野を中心に、日本ではORU メッセージで表現することが多い。他のメッセージの組み立ても若干異なっている。当然ながらマルチバイト対応も必要である。特に、病院情報システム（HIS）の位置づけが欧米とは大きく異なっていた。したがって、単に先行している欧米のIHE を模倣するのではなく、日本の慣習や医療制度に合わせた分析をしなければならない。IHE で HL7 を適用する際には詳細な調査が必要である。

（２）IHE-J としての拡張（National Extension）

保健医療福祉情報システム工業会（JAHIS）では、IHE-J の活動を睨みつつ、臨床検査や処方などのデータ交換規約との整合も図りながら、病院情報システム（HIS）と放射線部門システム（RIS）とのデータ交換の仕組みを検討し「JAHIS 放射線データ交換規約」を作成した。本書では、HL7（Ver2.4）の第 4 章オーダ入力を中心に、第2 章コントロールおよび第 3 章患者管理などから放射線に関係する部分をまとめている。わが国の実情に合わない部分や解釈が曖昧になりやすい部分については放射線データに限定した注釈を加えた。詳細については、 http://www.jahis.jp/ を参照されたい。本稿では、IHE のテクニカルフレームワークに記述されている統合プロファイルやアクタ、トランザクションの定義を日本国内で実践するにあたり、それを効果的に支援するために拡張あるいは制限した事項（National Extension）について述べる。１）文字コード HL7 でのトランザクションを行う全てのアクタに対し、マルチバイト文字をサポートすることを必須とした。すなわち、MSH-18 フィールドの第 1 要素に ASCII 文字コード（ISO IR 6）を、第 2 要素に JIS 漢字コード（ISO IR87）を設定することを推奨している。文字コードの切替えにはISO2022-1994（JIS-X0202）を使用する。また、半角カタカナ（ISO-IR 13）の使用を禁止し、また、JIS 補助漢字（IR 159）の使用も推奨しないこととした。ISO IR87 にない 2 バイト系文字は類似形態の文字またはひらがな（カタカナ）を用いる。

(3)

２）メッセージ構成

日本国内でのHL7 実装の実情や放射線以外の分野との整合性も意識しながら、IHE テクニカルフレームワークで定義されている仕様を拡張した。 ① ORM メッセージへの応答メッセージ

IHE テクニカルフレームワークには、ORM メッセージへの応答に ACK メッセージを用いると記述されている。しかしながら、HL7 規約では ORR メッセージを用いるとしており、明らかに解釈の誤りである。すでにIHE に申し入れており、本件に関する訂正も行われることになっているが、当面は ORR メッセージの使用を日本版拡張として扱う。 ② MLLP の不採用（開始ブロックの付加など）前述のORRメッセージと同様に、IHEにおけるHL7の利用に関しては、いくつかの誤解がある。開始ブロック制御文字の利用もその一つである。HL7の実装例（Minimum lower layer Protocol）としてMSHの前に開始ブロック制御文字を付加する例が示されているが、これはOSIの下位層がRS232Cなどの場合を想定しており、TCP/IPのような環境では適当でない。また、日本国内でのHL7実装の実情を考えた場合に、このような制御文字を付加していない事例が多く、放射線以外の分野との整合性も意識すると、開始ブロック(0b)を付加しない方が好ましいと判断した。下位層の問題をアプリケーションに持ち込むべきではないと考える。 ③ 患者到着確認や検査完了通知 IHE-J では、放射線検査における患者到着確認や検査完了通知は、臨床検査と同様にORU/ACK メッセージを用いる。OBR-25 に、‘Ｉ’（到着確認）、‘A’（部分結果報告）、‘R’（未承認結果報告）、‘F’（最終結果報告）などのステータスを設定する。なお、IHE-J コネクタソンでは‘Ｉ’（到着確認）と‘F’（最終結果報告）のみを扱うことにした。現時点ではステータス通知だけで、会計情報は扱っていない。 ④ 患者情報通知本メッセージは放射線固有のものではなく臨床検査や処方などと同一である。したがって、イベントは患者登録（A04）及び患者更新（A08）を使用することとし、その他については関連システム間の取り決めとした。但し、患者情報は検査依頼情報とともに提供され、ADT メッセージによる情報提供という形を取らないのが一般的である。HIS-RIS 間での PID-5（患者氏名）については、表音文字（カナ氏名）を必須とし、漢字氏名やローマ字氏名は任意とした。カナ氏名→英字氏名（ローマ字）の変換は RIS 側で行う。なお、患者所在を示す ADT メッセージは、日本ではほとんど使用されていない。患者マージ（A40）については技術的な問題に加え、運用的な問題も解決する必要があり、今のところ

(4)

採用しない。 ⑤ 検査依頼情報通知わが国では検査依頼時に詳細情報を指定することが多い。そこで、検査種別、検査部位、検査詳細、検査材料などの階層構造を実現するために、ORC セグメントで、撮影全体に関する情報を親オーダ、個々の撮影に関する情報を子オーダとして記述し、紐付けすることにした。具体的な例を挙げて説明する。図３．１－１では、X 線単純撮影の胸部正面（A→P）と胸部側面（L→R）及び、腹部正面（A→P）と腹部側面（L→R）を依頼している。 MSH|^~\&|HIS|IHEJÔP|RIS|IHEJÔF|20040120100000||ORMÔ01|20040120000010|P|2.4|||||| ~ISO IR87||ISO 2022-1994 <cr> PID|||0123456789^^^^PI||東京^太郎^^^^^LÎ~トウキョウ^タロウ^^^^^L^P||19501214|M||| 東京都港区虎ノ門１－１９－９^^^^1050001||^PRN^PH^^^03^35068010 <cr> PV1||O|01 <cr> ORC|NW|200401200000100|||||||20040120100000|||D12345^中田^隆^^^^^^^L|01 <cr> ORC|PA|200401200000100|||||||20040120100000|||D12345^中田^隆^^^^^^^L|01 <cr> OBR||200401200000100||1210000000000000^Ｘ線単純撮影^JJ1017-16P|||200401201030||||||||| D12345^中田^隆^^^^^^^L|||||||||||^^^^^R <cr> OBX||NM|01-02^体重||62|kg|||||P <cr> ORC|CH|200401200000101||||||200401200000100|20040120100000|||D12345^中田^隆^^^^^^^L|01 <cr> OBR||200401200000101||12100002000102000001000000000000 ^胸部.Ｘ線単純撮影.立位正面(A→P)^JJ1017-32|||200401201030||||||||| D12345^中田^隆^^^^^^^L|||||||||||^^^^^R||200401200000100 <cr> ORC|CH|200401200000102||||||200401200000100|20040120100000|||D12345^中田^隆^^^^^^^L|01 <cr> OBR||200401200000102||12100002000106000001000000000000 ^胸部.Ｘ線単純撮影.立位側面(L→R)^JJ1017-32|||200401201030||||||||| D12345^中田^隆^^^^^^^L|||||||||||^^^^^R||200401200000100 <cr> ORC|CH|200401200000103||||||200401200000100|20040120100000|||D12345^中田^隆^^^^^^^L|01 <cr> OBR||200401200000103||12100002500102000001000000000000 ^腹部.Ｘ線単純撮影.立位正面(A→P)^JJ1017-32|||200401201030||||||||| D12345^中田^隆^^^^^^^L|||||||||||^^^^^R||200401200000100 <cr> ORC|CH|200401200000104||||||200401200000100|20040120100000|||D12345^中田^隆^^^^^^^L|01 <cr> OBR||200401200000104||12100002500106000001000000000000 ^腹部.Ｘ線単純撮影.立位側面(L→R)^JJ1017-32|||200401201030||||||||| D12345^中田^隆^^^^^^^L|||||||||||^^^^^R||200401200000100 <cr> 図３．１．１－１放射線検査依頼メッセージ例親オーダ（ORC-1：‘PA’）では、OBR-4 で検査種別を、OBX-3,5 で患者プロファイル情報を記述する。一方、子オーダ（ORC-1：‘CH’）では、OBR-4 で検

(5)

査部位や検査詳細（方向）を記述する。部位などが異なる撮影に関しては、それぞれを子オーダで記述する。そして、親オーダと子オーダをORC-8 や OBR-29 で紐付ける。すなわち、患者プロファイル情報と、検査種別（Ｘ線撮影、CT 撮影など）、検査部位（胸部、腹部など）、検査詳細（撮影方向など）、検査材料（薬剤、フィルムなど）をすべてOBR/OBX セグメントで記述することになる。新規オーダを表すORC(NW)などは､ORC(PA)の前に記述する。親子メッセージの関係を図３．１．１－２に示す。 ORC(NW) 新規オーダ ORC(PA) 親オーダ OBR 親オーダの記述（検査種別を指定） ORC(CH) １番目の子オーダ OBR １番目の子オーダの記述（撮影部位、方向等を指定） ORC(CH) ２番目の子オーダ OBR ２番目の子オーダの記述（撮影部位、方向等を指定）図３．１．１－２親子メッセージの関係なお、項目コードは、JJ1017 委員会（主査：浜松医科大学の木村通男教授）で検討された標準コードを推奨している。JJ1017 マスタ（Ver3.0）のコード構造は図３．１．１－３の通りである。項目は、保険診療上必要な前半１６桁部分（JJ1017-16M という）に、伝票種別に相当するモダリティコードの他、検査を同定するための手技（大分類、小分類）、部位（左右区分含む）、体位方向などが設定されている。そして、後半１６桁部分（JJ1017-16S という）には、その他の詳細情報が設定されている。これらのコードの組み合わせにより、指示内容を３２桁（JJ1017-32 という）で表現する。詳細については、JJ1017 委員会から発信される情報を参照されたい。親オーダのOBR-4 にはオーダを括るための JJ1017-16P を設定する。JJ1017-16M のうち、先頭の３桁分（モダリティ＋手技大分類）をセットし、他のコードを０で埋めた形式を標準形とするが、施設の事情により設定する内容を変更（例えば、モダリティコードの１桁のみ、あるいは手技全体コードの７桁に）してもよい。子オーダのOBR-4 には JJ1017-16M＋JJ1017-16S の 32 桁（JJ1017-32）を設定する。

(6)

図３．１．１－３ JJ1017 マスタ（Ver3.0）のコード構造 ⑥ 患者プロファイル情報患者プロファイル情報（感染症、アレルギーなど）は、基本的に所見／結果情報として OBX セグメントにまとめて記述する。他のセグメントに記述してもHL7 文法上は誤りではないが、アレルギー情報などは放射線検査の禁忌情報として使用されるため、その他の禁忌情報と分散させない方が使いやすいと判断した。撮影に必要な検査結果などは、OBX-11 で‘P’（事前結果）と記述する。但し、臨床検査でも扱っている歩行状態（独歩、介助）などは、OBR セグメントで記述する。 ⑦ その他放射線検査専用のデータ型として‘ZRD’を新たに定義した。「フィルム（半切）を２分割で１枚使用」というような、薬品やフィルムの量、フィルムの分割数などの数値量を記述するために用いる。また、HL7 では、記述的レポート中で共通コンポーネントに用いる検査 ID を生成するためのコード接尾辞を定義することができるが、フィルム情報を扱う接尾辞として新たに‘ZFM’を定義した。‘ZFM’が付加された OBX-3（検査項目）は、放射線検査において使用されるフィルムの情報が含まれていることを示す。患者が複数のフィルムを使用する場合は各OBX セグメントで、該当する撮影を記述しているOBR に関連するよう記述する。

(7)

３）実装上の注意 IHE-J コネクタソンにおいて、HL7 メッセージを実装する際、事前に確認した基本的な約束ごとを以下に記す。 ① メッセージ表現・HL7 メッセージは<EOM>までを１メッセージとして送受信する。・メッセージは複数のセグメントにより構成され、各セグメントは<CR>（文字コード00/13）により区切られる。・メッセージの最後には２バイトからなるメッセージ終端文字列<EOM>（文字コード01/12 と 00/13 の２バイト）を付ける。 ② メッセージ送受信・メッセージの送受信はTCP/IP によるソケット通信とし、ORM/ORR、 ORU/ACK、ADT/ACK で各１ポート使用する。なお、データ送信元がコネクションを確立することとし、連続しているデータがある限りコネクションを維持し、データが途切れた時点で開放する。・受信側では、必須フィールド以外のフィールドに値が設定された応答メッセージが送信されてくる可能性があることを前提とする。すなわち、受信側で不要なデータは読み捨てる。・送信側で管理していない情報は、null データとする。受信側は全ての情報がセットされてくると誤解しない。（必須フィールド以外）・オーダ番号（15 桁）はユニークキーとする。図３．１．１－１のメッセージ例では下２桁を連番として、親レコードを 00、子レコードを 01～99 で示している。・修正オーダはCancel オーダと New オーダを続けて発行する。（オーダ番号は同一）

・Cancel オーダでは OBR の親オーダ（PA）までを送信すればよい。（オーダ番号をもとに当該オーダを削除）

(8)

３．１．１．２新たに対応する統合プロファイルの検討２００３年度の放射線部門に関するIHE-J の活動では、表３．１．１．２－１放射線部門の統合プロファイルに示す１４種の統合プロファイルのうち、中心となる１～４の４つの統合プロファイルへの対応を行った。表３．１．１－１放射線部門の統合プロファイル名称略称概要対応状況 1 Scheduled Workflow SWF 放射線検査基本ワークフロー昨年度実施

2 Patient Information _{Reconciliation} PIR 患者情報の整合性確保昨年度実施

3 Consistent Presentation _{of Image} CPI 画像表示の一貫性確保昨年度実施

4 Simple Image and _{Numeric Report} SINR 単純な画像と数値付きのレポート昨年度実施

5 Presentation of _{Grouped Procedure} PGP 複数検査の一括処理

6 Post-Processing _Workflow PWF 後処理・画像処理のワークフロー

7 Reporting Workflow RWF 読影レポート作成のワークフロー

8 Charge Posting CHG 放射線検査会計

9 Key Image Note KIN キー画像の選択と注釈の付加

10 Evidence Documents ED エビデンスドキュメント

11 Access to Radiology _Information ARI 放射線部門情報へのアクセス

12 Basic Security SEC 基本的なセキュリティ対策

13 NM Images NM 核医学画像新規項目

14 Portable Document for _Imaging PDI 媒体による画像情報交換新規項目

本事業では、新たに今年度から追加された１３，１４の「核医学画像」及び「媒体による画像情報交換」を含め、米国で定められた１４の統合プロファイル全てに対応することにした。ここでは、本事業で対応を行うことにした、５～１４の統合プロファイルについて、欧米で定めたテクカルフレームワークを用いて、我が国で実施されている放射線部門検査における相互接続性に関して、適用可能かどうかの検討を行った。（１）米Technical Framework の翻訳

米IHE Initiative からは、２００３年１１月２０日に、４巻構成の IHE Technical Framework Revision 5.5 が発行されており、前述の統合プロファイルの内、１～１２までが既に定められている。２００４年度は、それらに加え、２００４年６月４日に、IHE Radiology Technical Framework Supplements 2004-2005 - For Trial

(9)

Implementation が発行されており、既存の統合プロファイルへの拡張と、１３，１４の新たな統合プロファイルの追加が行われた。

今回５～１４の統合プロファイルの検討に先立ち、IHE Radiology Technical Framework Supplements 2004-2005 - For Trial Implementation の翻訳作業を行った。（２）PGP に関する検討同一患者に対する複数の放射線検査オーダがあった場合、１回の撮影で複数の検査に対応できるケースがあるが、従来のDICOM 等の規格で定められている検査と撮影の関係では対応できなかった。たとえば、同一患者に対し呼吸器内科から胸部CT の撮影を、消化器外科から腹部 CT の検査依頼が別々に出された場合、CT 撮影そのものは、胸部と腹部を連続して撮影できるケースがあるが、実際には１回の撮影単位では１回の検査分の画像シリーズしか出力できないため、胸部撮影と腹部撮影とを別々に行わざるを得なかった。 PGP はこのような検査依頼に対し、プレゼンテーションステート（略称：PR）と呼ばれる DICOM オブジェクトをそれぞれの検査ごとに作成し、同一の画像データの必要な部分を参照することにより、１つの画像データを複数の検査として利用できるようにするものである。このため、撮影時に胸腹部の撮影を行い、胸部検査の依頼に対するPR と腹部検査の依頼に対するPR を作成することにより、以後の読影レポート作成・検査結果の報告についてPR 単位に行うことにより、検査単位での扱いを可能としている。検討の結果、この統合プロファイルの技術的な枠組みについては、大きな問題は無く、日本での運用において特に技術的に付加すべき事項はないと判断した。しかしながら、実際のCT 撮影においては、胸部と腹部とで撮影条件や再構成条件などが異なるため、連続で撮影できるケースは少なく、あまり実用的では無いとの指摘もあった。（３）PWF に関する検討本統合プロファイルは、放射線検査の撮影により生成された画像データに対する後処理に関するワークフローを規定するものである。アクタとトランザクションとの関係を図３．１．１－５ PWF のアクタとトランザクションに示す。

(10)

Evidence Creator Evidence Creator Post Processing Manager Post Processing Manager Image Display Image Display DSS/ Order Filler DSS/

Order Filler Image ManagerImage Manager Image ArchiveImage Archive

Image Availability Query Perfoemed Work Status Update

Query Post-Processing Worklist Workitem Clamed

Workitem PPS In Progress Workitem PPS Completed Workitem Comleted

Creator Image Stored Query Images Retrieve Images

Query Other Content Retrieve Other Content

図３．１．１－５ PWF のアクタとトランザクション

後処理としての画像処理や画像解析はEvidence Creator（略称 EC）と呼ばれるアクタが処理を行う。EC は通常 Image Display（略称 ID）と呼ばれる画像標記機能を合わせて実装されることが想定されている。EC は Post Processing Manager（略称 PM）から Post-Processing Worklist を検索取得し、その内容に従ってImage Manager/Image Archive（略称 IM/IA）から必要な画像データなどを取得し、後処理を行う。その際に、複数のEC が存在する場合の排他制御を PM が行うため、どのWorklist の処理を行うかを Workitem Clamed のトランザクションを行っている。また、処理の進行状況をPM に報告するためのトランザクションをDICOM の GPPPS の通信により実装することになっている。EC が後処理として生成した画像やエビデンスドキュメントは、IM/IA に保存され、放射線部門システム（RIS）である DSS/Order Filler（略称 OF）に、利用可能になったかどうかの情報を提供する。検討の結果、この統合プロファイルの技術的な枠組みについては、大きな問題は無く、日本での運用において特に技術的に付加すべき事項はないと判断した。しかしながら、現状では各種の後処理は、撮影を行ったモダリティに付属したワークステーション等で実施されることが多く、本格的なPM を使用するケースは少ないとの指摘があった。また、PM での Worklist の作成の元となる情報をどこから入力するかについての規定はされていないため、どの用にPM を実装するかについては、今後検討の必要があるとされた。

(11)

（４）RWF に関する検討放射線検査部門での最も重要な機能の一つとして、撮影機能の他に、撮影された画像データを読影しレポートを作成することがある。従来は、X 線写真やイメージャから出力されたモダリティ画像のフィルムをそれぞれの検査ごとにシャーカステンに掲示し、読影診断をおこないレポートを作成していたが、ディスプレイモニタによる診断が行われるようになりつつあり、その際のワークフローを定義したものがこのRWF の統合プロファイルである。この統合プロファイルは、昨年度対応を行ったSINR（単純な画像と数値付きのレポート）と連携し、機能するものである。そのアクタとトランザクションを図３．１．１－６ RWF のアクタとトランザクションに示す。 Report Creator Report Creator Report Manager Report Manager PPS Manager PPS Manager DSS/ Order Filler DSS/ Order Filler Image Archive Image Archive Image Manager Image Manager

Performed Work Status Update _{Query Reporting Worklist} Workitem Clamed Workitem PPS In Progress Workitem PPS Completed Workitem Comleted

Madality PS Completed

Image Availability Query

Report Reader Report Reader Procedure Scheduled Procedure Update Image Display Image Display Query Image Retrieve Image 図３．１．１－６ RWF のアクタとトランザクションこのレポート作成のワークフローを全体として制御を行うものが、Report Manager（略称 RM）であり、部門システムである OF から、検査依頼情報を Procedure Scheduled および Procedure Update のトランザクションにより取得し、その情報をもとにレポート作成の依頼情報をDICOM GPWL のオブジェクトとして生成する。また、その際に、PPS Manager（略称 PPSM）から撮影検査の実施状況を、IM/IA から画像データの生成状況を取得し、画像診断が可能な状況になったかどうかを判断している。

(12)

実際にレポートを作成する機能は、SINR で既に定義されている Report Creator （略称RC）が行うが、RC は RM に対し Query Reporting Worklist のトランザクションにより先に生成されているDICOM GPWL のオブジェクトを取得し、それに基づいて読影診断を行う。実際にはこの統合プロファイルには規定されていないが、RC と一緒に、あるいは隣接した形で実装されている ID が IM/IA より必要な画像データを取得し、画像表示をおこない読性診断を行うことが期待されている。このワークフローに関しては、表３．１．１－２ RWF におけるユースケースに示す１１種類のユースケースが規定されており、それぞれについて検証を行った。表３．１．１－２ SWF におけるユースケース名称概要 1 Predefined Repot 草案レポート（ひな形） 2 Workitem Deferred 読影作業を延期する

3 Direct Report Creation 直接レポート作成（基本形） 4 Interpretation and Dictation 読影とディクテーション 5 Transcription 音声からの文書化 6 Partial completion 部分的なレポートの完成 7 Verification レポートの検証 8 Double Reading 二重読影 9 Comparison 複数のレポートの比較 10 Review レポートのレビュー 11 Over Read 確認読影現状での日本の読影診断の運用を考えた場合、これら１１全てのユースケースを実施している施設はないと考えられるが、理由として人的およびシステムとしてのリソースが不足しているためであり、これら１１のユースケースへの対応は必要なものであると考えられる。しかしながら、日本での運用を考慮しこれら意外にユースケースを追加すべきかどうかについては、まだ検討が進んでおらず、今後の検討が必要である。（５）CHG に関する検討 CHG は、米国における撮影技術に対する Technical Fee と読影診断に対する Professional Fee の会計処理をベースに考えられた統合プロファイルである。図３．１．１－７ CHG のアクタとトランザクションに、そのアクタとトランザクションの関係を示す。

(13)

Evidence Creator Evidence Creator Post Processing Manager Post Processing Manager Acquisition Modality Acquisition Modality Report Manager Report Manager PPS Manager PPS Manager DSS/ Order Filler DSS/ Order Filler ADT ADT Charge Processor Charge Processor Account Management Charge Posted Modality PS In Progress Modality PS Completed Creator PS In Progress Creator PS Completed Creator PS In Progress Creator PS Completed Modality PS In Progress Modality PS Completed Workitem Completed Perfomed Work Status Update

図３．１．１－７ CHG のアクタとトランザクション会計処理そのものは、日本における医事システムに相当するCharge Processor （略称CP）において行われ、その内容については、特に規定はされていない。この統合プロファイルで規定されているのは、放射線部門の各システム（アクタ）からの、どのような情報をどのようにCP に対して送ることにより会計処理が可能になるかである。 CP に対しては、ADT が患者のアカウント情報を送付し、検査内容についてはOF が送付することになっている。構造的には、RIS が HIS に対して実施情報を送付することに相当する。OF は、実際に行われた画像撮影での検査種別や枚数、サイズなどの情報をDICOM の Modality Performed Procedure Step オブジェクトとして、PPSM を経由し Acquisition Modality（略称 AM）から取得するとともに、PM から画像処理などの後処理の情報を、RM から読影診断の情報を取得し、それらをCP に転送する機能を担っている。 Charge Posted の情報としては、単純な放射線検査の会計であれば、日本での運用が可能であるが、検査の組み合わせなど各種の例外規定のある診療報酬の計算に使用できるかについては、疑問が残るところが多い。また、ADT からのアカウント情報についても、保険制度が瀧にわたる我が国の状況では、メッセージとして不十分との見解となった。このため、CHG について今後の日本での適用に関しては、相当な検討が必要

(14)

であり、根本からの組み替えが必要であるとの結論になった。（６）KIN に関する検討放射線科医が読影する際にその判断のポイントとなったキーとなる画像やその画像に含まれる陰影などを選択し、その解釈について画像そのものに注釈を付けることにより、読影結果を利用する診療医に対する利便性は非常に高まるとされている。特に近年普及してきたマルチスライスCT や MR では数百枚から場合によっては千枚以上の画像データが１回の検査で生成されるため、キーとなる画像を明示的に示すための仕組みは重要となってきている。KIN は、そのような目的のための統合プロファイルである。

仕組みとしては、DICOM で規定されている Key Image Object（略称 KO）を作成し、画像データを参照することにより、どの画像データがキー画像であるかを示し、その画像に対する注釈などを画像表示の際に合わせて表示することが可能になる。KIN におけるアクタとトランザクションの関係を、図３．１．１－８ KIN のアクタとトランザクションに示す。 Evidence Creator Evidence Creator Image Manager

Image Manager Image ArchiveImage Archive

Acquisition Modality Acquisition Modality Image Display Image Display Storage Commitment

Storage Commitment Store Key Image Note

Store Key Image Note

Query Images Retrieve Images Query Key Image Notes Retrieve Key Image Notes

(15)

KO は、撮影を行ったモダリティ（AM）か、画像表示・処理を行う EC に於いて生成され、IM/IA に保存される。画像を ID において参照する際には、IM/IA から画像データとともに、その画像に関連するKO を検索取得することにより、画像表示とあわせてキー画像や注釈の表示が可能となる。本統合プロファイルは、機能として非常に有用であり、標準的なDICOM の仕組みで実装されることから相互接続性も高く、また注釈においても日本語が標準的に使用できることなど、我が国での実装は非常に有用であるとの結論になった。しかしながら、現状の診療医が参照する画像データは、HIS や電子カルテの端末でWEB を使用して表示されるシステムが増えてきており、DICOM の画像やKO を直接使用できる環境の提供は難しく、KO の情報を WEB を通じて提供できる仕組みが必要との指摘が合った。（７）ED に関する検討 Evidence Document とは、法的に証拠となる文書という訳ではなく、診断医がその診断を行った際にその判断の根拠となる情報を示しており、広くは画像データも含まれるが、IHE においては DICOM の Structured Report（略称 SR）オブジェクトとして定義されているものを指している。具体的には、超音波検査における各種の計測値や、最近注目を集めているCAD の結果などがある。図３．１．１－９ ED のアクタとトランザクションに、ED 統合プロファイルにおけるアクタとトランザクションの関係を示す。 Evidence Creator Evidence Creator Image Manager

Image Manager Image ArchiveImage Archive

Acquisition Modality Acquisition Modality Image Display Image Display Storage Commitment

Storage Commitment Evidence Documents Stored

Query Evidence Documents Retrieve Evidence Documents

Evidence Documents Stored

Report Creator Report Creator

(16)

先に述べたKIN における関係とほぼ同様であり、ED は AM もしくは EC で生成されIM/IA に保存される。IM/IA に保存されている ED は ID から検索取得され画面上に表示され、ID に付設された RC により読影診断のレポートが作成される。検討の結果、トランザクションの関係については、問題ないとの結論になった。しかしながら、計測値などの情報を保管し他のアクタに伝えるコンテナとしてDICOM SR が適切であるかについては、まだ議論が残っており、今後の検討が必要である。（８）ARI ARI は、放射線部門で生成される重要な２つの情報への他部門からのアクセス手段を提供するための統合プロファイルである。重要な２つの情報とは、放射線検査画像データと読影レポートである。これら２つの情報を、DICOM の Query／Retrieve を用いて他部門に提供する仕組みを定義している。図３．１．１－１０ ARI のアクタとトランザクションに本統合プロファイルでのアクタとトランザクションの関係を示す。 Image Manager

Image Manager Image ArchiveImage Archive Report RepositoryReport Repository Image Display Image Display Contents Query Contents Retrieve Report Reader Report Reader External Report Repository AccessExternal Report Repository Access Query Reports Retrieve Reports Query Reports Retrieve Reports 図３．１．１－１０ AIR のアクタとトランザクション

画像データの参照は、ID から IM/IA に対する画像データの Query／Retrieve により行い、読影レポートの参照はReport Reader（略称 RRD）から Report Repository（略称 RRP）もしくは External Report Repository Access（略称 ERRA）に対するSR の Query／Retrieve により行われる。

いずれの参照もDICOM オブジェクトによるものであり、すでに我が国においても十分実績のある技術であるため、相互接続性に関して十分対応できる統合プロファイルであると考えられる。

(17)

ベースで行われることが多いため、どの程度日本において、この仕組みが使用されるかは不明である。DICOM そのものの検討においても、WEB ベースでの DICOM データへのアクセス方法として WADO（WEB Access to DICOM

Persistent Object）の規格が提案され、ISO/TC215 Medical Informatics で規格化されようとしており、この技術に基づいた枠組みが必要となってきたと考えられる。IHE では、放射線部門以外のテクニカルフレームワークとして IT

Infrastructure と呼ぶ基盤系の枠組みが検討されており、そちらのなかで Retrieve Information for Display（略称 RID）が規定されており、それらとの比較検討が、今後必要であると考えられる。（９）SEC ２００５年４月からの個人情報保護法の全面施行を控え、医療機関においても施設内にある「究極の個人情報」と言われる診療情報をいかに守るかが、大きな課題となっている。特に情報システムを使用し診療情報を扱う場合、適切なセキュリティ対策を施さない限り、情報の漏洩にすら気づかず、大量の診療情報が不正な第三者に渡ってしまうことが予想される。米国においては、既に HIPAA（Health Insurance Portability and Accountability Act）の Privacy Standard が施行されており、基本的には医療機関側の個人情報保護の義務を定めたものであるが、そのための技術手段の提供は医療機関から求められており、それらに対する一つの技術手段がこのSEC 統合プロファイルであると言える。 SEC の基本的な考え方は、診療情報へのアクセスの記録を正確に取り、安全に保存しておく、ということであると言える。すなわち、万が一情報が漏洩した場合、その情報に誰が何時アクセスしたかの記録があれば、その犯人を突き止めることができるため、そのような仕組みが実装されていることにより、不正な行動を起こさせない抑止効果が期待できるとされている。 SEC におけるアクタとトランザクションの関係を、図３．１．１－１１ SEC のアクタとトランザクションに示す。

(18)

Any IHE Actor Any IHE Actor Secure Node

Secure Node

Secure Node Secure Node Any IHE Actor Any IHE Actor

Any IHE Actor Any IHE Actor

Audit Record Repository Audit Record

Repository

Node Authenticatoin _{Maintain Time}

Time Server Time Server

Maintain Time

Record Audit Event

図３．１．１－１１ SEC のアクタとトランザクション

SEC に対応する全てのアクタは、それぞれの機能に応じて診療情報へのアクセスのイベントが生じた場合にその監査証跡を生成することが必要であり、生成した監査証跡をAudit Record Repository（略称 ARR）に保存することが要求されている。ARR は監査証跡の保管庫であり、ここに放射線部門全体のシステムの監査証跡が集中的に安全に保管されることになっている。また、監査証跡としての正確性を向上させるためには、誰が何時アクセスしたかを正確に記録する必要がある。これらに対応するためにSecure Node（略称 SN）と呼ばれるアクタが定義されており、この SN としての要件として、ユーザの認証機能、通信相手のシステムの認証機能、正確な時計合わせ機能が要求されている。我が国における個人情報保護においても同様の要件が求められ、これらの機能で当面は十分であると考えられ、積極的に推進していくべきとの結論となった。しかしながら、我が国においては、診療情報の電子保存を行う際に、個人除法保護とは別に、保存されている診療情報の真正性、見読性、保存性の３つの要件が示されており、これらの要件に対して、このSEC 統合プロファイルで十分かどうかは、疑問の余地があり、今後の検討が必要であるとされた。

(19)

（１０）NM に関する検討 NM は２００４年度から拡張された統合プロファイルであり、核医学画像の扱いについて定めたものである。NM におけるアクタとトランザクションの関係を、図３．１．１－１２ NM のアクタとトランザクションに示すが、これはSWF において示された部分であると言え、KIN などのコンテンツ系の統合プロファイルと同様である。 Evidence C reator Evidence C reator Im age Manager

Im age Manager Im age A rchiveIm age A rchive

A cquisition Modality A cquisition Modality Im age Display Im age Display

Storage Com m itm ent

Storage Com m itm ent Creator Im age Stored

Query Im ages Retrieve Im ages

M odality Im age Stored

図３．１．１－１２ NM のアクタとトランザクションこのNM 統合プロファイルのポイントは、アクタとトランザクションというよりもID における核医学画像をいかに表示するかという点に力点がある。核医学検査では、撮影後に専用のワークステーションで様々な画像処理が行われることが普通であり、それらの処理結果を効果的に表示することが読影診断において重要であるといえる。従来は、読影診断はそれらの画像処理を行うワークステーションで直接行われてきたが、ネットワークシステムの進歩に従い、画像読影用のID においても同様の形態での表示が求められてきており、それらに対する要求から、このNM 統合プロファイルが作られている。従って、トランザクションやアクタは新設されてはいないが、トランザクションの内容に関しては、大幅に拡張されている。核医学に関してはIHE-J においても臨床検査委員会で２００３年度にワークフローの検討を行っており、既に報告しているが、それらの内容について、米のテクニカルフレームワークのAppendix に Informative として掲載されており、アクタやトランザクション検討のベースになっていることが述べられている。このように、もともとベースとして日本でのワークフロー検討が下敷きとさ

(20)

れており、トランザクションの拡張しようについても、DICOM として基本的に従来から定められているものであり、相互接続性の観点で問題ないとの結論となった。（１１）PDI に関する検討今までに検討してきた統合プロファイルは、全てネットワークによるトランザクションをベースにして作られているものである。それに対し、このPDI は、ネットワークを使わずに可搬型の記録媒体を用いることによりシステム間の情報交換を行うことを企図して作成されたものである。具体的には、CD-R メディアを使用し、DICOM で規定されている媒体による情報交換の規格を援用し、さらに相互接続性を高めるとともに、WEB コンテンツの扱いを定め、いわゆる見読性の機能を高める工夫をしているものである。 PDI のアクタとトランザクションの関係を図３．１．１－１３ PDI のアクタとトランザクションに示す。 Display Display Report Reader Report Reader Print Composer Print Composer Portable Media Importer Portable Media Importer Image Display Image Display Portable Media Creator Portable Media Creator

Distribute Imaging Information on Media

図３．１．１－１３ PDI のアクタとトランザクション

Portable Media Creator（略称 PMC）が、必要な情報を CD-R に書き込みメディアを作成し、そのCD-R を他のシステムで読み込んで利用するものである。読み込み側のアクタとしては、WEB データのみを表示する Display、DICOM 画像を表示する Image Display（略称 ID）、DICOM SR データを表示する Report

(21)

Reader（略称 RRD）、読み込んだ画像データの DICOM プリント行う Print Composer（略称 PC）、読み込んだデータを他のシステムにネットワーク経由で転送するPortable Media Importer（略称 PMI）、がある。

仏などでは、従来から診療情報の保管義務は患者側にあるため、X 線写真などは患者が持ち帰り管理していたが、検査機器がデジタル化されるにしたがい、検査データもデジタルデータのままCD-R などのデジタル記録媒体に書き出し、患者に持たせることになって来ている。DICOM の可搬媒体の規格などがあるが、従来はその解釈の違いなどにより、装置によっては他の装置でつくった CD-R が読めないなどの不具合が合ったため、IHE としてより厳密な仕様をまとめ相互接続性を高めた媒体交換を可能としている。我が国では、診療情報の保存義務は診療施設側にあるため、保存の観点での媒体の相互接続性の確保はそれほど重視されていない。しかしながら、我が国においても診療所と病院との連携が重要とされてきており、診療情報のやりとりは今後増大することこそあれ、減ることはないと考えられる。現状では、診療情報提供書の形で紙やX 線写真での診療情報の交換が行われているが、電子カルテの普及などにより電子的なデータでの診療情報の交換が必要になってくると考えられる。経済産業省や厚生労働省の実証実験事業としてネットワークベースの地域連携のプロジェクトが始まってはいるが、一般的な診療所・病院レベルでは安全に診療情報をやりとりできるようなネットワークの利用はまだ普及しておらず、当面はデジタルデータとしての診療情報の交換には、PDI で定めているようなCD-R などの標準的な可搬型媒体がまず使用されるものと考えられる。この PDI で採用されている技術仕様としては、DICOM の交換媒体の規格、 WEB でのコンテンツ形式などであり、非常に互換性の高いものを採用しており、前述のように仕様の解釈を厳密化しており、相互接続性についても高度なものが確保できると判断した。

(22)

３．１．２臨床検査部門３．１．２．１はじめに本件を検討・作成するワーキンググループは、放射線画像分野で成功を収めつつあるIHE-J 活動を、臨床検査（検体検査）分野に適用し、HL7 標準の医療情報システムへの更なる普及と実装上の問題解決を狙って、実質２００２年１０月、JAHIS（保健医療福祉情報システム工業会）臨床検査（院内）システム専門委員会がその任を受けて発足した。活動の目標は、実装ガイドラインとしての各種テクニカルフレームワークの確立である。さらに、２００３年１月からは、フランスを中心とした欧州も同じ活動をすることになり、当WG と協調して進めている。

尚、今回の事業においては、LDA（Laboratory Device Automation 検査自動化システム）テクニカルフレームワークの確立を実施した。

３．１．２．２活動経緯と成果

本事業以前の活動成果として、LSWF テクニカルフレームワークを完成させた。（LSWF：Laboratory Scheduled Workflow 臨床検査スケジュール済みワークフロー）

本事業活動成果として、LDA テクニカルフレームワークを完成させた。（LDA：Laboratory Device Automation 検査自動化システム）

表３．１．２－１活動経緯国際会議（Paris, France）日本チームからLDAの素案を提示。国際会議（Tokyo, Japan） LDA素案を審議・修正を実施。ミニシンポジウム開催日本臨床検査自動化学会「医療情報システム構築の新しい流れ-IHE活動を中心にして」と題して発表。医療情報学連合大会題目「IHEにおける臨床検査分野の標準化活動(現状と今後の展開)」を発表。国内メンバ活動 LDAテクニカルフレームワーク完成。欧米にパブリックコメントを募集。

(23)

表３．１．２－２成果物

国際活動の成果物 ① Laboratory Technical Framework Vol.1 : Integration Profiles

② Laboratory Technical Framework Vol.2 : Transactions Details 国内活動の成果物 ① 臨床検査テクニカルフレームワーク第１部：統合化プロファイル ② 臨床検査テクニカルフレームワーク第２部：トランザクション３．１．２．３統合プロファイルの構成と概略決定および予定しているプロファイルは、下記の５個である。図３．１．２－１統合プロファイルの構成（１）臨床検査スケジュール済みワークフロー（以下、LSWFという。）臨床部門と検査部門が通常行う入院・外来患者に対する検査業務のワークフローを扱う。これは今後論じるワークフロー/プロファイルの基本である。ここで、主に自動分析機器を用いた分析（測定）実行のプロセスは、分析結果を得るという点でブラックボックス化している。（２）検査自動化システム（以下､LDAという） LSWFの中にあって、そのブラックボックスを展開している。分析実行のプロセスにおける自動分析機器と上位システムとの間の処理フローを扱う。臨床検査スケジュール済みワークフロー

(Laboratory Scheduled Workflow) LSWF

検査自動化システム

(Laboratory Device Automation)

LDA

検査コードの更新

(Laboratory Code Set Distribution) LCSD

ポイントオブケア検査

(Laboratory Point of Care Testing) LPOCT

患者情報の整合性確保

(Laboratory Information Reconciliation) LIR

(24)

（３）患者情報の整合性確保（以下､LIRという）患者情報が不明な時の検体検査などで、患者情報の更新に関するワークフローを扱う。（４）ポイントオブケア検査（以下､LPOCTという。）手術室やベッドサイドで行われる検査のワークフローを扱う。ここで使う分析機器は監査部門（通常、臨床検査部門）により管理されているのが特徴である。緊急時の上位システムからの依頼伝達が無い検査では、検査依頼と結果の扱いがLSWF／LDAと一部重複する。さらに患者不詳の場合は、LIRとも関係する。（５）検査コードの更新（以下､LCSD）施設内で共通した検査コードを使うための更新フローを扱う。コードには個々の検査項目の他に、関連する複数の項目を集めた検査群（バッテリー）もある。３．１．２．４統合プロファイルの適用標準国際的検討でのテクニカルフレームワーク・LSWF 実装ガイドライン・LDA ← HL-7 Ver.2.5 ・LIR ・LPOCT → NCCLS ・LCSD 規約参照 ↓国内拡張国内版でのテクニカルフレームワーク実装ガイドライン JAIHIS ・LSWF ← 臨床検査データ交換規約・LDA → <オンライン版> 規約参照図３．１．２－２国際・国内テクニカルフレームワークの関係

(25)

LSWF、LDA、LIR、LCSD の技術文書であるテクニカルフレームワークは、データ交換に関する標準 HL7Ver2.5 の実装ガイドラインである。LPOCT は、 HL7 と NCCLS（POCT-A の改訂版）の双方または一方を予定している。国内へのIHE 適用では、LSWF＋LDA の拡張を予定しており、JAHIS 臨床検査データ交換規約 <オンライン版> がその参照すべき規約に予定している。 LIR、LPOCT、LCSD については、国際的検討の内容の全部または一部がそのまま適用できると予想され、拡張検討を予定していない。３．１．２．５技術文書（テクニカルフレームワーク）の構成 LDAテクニカルフレームワーク、下記の構成で作られている。第１部統合化プロファイル・概要、適用分野など・臨床検査スケジュール済み・ワークフローユースケース、アクタ／トランザクション、データモデル、プロセスフロー第２部トランザクション・トランザクション共通のメッセージ・セグメント・トランザクション毎のメッセージ構成とセグメント・適用例

(26)

３．１．２．６臨床検査スケジュール済みワークフロー（LSWF）本事業成果である、LDA テクニカルフレームワーク作成にと伴い、まず LDA は、LSWF 内の位置付けでもあり、LSWF について、まず記載する。（１）臨床検査スケジュール済み・ワークフローこのスケジュール済み・ワークフローは、検査部門を中心に、検査依頼と患者情報の一貫性の維持、検体と検査依頼との適合性の管理、および検証の多様な各ステップにおいての結果送信などのトランザクションをアクタとともに関連付ける。当プロファイルは臨床検査部門での、分析前、分析および分析後の工程の自動化を可能にする。図３．１．２－３ LSWF のアクタとトランザクションこのプロファイルでは、オートメーションマネージャと分析装置などの装置間のトランザクションを規定していない。（オートメーションマネージャは分析工程に使われる全ての自動化装置をグループ化するアクタである。）一般に臨床検査部門には、オーダ実施者とオートメーションマネージャが属する。患者管理 (ADT) → RAD12：患者更新 → RAD1：患者登録 ↓ RAD1：患者登録 ↓ RAD12：患者更新 ← RAD1：患者登録 ← RAD12：患者更新 → LAB1：依頼者オーダ管理 ← LAB2：実施者オーダ管理 ← LAB3：オーダ結果管理

臨

床

検

査

部

門

オートメーションマネージャ (Automation Manager) ↓ LAB4：検査オーダ管理 ↑ LAB5：検査結果管理オーダ依頼者 (Order Placer) オーダリザルトトラッカ

(Order Result Tracker)

オーダ実施者

(27)

（２）LSWF のアクタ１）患者管理（ADT）入院、退院、転院および外来による患者登録と患者情報の維持を行う。このアクタは患者名や関連情報の追加および更新を行い、この情報をオーダ依頼者、オーダ実施者、オーダ・リザルト・トラッカへ送信する。これはラジオロジ・テクニカルフレームワークおよびIT インフラストラクチャ・テクニカルフレームワークで提起されているアクタと同じである。２）オーダ依頼者（Order Placer）様々な診断や治療行為のために検査を依頼する。このアクタは検査依頼を適切なオーダ実施者（検査部門）へ配信し、依頼の状態変化を管理し、検査結果を照会する。あるケースでは、オーダ依頼者が検体採取（採血、採尿）および検体識別手段の付与（検体 ID の発行）を行う場合がある。そこでは、オーダ依頼者とオーダ実施者間のトランザクションは、検体に関連する情報も取り扱う。３）オーダ実施者（Order Filler）オーダ依頼者から検査依頼を受信し、該当する検体を識別可能（検体 ID の付与）にして採取する。分析の実施をスケジュールし、その実施依頼（実施オーダ）をオートメーションマネージャへ送信する。オートメーションマネージャから分析結果を受け取り、オーダ・リザルト・トラッカへ検査結果を送信する。ここでは検査結果について臨床的な検証を行うことが望まれている。オーダ依頼者側で検体を採取し識別 ID を付与するケースでは、このアクタは検査実施のスケジューリングが主業務になる。４）オートメーションマネージャ（Automation Manager）臨床検査室内での分析（測定）の自動化を行うシステムおよび構成機器を指す。自動化は、分析装置の他に、ロボット搬送システム、分析前処理装置（遠心分離機、分注機、開栓機、分類装置、ラベラーなど）、分析後処理装置（閉栓機、検体収納、検索システムなど）で構成され、統合管理する臨床検査自動化システム（LAS=Laboratory Automation System）も含まれる。

このアクタはオーダ実施者から分析の実施依頼（実施オーダ）を受け、依頼された検査を適切な機器で行い、技術的に検証された結果をオーダ実施者へ返信する。実際の検査室では、自動化システム（LAS）を有せず、LIS が１台または数台の分析装置と直接オンライン接続しているかもしれない。この場合、LIS はオーダ実施者とともにこのアクタも含んでいる。他方、検査室の中に複数のオートメーションマネージャが存在し、其々の専門分野での検査を担当しているかもしれない（例えば、生化学と免疫学、一般項

(28)

目と特殊項目）。

５）オーダ・リザルト・トラッカ（Order Result Tracker）

オーダ実施者から受信した検査結果を患者単位に登録、蓄積、保存する。このアクタは分析機器単体の検査単位で保存するのではなく、検査依頼毎の検査結果全体を保存する。臨床的に有用な形でデータ管理するのであれば、検体検査結果の他に、放射線検査レポート（画像）、病理学レポート、治療記録なども併せて持つだろう。実世界では、病院のオーダリングシステム、あるいは臨床医の端末システムのデータ蓄積、出力機能が相当する。（３）LSWF トランザクション ADT の“患者登録［RAD-1］”、“患者更新［RAD-12］”のトランザクションは、Radiology のスケジュール済み・ワークフローで既に明記されており、この２つのトランザクションを修正なく使用する。臨床検査分野のワークフローでは、LAB-1 から LAB-5 と番号付けされた５つのトランザクションを新しく割り当てている。１）LAB-1: 依頼者オーダ管理検査依頼の進行管理のため、オーダ依頼者とオーダ実施者間で必要な全てのメッセージを含むトランザクション。オーダ依頼者とオーダ実施者の間で、依頼について同じ状況（ステータス）が保たれる。２）LAB-2：実施者オーダ管理新規の実施者オーダ（オーダ実施者での管理される検査依頼）を通知するため、およびそれを反映した依頼者オーダ（オーダ依頼者で管理されている検査依頼）を更新するために、オーダ依頼者とオーダ実施者間で必要な全てのメッセージを含むトランザクション。オーダ依頼者とオーダ実施者の間で、同じ実施者オーダ番号（オーダ実施者での管理番号）と依頼者オーダ番号（オーダ依頼者での管理番号）が保たれる。３）LAB-3 オーダ結果管理オーダ実施者からオーダ・リザルト・トラッカへ検査結果や依頼状況の変更（例：訂正、キャンセル）を通知するトランザクション。４）LAB-4：検査実施依頼検査依頼の全てまたはその一部を含む分析の実施依頼を行うため、オーダ実施者とオートメーションマネージャの間で必要な全てのメッセージを含むトランザクション。オートメーションマネージャへの実施割り当てや、そのアクタに患者情報や依頼更新を通知する。このトランザクションの伝送形態は、オーダ実施者からオートメーションマネージャに検査内容（実施オーダ）をダウン

(29)

ロードする「プッシュ型」に基づいており、オートメーションマネージャがオーダ施者に検査内容（実施オーダ）を問い合せる「クエリー型」は使われない。５）LAB-5：検査結果通知オートメーションマネージャからオーダ実施者へ技術的に検証された検査結果を伝えるトランザクション。オーダ実施者は、ひとつの検査依頼（依頼者オーダ）の全ての検査結果を受信すると、オーダ依頼者へオーダ完了（ステータス）を通知する。オートメーションマネージャに検体が到着したことの通知も含む。 LIS（臨床検査システム）がオーダ実施者とオートメーションマネージャ双方のアクタの機能をサポートしている場合、トランザクション LAB-4 と LAB-5 はシステム間の通信に現れない。これらのトランザクションは、検査部門にオーダ実施者とオートメーションマネージャのシステムが別々にある時、実装される。３．１．２．７検査自動化システム（LDA）前述のLSWF では、オートメーションマネージャと名づけられたアクタは「オーダ実施者から実施依頼を受けて、分析装置などの自動化機器を使用して分析結果を得て返送する」機能を持つユニットの代表であった。そこでは、分析実行を管理・監督するコントローラと分析などを実行する自動化機器の間でのワークフローを述べていない。LDA はそのユニットについて、ワークフローと必要なアクタ、トランザクションを明らかにする。つまり、LDA は LSWF が示す「オートメーションマネージャ」の内部を展開したプロファイルで、LSWF のサブセットである。当プロファイルは検体検査部門での一連の工程の自動化を可能にする。（１）実在のシステムとの関係 IHE のアクタとトランザクションは、実際の医療情報システム環境を抽象化したものである。アクタ“オートメーションマネージャ（Automation Manager）”は、臨床情報システム（Clinical Information System）、LIS（臨床検査システム）、LAS（臨床検査自動化システム）に相当するが、LDA テクニカルフレームワークでは意図的に、特定の製品カテゴリと関連付けないようにしている（LDA Technical Framework intentionally avoids associating this actor with specific product categories.）。オートメーションマネージャはオーダ実施者（Order Filler）と共に LIS（臨床検査システム）を構成するかもしれない。大規模で複雑な保健医

(30)

療機関では、複数の検査部門（unit）が階層的に構築されるかもしれない。この場合、オートメーションマネージャが複数、階層的に存在するとみることができる。アクタ“Analyzer”は、分析機そのものである。分析機は異なるタイプの検査ユニットを複数持つ複合機かもしれない（例えば、生化学と免疫学）。LDA テクニカルフレームワークでは、分析機の専門分野や単能機か複合機かなどの一切を問わない。 “Pre/Post-Processor”は、検査の前処理、後処理を行う機器共通のアクタをして定義する。大別すると、分注機/仕分け機（aliquotter/sorter）などの分析前処理装置（pre-analytic process equipment）と、検体保存などの分析後処理装置（post-analytic process equipment）から成る。ロボット搬送システム（robotic transportation system）やコンベア（conveyer）もそれぞれに含まれる。検体を仕分け流通させる点で、これらは同じ性質を持っており、本質的にひとつのアクタで定義できる。LDA テクニカルフレームワークでは、工程をわかり易くするためにふたつのアクタ名を設けたが、トランザクションは一通りである。実際のシステムではこれらの全部または一部が存在しなくてもよい。 “分析機 Analyzer”、“分析前処理・分析後処理装置 Pre/Post-processor”の２アクタをまとめて”LD（Laboratory Device）”のアクタと総称する。以上の様に LDA で定義するアクタは実在の製品に近い印象を持つが、実装する製品の完全なる定義と捉えてはならない。（２）適用範囲 LDA テクニカルフレームワークは、保健医療機関の検体検査部門についてのワークフローを説明する基本的に、検体検査部門は臨床担当部署あるいは医師から患者に関する検査実行の依頼をアクタ“オーダ実施者”を通して受ける。検査は患者から採取済みの検体で行われる。通常は依頼を受けた後に分析すべき検体が届くが、検体が依頼の前に届く場合もある。いずれでも分析機が検体を測定するには、分析依頼（=実施オーダ work order）を受けなければならない。電気通信を介したオーダ受信でなくても、他の手段で分析機に依頼が入力されれば良い。これは POCT（Point Of Care Testing）に似ているが､依頼情報が事前に準備される点で POCT とは異なる。

メッセージのやりとりのために、検体容器の識別は必須。分注機が子検体（aliquot）を作る時に、ラベルを新規発行する場合があるが、ラベル発行工程の具体的な詳細はこのフレームワークの適用範囲外である。

(31)

依頼を受入または却下する検体検査部門の能力を包括する。依頼の変更は実質的に無い。コード・セットと複数のアクタによって共有されている関連ルールのやりとりは、このプロファイルの適用範囲を超えている。通常、LD のアクタは laboratory 共通のコード・セットを受け取ることをしない。検査結果のトラッキングのため、技術的な検証の前の分析結果を保存することが必要な場合がある。これを LD のレベルでやるか、オートメーションマネージャで保存するかは、検査を実施する機関の方針に依る。その取り決めや方法は、このフレームワークの適用範囲外である。 HL7 13 章は自動化装置（automated instrument）の運転自動化に関するメッセージとセグメントを規定している。しかし、このフレームワークはこれらを扱わない。当該プロファイルは、検体の分析検査そのものを扱い、運転制御に関する内容は対象外である。唯一の例外は、分析前後処理での検体容器の搬送に関する指示である。これは、検査項目が分析前処理に関係し、再検査が分析後処理に関係するからである。（３）LDA のアクタ１）オーダ実施者（Order Filler）：３．１．２．６ LSWF の項を参照。２）オートメーションマネージャ（Automation Manager）前節LSWF で定義済みであるが、LDA では自動化システムを実行管理・監督する機能を指す。尚､LIS（臨床検査システム）がオーダ実施者とオートメーションマネージャの両方のアクタ機能をサポートしている場合がある。これらのアクタを分けて考慮せねばならない場合とは、LAS（臨床検査自動化システム）のようなオートメーションマネージャに相当する機能を有する装置があるときと、検査実施部門別に複数のオートメーションマネージャがあるときである。３）分析機（Analyzer）依頼された検査項目を分析する分析機器。このアクタはひとつのオートメーションマネージャから実施オーダ（work orders）を受ける。依頼された検査を処理し、自動的に分析結果をオートメーションマネージャへ返信する。実施オーダの受付はオンラインだけでなく、manual entry で為されるかもしれない。依頼された分析の他に、分析結果の正確度を維持、管理するためにキャリブレーションや精度管理などの測定も行う。４）分析前処理装置（Pre-Processor）、分析後処理装置（Post-Processor）検体の分析の前処理及び後処理工程を行う装置。大きく、分析前処理装置（Pre-processor）と分析後処理装置（Post-processor）に大別される。

(32)

分析前処理装置：採取された検体を分析可能な状態にする装置、または分析可能な場所に搬送する装置。前者では、自動遠心分離機、開栓機、分注機、希釈装置が該当する。後者では分類装置、搬送ロボット/コンベアが該当する。このアクタはひとつのオートメーションマネージャから実施オーダ（work orders）を受ける。依頼された指示に従って検体を処理し、自動的に処理結果をオートメーションマネージャへ返信する。当然ながら、このフレームワークはオートメーションマネージャとオンライン接続されていない分析前処理装置には適用されない。特に開栓機､搬送ロボット/コンベアではプリセットされたルールに基いて自律的に検体を処理することが多い。分析後処理装置：分析済み検体を再分析可能な状態に置いたり、廃棄可能な状態にする装置、またはこれらの装置に搬送する装置。前者では、検体収納、検索システムが該当する。後者では搬送ロボット/コンベアが該当する。このアクタはひとつのオートメーションマネージャからステップオーダ（work orders）を受ける。依頼された指示に従って検体を処理し、自動的に処理結果をオートメーションマネージャへ返信する。特に重要なステップオーダは、再検査のために検体を分析機に再投入する指示である。当然ながら、このフレームワークはオートメーションマネージャとオンライン接続されていない分析後処理装置には適用されない。このことは分析前処理装置と同様である。（４）アクタの接続構成

OF（Order Filler） – AM（Automation Manager） – LD の接続について、以下の構成が考えられる。図３．１．２－４ OF – AM – LD の接続 OF AM LD LD AM LD LD OF AM LD LD LD AM LD LD OF AM LD LD LD LD 単純な垂直構成階層的な構成交錯した(complicated)構成 LDAM