1993年、(財)医療情報システム開発センター(MEDIS-DC)臨床検査データ交換標準化協議会により「臨床検査データ交換規約(暫定版)」が発表された。その後、約１年間で30件以上におよぶ使用実績を見た。しかしながら、幾多の課題も見受けられる。

　そこで日本保健医療情報システム工業会(JAHIS)臨床検査センターシステム専門委員会では、その使用経験に基づき、課題や要望を抽出整理した。その結果、課題の一部は、仕様の解釈が不十分なことに起因していると考えられた。そこで平成６年度に、課題の共通認識と解決方法・注意点などを討議した結果、円滑に「臨床検査データ交換規約(暫定版)」が導入できるよう利用ガイドとしてまとめ発表した。

　平成７年度より課題の根本的解決と医療情報の標準化動向に沿った臨床検査データ交換規約の検討にはいり、標準化動向の調査学習をすすめ、本年度、臨床検査システムホスト接続ＷＧと共同で「臨床検査データ交換規約JAHIS-DRAFT」をまとめるに至った。本規約原案は、医療情報の標準化動向を見極めながら臨床検査のみならず保健医療情報システム全体のデータ交換体系に留意し、次世代かつWorldWideに通用するものとし、院内オーダリング、病医院−臨床検査センター、病医院間、臨床検査センター間に適用できるよう検討したものである。

　本規約が医療資源の有効利用、保健医療サービスの連携・向上を目指す医療情報標準化とデータ交換円滑化に多少とも貢献できれば幸いです。

　1997年3月 日本保健医療情報システム工業会臨床検査システム委員会

臨床検査院内システム専門委員会ホスト接続ＷＧ

臨床検査センターシステム専門委員会

本案は下記の方々のご協力により作成されました。ご協力感謝致します。

臨床検査センターシステム専門委員長　川真田文章

ＮＥＣ 高坂定

大塚製薬　 川真田文章

ＳＲＬ 山根幸彦・根橋伸之

住友金属ﾊﾞｲｵｻｲｴﾝｽ　 北沢泰弘

ファルコ　 田井中宏

オリンパス　 小林光久・石黒雄二

ＦＡＣＯＭ　 松尾俊二・蟻川典佳

三菱電機　 小南貢

ＮＥＣｺﾝﾋﾟｭｰﾀｼｽﾃﾑ　 有村智子・岡田謙二郎

東亜医用電子　 藤原杜好

塩野義製薬　 市岡正美

日立　 川上彰・宮俊行

ｵﾘﾝﾊﾟｽｼｽﾃﾑｽﾞ　 大塚裕史・谷畠賢

ダイナボット　 小川広一

東芝　 金井洋一

Ａ＆Ｔ 永富隆広

日本事務機　 朝田利行

伊藤忠ﾃｸﾉｻｲｴﾝｽ　 桑野芳伸

１．はじめに 1

２．ＨＬ７概要 2

３．主な用語 3

４．臨床検査依頼・臨床検査結果メッセージ構文 4

　４．１　臨床検査依頼 4

　４．２　臨床検査結果 5

　４．３　臨床検査依頼ＯＲＭ・臨床検査結果ＯＲＵの例 5

５．関連情報詳細 7

　５．１　検査項目コードについて 7

　５．２　材料・採取部位コードについて 8

　５．３　メッセージ区切り文字 10

　５．４　データタイプ 11

　５．５　数量・タイミング定義 17

　５．６　検査結果コメントの扱い 21

６．セグメント詳細 25

　６．１　ＭＳＨ　メッセージヘッダーセグメント 25

　６．２　ＮＴＥ　注釈・コメントセグメント 27

　６．３　ＰＩＤ　患者識別セグメント 28

　６．４　ＰＶ１　来院情報セグメント 30

　６．５　ＡＬ１　患者アレルギー情報セグメント 34

　６．６　ＯＲＣ　共通オーダーセグメント 35

　６．７　ＯＢＲ　検査要求セグメント 46

　６．８　ＯＢＸ　検査結果セグメント 53

1. はじめに

　今日、医療は独りのドクターがすべての医療行為や患者情報を掌握した時代から、医師とコメディカルとのチーム医療、病診連携、中央検査室や検査センター、遠隔診断、地域医療、在宅医療へと変貌しつつある。これに対応して、医療にかかわる情報は自己完結型から広域化・共有化する必要がある。このための情報システムの基盤はデータベースとネットワークである。その情報システムが共有化されるためには、ある約束ごとで客観的に記述され記録伝達されなければならない。この約束ごとが標準・規格と呼ばれるもので、工業界では日本工業規格ＪＩＳに代表される。近年まで医療分野では個別のカルテが中心であったため、標準化について具体的検討が進まなかった。しかしながら、先に述べたように医療環境が変化しインフォームドコンセントや分業化と連携が進むにつれ、標準化の重要性が認識されて来た。また、コンピュータメーカーに於ても、一メーカーですべての業務をカバーすることは困難となってきておりマルチベンダー化が進んでいる。ここでも効率的なシステム開発のため、標準化が必要となっている。このように医療情報の標準化は、患者中心の医療、効率的な医療を進めるにあたって、重要な位置を占めるものである。

　臨床検査の分野では、いち早く標準化の取り組みがおこなわれている。臨床検査そのものの標準化は１９８５年より日本臨床検査標準協議会ＪＣＣＬＳ(Japan Committee for Clinical Laboratory Standards）が設立され、検査方法や精度管理を中心に信頼される検査データが流通することを目的として活動している。

　検査項目コードについては、日本臨床病理学会で１９６２年より長年にわたり臨床検査項目分類コードを発表してきたが、１９９０年にコンピュータで使用する事を前提とした大改訂を行い、第８回改訂として発表した。さらに第８回改訂の問題点や新規項目などを追加し、結果識別コードも組み込んだ第９回改訂を１９９４年に発表した。

　臨床検査データのシステム間でのやり取りについては、１９９３年医療情報システム開発センターＭＥＤＩＳ−ＤＣ臨床検査データ交換標準化協議会で暫定規約を発表した。さらに日本医療情報システム工業会ではその利用ガイドを作成してきた。しかしながら、その暫定規約は当時の汎用機やオフコンで稼動している検査システムですぐ対応可能な規約としたため、国際情勢や医療情報システム動向を踏まえた規約については以後の検討とした。その意味で暫定版であった。

　日本保健医療情報システム工業会臨床検査システム委員会では医療情報の標準化動向を見極めながら臨床検査のみならず保健医療情報システム全体のデータ交換体系に留意し、次世代かつWorldWideに通用する「臨床検査データ交換規約第１版」原案検討を進めた。本規約が院内オーダリング、病医院−臨床検査センター、病医院間、臨床検査センター間に適用できるよう作業を行った。

　作業は、まず病院・医院ほか保健医療関連施設（臨床検査センターを含む）間で発生する検査依託業務に関する将来を見越した情報要素を抽出し、つぎに情報要素をＡＳＴＭ　Ｅ−１２３８及びＨＬ７と対比し原案検討の基本資料とした。それをもとに各情報フィールドの意味付けや定義を明確にするとともにアプリケーション層の検討を進めた。また、これまでの検討結果をＨＬ７Ｖｅｒ２．３に適用し、ＨＬ７Ｖｅｒ２．３に準拠する形で日本の実情を考慮した仕様となるよう検討した。ＨＬ７仕様で不都合な部分は浜松医大木村教授のご尽力によりＨＬ７に仕様変更と了承を取付けＶｅｒ２．３仕様で「臨床検査データ交換規約」ＪＡＨＩＳ原案としてまとめるにいたった。これにより、暫定版では定義されなかった検体数やアレルギーの情報などを反映することが可能となった。またセット検査や負荷試験の個々の検査を詳細にオーダーできるようになった。

　したがって本規約原案はＨＬ７Ｖｅｒ２．３の中から臨床検査に関係する部分をまとめたものに若干の注釈（下線部分）を加えたものとなった。関係団体や諸書先生方のご協力に感謝いたします。

2. ＨＬ７概要

(HL7とは)

　ヘルスケア関連情報の電子的データ交換のための応用規約である。また、規約の制定団体の名称でもある。異なるベンダーの異なるシステム間のインターフェースとなる標準的フォーマットである。本規約はOSI手順の第７層であるアプリケーション層に由来してHL7と名付けられたものであり、物理的規約は制定していない。

(なぜ標準化なのか)

　基本的目的は増大する医療費の削減と医療の質の向上である。それは医療費の効率化のためコスト計算を明らかにするとともにヘルスケア品質の計測化による質の向上を目指すものである。
　1960-70は単独処理で他との接続は必要なかったが、1970-85にかけ部門システムとの接続が始まり、1985以降様々なシステム間で接続が必要となりインターフェイスの必要性が増大している。
病院単独から病院の統廃合も手伝って州から国へとヘルスケア共同体が拡大し、今日のヘルスケアは病院を中心に事務所、製造業、販社、支払者、診療所、政府機関が一体となった情報連携が必要でかつ患者を取り巻くすべての部門とのトランザクションが通信で出来ることが必要である。
　技術の進歩、通信環境の進歩、場所の多様化、システムの巨大化が背景となり標準化されたデータ交換が可能であり必要である。

(HL7の歴史)

　1987年３月ペンシルバニア大学病院にて初会合、3-4ヶ月かけV1.0のドラフトができた。V1.0は1987年10月に発表され全体的なインターフェイスと入退院、オーダーエントリー、オーダー照会がふくまれる。患者会計の重要性が認識されていたが時間的制約で含まれなかった。以後1988年９月にV2.0、1990年にV2.1が発表された。1991年にはANSIのメンバーとなり、1992年にはANSI HISPPの起草メンバーとなった。1994年にはANSIに認知された標準化組織となった。1994年末V2.2を発表し、現在V2.3の最終作業中である。さらにオブジェクト指向のV3.0を予定している。

(HL7の組織)

　HL7は会員制の組織であり会員は意見を反映させることができる。即ちHL7の情報源は会員の意見である。HL7の使用は会員であることを問わないがHL7からのタイムリーな情報提供はない。理事会と作業グループがあり会員が参加できるし、作業グループに参加してなくても案に対して意見を述べることができる。また医療提供者顧問と工業会顧問のアドバイスを受ける。会員には、医療機関、コンピュータ会社、医療関連会社、コンサルタント会社などがいる。またUS以外の国々の会員もいる。会員数は増加しており現在1400を越える会員数である。

(HL7プロトコル概要)

　HL7はOSI第７層(アプリケーション層)での規約であり、データの型や要素、要素の構成やグループ、コードや用語、機密保持、管理規約などが定義される。HL7の包含する対象はV2.1では入退転院、患者基本情報、オーダーと結果、財務的処理、照会などである、さらにV2.2ではマスターファイル更新、V2.3ではスケジューリング、看護計画が追加される予定である。
　HL7の基本的体系はメッセージタイプID付電文で構成され複数セグメントで論理的意味をなすメッセージとなる。メッセージ（例えば入退転）は具体的な事象トリガーイベント（例えば患者入院）によりデータ構成要素（例えば患者名）からなるデータをもったセグメント（例えば患者属性）の集合として構成される。メッセージ交換は会話的にもバッチ処理的にも行われるものである。

(他の標準化組織との関連)

　ASTM E1238検査システム間データ交換をもとに検査関連をまとめているので互換性がある。HL7を含めた標準化団体の調和を図るためANSIでは、HISPP (Healthcare Informatics Standards Planning Panel)(現HISB)部門を設置し、NCPDP(薬剤情報), ACR/NEMA(画像DICOM), IEEE MEDIX(医療情報記述交換), ASTM(検査関連臨床情報交換), ASCX12(会計保険情報の電子データ交換)と協調している。また国際的にもCEN-TC251(European Committee for Standardization Technical Committee 251)などと連絡を取り合っている。これら協調は重複の縮小、標準化のスピードアップ、コスト低減、国際関係の促進、政府によらない開発、販売者の共同作業の促進などのため必要なことである。

3. 主な用語

トリガーイベントTrigger Event：　メッセージの交換を始める事象をトリガーイベントという。HL7標準ではシステム間データ流通の必要性に応じた実際のヘルスケアの現場での事象を受けて書かれている。実際現場での事象はトリガーイベントと呼ばれる。例えば、「患者が入院した」というトリガーイベントはその患者についての情報を幾つかの他のシステムに伝送する必要を引き起こすであろう。それらメッセージ型とトリガーイベントコードは一対多の関係である。同じトリガーイベントコードでも一つのメッセージ型との関連かもしれない。

メッセージMessage：　１つのメッセージは、システム間で転送されるデータの最小単位。これは定義された順序になっているセグメントのグループからなる。各々のメッセージはその目的を定義するメッセージタイプを持つ。例えば、ＡＤＴメッセージタイプはあるシステムから別なシステムに患者のＡＤＴデータの一部を伝送するために使用される。各々のメッセージに含まれる３文字のコードがそのタイプを識別する。

セグメントSegment (レコードrecord）：　セグメントはメッセージの１つの側面について記述するデータ要素（フィールド）から成る論理的集合体である。各々のセグメントはセグメントIDとして知られる一意の三文字コードで識別される。メッセージ中のセグメントは必要なものと任意のものとある。それらはメッセージ中一回だけ出現する場合と繰り返しが許される場合とある。たとえば、単一のオーダー関連情報は（ＯＢＲ）セグメント型として送られ、検査関連情報は別のセグメント（ＯＢＸ）型として送られる。

フィールド　Field：　患者診断などの、セグメントの属性であり、フィールドには基本属性をさらに洗練するデータ要素の集合体を含むことができる。

フィールド成分Field components：　フィールドへの入力要素として、成分という識別可能な部分を含むことができる。たとえば患者名は、姓、名、ミドルネーム（イニシャル）として記録されるが、それぞれの要素は別個のエンティティーであり、成分区切り文字（ＡＳＴＭ　Ｅ１２３８−９４の副副フィールド）により分離される。

メッセージ区切り文字Message Delimiters：　メッセージ構成では決められた文字が使われる。それらは、セグメントターミネータ、フィールドセパレータ、成分セパレータ、副成分セパレータ、反復セパレータ、そしてエスケープ文字である。

依頼者Placer：　検査セットを要求（依頼）する人あるいは部門。　たとえば、検査室検査、Ｘ線、バイタル・サインなどを依頼する医師、実施者、病院、または病棟部門など。要求者と同義であり、相互に交換して使用できる。

実施者Filler：　要求者により要求された検査を実施する（オーダーに応える）人または部門。“実施者（プロデューサー）”と同義であり、診断部門、臨床部門、その患者についての検査結果を報告する看護提供者を含む。臨床検査室は検査室検査結果の実施者（検査室オーダーに応える人）であり、看護部門はバイタルサイン観察などの実施者（バイタルサインの測定を依頼するオーダーに応える人）である。 ASTMの用語ではProducer（実施者）に相当する。

セット（バッテリー）Battery：　単一名と単一コード番号で識別される１個以上の検査を含むセットであり、構成要素である検査の結果を依頼・検索するのに使用する手短な単位として扱われる。バイタルサイン、電解質、ルーチン入院時検査、産科用超音波などはすべてセット（バッテリー）の例である。バイタルサインは（慣例上）、拡張期血圧、収縮期血圧、脈拍、呼吸数など。電解質は通常、Ｎａ＋、Ｋ＋、Ｃｌ−、ＨＣＯ３−。ルーチン入院時検査は血液、電解質、生化学、尿検査など。（ＨＬ７の目的を満足するには、セットの要素もセットになり得ることに注意する）。産科用超音波は、従来の成分測定および診断から成るセットであり、そのすべては、要求者に返される時、個別の“結果”として返される。集合に関する数学法則と同様、単一検査もセットとすることができる。セットという用語は、本仕様では、「プロファイル」あるいは「パネル」と同義である。セット内の個々の検査要素は、１つの生理学系（たとえば肝機能検査法）の特性を反映してもよいし、様々な異なる生理学系の特性を反映してもよい。

4. 臨床検査依頼・検査結果メッセージ構文

4.1 臨床検査依頼

臨床検査の依頼時には一般オーダーメッセージ(ORM)を用い、その場合のセグメントと構文規則は以下のとおりである。

ORM 一般オーダーメッセージ(臨床検査依頼)

ORM General Order Message

MSH Message Header

[{NTE}] Notes and Comments (for Header)

PID Patient Identification

[{NTE}] Notes and Comments (for Patient ID)

[PV1 Patient Visit

[PV2]] Patient Visit 2

[{AL1}] Allergy

{

ORC Common Order

OBR Observation Request

[{NTE}] Notes and Comments (for OBR)

[ {

OBX Observation/Result

[{NTE}] Notes and Comments (for Results)

} ]

}

注:　[ ]は省略可能、{ }は繰返し可能をを示す。

• MSHはオーダーの出力単位(メッセージ)に一つ必須である。
• PIDは１患者の一連のオーダーに１個必須である。オーダーがまとめて伝送される場合MSHがオーダーの区切りとなる。
• ORCは１患者の個々の詳細オーダー毎に１個必須である。ただし１オーダー多項目検査の場合ORCの冗長なしに対応するため、OBRに続くOBXで個別の検査項目指示することも可能である。
• ORCは検査材料単位や検査グループ単位に用いることが望ましい。。例えば１オーダーで検査材料が血液と尿の複数材料を扱う場合、血液を用いる検査で一つのORCとOBRで検査グループを表現し続くOBXで個々の検査項目を、尿を用いる検査で一つのORCとOBRで検査グループを表現し続くOBXで個々の検査項目を指示する。またOBRで多項目検査の内容が不明確な場合、OBXで個々の検査項目を指示することも可能である。例えばOBRで肝炎セット、OBXでGOT,GPT,HBsや、OBRで100g糖負荷試験、OBXで血糖前値,血糖30分値など。
• 検体検査の検査項目コード(OBR-4/OBX-3)は日本臨床病理学会臨床検査項目分類コードでコーディングされたものを用いる。
• 検査材料や部位(OBR-15)は日本臨床病理学会臨床検査分類コード材料コードを用いる。
• OBXは検査結果セグメントであるが、依頼の際に検査に必要な臨床データを知らせる目的でも利用できるものとする。例えば身長、体重、月経周期など。

4.2 臨床検査結果

臨床検査結果報告時には検査結果メッセージ(ORU)を用い、その場合のセグメントと構文規則は以下のとおりである。

ORU - 検査結果メッセージ

ORU Observational Results

MSH Message Header

{

PID Patient Identification

[{NTE}] Notes and comments( for PID)

[PV1] Patient Visit

{

[ORC] Order common

OBR Observations Report ID

[{NTE}] Notes and comments( for OBR)

[ {

OBX Observation/Result

[{NTE}] Notes and comments( for OBX)

} ]

}

}

注:　[ ]は省略可能、{ }は繰返し可能をを示す。

• MSHは検査結果の出力単位に先頭に一つ必要である。
• PIDは１患者の一連の検査結果に１個必須である。検査結果がまとめて伝送される場合PIDが患者毎の区切りとなる。
• OBRは検査依頼の情報とともに検査の状況や実施者の情報をセットして通知するため必須である。
• 検体検査の検査項目コード(OBR-4/OBX-3)は日本臨床病理学会臨床検査項目分類コードでコーディングされたものを用いる。
• OBXは臨床検査報告の最少単位即ち個々の検査結果や検査診断情報毎に１個使用する。
• 個々の検査結果に対する検査所見などのコメントは検査項目ID接尾辞をもったOBXで扱うことを推奨する。
• ORCは必要ない限り省略することを薦める。

4.3 臨床検査依頼ORM・検査結果ORUの例

３日間朝心電図をとるのオーダー　ORM message:

MSH|...

PID|...

ORC|NW|A226677^PC||946281^PC||N|3^QAM||198801121132|P123^AQITANE^ELLINORE^""^""^""^MD|||4EAST<CR>

// EKG order

OBR||||93000^EKG REPORT||||||||||||P030^SMITH^MARTIN^""^""^""^MD|||||||||||3^QAM<CR>

３日間朝心電図の結果報告　ORU message:

MSH|...

PID|...

ORC|PA|A226677^OE|89-450^EKG|... // original order's ORC.

OBR||||93000^EKG REPORT|... // original order segment

ORC|CH|A226677^OE|89-451^EKG<CR> // 1st child ORC.

OBR||||93000^EKG REPORT|... // 1st EKG child OBR.

OBX||ST... // 1st EKG report

...

ORC|CH|A226677^OE|89-452^EKG<CR> // 2nd child ORC.

OBR||||93000^EKG REPORT|... // 2nd EKG child OBR.

OBX||ST... // 2nd EKG report

...

ORC|CH|A226677^OE|89-453^EKG<CR> // 3rd child ORC.

OBR||||93000^EKG REPORT|... // 3rd EKG child OBR.

OBX||ST... // 3rd EKG report

...

患者特有の臨床情報を伴った検査依頼の例

クレアチニンクリアランスのための身長体重の報告

MSH|...

PID|...

ORC|NW|... // New order.

OBR||P42^PC||98142.1^Creatinine Clearance|...

OBX||ST|1010.1^Body Weight||62|kg<CR>

OBX||ST|1010.3^Height||190|cm<CR>

ORC|NW|... // Next order.

...

検査結果　電解質，血算，培養，感受性の例

MSH|...

PID|...

　電解質:

OBR|1|870930010^OE|CM3562^LAB|80004^ELECTROLYTES|R|198703281530|198703290800|||

401-0^INTERN^JOE^^^^MD^L|N|||||SER|^SMITH^RICHARD^W.^^^DR.|(319)377-4400|

||||198703311400|||F<CR>

OBX|1|ST|84295^NA||150|mmol/l|136-148|H||A|F|19850301<CR>

OBX|2|ST|84132^K+||4.5|mmol/l|3.5-5|N||N|F|19850301<CR>

OBX|3|ST|82435^CL||102|mmol/l|94-105|N||N|F|19850301<CR>

OBX|4|ST|82374^CO2||27|mmol/l|24-31|N||N|F|19850301<CR>

　血算:

OBR|2|870930011^OE|HEM3268^LAB|85022^CBC|R|198703281530|198703290800|||401-0 ^

INTERN^JOE^^^^MD^L|N||||BLD|^SMITH^RICHARD^W.^^^DR.|(319)377-4400|||||
198703311400|||F<CR>

OBX|1|ST|85018^HGB||13.4|GM/DL|14-18|N||S|F|19860522<CR>

OBX|2|ST|85014^HCT||40.3|%|42-52|L||S|F|19860522<CR>

OBX|3|ST|85041^RBC||4.56|10*6/ml|4.7-6.1|L||S|F|19860522<CR>

OBX|4|ST|85021.11^MCV||88|fl|80-94|N||S|F|19860522<CR>

OBX|5|ST|85021.21^MCH||29.5|pg|27-31|N||N|F|19860522<CR>

OBX|6|ST|85041.25^MCHC||33|%|33-37|N||N|F|19860522<CR>

OBX|7|ST|85048^WBC||10.7|10*3/ml|4.8-10.8|N||N|F|19860522<CR>

OBX|8|ST|85048.18^BAND NEUT.%||2|%||||F<CR>

...

　血液培養の親報告

OBR|4|2740X^OE|BC376^MIC|87040^Blood culture|R|198703280600|198703290800|||

99-2^JONES&COLLECTOR|N|Hepatitis risk||198703290830|Bld|4010^INTERN^JOE^^^^MD^L|
X3472|||||198703301000|35.00|MB|F|<CR>

OBX|1|CE|87040^Blood culture|1|^E Coli|||A||F<CR>

OBX|2|CE|87040^Blood culture|2|^S Aureus|||A||F<CR>

　細菌培養の子報告　第１親ＯＢＸの感受性試験結果

OBR|5|2740X^OE|BC402^MIC|87186^Antibiotic MIC|R|198703281230|198703290800||||G|

Hepatitis risk||198703290830|Bld|401.0^INTERN^JOE^^^^MD^L|X3472|||||

198703310900|40.00|MB|F|87040^1|||2740X&OE^BC376&MIC<CR>

OBX|1|ST|87186.2^Ampicillin MIC||<2|ug/ml||S|||F<CR>

OBX|2|ST|87186.5^Carbenicillin MIC||<16|ug/ml||S|||F<CR>

OBX|3|ST|87186.21^Gentamicin MIC||<2|ug/ml||S|||F<CR>

OBX|4|ST|87186.33^Tetracycline MIC1||<1|ug/ml||S|||F<CR>

OBX|5|ST|87186.29^Piperacillin MIC||<8|ug/ml||S|||F<CR>

OBX|6|ST|87186.15^Cefuroxime MIC||<2|ug/ml||S|||F<CR>

...

5. 関連情報詳細

5.1 検査項目コードについて

OBR-4,OBX-3には下記で定義された検査項目コードを使用するものとする。

日本臨床病理学会　臨床検査項目分類コード第９回改訂第２版（JLAC9）1996.10

臨床検査項目分類コード　基本コード体系

1. 分析物コード:検査対象物質、例外として反応名を適用の場合がある。

[例]白血球、アレルゲン特異IgE、潜血反応、ＺＴＴ、心電図検査

1. 識別コード:分析物コードを検査内容によって細分する必要がある場合使用。

[例]負荷試験時間、ウイルスの分類、アレルゲンの分類、薬剤感受性

1. 材料コード:同一項目における検査材料の別を分類する。

[例]001尿、004蓄尿、018全血、022血漿、023血清

1. 測定法コード:同一項目における測定法の別を分類する。

[例]ﾗｼﾞｵｲﾑﾉｱｯｾｲ二抗体法、紫外吸光度法、嫌気性培養

1. 結果識別コード:結果表現の含意するところを明示する。

[例]共通コード　01定量値、11判定、28クレアチニン補正値

　　固有コード　3B025 CKｱｲｿｻﾞｲﾑ：51 BB、52 MB、53 MM、54 ｱﾙﾌﾞﾐﾝ

検 査 項 目 コ ー ディ ン グ 例 　単 純 ヘ ル ペ ス

分析物： 単純ヘルペス ５Ｆ１９０

識別： ウイルス抗体 １４３０

材料： 血清 ０２３

髄液 ０４１

測定法： ＣＦ法 １４１

ウイルス中和法 １５１

結果識別： 希釈倍率（共通） ０５

ＨＳＶ−１抗原（固有） ５１

ＨＳＶ−２抗原（固有） ５２

髄液単純ヘルペスCF抗体価：

５Ｆ１９０−１４３０−０４１−１４１−０５(希釈倍率)

血清単純ヘルペス中和抗体価：

５Ｆ１９０−１４３０−０２３−１５１−５１(HSV-1抗原)

５Ｆ１９０−１４３０−０２３−１５１−５２(HSV-2抗原)

臨床検査項目分類コードの利用

　臨床検査項目分類コードは５つの基本コードを組合せ、実際の検査項目コードとして使用する。検査依頼時では結果識別コードを除く１５桁で表現され、結果報告時ではさらに結果識別コードが追加され１７桁で表現される。

検査項目コードと検査材料の関連

　検査項目コード中に材料が設定されているが、これはあくまで一つの検査項目測定系を示すものである。したがって、検査データを扱うシステムでは検査項目フィールドと検査材料フィールドを別に持つべきである。ＨＬ７−ＯＢＲ／ＯＢＸで用いる場合、検査項目フィールドにはオーダーする検査項目を示すコード（すなわち商品コードのような性格）、検査材料フィールドには実際に提出する材料コードを設定する。

検査項目コード事例集

　臨床検査項目分類コードを実際に組み合わせ検査項目コードを付番するのは様々な解釈もあり容易ではない。そこで一般に使用されている検査項目について付番したものを1997.10に公表予定である。（1997.2現在、付番の調整は終了し代表材料について調整中である。）

5.2 検査材料・部位コードについて

OBR-15では下記で定められた材料コードを使用するものとする。

日本臨床病理学会　臨床検査項目分類コード　材料コード 　Ver. 9.2

［材料コード適用細則］

1. 材料コードの選択は，一般の生体成分分析等においては“材料コード�T”によるものとし，細胞診・生理機能検査等に使用される“組織の詳細および生体部位”については“材料コード�U”に，その他の非生体材料については“材料コード�V”による。
2. ｢尿｣および｢血液｣について
   特別な場合を除き，尿は｢尿(含むその他の尿)｣(001)および｢蓄尿｣(004)を，血液は｢全血｣(018)，｢血漿｣(022)および｢血清｣(023)に分類することが望ましい。
3. ｢全血(添加物入り(019)｣について
   抗凝固剤，抗血小板剤等の添加物により検査材料の安定化を必要とする検査項目に適用する。
4. ｢ペア材料｣(098)について
   複数の異なる検査材料を必要とする検査項目に適用する。
   [適用例]各種クリアランス試験

　組織及び生体部位は200〜990の3桁で定義し，生検，及びそれぞれの切除組織は，下記のように定義する。

例 皮膚　生検組織　　⇒201

胃　　生検組織　　⇒456

生検組織　　　⇒　○○1or○○6 骨　　試験切除組織⇒252

試験切除組織　⇒　○○2or○○7 膀胱　試験切除組織⇒667

手術切除組織　⇒　○○3or○○8 膣　　手術切除組織⇒553

剖検切除組織　⇒　○○4or○○9 虫垂　手術切除組織⇒478

肺　　剖検切除組織⇒334

小脳　剖検切除組織⇒719

5.3 Message Delimitersメッセージ区切り文字

　メッセージを構成する場合に特殊文字が使われる。セグメント・ターミネータ、フィールド・セパレーター、成分セパレーター、副成分セパレーター、反復セパレーター、エスケープ文字である。セグメント・ターミネータは必ずキャリッジ・リターン（ASCII、１６進0D）である。その他の区切り文字はMSHレコードで定義されている。つまり、フィールド区切り文字は4番目の文字位置で定義され、その他の区切り文字は、コード化文字と呼ばれる、セグメントIDの後の最初のフィールドで定義されている。MSHセグメントで使われる区切り文字の値は、メッセージ全体にわたって使われる。特に理由がなければ、HL7は図2-1にリストした示唆値を推奨する。

Figure 2-1. Delimiter values区切文字の値

Segment Terminator　セグメントターミネータ

セグメント区切りセグメント区切りは毎セグメントの最終文字である。それはいつもASCIIの改行文字で(16進0D)である。

Field Separator　フィールドセパレータ

HL7のフィールドセパレータはセグメント内の隣接したデータフィールドを分離する。それはまたセグメントIDを最初のデータフィールドから分離する。フィールドセパレータを表す値は各メッセージ毎に違えて定義してもよい。MSHセグメントの第４文字はそれがどんな文字であっても、そのメッセージ中はフィールドセパレータとして働く。特別な理由がないかぎり、どのアプリケーションもフィールドセパレータとして"|"を用いることを薦める。

Component Separator 成分セパレータ

成分セパレータは、あるデータフィールドの隣り合った成分を区別するセパレータために使われる。その使用法は、関連するデータフィールドの記述に述べられている。成分セパレータはを表現するキャラクタは、ＭＳＨセグメントのエンコーディングキャラクタの最初のキャラクタとして各メッセージ毎に決められる。特別の理由がないかぎり、すべての送信アプリケーションは、成分セパレータとして"^"を推奨する。

Repetition Separator反復セパレータ

反復区切りはあるデータフィールドのおいて、複数の発生事象を区切るため用いられる。それは特別に認められた適切なデータフィールドに限り用いられる。反復区切りを示す文字はMSHセグメントのコード化文字の二番目の文字で示される。特に定めのない限り反復区切りとして"~"が用いられる。

Subcomponent Separator副成分セパレータ

副構成要素区切りはあるデータフィールドの隣接する副構成要素を区切るのに用いられる。その使用は関連するデータフィールドに説明されている。副構成要素区切りとして出現する文字はMSHセグメントのコード化文字データフィールドの第四文字に指定される。特に定めのない限り副成分区切りとして"&"が用いられる。

Escape Character　エスケープ文字

テキストフィールド（TXまたはFT型）では、エスケープ文字のような他の特殊文字も許可されます。TXまたはFTフィールドで許可されるどのような文字も、エスケープ文字とすることができる。エスケープ文字を表している単一の文字は、MSHセグメントの符号化文字データフィールドの3番目の文字として指定する。このフィールドはオプションです。エスケープ文字を使う必要のないアプリケーションではこの文字は省略できます。しかし、副成分セパレータがメッセージの中で使われるならば、存在せねばならない。他に考慮する必要がなければ、エスケープ文字として"\"を使用することが推奨されます。

注：区切り文字で囲まれる文字列中でASCII以外の文字セットを使用の場合、区切り文字に先立ちASCII文字セットにもどすこと。もし区切り文字が検出された場合は文字セットはASCIIへリセットしたものとみなす。

5.4 Data types データ型

Figure 2-2. HL7 data types

* for subcomponents of these elements please refer to the definition in the text.

Data types データ型解説(抜粋)

ST　文字列データ

文字列データは、左詰めにされこれに空白がうしろに続いてもよい。任意の表示可能な（印刷可能な）ASCII文字（20から7Eまでの16進値）である。例：|almost any data at all|

TX　テキスト・データ

文字列データは、ユーザーに対し表示するためにある（ターミナルまたはプリンターによって）。文字列に先行空白を挿入した方がユーザが見やすいということもあるので、文字列は必ずしも左詰めにするわけではない。この種のデータは表示することが目的なので、表示装置を制御するためのエスケープ文字シーケンスを含むことがある。先行空白文字を挿入し、後書き空白を取り除くとよい。　例：| leading spaces are allowed.|
TXデータは表示するためにあるので、反復区切文字をTXデータ・フィールドで使うと、それは一連の反復行がプリンターまたはターミナル上に表示されることを意味する。したがって反復区切文字は、パラグラフ・ターミネータまたはハード・キャリッジ・リターンとみなされる。（そのテキスト内にCR/LFが挿入されたように表示される）。
受信システムでは、任意の大きさの表示ウィンドウに合わせるためテキストを繰り返し区切り文字間でワードラップするが、繰り返し区切り文字で始まる行はすべて新たな行になる。

FT　フォーマット化テキスト・データ

このデータ型は、フォーマット指示を埋め込み追加することで文字列データ型を拡張したものである。これらのフォーマット指示は固有であり、フィールドの使用環境から独立している。実際の指示とその表記法は本章の後半で説明する。文字列データ・フィールドとFTフィールドとの違いは、長さが任意（65kまで）であることと、エスケープ文字で囲まれたフォーマット・コマンドを含むことである。　例：|\.sp\(skip one vertical line)|

NM　数字

ASCII数字列として表記される数字は、オプションの先行符号（＋または−）、数字、そしてオプションの小数点から構成される。符号がない場合、その数値は正数であると仮定される。小数点がない場合、その数値は整数であると仮定される。　例：|999|　　|-123.792|
先行ゼロまたは小数点の後の後書きゼロは無意味である。01.20と1.2という２つの数値は同一である。オプションの先行符号（＋または−）およびオプションの小数点（．）を除いては、数字以外のASCII文字は許されない。したがって、値“<12”は、文字列データ型としてコード化しなければならない。

DT　日付

常にフォーマットYYYYLLDDで表記。　例：|19880704|

TM　時間

24時間表記法による、フォーマットHHMM[SS[.SSSS]][+/-ZZZZ]を常に使用する。秒指定（SS）はオプションである。存在しない場合、それは00と解釈される。小数の秒指定は同様にオプションである。存在しない場合、それは.0000と解釈される。小数の秒は、秒より高い精度の時間を必要とする場合に送信される。分、時間、またはそれ以上の時間単位を小数で表記することはできない。発信者の時間帯は、万国標準時（以前はグリニッジ標準時として知られていた）からのオフセットとしてオプションで送られることがある。発信者の時間帯が特定のTMフィールドに存在しないが、MSHセグメントの日時フィールドの一部として含まれる場合は、MSH値がデフォルトの時間帯として使われる。それ以外の場合、その時間は発信者の現地時間を参照するものと解釈される。真夜中は0000と表記する。　例：
|235959+1130| 1 second before midnight in a time zone eleven and half hours ahead of Universal Coordinated Time (i.e., east of Greenwich).
|0800| Eight AM, local time of the sender.
|093544.2312| 44.2312 seconds after Nine thirty-five AM, local time of sender.

TS　タイム・スタンプ

日付と時間を含む、イベントの正確な時間から成る。タイムスタンプのフォーマットは、必ずつぎのようなものである。
YYYYLLDD[HHMM[SS[.SSSS]]][+/-ZZZZ]^<精度>
タイム・スタンプの日付部は日付フィールドの規則に従う。時間部は時間フィールドの規則に従う。誕生日として使われるとき、HHMM部はオプションである。存在しない場合、HHMM部はデフォルトで0000、すなわち、まさに明けようとしているその日の真夜中になる。HL7コード化規則の中で使われる特定のデータ表記はISO 8824-1987(E)との互換性がある。オプションの秒成分はその日付の精度を示す（Y = 年、L = 月、D = 日、H = 時間、M = 分、S = 秒）。（フィールドの最大長は26である）。例:
|17760704010159-0600| 1:01:59 on July 4, 1776 in the Eastern Standard Time zone.
|17760704010159-0500| 1:01:59 on July 4, 1776 in the Eastern Daylight Saving Time zone.
|198807050000| Midnight of the night extending from July 4 to July 5, 1988 in the local time zone of the sender.
|198807050000^D| Same as prior example, but precision extends only to the day. Could be used for a birthdate.
HL7規格では、すべてのシステムが日常的に時間帯オフセットを送るよう強く推奨するが、強制はしない。HL7システムではすべて時間帯オフセット受け入れる必要があるが、その実装はアプリケーションに任される。多くのアプリケーションの場合、関心ある時間はその発信者の現地時間である。たとえば、東部標準時間帯にあるアプリケーションが12月11日午後11:00にサンフランシスコで入院が発生したという通知を受けた場合、その入院を12月12日ではなくて（現地時間の）12月11日に発生したものとして扱うのがよい。
この規則における一つの例外は、臨床システムが、互いに近くに存在しながら時間帯の異なる複数の病院で収集された患者データを処理する場合である。そのようなアプリケーションは、そのデータを共通の表記に変換することがある。同じような問題は、サマータイムとの切り替え時にも発生する。HL7は、情報の送信時に時間帯情報を含めるよう要求することでそのような要件に対応する。しかし、ここで検討した処理のどちらを受信システムが採用するかは指定しない。

ID　コード化値

この種のフィールドで使う値は、正当な値のテーブルから引用される以外はSTフィールドで使うフォーマット規則に従う。IDフィールドの例として宗教、性別などがある。

SI　シーケンスID

NMフィールド形式の正整数。このフィールドの使用方法は、それが現れるセグメントとメッセージを定義している章で定義する。

CM　複合フィールド

他の有意データ・フィールドと組合せるフィールド。それぞれの部分は成分と呼ばれる。CMフィールドの特定成分は、そのフィールド記述の範囲内で定義される。その他個別に識別される複合フィールドもあり、それについては以下に記述する。このデータ型の使用は発展的に解消し、独自のデータ型を新たに作成する予定である。
HL7フィールドの成分そのものが成分を含むHL7データ型である場合、その区切り文字は一ランク下位に落とされる。したがって、CEデータ型として示された成分は、<識別子＆テキスト＆コーディング方式名>としてコード化すべきである。HL7区切り文字は再帰的でないので、成分を含むHL7データ型は副成分となりえないことに注意。このレベルの詳細情報が必要な場合、HL7データ型の各成分は、別々の副成分としてコード化することができる。この例に関しては、タイミング／数量データ型のオーダーシーケンス化成分にある実施者オーダー番号のコード化方式を参照のこと。

CK チェック・ディジット付き複合ID

<ID番号(NM)> ^ <チェック・ディジット(NM)> ^ <採用チェック・ディジット・スキーマを識別するコード(ID)> ^ <割り当て施設ID(ST)>
このデータ型は、たとえばPID-3-患者ＩＤ（内部ID）など、通常チェック・ディジットを含むフィールドで使われる。現場で、あるCKフィールドにチェック・ディジットを使っていない場合、第２、第３成分は評価されない。
このデータ型のチェック・ディジットは、メッセージ処理システムが追加生成するわけではない。それは、送信アプリケーション内で使われる識別番号に含まれる。送信アプリケーションが識別番号内に自己生成チェック・ディジットを含まない場合、この成分はnullとして評価すべきである。
割当施設IDは、データを保管するシステムの一意な名前（最大長6文字）である。それはSTデータ型であり、その依頼者（または実施者）オーダー番号のアプリケーションＩＤに等しい（第4章を参照）。割当施設ＩＤは、与えられたHL7実装システム全体にわたって一意である。
チェック・ディジット・スキーマ・コードは、テーブル0061　−　チェック・ディジットスキーマで定義する。表 　0061 　チェック・ディジット・スキーマ値　　　　　　記述M10　　　　 　Mod 10 アルゴリズムM11　 Mod 11 アルゴリズム

例： |128952^6^M11^ADT01|
Mod10チェック・ディジットを計算するためのアルゴリズムは以下の通り

あなたが識別子=12345を持つと仮定する。右側から数えて奇数桁、つまり531を考える。この数を２倍して1062を得る。右から数えて偶数桁、すなわち42を取り、これに1062を付けたして421062を得る。この数字の6桁すべてを加算して15を得る。15の次に大きい10の倍数からこの数を減ずる、つまり20-15により5を得る。これがMod10チェック・ディジットである。401の場合のMod10チェック・ディジットは0である；9999の場合は4である；99999999の場合は7である。
Mod11チェック・ディジットを計算するためのアルゴリズムは以下の通り
用語
d = １の位から始まり、以降１０の位、１００の位、．．．と続く各位の数字

w = １の位から始まり、以降１０の位、１００の位、．．．と続く各位の重み。Wの値は2、3、4、5、6、7、2、3、4、5、6、7、．．．と続く（6桁単位で繰り返す）
c = チェック・ディジット
計算
（ステップ1） m = １の位から開始し、それぞれの位について計算した（d * w）の合計
　　　　　　　　d = １の位から最高桁の位までの各桁の数字
　　　　　　　　w = １の位から始まり、６桁単位で繰り返す２から７までの各桁の重み
（ステップ2） c1 = m mod 11
（ステップ3） 　c1 =０の場合はc1 =１に置き換える。
（ステップ4） c =（11−c1） mod 10
例: if the number is 1234567, then the mod 11 check digit = 6
計算は以下の通り
m =（7*2）+(6*3)+(5*4)+(4*5)+(3*6)+(2*7)+(1*2)
= 14 + 18 + 20 + 20 + 18 + 14 + 2
= 106
c1 = 106 mod 11
= 7
c = (11-c1) mod 10
= 4 mod 10
= 4
上記以外のチェック・ディジット計算アルゴリズムが存在して、現地双方の取り決めにより使うことができる。

CQ　単位付き合成量

<数量>^<単位>
第１成分は数量である。第２成分はその数量の単位である。デフォルトの単位で検査を測定した場合、その単位は送信する必要ない。その単位がISO+単位であるなら小文字の省略形を使用するとよい 。その単位がANSIまたはローカル定義のものならその単位とソース・テーブルを記録しなければならない。 例：
|123.7^kg| kilograms is an ISO unit
|150^lb&&ANSI+| weight in pounds is a customary US unit defined within ANSI+.

CE　コード化要素

このデータ型は、コード、およびそのコードと関連するテキストを送る。この型は、次に述べる通り、２つのグループに整備された6個の成分を持つ：
〈識別子〉＾〈テキスト〉＾〈コーディング方式名〉＾〈代替識別子〉＾〈代替テキスト〉＾〈代替コーディング方式名〉
CEデータ型の6成分すべてを設定すると、このデータ型の長さは少なくとも60になる。
以下のように定義される：
　識別子：　後ろの<text>によって参照される項目を一意に識別する文字列（コード）。異なるコーディング・スキーマでは、異なる要素を持つ。
　テキスト：　問題としている項目の名前または記述。たとえば、心筋梗塞とかＸ線撮影所見など。そのデータ型は文字列（ST）である。
　コーディング方式名：　コーディング方式には一意な識別子が割り当てられる。この成分は、識別子成分内で使われているコーディング・スキーマを識別するのに役立つ。識別子成分とコーディング方式名成分の組合せは、データに対して一意なコードである。下位互換性のため、この成分がない場合は、ASTM拡張子を持つCPT-4、つまりAS4を意味すると解釈される。ここに指定されるその他のコーディング方式は、ICD-9、ICD-10、SNOMEDなどである。各方式には一意な識別文字列が与えられる。現在の「ASTM 1238ｰ88診断/手順/検査/薬剤ID/健康結果」コーディング方式は、以下のテーブルで識別される。その他の方式は必要に応じて追加される。
　代替成分：　これらの３つの成分は、上記と同様、代替方式または現地コーディング方式を定義するためにある。代替テキスト成分が存在せず、代替識別子が存在すると、代替テキストはテキスト成分と同じであると解釈される。代替コーディング方式成分が存在しない場合、それはローカル定義の方式であると解釈される。

注記：　このデータ型では２組の等価コードを表現しているが、それはCE型フィールドの反復とは意味が違っている。反復を用いる場合は、いくつかの明瞭なコード（明瞭な意味を持つコード）を送信するのが普通である。

例：|54.21^Laparoscopy^I9^42112^^AS4|

CF　フォーマット値付きコード化要素

このデータ型は、コード、およびそのコードと関連するフォーマット化テキストを送る。このデータ型は、レポートの詰め込みテキスト部に使用するフォーマット化テキスト（たとえば、単純胸部Ｘ線について標準的に記述された放射線所見など）を初めて送る場合に使用する。受信システムは、この情報を保存し、次のメッセージではその識別子だけを送信すればよい。このデータ型のもう一つの考えられる使用法は、フォーマット化テキストを含むマスターファイル・レコードを送ることである。
このデータ型は、以下のような2つのグループ化から成る6個の成分を持つ：
<識別子> ^ <フォーマット化テキスト> ^ <コーディング方式名> ^ <代替識別子> ^ <代替フォーマット化テキスト> ^ <代替方式名>
主要成分、代替成分とも、第２成分および第５成分がフォーマット化テキスト・データ型であるという点を除いて、CEデータ型の場合と全く同様に定義される。例：
OBX||CF|71020^CXR^CPMC||79989^
\H\Description:\N\\.sp\\ti+4\Heart is not enlarged. There is no evidence of pneumonia, effusion, pneumothorax or any masses.\.sp+3\\H\Impression:\N\\.sp\\.ti+4\Negative chest.^CPMC

RP　参照ポインタ

このデータ型は、別のシステムに保存されているデータの情報を伝送する。このデータ型には、そのシステムに保存されているデータを一意に識別する参照ポインタ、そのシステムの識別、およびデータの型が含まれる。　<ポインタ> ^ <アプリケーションID> ^ <データの型>
　ポインタ：　データを保存するシステムが割り当てる一意なキー。そのキーはSTデータ型であり、データを識別しそのデータにアクセスするのに使う。
　アプリケーションID：　データを保存するシステムの一意な名前 (最大長６文字)。それはSTデータ型である。依頼者（または実施者）アプリケーションIDに同じ。
　データ型：　保存データの型を表すコードで、それはID データ型である。

表0191　データの型

値 記述

SI スキャンされた画像

NS スキャンされない画像

SD スキャンされた文書

TX 機械で読めるテキスト文書

FT フォーマットされたテキスト

その他の型は必要に応じて追加する。　例：　|1234A321634BC^EFC^SD|

TQ　タイミング数量

サービスの実施時期とその頻度を指定する。数量／タイミング定義を参照のこと。

XCN　拡張複合ID番号と名前

〈ＩＤ番号〉＾〈姓〉＾〈名〉＾〈ミドルネーム（イニシャルも可）〉＾〈接尾辞（たとえばＪＲ）〉＾〈接頭辞（たとえばＤＲ）〉＾〈学位（たとえばＭＤ）〉＾〈ソーステーブル〉 ^ <割当て権限者> ^ <名前タイプコード> ^ <チェックデジット> ^ <チェックデジット方法> ^ <識別タイプコード> ^ <割当て施設>
割当て権限者の副成分 : <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
割当て施設の副成分 : <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
コード値およびテキスト名により人物を識別するフィールド。第１成分は、現場固有のテーブルに従ってコード化されたIDである。第２成分から第７成分は人物名を表すPNフィールドである。第８成分は、第１成分で使われるソース・テーブルを指定する。特定のフィールドでは、それぞれの現場でIDまたは名前を省略することができる。
例: |12372^RIGGINS^JOHN^""^""^""^MD^ADT1|
|12372|
|^RIGGINS^JOHN^""^""^""^MD|

XPN　拡張人名

〈姓〉＾〈名〉＾〈ミドルネーム（イニシャルも可）〉＾〈接尾辞（たとえばＪＲ）〉＾〈接頭辞（たとえばＤＲ）〉＾〈学位（たとえばＭＤ）〉＾〈名前タイプ〉＾〈名前表示コード〉
上にリストしたように、名前は複数のフリーテキスト成分から成る。PNフィールドの最大長は、成分セパレーターを含めて48文字である。送信システムは大文字と小文字の混合、またはすべて大文字を送ることができる。必要なら、受信システム側ですべて大文字に変換してもよい。　例：|Smith^John^J^III^DR^PHD^L|
Name type code (ID) 　Table 0200 - Name type

Value	Description
A	Alias Name
L	Legal Name
D	Display Name
M	Maiden Name
C	Adopted Name

Name representation code (ID) Table 4000 - Name representation

Value	Description
I	Ideographic (i.e., Kanji)
A	Alphabetic (i.e., Default or some single-byte)
P	Phonetic (i.e., ASCII, Katakana, Hirigana, etc)

PL　患者所在

成分: <看護単位> ^ <部屋> ^ <ベッド> ^ <施設> ^ <場所の状況> ^ <所在場所のタイプ> ^ <建物> ^ <階> ^ <場所の詳細>
患者の所在場所やその状況を表現する。看護単位とは診療場所や部門をいう。部屋とは診療室や病室をいう。場所の状況でベッドのあき状況などを表示する。所在場所のタイプをコードで表現する。

5.5 QUANTITY/TIMING (TQ) DEFINITION　数量／タイミング定義

成分： <数量>^<時間間隔>^<継続時間>^<開始日時>^<終了日時>^<優先度>^<条件>^<テキスト>^<連結>^<オーダーシーケンス化>

定義： 数量／タイミング（ORC-7,OBR-27）は、オーダーセグメントによって述べられたサービスがいつ，どのような頻度で行なわれるかを規定する手段を与える。それは、繰り返しを持つことができる複合多重成分フィールドである。すなわち複数回の数量／タイミング指定が、区切り文字で分離されて現れる。数量／タイミング指定の成分を、以下に述べる。

Quantity component 数量成分 (CQ)

Subcomponents: 副成分： <数量&単位>

定義： 各々のサービス間隔で供給される必要があるサービスの量。たとえば2つの血液培養が4時間毎に得られるとすれば、数量が2である。もし3ユニットの血液が血液型を調べクロスマッチされるならば、数量は3である。デフォルト値は1である。単位が要求される時、後ろの成分で限定するものによって明示され加えられる。

Interval component 時間間隔成分 (CM)

Subcomponents: <繰り返しパターン&明確な時間間隔>

定義：繰り返されるサービスの時間間隔を決める。デフォルトは１回のみである。第１副成分は繰り返しパターンである。第２副成分はパターンが実行される明確な時間である。

　　Repeat pattern繰り返しパターン

User-defined table 4001 - Repeat pattern

Q<integer>S	every <integer> seconds秒毎
Q<integer>M	every <integer> minutes分毎
Q<integer>H	every <integer> hours時間毎
Q<integer>D	every <integer> days日毎
Q<integer>W	every <integer> weeks週毎
Q<integer>L	every <integer> months (Lunar cycle)月毎
Q<integer>J<day#>	特定の曜日に繰り返す。Jはフランス語のjour（day）から。もし<整数>がないならば、繰り返しレートは１と仮定する。日付の番号は、1=月曜日から7=日曜日までカウントする。それゆえQ2J2は第2火曜日毎、Q1J6は、土曜日毎を意味する。
BID	1日2回、施設が決めた時刻（たとえば、9AM-4PM）
TID	1日3回、施設が決めた時刻（たとえば、9AM-4PM-9PM）
QID	1日4回、施設が決めた時刻（たとえば、9AM-11AM-4PM-9PM）
xID	1日"X" 回、施設が決めた時刻、Xは数字5より大。(例えば5ID=一日5回、8ID=一日8回)
注：上記の4つの指定はいずれもそのQ<整数>H対応と同等ではない。たとえばQIDは、Q6Hではない。前者は不等間隔に置かれる；後者は等間隔に置かれる。
QAM	朝に、施設が決めた時刻に。
QSHIFT	3回の8時間シフトの各々の間で、施設が決めた時刻に。
QOD	隔日（Q2Dと同じ）
QHS	毎日就寝前に。
QPM	夕方、施設が決めた時刻に。
C	サービスの提供は連続的に初めの時刻から終わりの時刻まで
U <spec>	スペック） 将来使用のため。<スペック>がUNIXのクローンで定義された時間隔仕様である場合。
PRN	必要に応じて与えられる。
PRNxxx	xxxがなんらかの頻度コード（たとえば、（PRNQ6H））；必要に応じて頻度期間にわたって与えられる。
Once	一度だけ。これは、この成分がnullである時、デフォルトである。

　　Explicit time interval subcomponent明確な時間間隔の副成分

定義： 次のフォーマットにおいて、第１副成分のコードによって参照された実際の時刻を明確にリストする：HHMM,HHMM,HHMM,...。この第２副成分は、実際の投薬時刻が施設内で変化する場合等、第１副成分を明らかにするために使用される。オーダーの期間が1日を超えるならば、この新しい副成分が実際に役立つのは次の場合に限る。すなわち同じ投薬時刻がオーダーの各々の日に対して発生する場合である。オーダーの実際の開始時刻（数量／タイミングフィールドの第４副成分によって与えられる）が、リストの最初の明確な時刻の後であるならば、最初の投薬は、開始時刻の後の最初の明確な時刻とする。患者が明確な時間の異なったセットを持っている場所へ移動する場合、現在のオーダーは、変更された明確な時間を示している新しい数量／タイミングフィールドで更新される。
Ex: 数量／タイミングフィールドの第2成分：
　　...^QID&0230,0830,1430,2030^...

Duration component継続時間成分

定義： サービスが開始された後で、サービスがどのくらい長く続くかを示す。デフォルトは、INDEF（不定）である。この成分は、以下の通りにコード化される：

S<integer>	=	<integer> seconds　秒
M<integer>	=	<integer> minutes　分
H<integer>	=	<integer> hours　時間
D<integer>	=	<integer> days　日
W<integer>	=	<integer> weeks　週
L<integer>	=	<integer> months　月
X<integer>	=	オーダーで指定された時間間隔成分の繰り返し回数。2つの血液培養に対する要求Q2H　X3、2つの血液培養を3つの異なった時刻に2時間おきに入手して合計6つの血液培養を入手するという意味である。
T<integer>	=	明記されている時間間隔と量で、合計の<整数>『DOSAGE』が蓄積されるまで。単位は、「数量」フィールドにおけると同じであると仮定される。
INDEF	=	期間を特に定めない(不定)-同様にデフォルト

Start date/time component 開始日時成分 (TS)

定義：依頼者によって規定される。その場合それはサービスを開始する必要がある最も初めの日時を示す。多くの場合、しかしながら、開始日時は、オーダーレコード（たとえば、（緊急）-STAT）の他のフィールドによって示唆されるか、あるいは定義される。そのような場合、このフィールドは空となる。
実施者サービスは、オーダーを受領後このフィールドの値をしばしば記録する。一方実施サービスの内部使用のために、開始日時を基礎にして終了時刻を計算する

End date/time component 終了日時成分 (TS)

定義：サービスを要求する人によってこの値が指定された時は、このフィールドはサービスが行なわれるべき最後日時である必要がある。ここで明示された時間までに行なわれなかったならば、それは行うべきではない。要求する人がこの値を満たすとは限らない。しかし実施者サービスは、それが受け取る指示および実際の開始時間を基礎として、満たしてもよい。
終了日時の値に関係なく、サービスは、継続時間または終了日時によって指定された最も早い日時に終了すべきである。

Priority component 優先度成分 (ID)

定義：　要求の緊急度を述べる。次の値が提案される（優先度のデフォルトはRである）：

値『T』（タイミングがクリティカル）を使用するならば、クリティカルの程度は次のように明示できる：

Format:

TS<integer>	=	秒以内で
TM<integer>	=	分以内で
TH<integer>	=	時間以内で
TD<integer>	=	日以内で
TW<integer>	=	週以内で
TL<integer>	=	月以内で

オーダーの連続指定の場合、これらの値は、先行オーダーから後に続くオーダー全部に対してタイミングの重要性を規定する。優先度成分を反復する場合はスペースで区切る。

Condition component 条件成分 (ST)

定義： 　これは、投薬条件を記述するフリー・テキストフィールドである。たとえば、「PRN pain」、「血圧を110以下に保て」など。このフィールドにテキストが存在する場合、投薬方法または投薬時期（あるいはその両方）を決定するため人間が見直す必要がある。

Text component テキスト成分 (TX)

定義： 指示（オプショナル）の完全なテキストバージョン。

Conjunction component 連結成分 (ID)

定義：　この成分がnullでなければ、反復区切り文字を使用して、２番目のタイミング指定を後に続ける。このフィールドは３つの値を採ることができる：

a) S = Synchronous 同期

今回の指定の後に次の指定を行う（ＯＲＣ−４＾４−開始日時、およびＯＲＣ−４＾５−終了日時成分により制限を受けなければ）。
”Ｓ”指定は、最初のタイミング・シーケンスの後に２番目のタイミング・シーケンスが続くことを示す。たとえば、最初の１時間はＱ１５分ごとに血圧を測定し、次の日には２時間ごとに血圧を測定するよう依頼する。

b) A = Asynchronous 非同期

今回の指定と並行して次の指定を行う（ＯＲＣ−４＾４−開始日時、およびＯＲＣ−４＾５−終了日時成分により制限を受けなければ）。連結”Ａ”により、投薬時などに散見される、２つの指示の並行指定が可能になる。たとえば、月曜、水曜、金曜にプレドニゾン１錠、火曜、木曜、土曜、日曜には１／２錠。

c) C = This is an actuation timeこれは開始時間である

このコードの後にはサービスの終了時間が続く。このコードにより、サービスを起動すべき（採血など）時間・優先度から、サービスを終了すべき（結果報告など）時間・優先度が区別できるようになる。
連続サービスあるいは循環サービスの場合、サービスを実際に停止するポイントは、成分ＯＲＣ−４＾５−終了日時またはＯＲＣ−４＾３−継続時間の、どちらかより早い停止時間を示す成分により決定される。通常、この２つの成分のうち１つだけが存在する。しかし以下のような指定によりＥＫＧを要求した場合は、反復数（３）のほうがより早い停止時間を定義しているので、ＥＫＧは３日間だけ実施されることになる。

^1^QAM^X3^D10

Order sequencing component (complex)オーダーシーケンス化成分

定義：　実際の現場ではさまざまな状態が想定される。たとえば、あるまとまった点滴（ＩＶ）溶剤を要求するオーダーを作成した場合は、個々の点滴溶剤（各々それ自体が１個のオーダー）のシーケンスを指定する必要がある。
また、“PRN pain”などある種の結果条件がオーダー指示に含まれる、というような状態も考えられる。現在は、ＯＲＣ−４−数量／タイミングのフリー・テキスト“条件”成分により任意の条件を指定することができる。しかし、完全にコード化したオーダー・シーケンスあるいは結果条件をサポートするために、次のパラグラフでＯＲＣ−４−数量／タイミングの第１０番成分を定義した。
この第１０成分のサポートするシーケンス化条件は、あるオーダーの終了に基づく。
第１１成分以降は将来に備えた予約であり、オーダーの実行前に複数の条件を評価するよう指定するのに使用する。将来をにらんだこのような指定により、現在の数量／タイミング定義との上位互換性が保たれる。

注記： 　第１０成分が存在する場合、第７成分（条件成分）は、依頼のさいに表示されるテキスト“注記”とみなされる。すなわちシステムは、このテキストをシーケンス化指定の一部として解釈することはない。

　　シーケンスの副成分

シーケンス条件を定義するために、数量／タイミング・フィールド成分の第１０成分は、図４−７に示す副成分に分割される

使用上の注意：以下を仮定する。
先行オーダーは、「ＯＲＣ−４−数量／タイミング」の第１０成分の副成分２と３において、依頼者オーダー番号としてOE1000&OrdEntにより定義される。
後続オーダー、つまり今回のオーダーは、ＯＲＣセグメントに依頼者オーダー番号OE1001^OrdEntを持つ。

次のシーケンス条件値の意味を説明する。

ES + 10M	｢OE1000&OrdEnt（先行オーダー）の終了時間　＋　１０分」により、後続オーダー、OE1001^OrdEnt（今回のオーダー）の開始時間を定義する；つまり、先行オーダーが終了してから１０分後に、このオーダーを開始せよ、ということ。
SS - 10M	「先行オーダーの開始時間−１０分」によりこのオーダーの開始時間を定義する。つまり、先行オーダーの１０分前にこのオーダーを開始、ということ。

　　循環依頼者グループ

反復すべき循環オーダーがある場合、実行される最初のオーダーは、アスタリスク（＊）で始まる“シーケンス条件値”を持つ。

Example:

*FS+10M	第１０成分に指定された条件を評価せずに、このオーダーを１回実行する。指定された外部オーダーの開始・終了日時がこの条件に合致したときのみその実行を繰り返す。このように指定すると、各サイクルでオーダーが１回反復される。
注記：　オーダーを繰り返すには、依頼アプリケーションは、最初のオーダーの数量／タイミングを指定する際に、サイクル内の最終オーダーの依頼者オーダー番号を指定できなければならない。

親子パラダイムを使用して、４つのＩＶオーダーから成る循環グループを指定するには、親はＩＶのカスタム・グループを指定する。すると、以下のように処理が実行される。

２番目の子オーダーのＯＲＣ−４−数量／タイミングは、それが１番目の子オーダーに続くことを示す。
３番目の子オーダーのＯＲＣ−４−数量／タイミングは、それが２番目の子オーダーに続くことを示す。
４番目の子オーダーのＯＲＣ−４−数量／タイミングは、それが３番目のオーダーに続くことを示す。

４つの子オーダーから成るグループを循環的に繰り返すには次のように処理が実行される。:

１番目の子オーダーのＯＲＣ−４−数量／タイミングは、この子オーダーが、他のオーダーが終了したかどうかとは無関係に、１度実行されることを示す。
この子オーダーが２回目に実行されるのは、４番目のオーダーが終了してからである。

このスキームにより、下記情報を追跡することができる：

親オーダーのレベルで返答すべきオーダー・グループ全体の状態。
対応する子オーダーの状態をフォローすることによって、ＩＶオーダーそれぞれの状態。

個別のオーダー例：同じグループのオーダーは、その数量／タイミング・フィールド内のデータによってのみ連携させることで、４つのオーダー（共通の親のない）を１グループとして送ることができる。この場合ＨＬ７では、グループ全体のオーダー状態をまとめて伝送する便利な手段がないので、４つのオーダーの個々の状態を別々に伝送するしかない。

　　オーダー状態の継承

キャンセル／中断／保留オーダー制御イベント：
ここでは、指定された先行オーダーが通常通り実行されることを想定している。したがって、先行オーダーのキャンセル（あるいは中断、保留）は、後続の関連オーダーすべてを取り消す（あるいは中断する、保留する）ことを意味する。
参照されているオーダーが取り消された（あるいは中止、保留された）場合、今回のオーダーはそれと同じ状態を継承する。
保留の場合、先行オーダーの保留を解除することは、その該当オーダーも解除するという意味である。（したがって、そのオーダーは第１０成分内の指定にしたがって実行することができる。）

Examples of quantity/timing usage数量／タイミングの使用例

3^once

指定時刻にサービスを実行する。たとえば、３単位の輸血を１回実行せよというオーダー。

1^QHS^X2

就寝時にサービスを２回実行する。たとえば、２夜連続、就寝時に１単位の輸血。

1^C^3D

３日間サービスを継続する。

1^Q1H^X4^^^^PVCs>10/min

患者のＰＶＣが毎分１０を越える場合は、最大４回、１時間ごとにＥＫＧを実行する。

1^Q2J^^1432

毎週火曜日、午後２：３２にサービスを実行する。

1^^^^198911210800

11/21/89 0800前に検査を実行する。たとえば手術前の臨床検査。

1^Q3600S^X5^198911051030

11/5/89の午前10:30より、５時間に渡って、１時間ごとにサービスを実行する。血糖採取など。

1^QAM^X3^^^^^^S~1^QOD^4D^^^^if K+>5.5.

３日間毎朝サービスを実行し、血清カリウムが5.5を越える場合、４日間（つまり最大２回）１日おきにサービスを朝に実行する。

^^^198812120800^^T^^Trough specimen for MIC^C^~^^^^^R

12/12/1988午前8:00きっかりに採血し、ルーチンにしたがい結果を報告する。

5.6 検査結果コメントの扱い

検査結果コメントを必要とする場合、必要とするOBXに続いてNTEでコメントするか、検査項目IDを接尾辞で修飾することによりOBXを追加する方法がある。コメントの性格が明確になる後者の方法を推奨する。以下にその方法について解説する。

OBXに伴う叙述的報告について

放射線科などの部門から送信される読影レポートは通常、多くの副成分から構成される（たとえば胸部Ｘ線レポートは、記述、診断、指導から構成することができる）。心電図などのその他の検査には、そのような類似の成分だけでなく数値検査（左心室拡張期の直径など）も含まれる。外科病理学レポートには、採取部位、概略記述、詳細記述および各検体の仮診断など複数の検体・レポート関連情報を含むことができる。

ＨＬ７は、叙述的報告共通成分に使う検査ＩＤを構築するためのコード接尾辞を定義した（図７．１を参照）。そのような成分に使う検査項目は、適切な接尾辞を検査セットＩＤ（どのようなコーディング方式の場合でも先行ＯＢＲの「ＯＢＲ−４−検査項目ＩＤ」内のＩＤ）に連結することで得られる。たとえば、胸部Ｘ線診断用の検査ＩＤは、胸部Ｘ線検査ＩＤ（ＣＰＴ４の場合、７１０２０）、副成分区切り文字、それに接尾辞“ＩＭＰ”から構成される（つまり７１０２０＆ＩＭＰになる）。

送り手と受け手が合意した場合、結果セグメントの“検査ＩＤ”成分は、先行ＯＢＲの検査ＩＤと同じならば、オプションで省略することができるだろう。この場合、結果セグメントのＯＢＸ−３−検査項目内には＆ＩＭＰ、＆ＲＥＣなどと記述して、アンパサンと接尾辞だけを送信すればよい。完全なコードは、「（オーダー・セグメントに記録された）検査項目＋検査セグメントに記録された識別子」であると仮定されるだろう。

叙述的報告の共通成分に使う検査ＩＤを定義するための接尾辞の解説

Diagnostic impressions 所見(IMP)

接尾辞がIMPの場合結果は診断か所見でありCEデータ型として保管される。僧帽弁脱出症と大動脈弁狭窄症などの複数の別個の診断が報告されている場合、それぞれの診断は個別のOBXセグメントで送るべきである。１個のコード化結果セグメントに複数のコードが含まれているのは、そのようなコードが主要診断の修飾子である場合に限られる。つまり主要診断に関する追加詳細情報を報告するためであり、全く異なる診断を報告するためではない。

所見用コード化データ型が存在するからといって、報告部門でそのような所見をすべて実際にコード化しなければならないということではない。所見は書き取りテキストとして送信できるが、テキストは、ＣＥデータ型の第２成分で送信することにより、コードを区別すべきである、つまり、テキストの前には成分区切り文字を記述すべきである（たとえば＾うっ血性心不全のように）。複数のテキスト所見が報告されている場合、個別のＯＢＸセグメントで報告し、それらのテキスト所見が別個の所見であることを示すべきである。

Recommendations 指導(REC)

接尾辞がＲＥＣの場合、その値はＣＥ結果であり、反復テスト、フォローアップ、あるいは治療に関する読影医師の指導を表わしている。たとえば、疑わしい病変結果がマンモグラフィ上で見られたら、読影医師は、６か月以内にマンモグラフィを再実施するかあるいは直ちに穿刺生検を実施するよう指導することができる。指導手順は、コードとして、および（もしくは）コード化識別子構造のテキスト記述として記録する。複数のフォローアップ検査が推奨されている場合、そのような指導はそれぞれ個別のＲＥＣで送られる。

Confirming procedure 処置確認(CNP)

処置確認ＯＢＸ接尾辞は、ＩＭＰ　ＯＢＸに報告された診断を確定するのに使用される追加検査を識別する。たとえば、電子顕微鏡を使って外科病理学診断を確定する場合、電子顕微鏡「ＯＢＸ−３−検査項目」用識別子は、処置確認を表す接尾辞の付いた検査ＩＤの値フィールドとして保管されるだろう。処置確認は、外科病理学レポートにおいて最も重要である。しかし処置確認は内視鏡検査などのサービスでも使用され、処置確認として生検や培養などを実施したと記録することもできる。

Procedure medication 処置投薬治療(MED)

接尾辞ＭＥＤの付いたＯＢＸ−３−検査項目は、造影剤の投薬、生理反応を引き起こすことを目的とした投薬（ストレス試験などを実施するために）、あるいは事前投薬など、手順の一部として投薬を実施した場合その薬剤に関する情報が含まれていることを示す。患者が複数の投薬を受ける場合、それぞれの薬剤は個別のＯＢＸ投薬セグメントで報告すべきである。伝送システムで投薬にコードを利用できる場合、そのようなコードはＯＢＸ−３−検査項目の第１成分として記録する。薬剤名と（または）投薬量は、ＯＢＸ−５−検査結果値の第２成分に含むことができる。

Anatomic site 解剖部位(ANT)

単一レポートに複数部位についての検査を含むような診断観察がある。たとえば患者が胆嚢手術に伴い虫垂切除術を受けた場合、両検体に対する病理学者の病理診断は通常、１つのレポートの単一検体番号に含まれるだろう。それぞれ個別の部位は、接尾辞ＡＮＴ（ＯＢＸ−３−検査項目）を持つ個別のＯＢＸセグメントとして報告されることになる。

Devices 装置(DEV)

要求があれば、検査の実施に使用した器具あるいは装置を検査の追加“結果”として転送することができる。この場合、ＯＢＸ−３−検査項目の接尾辞はＤＥＶである。たとえば、臨床検査室の自動化装置、放射線科の画像装置とそのモデル番号、病棟の自動血圧測定器など。装置の識別子はいずれコードとして指定されることが予想されるので、コード化された入力値として装置を指定する。とりあえず当初は、装置関連情報のほとんどをＣＥ識別子の第２成分のテキストとして転送すると期待される。

Gross or general description 概略記述もしくは一般記述(GDT)

一般記述を表す接尾辞により、診断検査の記述成分が識別される。解剖病理学の場合には、一般記述は検体についての概略記述に適用される。記述が複数のパラグラフから成る場合、受信コンピューター側でパラグラフをパラグラフとして表示できるようにするため、パラグラフは反復区切り文字により分離すべきである。レポートが簡潔に表現できる通常検査やＥＫＧ検査などの場合は、診断セグメントですべての情報を表現し尽くしていれば、レポート用記述セグメントを含むる必要はないだろう。

Secondary or microscopic description ２次的記述もしくは詳細記述(MDT)

ほとんどの検査では２次的記述は必要ないだろう。しかし、外科病理学の場合には、詳細記述はレポートの独立箇所として存在する。それは顕微鏡を通して見られるような顕微鏡組織検査について記述する。詳細記述は、ＯＢＸ−３−検査項目の接尾辞にＭＤＴを指定したセグメントで送られるだろう。

Technician comment 医療技術者コメント(TCM)

医療技術者がコメントを記述するのに使用するフリーテキストであり、ＯＢＸ−３−検査識別子の接尾辞がＴＣＭである結果セグメントに保管される。このコメントの内容は通常、処置を実施する際の技術情報である。

Addendum note 追加情報メモ(ADT)

オリジナルの叙述の後に追加情報として加えられ、レポートの個別のラベル付きセクションとして送られる情報を報告するのに使用する。

Diagnosis (problem) onset date-time 診断（プロブレム）開始日時(ITM)

プロブレムが存在するとはじめて認識された日時を記録するのに使用。

Diagnosis (problem) resolution date-time 診断（プロブレム）終了日時(RTM)

プロブレムが治療されたか軽減した日時を記録するのに使用。

Comparison study 比較検査(CMS)

診断レポートの読み手が現在の検査結果を以前の検査結果と比較する場合、この接尾辞により、比較検査の性質を個別の結果として報告することができる（つまり検査ＩＤの接尾辞がＣＭＳであるセグメントを持つＯＢＸセグメント）。他の任意の比較値が転送さていれば、他の比較ＯＢＸセグメント内の検査ＩＤによりテストが識別されるので、通常これは必要とされない。

Comparison date-time 比較日時(CMT)

診断処置の読み手が以前の検査結果と現在の検査結果を比較する場合、この接尾辞により、以前の検査の日時を個別の結果として現行レポートで報告することができる。

Comparison results 比較結果(CMR)

診断処置の読み手が、現在の結果を同じ患者に関する以前の結果と比較する場合、この接尾辞により、以前の結果（診断）を個別の結果として現行レポートで報告することができる。

Comparison change 比較変化(CMC)

診断部門が現在の検査と以前の検査の比較を報告する場合、この接尾辞を使って変化の程度を個別の結果としてレポートに報告する。（たとえば、大幅に悪化、悪化、最小限悪化しないこと、変化なし、少し回復、回復、非常に回復、正常に回復）現行の書き取りレポートでは、比較に関する情報は通常、検査記述に含まれる。上に列記した比較接尾辞の規定は、この情報を個別の成分として送信しなければならないという意味ではない。単に比較変数を使用できるという意味である。システム側で個別のレポート成分としてこの情報を転送したい場合、これらの接尾辞により所望の比較を選択することができる。

Predicted 推定(PRD)

多くの肺活量測定の場合がそうであるように、検査に推定値がある場合、この接尾辞により推測と実測定が区別される。最大肺活量を表すＡＳ４コードは９４０１０．１である。推定される最大肺活量は９４０１０．１＆ＰＲＤになるだろう。

Percent of predicted 推定率(PPR)

これは（実測）／（推測）により計算される観察である。最大肺活量の場合、推定率は９４０１０．１＆ＰＰＲとなるだろう。

After drug observed 投薬後検査(AFD)

投薬の前後に検査を実施する場合がある。これは特に肺活量測定で生じる。投薬前検査は基本ＩＤにより識別される。投薬後測定は接尾辞「ＡＦＤ」により識別される。最大肺活量に基本コード「ＡＳ４」を使用して、投薬後結果は９４０１０．１＆ＡＦＤとして特定されるだろう。

Predicted value after drug 投薬後推測値(ADP)

投薬後推測値は、接尾辞「ＡＤＰ」により識別される。上記のパターン例に従い、９４０１０．１＆ＡＤＰとなるだろう。

Percent predicted after drug 投薬後推測率(APP)

投薬後の推測率は、基本単位コードへ接尾辞「ＡＰＰ」を適用することで識別される――　最大肺活量にＡＳ４コードを使用して９４０１０．１＆ＡＰＰとなる。

6. 関連セグメント詳細

6.1 MSH - message header segmentメッセージ・ヘッダ・セグメント

MSHセグメントは、メッセージの構文の目的、発信源、宛先、特性を定義する。

Figure 2-8. MSH attributes

Optionality

R - required

O - optional

C - conditional on the trigger event or on some other field(s)

X - not used with this trigger event

B - left in for backward compatibility with previous versions of HL7

Repetition

N - no repetition

Y - the field may repeat an indefinite or site determined number of times

(integer)- the field may repeat up to the number of times specified in the integer

MSH field definitions　MSHフィールド定義

MSH-1 Field separator フィールド区切文字 (ST) 00001

定義：　セグメントIDと最初の実フィールド（MSH-2-コード化文字）間のセパレーター。そのようなセパレータとしての他に、残りのメッセージでセパレータとして使う文字を定義する。推薦値は | である。

MSH-2 Encoding characters コード化文字 (ST) 00002

定義：　次の順番で並べられた５文字、つまり、成分セパレータ、反復セパレータ、エスケープ文字、副成分セパレータ、PN反復副成分セパレータ。推薦値は ^~\&= である。メッセージ区切文字を参照。

MSH-3 Sending application 送信アプリケーション (HD) 00003

定義：　ネットワークにより送信アプリケーションが結ばれている場合他のアプリケーションと区別するため用いる。

MSH-4 Sending facility 送信施設 (HD) 00004

定義：　送信システムで同じアプリケーションが複数発生する場合の一つのアドレスを示す。送信側の施設コードや略称などをセットする。

MSH-5 Receiving application 受信アプリケーション (HD) 00005

定義：　ネットワークにより受信アプリケーションが結ばれている場合他のアプリケーションと区別するため用いる。

MSH-6 Receiving facility 受信施設 (HD) 00006

定義：　異なる組織で稼働している複数の同一アプリケーションから、受信アプリケーションを特定する。受信側の施設コードや略称などをセットする。

MSH-7 Date/time of message メッセージ日時 (TS) 00007

定義：　送信システムがメッセージを作成した日時。時間帯を指定した場合、それはメッセージ全体でデフォルトの時間帯として使われる。

MSH-8 Security セキュリティ (ST) 00008

定義：　いくつかのHL7アプリケーションでは、このフィールドは安全性を実装するのに使われる。その使用法はまだ規定されていない。

MSH-9 Message type メッセージ型 (CM) 00009

Components: <message type (ID)> ^ <trigger event (ID)>

定義：　第１成分は、テーブル0076 - メッセージ型にリストされているメッセージ型である。第２成分は、テーブル0003 - イベント型コードにリストされているトリガー・イベント・コードである。受信システムはこのフィールドを使い、認識すべきデータ・セグメントを知り、また、これを転送するアプリケーションを知る。

MSH-10 Message control ID メッセージ制御ID (ST) 00010

定義：　メッセージを一意に識別する番号または他の識別子。

MSH-11 Processing ID 処理ID (PT) 00011

Components: <processing ID (ID)> ^<processing mode (ID)>

定義：　メッセージを処理するかどうか決めるのに使用する。

MSH-12 Version ID バージョンID (ID) 00012

定義：　受信システムは、バージョンＩＤを認識しメッセージが確実に解釈されるようにする。省略されている場合 2.3とみなす。

MSH-13 Sequence number シーケンス番号 (NM) 00013

定義：　このフィールドの値がnullでなければ、シーケンス番号プロトコルが使われていることを意味する。この数値フィールドは、以降のシーケンスごとに１づつインクリメントされる。

MSH-14 Continuation pointer 継続ポインタ (ST) 00014

定義：　アプリケーションに特有の方法で継続を定義するのに使用する。

MSH-15 Accept acknowledgment type 受諾肯定応答型 (ID) 00015

定義：　このメッセージに応答して受諾肯定応答を返すことが要求される条件を定義する。拡張肯定応答モードで要求される。

MSH-16 Application acknowledgment type アプリケーション肯定応答型 (ID) 00016

定義：　このメッセージに応答してアプリケーション肯定応答を返すことが要求される条件を定義する。拡張肯定応答モードで要求される。以下のテーブルには、MSH-15-受諾肯定応答型とMSH-16-アプリケーション肯定応答型で可能な値が含まれる：

MSH-17 Country code 国コード (ID) 00017

定義：　メッセージの発信国を定義する。主に通貨単位などのデフォルト要素を指定するのに使用される。ISO 3166は、使用可能な国コードのリストを提供する。

MSH-18 Character set 文字セット (ID) 00692

定義：　メッセージ全体に使用する文字セットをコードで定義する。有効な文字セットを表２１１にしめす。

異なる文字セットの反復はデータタイプPNとXPNのみに適用される。本フィールドの指定がないもしくは反復の第一成分がNullの場合はsingle-byte character set (ASCII (ISO IR-6))が適用される。本フィールドが出現し第一成分が特定される場合この文字セットがメッセージのデフォルト文字セットとなる。これはシングルバイト文字セットでなければならない。 (例えば ISO-IR 6, ISO-IR 13, ISO-IR 14, ISO-IR 100, etc.)　第二第三成分は代替文字セットが使用できダブルバイト文字セットも含まれる。 (例えば JIS X 0208)　デフォルト文字セットは常にシングルバイト文字セットであり、ISO-IR 6 (ISO 646) or ISO-IR 14 (JIS X 0201-1976)の G0 域である。
半角カタカナは全てのフィールドで使用しないようにすること。

MSH-19 Principal language of message 主要言語 (CE) 00693

定義：　メッセージの主要言語を定義する。コードはISO 639を使用。

6.2 NTE - notes and comments segment　注釈コメントセグメント

注釈とコメントを送るためのメッセージに共通のフォーマットである。Figure 2-22. NTE attributes

NTE field definitions　ＮＴＥフィールド定義

NTE-1 Set ID - NTE セットＩＤ-NTE (SI) 00096

定義: ひとつのメッセージ中に複数のＮＴＥセグメントが含まれる場合に使用される。番号付けについては、アプリケーション・メッセージの定義に記述されなければならない。

NTE-2 Source of comment コメント・ソース (ID) 00097

定義: コメントの発生源を明示する。これは導入の際にサイトで拡張される可能性がある。

NTE-3 Comment コメント (FT) 00098

定義: 先行するセグメントに従属するコメント。

PID - patient identification segment　患者識別セグメント

ＰＩＤセグメントは、患者識別情報を通信する主要な手段としてすべてのアプリケーションによって使用される。このセグメントは患者を永久に識別する情報と調査情報を含むが、この大部分はそれほど頻繁に変化しない。Figure 3-2. PID attributes　ＰＩＤ属性

PID field definitions　ＰＩＤフィールド定義

PID-1 Set ID - patient ID セットＩＤ−患者ＩＤ (SI) 00104

定義：セグメントの反復が許されるメッセージについては、反復を識別するためにセットＩＤフィールドが使用される。例えば、交換及び照会のトランザクションは、セットＩＤ値１、２、３、などの多数のＰＩＤセグメントを持つことができる。

PID-2 Patient ID (external ID) 患者ＩＤ（外部ＩＤ） (CK) 00105

定義：患者がオフィスなどの外部の別の施設からきていればその施設のIDなどをここに表現する。これは多数の異種の会社や施設が共有することができるIDとなる。

PID-3 Patient ID (internal ID 患者ＩＤ（内部ＩＤ） (CX) 00106

定義：患者を一意的に識別するため施設によって使用されるＩＤ（たとえば患者IDやカルテ番号、請求書番号など）

PID-4 Alternate patient ID - PID 代替患者ＩＤ (ST) 00107

定義：第３のIDが患者を識別するために必要とされるかもしれない。例えば訪問番号、訪問期日あるいは社会保障番号を含んでいる。患者IDとカルテ番号を併用するようなばあい従となるIDはこのフィールドを使用する。

PID-5 Patient name 患者氏名 (XPN) 00108

成分：〈姓〉＾〈ギブンネーム〉＾〈ミドルネーム〉＾〈補助記号（たとえばＪＲあるいはIII）〉＾〈接頭辞（たとえばＤＲ）〉＾〈学位（たとえばＭＤ）〉

定義：患者氏名をMSH-18文字セットで指定した文字コードで使用する。例えばMSH-18に ~JIS X 0208をセットした場合、PID-5はYamada^Tarou=山田^太郎=ヤマダ^タロウとなる。
半角カタカナは全てのフィールドで使用しないようにすること。

PID-6 Mother's maiden name 母親の旧姓 (XPN) 00109

定義：母親の旧姓、同じラストネームを持つ患者を明確に識別するために使用する。

PID-7 Date/Time of birth 生年月日 (TS) 年齢 00110

定義：患者の生年月日、新生児などは誕生時刻まで記述。
生年月日に続けて年齢nnnUを記載することもできる、また年齢単位として　Y年、L月、W週、D日を使用、省略時は年令とする(YYYYLLDDHHMMSS^nnnU)。例えば 19900301^7 1990年3月1日生7才、^10 10才、^5D 5日齢など、和暦は不可。

PID-8 Sex 性別 (IS) 00111

定義：患者の性別、表0001を推奨する。 User-defined Table 0001 - Sex

Value	Description
F	Female女性
M	Male男性
O	Otherその他
U	Unknown未知

PID-9 Patient alias 患者の別名 (XPN) 00112

PID-10 Race 人種 (IS) 00113

定義：患者の同意を得て使用することができる。

PID-11 Patient address 患者住所 (XAD) 00114

定義：患者の現住所。

PID-12 County code 郡コード (IS) 00115

定義：患者の郡コード。

PID-13 Phone number - home 電話番号−自宅 (XTN) 00116

PID-14 Phone number - business 電話番号−勤務先 (XTN) 00117

PID-15 Primary language 言語−患者 (CE) 00118

定義：患者の主要な言語。

PID-16 Marital status 婚姻状況 (IS) 00119 User-defined Table 0002 - Marital status婚姻状況

PID-17 Religion 宗教 (IS) 00120

PID-18 Patient account number 患者会計番号 (CX) 00121

定義：料金、支払いなどがすべて記録される勘定によって割り当てられる数字。患者の会計を識別するために使用される。

PID-19 SSN number - patient ＳＳＮ番号−患者 (ST) 00122

定義：患者の社会保障番号。

PID-20 Driver's license number - patient 患者の運転免許証番号 (CM) 00123

成分：〈免許証番号〉＾〈発行の州、地方、国〉。

定義：患者の運転免許証番号。いくつかのサイトは、患者を識別する一意的な番号としてこれを使用してもよい。第２の成分のデフォルトは患者が登録されている州である。

PID-21 Mother's identifier 母親の識別子 (CX) 00124

定義：例えば新生児用にリンク・フィールドとして使用される。典型的に、患者ＩＤあるいは会計番号が使用されるかもしれない。

PID-22 Ethnic group 人種のグループ (IS) 00125

定義：患者の民族的起源を定義する。

PID-23 Birth place 誕生場所 (ST) 00126

定義：患者の誕生の場所を示す。

PID-24 Multiple birth indicator多胎児誕生標識 (ID) 00127

定義：患者が多胎児の一人であったかどうか示す。Ｙ／Ｎインジケータを使用。

PID-25 Birth order 誕生順序 (NM) 00128

定義：患者が多胎児の一人であった場合、誕生順序を示す値。

PID-26 Citizenship 市民権 (IS) 00129

定義：患者の市民権の国を示す。提案値として、ユーザ定義テーブル0171−国コード又はISO3166を参照すること。

PID-27 Veterans military status 退役軍人の状況 (CE) 00130

PID-28 Nationality 国籍 (CE) 00739

定義：患者の属する国籍や国グループを示す。市民権と違い複数指定可。

PID-29 Patient death date and time 患者死亡日時 (TS) 00740

定義：患者死亡日時、臨床研究や管理用。

PID-30 Patient death indicator 患者死亡識別 (ID) 00741

定義：患者が死亡したか否かY/Nで表現。

6.4 PV1 - patient visit segment　来院セグメント

ＰＶ１セグメントは、来院に関する情報を通信するために登録／ＡＤＴアプリケーションによって使用される。このセグメントは複数の来院統計記録を同じ患者の会計に送るため、又は単一の来院記録を複数の会計に送るために、使用することができる。個々のサイトは必ずこのセグメントを使用しなければならない。

Figure 3-3. PV1 attributes

PV1 field definitions　ＰＶ１フィールド定義

PV1-1 Set ID - patient visit セットＩＤ−来院 (SI) 00131

定義：トランザクションを一意的に識別する番号。

PV1-2 Patient class 患者クラス (IS) 00132

定義：サイトにおいて患者を分類するためにシステムで使われる共通のフィールド。入院、外来などの区別を表現する。

User-defined Table 0004 - Patient class

Value	Description
E	Emergency 救急
I	Inpatient 入院患者
O	Outpatient 外来患者
P	Preadmit 予備入院
R	Recurring Patient 再来院患者
B	Obstetrics 産科

PV1-3 Assigned patient location 患者所在場所 (PL) 00133

定義：病院、診療科、病棟、病室、ベッド等を表現する。新規の場所は最初に割当てた場所、あるいは患者の移動先の場所である。トランザクションの取消しや、退院の場合、現在の部屋番号をこのフィールド表現する。
必要に応じ病院コード、診療科、病棟、病室、ベットなどをセットする。

PV1-4 Admission type 入院タイプ (IS) 00134

定義：患者が入院していたか入院予定の状況を示す。

User-defined Table 0007 - Admission type

Value	Description
A	Accident　事故
E	Emergency　救急
L	Labor and Delivery　陣痛および出産
R	Routine　通常

PV1-5 Pre-admit number 仮入院番号 (CX) 00135

定義：患者の仮入院番号を一意的に識別する。システムでは、仮入院番号を請求番号として患者が入院した後も使用し続けることもできる。

PV1-6 Prior patient location 患者の以前の所在 (PL) 00136

定義：新患であればここはNULLである。患者が転院されていれば、それは以前の患者所在を含んでいる。

PV1-7 Attending doctor 主治医 (XCN) 00137

定義：主治医の情報で、複数の名前やIDを持つ場合もある。

PV1-8 Referring doctor 紹介医師 (XCN) 00138

定義：紹介医師の情報で、複数の名前やIDを持つ場合もある。

PV1-9 Consulting doctor コンサルティング医師 (XCN) 00139

定義：コンサルティング医師の情報。

PV1-10 Hospital service 病院サービス (IS) 00140

定義：患者が受ける処置又は手術のタイプ。トリガーイベントA01,A02,A14,A15に関して要求されるフィールド。

PV1-11 Temporary location 一時的な所在 (PL) 00141

定義：割り当てられた所在以外の所在であって、一時的に必要なもの（たとえばＯＲ）。.

PV1-12 Pre-admit test indicator 仮入院検査標識 (IS) 00142

定義：患者は入院するために仮入院検査を受けねばならないことを示す。

PV1-13 Re-admission indicator 再入院標識 (IS) 00143

定義：患者が施設および環境に再入院することを示す。再入院はR、そうでなければNullである。再発患者の来院も示すことができる。

PV1-14 Admit source 入院元 (IS) 00144

定義：患者がどこに入院していたかを示す。

PV1-15 Ambulatory status 外来の状況 (IS) 00145

定義：提案値としてユーザ定義テーブル0009-外来状況を参照すること。

User-defined Table 0009 - Ambulatory status

Value	Description
A0	No functional limitations 機能制限なし
A1	Ambulates with assistive device 補助機器を使用して来院
A2	Wheelchair/stretcher bound 車椅子／担架を使用して来院
A3	Comatose; non-responsive 意識不明；反応なし
A4	Disoriented 方向感覚なし
A5	Vision impaired 視力障害あり
A6	Hearing impaired 聴力障害あり
A7	Speech impaired 言語障害あり
A8	Non-English speaking 英語以外を話す
A9	Functional level unknown 機能のレベル未知
B1	Oxygen Therapy 酸素治療
B2	Special equipment (tubes, IVs, catheters) 特別の装置（チューブ、ＩＶ、カテーテル）
B3	Amputee 手足の切断手術を受けた人
B4	Mastectomy 乳房切除術
B5	Paraplegic 対麻痺
B6	Pregnant 妊婦

PV1-16 VIP indicator ＶＩＰ標識 (IS) 00146

定義：ＶＩＰのタイプを識別するユーザ定義コード。

PV1-17 Admitting doctor 入院時医師 (XCN) 00147

定義：入院時の医師の情報、複数の名前やIDのこともある。

PV1-18 Patient type 患者タイプ (IS) 00148

定義：患者のタイプを示すサイト特定の値。

PV1-19 Visit number 来院回数 (CK) 00149

定義：患者の各来院に割り当てられた一意的な数。

PV1-20 Financial class 財務クラス (CM) 00150

定義：診療報酬の源を識別する目的で患者に割り当てられた、主要な財務のクラス。

PV1-21 Charge price indicator 有償価格標識 (IS) 00151

定義：部屋およびベッドの料金にどの価格表を使用するか決めるために使用されるコード。

PV1-22 Courtesy code 優待コード (IS) 00152

定義：患者が特定の優待を受けるかどうか示すコード。

PV1-23 Credit rating 信用格付け (IS) 00153

定義：過去の信用経験を決定するユーザ定義コード。

PV1-24 Contract code 契約コード (IS) 00154

定義：会計残高を決済するための施設および保証人による契約のタイプを識別する。

PV1-25 Contract effective date 契約有効日付 (DT) 00155

定義：契約が始まる日付。

PV1-26 Contract amount 契約金額 (NM) 00156

定義：保証人によって各期に契約ごとに支払われる金額。

PV1-27 Contract period 契約期間 (NM) 00157

定義：ユーザが定義する期間で、契約の持続期間を指定する。

PV1-28 Interest code 利息コード (IS) 00158

定義：任意の未決済の金額に対し保証人に請求される利息額を示す。

PV1-29 Transfer to bad debt code 不良負債変換コード (IS) 00159

定義：会計が不良負債に転換されたこと及び理由を示す。

PV1-30 Transfer to bad debt date 不良負債変換日付 (DT) 00160

定義：会計が不良負債状況に転換された日付。

PV1-31 Bad debt agency code 不良負債代理コード (IS) 00161

定義：会計が転換された先の不良負債代理を一意的に識別する。

PV1-32 Bad debt transfer amount 不良負債転換額 (NM) 00162

定義：不良負債に転換された金額。

PV1-33 Bad debt recovery amount 不良負債回収額 (NM) 00163

定義：会計上の保証人から回収された金額。

PV1-34 Delete account indicator 会計削除標識 (IS) 00164

定義：会計がファイルから削除されたこと及びその理由を示す。

PV1-35 Delete account date 会計削除日付 (DT) 00165

定義：会計がファイルから削除された日付。

PV1-36 Discharge disposition 退院処置 (IS) 00166

定義：退院（つまり、帰宅；期限満了；など）の時の患者の処置。

PV1-37 Discharged to location 退院先 (IS) 00167

定義：患者の退院先の施設を示す。

PV1-38 Diet type 給食タイプ (IS) 00168

定義：患者用の特別の給食タイプを示す。

PV1-39 Servicing facility サービス施設 (IS) 00169

定義：複数の施設環境の中でこの来院が関係している施設を示す。

PV1-40 Bed status ベッド状況 (IS) 00170

定義：下位互換のためののみ使用。ＰＬデータタイプの第５成分状況を使用すること。

PV1-41 Account status 会計状況 (IS) 00171

定義：会計状況

PV1-42 Pending location 保留所在 (PL) 00172

定義：患者が移動する先の看護ステーション、部屋、ベッド、施設ＩＤおよびベッド状況を示す。第５の成分（ベッド状況）中に値がある場合、それは、PV1-40の値に取って代わる。

PV1-43 Prior temporary location 以前の一時的な所在 (PL) 00173

定義：患者が到着しているか出発している場合、又は一般更新イベントのために使用される。

PV1-44 Admit date/time 入院日時 (TS) 00174

定義：入院の日付／時刻。

PV1-45 Discharge date/time 退院日時 (TS) 00175

定義：退院の日付／時刻。

PV1-46 Current patient balance 患者の差引不足額 (NM) 00176

定義：来院患者の現在の差引不足額。

PV1-47 Total charges 合計有償金額 (NM) 00177

定義：来院有償金額の合計

PV1-48 Total adjustments 合計調整金額 (NM) 00178

定義：来院調整金額の合計

PV1-49 Total payments 合計支払金額 (NM) 00179

定義：来院の支払い金額の合計

PV1-50 Alternate visit ID 代替来院ＩＤ (CX) 00180

定義：来院ＩＤ番号。このＩＤは入院時に患者を一意的に識別するために使用される。

PV1-51 Visit indicator 来院標識 (IS) 01226

定義：データ送信が患者の来院によるのか会計によるのかの識別に使用。

User-defined Table 0326 - Visit Indicator

Value	Description
A	Account Level　会計
no value	Visit Level　来院

PV1-52 Other healthcare provider 他のヘルスケア供給者 (XCN) 01224

定義：他のヘルスケア供給者を示す。（例えば看護婦，付き添い，補助医師）複数の関係者に送ることができる。

注：ＰＬデータタイプのフィールドは値の第５の成分（ベッド状況）が存在する場合、それは、PV1-40の値に取って代わる。 User-defined Table 0116 - Bed status

Value	Description
C	Closed 閉鎖
H	Housekeeping 清掃
O	Occupied 使用
U	Unoccupied 空き
K	Contaminated 汚染
I	Isolated 隔離

6.5 AL1 - patient allergy information segment　患者アレルギー情報

ＡＬ１セグメントは、多様なタイプの患者アレルギー情報を含んでいる。ほとんどのこの情報はユーザ定義テーブルによるだろう。各ＡＬ１セグメントは単一の患者アレルギーについて記述する。Figure 3-6. AL1 attributes

AL1 field definitions　ＡＬ１フィールド定義

AL1-1 Set ID - allergy セットＩＤ−アレルギー (SI) 00203

定義：患者の記録中のアレルギー記述の追加・変更・削除のために個々のトランザクションを一意的に識別する数字である。セグメントの反復が許されるメッセージについては、反復を識別するためにセットＩＤフィールドが使用される。

AL1-2 Allergy type アレルギータイプ (IS) 00204

定義：一般的なアレルギーカテゴリー（薬、食物、花粉など）を示す。表127参照

User-defined Table 0127 - Allergy type

Value	Description
DA	Drug Allergy　薬剤アレルギー
FA	Food Allergy　食事アレルギー
MA	Miscellaneous Allergy　様々なアレルギー
MC	Miscellaneous Contraindication　様々な禁忌

AL1-3 Allergy code/mnemonic/description アレルギーコード／記憶法／記述 (CE) 00205

定義：一意的に、特別のアレルギーを識別する。この要素は、ある外部かつ標準のコード化するシステム（それは識別されねばならない）に一致させたり、あるいは、局所的な記述、主に文章の記述あるいは記憶法の記述によっても良い。

AL1-4 Allergy severity アレルギー重症度 (IS) 00206

定義：アレルギー（重度、中程度、軽度など）の一般的な重症度を示す。表128参照。

User-defined Table 0128 - Allergy severity　アレルギー重症度

Value	Description
SV	Severe　　重度
MO	Moderate　中程度
MI	Mild　　　軽度

AL1-5 Allergy reaction アレルギー反応 (ST) 00207

定義：特定のアレルギー反応（震え、くしゃみ、発疹など）を短く文章で記述したもの。

AL1-6 Identification date (DT) 00208

定義：アレルギーが認められた日付

6.6 ORC - common order segment　共通オーダーセグメント

共通オーダーセグメント（ORC）は、すべてのオーダーに共通なデータ要素を伝達するために使用される（要求されるすべてのタイプのサービス）。場合によっては、ORCは文字列ORC|OK|＜依頼者オーダー番号＞|＜実施者オーダー番号＞|＜CR＞のように単純になる。

詳細内容がオーダーのために必要ないならば、オーダー詳細セグメントは省略してよい。たとえば、オーダーを保留するためには、ORCで次のフィールドを付けて伝達する（HDの値付きのORC-1−オーダー制御、ORC-2−依頼者オーダー番号、およびORC-3実施者オーダー番号）。

ORCのフィールドとオーダー詳細セグメントの中のフィールドとの間にいくつかの重複がある。これらは以下の節に述べる。

ORC使用注記

ａ）依頼者オーダーグループ

本規格では、複数のオーダーを１つのグループに集めるメカニズムをサポートする。大抵の場合、これは１人の患者に対して「依頼セッション」を表すために使用される。

オーダーグループは、ORC-４-依頼者グループ番号に関連するオーダー（ORCs）のリストである。グループは、依頼者が最初のオーダーに依頼者グループ番号を付けた時に確立する。オーダーグループは、同じ依頼者グループ番号を有するすべてのORCsおよびすべての詳細セグメントから成る。オーダーは、グループからキャンセルを使用して除去したり、取換えや親子メカニズムを使用して追加したりできる。新規オーダーは、その他の方法でのグループへの追加はできない。

ｂ）重複フィールド

ORCは、すべてのオーダー（すなわち要求されたサービス）に共通なフィールドを一様に定義するよう意図されている。ただし、一部のORCフィールドは、一部のオーダー詳細セグメント（たとえばOBR、RXO）では重複する。たとえば、ORC-2依頼者オーダー番号は、OBR-2依頼者オーダー番号フィールドど同じ意味および目的を持つ。これによって過去のバージョンおよびASTMとの上位互換性が保たれる。

これらのフィールドを使用する規則では、ORCに現れない値はオーダー詳細セグメントに現れねばならない。しかし、両方の箇所に値を入れて混乱を避けることが望ましい。

ｃ）親／子　−　キャンセル、保留、中断

親オーダーのキャンセル、保留または中断の要求の伝達は、その要求は親オーダーおよびすべての関連の子オーダーに対して再帰的に適用されるよう意図されている。

たとえば

１）EKGアプリケーションが３回のEKGに対するオーダーを受け、これが３日連続で毎朝行われるとする。

２）EKGアプリケーションは３つの子オーダーを、各々の要求されたEKGに対して１つづつ作成する。

３）元の親オーダーを取り消す要求が受け取られた時に１日目のEKGが実施されていた。（親は取り消せなかった）

４）残りの、未実施の子は要求の結果として取り消される。
Figure 4-1. ORC attributes 　ORCの属性