短く言うと： Condition は、診断、健康上の問題、または懸念されるレベルに達した症状を表す FHIR リソースです。「この患者は2型糖尿病で、活動期、確定、2019年から」といった具合です。このリソースの2つのステータスフィールドが、その有用性を高めています。clinicalStatus は、その病状がどの段階にあるか（活動期、再発、寛解、不活動期、治癒、解決）を示します。verificationStatus は、その確実性を表します（未確定、暫定、鑑別診断、確定、否定、エラー入力）。category は、長期的な問題リスト項目と、1回の受診のために記録された受診診断を区別します。コードは通常 SNOMED CT で、報告のために ICD-10 コードが併記されることがよくあります。
有効な FHIR R4 の例
有効な FHIR R4 の Condition リソースには、subject 参照と、entered-in-error でない限り clinicalStatus が必要です。実際には、verificationStatus、category（problem-list-item または encounter-diagnosis)、コード化された診断、onset も含まれます。以下の例は、SNOMED CT コードと ICD-10 コードを並記した、確認済みの活動中の2型糖尿病を記録しています。
{
"resourceType": "Condition",
"id": "t2dm",
"clinicalStatus": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/condition-clinical", "code": "active"}]},
"verificationStatus": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/condition-ver-status", "code": "confirmed"}]},
"category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/condition-category", "code": "problem-list-item"}]}],
"severity": {"coding": [{"system": "http://snomed.info/sct", "code": "6736007", "display": "Moderate"}]},
"code": {
"coding": [
{"system": "http://snomed.info/sct", "code": "44054006", "display": "Type 2 diabetes mellitus"},
{"system": "http://hl7.org/fhir/sid/icd-10", "code": "E11", "display": "Type 2 diabetes mellitus"}
],
"text": "Type 2 diabetes"
},
"subject": {"reference": "Patient/example"},
"onsetDateTime": "2019-03",
"recordedDate": "2019-03-18",
"recorder": {"reference": "Practitioner/gp-42"},
"asserter": {"reference": "Practitioner/gp-42"},
"note": [{"text": "Diet-controlled at diagnosis; metformin started 2021."}]
}
重要な要素
最も重要な Condition の要素は、clinicalStatus（病状の経過)、verificationStatus（診断の確実性)、category（問題リスト項目または診察診断)、code（通常は SNOMED CT、しばしば ICD-10 と併記)、onset と abatement、recordedDate、そして recorder と asserter（誰が Condition を入力し、誰がそれを主張しているかを示す)です。
- clinicalStatus は、エラー入力でない限り、病状がその経過をたどる際に必要です。
resolvedは終了した病状（治癒した骨折など）に、remissionは再発する可能性のある病状に、inactiveはもはや管理されていない問題に使用されます。これを変更することで、履歴を削除せずに問題リストを正確に保つことができます。 - verificationStatus は確実性を記録します。
provisionalとdifferentialは、検査中の作業診断であり、confirmedは確立された後、refutedは除外された場合に記録され、検討された内容の履歴を保持します。症状レベルのエントリは、しばしばunconfirmedです。 - category: GP が管理する常設リストの場合は
problem-list-item、今回の受診に関する場合はencounter-diagnosisです。同じ病気が両方として現れることがあり、異なる受診に関連付けられます。 - code は CodeableConcept であり、臨床的な意味を持つ SNOMED CT コンセプトと、統計用の ICD-10 コードを並べて持つことができます。CodeableConcept と Coding および SNOMED CT vs ICD-10 を参照してください。
- bodySite、severity、stage（評価参照付き）は病状を修飾し、evidence はそれを支持する Observation やレポートを指します。
- onset[x] および abatement[x] は、患者が正確な日付をほとんど知らないため、日時、年齢、期間、範囲、または文字列（「幼少期」）にすることができます。recordedDate は記録された日時であり、数年後になることもあります。
- recorder は記録した人で、asserter はそれを主張する人で、患者自身であることもあります。
Condition と Observation の違い
FHIR では、Observation は血圧測定値や記録された頭痛など、単一の測定または報告されたデータポイントです。一方、Condition は高血圧や片頭痛など、時間とともに管理される持続的な臨床的解釈です。Observation は証拠を提供し、Condition は臨床医または患者によって主張される患者に関する主張です。
血圧測定は Observation です。高血圧は Condition です。患者が記録した症状（「頭痛、6/10、火曜日から」）は Observation です。頭痛が片頭痛であるという臨床医の判断は Condition です。経験則：Observation はデータポイントであり、Condition は持続し管理される臨床的な解釈です。Anpheros は症状を Observation として記録し、臨床医が診断した、または患者が伝えられた通りに報告した診断に対してのみ Condition を作成します。アプリは症状から Condition を導き出すことはありません。症状としての Observation および 記録としての Condition を参照してください。
受診診断と問題リスト
FHIR では、encounter diagnosis は、ある診察のために Encounter.diagnosis からリンクされた Condition で、admission や discharge diagnosis のような用途とランクを持ちます。一方、problem list は、category problem-list-item と active clinicalStatus を持つ、継続的な Condition のセットです。同じ病気が両方の役割で現れ、異なる診察にリンクされることがあります。
Encounter は、Encounter.diagnosis を通じてその診断にリンクされ、それぞれに use（入院診断、退院診断、主訴、併存疾患、請求）と rank があります。問題リストは、category が problem-list-item で、clinicalStatus が active またはそれに類似する Condition のセットです。これら2つを調整すること（退院診断が新しい問題になったかなど）は、FHIR が記録するが自動化しない臨床作業です。FHIR Encounter の説明 を参照してください。
Condition に含めないもの
FHIR Condition には、患者について誰かが主張する診断、問題、または症状のみを含めるべきです。家族歴は FamilyMemberHistory に、アレルギーは AllergyIntolerance に、リスクとスコアは Observation または RiskAssessment に、完了した処置は Procedure に含めます。臨床医または患者が主張せずにソフトウェアが推測したものは、Condition には一切含めるべきではありません。
- 家族歴（これは FamilyMemberHistory に属します）。
- アレルギー（AllergyIntolerance は独自の重要度と反応モデルを持っています）。
- リスクとスコア（Observation または RiskAssessment）。
- 実施された処置（Procedure）。
- 臨床医または患者が主張せずにソフトウェアが推測したもの。Condition は患者に関する主張であり、
asserterが誰の主張かを示します。
Anpheros では
Anpheros は、API を介したクリニックからの入力、それに遡れる provenance を持つコード化されたドキュメント、または患者が受けたと報告した診断からのみ、Anpheros Platform 上で FHIR Condition リソースを作成します。各 Condition はそのステータスとソースとともに表示され、アプリは単独で Condition を診断したり確認済みとマークしたりすることはありません。
臨床医は、コードとともに同じ Condition を表示します。これにより、レコードはどの FHIR システムでも読み取り可能になります。
関連ページ
- FHIR Encounter の説明
- FHIR における CodeableConcept と Coding
- SNOMED CT vs ICD-10
- FHIR Observation の説明
- FHIR AllergyIntolerance の説明
- 開発者サイトの Condition の例
ソース
- HL7 FHIR R4: Condition
- HL7 Terminology: condition-clinical コードシステム
- HL7 Terminology: condition-ver-status コードシステム
- HL7 US Core: Condition プロファイル
- HL7 IPS: Condition プロファイル
よくある質問
Condition.code に SNOMED CT または ICD-10 のどちらを使用すべきですか？
両方、両方ある場合。SNOMED CT はケアのための臨床的な意味を持ち、ICD-10（またはその国のバリアント）は報告と請求のための分類を持ちます。両方を同じ CodeableConcept の Coding として配置します。プロファイルはどちらが必要かを指定します。
診断が間違っていたことをどのように記録しますか？
検討された後に病状が除外された場合は verificationStatus を refuted に設定し、誤って記録された場合は entered-in-error に設定します。リソースを削除しないでください。履歴は記録の一部です。
症状は Condition と Observation のどちらに配置しますか？
データポイントとして報告されている間（痛みのスコア、期間、トリガー）は Observation として。臨床医または患者が管理すべき問題として主張した場合にのみ、適切な verificationStatus を付けて Condition として。
Condition には診断された日付がありますか？
onset[x] は病状が始まった日時であり、概算の場合があります。recordedDate は記録された日時です。個別の診断日はありません。多くのガイドでは、recordedDate または Encounter 参照をそのために使用しています。
サンドボックスで無料で試す
5分で最初のFHIR呼び出し. 患者さんの同意が組み込まれたHL7 FHIR R4 APIです。サンドボックスでお試しいただき、ご自身のアプリやクリニックのシステムを接続してください。
無料・合成患者30人・カード不要
Anpherosは、患者が管理し、あらゆるクリニックと共有できる医療記録を、EUを拠点とするHL7 FHIR R4プラットフォーム上で構築しています。これらのガイドは、ご自身の健康を理解し整理するのに役立ちますが、医師の代わりになるものではありません。
Anpherosについて →