第10節 標準規格

IHEとは

IHE = “I"ntegrating “H"ealthcare “E"nterprise のこと。

医療情報システムの相互接続性を推進する国際的なプロジェクトです。

つまり、医療のワークフローと通信規格の使い方を決める団体のことです。

・IHE International - IHE NA( USA & Canada ) - IHE EU - IHE China - IHE Japan

1999年北米放射線学会（RSNA）と医療情報管理システム協会（HIMSS）が中心となって始められたDICOMとHL7という既存の医療通信規格を使用して、病院内の医療情報システムを統一的に運用するためのガイドライン作成と普及を目指す運動のことです。

医療通信規格

これらの医療通信規格は、どこに何の値を設定するか？は決まっていますが、 ・いつ ・どこで ・どの機器が ・どんな情報を ・どの規格で送るのか？ は定義していません。 患者情報をDICOMで送るのか、HL7で送るのか？は決まっていないため、

・A社の医事システムは患者情報をDICOMで送るけど、B社のカルテは患者情報をHL7で受信する。 となってしまうと、A社とB社は思ったように医療機器やシステムが接続できず、情報を円滑に利用できなくなります。

既存にある規格を使って、 ・いつ ・どこで ・どの機器が ・どんな情報を ・どの規格で送るのか？ を決めるのがIHEです。 例えば ・医事に患者が新規登録されたら、 ・医事から電子カルテに ・患者情報を ・HL7規格のADTというメッセージで送る と決めておき、A社もB社もこれに準拠していれば、A社とB社のシステムを買っても現場で困りません。 メリット 病院さん：マルチベンダーでシステムを作る事ができ、対応している好きなシステムを使う事ができる ベンダー：商売のチャンスが広がる

DICOMについて

DICOMとは

DICOMはDigital Imaging and Communications in Medicineの頭文字で、「ダイコム」と読みます。

DICOM（ダイコム） 医療画像を中心とする通信規格 画像や数値をやり取りする デメリット・・・バイナリ(2進数)なので人が見てもわかりにくい

CT・MRI・内視鏡・超音波などの医用画像診断装置、医用画像プリンタ、医用画像システム、医療情報システムなどの間でデジタル画像データや関連する診療データを通信したり、保存したりする方法を定めた国際標準規格です。

DICOM規格では、医用画像ネットワークで必要となるさまざまな機能をサービスと呼んでいます。

サービスは

・「画像受送信」

・「画像プリント」

・「画像検索」

などの分野ごとにまとめられています。

DICOMは広範囲にわたって規格が定められているため、「DICOM対応」を主張する場合、DICOMのさまざまな機能のうちどの部分に対応できるのか、製造者はそのサポート範囲について明確に宣言するよう求められています。

これを「コンフォーマンス・ステートメント（適合性宣言）」といい、接続に必要となる各種の技術情報が記述されています。このコンフォーマンス・ステートメントを交換することによって、機器の接続に関してメーカー間で仕様を確認したり、ユーザーが性能比較や機器同士の互換性確認をすることができます。

機器間通信のイメージ

サービスクラスの種類

●Basic Worklist Management Service Class

作業リストを取得する機能

●Modality Performed Procedure Step Service Class

検査作業結果をHIS/RISに送る機能

●Modality Worklist Management Service Class

検査情報を取得する機能

●Patient Management Service Class

外来・入退院・人口統計などに関する情報を扱う機能

●Print Management Service Class

診断装置からイメージャなどに画像を出力する機能

●Query/Retrieve Service Class

画像データなどの問い合わせ・検索、取得をする機能

●Results Management Service Class

検査結果に関する情報を管理する機能

●Storage Commitment Service Class

画像データなどの保管状況を知らせる機能

●Storage Service Class

装置間で画像データなどを送受信する機能

●Study Management Service Class

画像検査の生成、スケジューリング、実行、追跡をする機能

●Study Content Notification Service Class

検査内容や画像の格納先を知らせる機能

●Verification Service Class

DICOM接続できるかどうかの確認をする機能

上記のすべてのサービスクラスには、サービスを提供する側と、サービスを利用する側の2つがあります。

前者をSCP（Service Class Provider）、

後者をSCU（Service Class User）といいます。

また、上記のサービスクラスのうち、特によく利用されるのは次のサービスクラスです。

・Modality Performed Procedure Step Service Class(検査作業結果をHIS/RISに送る機能)

・Modality Worklist Management Service Class(検査情報を取得する機能)

・Print Management Service Class(診断装置からイメージャなどに画像を出力する機能)

・Query/Retrieve Service Class(画像データなどの問い合わせ・検索、取得をする機能)

・Storage Service Class(装置間で画像データなどを送受信する機能)

・Verification Service Class(DICOM接続できるかどうかの確認をする機能)

SCPとは(送る側)

Service Class Provider［サービス・クラス・プロバイダ］の略。 DICOMのサービスを提供する側の呼び方。

DICOM仕様中のクラスという用語は、C++や、Java言語中のクラスと違って、機能やプロトコルの分類を意味します。 サービスクラスプロバイダは、操作の実行および通知の発行を行うDICOMアプリケーション実体を指します。 一般のクライアント・サーバシステム中のサーバに相当します。

SCUとは(受け取る側)

SCU ［エス・シー・ユー］ Service Class User［サービス・クラス・ユーザ］の略。 DICOMのサービスを利用する（要求する）側の呼び方。

サービスクラスユーザは、操作の発行および通知の実行を行うDICOMアプリケーション実体を指します。 一般のクライアント・サーバシステム中のクライアントに相当します。

アソシエーションとは

Association Negotiation ［アソシエーション・ネゴシエーション］

AE 同士が取り交わす DICOM通信の最初のフェーズ。

要求するサービスの種別や符号化方法等に関する折衝を Association Negotiation （アソシエーション折衝）と呼び、 折衝の成立を Association Establishment （アソシエーション確立）といいます。 この折衝の成立により「DICOM通信路」が確立され、以降、AE間で データのやり取りが可能になります。 一連のデータ通信の最後には、 Association Release （アソシエーション解放） により、通信路を解放します。

電文構造概略

DICOMファイルの正式なファイル名の形式は以下のとおりである。

●半角大文字および数字

●最大８文字

●拡張子は存在しない

しかし、DICOMファイルのファイル名規則は、MS-DOSのファイル名規則（8文字+拡張子3文字）よりも厳しい内容であるため、運用性が非常に悪く、このルールは無視されていることが多い。そのため、ファイル名の文字数も８文字以上で拡張子には「.dcm」などが用いられるのが一般的となっています。

.dcm拡張子については米国の政府機関であるIANAおよびRFC 3240において「application/dicom」というMIME TYPEが割り振られており、事実上のデファクトスタンダードとなっています。

ただしこれはDICOMの正式な決まりではないので稀に「.dicom」などとしている製品やファイル名は８文字以上で小文字や記号も含まれるが拡張子なしなど、様々な形式を採用している製品も見受けられるため、DICOM対応製品の開発に際してはこれらを受け入れる柔軟性が重要となります。

■通信の概要

• PDU……プロトコルデータユニット。通信において1回に送ったり受け取ったりする単位。HTTPで言えば、リクエスト全体がひとつのPDU、それに対する応答全体が１つのPDU。
• ビッグエンディアン。
• 長さの数値は符号なし。

●PDUの種類

• A-ASSOCIATE-RQ …… Request
• A-ASSOCIATE-AC …… Acknowledge
• A-ASSOCIATE-RJ …… Reject
• P-DATA-TF
• A-RELEASE-RQ …… Request
• A-RELEASE-RP …… Response
• A-ABORT

●A-ASSOCIATE

通信路（アソシエイション）の確立のためのやり取り。クライアント側から通信路確立要求を出し、サーバ側がそれ を承認もしくは拒絶する。

●A-RELEASE

通信路（アソシエイション）開放のためのやり取り。クライアント側から通信路の開放を要求し、サーバ側がそれに応答する。

●A-BORT

通信路の異常開放。クライアント側から一方的に通信の中断を通知する。

●P-DATE

確立された通信路上での「DICOMメッセージ交換」に使用する。

●クライアント側からみた実際の流れ

1. 指定のTCPポートに接続
2. A-ASSOCIATE-RQの送信
3. A-ASSOCIATE-ACもしくはA-ASSOCIATE-RJの受信。後者ならexit
4. P-DATA-TFによるDICOMメッセージ交換
5. A-RELEASE-RQの送信
6. A-RELEASE-RPの受信
7. TCPセッションクローズ

■A-ASSOCIATE-RQ、A-ASSOCIATE-AC共通

■A-ASSOCIATE-RQ

可変アイテムには以下のすべてを含む。

• １つのアプリケーションコンテキスト
• １つ以上のプレゼンテーションコンテキスト
• １つのユーザー情報

●アプリケーションコンテキスト

A-ASSOCIATE-RQと異なりサブアイテムとして転送構文のみ持つことに注意してください。

A-ASSOCIATE-RQにプレゼンテーションコンテキストが複数存在した場合は、それぞれ個別のコンテキスト（抽象構文＝操作指示および転送構文）についての「許可、不許可」を個別に応答します。応答しないものがある場合、不許可とみなされるようですが、リクエストにあったすべてのプレゼンテーションコンテキストについて応答するほうが望ましいと言えます。

またあるメッセージIDで非対応の転送構文が指定されたときは、対応している転送構文に書き換えてACを返信してあげれば、その形式で送ってくるようです。

■A-ASSOCIATE-RJ

■P-DATE-TF

●プレゼンテーションデータアイテム

コンテキストIDは「A-ASSOCIATE」によりネゴシエーションされたコンテキストIDを示します。これにより、どんな操作か（抽象構文）、どの形式で転送するか（転送構文）を示しています。

■A-RELEASE－RQ

■A-RELEASE－RP

■A-ABOAT

■PDV、DIMSEメッセージ

P-DATAによりやりとりされる実体がDIMSEメッセージです。

プレゼンテーションアイテム（PDV）が１つであるとき、P-DATA PDUは次のようになります。

PDVは「コマンド集合」もしくは「データ集合」のどちらかです。両方同時に持つことは許されず、ひとつのPDUは必ずどちらかのPDVを持ちます。これを示すのがデータヘッダです。（PS 3.8付属書Eより）

• Headerのbit 0
  • 1 : 続くフラグメントがコマンドである
  • 0 : 続くフラグメントがデータである
• Headerのbit 1
  • 1 : このPDV中に最後の要素を含む
  • 0 : このPDV中に最後の要素を含まない

Headerのbit 1が0の場合、続いて送られてくるP-DATAの中のPDVが後ろに続いているとみなして処理します。例えば、256byteの大きさを持つPDV中のとある要素が512byteのサイズをもつ場合、1つめのPDVからあふれた分のサイズは続いてのPDVから読み込みます。

• P-DATA PDU #1
  • PDUヘッダ
  • PDVヘッダ = 0
  • PDV (256byte)
    • 要素X ヘッダ8byte(データ長さ120) + データ120byte
    • 要素Y ヘッダ8byte(データ長さ240) + データの先頭120byte
• P-DATA PDU #2
  • PDUヘッダ
  • PDVヘッダ = 2
  • PDV (256byte以下)
    • 要素Y データの後半120byte
    • 要素Z ヘッダ8byte + データ

要素ヘッダの途中で複数のP-DATA PDUに分割されることも考えられるため、柔軟な実装が必要になります。

●コマンド要素、データ要素の形式

コマンド集合やデータ集合はそれぞれ、複数の「コマンド要素」や「データ要素」から構成されます。要素はそれぞれ独自のタグ（4byte）を持ち、各要素にはVRと呼ばれるデータ形式が予め決められています。

これまでと異なり、各要素中の値（数値）はリトルエンディアンで表現されます。A-ASSOCIATE-RQによって「暗黙VRリトルエンディアン転送構文（1.2.840.10008.1.2）」を指定しているためです。

●VRの形式(一部抜粋)

VRに対応する値の形式はPS 3.5の6.2で定義されています。サイズはすべて偶数である（偶数でなければならない）。

●シーケンス要素の特殊処理

DICOM通信においてデータを取得する際、シーケンスを適切に処理する必要があります。 要するに一つの項目に複数のデータが列挙された形式です。 （VR非明示リトルエンディアン転送では）シーケンスデータのアイテムは、「正しい長さ」か「FFFFFFFFhの長さ」を持ちます。後者は長さが未定義であることを示します。鵜呑みにして処理するとその後のアイテムがパースできず痛い目を見ます。 シーケンスデータは「FEFFE000h」で始まり「FFFEE0DDh 00000000h」で終わります。 ただしシーケンスデータの中身か空の場合は、シーケンスデータの始まりはなく単に「FFFEE0DDh 00000000h」で終わります。この部分（シーケンス区切りに挟まれた中身）を切り出して上げれば良いわけです。

シーケンスとして登録されているVRをすべて処理プログラム側で持つのが本来の正しい処理かもしれませんが、そうも言ってられないので、次の方法で処理をしました。

● シーケンスデータの長さが「FFFFFFFFh」でなければ通常のとおり処理する。

● データ長さが「FFFFFFFFh」でデータの先頭が「FEh FFh」で始まるデータをシーケンスデータとみなす。

● シーケンスデータの終わりは単純に8byteの文字列マッチングで「FEh FFh DDh E0h

00h 00h 00h 00h」の手前までを切り出す

（追記）シーケンスは確認した限り1階層の入れ子になることがあります。その場合「FFFFFFFFh FEFFE000h」～「FFFEE0DDh 00000000h」の最小単位（最短マッチ）を認識して、入れ子構造を保って切り出さないと、dcmj2pnmなどのコマンドで弾かれることがあります。

Strage-SCP/SCUを例にした電文構造

HL7について

HL7とは

ヘルス・レベル・セブン(Health Level 7)

・HL7 テキスト形式の通信規格 患者情報やオーダー情報をやり取りする ＞人が目で見てなんとなくわかる

■組織としての名前：HL7.inc

●HL7規格を開発し、改良する組織 ●1987年に米国で発足 ●ユーザとベンダーで構成される非営利団体 ●約30カ国の国際支部、約2200人の会員 ●ANSI公認のSDO(規格制定団体)

■規格としての名前

●医療情報を表現し交換するための規格 ●2001年改定声明：医療情報の包括的枠組みに関する標準 ●三つの話題： メッセージ、永続的オブジェクト、連携機能

■メッセージ

システム間での情報交換するためのメッセージ形式

■永続的オブジェクト（Persistent Object）

通信終了時に消えるメッセージに対する“永続性” HL7の医療情報表現に対するアプローチ

■連携機能

システム構築のための機能的な技術仕様 アプリケーション間での情報の同期の仕組み

■V2.x の流れ

●1994 V2.2 ヘルスケア分野初のANSI化 ●1999 V2.3.1 米国で普及が進んでいる版 ●2003 V2.5 ISO化

■V3の流れ

●1996 検討組織が発足 ●1997 RIM 案開発 ●まだ規格制定にまで至っていない

■V2x の課題

●対象分野ごとのバラツキ ●開発手法がない ・・・ 職人技の世界 ●解釈の違いを生みやすい ・・・ 相互運用性の低下

■V2.xの課題解決のためのV3

●全ての医療情報を表現する参照情報モデル（RIM) ●開発手法の定義（HDF)：図で表記、ツール整備 ●実装の再利用性とコスト削減(作る人と使う人の分離) ●但し、まだ完成していない

・・・よって当面、V2.xはメッセージ、V3は診療記録(RIM,CDA)

現段階では

V2.5はメッセージに！ V3の開発成果の一部が活用され始めている

RIM

●CDA: Clinical Document Architecture 診療情報の表現の仕様、XML形式

●CCOW: Clinical Context Workgroup Visual Integration の実装方式

●Arden Syntax 診断論理の記述方法

電文種別とイベントタイプについて

イベントタイプ(一例)

電文構造概略

電文構造の構成 は主に以下の４つです。

●メッセージ

■メッセージ セグメントの集まり ■セグメント フィールドの集まり ■フィールド フィールド成分の集まり

・ORMメッセージ ：検査依頼に関するメッセージ ・MSHセグメント ：メッセージID、送信日時、文字コードなどのフィールド ・PIDセグメント ：患者ID、患者名、生年月日などのフィールド ・PV1セグメント ：主治医、入院外来などのフィールド ・ORCセグメント ：依頼検査の情報などのフィールド

■フィールド成分

PV1-3 患者所在場所(PL) （PV1セグメントの3番目のフィールド)

●Components:<point of care 病棟・診療科・診察室など(IS)>

^<room病室(IS)>＾<bed病床(IS)>^<facility施設(HD)>

^<location status状態(IS)>^<person location type区分(IS)>

^<building建物(IS)>^<floor階(IS)>

^<location description詳細(ST)>

ADTを例にした電文構造

例２

MSH|^~¥&|ADT1|MCM|LABADT|MCM|198808181126|SECURITY|ADT ^A01|MSG00001|P|2.3| EVN|A01|198808181123|| PID|||PATID1234^5^M11||JONES^WILLIAM^A^III||19610615|M ||C|1200 N ELM STREET^^GREENSBORO^NC^27401- 1020|GL|(919)379-1212|(919)271-3434||S|| PATID12345001^2^M10|123456789|987654^NC| NK1|JONES^BARBARA^K|WIFE||||||NK^NEXT OF KIN PV1|1|I|2000^2012^01||||004777^LEBAUER^SIDNEY^J.|||SUR ||||ADM|A0|

http://www.hl7.jp/docs/seminar/SeminarNo7Kawamata.pdf