Quartz 4

FHIR ServiceRequest

draft
Not verified

3 min read

FHIR R4 ресурс — запрос на выполнение услуги или процедуры. Покрывает lab orders, imaging, referrals к специалистам, procedures. В реальной медицине это то, что врач выписывает: «пойди сдай этот тест», «направление на МРТ», «консультация эндокринолога».

Status в BloodGPT: exploratory. Рассматривается как контейнер для AI-сгенерированных suggestions about additional workup в V2.5 rich-output (BG-1323). Builder в worktree bloodgpt-for-business/worktrees/v2-param-analysis, не deployed. Сейчас follow-up рекомендации идут через fhir-careplan activity[] — open вопрос как это меняется при внедрении ServiceRequest для AI suggestions.

Зачем рассматривается

V2.5 additionalWorkup[] — AI рекомендует дополнительные тесты per-параметр (например: «high cholesterol → попробуйте Apo B и Lp(a)»). Сейчас сливается в CarePlan.activity[]. Идея — отдельные ServiceRequest ресурсы с intent: proposal, чтобы:

  • Маркировать как AI suggestion (не auto-order)
  • Связать с конкретной fhir-clinical-impression через reasonReference
  • Filter через _security=AIAST (см. fhir-meta-tagging)

Ключевое поле — intent

Градиент намерения от AI suggestion до реального заказа:

proposal → plan → directive → order → original-order → reflex-order → filler-order → instance-order
   ▲                              ▲
   "AI советует"             "реальный заказ в lab"

intent: proposal — наш кейс. Downstream клиент видит proposal и понимает: показывать в UI как suggestion, не отправлять в lab автоматически.

Структура для нашего use case (proposed)

{
  "resourceType": "ServiceRequest",
  "id": "sr-iron-panel-test123",
  "meta": {
    "security": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-ObservationValue",
      "code": "AIAST"
    }]
  },
  "status": "draft",
  "intent": "proposal",
  "priority": "routine",
  "code": {
    "coding": [{
      "system": "http://loinc.org",
      "code": "24360-0",
      "display": "Hemogram, platelet, and WBC differential panel"
    }],
    "text": "Iron panel (iron, TIBC, transferrin saturation, ferritin)"
  },
  "subject": { "reference": "Patient/patient-456" },
  "authoredOn": "2026-04-24T10:03:42Z",
  "requester": { "reference": "Device/bloodgpt-pipeline-v2-5" },
  "reasonReference": [
    { "reference": "ClinicalImpression/ci-hemoglobin-test123" }
  ]
}

Связь с другими ресурсами

ClinicalImpression/{ci}    ←──reasonReference──    ServiceRequest/{sr}
                                                        │
                                                        ├── intent: proposal
                                                        ├── status: draft
                                                        ├── meta.security: AIAST
                                                        └── code: LOINC

requester — Device/bloodgpt-pipeline-v2-5 (см. fhir-provenance про pipeline version singletons).

Возможное влияние на текущий follow-up flow

Ильдар (carry-over markup): «возможно, это должно также изменить генерацию того, что мы называем follow-up»

Сейчас FollowUpRecommendations → fhir-careplan activity[]. Если ServiceRequest становится primary container для AI-рекомендаций — CarePlan может:

  • Остаться для plan-level orchestration (последовательность действий, scheduling)
  • Сослаться на ServiceRequest через activity[].reference
  • Или CarePlan становится опциональным wrapper если все рекомендации — discrete ServiceRequests

Не финализировано. Open вопрос — как именно перераспределить FollowUp generation между CarePlan и ServiceRequest.

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

  • intent: proposal ≠ status: draft — это разные оси. Intent describes “что это (предложение vs приказ)”, status — “where in workflow”. AI suggestions: intent: proposal + status: draft|active.
  • code обязательное — должен быть LOINC (для labs) или SNOMED (для процедур). Без code — invalid resource. Если AI не может resolve LOINC — fallback в code.text с пустым coding[] — но это anti-pattern.
  • requester — Device, Practitioner, Organization, Patient, RelatedPerson — допустимые reference types. Device/bloodgpt-pipeline-vN — валидно для AI (см. fhir-provenance singleton pattern).

Открытые вопросы

  • CarePlan vs ServiceRequest для AI follow-up — split responsibility? CarePlan для plans, ServiceRequest для concrete requests?
  • Backfill старых тестов — если внедрим ServiceRequest, нужно конвертировать historical FollowUpRecommendations.
  • code.text без LOINC — fallback стратегия когда AI не resolved LOINC code.

Связано

  • fhir-clinical-impression — связано через reasonReference (зачем заказали)
  • fhir-careplan — текущий container для FollowUpRecommendations; carry-over question как меняется при внедрении ServiceRequest
  • fhir-provenance — requester: Device/bloodgpt-pipeline-vN
  • fhir-meta-tagging — meta.security: AIAST для AI-suggestion marking
  • loinc — code использует LOINC

Источники

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

Сноски

  1. FHIR R4 ServiceRequest, accessed 2026-05-17, https://hl7.org/fhir/R4/servicerequest.html. ↩

  2. Linear BG-1323, accessed 2026-05-17, https://linear.app/realai/issue/BG-1323 — issue tracking. ↩

Graph View

Backlinks