FHIR R4 ресурс для клинической оценки — record of a clinician’s view of a patient’s situation. Содержит structured findings (что обнаружено) + prose summary + recommended actions. Используется для assessments которые AI/врач делает поверх лаб-данных, не для самих измерений. По смыслу — процесс клинического суждения, не data points’ы.

В BloodGPT рассматривается как контейнер для per-параметрного AI clinical assessment’а (prose-резюме + evidence + рекомендованные доисследования + триаж приоритета) — более подробное описание самого этого подхода и его эволюции живёт отдельно (TBD page name + scope). Какой именно FHIR-формат используется — open, см. staged-output-fhir-storage.

Поля ресурса (FHIR R4 spec)

Полная спецификация. Ключевые слоты:

  • summary — текстовое резюме investigations и диагноза. Свободная prose-форма.
  • investigation[].item[] — input для assessment’а: данные собранные в процессе или ранее зафиксированные, релевантные выводам. Это input — на что мы смотрели. References на Observation | DiagnosticReport | QuestionnaireResponse | FamilyMemberHistory | RiskAssessment | ImagingStudy | Media (closed list).
  • finding[]output assessment: диагнозы и выводы которые посчитали likely / релевантными. Может включать ruled-out (исключённые) состояния. References на Condition | Observation либо itemCodeableConcept. Не «рекомендованные тесты» — те идут в отдельный fhir-service-request.

Поток данных через CI

                              ┌──────────────────────┐
                              │  ClinicalImpression  │
        INPUT  ─────────►     │                      │     ─────────►  OUTPUT
                              │   focus  → объект    │
  investigation.item[]   ◄──  │   summary: prose     │  ──►   finding[]
   • Observation             │   note[]: comments    │       • Condition refs
   • DiagnosticReport        │                       │       • Observation refs
   • QuestionnaireResponse   │                       │       • itemCodeableConcept
   • FamilyMemberHistory     │                       │
   • RiskAssessment          │                       │  ──►   prognosisReference
   • ImagingStudy            │                       │       → RiskAssessment
   • Media                    │                       │
                              │                       │
  problem[]            ◄────  │   patient background │
   • Condition                │                       │     ──►  parallel resource:
   • AllergyIntolerance       │                       │           ServiceRequest
                              │                       │           (intent: proposal)
  supportingInfo[]     ◄────  │   free context       │            ← рекомендованные
   • Reference(Any)           │                       │              доисследования
                              └──────────────────────┘

investigation.item[] (что посмотрели) → assessment-процесс → finding[] (что вывели). summary — prose-резюме того же assessment’а параллельно с structured finding[]. Рекомендованные тесты — не часть CI, отдельный ServiceRequest.

  • problem[] — список существующих проблем / состояний пациента. References на Condition | AllergyIntolerance. Это бэкграунд пациента (то что было до assessment’а), не то что мы упустили.
  • supportingInfo[] — любые ресурсы, поддерживающие assessment. Reference(Any) — type-permissive свободный слот.
  • prognosisCodeableConcept / prognosisReference[] — оценка вероятного исхода. Reference может идти на fhir-risk-assessment.
  • note[] — комментарии, обычно записанные после самого impression-а. Annotation data type (fhir-annotation).
  • focus — central object on which the impression focuses. Reference(Any).
  • assessor — человек ответственный за impression. Reference(Practitioner | PractitionerRole) — closed list, не Organization, не Device.
  • statusin-progress | completed | entered-in-error.
  • effectiveDateTime / effectivePeriod — момент assessment’а (не момент тестирования — тот живёт на Observation).

investigation.item[] vs finding[]

Оба могут ссылаться на Observation, но семантика разная:

  • investigation.item[] = input для assessment — какие исходные данные посмотрели чтобы прийти к выводу.
  • finding[] = output assessment — что считаем likely / relevant как diagnostic conclusion. В FHIR-смысле здесь живут «вероятно железодефицитная анемия», «исключить гипотиреоз». Структурный список диагностических гипотез как кодов / ссылок на Conditions, параллельный prose-резюме в summary.

finding[] и summary — два слоя одного assessment’а: prose-резюме + structured кодированные diagnoses. По spec оба заполняются для полной картины.

Boundary: scoring tools → Observation, не CI

Spec явно выносит структурированные scoring tools (Apgar и подобные) за пределы ClinicalImpression:

“There is another related clinical concept often called an ‘assessment’: assessment Tools such as Apgar (also known as ‘Assessment Scales’). This is not what the ClinicalImpression resource is about; assessment tools such as Apgar are represented as Observations, and Questionnaires may be used to help generate these.”

“This resource is called ‘ClinicalImpression’ rather than ‘ClinicalAssessment’ to avoid confusion with the recording of assessment tools such as Apgar score.”

FHIR R4 ClinicalImpression spec, Scope and Usage

Граница: детерминированный score (вход → таблица → результат) = Observation с LOINC-кодом для шкалы. Клинический синтез поверх данных (“параметр повышен, скорее всего из-за X, стоит проверить Y”) = ClinicalImpression. Spec прямо говорит что CI — это SOAP “A” (Assessment как процесс), а scoring tools — это data points, которые в этот процесс входят, не являются им.

Связанная граница — prediction vs assessment: predicted outcomes (10-year risk scores с probability) → fhir-risk-assessment. CI ссылается на RA через prognosisReference[]. Чисто-assessment контент в RA не кладут.

Связь с DiagnosticReport

В spec нет dedicated поля связи DR ↔ CI. DR может быть в investigation.item[] как одно из «исследований» которые посмотрели. Связь идёт транзитивно через Observation: CI ссылается на биомаркер через focus → Observation, DR ссылается на тот же Observation через result[]. Прямой ссылки между DR и CI в R4 spec нет — кому нужна, делает custom extension.

При множественных CI per тест (per-parameter дизайн) DR может работать test-level aggregator: conclusion хранит общий summary, conclusionCode[] — union triage / max severity по всем CIs. Это позволяет UI/API быстро получить test-level signal без обхода всех CIs.

Gotchas / ограничения

  • assessor: только Practitioner | PractitionerRole — не Organization, не Device. Блокер для AI-author через assessor. Workaround: note[].authorReference: Organization/bloodgpt, или audit через Provenance.agent.who. См. authorship-organization-not-device.
  • Trial Use status в FHIR R4 — ClinicalImpression менее стабильный чем DiagnosticReport. В R5 структура может измениться.
  • Без published Profile + binding=required — валидаторы не проверяют custom extensions; согласованность структуры — на pipeline-сторону.
  • Closed list на investigation.item[] — принимает Observation/DR/QR/FamilyMemberHistory/RiskAssessment/ImagingStudy/Media. Не принимает Condition или Medication. Если evidence имеет смешанные типы, нужно spread по другим slots или extension. См. foundcontext-fhir-mapping.

Связано

Источники

Источники: 1.

Сноски

  1. FHIR R4 ClinicalImpression, accessed 2026-05-17, https://hl7.org/fhir/R4/clinicalimpression.html.