IHE-Jベンダワークショップ2006

IHE-Jコネクタソン（SWF/PIR HL7関係）

2006年11月20日
HIS-RISメッセージ交換標準化WG
藤田 由昭（富士通株式会社）

JAHIS 放射線データ交換規約 Ver2.0

IHE-Jベンダワークショップ2006

IHE-J 2006 コネクタソンは、「JAHIS 放射線データ交換規約 Ver2.0」を採用

概要
IHE-J の Technical Framework （National Extension)のベースになった「JAHIS放射線データ交換規約 Ver.1.1」をHL7(Ver2.5)に完全準拠させると共に、対象範囲として、従来のHIS-RIS間のメッセージの標準化に加え、RIS-PACS/Report間のメッセージおよび、これまでスコープ外にしていた実施情報（会計情報）のメッセージの標準化についても検討し、今後の普及を促進させるべく「放射線データ交換規約 Ver.2.0」を策定した。
～ 詳細は、JAHISホームページにて標準原案として公開 ～2

対象となるアクターとトランザクション（１）患者情報通知 （PIRのみ）

ADT

ADT
ACKOrderPlacer/Order
Filler（３）患者到着確認通知

ORU

ADT

Image
ManagerACK（２）放射線検査依頼通知

OMG

Order
PlacerORG

OrderFiller

ACK

Order
Placer（４）放射線検査結果通知

OMI

Order
Filler

IHE-Jベンダワークショップ2006

OMI

Image
Manager
ORI

Order
Filler

ORI

Order
Placer3

テストシナリオ（概要/SWF）
IHEJ-SWF-OPOF

IHE-Jベンダワークショップ2006

5パターン実施 OPから新規に放射線検査依頼情報をOFへ送信
OFから上記に対する応答メッセージをOPへ送信 OFから新規の放射線検査依頼情報をIMへ送信
IMから上記に対する応答メッセージをOFへ送信 OPから修正した放射線検査依頼情報をOFへ送信
OFから上記に対する応答メッセージをOPへ送信 OFから修正された放射線検査依頼情報をIMへ送信
IMから上記に対する応答メッセージをOFへ送信 OFから患者到着確認情報をOPへ送信
OPから上記に対する応答メッセージをOFへ送信 OFから放射線検査実施情報をOPへ送信
OPから上記に対する応答メッセージをOFへ送信

OFにOPの情報が正しく反映しているか？

IMにOFの情報が正しく反映しているか？

OFにOPの情報が正しく反映しているか？

IMにOFの情報が正しく反映しているか？

OPにOFの情報が正しく反映しているか？

OPにOFの情報が正しく反映しているか？

4

テストシナリオ（概要/PIR）IHEJ-PIR-ADTOPOF

IHE-Jベンダワークショップ2006

OP,OFにADTの情報が正しく反映しているか？

 ADTから救急患者用IDの患者情報をOP,OFへ送信
OP,OFから上記に対する応答メッセージをADTへ送信 OFから緊急患者用IDの患者情報をIMへ送信
IMから上記に対する応答メッセージをOFへ送信（以降は、SWFと同じ） 2パターン実施

IMにOFの情報が正しく反映しているか？

OP,OFにADTの情報が正しく反映しているか？

 患者到着前あるいは検査完了時に、ADTから当該患者の変更情報をOP,OFへ送信
OP,OFから上記に対する応答メッセージをADTへ送信 患者到着前あるいは検査完了時に、OFから当該患者の変更情報をIMへ送信
OFにOPの情報がIMから上記に対する応答メッセージをOFへ送信
正しく反映しているか？
5

テストデータ（検査項目）

IHE-Jベンダワークショップ2006

検査項目は、JJ1017（Ver3.0）を採用
http://www.jira-net.or.jp/commission/system/index.html

 Ｘ線単純撮影
胸部立位正面（P→A）、腹部仰臥位正面（A→P）、頭部正面（A→P）、右手部正面
 Ｘ線透視造影検査腹部、造影検査胸部
 Ｘ線ＣＴ検査
頭部仰臥位、造影胸部
 ＭＲＩ検査
頚椎仰臥位（1H）、骨盤仰臥位（1H）
 経皮的超音波検査
甲状腺、心臓、腹部、両腎臓、胎児、両乳房
6

テストデータ（検査項目）

IHE-Jベンダワークショップ2006

7テストデータ（患者プロファイル）

IHE-Jベンダワークショップ2006

患者プロファイルの値は以下を採用
 身長、体重（OBX-3、OBR-5） ※JAHIS放射線データ交換規約参照
身長（01-01、値）、体重（01-02、値）
 歩行状態（OBR-30）※JAHIS放射線データ交換規約参照
独歩（WALK）、車椅子（WHLC）、ストレッチャー（CART）、ポータブル（PORT）
 患者状態（OBX-3、OBR-5）
聴力障害あり（PAST、XPAST001）、言語障害あり（PAST、XPAST002）、視力障害あり（PAST、XPAST003）、運動障害あり（PAST、XPAST004）、意識障害あり（PAST、XPAST005）
 読影依頼（OBX-3、OBR-5）
通常（READ、XREAD001）、なし（READ、XREAD002）、緊急（READ、XREAD003）

8

テストデータ（実施情報）

IHE-Jベンダワークショップ2006

放射線検査結果通知には、医事会計に必要な実施情報を含む
実施情報として、使用したフィルム、薬品、器材等の情報が正しく通知されることを確認する。（ZE1-8、ZE1-9）※JAHIS放射線データ交換規約 Ver.2.0 参照
フィルム（DE-01、値）、薬品（DE-02、値）、器材（DE-03、値）、・・・→ テストデータは、後日提示予定

9

HL7メッセージ確認項目IHE-Jベンダワークショップ2006

 EVNセグメント使用しない。

 OMGメッセージ、OMIメッセージのPV1セグメントについてPV1-2でオーダ時の入外区分を示すため、必須。

 OMGメッセージ、OMIメッセージのTQ1セグメントについてTQ1-9で要求の優先度を示すため、必須。デフォルトは‘R’。

 MLLPは不採用
HL7の実装例(Minimum lower layer Protocol)としてMSHの前に開始ブロック制御文字を付加する例が示されている。しかしながら、これはOSIの下位層がRS232Cなどの場合を想定しており、TCP/IPのような環境では適当でなく、開始ブロック(0b)は付加しない。

10

HL7メッセージ確認項目

IHE-Jベンダワークショップ2006

 MSH-9
MSH-9 Message Typeでは3つの成分を持つ必要がある。
<メッセージ型>^<トリガーイベント>^<メッセージ構造>
例）

ADT^A08^ADT_A08
OMG^O19^OMG_O19

11

HL7メッセージ確認項目

IHE-Jベンダワークショップ2006

 PV1-3患者所在（PL型）なので、入院の場合、<病棟>^<病室>^<病床>^^^N
外来の場合<診療科>^^^^^Cと解釈し、person location type の指定を必須とする。
日本の場合、入院では診療科と病棟の両方が意味をもつが、PL型の使用方法
として、HL7原文の定義に忠実に沿うこととした。
すなわち、PV1-3では所在を表現し、診療科はPV1-10で表現する。

 PV1-10
患者の受診科や入院科（IS型）を設定する。
外来の場合はPV1-3と同じ診療科を示す。

12

HL7メッセージ確認項目

IHE-Jベンダワークショップ2006

 ORC-13
入力場所（PL型）なので、医師が入力するオーダ情報では入院の場合、<病棟>^<病室>^<病床>^^^N
外来の場合<診療科>^^^^^Cと解釈し、person location type の指定を必須とする。
日本の場合、入院では診療科と病棟の両方が意味をもつが、PL型の使用方法として、HL7原文の定義に忠実に沿うこととした。
すなわち、ORC-13では所在を表現し、診療科はORC-17で表現する。

 ORC-17
入力者の所属(CE型)なので、医師が入力するオーダ情報では診療科と扱う。
外来の場合はORC-13やPV1-10と同一。
入院の場合はPV1-10と同一。

13

HL7メッセージ確認項目

IHE-Jベンダワークショップ2006

 PID-11（住所）
最初のエレメントは、<Street Address (SAD)>であり、これはさらに<Street or Mailing Address (ST)> & <Street Name (ST)>& <Dwelling Num-ber (ST)>に分解される。
そこで、日本の場合は、
虎ノ門１－１９－９^^港区^東京都^105-0001^^Hのように記述する。
なお、住所を（都道府県や市町村などに）分離して管理していない場合もあるので、最初のエレメントだけを用いて、東京都港区虎ノ門１－１９－９^^^^105-0001^^Hのように記述しても構わない。

 PID-13（電話番号）
最初のエレメントのData TypeはSTなので、例えば、03-3506-8010^PRN^PHと扱うこととする。（V2.4までは原文に余分な表現があったが、V2.5で修正）
14

HL7メッセージ確認項目

IHE-Jベンダワークショップ2006

 XCN型の補足説明
第10成分（名前タイプコード）と第15成分（名前表示コード）は必須。

 XPN型の補足説明
第7成分（名前タイプコード）と第8成分（名前表示コード）は必須。

 OBR-29
子レコードの場合、Parent Number（親オーダ番号）は必須。

15

実装上の注意 [IHE-Jとしての拡張]

IHE-Jベンダワークショップ2006

IHE-Jコネクタソンにおいて、HL7メッセージを実装する際の基本的な約束事を以下に記す。

① メッセージ表現・ HL7メッセージは<EOM>までを1メッセージとして送受信する。
・ メッセージは複数のセグメントにより構成され、各セグメントは<CR>（文字コード00/13）により区切る。
・ メッセージの最後には2バイトからなるメッセージ終端文字列<EOM>（文字コード01/12と00/13の2バイト）を付ける。最終セグメントにも<CR>が必要。
セグメント1 <CR>
セグメント2 <CR>
・・・
セグメントn <CR>
<EOM>

16

実装上の注意 [IHE-Jとしての拡張]

IHE-Jベンダワークショップ2006② 文字コード・ HL7でのトランザクションを行う全てのアクタに対し、マルチバイト文字をサポートする。
すなわち、MSH-18フィールドの第1要素（1バイト系文字コード）にASCII文字コード（ISO IR 6） を第2要素(2バイト系文字コード）にJIS漢字コード（ISO IR87） を設定する。
・ 文字コードの切替えにはISO2022-1994（JIS-X0202） を使用する。
・ 半角カタカナ（ISO-IR13）の使用を禁止し、JIS補助漢字（IR 159）の使用も推奨しない。ISO IR87にない2バイト系文字は類似形態の文字または、ひらがな（カタカナ）とする。

17

実装上の注意 [IHE-Jとしての拡張]

IHE-Jベンダワークショップ2006③ メッセージ送受信
・ メッセージの送受信はTCP/IPによるソケット通信とし、OMG/ORG、OMI/ORI、ORU/ACK、ADT/ACKメッセージで、各1ポートずつ（計4ポート）割り当てる＜原則＞
・ メッセージ送信側のアクタがコネクション確立を行なう。連続してメッセージがある限りコネクションを維持し、メッセージが途切れた時点で開放する。
・ 受信側のアクタでは、必須フィールド以外のフィールドに値が設定された応答メッセージが送信されてくる可能性があることを前提とする。すなわち、受信側アクタで不要なデータは読み捨てる。
・ 送信側アクタで管理していない情報は、null値とする。受信側アクタは全ての情報がセットされてくると誤解しない。（必須フィールド以外）
・ 後続フィールドが全てnull値の場合、セパレータが省略されることを考慮する。

18

実装上の注意 [IHE-Jとしての拡張]

IHE-Jベンダワークショップ2006

・ オーダ番号（15桁）はユニークキーとする。
メッセージ例では下2桁を連番として、親レコードを00、子レコードを01～99で示している。
・ 修正オーダはCancelオーダとNewオーダを続けて発行する。
（オーダ番号は同一）・ CancelオーダではOBRの親オーダ（PA）までを送信する。
（オーダ番号をもとに当該オーダを削除）
・ HIS-RIS間での患者氏名はカナ氏名（表音文字）を必須とし、カナ氏名→英字氏名（ローマ字）変換はRIS側で行う。

19