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-а.Annotationdata type (fhir-annotation).focus— central object on which the impression focuses.Reference(Any).assessor— человек ответственный за impression.Reference(Practitioner | PractitionerRole)— closed list, не Organization, не Device.status—in-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.”
Граница: детерминированный 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.
Связано
- staged-output-fhir-storage — наш выбор как использовать CI для V2.5 (host resource / гранулярность / distribution полей)
- foundcontext-fhir-mapping — sub-вопрос про конкретный slot для evidence items с mixed types
- zero-extensions-fhir — общая стратегия: минимум custom extensions
- authorship-organization-not-device —
Organization/bloodgptкак author (обходитassessorPractitioner-only constraint) - fhir-modeling-ai-content — текущая deployed архитектура AI-output в FHIR (Composition + CarePlan + Observation)
- fhir-composition — параллельный контейнер для overview AI text
- fhir-careplan — параллельный контейнер для FollowUpRecommendations
- fhir-observation — лаб-данные, target для CI.focus / investigation.item
- fhir-service-request — для рекомендованных тестов (additionalWorkup)
- fhir-provenance — multi-agent audit chain
- fhir-organization —
Organization/bloodgptкак author - fhir-risk-assessment — для predicted outcomes; CI ссылается через
prognosisReference[] - fhir-annotation — data type для
note[] - parameter-triage-codes — triage enum который ложится в CI extension
Источники
Источники: 1.
Сноски
-
FHIR R4 ClinicalImpression, accessed 2026-05-17, https://hl7.org/fhir/R4/clinicalimpression.html. ↩