本项目是专为医院MDT（多学科会诊）场景设计的一套结构化归档系统，解决临床中「意见散在、追溯困难、归档无据」的共性痛点。我们不做大而全的HIS替代，只聚焦一件事：把原本写在纸面、微信对话或零散病程记录里的会诊意见，变成可录入、可版本化、可按患者拉出完整时间线、可生成签字存档清单的结构化数据。系统以Web应用形态交付，前端用原生HTML/CSS/JS实现跨终端适配，后端基于Express.js提供RESTful API，底层采用SQLite单文件数据库，无需DBA、不依赖外部服务、开箱即用。核心能力包括科室/意见类型/依据/医生/时间戳五维结构化录入、每次修改自动存档版本、患者粒度时间轴可视化、支持筛选导出的搜索模块，以及直连EMR所需的CSV/JSON导出与API对接能力。
定位与能力范围
我们明确划清边界：这不是一个排班系统，不调度专家时间；不是电子病历本身，不替代医嘱书写；也不是BI看板，不作统计分析。它只做三件事，录得准、查得清、交得稳。
- 「录得准」：通过表单强制约束关键字段（如意见类型限定为诊断/治疗/其他），避免自由文本导致后续无法归类；
- 「查得清」：支持按患者ID、科室、意见类型、关键词、时间段任意组合检索，每条意见自带创建/更新/删除时间戳与操作人痕迹；
- 「交得稳」：生成带患者基本信息、各科意见摘要、签署栏的归档清单页，格式兼容医院现有打印存档流程，并可通过API与院内EMR系统对接。
这套逻辑源自对真实MDT场景的观察：一次肿瘤患者的会诊，可能经历影像科初判、病理科补充、放疗科评估、外科手术建议、内科药物方案五轮反馈，中间有修订、有否决、有时效性要求。传统方式靠人工整理会议纪要，极易遗漏版本差异或责任归属。而本系统让每一次表达都成为可定位、可比对、可引用的数据节点。
核心功能详解
所有功能围绕「患者」这一中心实体展开，界面导航清晰对应四大主入口：
功能模块 | 关键动作 | 输出形态 | 适用角色 |
|---|---|---|---|
录入意见 | 填写患者ID/姓名、选择科室与意见类型、输入内容与依据、提交 | 数据库新增记录，自动生成版本号 | 会诊秘书、主治医师、信息科录入员 |
时间轴 | 输入患者ID，点击查询 | 按时间倒序排列的意见卡片流，含科室标识、意见类型标签、医生署名、原始时间戳 | 主任医师、质控员、病案管理员 |
归档清单 | 输入患者ID，点击生成 | 单页PDF友好型HTML，含患者头信息、分科室意见汇总、空白签署栏 | 病案室、医务科、法律事务岗 |
搜索查询 | 输入关键词，或勾选科室/意见类型/日期范围 | 分页表格列表，支持点击查看详情与历史版本 | 科研人员、随访护士、医保审核员 |
特别说明：所有意见均默认启用软删除（deleted_at字段标记），删除操作可逆；每次更新自动写入mdt_opinion_versions表，保留全部历史快照；时间轴页面展示的是“有效状态下的最新意见”，但点击任一条目即可展开其完整版本树。
使用与配置流程
系统无需复杂部署，本地启动仅需四步，全程命令行可控：
进入项目目录
cd mdt-archiver安装依赖
npm install初始化数据库（首次运行必执行）
npm run init-db启动服务
npm run dev浏览器访问 http://localhost:3000 即可使用。若需快速体验，运行npm run seed可注入模拟患者与多轮会诊意见数据。
配置通过.env文件管理，关键参数包括：
-PORT：服务端口，默认3000，冲突时可直接修改；
-DATABASE_PATH：SQLite数据库路径，默认指向data/mdt.db，确保该目录存在且有读写权限；
-NODE_ENV：设为production时启用更严格的日志与错误处理策略。
工程结构与技术选型
我们坚持「够用、可控、易维护」原则进行技术决策：
为什么选SQLite而非MySQL/PostgreSQL？
医院MDT数据规模天然受限（单院年均会诊量通常在千至万级），SQLite单文件存储免运维、零配置、ACID可靠，且better-sqlite3支持同步API，规避Node.js异步I/O在医疗场景下可能引发的时序错乱风险。为什么用Express.js而非Next.js/Nuxt？
需求明确为CRUD+静态展示，无SSR或复杂路由嵌套，Express轻量直接，中间件（如validator.js校验入参、errorHandler.js统一封装错误响应）可精准控制每一处HTTP行为，便于后续对接院内统一认证网关。为什么前端不用React/Vue？
基层医院信息科常需现场快速调试，原生HTML/CSS/JS无构建步骤、无包依赖、可直接编辑public/html/下文件生效，降低一线人员介入门槛；同时保障在老旧Windows终端IE11兼容模式下基础功能可用。
整个代码结构按关注点分离：models/封装数据访问逻辑，routes/定义API契约，middleware/处理横切关注点，public/存放纯前端资源，db/集中管理建表与初始化脚本。
数据模型与扩展性
数据库共三张表，严格遵循「患者-意见-版本」三层关系：
mdt_patients：仅存患者ID与姓名，作为外键被意见表引用，避免冗余存储；
mdt_opinions：主业务表，每条记录代表某次会诊中某一科室的正式意见，含软删除标记；
mdt_opinion_versions：独立版本表，不与主表耦合，支持无限次修订追溯。
这种设计带来两个确定性优势：
1.归档清单可稳定生成：因患者与意见关系清晰，清单页能准确聚合同一患者所有有效意见，不因后续新增意见而改变历史快照；
2.API可平滑扩展：如未来需增加「会诊结论」字段，只需在mdt_opinions加列并更新Opinion.js模型，前端表单与API文档同步调整，不影响存量数据结构。
环境与运行保障
系统最低运行要求明确且宽松：
依赖项 | 版本要求 | 说明 |
|---|---|---|
Node.js | >= 16.x | 兼容主流LTS版本，避免V8引擎特性兼容问题 |
npm | >= 8.x | 确保 |
浏览器 | Chrome/Firefox/Edge 最新版，或 IE11 兼容模式 | 前端未使用ES2022+语法，CSS采用Flex布局降级方案 |
常见问题处理方式已在项目内置闭环：
- 数据库初始化失败 → 检查data/目录是否存在且有写权限；
- 端口占用 → 修改.env中PORT值后重启；
- 意见类型枚举值 → 仅支持DIAGNOSIS（诊断）、TREATMENT（治疗）、OTHER（其他），前端下拉菜单硬编码，杜绝非法输入。
限制与说明
我们坦诚说明当前边界：
- 不支持用户权限分级（如仅科主任可删意见），所有操作默认由具备服务器登录权限的人员执行；
- 不内置消息通知，但提供/api/health健康检查端点，便于纳入医院统一监控平台；
- 不提供SaaS托管服务，全部代码与数据自主掌控，符合《医疗卫生机构信息安全管理办法》对敏感医疗数据本地化存储的要求；
- 导出功能（CSV/JSON）仅按查询条件导出，不支持全库一键导出，防止误操作泄露批量患者信息。
所有字段含义、API调用示例、错误码定义均在项目文档中逐条说明，无隐藏约定。
项目地址：
https://github.com/nexorin9/mdt-archiver
