Observation Common Profile

HL7 FHIR JP Core ImplementationGuide
1.1.1 - release Japan flag

HL7 FHIR JP Core ImplementationGuide - Local Development build (v1.1.1). See the Directory of published versions

Resource Profile: JP Core Observation Common Profile

項目	内容
定義URL	http://jpfhir.jp/fhir/core/StructureDefinition/JP_Observation_Common
Version	1.1.1
Name	JP_Observation_Common
Title	JP Core Observation Common Profile
Status	Active ( 2022-10-24 )
Copyright	Copyright FHIR Japanese implementation research working group in Japan Association of Medical Informatics (JAMI) 一般社団法人日本医療情報学会NeXEHRS課題研究会FHIR日本実装検討WG

このプロファイルはObservationリソースに対して、データを送受信するための共通の制約と拡張を定めたものである。

背景および想定シナリオ

Observationリソースに対する主な用途は以下の通り。

体重、血圧、体温などのバイタルサイン
血糖値や推定GFRなどの検体検査結果
骨密度や胎児測定値などの画像検査結果
腹部圧痛などの臨床所見（※）
目の色など、個人的な特徴
喫煙歴、社会歴、家族支援、認知状態など

※ 臨床所見と疾患の境界は、医療オントロジの課題となる。一般的なガイドについては、Observationリソースの境界およびConditionリソースの境界のセクションを参照のこと。

スコープ

Observation（検査、観察）はヘルスケアの中心的な要素であり、診断の補助、進行状況のモニタリング、基準とパターンの決定、人口統計的特性の把握に使用される。ほとんどのObservationは、メタデータを含む単純な名前/値のペアとなる。一部のObservationは、他のObservationを論理的にグループ化したり、複数の要素から構成される場合もある。

DiagnosticReport（検査レポート）リソースは一連の検査の臨床/ワークフローの文脈を定義する。ObservationリソースはDiagnosticReportから参照されることで、検査、画像、その他の臨床および診断データから表現されるレポートを形作る。

プロファイル定義

Usage:

Derived from this Resource Profile: JP Core Observation BodyMeasurement Profile, JP Core Observation LabResult Profile, JP Core Observation PhysicalExam Profile, JP Core Observation SocialHistory Profile, JP Core Observation VitalSigns Profile
Refer to this Resource Profile:

プロファイル詳細

Description of Profiles, Differentials, Snapshots and how the different presentations work.

Text Summary
Differential Table
Snapshot Table
Terminology Bindings
Constraints
All

This structure is derived from Observation

Summary

Structures

This structure refers to these other structures:

Name	Card.	Type	Description & Constraints
Observation	0..*	Observation	測定や簡単な観察事実（assertion）
identifier	0..*	Identifier	Business Identifier for observation　Observationのためのビジネス識別子
basedOn	0..*	Reference(CarePlan \| DeviceRequest \| ImmunizationRecommendation \| JP Core MedicationRequest Profile \| JP Core MedicationRequest Injection Profile \| NutritionOrder \| ServiceRequest)	Fulfills plan, proposal or order　実施されるプラン、提案、依頼
partOf	0..*	Reference(JP Core MedicationAdministration Profile \| JP Core MedicationAdministration Injection Profile \| JP Core MedicationDispenseBase Profile \| MedicationStatement \| JP Core Procedure Profile \| JP Core Immunization Profile \| ImagingStudy)	Part of referenced event　参照されるイベントの一部分
status	1..1	code	registered \| preliminary \| final \| amended +
category	0..*	CodeableConcept	Classification of type of observation　Observationの種類（タイプ）の分類
code	1..1	CodeableConcept	Type of observation (code / type)　observation のタイプ（コードまたはタイプ）
subject	0..1	Reference(JP Core Patient Profile \| Group \| Device \| JP Core Location Profile)	Who and/or what the observation is about　観察対象者
focus	0..*	Reference(Resource)	What the observation is about, when it is not about the subject of record　subject 要素が実際のobservationの対象でない場合に、observation の対象物
encounter	0..1	Reference(JP Core Encounter Profile)	Healthcare event during which this observation is made　このobservationが行われるヘルスケアイベント
effective[x]	0..1	dateTime, Period, Timing, instant	Clinically relevant time/time-period for observation　臨床的に関連する時刻または時間
issued	0..1	instant	Date/Time this version was made available　このバージョンが利用可能となった日時
performer	0..*	Reference(JP Core Practitioner Profile \| JP Core PractitionerRole Profile \| JP Core Organization Profile \| CareTeam \| JP Core Patient Profile \| RelatedPerson)	Who is responsible for the observation　observationに責任をもつ者
value[x]	0..1	Quantity, CodeableConcept, string, boolean, integer, Range, Ratio, SampledData, time, dateTime, Period	Actual result　実際の結果値
dataAbsentReason	0..1	CodeableConcept	Why the result is missing　結果が欠損値である理由
interpretation	0..*	CodeableConcept	High, low, normal, etc.
note	0..*	Annotation	Comments about the observation　結果に対するコメント
bodySite	0..1	CodeableConcept	Bindingについてはユースケースに応じて各プロファイルで定義すること
method	0..1	CodeableConcept	Bindingについてはユースケースに応じて各プロファイルで定義すること
specimen	0..1	Reference(Specimen)	Specimen used for this observation　観察（観測、検査）に使われた検体材料
device	0..1	Reference(Device \| DeviceMetric)	(Measurement) Device　測定機器
referenceRange	0..*	BackboneElement	Provides guide for interpretation　解釈のためのガイドを与える
hasMember	0..*	Reference(JP Core Observation Common Profile \| QuestionnaireResponse \| MolecularSequence)	Related resource that belongs to the Observation group　observationグループに属する関連リソース
derivedFrom	0..*	Reference(DocumentReference \| ImagingStudy \| Media \| QuestionnaireResponse \| JP Core Observation Common Profile \| MolecularSequence)	Related measurements the observation is made from　observation が作られる元の関連する測定
component	0..*	BackboneElement	Component results　　コンポーネント結果
Documentation for this format

Description & Constraints

Observation

C

0..*

Observation

測定や簡単な観察事実（assertion）

id

Σ

0..1

id

Logical id of this artifact

必須要素

次のデータ項目はデータが存在しなければならない（必須）、あるいは、データが送信システムに存在する場合はサポートされなければならない（Must Support）要素である。

必須

このプロファイルでは、次の要素を持たなければならない。

status︓検査項目情報の状態は必須である
code︓このプロファイルは何の検査項目であるかを示すため必須である

MustSupport

このプロファイルではMust Supportの要素は存在しない。

Extension定義

このプロファイルでは拡張定義は行っていない。

利用方法

OperationおよびSearch Parameter 一覧

Search Parameter一覧

ユースケース独自のSearch Parameterが定義されていない場合、以下の表の内容が共通のSearch Parameterとなる。ただし、categoryパラメータおよびcodeパラメータについては、各ユースケース毎に異なる固定値および用語定義で定められたコード体系を指定することになるので注意が必要である。

コンフォーマンス	パラメータ	型	例
SHALL	identifier	token	`GET [base]/Observation?identifier=http://myhospital.com/fhir/observation-id-system\|1234567890`
MAY	patient,category,code,value-quantity	reference,token,token,quantity	`GET [base]/Observation?patient=123&category=vital-signs&code=http://loinc.org\|8867-4&value-quantity=gt40`
MAY	patient,category,code,value-quantity,date	reference,token,token,quantity,date	`GET [base]/Observation?patient=123&category=vital-signs&code=http://loinc.org\|8867-4&value-quantity=gt40&date=le2020-12-31`
MAY	patient,category,code,value-quantity,encounter	reference,token,token,quantity,encounter	`GET [base]/Observation?patient=123&category=vital-signs&code=http://loinc.org\|8867-4&value-quantity=gt40&encounter=456`

操作詳細

必須検索パラメータ

次の検索パラメータは必須でサポートされなければならない。

identifier 検索パラメータを使用して、オーダIDなどの識別子によるObservationの検索をサポートしなければならない（SHALL）
```
GET [base]/Observation?identifier={token}
```
例：
```
GET [base]/Observation?identifier=http://myhospital.com/fhir/observation-id-system|1234567890
```
指定された識別子に一致するObservationリソースを含むBundleを検索する。

推奨検索パラメータ

このプロファイルでは検索の多様性が求められるため、推奨（SHOULD）とする検索項目は定義していない。

オプション検索パラメータ

オプションとして次の検索パラメータをサポートすることができる。(MAY)

1.患者中心での検索：subject（= Patientリソース：対象患者）、category（対象カテゴリ）、code（対象項目）、value[x].valueQuantity（値条件）での検索をサポートすることが望ましい。（MAY）

検査結果値であるエレメント=value[x].valueQuantityの実際のSearch Parameterはvalue-quantityとなる。

patient,category,code,value-quantity の各検索パラメータに一致するObservationリソースを含むBundleを取得することができる。

   GET [base]/Observation?patient={reference}&category={token}&code={token}&value-quantity={quantity}

例：患者123の心拍数が40超えのバイタルサインを取得したい場合

   GET [base]/Observation?patient=123&category=vital-signs&code=http://loinc.org|8867-4&value-quantity=gt40

2.項目中心の検索：subject（= 複数のPatientリソース：母集団としての患者範囲）、category（対象カテゴリ）、code（対象項目）、value[x].valueQuantity（値条件）、effective[x].effectiveDateTime または .effectivePeriod（期間範囲）での検索をサポートすることが望ましい。（MAY）

検査結果値であるエレメント=value[x].valueQuantityの実際のSearch Parameterはvalue-quantityとなり、期間指定についてはエレメントがeffective[x].effectiveDateTime または .effectivePeriod いずれの場合においてもSearch Parameterはdateとなる。

patient,category,code,value-quantity,date の各検索パラメータに一致するObservationリソースを含むBundleを検索する。

   GET [base]/Observation?patient={reference}&category={token}&code={token}&value-quantity={quantity}&date={date}

例：患者123の心拍数が40超えかつ2020年12月31日以前のバイタルサインを取得したい場合

   GET [base]/Observation?patient=123&category=vital-signs&code=http://loinc.org|8867-4&value-quantity=gt40&date=le2020-12-31

3.訪問診療等の検索：subject（= 複数のPatientリソース：母集団としての患者範囲）、category（対象カテゴリ）、code（対象項目）、value[x].valueQuantity（値条件）、encounter（= Encounterリソース：対象医療行為）での検索をサポートすることが望ましい。（MAY）

patient,category,code,value-quantity,date,encounter の各検索パラメータに一致するObservationリソースを含むBundleを検索する。

   GET [base]/Observation?patient={reference}&category={token}&code={token}&value-quantity={quantity}&date={date}&encounter={encounter}

例：患者123の心拍数が40超えかつ2020年12月31日以前で診療456の時のバイタルサインを取得したい場合

   GET [base]/Observation?patient=123&category=vital-signs&code=http://loinc.org|8867-4&value-quantity=gt40&date=le2020-12-31&encounter=456

Operation一覧

コンフォーマンス	オペレーション	説明
MAY	`$lastn`	`$lastn`オペレーションを使用すると、指定したある条件を満たす、最新のn件のObservationリソースを取得することができる。

オプションオペレーション

オプションとして次のオペレーションをサポートすることができる。(MAY)

Observation用 $lastn オペレーション

$lastn オペレーションはある条件に基づく最新、または最新からn件の検査結果/測定結果等を取得するという一般的なニーズを満たすためのオペレーションである。例えば、直近の傾向を見るために、患者の過去5回分の体温を取得したり、最新の検査結果や媒体るサインを取得したりすることができる。検索を行う際は、通常のObservationの検索パラメータと組み合わせて使用される。また、対象となる患者等を限定するための、patientまたはsubjectの検索パラメータ、およびカテゴリを指定するcategory検索パラメータは必須の検索パラメータとなる。

また取得される結果には以下のルールに従う。

追加パラメータによりフィルタされる
取得される結果はObservation.codeの値によるグルーピング処理(Group by)される
新しいデータから古いデータの順にソートされる
グループごとにmaxパラメータに指定された数だけ応答が返る。maxが指定されない場合は、最新の結果のみが返される

この操作の公式なURLは以下である。
https://hl7.org/fhir/R4/operation-observation-lastn.html

入力パラメータ

名前	多重度	型	説明
max	0..1	positiveInt	max は、lastn クエリ操作のオプションの入力パラメータ。これは、各グループから返すObservationの最大数を指定するために使用される。例えば、「ある患者のすべてのバイタルサイン結果から最新の3件を取得する」というクエリの場合、max = 3となる。

出力パラメータ

名前	多重度	型	説明
return	1..1	Bundle	バンドルのタイプは”searchset”である。この操作の結果は、リソースとして直接返される。

サンプル

リクエスト：ある患者のすべてのバイタルから最新の3件を取得する。

GET [base]/Observation/$lastn?max=3&patient=Patient/123&category=vital-signs

レスポンス：各サーバ毎に実装されたLast Nアルゴリズムに従い、患者のすべてのバイタルの中からコードごとに分類し、それぞれについて最新の3件を返す。以下の応答例では、9種のバイタルに対してそれぞれ3件ずつ応答を返しているため、合計27件のObservationのバンドルとなっている。

HTTP/1.1 200 OK
[other headers]

{
  "resourceType": "Bundle",
  "id": "26419249-18b3-45de-b10e-dca0b2e72b",
  "meta": {
    "lastUpdated": "2017-02-18T03:28:49Z"
  },
  "type": "searchset",
  "total": 27,
  // the patient temperature was being taken several times a day
  "entry": [{
    "fullUrl": "http://server/path/Observation/20170219-06temp",
    "resource": {
      "resourceType": "Observation",
      "id": "20170219temp",
      .. 中略 ...
  ,{
   "fullUrl": "http://server/path/Observation/20170219-05temp",
       "resource": {
         "resourceType": "Observation",
         "id": "20170218temp",
      .. 中略 ...
    }
      .. 中略 ...
  ]
}

補足説明

本セクションはObservationリソースを理解する上で重要となるObservation基底仕様の「Note」セクションを抜粋＆翻訳し、転記したものである。なお、本セクションではobservationを”検査”と和訳している点に留意されたい（ただし、リソース名を明確に指す場合のみObservationと表記している）。

検査のプロファイリング

最も単純な場合、リソースインスタンスはコード、値、および状態フラグだけで構成できる。他のプロパティの関連性は、検査の種類によって異なる。プロファイルは、与えられた事例に対する特定の種類の検査を記録する際の指針を提供するために作成される。Observationリソースは、大多数のシステムで記録された詳細さの度合いに焦点を当てている。ただし、特定の事例では、特定の状況に関連する追加の制約と追加の情報がある場合がある。こうした複雑さを追加で取り込めるように、他のリソースと同様、拡張機能が利用できる。

検査の対象

通常、対象（患者もしくは患者グループ、場所、もしくは機器）に対して検査が行われ、その検査のために直接計測されたものと対象との間の区別は、検査コード（例えば、血糖）によって特定され、別々に表現する必要はない。ただし、対象そのものでない場合、検査の焦点を表現するために3つの属性を使用できる。specimen（検体）およびbodySite（検査対応部位）の要素は、対象のサンプルもしくは解剖学的・形態学的な位置の測定値の表現に利用され、患者に埋め込まれた機器や別の検査などの注意点に相当するような対象の特定の観点に焦点を当てて表現している。

検査のグループ分け

多くの検査は、他の検査と重要な関係性を持っているため、グループ化する必要がある。

例えば、構造は以下のように定義される：
検査レポートとDiagnosticReport.result（検査レポート結果）
検査の要素については以下のように定義される：
Observation.component（検査コンポーネント）、 Observation.hasMember（検査保持メンバ）、Observation.derivedFrom（検査派生元）

以下の節では、使用される構造に関しての指針について述べる。何をグループ化するのかという考え方は、しばしば文脈に高く依存しており、エンドユーザの視点にも基づくため、使用する構造の選択は、権限や組織的な訓練、文脈などによって決めるべきである。通常、プロファイリングは実装に必要になるだろう。

DiagnosticReport.result（検査レポート結果）

検査レポートはオーダ（サービス要求）に直接関連している。DiagnosticReport.code（検査レポートコード）はパネルに名前を付け、グループ化要素として機能する。従来、これは臨床検査において”パネル”や”バッテリー”と呼ばれていたものである。DiagnosticReport.result（検査レポート結果）の要素は、個々の検査を参照する。いくつかの例では、検査レポートを使った検査のグループ化をグループ化の構造として示している。

Observation.component（検査コンポーネント）

Observation.component（検査コンポーネント）は、構成するObservationリソースの範囲を超えて、合理的には解釈できないような結果をサポートするために使われる。検査コンポーネントは、個別かつ分けられた検査の一部分から構成されるか、Observation.codeに対して適切な情報を提供する。また、Observation.codeに関して唯一、解釈を与えるものとなる（例えば、$stats操作を参照）。従って、正しく検査の意味を理解するためには、すべての code-value（コード・値）と component.code-component.value（要素コード・要素値）のペアを考慮する必要がある。コンポーネントは、一つの手法、一つの検査、一人の検査実施者、一つの装置、および1回しかない場合のみ使用するべきである。この構造を使用するユースケースには次のようなものがある。：

1.一般的に生成され、一緒に解釈される検査、たとえば収縮期および拡張期の血圧は単一の血圧パネルとして表現
2.一般的に一緒に生成および解釈される評価ツールの結果、たとえば5つの要素を持つ単一の検査である新生児のアプガー指数
3.質問に対する複数の回答の表現（検査と質問/回答の関係と境界）、たとえば患者が飲んだアルコールの種類の報告

一方で、別の検査の構成要素であるという文脈から外れた臨床的に関連する検査は、個別のObservationリソースで表されるべきである。例えば、ボディマス指数（BMI）検査は、身長と体重は臨床的に関連した検査であるから、これらを要素に含むべきではない。個別のObservationリソースとして表現するべきである。どのように独立した検査を関連付けるか、後述するセクションを参照のこと。

Observation.hasMember（検査保持メンバ）および Observation.derivedFrom（検査派生元）

Observation.hasMember（検査保持メンバ）と Observation.derivedFrom（検査派生元）、および中核となる拡張機能であるObservation-sequelTo（検査・続編）と Observation-replaces（検査・置換）は、手法、検査、実施者、機器、時間、エラー状態に対して1つ以上の異なる値を持った結果や、それ自体の使用や解釈した結果をサポートするために利用される。この構造を用いる2つの共通事例は以下の通り:

1.”パネル”や”バッテリー”などに対する検査に関連したグループ分けについて。この事例では、Observation.code（検査コード）は、”パネル”コードを表す。典型的には、Observation.value[x]（検査値）は存在せず、検査メンバのセットがObservation.hasMember（検査保持メンバ）に一覧される。この構造は、検査レポート（例えば、複雑なマイクロ分離と感受性検査報告）と共に利用される場合には、入れ子になったグループ分けを許可する
2.ある検査が派生して他の検査と関連付ける場合、Observation.code（検査コード）と Observation.value[x]（検査値）の両方とも存在し、関連付けられた検査はObservation.derivedFrom（検査派生元）に一覧される。この一例として、身長と体重の計測値が参照されるボディマス指数（BMI）検査がある

検査におけるコード利用

結果の値をコードを用いて事前定義された概念で表現するとき、valueCodeableConceptが使われる。この要素は、LOINCなどの標準的な命名法または元システム（”ローカル”）でコード化された結果値で構成される値セットにバインドされる。

多重コーディング

結果は、異なるコードシステムに基づいて複数の値セットでコーディングでき、概念マップリソースを使用してマッピングしたり、下の例に示すように要素に直接追加のコーディングとして指定したりできる。例えば、検体検査プロファイルでは、”尿酸”に関するローカルコードと標準コードの両方を同時に関連付けることが可能であり、valueCodeableConcept は以下のように表現される：

 "valueCodeableConcept": {
  "coding": [
   {
    "system": "http://abc-hospital.local/fhir/Observation/localcode",
    "code": "05104",
    "display": "尿酸"
   }, {
    "system": "http://jpfhir.jp/Common/ValueSet/labResult-code",
    "code": "3C020000002327101",
    "display": "尿酸(UA)"
   }
  ],
  "text": "検査項目コード"
 }

コーディング結果のためのテキスト値:

データ要素が通常通りコード化される時や、code（コード）要素と関連付けられた型がコードの値を定義する際、適切なコードがなく、フリーテキストのみが利用できる場合であってもvalueCodeableConceptを使用する。例えば、テキストだけ使うと、valueCodeableConcept 要素は以下のようになる：

 "valueCodeableConcept": {
  "text": "コード化不可のフリーテキスト結果"
 }

コード化された回答リストに”その他”の概念コードが含まれ、概念のフリーテキスト記述がある場合、情報源の完全な意味を取り込むため valueCodeableConcept.text要素を使用するべきである。以下の例では、回答コード”その他”は、valueCodeableConcept要素の中で提供され、valueCodeableConcept.text要素の中で提供される値がテキスト値となる。

{
 "resourceType": "Observation",
 ... 中略 ...
 "code": {
  "coding": [
   {
    "system": "http://loinc.org",
    "code": "74076-1",
    "display": "関与する薬物または物質"
   }
  ]
 },
 ... 中略 ...
 "valueCodeableConcept": {
  "coding": [
   {
    "system": "http://loinc.org",
    "code": " LA20343-2",
    "display": "その他の物質: 特定が必要"
   }
  ],
  "text": "その他: ソファの下で見つけた青い錠剤"
 }
 ... 中略 ...
}

FHIRにおけるコード値の組み合わせを用いた相互運用性の課題

多くの検査イベントに対して（特定パターンかどうかに関わらず）繰り返し発生する課題は、Observation.code（検査コード）とObservation.value（検査値）を追加する方法を決める時に起こる。このことは臨床検査においてはごく簡単なことだが、所見や疾患、家族歴などのその他の種類の検査にて曖昧性を生じる。この議論は、そのようなステートメントのコード化された表現が Observation.code（検査コード）および Observation.value（検査値）の要素を使用して表現される方法に焦点を当てている。

FHIRの検査には、中心となる2つの異なる側面がある：

プロパティが検査された所見および/またはプロパティを作成するために実行されたアクション。例：血中ヘモグロビンの測定
検査の結果。例：14 g/dl

Observation.codeとObservation.valueの異なる組み合わせを使用して、同じ情報を表すいくつかの異なる方法が存在する。代替手段の制約のない使用は、意味的等価性の計算と、さまざまなアプリケーションおよびユーザーからの検査に対する安全な解釈が大きな課題である。次の5つのパターンは、同じケースを合理的に表すことができる。 Observationリソースは多くのユースケースをサポートする必要があることを考慮すると、特定のパターンを定義する適切な場所は、FHIRを実装する権限および/または組織によって指定されたプロファイルおよび実装ガイドを通じて行われることが期待される。:

ケース1. Observation.code は、検査の性質を表現しており、Observation.value は数値以外の結果値を表している。これらは、FHIR検査の中心となる2つの異なる側面となっている。
例:
- code=[検査]
- value=[腹部圧痛]
ケース2. Observation.code は上記1.とほぼ同じだが、粒度のレベルは値からコードに移行される。
例:
- code=[腹部検査]
- value=[圧痛]
ケース3. Observation.code は、検査アクションを指定しない方法でも表現されるが、上記の項目のように、単一の名前（または用語）にまとめられた検出結果に関するステートメントを示す。この例では、Observation.value が存在し、通常それを確認または否決する結果を「修飾」する。
例:
- code=[腹部圧痛]
- value=[確認/陽性]
ケース4. この例では Observation.code は、検査アクションを指定しない方法で表現されているが、単一の名前（または用語）にまとめられた検出結果に関するステートメントを示している。この文脈における特定の例では、Observation.valueは省略されている。
例：
- code=[腹部圧痛]
- value要素は省略
ケース5.この例では、Observation.code にて、まず所見の有無（http://terminology.hl7.org/CodeSystem/v2-0532#Y）を指定し、Observation.bodySite.text に当該所見の部位（例えば、下腹部）を指定する。”圧痛”といった詳細な所見は Observation.component.code や Observation.component.valueString に記載する。日本仕様においては本ケースによる記述方法を想定する。
- code=[Yes]
- bodySite.text=[下腹部]
- component.valueString = [圧痛あり]

追加コードや複数の検査による Observation 解釈の精緻化

次のリストは、コードの使用または他の複数の検査によって、検査の解釈が変更される可能性がある追加文脈を付与するためのガイドである。:

1.可能であれば最も専用のコードを使用する。
例：

{
"resourceType": "Observation",
... 中略 ...
"code": {
 "coding": [
  {
   "system": "http://loinc.org",
   "code": "6689-4",
   "display": "血糖値[質量/体積]--食後2時間値"
  }
 ]
},
... 中略 ...
}

2.または上記のようにObservation.code で追加のコードを使用する。
例: Observation.code = coding-1: 59408-5 パルスオキシメータによる動脈血酸素飽和度, coding-2: 20564-1 血中酸素飽和度

{
"resourceType": "Observation",
... 中略 ...
"code": {
 "coding": [
  {
   "system": "http://loinc.org",
   "code": "59408-5",
   "display": "パルスオキシメータによる動脈血酸素飽和度"
  },
  {
   "system": "http://loinc.org",
   "code": "20564-1",
   "display": "血中酸素飽和度"
  }
 ]
},
... 中略 ...
}

3.上記のようにグループ化された複数の検査は検査を正しく理解・解釈するために必要な追加情報を与える、検査をグループ化する代わりに拡張機能を使用することで検査の理解・解釈に必要な他の検査の参照先にできる

（備考：既存の Observation Extensionsを評価するため、実装者コミュニティからの意見を募集中。フィードバックはこちら。）

値とデータ型

Observation.value[x]要素には、次のように型に応じた変数名がある。

valueQuantity（量）
valueCodeableConcept（コーダブルコンセプト値）
valueString（文字列）
valueBoolean（論理値）
valueInteger（整数値）
valueRange（範囲）
valueRatio（比率）
valueSampledData（サンプルデータ値）
valueTime（時刻）
valueDateTime（日時）
valuePeriod（期間）

詳細は結果値のコードの使い方を参照のこと。

ほとんどの検査結果値は「不明」などの例外のために完全な論理値にならないため、論理型はめったに使用されない。従って、代わりにデータ型CodeableConceptを使用し、バリューセットからコードを選択する必要がある（これら「はい/いいえ」の概念は、表示名「true / false」または必要に応じて他の相互に排他的な用語にマッピング可能）。

データ型SampledDataには、特別な値「E」（エラー）、「L」（検出限界未満）、「U」（検出限界超え）が使用できる。しかし、検出限界値超えもしくは未満の範囲の検査でデータ型valueQuantityを使用する場合は、比較基準と共に限界値を指定してvalueQuantityを使用する必要がある。さらにエラーが発生した場合、dataAbsentReason要素に適切な値（「エラー」または「NaN」）を使用する必要がある。たとえば、値が “2.0 mmol/L 未満” の検出下限を下回った場合、valueQuantityは次のようになる:

 "valueQuantity": {
  "value": 2.0,
  "comparator": "<",
  "unit": "mmol/l",
  "system": "http://unitsofmeasure.org",
  "code": "mmol/L"
 }

もし値が「NaN」（エラー）の場合、valueCodeableConcept要素は存在せず。dataAbsentReason要素は次のようになる。

 "dataAbsentReason": {
  "coding": [
   {
    "system": "http://terminology.hl7.org/CodeSystem/data-absent-reason",
    "code": "NaN",
    "display": "数値化不能"
   }
  ]
 }

値要素には複数の型が許可されているため、複数の値検索パラメータが定義されている。ただし、Ratio型の値を検索するための標準パラメータはない。

検査における生理学的に重要な時間

effectiveDateTimeとeffectivePeriodは、検査に密接に関連する時間情報である。生物学的対象（例：人間の患者）の場合、生理学的に検査に関連する時間である。検体の検査の場合、検体収集の開始と終了を表す（24時間尿中ナトリウム等）が、収集時間が十分に短い場合は１点の時刻を指す（例：通常の静脈穿刺）。対象者から直接得た検査の場合（例：血圧、胸部X線）、こちらも多くの場合、検査プロセスの開始時間と終了時間のうち１点の時刻を指す。

参照範囲

最も一般的な検査には普遍的な参照範囲が1個だけ含まれる。参照範囲は、臨床検査や他の収縮期血圧のような検査には有用かもしれないが、「妊娠」のようなものにはほとんど関係ない。システムは患者に関する知識（例：患者固有の年齢・性別・体重・その他要因）に基づいて関連する参照範囲のみに制限できる（MAY）が、それは不可能か不適切な場合がある。複数の参照範囲があるときは常に、参照範囲および/または年齢属性で違いが分かるようにしなければならない（SHOULD）。

キャンセルまたは中止された検査

検査や検査を完了できなかった場合（例えば検体が不十分とか、医療者がオーダをキャンセルしたとか）、ステータスをキャンセルに更新し、具体的な詳細を、できればコード化された値としてdataAbsentReasonかvalueCodeableConcept要素に設定する。note要素にも同様に追加情報が付与される場合がある。検体拒否の例は、”不十分な検体”という意味のコード値をdataAbsentReasonへ設定している。

遺伝情報についての検査

遺伝情報の報告には、DiagnosticReportリソースとObservationリソースを主に使用する。遺伝情報に関する結果の記述についての実装ガイドはこちらを参照されたい。

IG © 2022+ FHIR Japanese implementation research working group in Japan Association of Medical Informatics (JAMI). Package hl7.fhir.jp.core#1.1.1 based on FHIR 4.0.1. Generated 2022-11-02
Links: Table of Contents | QA Report

Id	Grade	Path(s)	Details	Requirements
ele-1	error	ALL elements	All FHIR elements must have a @value or children : hasValue() or (children().count() > id.count())
ext-1	error	ALL extensions	Must have either extensions or value[x], not both : extension.exists() != value.exists()
obs-3	error	Observation.referenceRange	Must have at least a low or a high or text : low.exists() or high.exists() or text.exists()

Id	Grade	Path(s)	Details	Requirements
ele-1	error	ALL elements	All FHIR elements must have a @value or children : hasValue() or (children().count() > id.count())
ext-1	error	ALL extensions	Must have either extensions or value[x], not both : extension.exists() != value.exists()
obs-3	error	Observation.referenceRange	Must have at least a low or a high or text : low.exists() or high.exists() or text.exists()