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

The metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content might not always be associated with version changes to the resource.

When the resource last changed - e.g. when the version changed.

This value is always populated except when the resource is first being created. The server / resource manager sets this value; what a client provides is irrelevant. This is equivalent to the HTTP Last-Modified and SHOULD have the same value on a read interaction.

A reference to a set of rules that were followed when the resource was constructed, and which must be understood when processing the content. Often, this is a reference to an implementation guide that defines the special rules along with other profiles etc.

Asserting this rule set restricts the content to be only understood by a limited set of trading partners. This inherently limits the usefulness of the data in the long term. However, the existing health eco-system is highly fractured, and not yet ready to define, collect, and exchange data in a generally computable sense. Wherever possible, implementers and/or specification writers should avoid using this element. Often, when used, the URL is a reference to an implementation guide that defines these special rules as part of it's narrative along with other profiles, value sets, etc.

May be used to represent additional information that is not part of the basic definition of the resource and that modifies the understanding of the element that contains it and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer is allowed to define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

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識別子

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

The request takes the place of the referenced completed or terminated request(s).

一人の発注者によっておおよそ同時に署名されたサービスリクエストの全てに共通する識別子で、複合、またはグループ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リソースを使用して反映される。

The status of a service order.

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

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

The kind of service request.

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

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

Used for filtering what service request are retrieved and displayed.

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

Identifies the level of importance to be assigned to actioning the request.

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

一般的には、コードと時間枠のみであるが、時には体の部位や実施者などの修飾語を追加して、禁止範囲を狭められる。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 線など、検体・器官系が検査オーダー名に埋め込まれている。検体は、検査コードとは別に記録されないかもしれない。

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

リクエストされたサービス提供の指示についての医療記録からの情報については、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が存在する場合、そのサービスを行うための前提条件を示す。例えば、「痛み」、「再発時」など。

A coded concept identifying the pre-condition that should hold prior to performing a procedure. For example "pain", "on flare-up", etc.

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

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

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

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

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

Indicates specific responsibility of an individual within the care team, such as "Primary physician", "Team coordinator", "Caregiver", etc.

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

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

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

A location type where services are delivered.

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

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

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

Diagnosis or problem codes justifying the reason for requesting the service investigation.

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

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

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

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

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

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

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

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

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

Codes describing anatomical locations. May include laterality.

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の履歴を対象とすべきである。）

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

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

この要素は、発注者（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の履歴を対象とすべきである。）

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

The logical id of the resource, as used in the URL for the resource. Once assigned, this value never changes.

The only time that a resource does not have an id is when it is being submitted to the server using a create operation.

The metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content might not always be associated with version changes to the resource.

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

The version specific identifier, as it appears in the version portion of the URL. This value changes when the resource is created, updated, or deleted.

The server assigns this value, and ignores what the client specifies, except in the case that the server is imposing version integrity on updates/deletes.

When the resource last changed - e.g. when the version changed.

This value is always populated except when the resource is first being created. The server / resource manager sets this value; what a client provides is irrelevant. This is equivalent to the HTTP Last-Modified and SHOULD have the same value on a read interaction.

A uri that identifies the source system of the resource. This provides a minimal amount of Provenance information that can be used to track or differentiate the source of information in the resource. The source may identify another FHIR server, document, message, database, etc.

In the provenance resource, this corresponds to Provenance.entity.what[x]. The exact use of the source (and the implied Provenance.entity.role) is left to implementer discretion. Only one nominated source is allowed; for additional provenance details, a full Provenance resource should be used.

This element can be used to indicate where the current master source of a resource that has a canonical URL if the resource is no longer hosted at the canonical URL.

A list of profiles (references to StructureDefinition resources) that this resource claims to conform to. The URL is a reference to StructureDefinition.url.

It is up to the server and/or other infrastructure of policy to determine whether/how these claims are verified and/or updated over time. The list of profile URLs is a set.

Security labels applied to this resource. These tags connect specific resources to the overall security policy and infrastructure.

The security labels can be updated without changing the stated version of the resource. The list of security labels is a set. Uniqueness is based the system/code, and version and display are ignored.

Security Labels from the Healthcare Privacy and Security Classification System.

Tags applied to this resource. Tags are intended to be used to identify and relate resources to process and workflow, and applications are not required to consider the tags when interpreting the meaning of a resource.

The tags can be updated without changing the stated version of the resource. The list of tags is a set. Uniqueness is based the system/code, and version and display are ignored.

Codes that represent various types of tags, commonly workflow-related; e.g. "Needs review by Dr. Jones".

A reference to a set of rules that were followed when the resource was constructed, and which must be understood when processing the content. Often, this is a reference to an implementation guide that defines the special rules along with other profiles etc.

Asserting this rule set restricts the content to be only understood by a limited set of trading partners. This inherently limits the usefulness of the data in the long term. However, the existing health eco-system is highly fractured, and not yet ready to define, collect, and exchange data in a generally computable sense. Wherever possible, implementers and/or specification writers should avoid using this element. Often, when used, the URL is a reference to an implementation guide that defines these special rules as part of it's narrative along with other profiles, value sets, etc.

The base language in which the resource is written.

Language is provided to support indexing and accessibility (typically, services such as text to speech use the language tag). The html language tag in the narrative applies to the narrative. The language tag on the resource may be used to specify the language of other presentations generated from the data in the resource. Not all the content has to be in the base language. The Resource.language should not be assumed to apply to the narrative automatically. If a language is specified, it should it also be specified on the div element in the html (see rules in HTML5 for information about the relationship between xml:lang and the html lang attribute).

A human language.

A human-readable narrative that contains a summary of the resource and can be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative. Resource definitions may define what content should be represented in the narrative to ensure clinical safety.

Contained resources do not have narrative. Resources that are not contained SHOULD have a narrative. In some cases, a resource may only have text with little or no additional discrete data (as long as all minOccurs=1 elements are satisfied). This may be necessary for data from legacy systems where information is captured as a "text blob" or where text is additionally entered raw or narrated and encoded information is added later.

These resources do not have an independent existence apart from the resource that contains them - they cannot be identified independently, and nor can they have their own independent transaction scope.

This should never be done when the content can be identified properly, as once identification is lost, it is extremely difficult (and context dependent) to restore it again. Contained resources may have profiles and tags In their meta elements, but SHALL NOT have security labels.

May be used to represent additional information that is not part of the basic definition of the resource. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

May be used to represent additional information that is not part of the basic definition of the resource and that modifies the understanding of the element that contains it and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer is allowed to define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

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識別子

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

The request takes the place of the referenced completed or terminated request(s).

一人の発注者によっておおよそ同時に署名されたサービスリクエストの全てに共通する識別子で、複合、またはグループ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リソースを使用して反映される。

The status of a service order.

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

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

The kind of service request.

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

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

Used for filtering what service request are retrieved and displayed.

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

Identifies the level of importance to be assigned to actioning the request.

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

一般的には、コードと時間枠のみであるが、時には体の部位や実施者などの修飾語を追加して、禁止範囲を狭められる。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 線など、検体・器官系が検査オーダー名に埋め込まれている。検体は、検査コードとは別に記録されないかもしれない。

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

リクエストされたサービス提供の指示についての医療記録からの情報については、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が存在する場合、そのサービスを行うための前提条件を示す。例えば、「痛み」、「再発時」など。

A coded concept identifying the pre-condition that should hold prior to performing a procedure. For example "pain", "on flare-up", etc.

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

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

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

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

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

Indicates specific responsibility of an individual within the care team, such as "Primary physician", "Team coordinator", "Caregiver", etc.

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

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

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

A location type where services are delivered.

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

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

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

Diagnosis or problem codes justifying the reason for requesting the service investigation.

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

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

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

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

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

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

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

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

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

Codes describing anatomical locations. May include laterality.

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の履歴を対象とすべきである。）