Ресурс FHIR Condition: пояснення та приклад

Q: Як записати, що діагноз був неправильним?

Встановіть verificationStatus на refuted , якщо стан був виключений після розгляду, або entered-in-error , якщо він був записаний помилково. Не видаляйте ресурс; історія є частиною запису.

Коротка відповідь: Condition — це ресурс FHIR для діагнозу, проблеми зі здоров'ям або симптому, який викликає занепокоєння: у цього пацієнта цукровий діабет 2 типу, активний, підтверджений, з 2019 року. Його два поля статусу роблять його корисним. clinicalStatus вказує на стадію перебігу стану (активний, рецидив, загострення, неактивний, ремісія, вирішений); verificationStatus вказує на ступінь впевненості (непідтверджений, попередній, диференційний, підтверджений, спростований, помилково введений). category розділяє довготривалі елементи списку проблем від діагнозів при зверненні, записаних для одного візиту. Код зазвичай є SNOMED CT, часто з кодом ICD-10 поруч для звітності.

Валідний приклад FHIR R4

Валідний ресурс FHIR R4 Condition потребує посилання на суб'єкт (subject) і, якщо він не позначений як помилковий (entered-in-error), клінічний статус (clinicalStatus). На практиці він також містить статус верифікації (verificationStatus), категорію (problem-list-item або encounter-diagnosis), кодований діагноз та дату початку (onset). Наведений нижче приклад записує підтверджений, активний цукровий діабет 2 типу з кодом SNOMED CT та кодом ICD-10 поруч.

{
  "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), які вказують, хто вніс інформацію про стан і хто її підтверджує.

clinicalStatus є обов'язковим, якщо стан не був помилково введений, і його значення відображають перебіг хвороби. resolved використовується для станів, які закінчилися (загоєний перелом); remission — для тих, що можуть повернутися; inactive — для проблеми, яка більше не лікується. Зміна цього поля дозволяє списку проблем залишатися актуальним без видалення історії.
verificationStatus записує ступінь впевненості. provisional і differential — це робочі діагнози під час обстеження; confirmed — після встановлення; refuted — коли його виключили, що зберігає запис про те, що розглядалося. Запис на рівні симптому часто має статус unconfirmed.
category: problem-list-item для постійного списку, який веде сімейний лікар; encounter-diagnosis — для того, що було причиною цього візиту. Одна й та сама хвороба може з'являтися в обох категоріях, пов'язана з різними зверненнями.
code — це CodeableConcept, тому він може містити концепт SNOMED CT для клінічного значення та код ICD-10 для статистики поруч. Див. CodeableConcept та Coding та SNOMED CT проти ICD-10.
bodySite, severity та stage (з посиланнями на оцінки) кваліфікують стан; evidence вказує на Спостереження або звіти, які його підтверджують.
onset[x] та abatement[x] можуть бути датою/часом, віком, періодом, діапазоном або рядком ("дитинство"), оскільки пацієнти рідко знають точні дати. recordedDate — це дата, коли стан був внесений до запису, що може бути через роки.
recorder — хто вніс запис; asserter — хто стверджує стан, це може бути сам пацієнт.

Condition проти Observation

У FHIR, Observation – це окрема виміряна або зареєстрована точка даних, наприклад, показник артеріального тиску або зафі lidований головний біль. Condition – це стійка клінічна інтерпретація, яка керується протягом часу, наприклад, гіпертонія або мігрень. Observations надають докази; Condition – це твердження про пацієнта, зроблене клініцистом або самим пацієнтом.

Вимірювання артеріального тиску — це Observation. Гіпертонія — це Condition. Симптом, який пацієнт записує ("головний біль, 6/10, з вівторка"), — це Observation; судження лікаря про те, що головні болі є мігренню, — це Condition. Загальне правило: Observations — це точки даних; Conditions — це клінічна інтерпретація, яка зберігається і лікується. Anpheros записує симптоми як Observations і створює Condition лише для діагнозу, встановленого лікарем, або для діагнозу, про який повідомила особа за вказівкою. Додаток ніколи не виводить Condition із симптомів. Див. Симптоми як Observations та Conditions як записи.

Діагнози при зверненні та список проблем

У FHIR, діагноз при зверненні (encounter diagnosis) – це Condition, пов'язаний з Encounter.diagnosis для одного візиту, з використанням, таким як діагноз при госпіталізації або виписці, та рангом. Список проблем (problem list) – це постійний набір Conditions з категорією problem-list-item та активним клінічним статусом (active clinicalStatus). Одне й те саме захворювання може з'являтися в обох ролях, пов'язане з різними зверненнями.

Encounter посилається на свої діагнози через Encounter.diagnosis, кожен з яких має use (діагноз при госпіталізації, діагноз при виписці, основна скарга, супутнє захворювання, виставлення рахунку) та rank. Список проблем — це сукупність Conditions з категорією problem-list-item та clinicalStatus активний або подібний. Узгодження цих двох (чи став діагноз при виписці новою проблемою?) — це клінічна робота, яку FHIR записує, але не автоматизує. Див. Пояснення FHIR Encounter.

Чого не слід вносити до Condition

FHIR Condition повинен містити лише діагноз, проблему або симптом, які хтось стверджує щодо пацієнта. Сімейний анамнез належить до FamilyMemberHistory, алергії – до AllergyIntolerance, ризики та оцінки – до Observation або RiskAssessment, а завершені процедури – до Procedure. Будь-що, виведене програмним забезпеченням без підтвердження клініцистом або пацієнтом, взагалі не повинно міститися в Condition.

Сімейний анамнез (це належить до FamilyMemberHistory).
Алергії (AllergyIntolerance має власну модель критичності та реакції).
Ризики та оцінки (Observation або RiskAssessment).
Проведені процедури (Procedure).
Будь-що, що було виведено програмним забезпеченням без підтвердження лікарем або пацієнтом; Condition — це твердження про пацієнта, а asserter вказує, чиє воно.

В Anpheros

Anpheros створює ресурси FHIR Condition на платформі Anpheros Platform лише на основі запису з клініки через API, з кодованого документа з вказаним джерелом, або на основі діагнозу, який людина повідомляє, що їй було поставлено. Кожен Condition відображається зі своїм статусом та джерелом, і додаток ніколи самостійно не ставить діагнози та не позначає Condition як підтверджений.

Клініцисти бачать той самий Condition з його кодами, що робить запис читабельним для будь-якої системи FHIR.

Пов'язані сторінки

Джерела

Поширені запитання

Чи слід використовувати SNOMED CT або ICD-10 у Condition.code?

Обидва, якщо вони у вас є. SNOMED CT несе клінічне значення для догляду; ICD-10 (або його національний варіант) несе класифікацію для звітності та виставлення рахунків. Внесіть кожен як Coding у той самий CodeableConcept; профілі вказують, який з них є обов'язковим.

Як записати, що діагноз був неправильним?

Встановіть verificationStatus на refuted, якщо стан був виключений після розгляду, або entered-in-error, якщо він був записаний помилково. Не видаляйте ресурс; історія є частиною запису.

Де розміщується симптом: Condition чи Observation?

Як Observation, поки це звітна точка даних (оцінка болю, тривалість, тригер). Як Condition лише тоді, коли лікар або пацієнт стверджує його як проблему, яку потрібно лікувати, з відповідним verificationStatus.

Чи має Condition дату діагностики?

onset[x] — це час початку стану, який може бути приблизним; recordedDate — це час його внесення. Окремої дати діагностики немає; багато посібників використовують recordedDate або посилання на Encounter для цього.

Anpheros Platform

Спробуйте безкоштовно в пісочниці

Перший запит FHIR за 5 хвилин. API стандарту HL7 FHIR R4 з вбудованою згодою пацієнта: спробуйте в пісочниці, а потім підключіть власну програму чи клінічну систему.

Створити безкоштовну пісочницю Читати посібники для розробників →

Безкоштовно · 30 синтетичних пацієнтів · без картки

Цей посібник призначений для інформаційних цілей і не замінює медичну консультацію. Для прийняття рішень щодо вашого здоров'я зверніться до лікаря. У надзвичайній ситуації телефонуйте на місцевий номер екстреної допомоги (112 у Європі).

Написано

Команда Anpheros

Anpheros створює медичну карту, яку пацієнт контролює та може ділитися з будь-якою клінікою, на платформі HL7 FHIR R4, розташованій в ЄС. Ці посібники допоможуть вам зрозуміти та організувати своє здоров'я; вони не замінюють вашого лікаря.

Про Anpheros →