FHIR CarePlan

План медицинского ухода — последовательность действий, назначенных пациенту, с временем (когда), приоритетом (срочность) и обоснованием (зачем). Семантика: “что делать дальше” — в отличие от fhir-composition, которая фиксирует “что зафиксировано как итог теста”.

Использование в BloodGPT

Follow-up рекомендации — FollowUpRecommendations BloodGPT-таблица маппится на CarePlan. followUpSchedules → activities со scheduledPeriod, urgentTests → activities с priority. Реализация: fhir-careplan-builder.ts. См. ai-content-fhir-mapping.
Досдача тестов — нативный FHIR-паттерн: activity.detail.kind="ServiceRequest" + code (LOINC) + scheduledPeriod. Никаких custom extensions.

Ключевые поля для нас

subject — Patient/{id}
supportingInfo — DiagnosticReport/{reportId} для привязки к конкретному тесту-источнику
intent — у нас "proposal". Возможные значения из FHIR R4 ValueSet CarePlanIntent:
- proposal — предложение/рекомендация (наш кейс — AI рекомендует, не назначает)
- plan — планируемый ход действий, согласованный
- order — формальное назначение от authority (врача)
- option — один из нескольких вариантов на выбор
- directive — более строгое указание/директива
Мы используем proposal потому что не заменяем врача — наш CarePlan это suggestion, не medical order.
status — у нас "active". Возможные значения из FHIR R4 ValueSet RequestStatus:
- draft, active, on-hold, revoked, completed, entered-in-error, unknown
В принципе status может меняться: active → completed когда пациент сдал рекомендованные тесты, revoked если рекомендация отменена. Сейчас у нас одноразовая запись (создали active и не трогаем). Тема для будущего — нужен ли lifecycle management для CarePlans или нет.
activity[].detail:
- kind — тип активности из стандартного FHIR ValueSet CarePlanActivityKind. Не рандомная строка. Возможные значения: Appointment, CommunicationRequest, DeviceRequest, MedicationRequest, NutritionOrder, Task, ServiceRequest, VisionPrescription. У нас ServiceRequest — стандартный FHIR-способ выразить “запрос на лабораторный анализ”.
- code — что именно делать. Для retest это LOINC через loinc. Может быть как одиночный анализ, так и панель — LOINC включает codes для панелей (24323-8 — Comprehensive metabolic panel, 58410-2 — CBC, и т.п.). То есть один activity может означать “досдать всю панель CBC”.
- description — rationale из followUpSchedules.rationale
- scheduledPeriod — { start, end } из suggestedTimeframe
- priority — стандартный FHIR ValueSet RequestPriority. Возможные: routine, urgent, asap, stat. Это не произвольные — фиксированный набор. У нас в urgentTests.urgencyLevel маппится в эти коды.
author — см. fhir-annotation про choice type; у нас → Organization/bloodgpt-com (см. authorship-organization-not-device)

FHIR R5 implications

В R5 CarePlan.activity.detail удалён целиком — inline backbone-элемент вместе с code, priority, description, status, kind, scheduledPeriod пропадает. Вместо него activity.plannedActivityReference указывает на отдельный ресурс (ServiceRequest для lab-запросов, Task, MedicationRequest, RequestOrchestration, ImmunizationRecommendation, SupplyRequest). Также удалены outcomeCodeableConcept / outcomeReference — заменены на performedActivity (CodeableReference).

Сам ресурс CarePlan жив (Maturity Level 2, Trial Use). Удалён конкретно inline-block.

Это часть общего R5 design-trend: меньше inline backbone-элементов, больше ссылок на специализированные ресурсы. См. fhir-versions.

Что это значит для нас:

При R4 → R5 миграции придётся переписать builder: каждый activity.detail.* уезжает в отдельный ServiceRequest (для lab tests) с intent: proposal или plan, плюс activity.plannedActivityReference на него. См. fhir-service-request про целевую форму.
R4 разрешает activity.reference (на отдельный ресурс) как опцию параллельно с activity.detail (inline). Если хотим R5-ready дизайн уже сейчас — можно использовать reference-форму в R4, тогда апгрейд тривиален (только переименование поля reference → plannedActivityReference).
Inline activity.detail.priority подход (план BG-1250) — R4-only решение, при апгрейде на R5 ломается. Reference-через-ServiceRequest — переживает оба.

Маппинг полей BloodGPT

BloodGPT	FHIR CarePlan path
`followUpSchedules[].parametersToMonitor`	`activity.detail.code` (LOINC array, может быть панелью)
`followUpSchedules[].suggestedTimeframe`	`activity.detail.scheduledPeriod`
`followUpSchedules[].rationale`	`activity.detail.description`
`urgentTests[].testName`	`activity.detail.code.text` (если нет LOINC code, fallback в текстовое имя)
`urgentTests[].urgencyLevel`	`activity.detail.priority` (`urgent` / `asap` / `routine` / `stat`)
`urgentTests[].justification`	`activity.detail.description`

Связано

fhir-composition — parallel: AI overview (что зафиксировано) vs CarePlan (что дальше)
fhir-observation — parametersToMonitor LOINC коды переиспользуются
fhir-service-request — R5-ready форма для AI-сгенерированных lab-suggestions (replacement для inline activity.detail)
fhir-versions — R4 → R5 trend, удаление activity.detail и общий паттерн references-вместо-inline
loinc — coding system для test codes (включая панели)
ai-content-fhir-mapping — overview маппинга AI-output
zero-extensions-fhir — CarePlan покрывается полностью стандартом

Источники

Источники: ¹ ² ³ ⁴ ⁵ ⁶ ⁷ ⁸.

Сноски

HL7 R4 spec, accessed 2026-05-17, https://hl7.org/fhir/R4/careplan.html. ↩
HL7 R5 spec, accessed 2026-05-17, https://hl7.org/fhir/R5/careplan.html. ↩
R4 → R5 diff, accessed 2026-05-17, https://hl7.org/fhir/R5/diff.html. ↩
CarePlanIntent ValueSet, accessed 2026-05-17, https://hl7.org/fhir/R4/valueset-care-plan-intent.html. ↩
CarePlanActivityKind ValueSet, accessed 2026-05-17, https://hl7.org/fhir/R4/valueset-care-plan-activity-kind.html. ↩
RequestPriority ValueSet, accessed 2026-05-17, https://hl7.org/fhir/R4/valueset-request-priority.html. ↩
Реализация, accessed 2026-05-17, https://github.com/Realai-plus/bloodgpt-for-business/blob/main/packages/analysis-core/src/lib/fhir-careplan-builder.ts. ↩
Сессия ildar/871a7608, 2026-02-13 — обсуждение и финализация маппинга. ↩

Quartz 4

Explorer