From 8bb6d75fed65b1d5371ace05f5d0956df915956d Mon Sep 17 00:00:00 2001 From: muqiuhan Date: Mon, 29 Dec 2025 13:29:56 +0000 Subject: deploy: 125862a284943979eed046927483686b770da9ff --- .../index.html" | 337 +++++++++++++++++++++ .../29/TSOPT-\346\243\200\346\237\245/index.html" | 295 ++++++++++++++++++ 2 files changed, 632 insertions(+) create mode 100644 "2025/12/29/FHIR-\350\256\260\345\275\225\346\202\243\350\200\205\347\232\204\347\224\250\350\215\257\350\256\260\345\275\225/index.html" create mode 100644 "2025/12/29/TSOPT-\346\243\200\346\237\245/index.html" (limited to '2025/12/29') diff --git "a/2025/12/29/FHIR-\350\256\260\345\275\225\346\202\243\350\200\205\347\232\204\347\224\250\350\215\257\350\256\260\345\275\225/index.html" "b/2025/12/29/FHIR-\350\256\260\345\275\225\346\202\243\350\200\205\347\232\204\347\224\250\350\215\257\350\256\260\345\275\225/index.html" new file mode 100644 index 00000000..4aa8f73f --- /dev/null +++ "b/2025/12/29/FHIR-\350\256\260\345\275\225\346\202\243\350\200\205\347\232\204\347\224\250\350\215\257\350\256\260\345\275\225/index.html" @@ -0,0 +1,337 @@ + + + + + + + + + + + + + + + + + + + + + + + + FHIR 记录患者的用药记录 | + 暮秋小屋 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+ +
+ +
+
+
+ + + +
+
+
+ +
+
+
+ + +
+ +
+ +
+ +
+
+
+

FHIR 中的“用药记录”并非一个单一概念,而是一个由不同角色、不同时间点和不同意图构成的连续工作流。

+

FHIR 中的药物相关记录类型本质上是是状态机(State Machine)和责任链(Chain of Responsibility)。每个资源代表业务流程中的一个特定状态(如“已下达”、“已执行”、“已陈述”),并通过引用链接形成完整的、可审计的责任链。以下是基于此原理的决策逻辑与实现方案。

+

核心逻辑:根据数据源的意图选择资源

+

用药信息的记录遵循“谁在什么时间点产生了什么信息”的原则。这直接对应到三个核心资源:

+
    +
  1. +

    MedicationRequest(用药请求)

    +
      +
    • 意图与状态:代表一个临床意图或指令。这是一个对未来行为的请求,其状态包括 active(激活)、completed(完成)、cancelled(取消)等。
    • +
    • 数据来源:由具有处方权的医疗专业人员(如医生)创建。
    • +
    • 核心信息:包含用药方案(药品、剂量、频次、途径)、用药原因、有效时间段、开立者、开立时间。
    • +
    • 类比:医院的“医嘱单”或药房的“处方”。
    • +
    +
  2. +
  3. +

    MedicationAdministration(用药管理)

    +
      +
    • 意图与状态:代表一个已发生的事实。这是对MedicationRequest指令的一次具体执行事件的记录,状态为 completed。
    • +
    • 数据来源:由执行给药的医疗专业人员(如护士)在给药后记录。
    • +
    • 核心信息:包含实际使用的药品、实际剂量、实际给药时间、给药途径、执行者。它必须通过 .basedOn 字段引用一个或多个MedicationRequest,以建立从“指令”到“执行”的可追溯性。
    • +
    • 类比:护士的“给药记录”,精确到某年某月某日某时某分给患者注射了某药。
    • +
    +
  4. +
  5. +

    MedicationStatement(用药陈述)

    +
      +
    • 意图与状态:代表一个关于用药的断言或声明。它描述的是患者正在使用、曾经使用或计划使用某种药物的状态,不一定关联到具体的医嘱。
    • +
    • 数据来源:可以来自患者自述(如“我每天吃一粒阿司匹林”)、家属转述,或由系统从历史记录中汇总生成。
    • +
    • 核心信息:包含陈述的用药信息、有效时间段、信息状态(如 active, completed)、信息来源(patient-reported)。
    • +
    • 类比:病历中的“现病史-用药史”部分,或患者填写的“用药清单”。
    • +
    +
  6. +
+

一个完整的院内用药闭环通常遵循以下可追溯的数据流:

+
1
2
3
4
graph LR
A[医生创建<br>MedicationRequest] -- `.basedOn` 引用 --> B[护士执行后创建<br>MedicationAdministration];
B -- 系统可推导生成 --> C[系统生成<br>MedicationStatement<br>(汇总当前有效用药)];
D[患者自述<br>MedicationStatement] -- 可提供给 --> A;
+

这种设计确保了数据的不可变性与可审计性。每个事件(开立、执行)作为一个独立的资源被记录,通过引用链形成完整的溯源路径。

+
    +
  • 追求完整审计溯源:必须使用 MedicationRequest + MedicationAdministration 的组合。这引入了更高的系统复杂性,但提供了从医嘱到执行的全链路证据。
  • +
  • 记录患者用药史或社区医疗场景:使用 MedicationStatement 更为合适和轻量。它牺牲了与具体执行事件的强关联,但能更灵活地捕获患者陈述或汇总的用药信息。
  • +
  • 一个常见错误是试图用一个 MedicationStatement 来同时扮演“医嘱”和“执行记录”的角色。这会破坏数据模型,导致无法区分“医嘱内容”、“实际执行情况”和“患者陈述”,在出现用药差错时无法进行有效溯源。
  • +
+

示例:记录一次门诊处方及取药

+
    +
  1. 医生开处方:创建 MedicationRequest,状态为 active,包含药品、用法用量、开立时间。
  2. +
  3. 药师发药:(若需记录发药行为)可创建 MedicationDispense 资源(另一个相关资源),记录发药时间、数量,并通过 .basedOn 引用上述 MedicationRequest。
  4. +
  5. 患者回家服药:此事件通常不在临床系统直接记录。但患者复诊时,可自述“我按处方吃了药”,此时可创建一条来源为 patient-reported 的 MedicationStatement,通过 .derivedFrom 关联到最初的 MedicationRequest,表明此陈述源于该处方。
  6. +
+ +
+ + + + + +
+ + + + + + + +
+ + +
+
+
+ + + +
+ + +
+
+
+
+
+
+ +
+
+
+
+
+
+
+
+
+ + + + + + + + + diff --git "a/2025/12/29/TSOPT-\346\243\200\346\237\245/index.html" "b/2025/12/29/TSOPT-\346\243\200\346\237\245/index.html" new file mode 100644 index 00000000..f0648301 --- /dev/null +++ "b/2025/12/29/TSOPT-\346\243\200\346\237\245/index.html" @@ -0,0 +1,295 @@ + + + + + + + + + + + + + + + + + + + + + + + + TSOPT 检查 | + 暮秋小屋 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+ +
+ +
+
+
+ + + +
+
+
+ +
+
+
+ + +
+ +
+ +
+ +
+
+
+

T-SPOT检查,其全称为T-SPOT.TB,是一种用于检测结核分枝杆菌感染的体外诊断血液检测技术。该方法属于一类被称为γ-干扰素释放试验(Interferon Gamma Release Assay, IGRA)的检测手段,旨在辅助医生诊断个体是否存在结核菌感染,包括活动性结核病和潜伏性结-核感染。此项检测并非直接寻找病原体,而是通过评估人体免疫系统对结核菌特定抗原的反应来做出间接判断,因此,其结果需要结合临床风险评估、影像学检查及其他医疗诊断信息进行综合解读。

+

该检测的核心原理在于测量外周血中效应T淋巴细胞的功能。具体而言,检测过程中会分离患者血液中的单个核细胞,并在体外用两种结核分枝杆菌特异性抗原——早期分泌性抗原靶6(ESAT-6)和培养滤液蛋白10(CFP-10)——对其进行刺激。这两种蛋白由结核分枝杆菌表达,但绝大多数非结核分枝杆菌以及目前使用的所有卡介苗(BCG疫苗)菌株均不表达,这使得T-SPOT.TB检测相比于传统的结核菌素皮肤试验(TST)具有更高的特异性,能有效避免因卡介苗接种史或大多数非结核分枝杆菌感染而导致的假阳性结果。

+

如果受检者的免疫系统曾经接触过结核分枝杆菌,其血液中会存在能够识别这些特异性抗原的效应T细胞。当这些T细胞在体外再次遇到ESAT-6和CFP-10时,会被激活并释放γ-干扰素(IFN-γ)。T-SPOT.TB检测利用一种名为酶联免疫斑点(ELISPOT)的技术,在微孔板中捕获并可视化这些由单个T细胞释放的γ-干扰素,形成可见的“斑点”。通过计数这些斑点的数量,可以量化对结核菌抗原敏感的T细胞的丰度,从而判断免疫系统是否对结核菌存在记忆反应。

+

检测结果通常以阳性、阴性或临界(可疑)的形式报告。阳性结果表明受检者很可能感染了结核分枝杆菌;阴性结果则意味着未检测到对结核菌的免疫反应,提示可能没有感染;而临界结果则表示无法明确判断,可能建议重新进行检测或结合其他诊断方法进一步评估。由于其操作的标准化和对特定抗原的依赖,T-SPOT.TB被认为是一种重要的结核病辅助诊断工具,尤其适用于那些因免疫抑制状态(如HIV感染者或长期使用免疫抑制剂的患者)而导致结核菌素皮肤试验结果不可靠的人群。

+

参考文献

+ +
+ + + + + +
+ + + + + + + +
+ + +
+
+
+ + + +
+ + +
+
+
+
+
+
+ +
+
+
+
+
+
+
+
+
+ + + + + + + + + -- cgit v1.2.3