Kurze Antwort: Condition ist die FHIR-Ressource für eine Diagnose, ein Gesundheitsproblem oder ein Symptom, das Anlass zur Sorge gibt: dieser Patient hat Typ-2-Diabetes, aktiv, bestätigt, seit 2019. Ihre beiden Statusfelder machen sie nützlich. clinicalStatus gibt an, wo sich die Erkrankung in ihrem Verlauf befindet (aktiv, Rezidiv, Rückfall, inaktiv, Remission, geheilt); verificationStatus gibt an, wie sicher jemand ist (unbestätigt, vorläufig, differential, bestätigt, widerlegt, fehlerhaft eingegeben). category trennt langfristige Problem-List-Einträge von Encounter-Diagnosen, die für einen Besuch erfasst wurden. Der Code ist normalerweise SNOMED CT, oft mit einem ICD-10-Code daneben für die Berichterstattung.
Ein gültiges FHIR R4 Beispiel
Eine gültige FHIR R4 Condition-Ressource benötigt eine Referenz auf das Subjekt und, sofern sie nicht als ungültig markiert ist, einen klinischen Status. In der Praxis enthält sie auch den Verifizierungsstatus, eine Kategorie (Problem-Listen-Eintrag oder Behandlungsdiagnose), eine kodierte Diagnose und den Beginn. Das folgende Beispiel erfasst bestätigten, aktiven Typ-2-Diabetes mit einem SNOMED CT-Code und einem ICD-10-Code nebeneinander.
{
"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."}]
}
Die wichtigen Elemente
Die wichtigsten Elemente einer Condition sind der klinische Status (wie weit die Erkrankung fortgeschritten ist), der Verifizierungsstatus (wie sicher die Diagnose ist), die Kategorie (Problem-Listen-Eintrag oder Behandlungsdiagnose), der Code (normalerweise SNOMED CT, oft mit ICD-10 daneben), Beginn und Ende, das Aufnahmedatum sowie der Erfasser und der Bestätigende, die angeben, wer die Condition eingetragen hat und wer sie beansprucht.
- clinicalStatus ist erforderlich, wenn die Erkrankung nicht fehlerhaft eingegeben wurde, und seine Werte folgen dem Krankheitsverlauf.
resolvedist für Erkrankungen, die beendet sind (ein Heilungsprozess einer Fraktur);remissionfür solche, die wieder auftreten können;inactivefür ein Problem, das nicht mehr behandelt wird. Die Änderung dieses Feldes ist der Weg, wie eine Problem-Liste die Wahrheit ohne Löschen der Historie beibehält. - verificationStatus erfasst die Sicherheit.
provisionalunddifferentialsind Arbeitsdiagnosen während einer Untersuchung;confirmedsobald etabliert;refuted, wenn ausgeschlossen, was die Aufzeichnung dessen, was in Betracht gezogen wurde, beibehält. Ein Eintrag auf Symptomebene ist oftunconfirmed. - category:
problem-list-itemfür die stehende Liste, die ein Hausarzt führt;encounter-diagnosisfür das, worum es bei diesem Besuch ging. Dieselbe Krankheit kann als beides erscheinen, verknüpft mit verschiedenen Besuchen. - code ist ein CodeableConcept, sodass es ein SNOMED CT-Konzept für die klinische Bedeutung und einen ICD-10-Code für Statistiken nebeneinander tragen kann. Siehe CodeableConcept und Coding und SNOMED CT vs ICD-10.
- bodySite, severity und stage (mit Verweisen auf Bewertungen) qualifizieren die Erkrankung; evidence verweist auf die Beobachtungen oder Berichte, die sie unterstützen.
- onset[x] und abatement[x] können ein Datum/Uhrzeit, ein Alter, eine Periode, ein Bereich oder ein Text ("Kindheit") sein, da Patienten selten genaue Daten kennen. recordedDate ist, wann es in die Aufzeichnung aufgenommen wurde, was Jahre später sein kann.
- recorder hat es eingegeben; asserter ist, wer es beansprucht, was der Patient selbst sein kann.
Condition vs Observation
In FHIR ist eine Observation ein einzelner gemessener oder berichteter Datenpunkt, wie z. B. ein Blutdruckwert oder ein eingetragener Kopfschmerz, während eine Condition die fortbestehende klinische Interpretation ist, die über die Zeit verwaltet wird, wie z. B. Bluthochdruck oder Migräne. Observations liefern Beweise; eine Condition ist eine Behauptung über den Patienten, die von einem Kliniker oder dem Patienten aufgestellt wird.
Ein Blutdruckmesswert ist eine Observation. Hypertonie ist eine Condition. Ein vom Patienten protokolliertes Symptom ("Kopfschmerzen, 6/10, seit Dienstag") ist eine Observation; die Einschätzung eines Klinikers, dass die Kopfschmerzen Migräne sind, ist eine Condition. Faustregel: Observations sind Datenpunkte; Conditions sind die klinische Interpretation, die bestehen bleibt und behandelt wird. Anpheros zeichnet Symptome als Observations auf und erstellt nur eine Condition für eine Diagnose, die ein Kliniker gestellt hat oder die Person ihm gegenüber berichtet hat; die App leitet niemals eine Condition von Symptomen ab. Siehe Symptome als Observations und Conditions als Aufzeichnungen.
Encounter-Diagnosen und die Problem-Liste
In FHIR ist eine Encounter-Diagnose eine Condition, die von Encounter.diagnosis für einen Besuch verknüpft ist, mit einer Verwendung wie Aufnahme- oder Entlassungsdiagnose und einem Rang. Die Problem-Liste ist die stehende Sammlung von Conditions mit der Kategorie problem-list-item und einem aktiven klinischen Status. Dieselbe Krankheit kann in beiden Rollen auftreten und mit verschiedenen Behandlungen verknüpft sein.
Ein Encounter verweist über Encounter.diagnosis auf seine Diagnosen, jede mit einem use (Aufnahmediagnose, Entlassungsdiagnose, Hauptbeschwerde, Komorbidität, Abrechnung) und einem rank. Die Problem-Liste ist die Menge der Conditions mit der Kategorie problem-list-item und einem clinicalStatus von aktiv oder ähnlich. Die Abstimmung der beiden (wurde die Entlassungsdiagnose zu einem neuen Problem?) ist klinische Arbeit, die FHIR aufzeichnet, aber nicht automatisiert. Siehe FHIR Encounter erklärt.
Was nicht in eine Condition gehört
Eine FHIR Condition sollte nur eine Diagnose, ein Problem oder ein Symptom enthalten, das jemand über den Patienten behauptet. Die Familiengeschichte gehört in FamilyMemberHistory, Allergien in AllergyIntolerance, Risiken und Punktzahlen in Observation oder RiskAssessment und abgeschlossene Prozeduren in Procedure. Alles, was eine Software ohne Bestätigung durch einen Kliniker oder den Patienten ableitet, gehört überhaupt nicht in eine Condition.
- Familiengeschichte (das gehört in FamilyMemberHistory).
- Allergien (AllergyIntolerance hat ein eigenes Kriterienmodell für Kritikalität und Reaktionen).
- Risiken und Scores (Observation oder RiskAssessment).
- Durchgeführte Prozeduren (Procedure).
- Alles, was die Software ohne einen Kliniker oder den Patienten abgeleitet hat; eine Condition ist eine Behauptung über den Patienten, und
assertergibt an, wessen Behauptung es ist.
In Anpheros
Anpheros erstellt FHIR Condition-Ressourcen auf der Anpheros Platform nur aus einer Klinik, die über die API schreibt, aus einem kodierten Dokument mit Herkunftsnachweis, der darauf zurückverweist, oder aus einer Diagnose, die eine Person selbst berichtet. Jede Condition wird mit ihrem Status und ihrer Quelle angezeigt, und die App stellt niemals selbst Diagnosen oder markiert eine Condition als bestätigt.
Kliniker sehen dieselbe Condition mit ihren Codes, was den Datensatz für jedes FHIR-System lesbar macht.
Verwandte Seiten
- FHIR Encounter erklärt
- CodeableConcept und Coding in FHIR
- SNOMED CT vs ICD-10
- FHIR Observation erklärt
- FHIR AllergyIntolerance erklärt
- Condition-Beispiel auf der Entwicklerseite
Quellen
- HL7 FHIR R4: Condition
- HL7 Terminology: condition-clinical code system
- HL7 Terminology: condition-ver-status code system
- HL7 US Core: Condition profiles
- HL7 IPS: Condition profile
Häufige Fragen
Sollte ich SNOMED CT oder ICD-10 in Condition.code verwenden?
Beides, wenn Sie beides haben. SNOMED CT trägt die klinische Bedeutung für die Versorgung; ICD-10 (oder seine nationale Variante) trägt die Klassifizierung für Berichterstattung und Abrechnung. Geben Sie jeden als Coding in dasselbe CodeableConcept ein; Profile geben an, welches davon erforderlich ist.
Wie erfasse ich, dass eine Diagnose falsch war?
Setzen Sie verificationStatus auf refuted, wenn die Erkrankung nach Erwägung ausgeschlossen wurde, oder entered-in-error, wenn sie versehentlich aufgezeichnet wurde. Löschen Sie die Ressource nicht; die Historie ist Teil der Aufzeichnung.
Wo gehört ein Symptom hin, Condition oder Observation?
Als Observation, solange es sich um einen berichteten Datenpunkt handelt (Schmerzskala, Dauer, Auslöser). Als Condition nur, wenn ein Kliniker oder der Patient es als zu behandelndes Problem beansprucht, mit dem entsprechenden verificationStatus.
Hat Condition ein Datum, an dem es diagnostiziert wurde?
onset[x] ist, wann die Erkrankung begann, was annähernd sein kann; recordedDate ist, wann sie eingegeben wurde. Es gibt kein separates Diagnosedatum; viele Anleitungen verwenden recordedDate oder eine Encounter-Referenz dafür.
Kostenlos in der Sandbox testen
Ihr erster FHIR-Aufruf in 5 Minuten. Eine HL7 FHIR R4 API mit der Zustimmung des Patienten: probieren Sie sie in der Sandbox aus und verbinden Sie dann Ihre eigene App oder Ihr Kliniksystem.
Kostenlos · 30 synthetische Patienten · keine Karte
Anpheros entwickelt eine Patientenakte, die der Patient kontrolliert und mit jeder Klinik teilen kann, auf einer HL7 FHIR R4-Plattform mit Sitz in der EU. Diese Anleitungen helfen Ihnen, Ihre Gesundheit zu verstehen und zu organisieren; sie ersetzen nicht Ihren Arzt.
Über Anpheros →