Quartz 4

FHIR DiagnosticReport

draft
Not verified

3 min read

Ресурс-контейнер для лабораторного отчёта или imaging-отчёта. Связывает несколько Observation (lab parameters / imaging findings) с metadata о том кто заказал, кто провёл, когда issued. У нас — каждый загруженный лаб-отчёт = один DiagnosticReport, ссылающийся на N Observations с биомаркерами.

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

  • Один на загруженный документ — все Observation’ы (биомаркеры) одного теста группируются под одним DiagnosticReport.
  • Источник — VLM pipeline (recognize → save). DiagnosticReport создаётся в save-fhir-resources.function.ts параллельно с Observations, ссылается на них через result[].
  • Альтернативные builder’ы — есть fhir-client.ts:990 (legacy buildDiagnosticReport), fhir-client.ts:1780 (другой path), fhir-observation-builders.ts:619 (newer). Все три ставят category: "LAB" hardcoded.
  • Multi-date documents — discharge summary с лабами за 3 даты создаёт 3 DiagnosticReport (по одному на уникальный test_date). См. recognize.orchestrator.ts.

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

  • subject — Patient/{id}
  • status — обычно "final" (для completed report’ов) или "preliminary" для pre-enrich state
  • category — у нас всегда LAB hardcoded (codesystem v2-0074). Не различаем RAD / IMG / EC для рентген / EKG / imaging — это gap.
  • code — что за тест (CodeableConcept). У нас обычно LOINC 11502-2 Laboratory report или 58410-2 Complete blood count panel.
  • effectiveDateTime — когда был тест (clinical date)
  • issued — когда reported (new Date() у нас — наш ingest time)
  • result[] — references на Observation’ы внутри report’а

Default category: "LAB" — единственное значение

Все 3 builder’а (legacy fhir-client.ts, fhir-observation-builders.ts:619, save-fhir-resources.function.ts) hardcoded ставят LAB. Codesystem v2-0074 содержит 40+ кодов (HM, CH, MB, RAD, CT, IMG, EC, SP, etc.), но мы используем только LAB.

Gap для timeline icons — на Timeline LAB всё-всё одинаково отображается, отдельную иконку для radiology / EKG / imaging нельзя сейчас. См. [[../domain/category-coverage]] (TBD).

Расширение LAB → granular discrimination зависит от того что LLM вернёт как document_type (см. [[../product/uploaded-document-types-supported]] — поле document_type в recognize prompt пока не extracted).

Связь с DocumentReference

DiagnosticReport — про отчёт (с результатами в виде Observations). DocumentReference — про загруженный файл (PDF/JPG/HEIC). Эти resource’ы не дублируются — DocumentReference указывает на файл (с GCS path), DiagnosticReport ссылается на extracted result’ы. У нас сейчас:

  • DocumentReference создаётся при upload
  • DiagnosticReport создаётся в save-fhir-resources после recognition

Multi-date case — один DocumentReference (один файл) + N DiagnosticReports (для каждой test_date).

Failure modes

  • Только LAB категория — не различаем тип теста. LAB для biopsy report’а и для CBC выглядит одинаково.
  • issued ≠ effectiveDateTime — мы ставим issued = new Date() (наш ingest time), но effectiveDateTime = реальная дата теста. Это правильно семантически, но для Timeline нужно использовать effectiveDateTime (clinical) а не issued (system).
  • performer не выставляется — кто провёл тест (Organization / Practitioner). Может быть useful для multi-lab scenarios, но сейчас не хватает infrastructure.

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

  • Расширять ли category чтобы различать LAB / RAD / IMG / EC? Зависит от того, что LLM extracts из document headers. Связано с [[uploaded-document-types]] taxonomy.
  • Добавлять ли performer (lab name → Organization)? У нас есть lab_name в test_info schema, но мы не создаём для него Organization resource.

Связанные решения

  • [[../product/uploaded-document-types-supported]] — document_type extraction от LLM = unblocker для granular category
  • [[../domain/category-coverage]] (TBD) — рамки расширения LAB → granular

Связано

  • [[fhir-resource-categories]] — общая концепция (включая текущий LAB-only gap)
  • [[fhir-observation]] — DR.result[] ссылается на Observations
  • [[fhir-document-reference]] — параллельный resource (файл vs report)
  • [[fhir-composition]] — alternative document container (с section’ами); у нас оба используются для разных целей

Источники

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

Сноски

  1. HL7 R4 spec, accessed 2026-05-17, https://hl7.org/fhir/R4/diagnosticreport.html. ↩

  2. ValueSet diagnostic-service-sections (codesystem v2-0074), accessed 2026-05-17, https://terminology.hl7.org/CodeSystem-v2-0074.html. ↩

Graph View

Backlinks