目次
1.
2.
3.
4.

はじめに ...................................................................... 1-1
HL7 概要 ....................................................................... 2-1
主な用語 ...................................................................... 3-1
臨床検査データ交換規約の対象範囲 .............................................. 4-1
4.1 会話型としての利用 .......................................................... 4-1
4.2 ファイル転送型としての利用 .................................................. 4-1
4.2.1 ファイル転送型における本規約利用上の考慮点............................. 4-2
4.3 臨床検査関連システム構成イメージとメッセージの適用........................... 4-3
4.3.1 臨床検査依頼・報告関連システム間情報伝達イメージ....................... 4-3
4.3.2 マスタファイル通知イメージ ............................................ 4-4
4.3.3 メッセージとトリガイベント ............................................ 4-5
4.4 臨床検査依頼・報告メッセージの対応関係....................................... 4-8
4.4.1 臨床検査依頼・報告メッセージの OBR,OBX の対応関係例..................... 4-8

Copyright©2008 JAHIS

1

1.

はじめに

今日、医療環境が変化し、分業化と連携が進むにつれ、標準化と客観化の重要性がより認識されるようになった。また、システムメーカーにおいても、一社ですべての業務システムをカバーすることは困難となってきており、マルチベンダー化が進んでいる。このような状況で効率的なシステム開発のため、標準化が必須となっている。つまり医療情報の標準化は、患者中心の医療や効率的な医療を進めるにあたって、重要な位置を占めるものである。
臨床検査の分野では、いち早く標準化の取り組みが行われている。
臨床検査そのものの標準化は1985年より日本臨床検査標準協議会JCCLS(Japan Committee for ClinicalLaboratory Standards)が設立され、検査方法や精度管理を中心に信頼される検査データが流通することを目的として活動している。
検査項目コードについては、日本臨床検査医学会（旧：日本臨床病理学会）が1962年より長年にわたり
臨床検査項目分類コードを発表してきたが、1990年にコンピュータで使用する事を前提とした大改訂を行い、第8回改訂として発表した。さらに第8回改訂の問題点や新規項目などを追加し、結果識別コードも組
み込んだ第9回改訂を1994年に発表し、1997年の第10回改訂にてJLAC10として発表し利用されている。
臨床検査データのシステム間でのやり取りについては、 1993年医療情報システム開発センター
MEDIS-DC臨床検査データ交換標準化協議会より暫定規約｢臨床検査データ交換規約（暫定版）｣が発表され、保健医療福祉情報システム工業会ではその利用ガイドを作成してきた。しかしながら、その暫定規約
は当時の汎用機やオフコンで稼動している臨床検査システムですぐ対応可能な規約とし、国際情勢や医療情報システム動向を踏まえた規約については以後の検討とした。
このため、保健医療福祉情報システム工業会臨床検査システム委員会では、院内オーダリングや病医院－臨床検査センター間をはじめ、様々な医療関連施設間相互に適用でき、かつワールドワイドに通用する
臨床検査データ交換規約の検討を進めた。まず病院・医院ほか保健医療関連施設（臨床検査センターを含む）間で発生する、検査依託業務に関する情報要素を抽出し、つぎに情報要素をASTM E-1238及びHL7と対比し原案検討を行い、1998年HL7 Ver.2.3に準拠した｢JAHIS 臨床検査データ交換規約 Ver.1.0｣をまとめるにいたった。
その後、病院情報システム（HIS）と臨床検査システム（LIS）間のオンライン通信機能を強化したHL7
Ver.2.3準拠の｢JAHIS 臨床検査データ交換規約<オンライン版>Ver. 1.0｣および各種マスタファイル情報の設定更新するメッセージが追加されたHL7 Ver.2.3.1準拠の｢JAHIS 臨床検査データ交換規約 Ver.2.0｣が制定された。さらに臨床検査自動化に関する通信仕様の追加等の改訂が行われたHL7 Ver.2.4に準拠した｢JAHIS 臨床検査データ交換規約<オンライン版>Ver.2.0｣が制定されてきた。
IHE-JでHL7Ver.2.5を採用したこと、ならびに「JAHIS臨床検査データ交換規約Ver.2.0」と会話型仕様「JAHIS臨床検査データ交換規約<オンライン版>Ver.2.0」の２つの規格が存在することを鑑み、今回、
HL7Ver.2.5準拠ならびに２つの規格を一本化した「JAHIS臨床検査データ交換規約Ver.3.0」を制定するにいたった。HL7Ver.2.5準拠とすることで、従来のオーダ依存型メッセージに加え、検体依存型のメッセージも可能となり、いずれの場合も必要に応じ検体容器について記述することが可能となった。

Copyright©2008 JAHIS

1-1

2.

HL7概要
概要

（HL7とは）ヘルスケア関連情報の電子的データ交換のための応用規約であり、また、規約の制定団体の名称でもある。異なるベンダの異なるシステム間のインタフェースとなる標準的書式である。本規約はOSI手順の第7層であるアプリケーション層に由来してHL7と名付けられたものであり、物理的規約は制定していない1。
（なぜ標準化なのか）
基本的目的は増大する医療費の削減と医療の質の向上である。それは医療費の効率化のためコスト計算を明らかにするとともにヘルスケア品質の計測化による質の向上を目指すものである。
1960年代は単独処理で他との接続は必要なかったが、1970-85年にかけ部門システムとの接続が始まり、1985年以降様々なシステム間で接続が要望され、インタフェース標準化の必要性が増大している。
病院単独から病院の統廃合も手伝ってヘルスケア共同体が拡大し、今日のヘルスケアは病院を中心に事務所、製造業、販社、支払者、診療所、政府機関が一体となった情報連携が必要で、かつ患者を取り巻くすべての部門とのトランザクションが通信で出来ることが必要となってきた。
技術の進歩、通信環境の進歩、場所の多様化、システムの巨大化が背景となり標準化されたデータ交換が可能であり不可欠となっている。
（HL7の歴史）1987年3月ペンシルバニア大学病院で初会合、3-4ヶ月かけVer.1.0のドラフトができた。Ver.1.0は1987年10月に発表され全体的なインタフェースと入退院、オーダエントリ、オーダ照会が含まれる。患者会計の重要性が認識されていたが時間的制約で含まれなかった。以後1988年9月にVer.2.0、1990年にVer.2.1が発表された。1991年にはANSIのメンバとなり、1992年にはANSI HISPP(Healthcare Informatics Standards
Planning Panel)の起草メンバとなった。1994年にはANSIに認知された標準化組織となった。1994年末Ver.2.2を発表し、最新版は2003年のVer.2.5で、ISO規格にも採用された。さらに、2005年の時点でVer.2.6も一部承認された。またオブジェクト指向のVer.3.0も発表され、2006年にはRIM(Reference Information Model)がISO/DISになっている。
（HL7の組織）
HL7は会員制の組織であり会員は意見を反映させることができる。即ちHL7の情報源は会員の意見である。HL7の使用は会員であることを問わないが、HL7からのタイムリーな情報提供はない。理事会と作業グループがあり会員が参加できるし、作業グループに参加してなくても案に対して意見を述べることができる。また医療提供者顧問と工業会顧問のアドバイスを受ける。会員には、医療機関、コンピュータ会社、
医療関連会社、コンサルタント会社などがいる。また米国以外の国々の会員もいる。会員数は増加しており2007年8月現在2300を越える会員数である。国際支部も既に30ヵ国以上になり各国での利用が進んできた。
（HL7プロトコル概要）
HL7はOSI第7層（アプリケーション層）での規約であり、データの型や要素、要素の構成やグループ、
コードや用語、機密保持、管理規約などが定義される。HL7の包含する対象はVer.2.1では入退転院、患者基本情報、オーダ、検査報告、財務的処理、照会などである、さらにVer.2.2では、マスタファイル更新、
Ver.2.3では、文書管理、予約、患者紹介、患者看護、Ver.2.4、Ver.2.5では自動検査、人事管理、保険請求、材料管理などが追加された。
HL7の基本的体系は、メッセージ型ID付電文で構成され、複数セグメントで論理的意味をなすメッセー
ジとなる。メッセージ（例えば、入退転）は、具体的なきっかけとなる事象（例えば、患者入院）により、データ構成要素（例えば、患者名）からなるセグメント（例えば、患者属性）の集合として構成される。
メッセージ交換は会話的にもバッチ処理的にも行われるものである。
（他の標準化組織との関連）
ASTM E1238検査システム間データ交換をもとに検査関連をまとめているので互換性がある。HL7を含めた標準化団体の調和を図るためANSIでは、HSIB（Healthcare Informatics Standards Board）部門を設置し、
1

HL7にはメッセージの記述の他、実装のガイドラインを規定している。HL7（バージョン3）のITS(Implementation Technology Specification)ではebXML、SOAP、MLLP(Minimum Low Layer Protocol)での下位層での取り扱いも規定されている。しかし、JAHIS標準ではこれらは採用していない。
Copyright©2008 JAHIS

2-1

NCPDP（薬剤情報）、 ACR/NEMA（画像DICOM）、 IEEE MEDIX（医療情報記述交換）、 ASTM（検査関連臨床情報交換）、 ASC X12（会計保険情報の電子データ交換）と協調している。また国際的にも
CEN-TC251(European Committee for Standardization Technical Committee 251)などと連絡を取り合っている。
これら協調は重複の縮小、標準化のスピードアップ、コスト低減、国際関係の促進、政府によらない開発、販売者の共同作業の促進などのため必要なことである。さらにISO/TC215(Health Informatics)とHL7はPilot
ProjectとしてHL7規格をISO規格にすることが決定された。
（日本HL7協会他国内の標準化組織との関連）
日本HL7協会が1998年7月に設立された。これを受け、JAHISでもHL7標準化規約の日本国内における普及を日本HL7協会と協力し、進めている。

Copyright©2008 JAHIS

2-2

3.

主な用語

トリガイベントTrigger Event： メッセージの交換を始めるきっかけとなる事象をトリガイベントという。
HL7は、実際のヘルスケア現場でのシステム間データ通信の必要性に応じた事象を受けて書かれている。例えば、｢患者が入院｣というトリガイベントは、その患者についての情報を幾つかの他のシステムに伝送する必要を引き起こすであろう。それらメッセージ型とトリガイベントコード
は一対多の関係である。
メッセージMessage： 1つのメッセージは、システム間で転送されるデータの意味のある最小単位であり、これは定義された順序のセグメントの集合からなる。各々のメッセージはその目的を定義するメッセージ型を持っている。例えば、ADT（入退転）メッセージ型はあるシステムから別なシステムに患者の入退院・転棟・転床データの一部を伝送するために使用される。各々のメッセージに含まれる3文字のコードがその型を識別する。
セグメントSegment(record)： セグメントはメッセージの1つの側面について記述するもので、データ要素（フィールド）の論理的集合体である。各々のセグメントはセグメントIDと呼ばれる3文字のコードで識別される。メッセージ中のセグメントは必要なものと任意のものとある。それらはメッセージ中一回だけ出現する場合と繰り返しが許される場合とある。例えば、単一のオーダ関連
情報はOBRセグメントとして送られ、検査関連情報は別のOBXセグメントとして送られることがある。
フィールドField： 診断名などといったセグメント中の1つの意味付けされた属性であり、フィールドには基本属性をさらに詳細に記したデータ成分の集合を含むことがある。
フィールド成分Field components： フィールドへの入力要素として、成分という識別可能な部分を含むことがある。例えば、患者名は、姓、名、ミドルネーム（イニシャル）として記録されるが、それぞれの要素は別個のエンティティであり、成分区切り文字により分離される。成分はさらに副成分で構成される場合もある。
メッセージ区切り文字Message Delimiters： メッセージを構成するにあたっては、定義された文字が使用される。それらは、セグメントターミネータ、フィールドセパレータ、成分セパレータ、副成分セパレータ、反復セパレータ、そしてエスケープ文字である。
依頼者Placer(Requestor)： 検査群を依頼（要求）する人あるいは部門をいう。 例えば、検体検査、X線、バイタルサインなどを依頼する医師、実施者、病院、または病棟部門などである。
実施者Filler(Producer)： 依頼・要求された検査を実施する（オーダに応える）人または部門のことである。診断部門、臨床部門、その患者についての検査結果を報告する看護提供者を含む。臨床検査
室は検体検査の実施者（検査オーダに応える人）であり、看護部門はバイタルサイン観察などの実施者（バイタルサインの測定を依頼するオーダに応える人）である。
検査群（バッテリ）Battery： 単一名と単一コード番号で識別される1個以上の検査を含む検査集合であり、構成要素である検査を依頼・検索するのに使用する包括的なまとまりとして扱われる。通常、
バイタルサインは、拡張期血圧、収縮期血圧、脈拍、呼吸数などで、電解質は通常、Na+、K+、
Cl-、HCO3-などで、入院時検査は血液、電解質、生化学、尿検査などで、産科用超音波は、従来の計測結果および所見から成るセットで、構成され、それら構成要素は、依頼者に返される時、個別の“結果”として返される。これらバイタルサイン、電解質、入院時検査、産科用超音波などはすべて検査群の例である。集合に関する数学法則と同様、単一検査も検査群とすることができる。検査群という用語は、本仕様では、｢プロファイル｣あるいは｢パネル｣と同義である。検査群
は他の検査群の構成要素にもなり得ることに注意すること。検査群内の個々の検査要素は、1つの生理学系（例えば、肝機能検査）の特性を反映してもよいし、様々な異なる生理学系の特性を反映してもよい。
病院情報システム（HIS）Hospital Information System： 患者管理ADT（入院、退院、転院）、各種オー
ダ、施設管理など、通常、検査室の外部の機能をサポートするシステムをいう。

Copyright©2008 JAHIS

3-1

臨床検査システム（LIS）Laboratory Information System： 患者検体の識別、検査の依頼、検査の報告、精度管理などの、検査の様々な面に関するデータ管理の責任を負う情報システムをいう。
注ａ： LISはLASと直接インタフェースを行い、患者、到着、採取管、検査依頼、検体ステー
タス、検査の結果を通信する。
注ｂ： LISまたはLASは装置（または検体処理装置）とインタフェースして、特定の検査依頼と報告のための結果のやり取りを行う。
注ｃ： LISは、医師および他の医療職員が使用するために、臨床システムとインタフェースする場合が多い。
臨床検査自動化システム（LAS）Laboratory Automation System： 臨床検査室のシステムの運用においてオペレータの介在をできるだけ少なくした、情報とハードウェアテクノロジーのシステムをいう。
注：
典型的な機能には、LASインタフェースを通じた装置の情報システム管理があり、これには検体の操作（遠心分離）、検体の搬送、結果の計算、再検査、検査の考察、品質評
価と結果報告を行う技術が含まれる。
自動化装置Automated instrument： 患者のサンプルの計測を行う自動化された検査装置をいう。臨床検査システム（LIS）、病院情報システム（HIS）、臨床検査自動化システム（LAS）に接続している場合も接続していない場合もある。
注：
これらの装置は、臨床検査自動化システムとのインタフェースが行えるよう、ハードウ
ェアまたはソフトウェアの仕様の変更を行っても良い。
検体Specimen： ある量や性質を検査、研究、分析して全体の特性を決定するために採取した、体液または組織の一部をいう。
注：
採取した検体を処理したものも検体と呼ばれる。従って、検体の例には、全血および全血から得られる血清や血漿、唾液、髄液、便、尿、爪、毛髪、パラフィンブロックに内包された組織サンプルなども含まれる。
採取管Container： 患者の検体を保持する容器をいう。（図１参照）
注：
採取管は通常、ガラスまたはプラスチック製の片側が閉じた管で、反対側に取り外し可
能な蓋が付いている。
ロケーションLocation： 一意の識別子（冷蔵庫の棚番号、機器バッファID、トラックIDなど）を持つ、検査室内の物理的な場所をいう。（図１参照）
キャリアCarrier： 採取管を保持するデバイスをいう。（図１参照）
注：
キャリアは、搬送システムと機械的にインタフェースして、ロケーションからロケーシ
ョンに検体を移動させる。運搬する採取管の数は1個の場合も複数の場合もある。
トレイTray：

1個以上のキャリアを保持するデバイスをいう。（図１参照）

LECIS Laboratory Equipment Control Interface Specification： 分析機と機器のリモート制御の、規格動作またはインタラクションのためのメッセージ内容を定める高レベルプロトコル（ASTM E
1989-98）。

Copyright©2008 JAHIS

3-2

Specimen
Container

Spec.
Carrier

Tray

1

2

2037

2002

2123

2456

3

4

5

6
Location

Specimen
Container

1

13
4

2

02
3

3

10
2

4

04
5

Spec.
Carrier

Location

図１．採取管、キャリア、トレイ、ロケーションの関係

Copyright©2008 JAHIS

3-3

4.

臨床検査データ
臨床検査データ交換規約
データ交換規約の交換規約の対象範囲

従来JAHIS臨床検査データ交換規約はファイル転送型（通称バッチ版）とHIS-LIS間通信のような会話型（通称オンライン版）があったが、このたび両者を統合し「JAHIS臨床検査データ交換規約Ver.3.0」とした。
各々の利用場面での特徴や注意事項をつぎに述べる。

4.1

会話型としての会話型としての利用としての利用一般的に施設内の臨床検査依頼、結果報告などのデータ交換では、病院情報システム（HIS）、
臨床検査システム（LIS）、臨床検査自動化システム（LAS）の間で、会話型の通信が使用される。会話型のデータ交換規約としては、これまで「JAHIS臨床検査データ交換規約<オンライン版>Ver.1.0」（HL7 Ver.2.3.1準拠）、臨床検査自動化に関する通信仕様の追加等の改訂が行われたVer.2.0（HL7 Ver.2.4準拠）があった。本規約はVer.2.0の改訂版<Ver.3.0 >として、HL7
Ver.2.5に準拠するとともに、ファイル転送型と統合したものであるが、特別のコメントがな
い限り、会話型について記述している。

4.2

ファイル転送型
ファイル転送型としての転送型としての利用としての利用
ファイル転送型の規約としては、これまで「臨床検査データ交換規約暫定版」（MEDIS-DC）、
ASTM E1238を参考にした「JAHIS臨床検査データ交換規約Ver.1.0」（HL7 Ver.2.3準拠）、同
Ver.2.0（HL7 Ver.2.3.1準拠）があった。ファイル転送型はシステム間のデータ交換をファイルを転送することで実現するが、ファイル転送の手段としてFTP、NFS、電子メールなどのオンラインファイル伝送や、フロッピディスクなどのオフラインメディア搬送などが利用でき、施設内・外を問わず極めて導入が容易である。また、一般的なファイル交換でのセキュリテ
ィ対策（PGPなど）が適用でき必要十分な対策が可能である。
ファイル転送型の利用形態について以下に示す。

検査依頼・結果の交換
検査依頼者

検査依頼
検査結果

検査実施者

ＦＴＰ、メール、フロッピディス クな ど

検査依頼のみ転送
検査依頼者

検査依頼

検査実施者

ＦＴＰ、メール、フロッピディス クな ど

検査結果のみ転送
検査依頼者

検査結果
ＦＴＰ、メール、フロッピディス クな ど

Copyright©2008 JAHIS

4-1

検査実施者

4.2.1

ファイル転送型
ファイル転送型に転送型における本規約利用上おける本規約利用上の本規約利用上の考慮点



臨床検査依頼メッセージと臨床検査報告メッセージはそれぞれ単独でも使用可能であるが、電子化メッセージ交換の効果を高めるには両者を使用し精度の高い情報交換を実現することを推奨する。



ファイル転送型で使用するメッセージは、臨床検査依頼（OML^O21）、臨床検査結果報告（ORU^R01）、マスタファイル通知（MFN^M08~M14）であり、照会、到着確認、検査自動化
関係のメッセージは適用しない。



本規約では会話型で使用する応答メッセージについても記載があるが、ファイル転送型ではMSHセグメント等での応答指定にかかわらず応答メッセージは使用しない。

Copyright©2008 JAHIS

4-2

臨床検査関連システム
臨床検査関連システム構成
システム構成イメージ
構成イメージとイメージとメッセージのメッセージの適用

4.3

臨床検査データ交換規約は下図「システム間情報伝達イメージ」と「マスタファイル通知イメージ」の範囲を対象とする。また、取り扱うメッセージ型及びトリガイベントを表「メッセージとトリガイベント」
に示す。

4.3.1

臨床検査依頼・
臨床検査依頼・報告関連システム
報告関連システム間情報伝達
システム間情報伝達イメージ
間情報伝達イメージ
ＨＩＳ
サーバ

Database

①、④
②、③

①、④
②、③
※

ＬＩＳ／ＬＡＳ
ＬＩＳ／ＬＡＳ(ＨＩＳ／ＬＡＳ ＨＩＳ )検査センター
検査センター
①、④

サーバ

サーバ

②、③

①、⑥、⑧、⑩、⑪、⑮、⑰②、⑤、⑦、⑨、⑫、⑬、⑭、⑯※システム構成によっては、Automated Instrument が 直接HISに接続される。

Ａｕｔｏｍａｔｅｄ Ｉｎｓｔｒｕｍｅｎｔ
外部インタフェース

各数字（①～⑰）は、表「メッセージとトリガイベント」の番号に対応する。

Copyright©2008 JAHIS

4-3

4.3.2

マスタファイル通知
マスタファイル通知イメージ
通知イメージ
コードセットマスタ
サーバ

Database⑱⑲

コードセットコンシューマ

サーバ

各数字（⑱、⑲）は、表「メッセージとトリガイベント」の番号に対応する。

Copyright©2008 JAHIS

4-4

4.3.3

メッセージとメッセージとトリガイベント
メッセージとメッセージとトリガイベント

NO①

メッセージ定義

臨床検査依頼メッセージ型

OML→
←ORL

ORU→
②

←ACK

到着確認報告、臨床検査結果
OUL→

←ACK

③

情報照会

QBP→

トリガイベント

イベント型

一般オーダメッセージ

O21/O22

１検体に対する複数依頼の検査オ
ーダメッセージ

O33/O34

1検体1容器複数依頼時の検査オー
ダメッセージ

O35/O36

非要求検体ベース検査結果メッセージ

R22

非要求検査結果転送メッセージ

R01

非要求検査結果メッセージR21

非要求検体採取容器ベース検査結果メッセージ

R23

非要求オーダベース検査結果メッ
セージ

R24

非要求POCT検査メッセージ依頼部
門オーダなし

R30

非要求POCT検査メッセージオーダ
検索

R31

非要求事前POCT検査オーダ

R32

患者情報照会メッセージ

ZC0/ZC1←RSP 検査結果情報照会メッセージ④

患者情報通知患者管理メッセージ

ADT→

ZB5/ZB6
A08

←ACK
⑤

自動化装置ステータス更新⑥

自動化装置ステータス要求⑦

検体ステータス更新⑧

検体ステータス要求

Copyright©2008 JAHIS

ESU→

自動化装置または自動化装置のステータスに関する情報の更新
←ACK

U01

ESR→

自動化装置または自動化装置のステータスに関する情報の要求
→ACK

U02

SSU→

検体の位置とステータスに関する←ACK 情報の更新

U03

SSR→

検体の位置とステータスに関する←ACK 情報の要求

U04

4-5

NO

メッセージ定義⑨

自動化装置在庫更新

メッセージ型

トリガイベント

イベント型

INU→

在庫項目に関する情報の更新

U05

在庫項目に関する情報の要求

U06

自動化装置コマンドの発行

U07

自動化装置コマンドに対する応答

U08

自動化装置に関する通知

U09

←ACK
⑩

自動化装置在庫要求

INR→
←ACK

⑪

自動化装置コマンド

EAC→
←ACK

⑫

自動化装置応答

EAR→
←ACK

⑬

自動化装置通知

EAN→
←ACK

⑭

自動化装置検査コード設定
更新

TCU→

検査コードとパラメータに関する←ACK 情報の更新

U10⑮

自動化装置検査コード設定
要求

TCR→

検査コードとパラメータに関する←ACK 情報の要求

U11⑯

自動化装置ログ/サービス更新LSU→

ログ／サービスのイベントのどち←ACK らかまたは両方の更新

U12⑰

自動化装置ログ/サービス要
求LSR→

ログ／サービスのイベントのどち←ACK らかまたは両方の要求

U13

Copyright©2008 JAHIS

4-6

NO

⑱

メッセージ定義

マスタファイル通知

メッセージ型

トリガイベント

イベント型

他に特定されないマスタファイル（旧版互換のみ）

M01

職員／従事者マスタファイル

M02

検査項目マスタファイル（旧版互換
のみ）

M03

課金明細マスタファイル

M04

ロケーションマスタファイル

M05

相とスケジュールを伴う治験マス
タファイル

M06

相を除くスケジュールを伴う治験
マスタファイル

MFN→←MFK 数値型検査項目マスタファイル
カテゴリ型検査項目マスタファイ
ル
群（セット）検査項目マスタファイ
ル
計算型検査項目マスタファイル
付加的基本的観察サービス属性マスタファイル
一般マスタファイル
サイト定義マスタファイル
在庫管理項目マスタファイル⑲

マスタファイル照会

マスタ通知と同様

MFQ→
←MFR

Copyright©2008 JAHIS

4-7

M07
M08
M09
M10
M11
M12
M13
M14
M15
M01～M15

臨床検査依頼・
臨床検査依頼・報告メッセージ
報告メッセージのメッセージの対応関係

4.4


臨床検査結果報告メッセージにおける患者識別PID、来院PV1、検査依頼OBRの各セグメントは検査依頼メッセージの当該セグメントの内容を引き継ぐようシステム設計すべきである。特にOBRセグメントは依頼情報に実施者情報を設定するフィールドや依頼者情報を保持したまま返すフィールドがあるのでシステム設計上の配慮が必要である。



検査結果セグメントOBXは臨床検査依頼メッセージでも使用されるが、臨床検査結果報告メッ
セージの検査結果セグメントOBXと対応するものではない。すなわち、臨床検査結果報告メッ
セージにおけるOBXセグメントは依頼された検査に対応する結果表現の最小単位ごとに出現し、その数は結果により可変である。



検査結果セグメントOBXのOBX-5検査結果には参照ポインタを設定し、画像やチャートなど別のファイルやデータを参照することも可能としている。そのため関連してHL7メッセージファイル
以外のファイルの伝送や、参照する仕組みについてもシステム設計上の配慮が必要である。

4.4.1

臨床検査依頼・の対応関係例
臨床検査依頼・報告メッセージ
報告メッセージのメッセージのOBR,OBXの臨床検査報告に含まれる検査結果の件数は検査内容や結果により適宜変化する。例えば、判定
値や所見が付加されたり、検査結果から必要とされる次の検査項目の追加による検査結果の発生などがある。そのため、臨床検査依頼メッセージに含まれるOBRやOBXの件数と対応する臨床検査報告メッセージに含まれるOBRやOBXの件数は一致しない。システム設計上、OBRやOBXの件数は可変であることに注意が必要である。
対応関係の例を以下に示す。

検査依頼メッセージ中のOBR, OBX
OBR
肝炎セット検査、血清
OBX
GOT依頼
OBX
GPT依頼
OBR

尿一般検査、尿OBR

クレアチニンクリアランス検査、
ペア材料：血清・蓄尿
身長，170cm
体重，60kg

OBX
OBX

結果報告メッセージ中のOBR, OBX
OBR
肝炎セット検査、血清
OBX
GOT、10U
OBX
GPT、5U
OBX
file://肝炎
肝炎チャート
肝炎チャート.png
チャート
OBR
尿一般検査、尿OBX
尿蛋白定性、（－）
OBX
尿糖定性、（－）
OBX
ウロビリ定性、（－）
OBR
クレアチニンクリアランス検査、
ペア材料：血清・蓄尿OBX
クレアチニンクリアランス、100ml/min
別File：： 肝炎チャート
肝炎チャート.png
チャート

Copyright©2008 JAHIS

4-8