4. 医疗设备数据需求分析与领域界定

在医疗设备数据语义建模工程中，需求分析不是简单罗列“设备有哪些字段”，而是要把不同来源的诉求翻译成可被本体、术语和约束表达的语义需求。临床场景关心的是“此刻这台设备对这位患者意味着什么”，设备运维关心的是“设备处于什么状态、何时需要干预”，监管上报关心的是“数据能否按统一口径追溯到人、机、时、事”。这三类诉求往往使用同一批原始数据，却对语义粒度、时间基准和标识体系提出不同要求。因此，本节的核心任务是：从三类场景中抽取语义需求，划定领域边界，并制定可复用的建模策略。

一、三类场景的语义需求提取

临床场景的语义需求通常围绕“患者—设备—测量—结论”展开。以重症监护中的呼吸机为例，临床不仅需要PEEP、潮气量、吸气压力等参数值，还需要知道这些值属于哪次通气模式、作用于哪位患者、在哪个时间窗内有效。语义需求可表达为：一次机械通气事件必须关联患者标识、设备标识、通气模式、参数集合与时间区间。如果只记录数值而不记录模式，后续就无法判断潮气量 450 mL是容量控制还是压力控制下的结果。

设备运维的语义需求则偏向“状态—事件—处置”。例如输液泵的运维数据包括运行状态、阻塞报警、电池电量、累计运行时长、最近一次校准时间。语义上需要区分瞬时状态（如当前流速）与累积状态（如累计运行小时），并明确报警事件与处置动作之间的因果链。运维场景还要求设备标识在全生命周期内稳定，不能因科室调拨而改变，否则历史故障记录会断裂。

监管上报的语义需求强调“可追溯、可聚合、可交换”。以不良事件上报为例，监管机构需要知道事件类型、涉及设备、患者伤害程度、发生时间、报告机构，并希望不同厂商的设备数据能映射到同一套术语。这里的关键语义需求是标识唯一性、时间标准化和术语可映射。例如“设备故障”在厂商日志中可能写作E-102，在上报系统中必须映射为监管术语集中的“设备失效—治疗延迟”。

二、领域边界的划定方法

领域边界不是按科室或设备型号划分，而是按“语义自治”划分。一个合理的边界应满足：边界内的概念有稳定的定义和关系，边界之间的交互通过明确定义的接口完成。对于医疗设备数据，建议划分为四个域：设备域（设备标识、型号、通道、状态）、患者域（患者标识、人口学信息、临床事件）、事件域（报警、治疗、运维、上报事件）、术语域（编码系统、映射规则、版本）。

划定边界时，可用“三问法”检验：第一，这个概念是否在多个场景中反复出现且含义一致？若是，放入核心域。第二，这个概念是否只在某一场景中有意义？若是，放入场景扩展。第三，这个概念是否来自外部标准且需要版本管理？若是，放入术语域并建立映射。例如，设备序列号在临床、运维、监管中都出现且含义一致，应放入设备域核心；通气模式主要服务于临床，可作为临床场景扩展；不良事件类型来自监管术语集，应放入术语域并保留版本号。

三、复用策略与落地示例

复用策略的核心是“一次定义、多处映射”。具体做法包括：建立核心本体，定义设备、患者、事件、测量四类顶层实体；为每类场景建立扩展剖面，只增加该场景特有的属性；为外部系统建立映射适配器，把厂商私有编码转换为标准术语。以下是一个可参考的语义需求登记表示例，用于把三类场景的诉求落到可建模的条目上。

四、从需求到边界的关键判断

实际工作中，最容易出现的问题是把“数据字段”直接当成“语义需求”。例如，看到设备日志里有FlowRate，就认为需求是“记录流速”。但真正的语义需求可能是“在输液事件中，流速必须与处方剂量、患者体重和时间窗共同解释”。前者是字段，后者才是语义。判断方法是：如果去掉上下文后该字段仍然可独立理解，它可能是核心属性；如果必须依赖场景才能解释，它就需要进入场景扩展或事件模型。

另一个关键判断是时间基准。临床场景常使用“事件发生时间”，运维场景常使用“设备本地时间”，监管上报要求“标准化UTC时间”。在领域边界中，应把时间基准作为独立维度管理，而不是混在业务字段里。建议在核心本体中定义时间戳实体，包含原始时间、时区、标准化时间和时间来源四个属性，各场景按需引用。