4. 设备接口与通信协议解析

数字临床试验设备接入的难点，往往不在“能不能连上”，而在“连上之后数据能不能被正确理解、被合规地传递、被系统稳定地消费”。同一台电子血压计，可能通过串口输出十六进制帧，也可能通过蓝牙 GATT 特征值推送 JSON；同一份实验室检验结果，可能以 HL7 v2 的竖线分隔消息到达，也可能以 FHIR Observation 资源被查询。接口与协议解析要解决的，就是把这些差异收敛成可校验、可追溯、可映射的数据流。

一、先分清“物理接口”和“应用协议”

串口、USB、蓝牙、Wi-Fi 属于承载层或链路层，决定“用什么介质、什么连接方式传”；MQTT、HTTP、HL7、FHIR 属于应用层或数据交换层，决定“传什么格式、按什么语义解释”。选型时不能只看接口，例如蓝牙只是通道，真正决定解析难度的是它上面跑的是自定义二进制帧、JSON，还是标准 GATT 服务。反过来，Wi-Fi 上既可以跑 HTTP 轮询，也可以跑 MQTT 长连接，二者在时延、功耗、服务端压力上完全不同。

二、串口与 USB：最“原始”也最需要协议文档

串口（RS-232/RS-485）常见于监护仪、输液泵、部分肺功能仪。它只提供字节流，没有消息边界，因此必须依赖设备厂商的通信协议文档来切帧。典型帧结构为：帧头（如 0x02）、长度、命令字、数据域、校验（和校验或 CRC16）、帧尾（如 0x03）。例如某血压计返回 02 0A 01 78 00 78 00 50 03，其中 0x78 表示收缩压 120 mmHg，0x50 表示舒张压 80 mmHg，校验为前若干字节之和取低八位。解析时必须先按帧头帧尾切分，再校验，再按字节序（大端/小端）还原数值，最后做单位确认——有的设备输出 kPa，需要乘以 7.5006 转为 mmHg。

USB 则分两类：一类是 USB 转串口（CDC-ACM），本质仍是串口协议；另一类是 USB HID 或厂商自定义驱动，需要按报告描述符解析。实操中优先选择 CDC-ACM，因为它跨平台、免驱、可用标准串口库读取；若设备只提供 HID，则需按报告 ID 和字段偏移解析，且要注意不同操作系统对 HID 报告的封装差异。

三、蓝牙与 Wi-Fi：连接管理比解析更棘手

BLE 设备通常以 GATT 服务暴露数据。以标准血压服务 0x1810 为例，收缩压、舒张压、平均压位于同一特征值中，前 7 字节为标志位、单位、读数，后续为时间戳。订阅时先使能通知（写 CCCD 为 0x0100），再接收 notify。常见坑是：设备在断开后缓存数据，重连时批量补发，若网关只按实时流处理，会丢失历史点。因此 BLE 适配层要支持“补发识别”和去重。

Wi-Fi 设备功耗高但带宽大，适合影像、连续波形或高频生命体征。它上面可以跑 MQTT：设备作为 publisher 向 devices/{deviceId}/vitals 发布 JSON，QoS 设为 1 保证至少一次；网关订阅后写入队列。MQTT 的优势是长连接、低开销、支持断线重连和遗嘱消息，适合大量设备并发。HTTP 则更适合请求-响应式场景，如设备主动 POST 一条测量结果，或平台按需 GET 设备状态。HTTP 实现简单、易调试，但轮询会产生空请求，长连接又不如 MQTT 轻量。

四、HL7 与 FHIR：临床语义层的两种范式

HL7 v2 是医院内部广泛使用的消息标准，以竖线分隔、段为行。例如一条 ORU^R01 检验结果消息：

MSH|^~\&|LIS|HOSP|EMR|HOSP|202405121030||ORU^R01|MSG0001|P|2.5
PID|1||P12345||张三||19800101|M
OBR|1|||GLU^血糖^L
OBX|1|NM|GLU^血糖^L||5.6|mmol/L|3.9-6.1|N|||F

解析要点：MSH 定义分隔符和消息类型；PID 提供患者标识；OBX 是观察结果，第 5 字段为值，第 6 字段为单位，第 7 字段为参考范围。HL7 v2 的难点在于版本差异、可选字段、Z 段扩展和编码字符集。适配时通常用接口引擎做消息路由和字段映射，而不是手写解析器。

FHIR 则是基于 REST 的资源模型，用 JSON 或 XML 表达。同一条血糖结果可表示为 Observation 资源：code 使用 LOINC 2339-0，valueQuantity 为 5.6 mmol/L，subject 指向 Patient/P12345，effectiveDateTime 记录测量时间。FHIR 的优势是语义明确、可查询、可扩展，适合科研平台和跨系统交换；代价是资源结构较深，需要处理引用、版本和搜索参数。选型上，院内实时消息优先 HL7 v2，跨机构、科研、移动端优先 FHIR。

五、选型与适配的落地判断

实际工程中很少“只选一种”。更常见的做法是：设备侧按能力选择串口、BLE 或 Wi-Fi；网关侧统一转换为内部事件模型；平台侧再按消费方需要输出 HL7 或 FHIR。判断依据可以归纳为四条：数据实时性要求、设备资源约束、目标系统接口能力、合规审计要求。若设备只能串口输出且无网络，就用串口转网关；若设备支持 BLE 但需要长时间连续监测，则评估 Wi-Fi 或网关中转；若接收方是医院 EHR，优先 HL7 v2；若接收方是科研数据平台，优先 FHIR。

最后要强调：协议解析的产出不是“解析成功”四个字，而是一条带有设备标识、患者标识、测量时间、原始值、标准单位、标准编码和校验状态的结构化记录。只有这条记录能被下游系统稳定消费，设备接入才算真正完成。