В FHIR R4 — 145 resourceType’ов (R5 добавил ещё несколько). Спецификация группирует их в модули по теме. Ниже — короткий обзор каждого модуля + альтернативный взгляд по роли ресурса в системе (каркас системы / каталоги / транзакции пациента). Полный список ресурсов с подробной документацией — hl7.org/fhir/R4/resourcelist.html1.
Канонические модули FHIR (как в спецификации)
Группировка от HL7. Жирным — ресурсы которые мы используем в коде BloodGPT (есть отдельные страницы или явные builders).
1. Foundation — каркас системы
Базовая инфраструктура, на которой стоит вся FHIR-семантика.
- Abstract base —
Resource,DomainResource. От них наследуются все остальные. - Conformance — описание самой системы: какой сервер что умеет (
CapabilityStatement), как устроен ресурс (StructureDefinition), какие операции доступны (OperationDefinition). Подробно: fhir-conformance-resources. - Terminology — словари и переводы между ними:
CodeSystem,ValueSet,ConceptMap,NamingSystem. Подробно: fhir-terminology-service. - Documents — документ как объект:
Composition(наш центральный AI-документ),DocumentReference(ссылки на input PDF). - Exchange — обмен данными:
Bundle(атомарный POST/GET кучи ресурсов),MessageHeader,Subscription. - Security — audit и доступ:
Provenance(кто/когда/чем сгенерил),AuditEvent,Consent.
2. Base (administrative) — кто, где, когда
Административные сущности — люди, организации, места, координация процессов.
- Individuals — люди в системе:
Patient,Practitioner,PractitionerRole,RelatedPerson. - Entities — организации, места, устройства:
Organization,Location,HealthcareService,Device. - Workflow — координация процессов:
Task(задача),Encounter(визит),Appointment/Schedule/Slot(запись на приём),EpisodeOfCare. Это state-machine ресурсы — каждый имеет обязательноеstatusполе с жизненным циклом. - Management — финансово-организационные сущности:
Account,Coverage.
3. Clinical — клинические данные пациента
Что произошло с пациентом / что у него есть.
- Summary — основные клинические записи:
Condition(диагнозы),Procedure(процедуры),AllergyIntolerance(аллергии),ClinicalImpression,FamilyMemberHistory. - Diagnostics — диагностика:
Observation(биомаркеры, симптомы, narrative),DiagnosticReport(контейнер лабораторного отчёта),Specimen(биоматериал),ImagingStudy. - Medications — лекарства в разных позициях процесса:
MedicationRequest(назначение врача),MedicationStatement(что пациент принимает),MedicationDispense(выдача аптекой),MedicationAdministration(факт приёма). - Care Provision — план помощи и заявки:
CarePlan,ServiceRequest(заявка на действие),Goal,NutritionOrder,Communication.
4. Financial — биллинг и страховые потоки
Заявки в страховые, payments, claims, биллинг. Ресурсы: Claim, ClaimResponse, Coverage, Invoice, Account, ExplanationOfBenefit, PaymentNotice.
Мы не используем — B2C без insurance integration.
5. Specialized — специфичные use cases
Разнородный модуль под нишевые сценарии.
- Public Health & Research — для клинических исследований:
ResearchStudy,ResearchSubject,AdverseEvent. - Definitional Artifacts (catalog) — справочники «что бывает» (каталог клиента, level 2):
ActivityDefinition,PlanDefinition,ObservationDefinition(в плане для custom ranges),SpecimenDefinition,Questionnaire,MedicationKnowledge. - Evidence-Based Medicine — knowledge artifacts. В R4 здесь
EvidenceиEvidenceVariable(maturity Trial Use, ~0-1);CitationиArtifactAssessmentдобавлены в R5. - Quality Reporting & Testing —
Measure,MeasureReport,TestScript. - Medication Definition (R5) — детальное описание препарата:
MedicinalProductDefinition,Ingredient,ClinicalUseDefinition.
Другой угол: по роли в системе
Канонические модули группируют ресурсы по теме (financial / clinical / administrative). Есть второй важный разрез — по роли в FHIR-системе: каркас спецификации vs справочники vs реальные данные пациента. Эта ось полезна потому что обращает внимание на существование не-транзакционных ресурсов, которые легко проглядеть, если работаешь только с потоком данных от пациентов. StructureDefinition / ValueSet / ObservationDefinition — тоже Resources, со своим жизненным циклом, своими actor’ами, своей дисциплиной редактирования.
| Уровень | Роль | Кто пишет | Примеры |
|---|---|---|---|
| 1. Ресурсы системы | определяют сам FHIR-каркас — какие structures валидны, какие коды разрешены, что сервер умеет. Не данные пациента вовсе, а формальная спецификация-как-resource | архитектор / тех-лид (редко — при изменении системы) | StructureDefinition, ValueSet, CodeSystem, CapabilityStatement, ConceptMap |
| 2. Каталоги данных | определяют «что бывает» в конкретной клинике — какие тесты лаборатория предлагает, какие формы-анкеты существуют, какие препараты в формуляре. Reference-data, на которую ссылаются транзакции | curator / admin клиента (per onboarding / product change) | ObservationDefinition, SpecimenDefinition, MedicationKnowledge, PlanDefinition, Questionnaire, ChargeItemDefinition |
| 3. Транзакционные данные | реальный поток про конкретных пациентов — identity, измерения, диагнозы, заявки, audit | приложение / клиницист / системы интеграций (непрерывно — каждое событие) | Patient, Observation, Condition, MedicationStatement, Task, ServiceRequest, Composition, Bundle, Provenance |
Та же триада в DB-аналогии: схема → reference tables → fact tables. Когда работаешь с конкретными пациентами, видишь только уровень 3 — но уровни 1-2 существуют и определяют как уровень 3 может выглядеть и интерпретироваться. Скорость изменения — следствие роли: системные ресурсы меняются с релизом системы, каталоги — с onboarding-ом клиента, транзакции — каждое событие. Но центральный концепт — роль, не velocity.
Где мы в этой картине. BloodGPT пишет преимущественно в уровень 3 — Observation, Condition, Composition, Bundle, ServiceRequest, Provenance появляются с каждым анализом. Уровень 1 используем как consumer (CodeSystem / ValueSet через Google Healthcare API + LOINC ingest, см. clinical-code-resolution) — сами туда не пишем. Уровень 2 — в плане: ObservationDefinition для кастомных reference ranges per-клиент (BG-925, см. custom-reference-ranges), сейчас не пишем.
Что использует BloodGPT
Активно в нашем pipeline (есть builders, читается dashboard’ом):
| Ресурс | Где / зачем |
|---|---|
Patient | Базовый объект всего pipeline’а; см. fhir-resource-origin-and-lifecycle |
Composition | Наш центральный AI-документ (test overview); см. fhir-composition |
Observation | Биомаркеры (лаб) + narrative observations + symptoms; см. fhir-observation |
Condition | Диагнозы пациента; см. fhir-condition |
MedicationStatement | Лекарства, которые принимает пациент; см. fhir-medication-statement |
AllergyIntolerance | Аллергии; см. fhir-allergy-intolerance |
Procedure | Процедуры в истории; см. fhir-procedure |
CarePlan | Follow-up рекомендации (досдать тест через месяц); см. fhir-careplan |
ServiceRequest | Запрос на досдачу теста; см. fhir-service-request |
DiagnosticReport | Контейнер лабораторного отчёта; см. fhir-diagnostic-report |
Specimen | Биоматериал (кровь/моча/etc) |
Bundle | Атомарный POST всех ресурсов из одного analysis run; см. fhir-bundle |
ClinicalImpression | V2.5 per-параметр rich-output (planned); см. fhir-clinical-impression |
Provenance | Audit trail (кто/когда/каким AI сгенерил); см. fhir-provenance |
DocumentReference | Incoming документы (в плане); см. fhir-document-reference |
Organization / Device | Authorship AI-output; см. authorship-organization-not-device |
Из ресурсов системы (уровень 1) используем неявно (vanilla R4, без своих SDs):
CodeSystem/ValueSetчерез terminology resolutionCapabilityStatement— отдаётся Google Healthcare API автоматом
В плане:
ObservationDefinition(уровень 2) — для custom reference ranges (BG-925); см. custom-reference-rangesStructureDefinition(уровень 1) — если формализуем профайлинг; см. formalize-fhir-profiles
Failure modes навигации
- Похожие имена с разной семантикой.
MedicationRequestvsMedicationStatementvsMedicationAdministration— три разных ресурса под три разные ситуации (назначение / самоотчёт пациента / факт приёма). Легко перепутать. Аналогично:ProcedurevsServiceRequest(выполненное vs запрошенное). - Definitional vs data близнецы.
MedicationvsMedicationKnowledge,ObservationvsObservationDefinition,ProcedurevsPlanDefinition(точнееActivityDefinitionдля шаблонов). Первое — уровень 3 (instance с patient data); второе — уровень 2 (catalog entry). typevscategoryconfusion. Многие ресурсы имеют оба поля, см. fhir-resource-categories (этой страницы проResource.categoryполе — не путать с этой текущей страницей про модули).
Связано
- fhir-basics — введение через метафору карточек и связей
- fhir-resource-elements — глоссарий содержимого одной карточки (cardinality, datatypes, references, etc)
- fhir-conformance-resources — ресурсы системы (уровень 1) детально
- fhir-terminology-service — terminology модуль (CodeSystem / ValueSet / ConceptMap)
- fhir-resource-categories — отдельная страница про поле
Resource.category(классификация подтипов внутри одного resourceType, не модули) - fhir-versions — что меняется в R5 / R6 относительно этой картины
Сноски
-
HL7 FHIR R4 — Resource List (canonical module breakdown), accessed 2026-05-19, https://www.hl7.org/fhir/R4/resourcelist.html. ↩