DOI:10.3969/j.issn.1673-6036.2025.09.011
中图分类号:R-05;|TP311.13
面向智能辅助诊疗模式的神经重症监护数据库建设研究
兰蓝1， 黄楷文1， 王鑫1， 刘丽萍2， 聂曦明2， 杨谨旭2， 李岳3， 李瑞1
| 【作者机构】 | 1首都医科大学附属北京天坛医院信息管理与数据中心； 2首都医科大学附属北京天坛医院神经病学中心神经重症医学科； 3北京万丰铭悦医疗科技有限公司 |
| 【分 类 号】 | R-05;TP311.13 |
| 【基 金】 | 国家自然科学基金资助项目(项目编号：72204169) 北京市属医院科研培育项目(项目编号：PG2025007) 首都医科大学附属天坛医院资助项目(项目编号：TYGL202501)。 |
全文
文内图表
参考文献
出版信息
•医学信息技术•
面向智能辅助诊疗模式的神经重症监护数据库建设研究
1 引言
随着医疗数字化的发展，医疗专病数据库已成为提升诊疗水平的重要工具[1]。国务院办公厅《关于促进和规范健康医疗大数据应用发展的指导意见》提出要依托现有资源建设一批心脑血管等临床医学数据示范中心，构建临床决策支持系统。近年来，医疗数据库技术取得重要进展。例如，混合数据库可高效管理化验单和影像图片等不同类型数据[2]；人工智能技术可快速解析病历文本，实现精确短语提取和语义消歧[3]；有研究[4]建立神经胶质瘤专病科研数据库，用以支持科研。在神经重症监护领域，患者病情变化快、数据种类多(如生理指标、脑电波形、心电波形等)[5-7]，因此神经重症辅助诊疗相关系统建设要求能快速处理实时监测数据，以准确预测病情风险。然而现有研究多集中于回顾性数据，无法满足需求。本研究基于国家神经疾病医学中心(首都医科大学附属北京天坛医院)的现实情况，结合神经重症监护场景的临床需求和数据特点进行需求分析，通过完善环境配置、逻辑设计和物理设计，完成数据库搭建，以提升实时数据处理速度，满足智能辅助诊疗模式需求。
2 数据库需求分析与对应系统架构设计
2.1 数据需求
基于神经重症临床诊疗场景的特殊性，开展多轮深度需求调研与跨领域论证，从临床需求、技术可行性、合规性3个维度进行需求分析，明确数据库纳入现有数据接口，包括医院信息系统(hospital information system，HIS)的基础数据以及床旁监护仪数据，为后续统计、分析及展示提供数据支撑的同时，保证数据完整性。
2.2 数据采集需求
依托以下软硬件设备及设置满足不同数据的存取需求。一是在网络基础设施方面，使用高质量网络硬件和足够的带宽，保证数据传输的稳定性和速度。二是选用响应速度快、精度高的传感器，确保准确捕捉设备状态变化。三是选取高效的数据传输协议，采用适合物联网环境的轻量级通信协议(如WebSocket)，此类协议具有较低的开销和延迟，较适用于资源受限的设备。四是采用批量传输与压缩技术，合理安排数据发送频率，利用数据压缩技术减少传输量，提高传输效率。五是建立数据保障机制，当网络条件不佳无法立即上传数据时，可以在本地暂时存储数据，待网络恢复后再同步至云端或其他数据中心；同时，设计合理的智能重试逻辑，遇到短暂网络故障时自动重试。六是定期维护与监控，对整个数据采集系统定期进行健康检查，包括硬件状态、软件版本更新、网络性能评估等，消除潜在问题。
2.3 系统建设需求与对应技术架构设计
2.3.1 系统建设需求 为支持智能辅助诊疗系统，整体架构须集成数据采集分析、算法研究与临床辅助诊疗等功能。在便利临床治疗的同时，满足数据闭环检验和优化算法分析的需求。
2.3.2 系统与数据库技术架构设计 整体应用系统架构设计分为5个基础层级。(1)基础层。作为整个系统的根基，主要负责硬件和网络基础建设。(2)应用数据层。集中管理系统所有数据资源。(3)应用支撑层。作为连接前后端的重要桥梁，主要整合各类技术服务模块。(4)应用管理层。是直接面向业务需求的功能实现层。(5)交互层。负责向用户提供交互界面。数据库建设工作主要集中在应用数据层，该层流程，见图1。通过使用标准接口、非结构化资源整合模板、抽取转换加载(extraction-transformation-loading，ETL)工具，从床旁监护仪等设备采集数据，从而将非结构化数据、相关业务系统中的数据和关系型数据资源进行整理并统一存储。存储分为结构化资源(包括患者基本信息和患者体征监护信息等)和非结构化资源(包括患者波形监护信息等)。
图1 应用数据层流程
2.3.3 数据融合设计 ETL工具从不同数据源提取数据，进行清洗、转换和整合，然后加载到目标数据仓库中，满足快速连接、高效融合各种数据、灵活进行数据开发的需求。数据清理策略如下。(1)空值约束。过滤、清除数据库主键空值。(2)合理去重。通过床号、病案流水号等数据字段进行去重。(3)类型转换。字段列空值统一转换，时间数据转换为日期数据类型。(4)异常值处理。重点关注血压值的异常值处理。(5)数据脱敏。对患者姓名、身份证号等进行脱敏处理。
3 关键模块实现
3.1 系统接口信息
3.1.1 患者基本信息 系统提供多接口对接方案。系统核心访问接口基于WebService架构提供服务，通过医院内部网络访问指定安全地址完成身份认证后调用接口。核心功能包含3个标准化服务接口。(1)用于获取服务器标准时间的接口。为终端设备提供精准时间校准基准，确保跨系统业务逻辑的时间同步性。(2)实时对接HIS接口。用于提取神经重症监护室(neurological intensive care unit，NICU)当日全部在床患者的信息列表。(3)按住院号精确查询特定患者在床信息的接口。按照《信息安全技术 健康医疗数据安全指南》相关要求，所有接口通信加密，形成从身份认证、时间校准到数据查询的全链路安全交互体系。
3.1.2 床旁监护信息 针对床旁监护信息提供双模式安全访问通道，通过医院内部网络访问指定安全地址完成身份认证后调用接口，满足不同临床场景的数据交互需求。WebService采用标准请求-响应机制，支持结构化数据高效交互，包含获取全体在床患者实时体征数据(心率、血氧等，字段与监护表同步)、按床号精准查询患者体征，以及提供全体或指定床位患者原始生理波形数据。WebSocket基于全双工技术，适用于高频生理信号持续推送，请求格式为“协议类型|床号”。两类接口均符合《信息安全技术 健康医疗数据安全指南》隐私规范相关要求，兼顾数据完整性、实时性，形成从批量查询到实时监测的重症监护数据交互体系。
3.2 数据库技术架构设计
3.2.1 数据库环境说明 为满足数据库的多种建设需求，综合考虑关系型数据库与非关系型数据库，比较支撑实时业务的常用数据库，选择MySQL、PostgreSQL、MongoDB这3种数据库从不同维度进行比较分析，见表1。PostgreSQL虽然支持复杂查询和地理空间分析，但现有核心需求是保证数据时效性，其简单查询性能较MySQL低，同时缺乏规模化医疗案例验证。MongoDB作为非关系型数据库较为灵活，但并不适用于医疗数据规范要求。在没有模式约束的情况下允许自由增减字段，可能导致数据错误或格式混乱。在面对高度结构化数据(如患者基本信息、监护指标等)时，要严格限定模式以保证数据质量，MySQL比较适配。智能辅助诊疗模式的对接中，以标准化录入和查询为主，MySQL的索引优化和缓存机制在简单查询中表现良好。MySQL在保持高性能的同时，对硬件资源消耗相对较低，还可提供丰富的安全功能，确保数据安全性。同时MySQL作为开源商业化成熟数据库类型，其社区资源丰富、部署简单，国内多家三甲医院核心系统采用MySQL，已有规模化医疗案例作为支撑。在面向智能辅助诊疗模式的数据库选型中，MySQL凭借其稳定性、规范性和性能优势成为更好的选择。因此最终选取MySQL作为数据库系统进行搭建，搭建环境如下。(1)数据库系统。MySQL 8.0能够高效处理大量数据和高并发请求，适用于要处理动态网站和大型数据库的应用。其将数据保存在不同表中，提升系统运行速度和灵活性[8]。(2)数据库部署环境。高性能工作站用于满足初步数据处理和本地AI模型运行需求。(3)数据库设计工具。运用Navicat 10，用户可完成数据库结构的可视化管理，有效降低运维复杂度并保障数据操作的安全性。
表1 3种数据库对比分析
维 度 M y S Q L P o s t g r e S Q L M o n g o D B 数 据 模 型 关 系 型 , 严 格 模 式 关 系 型 , 支 持 J S O N B 等 扩 展 文 档 型 , 无 固 定 模 式 事 务 支 持 A C I D ( I n n o D B ) 成 熟 稳 定 A C I D ( M V C C ) 性 能 略 低 多 文 档 A C I D , 性 能 较 差 读 写 性 能 读 优 化 显 著 , 批 量 插 入 快 复 杂 查 询 强 , 简 单 读 写 略 低 写 入 吞 吐 高 , 读 依 赖 索 引 扩 展 性 垂 直 扩 展 为 主 , 分 表 需 工 具 支 持 插 件 化 水 平 扩 展 原 生 分 片 , 自 动 水 平 扩 展 适 用 场 景 结 构 化 数 据 、 高 并 发 读 复 杂 分 析 、 混 合 数 据 非 结 构 化 数 据 、 高 扩 展 性
3.2.2 数据库逻辑设计 采用实体-关系(E-R)图进行数据库概念结构设计。E-R图提供了表示实体、属性和联系的方法。数据库概念结构设计E-R图，见图2—图4。相关实体通过床号进行匹配和对应。
图2 患者基础信息实体E-R图
图3 患者体征监护信息实体E-R图
图4 患者波形监护信息实体E-R图
3.2.3 数据库物理设计 数据库共包含3个表。一是患者基础信息表：主要用于同步转入NICU在床患者的基本信息，如患者姓名、性别、年龄等，见表2。
表2 患者基础信息表设计
序号 字段名称 字段描述 字段类型 长度 是否 允许空 1 NAME 患者姓名 VARCHAR 20 否 2 SEX 性别 VARCHAR 8 否 3 AGE 年龄 VARCHAR 64 否 4 SICKNAME 疾病诊断 VARCHAR 100 是 5 INNUMBER 入院次数 INT 8 是 6 ROOMID 病区编号 NUMBER 8 是 7 ROOMNAME 病区名称 VARCHAR 20 是 8 BRANCHNAME 科室名称 VARCHAR 50 是 9 BEDNO 床号 VARCHAR 30 否 10 PATIENTID 住院号 VARCHAR 20 否 11 INPATIENTNO 病案流水号 VARCHAR 20 是 12 PATIENTSTATUS 入科状态 VARCHAR 10 是 13 ZKTIME 转科时间 VARCHAR 20 否
字段类型选用可变长度字符串(VARCHAR)和整数类型(INT)。前者用于存储不同长度的数据，指定最大长度后较节省空间；后者用于存储整数值，适用于表格中入院次数字段。此外，允许空代表该种数据为非必填或未知值，可暂存为“NULL”。
二是患者体征监护信息表：通过采集设备和采集服务获取所有在床患者实时监护信息并实时存储，包括采集时间、心率、脉搏、血压等基本监护参数，见表3。该表字段类型还包括日期类型(DATE)，用于存储日期。由于体征监护数据采集并不包括患者基本信息，其依靠对应时间段内的床号进行患者对应。
表3 患者体征监护信息表设计
序号 字段名称 字段描述 字段类型 长度 是否 允许空 1 id 自增加 ID 主键 INT 16 否 2 time 采集时间 DATE 20 否 3 hr 心率 VARCHAR 10 是 4 pr 脉搏 VARCHAR 10 是 5 nibp_ s 无创收缩压 VARCHAR 10 是 6 nibp_ d 无创舒张压 VARCHAR 10 是 7 nibp_ m 无创平均压 VARCHAR 10 是 8 abp_ s 有创收缩压 VARCHAR 10 是 9 abp_ d 有创舒张压 VARCHAR 10 是 10 abp_ m 有创平均压 VARCHAR 10 是 11 rr 呼吸频率 VARCHAR 10 是 12 etco2 呼气末二氧化碳 VARCHAR 10 是 13 cvp 中心静脉压 VARCHAR 10 是 14 t1 体温 1 VARCHAR 10 是 15 t2 体温 2 VARCHAR 10 是 16 bis 脑电双频指数 VARCHAR 10 是 17 spo2 血氧 VARCHAR 10 否 18 bedid 床号 VARCHAR 10 否
三是患者波形监护信息表：通过采集设备和采集服务获取所有在床患者实时波形监护信息并实时存储，包括采集时间、采集通道、波形数据等，见表4。波形监护数据中同样不包括患者基本信息，依赖床号进行患者对应。
表4 患者波形监护信息表设计
序号 字段名称 字段描述 字段类型 长度 是否 允许空 1 id 自增加 ID 主键 INT 16 否 2 time 采集时间 VARCHAR 20 否 3 channel 采集通道 VARCHAR 64 否 4 data 波形数据 VARCHAR 2 000 否 5 count 数据点个数 INT 7 否 6 mdi_ time 设备时间 VARCHAR 20 否 7 bedid 床号 VARCHAR 5 否
3.3 数据库建设结果
截至2025年4月，数据库已采集患者体征数据8 537 042条，波形数据8 854 681条，共计31 948.8 MB，采集频次为10秒。月均数据采集约2 134 260条，约7 987MB。本研究通过标准化工具Spotlight模拟真实负载，生成可对比的性能数据。基于NICU业务运行场景，数据库性能测试结果显示，CPU利用率始终低于30%，C盘每秒写入数0～10 MB，每秒读取数0～3 MB，D盘每秒写入数0～97 MB，每秒读取数0～1 214 MB，每秒处理发送数据包0～1 000个，每秒处理接收数据包100～500个。经过监控和测试系统服务器性能，实时写入性能未达上限，可支持更多床旁采集设备接入，数据库运行良好、稳定。针对临床长期存在的监护仪数据存储瓶颈，如迈瑞中央监护站设备仅支持患者数据10天本地存储，将多台监护仪的生理参数实时同步至数据库，突破硬件限制，实现了每名患者两周及更久的原始数据存储，解决了医生过去无法追踪患者术后长期生理趋势的难题。此外，对比传统人工导出U盘备份的方式，数据调阅时间从平均10分钟缩短至10秒，有效提升医生工作效率。
4 讨论
本研究面向智能辅助诊疗模式构建神经重症监护数据库，与国内外同领域的重症监护室(intensive care unit，ICU)数据库对比来看，在多模态数据、实时数据处理及对智能辅助诊疗系统的兼容性等技术难点方面取得了进展，但仍存在局限性和短板。考虑现有技术进步及数据安全，利用国产数据库进行基础数据库类型替换是未来发展方向。
4.1 国内外相关数据库对比
美国eICU数据库作为多中心数据库代表，覆盖美国208家医院；美国MIMIC-IV数据库数据丰富，包含序贯器官衰竭评分、急性生理与慢性健康评分、影像学资料等；瑞士HiRID分钟级高频率监测数据可有效支持时序分析[9]。国内中南大学湘雅二医院已基于ICU数据库[10]支撑“智慧ICU云平台”，对脓毒症、急性呼吸窘迫综合征等常见危重症进行早期预警；解放军总医院第一医学中心通过整合HIS、电子病历系统、监护信息系统、检验信息系统、放射信息系统构建ICU数据库，并将收集到的数据应用于统计分析和临床研究[11]。
本研究所建数据库较国内外ICU数据库的主要优点在于保证了数据的时效性，可以支持神经重症疾病智能辅助诊疗决策。针对该数据库的不足，未来将通过创建新接口的方式，使用住院号等字段将监护信息与患者基本信息进行自动匹配，减少人工操作可能出现的数据错误和缺失。另外，目前建设的数据库尚未纳入神经系统疾病患者脑电图和临床量表评分等信息。这是因为脑电图机多为进口产品，存在接口限制，而临床量表评分往往不能通过信息系统自动获取，未来拟将这些重要信息纳入数据库。
4.2 国产数据库替代可行性分析
近年来，国产数据库已完成多个行业领域的关键应用替代案例。例如，达梦数据库在水电站管理中体现了优秀的存储、采集和实时监控能力[12]；厦门大学附属医院成功进行了医院信息系统的全流程迁移，采用国产数据库替代Oracle数据库并运行稳定[13]。在数据迁移过程中，通过准备、转换、校验3个阶段，保证稳定性，同时通过建立合适索引等方法，保证迁移后数据库的高性能[14]。基于内存操作的高实时同步方案，缓解数据库难以实时共享同步数据的问题[15]，适用于神经重症领域等高并发场景。在当前国际环境复杂多变的背景下，依赖国外数据库技术可能面临数据泄漏、被监控甚至被篡改的风险，严重威胁国家安全和利益[16]。医疗系统的患者隐私数据和实时诊疗指令安全级别高，MySQL存在潜在供应链风险(如Oracle对MySQL的商业管控)[17]，使用国产数据库更加安全可靠。在医疗关键系统数据库的选取上采用或迁移成国产数据库将成趋势，且已拥有较为成熟的路径，可作为本研究数据库及医院其他信息系统数据库的未来改进方向。
5 结语
本研究围绕神经重症监护领域的临床需求，针对多模态数据管理困境与实时诊疗决策支持的技术挑战，设计并构建面向智能辅助诊疗模式的神经重症监护数据库。通过需求分析、架构设计与关键模块实现，研究取得以下核心结果。一是高效的多模态数据整合能力，MySQL标准化接口设计，实现了对结构化数据(如患者基本信息、体征监护信息)与非结构化数据(如波形信号)的统一存储与高效管理，解决了传统系统数据异构性导致的存取效率低下问题。二是实时数据处理性能优化，基于高性能硬件环境(如多核计算机中央处理器、高速存储设备)与轻量级传输协议(WebSocket)，较好地控制了数据延迟，显著提升了实时监测数据对临床决策的支持效率，满足神经重症监护对时效性的严苛要求。三是智能辅助诊疗的系统兼容性，通过系统服务接口(如患者信息同步、床旁监护数据实时推送)，实现了与医院信息系统的无缝对接，为智能算法(如病情预测模型)提供了高质量的数据输入与闭环验证环境。
作者贡献：兰蓝负责论文撰写；黄楷文负责文献调研；王鑫参与数据库实现；刘丽萍、聂曦明、杨谨旭参与需求分析；李岳参与系统架构设计；李瑞负责研究设计、提供指导。
利益声明：所有作者均声明不存在利益冲突。
1 王耀国，李鹏，刘迷迷，等. 临床专病数据库建设现状与思考[J]. 医学信息学杂志，2024，45(3)：65-69.
2 任明飞，李学军，崔蒙蒙，等. 基于MongoDB的非关系型数据库的设计与开发[J]. 电脑知识与技术：学术版，2019，15(34)：1-2.
3 杨丽冰，郭超，姜会珍，等. 人工智能辅助肺癌数据库构建[J]. 中国胸心血管外科临床杂志，2025，32(2)：167-174.
4 王若茗，凡豪志，张军霞，等. 神经胶质瘤专病科研数据库建设与应用[J]. 中国数字医学，2022，17(4)：12-18.
5 王拥军，李子孝，谷鸿秋，等. 中国卒中报告2020(中文版)(1)[J]. 中国卒中杂志，2022，17 (5)：433-447.
6 QARYOUTI D，GREENE-CHANDOS D. Neurocritical care aspects of ischemic stroke management[J]. Critical care clinics，2023，39(1)：55-70.
7 NEWCOMBE V，MUEHLSCHLEGEL S，SONNEVILLE R. Neurological diseases in intensive care[J]. Intensive care medicine，2023，49(8)：987-990.
8 相景丽. MySQL数据库技术在校园信息管理中的应用研究[J]. 信息记录材料，2025，26(3)：104-106.
9 SAUER C M，DAM T A，CELI L A，et al. Systematic review and comparison of publicly available ICU data sets-a decision guide for clinicians and data scientists[J]. Critical care medicine，2022，50(6)：e581.
10 王谷宜，黎家琦，钟燕军，等. 基于智慧ICU云平台的ARDS集束化管理对ARDS患者临床结局的影响[J]. 中华重症医学电子杂志，2025，11(1)：72-77.
11 齐霜，毛智，胡新，等. 基于专科信息系统建立的重症医学数据库：大型三甲医院重症医学数据库的模式[J]. 中华危重病急救医学，2020，32(6)：743-749.
12 雷若逍，王瑞康，汪帅涛，等. 国产达梦数据库在水电站管理运行中的应用[J]. 水电与新能源，2024，38(12)：58-60.
13 吴业毅，苏良波，黄秋红，等. 基于适配某型国产数据库的医院信息系统改造实践[J]. 中国数字医学，2025，20(2)：46-49.
14 肖驭文. Oracle数据库向国产数据库迁移的技术分析[J]. 信息与电脑(理论版)，2024，36(7)：149-151.
15 姚克，崔宇，何伟栗，等. 高实时国产数据库数据同步共享[J]. 无线互联科技，2025，22(1)：102-107.
16 裴立公. 国产数据库替代国外数据库演化过程分析[J]. 金融科技时代，2023，31(4)：94-97.
17 张智祥，许凌锋，梁洁波. 发展自主可控数据库 筑牢国家安全基石[J]. 中国经济报告，2024(2)：157-163.
Study on the Construction of a Neurological Intensive Care Database for Intelligent Assisted Diagnosis and Treatment
X