診断調査、治療、手術などのサービスの依頼記録。

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

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

この値はリソースが初めて作成される場合を除いて常に設定されています。サーバー/リソースマネージャーがこの値を設定します。クライアントが提供する値は関係ありません。これは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.

"注文の状況。"

状態は一般的にリクエスターの完全なコントロール下にあります。彼らは、注文が下書きかアクティブかを決定し、アクティベートされた後は、完了、キャンセル、または一時停止するかどうかを決定する責任があります。パフォーマーの活動に関連する状態は、対応するイベント（一般的なディスカッションには イベントパターン を参照）または タスク リソースを使用して反映されます。

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

その依頼が提案、計画、オリジナルの注文、反射的な注文であるかどうかは問わない。

この要素は修飾子としてラベル付けされています。なぜなら、意図が変わり、リソースが実際に適用可能な場合と方法が変わるからです。

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

記録が該当サービス/プロシジャー（処置等）を実行してはいけないと言っている場合は、これをtrueに設定してください。

一般的に、コードと時限のみが存在しますが、たまに部位や実行者などの追加の修飾語が含まれることがあります。ServiceRequest.codeとServiceRequest.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.

どの人または何にサービスを実施するか。通常は人の患者ですが、動物、人間または動物のグループ、透析機器など、場合によっては場所（環境スキャン用に）にも要求されることがあります。

診断調査、治療、手術などのサービスの依頼記録。

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

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

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

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

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

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

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

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

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

この値はリソースが初めて作成される場合を除いて常に設定されています。サーバー/リソースマネージャーがこの値を設定します。クライアントが提供する値は関係ありません。これは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.

オーダラー、レシーバー、オーダーフルフィラーによってこの注文インスタンスに割り当てられた識別子。

identifier.type要素は、オーダラーが割り当てる識別子（HL7 v2では「Placer」として知られています）と、オーダーに応じて観察を行う製造業者（HL7 v2では「Filler」として知られている）との間の区別に使用されます。詳細なディスカッションと例については、以下のリソースノートセクションを参照してください。

このServiceRequestによって全体または一部に従われる、FHIRで定義されたプロトコル、ガイドライン、オーダーセットまたはその他の定義を指すURL。

注：これはリソース識別子ではなくビジネス識別子です（議論を参照してください）。識別子が単一のリソースインスタンスにしか表示されないようにするのが最善の方法ですが、ビジネスプラクティスによっては、同じ識別子を持つ複数のリソースインスタンスが存在する場合があります。さらに、異なるリソースタイプであっても可能です。たとえば、複数の患者と人のリソースインスタンスが同じ社会保険番号を共有するかもしれません。

このServiceRequestにおいて、部分的にまたは完全に従われる外部で管理されているプロトコル、ガイドライン、オーダーセットその他の定義へのURL

これはHTMLページ、PDFなどであるか、解決不能なURI識別子である可能性があります。

このリクエストによって計画/提案/注文が履行されました。

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

共通の識別子であり、単一の作者によってほぼ同時に承認されたすべてのサービスリクエストに共通するものであり、複合またはグループ識別子を表します。

リクエストは、「basedOn」の関係（つまり、1つのリクエストが別のリクエストを満たすこと）によって、または共通の要求によってリンクされます。同じ要求の一部であるリクエストは、状態を変更する観点や初期作成後の維持の観点から一般的に独立して扱われます。

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

"注文の状況。"

状態は一般的にリクエスターの完全なコントロール下にあります。彼らは、注文が下書きかアクティブかを決定し、アクティベートされた後は、完了、キャンセル、または一時停止するかどうかを決定する責任があります。パフォーマーの活動に関連する状態は、対応するイベント（一般的なディスカッションには イベントパターン を参照）または タスク リソースを使用して反映されます。

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

その依頼が提案、計画、オリジナルの注文、反射的な注文であるかどうかは問わない。

この要素は修飾子としてラベル付けされています。なぜなら、意図が変わり、リソースが実際に適用可能な場合と方法が変わるからです。

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

「手術処置」など、検索、ソート、表示のためのサービスを分類するコード。

リソースを取得したり表示するための文脈や使用例に応じて、複数の分類軸が存在する場合があります。レベルの細かさは、値セット内のカテゴリコンセプトによって定義されます。

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

Used for filtering what service request are retrieved and displayed.

他のリクエストに対して、ServiceRequestがどのくらい迅速に対応すべきかを示します。

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

記録が該当サービス/プロシジャー（処置等）を実行してはいけないと言っている場合は、これをtrueに設定してください。

一般的に、コードと時限のみが存在しますが、たまに部位や実行者などの追加の修飾語が含まれることがあります。ServiceRequest.codeとServiceRequest.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要素を使用してください。

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

要求されるサービスの量は、数量であることができます（例：$1,500の住宅改修）、比率であることができます（例：1か月あたり20回の半日訪問）、または範囲であることができます（1回あたり2.0〜1.8 Gy）。

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

どの人または何にサービスを実施するか。通常は人の患者ですが、動物、人間または動物のグループ、透析機器など、場合によっては場所（環境スキャン用に）にも要求されることがあります。

この要求がされたヘルスケアの文脈に関する追加情報を提供するEncounter（診察、受診、入退院など）。

リクエストされたサービスが行われる日時。

CodeableConceptが存在する場合、それはサービスを提供するための前提条件を示します。例えば「痛み」「急増時」などです。

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

リクエストが実行可能な状態に移行したとき。

リクエストを開始し、その活性化の責任を持つ個人

これはディスパッチャーではなく、認可者です。この要素は、慣例的にプロバニエンスリソースを介して管理される委任を処理することを意図していません。

希望するパフォーマーのタイプは、リクエストされたサービスを行うためです。

これは役割であり、参加タイプではありません。言い換えれば、タスクを説明するのではなく、能力を説明します。例えば、「混合薬局」、「精神科医」、「内部紹介」などです。

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

要求されたサービスを行うために希望の演者。例えば、外科医、皮膚病理学者、内視鏡医など。

複数のパフォーマーが存在する場合、順序に関係なく、好みのない代替のパフォーマーのリストとして解釈されます。好みの順序が必要な場合は、request-performerOrder拡張機能を使用してください。パフォーマーのグループを表すには、CareTeamを使用します（例：実践者A および実践者B）。

手続きが実際に行われることが好ましい場所は、コード化されたテキスト形式または自由なテキスト形式で指定されます。例えば、自宅や介護デイケアセンターなどがあります。

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

実際にプロシジャー（処置等）が行われることが好ましい場所に関する参照。例、自宅または介護デイケアセンター。

このサービスをリクエストする理由や正当性について、コード化またはテキスト形式で説明または正当化すること。通常は請求目的のためです。「supportingInfo」で参照されるリソースに関連する場合があります。

この要素は、どのような理由で紹介がなされたかを示し、サービスを提供する方法、または提供するかどうかを決定するために使用されることがあります。データが自由（符号化されていない）テキストである場合は、CT Scan exampleに示されているように、CodeableConcept.text 要素を使用してください。

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

「このサービスが要求されている理由を正当化する他のリソースを示します。」サポート情報で言及されているリソースに関連する場合があります。

この要素は紹介理由を表し、サービスの提供方法、あるいは提供されるかどうかを決定するために使用される可能性があります。できるだけ具体的にするために、ObservationまたはConditionへの参照が可能な場合は使用するべきです。そうでない場合、DiagnosticReportへの参照をする場合は、DiagnosticReport.conclusionおよび/またはDiagnosticReport.conclusionCodeに結果が含まれている必要があります。DocumentReferenceへの参照を使用する場合は、対象の文書には、このサービスの要求の関連する理由を提供する明確な発見用語が含まれている必要があります。CTスキャンの例に示されるように、データがフリー（コード化されていない）テキストの場合は、ServiceRequest.reasonCode内のCodeableConceptテキスト要素を使用してください。

要求されたサービスを提供するために必要な保険プラン、補償の拡張、前承認および/または前決定

患者または検体に関する追加の臨床情報が、サービスまたはその解釈に影響を与える可能性があります。この情報には、診断、臨床所見、その他の観察が含まれます。これらは一般的に「注文エントリー時の質問（AOE）で問い合わせること」と呼ばれます。これには、生産者（フィラー）が明示的に要求し、注文を完了するために必要な文脈または補助情報を提供する観察が含まれます。例えば、血液ガス測定のための吸入酸素量を報告することが挙げられます。

サービスを提供する方法に関する情報を表現するには、 instructions 要素を使用してください。

実験室のプロシジャー（処置等）で使用される1つ以上の標本。

多くの診断プロシジャー（処置等）ではサンプルが必要ですが、要求自体は実際にはサンプルに関するものではありません。この要素は、既存のサンプルに対して診断が要求され、要求が適用されるサンプルを指す場合に使用されます。逆に、要求が先に未知のサンプルで入力された場合、試料リソースはServiceRequestを指します。

プロシジャー（処置等）を実行する解剖学的位置。これが目標箇所です。

ServiceRequest.codeで含意されていない場合にのみ使用する。ボディサイトをインラインのコード化要素の代わりに個別のリソースとして扱う必要がある場合（例：別々に識別して追跡する場合）、標準の拡張[プロシージャターゲットボディストラクチャ]（extension-procedure-targetbodystructure.html）を使用してください。

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

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

サービス依頼についてのその他のノートやコメント。例えば、内部の請求ノートなど。

患者または消費者に理解できる言葉での説明書

依頼の歴史における重要な出来事

この要求のすべてのバージョンについての出所が含まれるわけではない可能性があります。 "関連性"があると判断されたものだけを含みます。 これには、リソースの現在のバージョンに関連するプロバイダンスは含まれません。 （そのプロバイダンスが「関連のある」変更であると判断された場合、後の更新の一部として追加する必要があります。それまでは、_revincludeを使用してこのバージョンを指すプロバイダンスとして直接クエリできます） すべてのプロバニタンスには、この要求の何らかの歴史的バージョンがサブジェクトとして含まれる必要があります。