日本拡張対応の注意事項
IHEJ参加ベンダーワークショップ 2023.05.11
日本IHE協会 接続検証委員会

1

2

World ConnectathonsChina
about 50
Japan

About 45
EU
about 90

Korea
about 10?

NA
about 70
Australia
about 10?

Vendor’s participation

3

日本版拡張について
IHEではワールドワイドで共通なTFを提供しています。
でも、各国では、業務運用方法や習慣の違いから、それぞれのシステム化事情があります…

国別拡張（National Extension）が許されています。

4

RADの日本版拡張 RAD TF Rev.15.0:2016/07/29 に発行
 JP-NEX: 10. National Extension for IHE JapanTF Vol.4. は各国のNational Extensionが記載されている。
この中に日本版拡張仕様に関する記述（言語や日本特有の拡張仕様の説明）を追加しました。

5

日本語対応• IHE-J コネクタソンでは日本語の使用が前提。ただし…
– ISO IR87の2バイト文字 ＝ ○ 使う
– ISO IR13（半角カタカナ） ＝ × 使用禁止
HL7 MSH-18：
文字セット

日本語不使用ASCII文字＋日本語文字

備考•

×（設定なし）DICOM Tag(0008, 0005)：
特定文字集合タグ無し
ISO_IR100

ASCII~ISO IR87

ISO 200 IR 6¥ISO 2022 IR 87

ISO IR6~ISO IR87

¥ISO 2022 IR 87~ISO IR87

代替文字セット操作法 はMSH-20に別途設定

コード値表現以外は日本語使用対象

詳細は審査基準書の例を参照
6

DICOM日本語対応の基本原則【定義】 “DICOM日本語対応オプション”をサポートする装置
日本語文字（ISO 2022 IR 87）が、他のデバイス（装置又はリムーバブルメディアなど）からの連携データに含まれていた場合⇒ DICOＭデフォルト文字（ISO 2022 IR 6）のみの場合と、同様に取り扱うことができる。
すなわち…
日本語文字が届いた場合Reject しない（受信できる）
日本語文字を別の装置に送信できる
7

HL7V2通信の実装にあたって• IHE-Jコネクタソンにおける HL7通信規約は 、JAHISデータ交換規約（最新版） に従う。
（ HL7 v2.5をベースに国内の業務特性を取り入れたもの）
https://www.jahis.jp/standard/contents_type=33
 共通編 と 各個別部門編 に分かれている。
 共通編に通信レベルの基礎要件や、患者情報の取り扱いについて記載。
 各個別部門編では部門毎の業務フローに沿った要件について記載。
 HL7 V2.5 をベースにトランザクションを定義。
 日本語の取り扱いについて（患者氏名、住所、連絡先、主治医など）
 日本独自の業務トランザクションを追加


RAD例：患者到着通知、検査実績情報送信

日本の事情に合わせたフィールド設定内容の拡張定義。
RAD例： OF→IMの転送の際に患者名アルファベット情報を追加し送信。

8

HL7の日本版要件の経緯
IHEでは臨床検査分野で、HL7 V2.5.1を採用（先行の放射線検査分野は V2.3.1）
日本では独自にV2.5 系に統一【欧米】
では部門の独立性が高い→ 問題なし臨床検査
放射線検査

V2.3.1

XX部門【日本】
トータルシステム→ 別々では困る･･･

V2.5.1

HIS（病院システム）

V2.5.1V2.3.1
V2.X

V2.5.1

放射線検査 臨床検査

V2.X

V2.5.1

XX部門
9

IR87では第3,4水準の漢字が出ない• IR87を標準適応していることの課題
 JAHISデータ交換規約でIR87の使用を推奨している⇒ 部門システムで第3,4水準漢字が事実上表示できない 現在、JIS X 0213 や Unicode が整備され課題を解決できる
 HL7、DICOM規格ではIR159*やIR192は宣言すれば使える* IR159は JIS X 0212

• コネクタソンでは審査上 IR87を用いる
 現場においては、送受側の了解があればUnicodeも使用可能 今後、ニーズがあれば コネクタソンでも検証環境を検討したい

10Web系の日本語対応について• Web系（HTTP、XML、FHIR等）での文字コード– UTF-8を使用することがデフォルトになっている– キャラクタセットは送信時に指定可能で、UTF-8以外の文字コードを指定可能• そのため、HL7V2、DICOMとは異なり、日本コネクタ
ソンでもUTF-8を使用することを推奨する– 各ドメインで指定がある場合はその指示に従うこと

11NA/EU の文字コード事情• HL7 V2 通信ではUnicodeを使うベンダもいる あくまで Connectathon でのルールでIHEルールではない 一般的には ASCII（MSH-18宣言無し）がほとんど
 PAM、PDQ等では、MSH-18にUnicodeを宣言するケースあり
 Projectathon ではその国の言語事情に併せて宣言• DICOM 通信では試験的にUnicode対応
 EU Connectation 2019では、開催前からUTF-8を宣言した

DICOMファイルについて、受信可能かの問い合わせが発生。

12

コネクタソンにおけるHL7V2通信でのMLLP不採用• MLLPとは？

Minimum Lower Layer Protocol の略。HL7はOSI 7層のみの宣言であるため、最低限の通信規定をVer.2.3の時代に補足
 国外ではVer.2.3ベースで発展したため、MLLPを採用している
 Ver. 2.5で、この補足（Implementation Guide）が廃止された
 日本では Ver.2.5をベースとしており、MLLPの不採用が推奨されている
• 通信上のHL7電文認識について
MLLP使用時では開始バイト0x0B と 終了バイト0x1C 0x0Dの間にHL7の電文を配置することで、通信ソケット内に複数のHL7電文を含めて送信することが可能だが・・・
 日本では1接続にひとつのHL7電文しか含めないこととする

開始バイト0x0Bは使用しないことを推奨
電文終了は終了バイト0x1C 0x0Dが送られたことで判断する
１電文が複数パケットで送信されることを許容すること
電文の送受信が完了したらソケットを必ずCloseする

13HL７V2におけるオーダの構造• HL7オーダ表現で親子構造を持つドメインがある• RADではORC以下の部分は以下の構造になる• 詳細は各ドメインの審査基準書で解説する
ORC（NW）
TQ1
OBR

ORC（PA）
TQ1
OBR
OBX

ORC（CH）
TQ1
OBR×l
OBX
ZE1/ZE2×n×m×O

このオーダ情報がこのオーダ情報のこのオーダ情報の新規

手技＝検査種撮影方法と実施であることを示すを示すを示す
14

ご清聴ありがとうございました。
ご質問があれば承ります。

15