診断のための検査、治療、手術などのサービスリクエストの記録

リクエストの発注者、受注者、サービスの実施者によるインスタンスに割り当てられた識別子。

この要素は、発注者（HL7 v2 では 'Placer' ）とリクエストに応じて観察、行為等を実施した者（HL7 v2 では 'Filler' ）を区別するために用いられる。

このサービスリクエストに部分的、または完全に関わる、FHIRで定義されたプロトコル、ガイドライン、オーダセットまたは他の定義を指しているURL

PlanDefinitionリソースは、実行されるアクションのシリーズ、シーケンス、またはグループを記述するために使用され、ActivityDefinitionリソースは、特定の各ステップまたはアクティビティを定義するために使用される。詳細は、PlanDefinition のBoundaries and Relationshipsセクションを参照してください。（訳注:R4とR4Bの本文に誤りあり、修正されたR5を翻訳）

このサービスリクエストに部分的、または完全に関わる、外部の管理されたプロトコール、ガイドライン、オーダセットや他の定義へのURL参照

HTMLページ、PDFなど、名前で解決できないURI識別子

このリクエストによって実施すべき計画、提案、オーダの詳細（への参照）

一人の発注者によっておおよそ同時に署名されたサービスリクエストの全てに共通する識別子で、複合、またはグループIDを表現する。

サービスリクエストは、basedOn要素、このrequisition要素によって関係付けられる。同じrequisition要素の一部であるサービスリクエストは、初めに作成された後にその状態と管理が変化する視点から、一般的に独立して扱われる。

オーダの状態

status要素は、一般的に発注者の完全な制御下にあり、オーダが起案か有効かを決定し、有効化された後は、競合、停止、または中断される。受注者の活動に関連する状態は、対応するイベント（一般的な議論についてはEventパターンを参照）またはTaskリソースを使用して反映される。

この要求が、提案、経過、オリジナル、繰り返しかどうかを示す。

この要素は、リソースが実際に適用されるタイミングや方法を意図的に変更するため、修飾子と表現される。

検索、分類、表示の目的でサービスを分類するコード（例 「外科的手技」）

リソースを検索または表示するためのコンテキストまたはユースケースに応じて、複数の分類軸が存在する場合がある。粒度のレベルは、Value Setのカテゴリー概念によって定義される。

このサービスリクエストはどの程度早く対処されるべきかを示す。

要求された特定のサービス（例、手技、診断のための検査、また検査パネル）の識別子

一般的には、コードと時間枠のみであるが、時には体の部位や実施者などの修飾語を追加して、禁止範囲を狭められる。code要素とdoNotPerform要素がともに否定を含む場合、禁止を強化することになり、二重否定解釈をしてはならない。

要求された特定のサービス（例、行為、診断のための検査、また検査パネル）の識別子

多くの検査・放射線処置コードは、血清または血漿グルコース、胸部 X 線など、検体・器官系が検査オーダー名に埋め込まれている。検体は、検査コードとは別に記録されないかもしれない。

リクエストの提供方法に関する追加の詳細および指示。例えば、尿道カテーテルのサービスリクエストには、外部または留置カテーテルのリクエストの詳細があり、包帯のサービスリクエストには、包帯の適用方法を指定する追加の指示が必要な場合もある。

リクエストされたサービス提供の指示についての医療記録からの情報については、supportingInformation要素を使用。

リクエストされるサービスの量。数量（例:1500ドルの住宅改造）、比率（例:1ヶ月に20回の半日訪問）、または範囲（例:1分間に2.0～1.8Gy）。

サービスリクエスト時に、項目とは別に数を指定する必要がある。

サービスが実行される対象（人または物）。多くは患者だが、動物、集団（人または動物）、透析器のような装置、また場所（点家的には環境調査）も対象となる。

サービスがリクエストされる医療背景についての追加情報を提供する診療時の場面

リクエストされたサービスを実施すべき日時

CodeableConceptが存在する場合、そのサービスを行うための前提条件を示す。例えば、「痛み」、「再発時」など。

リクエストが有効化された日時

リクエストを開始し、その有効化に責任を持つ個人

伝言をする者ではなく、署名者。この要素は、Provenanceリソースを通じて管理される委任を扱うことを意図していない。

リクエストされたサービスの実施者の役割

参加者の資格ではなく役割。タスクではなく、能力を記述。例えば、「調剤薬局」、「精神科医」、「院内紹介」など。

リクエストされたサービスを行うために望ましい実施者。例えば、外科医、皮膚病理医、内視鏡医など。

実施者が複数の場合、順番に関係なく、優先順位のない実施者のリストとして解釈される。優先順位が必要な場合は、request.performerOrder 拡張を使用する。実施者のグループ（例えば、医師Aと医師B）を表すには、CareTeamを使用する。

実際に行為が行われるべき好ましい場所を、コード化またはフリーテキスト形式で記述。例：自宅や介護施設など。

実際に行為が行われるべき好ましい場所（複数可）への参照。例：自宅や介護施設など。

このサービスがリクエストされる理由についての説明または根拠をコード化またはテキスト化したもの。しばしば（保険）請求を目的とされる。supportingInfoで参照されるリソースに関連する場合がある。

この要素は照会理由を表し、サービスがどのように実行されるか、あるいは全く実行されないかどうかを決定するために使用される。CTスキャンの例で示したように、データが自由記述の場合は、CodeableConcept.text要素を使用する。

このサービスが要求される理由の正当性を提供する他のリソースを示す。supportingInfoで参照されるリソースに関連する場合がある。

この要素は照会理由を表し、サービスがどのように実行されるか、あるいは全く実行されないかどうかを決定するために使用される。可能な限り具体的にするために、ObservationやConditionリソースへの参照が可能であれば使用されるべきである。また、DiagnosticReport を参照する場合は、DiagnosticReport.conclusion および/または DiagnosticReport.conclusionCode を参照する必要がある。DocumentReference への参照を使用する場合、ターゲット文書は、このサービス要求の関連理由を提供する明確な所見言語を含んでいなければならない。CTスキャンの例に示すように、データが自由記述（符号化されていない）の場合、 ServiceRequest.reasonCodeにCodeableConcept.text要素を使用する。

リクエストされたサービスを提供するために必要な保険プラン、適用範囲拡大、事前承認、および/または事前決定がある。

サービスやその解釈に影響を与える可能性のある、患者や検体に関する追加の臨床情報。この情報には、診断、臨床所見、その他の観察が含まれる。検査のオーダでは、一般的に「オーダエントリー時の質問（AOEs）」と呼ばれ ている。これには、オーダを完了するために必要な文脈や裏付けとなる情報を提供するために、実施者が明示的に要求した観察が含まれる。例えば、血液ガス測定のための吸入酸素量の報告などである。

サービスの提供方法に関する情報を表すには、instructions 要素を使用する。

検査で使用する１つ以上の検体

多くの診断的行為は検体を必要とするが、リクエスト自体は実際には検体に関するものではない。この要素は、診断検査が既に存在する検体に対してリクエストされ、適用される検体を参照するためのものである。逆に、検体が未知の時に最初にリクエストが入力された場合、SpecimenリソースがServiceRequestリソースを参照する。

行為を実施すべき解剖学的部位。目標とする場所。

ServiceRequest.codeにあるコードに暗黙の了解がない場合にのみ使用する。使用例として、BodySiteをインラインコード化された要素ではなく、別のリソースとして扱う必要がある場合（例えば、別々に識別し追跡するため）、procedure.targetBodyStructureの拡張を使用してください。

サービス要求について作成された、その他のメモやコメント。例えば、内部請求のメモなど。

患者または消費者が理解できる言葉で指示。

このリクエストの履歴で重要なもの

この要素はには、ServiceRequestのProvenanceの全てのバージョンではなく、重要と思われたものだけ含められる。現在のバージョンのリソースに関連したProvenanceリソースを含めてはならない（SHALL NOT）。（もし、Provenanceとして重要な変化と思われれば、以降の更新の一部として追加すべきである。それまでは、'_revinclude'を使って指定されたProvenanceのバージョンを直接クエリーできる。全てのProvenanceはこのRequestの履歴を対象とすべきである。）

診断のための検査、治療、手術などのサービスリクエストの記録

リソースに関するMetadata。これはインフラストラクチャによって維持されるコンテンツです。 コンテンツの変更は、リソースのバージョン変更と常に関連しているわけではありません。

リソースが最後に変更されたとき - 例えば、バージョンが変更されたとき。

この値はリソースが初めて作成される場合を除いて常に設定されています。サーバー/リソースマネージャーがこの値を設定します。クライアントが提供する値は関係ありません。これはHTTP Last-Modifiedに相当し、readのインタラクションで同じ値を持つべきです。

リソース構築時に遵守された一連のルールを指すものであり、コンテンツを処理する際に理解する必要があります。しばしば、特別なルールを定義する実装ガイドとその他のプロファイルなどを含むものです。

このルールセットを主張することで、取引先の限られた集団にしか内容を理解させることができず、長期的にはデータの有用性が制限されます。しかしながら、現存するヘルスエコシステムは高度に分断化しており、一般的に計算可能な形式でデータを定義、収集、交換する準備が整っていません。できる限り、実装者および/または仕様ライターはこの要素の使用を避けるべきです。使用する場合、URLは、そのナラティブとともに他のプロファイル、値セットなどを含む実装ガイドを定義する参照となります。

リソースの基本的な定義に含まれない、要素の理解や、それを含む要素の子孫の理解を修正する追加情報を表すためにも使用されることがあります。通常、修飾要素は否定や修飾を提供します。拡張機能の使用を安全で管理しやすくするために、拡張機能の定義と使用に対して厳格な統治が適用されます。実装者は拡張機能を定義することが許可されていますが、拡張機能の定義の一部として満たす必要がある要件があります。リソースを処理するアプリケーションは、修飾子拡張をチェックする必要があります。修飾子拡張は、リソースまたはドメインリソースの任意の要素の意味を変更してはなりません（修飾子拡張自体の意味も変更できません）。

どのようなアプリケーション、プロジェクト、または標準が拡張機能を使用しているかに関わらず、拡張機能の使用には決して汚名が付くわけではありません - それらを使用または定義する機関または管轄区域に関係なく。拡張機能の使用こそが、FHIR仕様を誰にとっても簡単なコアレベルで維持することを可能にします。

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

リクエストの発注者、受注者、サービスの実施者によるインスタンスに割り当てられた識別子。

この要素は、発注者（HL7 v2 では 'Placer' ）とリクエストに応じて観察、行為等を実施した者（HL7 v2 では 'Filler' ）を区別するために用いられる。

このサービスリクエストに部分的、または完全に関わる、FHIRで定義されたプロトコル、ガイドライン、オーダセットまたは他の定義を指しているURL

PlanDefinitionリソースは、実行されるアクションのシリーズ、シーケンス、またはグループを記述するために使用され、ActivityDefinitionリソースは、特定の各ステップまたはアクティビティを定義するために使用される。詳細は、PlanDefinition のBoundaries and Relationshipsセクションを参照してください。（訳注:R4とR4Bの本文に誤りあり、修正されたR5を翻訳）

このサービスリクエストに部分的、または完全に関わる、外部の管理されたプロトコール、ガイドライン、オーダセットや他の定義へのURL参照

HTMLページ、PDFなど、名前で解決できないURI識別子

このリクエストによって実施すべき計画、提案、オーダの詳細（への参照）

そのリクエストは、参照された完了または終了したリクエストの代わりを占めます。

一人の発注者によっておおよそ同時に署名されたサービスリクエストの全てに共通する識別子で、複合、またはグループIDを表現する。

サービスリクエストは、basedOn要素、このrequisition要素によって関係付けられる。同じrequisition要素の一部であるサービスリクエストは、初めに作成された後にその状態と管理が変化する視点から、一般的に独立して扱われる。

Some business processes need to know if multiple items were ordered as part of the same "requisition" for billing or other purposes.

オーダの状態

status要素は、一般的に発注者の完全な制御下にあり、オーダが起案か有効かを決定し、有効化された後は、競合、停止、または中断される。受注者の活動に関連する状態は、対応するイベント（一般的な議論についてはEventパターンを参照）またはTaskリソースを使用して反映される。

"サービスオーダーのステータス。"

この要求が、提案、経過、オリジナル、繰り返しかどうかを示す。

この要素は、リソースが実際に適用されるタイミングや方法を意図的に変更するため、修飾子と表現される。

サービスのリクエストの種類

検索、分類、表示の目的でサービスを分類するコード（例 「外科的手技」）

リソースを検索または表示するためのコンテキストまたはユースケースに応じて、複数の分類軸が存在する場合がある。粒度のレベルは、Value Setのカテゴリー概念によって定義される。

要求されたサービスの分類。 (Yōkyū sa reta sābisu no bunrui.)

Used for filtering what service request are retrieved and displayed.

このサービスリクエストはどの程度早く対処されるべきかを示す。

リクエストの対処に割り当てるべき重要度のレベルを特定する。

要求された特定のサービス（例、手技、診断のための検査、また検査パネル）の識別子

一般的には、コードと時間枠のみであるが、時には体の部位や実施者などの修飾語を追加して、禁止範囲を狭められる。code要素とdoNotPerform要素がともに否定を含む場合、禁止を強化することになり、二重否定解釈をしてはならない。

Used for do not ambulate, do not elevate head of bed, do not flush NG tube, do not take blood pressure on a certain arm, etc.

要求された特定のサービス（例、行為、診断のための検査、また検査パネル）の識別子

多くの検査・放射線処置コードは、血清または血漿グルコース、胸部 X 線など、検体・器官系が検査オーダー名に埋め込まれている。検体は、検査コードとは別に記録されないかもしれない。

指定された個人、組織、または医療サービスによって実施できるテストやサービスのコード。ラボの場合、LOINCが（preferred）[http://build.fhir.org/terminologies.html#preferred]であり、LOINCオーダーコードを使用した値セットが[こちら]（valueset-diagnostic-requests.html）で利用可能です。

リクエストの提供方法に関する追加の詳細および指示。例えば、尿道カテーテルのサービスリクエストには、外部または留置カテーテルのリクエストの詳細があり、包帯のサービスリクエストには、包帯の適用方法を指定する追加の指示が必要な場合もある。

リクエストされたサービス提供の指示についての医療記録からの情報については、supportingInformation要素を使用。

注文コンテキストに基づくコード化された注文詳細。

リクエストされるサービスの量。数量（例:1500ドルの住宅改造）、比率（例:1ヶ月に20回の半日訪問）、または範囲（例:1分間に2.0～1.8Gy）。

サービスリクエスト時に、項目とは別に数を指定する必要がある。

When ordering a service the number of service items may need to be specified separately from the the service item.

サービスが実行される対象（人または物）。多くは患者だが、動物、集団（人または動物）、透析器のような装置、また場所（点家的には環境調査）も対象となる。

サービスがリクエストされる医療背景についての追加情報を提供する診療時の場面

リクエストされたサービスを実施すべき日時

CodeableConceptが存在する場合、そのサービスを行うための前提条件を示す。例えば、「痛み」、「再発時」など。

手続きを実行する前に満たされる必要がある前提条件を示すコード化された概念。たとえば、「痛み」、「フレアアップ時」など。

リクエストが有効化された日時

リクエストを開始し、その有効化に責任を持つ個人

伝言をする者ではなく、署名者。この要素は、Provenanceリソースを通じて管理される委任を扱うことを意図していない。

リクエストされたサービスの実施者の役割

参加者の資格ではなく役割。タスクではなく、能力を記述。例えば、「調剤薬局」、「精神科医」、「院内紹介」など。

初診医師」、「チームコーディネーター」、「介護者」など、ケアチーム内の個人の具体的責任を示します。

リクエストされたサービスを行うために望ましい実施者。例えば、外科医、皮膚病理医、内視鏡医など。

実施者が複数の場合、順番に関係なく、優先順位のない実施者のリストとして解釈される。優先順位が必要な場合は、request.performerOrder 拡張を使用する。実施者のグループ（例えば、医師Aと医師B）を表すには、CareTeamを使用する。

実際に行為が行われるべき好ましい場所を、コード化またはフリーテキスト形式で記述。例：自宅や介護施設など。

サービスが提供される場所タイプ。

実際に行為が行われるべき好ましい場所（複数可）への参照。例：自宅や介護施設など。

このサービスがリクエストされる理由についての説明または根拠をコード化またはテキスト化したもの。しばしば（保険）請求を目的とされる。supportingInfoで参照されるリソースに関連する場合がある。

この要素は照会理由を表し、サービスがどのように実行されるか、あるいは全く実行されないかどうかを決定するために使用される。CTスキャンの例で示したように、データが自由記述の場合は、CodeableConcept.text要素を使用する。

サービス調査の依頼理由を正当化する診断または問題コード。

このサービスが要求される理由の正当性を提供する他のリソースを示す。supportingInfoで参照されるリソースに関連する場合がある。

この要素は照会理由を表し、サービスがどのように実行されるか、あるいは全く実行されないかどうかを決定するために使用される。可能な限り具体的にするために、ObservationやConditionリソースへの参照が可能であれば使用されるべきである。また、DiagnosticReport を参照する場合は、DiagnosticReport.conclusion および/または DiagnosticReport.conclusionCode を参照する必要がある。DocumentReference への参照を使用する場合、ターゲット文書は、このサービス要求の関連理由を提供する明確な所見言語を含んでいなければならない。CTスキャンの例に示すように、データが自由記述（符号化されていない）の場合、 ServiceRequest.reasonCodeにCodeableConcept.text要素を使用する。

リクエストされたサービスを提供するために必要な保険プラン、適用範囲拡大、事前承認、および/または事前決定がある。

サービスやその解釈に影響を与える可能性のある、患者や検体に関する追加の臨床情報。この情報には、診断、臨床所見、その他の観察が含まれる。検査のオーダでは、一般的に「オーダエントリー時の質問（AOEs）」と呼ばれ ている。これには、オーダを完了するために必要な文脈や裏付けとなる情報を提供するために、実施者が明示的に要求した観察が含まれる。例えば、血液ガス測定のための吸入酸素量の報告などである。

サービスの提供方法に関する情報を表すには、instructions 要素を使用する。

検査で使用する１つ以上の検体

多くの診断的行為は検体を必要とするが、リクエスト自体は実際には検体に関するものではない。この要素は、診断検査が既に存在する検体に対してリクエストされ、適用される検体を参照するためのものである。逆に、検体が未知の時に最初にリクエストが入力された場合、SpecimenリソースがServiceRequestリソースを参照する。

行為を実施すべき解剖学的部位。目標とする場所。

ServiceRequest.codeにあるコードに暗黙の了解がない場合にのみ使用する。使用例として、BodySiteをインラインコード化された要素ではなく、別のリソースとして扱う必要がある場合（例えば、別々に識別し追跡するため）、procedure.targetBodyStructureの拡張を使用してください。

解剖学的位置を記述するコード。左右対称性を含む場合があります。

Knowing where the procedure is performed is important for tracking if multiple sites are possible.

サービス要求について作成された、その他のメモやコメント。例えば、内部請求のメモなど。

患者または消費者が理解できる言葉で指示。

このリクエストの履歴で重要なもの

この要素はには、ServiceRequestのProvenanceの全てのバージョンではなく、重要と思われたものだけ含められる。現在のバージョンのリソースに関連したProvenanceリソースを含めてはならない（SHALL NOT）。（もし、Provenanceとして重要な変化と思われれば、以降の更新の一部として追加すべきである。それまでは、'_revinclude'を使って指定されたProvenanceのバージョンを直接クエリーできる。全てのProvenanceはこのRequestの履歴を対象とすべきである。）

診断のための検査、治療、手術などのサービスリクエストの記録

リソースのURLで使用される論理ID。一度割り当てられたら、この値は変更されません。

リソースにIDがないのは、作成操作を使用してサーバーに送信されているときだけです。

リソースに関するMetadata。これはインフラストラクチャによって維持されるコンテンツです。 コンテンツの変更は、リソースのバージョン変更と常に関連しているわけではありません。

リソース内の要素の固有ID（内部参照用）。これは、スペースを含まない任意の文字列値である可能性があります。

要素の基本的な定義に含まれない追加情報を表すために使用されることがあります。拡張機能の使用を安全かつ管理しやすくするために、定義および使用に適用される厳格なガバナンスのセットがあります。実装者は拡張機能を定義できますが、拡張機能の定義の一部として満たす必要のある要件のセットがあります。

どのようなアプリケーション、プロジェクト、または標準が拡張機能を使用しているかに関わらず、拡張機能の使用には決して汚名が付くわけではありません - それらを使用または定義する機関または管轄区域に関係なく。拡張機能の使用こそが、FHIR仕様を誰にとっても簡単なコアレベルで維持することを可能にします。

URLのバージョン部分に表示されるバージョン固有のidentifier。この値は、リソースが作成、更新、または削除された場合に変更されます。

サーバーがこの値を割り当て、クライアントが指定した値を無視する。ただし、サーバーが更新/削除時にバージョンの整合性を強制する場合を除く。

リソースが最後に変更されたとき - 例えば、バージョンが変更されたとき。

この値はリソースが初めて作成される場合を除いて常に設定されています。サーバー/リソースマネージャーがこの値を設定します。クライアントが提供する値は関係ありません。これはHTTP Last-Modifiedに相当し、readのインタラクションで同じ値を持つべきです。

リソースのソースシステムを識別するURI。これにより、リソース内の情報のソースをトラックまたは区別するために使用できる最小限の[プロビナンス]（provenance.html＃）情報が提供されます。ソースは、別のFHIRサーバー、ドキュメント、メッセージ、データベースなどを識別できます。

プロバナンスのリソースにおいて、これはProvenance.entity.what[x]に対応します。ソースの正確な使用方法（および含意されるProvenance.entity.role）は実装者の判断に委ねられます。指定されたソースは1つだけです。追加のプロバナンスの詳細が必要な場合は、完全なプロバナンスリソースを使用するべきです。

この要素は、正規のURLでホストされていないリソースの現在のマスターソースがどこにあるかを示すために使用できます。

このリソースが準拠すると主張する StructureDefinition リソースに関するプロファイルのリストです。URL は StructureDefinition.url への参照です。

これらの主張が時間の経過に伴って検証または更新される方法と、それらを決定するサーバーや他の基盤に任されます。プロファイルURLのリストは1セットです。

このリソースにはセキュリティラベルが適用されています。これらのタグにより、特定のリソースが全体的なセキュリティポリシーやインフラストラクチャに関連付けられます。

セキュリティラベルは変更せずにリソースのバージョンを更新可能です。セキュリティラベルのリストはセットであり、一意性はシステム/コードに基づき、バージョンと表示は無視されます。

医療プライバシーおよびセキュリティ分類システムからのセキュリティラベル。

このリソースに適用されるタグです。タグは、リソースをプロセスやワークフローに識別し、関連付けるために使用することが意図されており、アプリケーションはリソースの意味を解釈する際にタグを考慮する必要はありません。

リソースの表示バージョンを変更することなく、タグを更新できます。タグのリストは集合です。ユニーク性はシステム/コードに基づき、バージョンと表示は無視されます。

様々なタグを表すコードで、一般的にはワークフローに関連しています。例：「ジョーンズ博士によるレビューが必要です」。

リソース構築時に遵守された一連のルールを指すものであり、コンテンツを処理する際に理解する必要があります。しばしば、特別なルールを定義する実装ガイドとその他のプロファイルなどを含むものです。

このルールセットを主張することで、取引先の限られた集団にしか内容を理解させることができず、長期的にはデータの有用性が制限されます。しかしながら、現存するヘルスエコシステムは高度に分断化しており、一般的に計算可能な形式でデータを定義、収集、交換する準備が整っていません。できる限り、実装者および/または仕様ライターはこの要素の使用を避けるべきです。使用する場合、URLは、そのナラティブとともに他のプロファイル、値セットなどを含む実装ガイドを定義する参照となります。

リソースが書かれている基本言語。

言語はインデックスとアクセシビリティをサポートするために提供されます（通常、テキスト読み上げなどのサービスは言語タグを使用します）。物語のHTML言語タグは、物語に適用されます。リソース上の言語タグは、リソース内のデータから生成される他のプレゼンテーションの言語を指定するために使用できます。すべてのコンテンツが基本言語である必要はありません。Resource.languageは自動的に物語に適用されたと想定してはいけません。言語が指定されている場合、HTMLのdiv要素にも指定する必要があります（xml：langとhtml lang属性の関係に関する情報はHTML5の規則を参照）。

「人間の言語。」

リソースの要約を含む人が読めるナビゲーションであり、リソースの内容を人に表現するために使用できます。ナビゲーションはすべての構造化されたデータをエンコードする必要はありませんが、人間がナビゲーションを読むだけで「臨床的に安全」であるために十分な詳細を含む必要があります。リソース定義には、臨床的な安全性を確保するためにナビゲーションで表現する必要があるコンテンツが定義される場合があります。

含まれるリソースには説明がありません。含まれないリソースには説明が必要です。場合によっては、リソースが少量のデータしか含まず、テキストだけで表現されることがあります（minOccurs = 1要素がすべて満たされている限り）。これは、情報が「テキストの塊」としてキャプチャされるレガシーシステムからのデータや、テキストが生またはナレーションされて符号化された情報が後で追加される場合に必要な場合があります。

これらのリソースは、それらを含むリソースから独立した存在を持ちません。それらは独立して識別することはできず、独自の独立したトランザクション範囲を持つこともできません。

コンテンツが適切に識別できる場合には、これを行うべきではありません。識別が失われると、再び復元することは非常に困難であり（文脈に依存します）、メタ要素にプロファイルとタグを持つことができますが、セキュリティのラベルを持っていてはいけません。

リソースの基本的な定義の一部ではない追加情報を表すために使用することができます。拡張機能の使用を安全かつ管理可能にするために、定義と使用の一定のガバナンスが適用されます。実装者はどんな拡張機能でも定義できますが、拡張機能の定義の一部として満たす必要がある要件があります

どのようなアプリケーション、プロジェクト、または標準が拡張機能を使用しているかに関わらず、拡張機能の使用には決して汚名が付くわけではありません - それらを使用または定義する機関または管轄区域に関係なく。拡張機能の使用こそが、FHIR仕様を誰にとっても簡単なコアレベルで維持することを可能にします。

リソースの基本的な定義に含まれない、要素の理解や、それを含む要素の子孫の理解を修正する追加情報を表すためにも使用されることがあります。通常、修飾要素は否定や修飾を提供します。拡張機能の使用を安全で管理しやすくするために、拡張機能の定義と使用に対して厳格な統治が適用されます。実装者は拡張機能を定義することが許可されていますが、拡張機能の定義の一部として満たす必要がある要件があります。リソースを処理するアプリケーションは、修飾子拡張をチェックする必要があります。修飾子拡張は、リソースまたはドメインリソースの任意の要素の意味を変更してはなりません（修飾子拡張自体の意味も変更できません）。

どのようなアプリケーション、プロジェクト、または標準が拡張機能を使用しているかに関わらず、拡張機能の使用には決して汚名が付くわけではありません - それらを使用または定義する機関または管轄区域に関係なく。拡張機能の使用こそが、FHIR仕様を誰にとっても簡単なコアレベルで維持することを可能にします。

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

リクエストの発注者、受注者、サービスの実施者によるインスタンスに割り当てられた識別子。

この要素は、発注者（HL7 v2 では 'Placer' ）とリクエストに応じて観察、行為等を実施した者（HL7 v2 では 'Filler' ）を区別するために用いられる。

このサービスリクエストに部分的、または完全に関わる、FHIRで定義されたプロトコル、ガイドライン、オーダセットまたは他の定義を指しているURL

PlanDefinitionリソースは、実行されるアクションのシリーズ、シーケンス、またはグループを記述するために使用され、ActivityDefinitionリソースは、特定の各ステップまたはアクティビティを定義するために使用される。詳細は、PlanDefinition のBoundaries and Relationshipsセクションを参照してください。（訳注:R4とR4Bの本文に誤りあり、修正されたR5を翻訳）

このサービスリクエストに部分的、または完全に関わる、外部の管理されたプロトコール、ガイドライン、オーダセットや他の定義へのURL参照

HTMLページ、PDFなど、名前で解決できないURI識別子

このリクエストによって実施すべき計画、提案、オーダの詳細（への参照）

そのリクエストは、参照された完了または終了したリクエストの代わりを占めます。

一人の発注者によっておおよそ同時に署名されたサービスリクエストの全てに共通する識別子で、複合、またはグループIDを表現する。

サービスリクエストは、basedOn要素、このrequisition要素によって関係付けられる。同じrequisition要素の一部であるサービスリクエストは、初めに作成された後にその状態と管理が変化する視点から、一般的に独立して扱われる。

Some business processes need to know if multiple items were ordered as part of the same "requisition" for billing or other purposes.

オーダの状態

status要素は、一般的に発注者の完全な制御下にあり、オーダが起案か有効かを決定し、有効化された後は、競合、停止、または中断される。受注者の活動に関連する状態は、対応するイベント（一般的な議論についてはEventパターンを参照）またはTaskリソースを使用して反映される。

"サービスオーダーのステータス。"

この要求が、提案、経過、オリジナル、繰り返しかどうかを示す。

この要素は、リソースが実際に適用されるタイミングや方法を意図的に変更するため、修飾子と表現される。

サービスのリクエストの種類

検索、分類、表示の目的でサービスを分類するコード（例 「外科的手技」）

リソースを検索または表示するためのコンテキストまたはユースケースに応じて、複数の分類軸が存在する場合がある。粒度のレベルは、Value Setのカテゴリー概念によって定義される。

要求されたサービスの分類。 (Yōkyū sa reta sābisu no bunrui.)

Used for filtering what service request are retrieved and displayed.

このサービスリクエストはどの程度早く対処されるべきかを示す。

リクエストの対処に割り当てるべき重要度のレベルを特定する。

要求された特定のサービス（例、手技、診断のための検査、また検査パネル）の識別子

一般的には、コードと時間枠のみであるが、時には体の部位や実施者などの修飾語を追加して、禁止範囲を狭められる。code要素とdoNotPerform要素がともに否定を含む場合、禁止を強化することになり、二重否定解釈をしてはならない。

Used for do not ambulate, do not elevate head of bed, do not flush NG tube, do not take blood pressure on a certain arm, etc.

要求された特定のサービス（例、行為、診断のための検査、また検査パネル）の識別子

多くの検査・放射線処置コードは、血清または血漿グルコース、胸部 X 線など、検体・器官系が検査オーダー名に埋め込まれている。検体は、検査コードとは別に記録されないかもしれない。

指定された個人、組織、または医療サービスによって実施できるテストやサービスのコード。ラボの場合、LOINCが（preferred）[http://build.fhir.org/terminologies.html#preferred]であり、LOINCオーダーコードを使用した値セットが[こちら]（valueset-diagnostic-requests.html）で利用可能です。

リクエストの提供方法に関する追加の詳細および指示。例えば、尿道カテーテルのサービスリクエストには、外部または留置カテーテルのリクエストの詳細があり、包帯のサービスリクエストには、包帯の適用方法を指定する追加の指示が必要な場合もある。

リクエストされたサービス提供の指示についての医療記録からの情報については、supportingInformation要素を使用。

注文コンテキストに基づくコード化された注文詳細。

リクエストされるサービスの量。数量（例:1500ドルの住宅改造）、比率（例:1ヶ月に20回の半日訪問）、または範囲（例:1分間に2.0～1.8Gy）。

サービスリクエスト時に、項目とは別に数を指定する必要がある。

When ordering a service the number of service items may need to be specified separately from the the service item.

サービスが実行される対象（人または物）。多くは患者だが、動物、集団（人または動物）、透析器のような装置、また場所（点家的には環境調査）も対象となる。

サービスがリクエストされる医療背景についての追加情報を提供する診療時の場面

リクエストされたサービスを実施すべき日時

CodeableConceptが存在する場合、そのサービスを行うための前提条件を示す。例えば、「痛み」、「再発時」など。

手続きを実行する前に満たされる必要がある前提条件を示すコード化された概念。たとえば、「痛み」、「フレアアップ時」など。

リクエストが有効化された日時

リクエストを開始し、その有効化に責任を持つ個人

伝言をする者ではなく、署名者。この要素は、Provenanceリソースを通じて管理される委任を扱うことを意図していない。

リクエストされたサービスの実施者の役割

参加者の資格ではなく役割。タスクではなく、能力を記述。例えば、「調剤薬局」、「精神科医」、「院内紹介」など。

初診医師」、「チームコーディネーター」、「介護者」など、ケアチーム内の個人の具体的責任を示します。

リクエストされたサービスを行うために望ましい実施者。例えば、外科医、皮膚病理医、内視鏡医など。

実施者が複数の場合、順番に関係なく、優先順位のない実施者のリストとして解釈される。優先順位が必要な場合は、request.performerOrder 拡張を使用する。実施者のグループ（例えば、医師Aと医師B）を表すには、CareTeamを使用する。

実際に行為が行われるべき好ましい場所を、コード化またはフリーテキスト形式で記述。例：自宅や介護施設など。

サービスが提供される場所タイプ。

実際に行為が行われるべき好ましい場所（複数可）への参照。例：自宅や介護施設など。

このサービスがリクエストされる理由についての説明または根拠をコード化またはテキスト化したもの。しばしば（保険）請求を目的とされる。supportingInfoで参照されるリソースに関連する場合がある。

この要素は照会理由を表し、サービスがどのように実行されるか、あるいは全く実行されないかどうかを決定するために使用される。CTスキャンの例で示したように、データが自由記述の場合は、CodeableConcept.text要素を使用する。

サービス調査の依頼理由を正当化する診断または問題コード。

このサービスが要求される理由の正当性を提供する他のリソースを示す。supportingInfoで参照されるリソースに関連する場合がある。

この要素は照会理由を表し、サービスがどのように実行されるか、あるいは全く実行されないかどうかを決定するために使用される。可能な限り具体的にするために、ObservationやConditionリソースへの参照が可能であれば使用されるべきである。また、DiagnosticReport を参照する場合は、DiagnosticReport.conclusion および/または DiagnosticReport.conclusionCode を参照する必要がある。DocumentReference への参照を使用する場合、ターゲット文書は、このサービス要求の関連理由を提供する明確な所見言語を含んでいなければならない。CTスキャンの例に示すように、データが自由記述（符号化されていない）の場合、 ServiceRequest.reasonCodeにCodeableConcept.text要素を使用する。

リクエストされたサービスを提供するために必要な保険プラン、適用範囲拡大、事前承認、および/または事前決定がある。

サービスやその解釈に影響を与える可能性のある、患者や検体に関する追加の臨床情報。この情報には、診断、臨床所見、その他の観察が含まれる。検査のオーダでは、一般的に「オーダエントリー時の質問（AOEs）」と呼ばれ ている。これには、オーダを完了するために必要な文脈や裏付けとなる情報を提供するために、実施者が明示的に要求した観察が含まれる。例えば、血液ガス測定のための吸入酸素量の報告などである。

サービスの提供方法に関する情報を表すには、instructions 要素を使用する。

検査で使用する１つ以上の検体

多くの診断的行為は検体を必要とするが、リクエスト自体は実際には検体に関するものではない。この要素は、診断検査が既に存在する検体に対してリクエストされ、適用される検体を参照するためのものである。逆に、検体が未知の時に最初にリクエストが入力された場合、SpecimenリソースがServiceRequestリソースを参照する。

行為を実施すべき解剖学的部位。目標とする場所。

ServiceRequest.codeにあるコードに暗黙の了解がない場合にのみ使用する。使用例として、BodySiteをインラインコード化された要素ではなく、別のリソースとして扱う必要がある場合（例えば、別々に識別し追跡するため）、procedure.targetBodyStructureの拡張を使用してください。

解剖学的位置を記述するコード。左右対称性を含む場合があります。

Knowing where the procedure is performed is important for tracking if multiple sites are possible.

サービス要求について作成された、その他のメモやコメント。例えば、内部請求のメモなど。

患者または消費者が理解できる言葉で指示。

このリクエストの履歴で重要なもの

この要素はには、ServiceRequestのProvenanceの全てのバージョンではなく、重要と思われたものだけ含められる。現在のバージョンのリソースに関連したProvenanceリソースを含めてはならない（SHALL NOT）。（もし、Provenanceとして重要な変化と思われれば、以降の更新の一部として追加すべきである。それまでは、'_revinclude'を使って指定されたProvenanceのバージョンを直接クエリーできる。全てのProvenanceはこのRequestの履歴を対象とすべきである。）