yelan
8c70f01e2e
原型 V10.2 的 needConfirm：检验 / 基因检测 / 自费类文书要求患者签完之后 由科室再复核签章，避免漏签补签。此前仓库完全没有这个节点，现在补全。 状态模型 - SigningTaskStatus 增加 confirming（待科室确认），BackendSigningTaskStatus 增加 WAITING_CONFIRM；文档侧 DocumentRecord / TemplateResponseDto / SigningTemplate / CreateSigningTaskInput 增加 needConfirm。 - normalizeTaskStatus、mapSigningTask、mapDocument、toBackendTaskQuery 的 statusMap、 mapAvailableTemplate、readLocalSigningTemplates 同步；needConfirm 取不到一律按 false， 不凭空给任务多插一道人工节点。 流转 - completeSigningTask 按 needConfirm 决定落 confirming 还是 signed； 新增 confirmDepartmentSigning（科室复核签章 → 已签署）。 真实模式暂未接入（后端要重做），如实提示"待接入"，不前端自己改状态。 - 任务事件与记录页事件补「已推送至 X 确认队列」「科室复核签章完成，文档归档」两条留痕。 工作台 - 列表徽标走 .task-status--confirming（原型 tg-cfm 橙），状态筛选加「待科室确认」。 - 详情动作按原型给：🏛 科室复核签章（确认完成）+ 催办 + 在线预览 + 下载已签 PDF； 该状态下不给「作废」（原型只在待签署/已超时给）。 - 新增「科室确认节点」卡（待患者签署后 / 待科室确认 / ✓ 已确认三分支）—— 原型放在文书签名区那一格，这里做成紧跟文书的独立卡，真实模板与回退纸样都能显示。 - confirming 时文书只读（患者已签完，不该再改填写项）。 - 签署完成提示语按 needConfirm 分流：需科室确认的说「已流转至科室确认节点」， 否则说「签署完成，文档已归档」—— 一律说"完成"会让人以为可以关页面了。 - 新增权限码 sign:task:confirm / sign:task:remind。 记录查询与报表 - 记录查询状态筛选与演示数据加该状态（2 条样本）。 - 报表 STATUS_LABELS / STATUS_COLUMNS / ReportStatusCounts / ReportGroupRow 加这一栏， 单独成列不并进「已签署」——并进去会让已签署虚高，科室复核本来就是这类文书的卡点。 - 时效样本按「有签署用时」取，待科室确认同样计入；总览统计块加一块。 演示数据 - 工作台补 task-009（confirming + needConfirm），否则该状态的徽标、动作、 筛选、报表栏在演示环境里一次都走不到。 - 注意：演示文库的麻精同意书**没有** needConfirm（原型里也确实没有）， 所以「新建任务 → 签署 → 落待科室确认」这条流转靠探针夹具验证，没有改产品种子。 验证：probe-dept-confirm.cjs（新建）36/36 PASS，含真实落笔签署后落待科室确认； 回归 probe-new-task 104/104、probe-method-domain 14/14、probe-workbench-lib 42/42、 probe-report-analytics 92/92（断言按七状态更新）；vue-tsc 与 eslint 0 错。
medical-sign
医签通（医疗知情同意电子签署平台）前端项目。
当前状态
已完成两个 Vite 应用的基础初始化、ESLint + Prettier 工程化配置，以及第一版业务页面骨架：
clinical-web：医护端布局、工作台、签署任务、文书库、报表和设置页面；patient-h5：签署入口、文书确认、签署人信息、手写签名和结果页面；- 默认仍使用演示数据，但医护端已按 MEDISIGN 接口文档接入登录、患者/就诊、模板、签署任务、文件产物、投递、用户组织和模板权限等真实接口；患者 H5 已接入一次性 Token 消费和签名上传请求；
packages目录暂时保留，等接口和公共类型稳定后再接入共享包。
项目定位
医签通用于管理医疗知情同意文书的生成、签署、回传、校验和审计，核心对象是：
患者 + 就诊 + 医嘱/项目 + 签署任务 + 文书版本 + 签署证据
目标流程：
医生在电子病历中发起
→ 患者或家属通过手机 H5 / 现场签字板签署
→ 医签通保存签署证据
→ 结果回传电子病历
→ 收费、检查或治疗前校验
目录结构
medical-sign/
├─ clinical-web/ 医护端、电子病历嵌入端和管理功能
├─ patient-h5/ 患者/家属手机签署端
└─ packages/
├─ api-client/ 公共接口客户端
└─ types/ 公共 TypeScript 类型
前端规划
clinical-web
面向医生、护士和系统管理人员，电脑端优先，后续可适配医院平板。
计划包含：
- 电子病历嵌入入口；
- 患者、就诊和医嘱关联；
- 签署任务创建和查询；
- 手机签署和签字板签署；
- 文书模板、版本、权限和报表；
- 签署结果回传及异常处理。
patient-h5
面向患者和家属的手机网页，不是完整的移动版电子病历。
计划包含：
- 短信/二维码打开；
- 身份和签署人关系确认；
- 阅读知情同意文书；
- 勾选同意/不同意项目；
- 手写签名和提交；
- 成功、过期、拒签和异常状态展示。
packages
存放两个前端共同使用的类型、接口和基础逻辑，不单独部署。
技术栈规划
- 医护端：Vue 3 + TypeScript + Vite + Vue Router + Pinia + Element Plus + Axios；
- 患者端：Vue 3 + TypeScript + Vite + Vue Router + Axios，移动端先使用原生 Canvas 完成签名演示；
- 接口数据：先通过 Axios 封装请求，接口稳定后再评估 OpenAPI 类型生成；
- 服务端数据：医护端后续再评估 TanStack Vue Query；
- 测试：待最小业务闭环稳定后再补充 Vitest + Playwright。
开发原则
- 签署任务必须尽量关联具体就诊和医嘱/项目；
- 解释医生、实际签署人和协助操作人员需要分别记录；
- 术中新增处置应创建追加签署任务，不修改已签署文书；
- 文书版本、签署时间、签署渠道和文档哈希必须可追溯；
- 前端不负责最终权限和签署有效性判断，后端必须重新校验；
- 患者 H5 不在 URL 中暴露身份证号、完整病历等敏感信息。
构建与部署规划
两个应用分别构建为 dist：
clinical-web/dist/ → 医护端网页
patient-h5/dist/ → 患者手机签署网页
packages 中被使用的代码会在构建时打包进对应应用。生产环境不需要部署 node_modules 或 packages 源码。
两个应用的构建资源名都会包含构建 ID 和内容哈希。构建 ID 默认使用当前毫秒时间戳，确保连续发布不会复用同名 JS/CSS；CI 可通过 BUILD_ID（例如流水线编号或提交短 SHA）显式指定。生产 Nginx 应对 index.html 使用 Cache-Control: no-cache，对带构建 ID 的 /assets/ 文件使用长期缓存。
医护端通常部署在医院内网；患者 H5 如果需要院外访问，应通过医院安全网关、DMZ 或反向代理提供服务。
后续工作
- 用真实调研结果校准页面字段、状态和角色权限；
- 完成“医护端发起 → 患者 H5 签署 → 结果回传”的最小闭环；
- 再接入
packages中的公共类型和接口客户端； - 验证电子病历 iframe、单点登录和签字板调用；
- 补充收费拦截、动态补签和急诊例外流程。