59 items under this folder.
HL7 (Health Level Seven International) — non-profit standards organization, publisher протоколов interoperability в healthcare: HL7v2 (legacy сообщения), CDA (clinical documents в XML), FHIR (modern resource-based, наш основной стандарт). Основана 1987 в США, штаб-квартира Ann Arbor (Michigan). Governance — membership-based working groups, ANSI-accredited. На стандартах HL7 строится US ONC certification и большинство interoperability mandates по всему миру.
Генерация типов и runtime-валидаторов из FHIR StructureDefinition: TS-interface'ы, Zod schemas, C#-классы, Java POJO. Один SD = один тип. Cardinality / fixed values / bindings разворачиваются в literal types и unions. Codegen закрывает builder от собирания невалидного ресурса на compile-time.
Семейство FHIR-ресурсов, которые описывают **поведение системы**, а не клинические данные о пациенте. StructureDefinition / ValueSet / CodeSystem / CapabilityStatement / OperationDefinition / SearchParameter / ImplementationGuide. Это машино-читаемая спецификация того, как должны выглядеть клинические ресурсы, какие коды разрешены, что умеет сервер.
FHIR Implementation Guide (IG) — публикуемый пакет conformance-ресурсов (StructureDefinition / ValueSet / CodeSystem / CapabilityStatement) + markdown-страницы + examples, описывающий как реализовать конкретный use case на FHIR. IG Publisher собирает всё в HTML-сайт + NPM-пакет + validation pack.
Карта 145+ resourceType'ов FHIR R4. Канонические модули спецификации (Foundation / Base / Clinical / Financial / Specialized) с кратким описанием каждого + альтернативный взгляд по роли ресурса в системе: каркас спецификации (StructureDefinition / ValueSet) vs каталоги клиента (ObservationDefinition / Questionnaire) vs транзакционные данные пациента (Patient / Observation / Composition). Какие из ресурсов мы используем сегодня, какие в планах.
Глоссарий по содержимому FHIR-карточек (resource elements), сгруппированный по уровням: три категории элементов (primitive / DataType / Resource), notation полей (cardinality + choice types), ключевые DataTypes (Identifier, CodeableConcept / Coding / code, Reference), universal slots на каждом ресурсе (meta + extension), Bundle как контейнер. Дополняет [[fhir-basics]] — там карточки и связи между ними, здесь — устройство одной карточки изнутри.
Landscape FHIR-инструментов поверх голой спецификации. Пять слоёв: type-libraries (для compile-time), HTTP-clients (read/write/search), validators (runtime check), server SDKs (persistence + REST), profiling tools (FSH/SUSHI/IG Publisher). Большинство pure-types vs full-stack продуктов в одной таблице.
FHIR Shorthand (FSH) — текстовый DSL для написания FHIR conformance-ресурсов (StructureDefinition, ValueSet, CodeSystem). Альтернатива ручному JSON. SUSHI компилирует FSH → JSON SD. Стандарт de-facto для современных IGs, но не universal: US-Core пишет JSON напрямую.
Биомаркер — клиническая единица, которую мы измеряем у пациента и интерпретируем как сигнал. Канонический term в продукте и коде (UI, graph, harmonization). Близкие термины — analyte (вещество в анализе), observation (единичное измерение в FHIR), тренд (последовательность observations того же биомаркера). Legacy: «параметр крови» в .NET-эпохе.
FHIR-нативный versioning для resource'а: каждое создание/изменение порождает запись в `_history`. `meta.versionId` + `meta.lastUpdated` идентифицируют конкретную версию; conditional PUT по identifier — основной механизм upsert'а; `{Resource}/{id}/_history/{versionId}` отдаёт точную версию. HAPI-specific квирк — `meta.tag` accumulates additively через conditional-PUT (не replacing) — нагружает наш CI ↔ Composition pairing.
FHIR Terminology Service — стандарт HL7 для управления медицинскими словарями. Три core ресурса (CodeSystem / ValueSet / ConceptMap) + стандартные operations ($lookup, $translate, $expand, $validate-code, $subsumes). Vendor implementations: CSIRO Ontoserver, Apelon DTS, Snowstorm, Termhub, tx.fhir.org. У нас сегодня нет полноценного terminology server'а — мы строим его компоненты bottom-up в LOINC harmonization service / biomarker graph; см. [[../technical/terminology-service]] про то как наш bottom-up artifact ложится на этот стандарт.
Биомаркер, который был назначен/ожидался в панели, но фактически не выполнен. В FHIR кодируется через Observation.dataAbsentReason; на UI рендерится в сером с трендом, без значения.
Введение в FHIR через метафору карточек и связей между ними: что это, для чего, как устроена коллекция связанных ресурсов на конкретном примере, сравнение с реляционной БД. Точка входа в FHIR-домен вики; дальше — отдельные страницы по содержимому карточек, видам ресурсов, профилированию, версиям.
FHIR Profiling — формальный механизм constraint'ов поверх базовых ресурсов (cardinality, must-support, slicing, fixed values, value set bindings, extensions) без изменения стандарта; основа интероперабельности через realm-IG (US Core / RuCore / IPS) и обязательное условие для регулируемых рынков.
SNOMED CT — глобальная клиническая терминология (350K+ активных concept'ов, hierarchical IS-A); у нас закрывает `Condition.code` / `Procedure.code` / `AllergyIntolerance.code` через `narrative-to-fhir/snomed-coder.ts` по pattern «LLM возвращает English term → terminology server `$expand` резолвит код»; bare LLM coding доказан неработающим (garbage codes), Артур май-2026 audit пофиксил wrong-concept bugs через CSIRO Ontoserver `$lookup`.
Федеральная НСИ Минздрава РФ — параллельный к LOINC каталог справочников. OID-пространство `1.2.643.5.1.13.13.11.*`: МКБ-10 (`.1005`), синонимы (`.1489`), справочник специальностей мед.работников. RuCore явно ссылается. У BloodGPT не используется; relevant если интеграция с ЕГИСЗ.
Какие `Resource.category` gap'ы закрыть для timeline v1 (для иконок). Закрываем MedicationStatement (`patientspecified`) / Procedure (SNOMED-based) / Composition (`assess-plan`) / CarePlan. Откладываем DiagnosticReport granular + Immunization builder.
FHIR AllergyIntolerance — аллергии и непереносимости. **Closed enum** category (4 кода R4 — нельзя custom-coding). `verificationStatus` default `unconfirmed` для self-reported — paper Macy/Contreras 2014 (false-positive penicillin allergies → suboptimal prescribing). Substance coding через `narrative-to-fhir/snomed-coder.ts`.
FHIR Condition — диагнозы / проблемы / состояния. У нас default `category: problem-list-item` (rationale: Encounter не emit'ится → encounter-diagnosis incoherent + US-Core query compatibility). `clinicalStatus` ⊥ `verificationStatus` (ортогональные оси). SNOMED CT через `narrative-to-fhir/snomed-coder.ts`.
Ресурс-контейнер для лаб-отчёта / imaging-отчёта. Связывает N `Observation` с metadata (кто заказал, кто провёл, когда issued). У нас каждый загруженный лаб = один DR. Hardcoded `category: LAB` (40+ возможных кодов v2-0074). Multi-date documents → 3 DR на 3 unique test_date. `effectiveDateTime` ≠ `issued`.
Ресурс для записи факта что пациент принимал/принимает препарат. Отличается от `MedicationRequest` (рецепт врача) и `MedicationAdministration` (зафиксированный приём). У нас `category` НЕ выставляется (gap). Singular `0..1`. Standard values: inpatient/outpatient/community/patientspecified. `informationSource` тоже не выставляется.
FHIR Procedure — выполненные процедуры. У нас `category` НЕ выставляется (gap). SNOMED-based, нет фиксированного ValueSet. `performedDateTime` vs `performedString` (R4-compliant fallback для нечётких дат типа «5 лет назад»). Кодирование через `narrative-to-fhir/snomed-coder.ts`.
Поле `Resource.category` для разделения подтипов внутри одного типа ресурса (Observation laboratory vs vital-signs, Condition problem-list-item vs encounter-diagnosis, etc). Use cases — UI filtering, pipeline routing, иконки в Timeline, search через `?category=`. Cardinality и binding strength варьируется по ресурсам.
Таксономия двух классов данных в health-приложениях — lifestyle (sleep / steps / calorie tracking, wellness coaching) vs clinical (lab results, conditions, medications). Различает что приложение **может сделать** + regulatory режим + trust frame. BloodGPT в clinical классе; Google Health / Superpower / Hone / Function — в lifestyle (другой класс, не конкуренты напрямую).
Survey индустрии и академической литературы по timeline visualization патиентской медкарты — LifeLines (foundational), Apple Health Records, Epic Storyboard (sidebar), MyChart, OpenMRS, EHR TimeBar. Pattern taxonomy: orientation/encoding/grouping/density/versioning. Versioning navigation (FHIR `_history`) — industry-стандарта нет.
Таксономия 16 типов документов которые юзер может загружать через `/upload` — классификация по LOINC's Document Ontology (ось `Type of service`). 4 tiers — Tier 1 lab / Tier 2 narrative / Tier 3 utility / Tier 4 composite. Сейчас в коде захардкожено `11502-2 Laboratory report` для всех — recognition не классифицирует document_type.
Lifecycle rules для ресурсов в FHIR-store по их `origin` tag — user-uploaded immutable, ai-generated mutable, external-data immutable. Discriminator (meta.tag origin) определяется в [[../technical/fhir-meta-tagging]]. Гэп — `enrich-fhir-observations` нарушает immutability на user-uploaded Observation; рекомендация удалить (V2.5 ClinicalImpression заменяет). Stale-detection через `?_tag=origin|user-uploaded&_lastUpdated=gt<...>`.
FHIR R4/R5/R6 — где мы (R4 во всём стеке), R5 design-trend «меньше inline backbone, больше references на специализированные ресурсы» (`CarePlan.activity.detail` удалён, и т.п.); R6 ballot4 (build May 14 2026) продолжает тренд — AdverseEvent → CodeableReference, InsurancePlan → InsuranceProduct, новый DeviceAlert.
Direction зафиксирован. Конкретные значения TTL per panel в работе, медицинской верификации пока нет (первое приближение через guideline-research).
FHIR R4 ресурс для **predicted outcomes** с probability и rationale. У нас не используется; рассматривался и отвергнут как хост V2.5 rich-output (assessment vs prediction semantic mismatch). ClinicalImpression ссылается на RiskAssessment через `prognosisReference[]`. Research status.
Builder в worktrees/v2-5-fhir/packages/analysis-core/src/lib/fhir-clinical-impression-builder.ts сейчас пишет в .finding[] с kind="found-context" sub-extension — это противоречит FHIR R4 spec (finding[] = диагностические выводы, не...
System-level topic про достижимость точности AI-pipeline и позиционирование её в коммуникации (внешний бенчмарк, инвесторам, врачам, пациентам). Research / placeholder для синтеза множественных transcripts.
5% UX-зона около границы reference range как marketing UX, не clinical interpretation. Initial decision Apr 17 — убрать, на следующем созвоне reversed; keep как захардкоженная константа. Без научного / регуляторного основания.
Структура где для каждого биомаркера зафиксированы препараты влияющие на него, связанные заболевания, межбиомаркерные взаимодействия. В команде называют «карта связей»; в имплементации — JSON-графы. Используется в diagnostic / generation pipelines.
FDA-задокументированная проблема искажения результатов анализов у пациентов с высокими дозами биотина (B7). Биотин искажает иммунологические тесты (тиреоидные гормоны, тропонин) → ошибочная диагностика инфаркта / щитовидки. В США зафиксированы летальные исходы.
Каталог параметров лаборатории с собственными reference ranges и метаданными — вместо AI-определения по умолчанию. Admin/lab-managed (BG-925, RFC-028). Research stage, скоро имплементация.
FHIR R4 ресурс для клинической оценки — record of clinician's view (structured findings + prose summary + recommended actions). У нас — proposed primary container для V2.5 per-параметрового rich-output (BG-1323, status: exploratory, не deployed). Семантика — процесс клинического суждения, не data points.
FHIR R4 ресурс — обёртка над **внешним документом** (PDF выписки, HL7-файл, скан анализов, URL guideline). Содержит metadata + либо inline attachment, либо ссылку на binary. Status в BloodGPT — **research**: сейчас оригиналы PDF в GCS без FHIR-обёртки; хочется внедрить (без timeline).
FHIR R4 ресурс — формальное юридическое / функциональное объединение людей. У нас в двух ролях: **AI-author** (`Organization/bloodgpt` для AI-generated контента, заменил Device после Google Healthcare API vendor-limit) + **tenant-brand** для per-organization portal. Known gap: provisioning только для новых orgs.
FHIR R4 ресурс — record of who/when/why/из какого source создан другой ресурс. Ссылается на target через `target[]: Reference`. Один Provenance может покрывать множественные resources (всё созданное при разборе одного source-документа). У нас — full audit chain для multi-source write events; см. [[../technical/fhir-meta-tagging]] для policy.
FHIR R4 ресурс — запрос на выполнение услуги/процедуры (lab orders, imaging, referrals, procedures). Status в BloodGPT — **exploratory**: контейнер для AI-сгенерированных suggestions about additional workup (V2.5 rich-output, BG-1323). Builder в worktree, не deployed. R5-обязательная reference-форма для CarePlan.activity.
Один TS-сервис маппинга биомаркеров (объединяет normalization-service + loinc-harmonization-service) с Dictionary-First lookup-layer + admin UI поверх. Старая нормализация → fallback внутри LOINC-сервиса. Tracker: BG-876, BG-1023.
Mastra multi-turn опросник пациента для сбора medical context (диагнозы / лекарства / аллергии / симптомы / семейный анамнез / lifestyle). Реализован как TS Mastra-агент (BG-1050), подключён к patient-portal через `/api/survey`. Output → MedicalProfile JSON (V0.5) → FHIR write через 5 tools (V1.5, bridge step TBD).
Иерархия медицинских источников на которые продукт ссылается (интерпретации, biomarker graph, отчёты). Принципиально влияет на регуляторное позиционирование (medical device vs wellness) и доверие врачей. От clinical guidelines (KDIGO, ATA) → research literature → consensus → educational.
Доменный enum для action priority на параметре в V2.5 rich-output `{urgent_doctor, routine_doctor, monitor, ok_in_context}`. Не FHIR-стандарт. Появился в session d9de9416 (BG-1323). Python ↔ TS drift; в Postgres `parameterAnalysis.triage` column. Не в production deploy.
Лабораторные диапазоны (`low/normal/high`) для биомаркера. Один из inputs для interpretation на параметре (не source-of-truth — для non-quantitative параметров их нет; lab может передать готовую `interpretation`). Multi-tier, region-aware. Failure modes — lab-status conflict.
EU и US гайдлайны расходятся в порогах одних и тех же биомаркеров (ApoB: 65 mg/dL EU vs 70 mg/dL US, Cyprus лаба отдаёт по US). Сейчас лаба передаёт одно значение, система применяет как есть; региональная семантика наблюдения не учитывается.
Pivot с Device на Organization подтверждён через session c9560637 (Feb 17–20 2026): Google Healthcare API не принимает Device-references в author[x] choice type. Это vendor-specific ограничение — FHIR R4 spec разрешает Device через...
FHIR data type (не самостоятельный resource) для freeform комментариев — embed внутри ресурсов через `note[]` поле в Observation / Composition / CarePlan / других. Содержит text + author + time.
Контейнер для группы FHIR-ресурсов. Семантика зависит от `Bundle.type`: transaction (атомарный batch CRUD), batch (independent ops), document (Composition first + refs), searchset (server response), history, message. Главное место сложности — UUID resolution в transaction Bundle: внутренние ссылки между ещё-не-созданными ресурсами идут через временные `urn:uuid:*` placeholders, сервер мапит их в real ID и переписывает все references за одну атомарную операцию.
План медицинского ухода — последовательность действий с временем / приоритетом / обоснованием. Семантика «что делать дальше» (в отличие от [[fhir-composition]] «что зафиксировано»). Наш контейнер для FollowUpRecommendations. R5 trend — `activity.detail` удалён → reference на ServiceRequest.
**Clinical document** в FHIR — структурированный document с иерархией секций, явным авторством, статусом. Аналог — заключение врача / выписка как FHIR resource. Наш контейнер для AI overview (TestOverview → section[]); enabler для snapshot-vision. PUT canonical per Patient (см. [[../technical/health-report-versioning-model]]).
FHIR resource для физического или software-агента в healthcare (включая SaMD — Software as a Medical Device). **Superseded** для AI-author в BloodGPT — изначально (session 871a7608) выбран, на session c9560637 заменён на `Organization/bloodgpt` (Google Healthcare API не принимает Device-references в `author[x]` choice).
Базовый ресурс для одного клинического измерения / оценки / интерпретации. У нас каждый лабораторный показатель (glucose, ferritin, vitamin D...) — отдельная Observation с LOINC code. Также enrichment'ы — `note[]` (AI commentary, legacy) и `interpretation` (H/L/N). См. `Observation.note[]` policy в [[../technical/recognize-per-observation-comments]].
International Patient Summary — **ISO 27269** + HL7 FHIR IPS Implementation Guide v2.0.0. Минимальный clinically-significant snapshot пациента для emergency / cross-border handoff / specialist transfer. В BloodGPT — концептуальный фрейм для проектирования summary; собственного IPS-документа в продакшене нет. `$summary` поддержка по vendor варьирует.
LOINC — глобальный coding system для лабораторных тестов (109K+ concept'ов в v2.82); 6-axis наименование (Component/Property/Time/System/Scale/Method), Pareto-распределение использования (80 кодов = 80% volume). У нас закрывает `Observation.code` + section coding в Composition (IPS sections).
Protected Health Information (HIPAA term). Используется в декision-страницах как термин-аксиома ([[../technical/phi-in-fhir-not-sql]]). Эта страница фиксирует что считаем PHI у себя — много открытых вопросов про границы (что считается identifier, agregated data, lifestyle metrics vs clinical).
Решение 2026-02-14 формулировалось как «ровно один custom extension». По факту к 2026-05 их около десятка (см. «Текущее состояние»). Принцип, который остался в силе: каждое новое поле сначала ищет стандартное место в R4, custom...
При каких условиях LLM безопасно использовать для обработки медицинских данных — что говорят исследования (NOHARM study), что требует регулятор (FDA Purolea precedent). Две прочные опоры: empirical paper + regulatory letter. Foundational reasoning для нашего product positioning и regulatory pathway.