Zasób FHIR Condition wyjaśniony, z przykładem

Q: Jak zarejestrować, że diagnoza była błędna?

Ustaw verificationStatus na refuted , jeśli stan został wykluczony po rozważeniu, lub entered-in-error , jeśli został zarejestrowany przez pomyłkę. Nie usuwaj zasobu; historia jest częścią zapisu.

Q: Czy Condition ma datę diagnozy?

onset[x] to czas rozpoczęcia stanu, który może być przybliżony; recordedDate to czas wprowadzenia. Nie ma oddzielnej daty diagnozy; wiele przewodników używa recordedDate lub odniesienia do Encounter w tym celu.

Krótka odpowiedź: Condition to zasób FHIR oznaczający diagnozę, problem zdrowotny lub objaw, który stał się przedmiotem troski: ten pacjent ma cukrzycę typu 2, aktywną, potwierdzoną, od 2019 roku. Dwa pola statusu czynią go użytecznym. clinicalStatus określa, na jakim etapie jest stan (aktywny, nawrót, remisja, nieaktywny, wyzdrowienie); verificationStatus mówi, jak pewna jest informacja (niepotwierdzony, tymczasowy, różnicowy, potwierdzony, obalony, wprowadzony w błąd). category rozróżnia długoterminowe pozycje listy problemów od rozpoznań epizodu zarejestrowanych podczas jednej wizyty. Kod jest zazwyczaj SNOMED CT, często z kodem ICD-10 obok dla celów raportowania.

Poprawny przykład FHIR R4

Poprawny zasób FHIR R4 typu Condition wymaga odniesienia do pacjenta (subject reference) oraz, chyba że został wprowadzony błędnie (entered-in-error), statusu klinicznego (clinicalStatus). W praktyce zawiera również status weryfikacji (verificationStatus), kategorię (problem-list-item lub encounter-diagnosis), zakodowaną diagnozę i początek wystąpienia (onset). Poniższy przykład dokumentuje potwierdzoną, aktywną cukrzycę typu 2 z kodem SNOMED CT i kodem ICD-10 obok siebie.

{
  "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."}]
}

Istotne elementy

Najważniejsze elementy zasobu Condition to: status kliniczny (clinicalStatus – określający przebieg schorzenia), status weryfikacji (verificationStatus – jak pewna jest diagnoza), kategoria (category – element listy problemów lub diagnoza epizodu), kod (code – zazwyczaj SNOMED CT, często z kodem ICD-10 obok), początek (onset) i ustąpienie (abatement), data zarejestrowania (recordedDate) oraz osoba rejestrująca (recorder) i potwierdzająca (asserter), które wskazują, kto wprowadził dane o stanie zdrowia i kto za nie odpowiada.

clinicalStatus jest wymagany, gdy stan nie został wprowadzony w błąd, a jego wartości odzwierciedlają przebieg choroby. resolved dotyczy stanów, które się zakończyły (np. zagojony uraz); remission – stanów, które mogą powrócić; inactive – problemu, którym nie jest się już zajmować. Zmiana tego pola pozwala na aktualizację listy problemów bez usuwania historii.
verificationStatus rejestruje pewność. provisional i differential to diagnozy robocze podczas diagnostyki; confirmed – po ustaleniu; refuted – gdy zostało wykluczone, co zachowuje zapis tego, co było brane pod uwagę. Wpis objawu jest często unconfirmed.
category: problem-list-item dla stałej listy prowadzonej przez lekarza rodzinnego; encounter-diagnosis – dla tego, czego dotyczyła dana wizyta. Ta sama choroba może pojawić się w obu kategoriach, powiązana z różnymi epizodami.
code to CodeableConcept, dzięki czemu może zawierać kod SNOMED CT dla znaczenia klinicznego i kod ICD-10 dla statystyk obok siebie. Zobacz CodeableConcept i Coding oraz SNOMED CT vs ICD-10.
bodySite, severity i stage (z odniesieniami do oceny) kwalifikują stan; evidence wskazuje na Obserwacje lub raporty, które go potwierdzają.
onset[x] i abatement[x] mogą być datą/czasem, wiekiem, okresem, zakresem lub tekstem ("dzieciństwo"), ponieważ pacjenci rzadko znają dokładne daty. recordedDate to data wprowadzenia do rejestru, która może nastąpić wiele lat później.
recorder wprowadził dane; asserter to osoba, która je zgłasza, może to być sam pacjent.

Condition a Observation

W FHIR, Observation to pojedynczy punkt danych zmierzony lub zgłoszony, taki jak odczyt ciśnienia krwi lub zarejestrowany ból głowy. Natomiast Condition to utrwalona interpretacja kliniczna, która jest zarządzana w czasie, na przykład nadciśnienie tętnicze lub migrena. Obserwacje (Observations) dostarczają dowodów; Condition to stwierdzenie dotyczące pacjenta, zgłoszone przez lekarza lub pacjenta.

Odczyt ciśnienia krwi to Observation. Nadciśnienie to Condition. Objaw zgłoszony przez pacjenta ("ból głowy, 6/10, od wtorku") to Observation; ocena klinicysty, że bóle głowy to migrena, to Condition. Zasada: Obserwacje to punkty danych; Stany to interpretacja kliniczna, która trwa i jest zarządzana. Anpheros rejestruje objawy jako Obserwacje i tworzy Stan tylko dla diagnozy postawionej przez lekarza lub zgłoszonej przez pacjenta zgodnie z zaleceniami; aplikacja nie stawia diagnoz i sama nie ustawia verificationStatus na confirmed. Zobacz Objawy jako Obserwacje i Stany jako zapisy.

Rozpoznania epizodu i lista problemów

W FHIR, diagnoza epizodu (encounter diagnosis) to Condition powiązane z Encounter.diagnosis dla jednej wizyty, z zastosowaniem takim jak diagnoza przy przyjęciu lub wypisie i rangą. Lista problemów (problem list) to stały zbiór Stanów zdrowia (Conditions) z kategorią problem-list-item i aktywnym statusem klinicznym (clinicalStatus). Ta sama choroba może pojawić się w obu rolach, powiązana z różnymi epizodami.

Encounter wskazuje na swoje diagnozy poprzez Encounter.diagnosis, każda z use (diagnoza przyjęcia, diagnoza wypisu, główna dolegliwość, choroba współistniejąca, rozliczenie) i rank. Lista problemów to zbiór Stanów z kategorią problem-list-item i clinicalStatus aktywny lub podobny. Pogodzenie tych dwóch (czy diagnoza wypisu stała się nowym problemem?) to praca kliniczna, którą FHIR rejestruje, ale nie automatyzuje. Zobacz Wyjaśnienie FHIR Encounter.

Czego nie umieszczać w Condition

FHIR Condition powinien zawierać tylko diagnozę, problem lub objaw, który ktoś zgłasza w odniesieniu do pacjenta. Wywiad rodzinny należy umieścić w FamilyMemberHistory, alergie w AllergyIntolerance, ryzyka i oceny w Observation lub RiskAssessment, a zakończone procedury w Procedure. Nic, co zostało wywnioskowane przez oprogramowanie bez potwierdzenia przez lekarza lub pacjenta, nie powinno znajdować się w Condition.

Wywiad rodzinny (należy do FamilyMemberHistory).
Alergie (AllergyIntolerance ma własny model krytyczności i reakcji).
Ryzyka i wyniki (Observation lub RiskAssessment).
Wykonane procedury (Procedure).
Cokolwiek, co zostało wywnioskowane przez oprogramowanie bez potwierdzenia przez lekarza lub pacjenta; Stan to twierdzenie dotyczące pacjenta, a asserter wskazuje, czyje.

W Anpheros

Anpheros tworzy zasoby FHIR Condition na platformie Anpheros wyłącznie na podstawie wpisów klinicznych przez API, z zakodowanego dokumentu z informacją o jego pochodzeniu, lub na podstawie diagnozy zgłoszonej przez pacjenta. Każdy Condition jest prezentowany wraz ze swoim statusem i źródłem, a aplikacja nigdy samodzielnie nie stawia diagnoz ani nie oznacza Condition jako potwierdzonego.

Lekarze widzą ten sam Condition wraz z jego kodami, co sprawia, że dane są czytelne dla każdego systemu zgodnego ze standardem FHIR.

Powiązane strony

Źródła

Najczęstsze pytania

Czy powinienem używać SNOMED CT czy ICD-10 w Condition.code?

Oba, gdy masz oba. SNOMED CT niesie znaczenie kliniczne dla opieki; ICD-10 (lub jego krajowy wariant) niesie klasyfikację do raportowania i rozliczeń. Umieść każdy jako Coding w tym samym CodeableConcept; profile określają, który jest wymagany.

Jak zarejestrować, że diagnoza była błędna?

Ustaw verificationStatus na refuted, jeśli stan został wykluczony po rozważeniu, lub entered-in-error, jeśli został zarejestrowany przez pomyłkę. Nie usuwaj zasobu; historia jest częścią zapisu.

Gdzie trafia objaw, do Condition czy Observation?

Jako Observation, gdy jest to zgłoszony punkt danych (wynik bólu, czas trwania, wyzwalacz). Jako Condition tylko wtedy, gdy lekarz lub pacjent zgłosi go jako problem do zarządzania, z odpowiednim verificationStatus.

Czy Condition ma datę diagnozy?

onset[x] to czas rozpoczęcia stanu, który może być przybliżony; recordedDate to czas wprowadzenia. Nie ma oddzielnej daty diagnozy; wiele przewodników używa recordedDate lub odniesienia do Encounter w tym celu.

Anpheros Platform

Wypróbuj za darmo w sandboksie

Pierwsze wywołanie FHIR w 5 minut. API HL7 FHIR R4 z wbudowaną zgodą pacjenta: wypróbuj w piaskownicy, a następnie połącz własną aplikację lub system kliniczny.

Utwórz darmowy sandbox Przeczytaj przewodniki dla programistów →

Za darmo · 30 syntetycznych pacjentów · bez karty

Ten poradnik ma charakter informacyjny i nie zastępuje konsultacji lekarskiej. Decyzje dotyczące zdrowia podejmuj z lekarzem. W nagłym wypadku zadzwoń pod lokalny numer alarmowy (112 w Europie).

Napisane przez

Zespół Anpheros

Anpheros tworzy dokumentację medyczną, nad którą pacjent ma kontrolę i którą może udostępniać dowolnej klinice, na platformie HL7 FHIR R4, z siedzibą w UE. Te przewodniki pomogą Ci zrozumieć i uporządkować informacje o Twoim zdrowiu; nie zastępują one wizyty u lekarza.

O Anpheros →