核对护理记录时效签名与评估表完整性
30/100
综合分
0
GitHub 星标
—
npm 周下载
—/5
用户评分
数据截至 2026/10/8 · 周下载取自 npm 全网(含 CI / 镜像),非本站安装数;综合分由星标、活跃度与兼容性检查合成。
安装命令 · 需先装 dsh CLI 引擎
dsh plugin --profile web add PerryLink/dsh-nurse-record-check该包不可直接 npm 安装,改从 GitHub 源安装(明细见下方安装检查)
状态速览
判定依据:实装验证 · 静态安装检查 · 自动扫描 · 仓库维护状态信任档位:需留意
是什么
dsh 原生插件 · tool
安全吗
本站尚未对该插件做风险分级
暂未覆盖,不等同于无风险
还在维护吗
活跃:最近一次提交在 27 天前
档位由哪些信号合成
本站实装验证(真实安装 L4 覆盖全站;L5 为运行时冒烟或实机截图,覆盖范围小于 L4) · 验证所用 dsh 版本 · 静态安装检查 · 风险分级 · 仓库维护状态。 下方各区块是它的证据明细。
⚠︎ 实装验证未通过(unknown · 2026/11/4) ——可能是验证环境差异,装前建议到 GitHub 仓库确认最近更新与 issue。
社区实装还没有人打卡 · 装过的第一个就是你
安全扫描自动 · 静态分析源码v2.7.0🟢 扫描:未发现敏感能力尚无人工评估展开查看扫描说明与证据 ↓
安全扫描自动 · 静态分析源码
v2.7.0静态扫描未发现敏感能力:最多只发网络请求、读取自身元数据或只读文件,未发现执行命令、文件写入或敏感信息读取。
扫描于 2026/11/3(1 天前) · 范围 入口闭包 + 发布文件清单 · 来源 GitHub 仓库
静态扫描只反映源码中出现的调用,不构成安全背书;人工评估与自动扫描相互独立、互不覆盖。
依赖的 DSH / Cordis 模块
@deepseek-ai/cordis@deepseek-ai/dsh-package-manifest@deepseek-ai/dsh-tools@deepseek-ai/schemastery给这个插件打分还没有人投票↓
用户评分
还没有人投票,来当第一个
功能亮点
- 核对护理记录时效
- 核对签名
- 核对评估表完整性
护理记录核对:依据《电子病历应用管理规范(试行)》《病历书写基本规范》(国卫办医发〔2017〕8号、卫医政发〔2010〕11号)。仅提示差异,不作出定性结论。
README
由 DeepSeek 最新模型翻译生成dsh-nurse-record-check — 护理记录时效性、签名与评估表完整性检查
dsh-nurse-record-check 读取一次住院过程的机器可读导出数据——护理条目、医嘱和已完成的评估表——检查这份护理记录(护理记录)的时效性、签名与评估表记录,对照引用条款报告字面不符之处:每条护理条目是否留下可追溯的记录人和时间,每个日期和时间是否用 24 小时制书写且可读,抢救记录的时间是否精确到分钟、记录是否在抢救结束后 6 小时内补写完成,临时医嘱是否带有执行时间和执行护士签名、已取消的医嘱是否记录取消信息,首次护理评估和记录频次是否达到机构配置的阈值,跌倒风险和压力性损伤评估表是否在档,巡房间隔是否符合记录所载护理级别对应的分级护理指引。无法运行的检查会列入 skipped,而不是判为通过。
它能回答什么
| 你问 | 它回答 |
| 一条护理条目从病房系统出来时没有签名护士。这会被报告吗? | 会。NR-001 报告每条未留下记录人标识的护理条目,也会报告与配置的员工编号模式不匹配的 nurseId。它检查的是材料是否留下记录人标记和时间,而不是电子签名在技术上如何实现。 |
| 导出数据里有一个时间值无法解析。规则会怎么处理? | NR-002 报告该值,并要求时间用 24 小时制书写、可按 YYYY-MM-DD HH:mm 读取。
展开完整文档(README 剩余 1 节)
dsh-nurse-record-check — 护理记录时效性、签名与评估表完整性检查
dsh-nurse-record-check 读取一次住院过程的机器可读导出数据——护理条目、医嘱和已完成的评估表——检查这份护理记录(护理记录)的时效性、签名与评估表记录,对照引用条款报告字面不符之处:每条护理条目是否留下可追溯的记录人和时间,每个日期和时间是否用 24 小时制书写且可读,抢救记录的时间是否精确到分钟、记录是否在抢救结束后 6 小时内补写完成,临时医嘱是否带有执行时间和执行护士签名、已取消的医嘱是否记录取消信息,首次护理评估和记录频次是否达到机构配置的阈值,跌倒风险和压力性损伤评估表是否在档,巡房间隔是否符合记录所载护理级别对应的分级护理指引。无法运行的检查会列入 skipped,而不是判为通过。
它能回答什么
| 你问 | 它回答 |
| 一条护理条目从病房系统出来时没有签名护士。这会被报告吗? | 会。NR-001 报告每条未留下记录人标识的护理条目,也会报告与配置的员工编号模式不匹配的 nurseId。它检查的是材料是否留下记录人标记和时间,而不是电子签名在技术上如何实现。 |
| 导出数据里有一个时间值无法解析。规则会怎么处理? | NR-002 报告该值,并要求时间用 24 小时制书写、可按 YYYY-MM-DD HH:mm 读取。时间无法解析的记录随后会被排除在后续的时间窗比较之外,所以它会在这里暴露,而不是作为超期问题出现——规则检查的是时间能否读取,而不是时间是否真实。 |
| 我们的抢救记录只给了抢救日期,没有具体时刻。 | NR-003 报告时间只精确到日的 rescue 记录,因为抢救时间必须精确到分钟。该规则包指出,它引用的两份文件要求并不相同——一份要求抢救时间精确到分钟,另一份要求记录时间——于是把两者并列呈现,并分别标注来源。 |
| 抢救记录是第二天早上补写的。这算迟吗? | NR-004 把记录时间与 rescueEndedAt 比较,报告间隔超过 6 小时的情况;在抢救结束前就写好的记录也会被报告。没有 rescueEndedAt 就没有可比对象,检查会报告无法运行,而不是判为通过。 |
| 临时医嘱已执行,但执行护士的签名栏是空的。 | NR-005 报告临时医嘱的执行记录缺少执行时间或执行护士签名。它只适用于临时医嘱——长期医嘱单的内容项不同,不能同样读取——它也不检查执行后多久才签名,因为规则包没有找到签名时限。 |
| 有些规则返回 skipped,而不是通过。这是什么意思? | 意思是检查没有运行,而不是通过了。NR-008 和 NR-012 发布时阈值就是空的(maxAfterAdmission、intervalHours),因为规则包没有找到可适用于护理记录的国家标准阈值——它记录下找到的 24 小时属于医生书写的入院记录,不能套用到首次护理评估——而 NR-011 同样在特级护理下把自己报为 skipped,因为指南没有规定间隔,且可比较的 rounds 条目少于两条。 |
遵循的标准
| 文件 | 编号 | 引用规则 |
| 《电子病历应用管理规范(试行)》 | 国卫办医发〔2017〕8号 | NR-001, NR-006, NR-010 |
| 《病历书写基本规范》 | 卫医政发〔2010〕11号 | NR-002, NR-003, NR-004, NR-005, NR-007, NR-010, NR-012 |
| 《医疗质量安全核心制度要点》 | 国卫医发〔2018〕8号 | NR-003, NR-004 |
| 《卫生部办公厅关于在医疗机构推行表格式护理文书的通知》 | 卫办医政发〔2010〕125号 | NR-005 |
| 《护理分级标准》 | WS/T 431—2023(全部代替 WS/T 431—2013;推荐性卫生行业标准,2024-02-01 施行) | NR-008 |
| 《进一步改善护理服务行动计划(2023—2025年)》 | 国卫医政发〔2023〕16号 | NR-009 |
| 《三级医院评审标准(2020年版)》 | 国卫医发〔2020〕26号 | NR-009 |
| 《综合医院分级护理指导原则(试行)》 | 卫医政发〔2009〕49号 | NR-011 |
边界: 本插件检查住院诊疗过程中的护理文书(护理记录)的及时性、签名和评估表记录。它不是 dsh-medrec-qc(后者检查病案首页及其内部矛盾),不是护理质量评分卡,也不是临床决策辅助。它读取机器可读的导出数据,报告与所引条款的字面不符;它从不判断某次诊疗是否恰当。
兼容性
| 层面 | 状态 |
| Harness | 对等范围 >=0.1.2-rc.1 <0.2.0 \|\| >=0.2.0-0 <0.3.0 —— 已验证同时接受 0.2.0-rc.2 和 0.2.1-alpha.1。engines.dsh 有意不声明:它没有读取方,也无法拒绝宿主 |
| Node | ^22.19.0 || >=24.0.0 |
| 平台 | 全部(纯 ESM;无原生代码、无网络、无模型调用) |
| 工具模式 | 在 native、ptc 和 both 下均可工作;对于一批诊疗过程,用 ptc 只付一次 schema 成本 |
它做什么
注册 nurse_record_check 工具。它读取一个患者的诊疗过程——护理条目、医嘱和评估表——应用版本化的规则包,返回报告,其中每条发现都指明它来自哪条条款。
| 规则 | 检查 | 严重级别 |
| NR-001 | 每条护理条目都带有可追溯的记录者(id 和时间) | error |
| NR-002 | 材料里每个日期/时间都写成 24 小时制,且可读 | error |
| NR-003 | 抢救记录时间精确到分钟 | error |
| NR-004 | 抢救结束后 6 小时内完成抢救记录 | error |
| NR-005 | 临时医嘱带有执行时间和执行护士签名 | error |
| NR-006 | 执行时间不早于医嘱下达时间 | info |
| NR-007 | 已取消的医嘱记录取消信息和签名 | error |
| NR-008 | 首次护理评估符合本地配置的时间窗 | info |
| NR-009 | 跌倒风险和压力性损伤表单已归档 | warn |
| NR-010 | 记录的时间戳不早于它所记录的事件 | info |
| NR-011 | 巡视间隔符合该护理级别的分级护理指引 | error |
| NR-012 | 记录频次符合本地配置的策略 | info |
有两条规则故意不预置配置,因为国家层面没有对应阈值。它们会在 skipped 里报告自己,绝不会悄悄通过。
安装
dsh plugin --profile <name> add dsh-nurse-record-check
dsh --profile <name> --dump-config | grep 'dsh-nurse-record-check'
配置
所有可调项都在 src/config.ts 的 Schemastery schema 里,因此可以直接从 cordis.yml 修改,不用改代码。
| 键 | 类型 | 默认值 | 说明 |
| rulesFile | string | rules/nurse-record.yaml | 规则包路径,相对于包根目录 |
| disabledRules | string[] | [] | 要停止运行的规则 id;每个都会出现在 skipped 里 |
| onlyRules | string[] | [] | 只运行这些规则 id;留空则运行全部规则 |
| skipNotes | string | "" | 附加到每条 skipped 原因后面的备注 |
| timeoutMs | number | 120000 | 协作式工具超时预算 |
材料格式
工具接受 JSON 或 YAML。docx 或 xlsx 二进制不会被解析:病区系统导出的要么是 JSON 载荷,要么是扁平表格,下面这份约定由调用方(或你自己的转换器)填好。字段在读取层是可选的,由检查引擎校验,所以部分导出会针对缺失部分给出发现项,而不是直接崩溃。
target: 内科三病区 2026-03-15 护理记录 episode: admittedAt: "2026-03-15 08:00" # drives NR-008 careLevel: level-2 # drives NR-011 / NR-012 patientLabel: 样本患者甲 records:
- id: REC-0001
kind: rescue # rescue | general | rounds | handover | discharge | other
recordedAt: "2026-03-15 14:20"
rescueEndedAt: "2026-03-15 13:50"
nurseId: N10231
orderId: ORD-1001 # links a record to an order for NR-010
orders:
- id: ORD-1001
type: temporary # temporary | long-term
orderedAt: "2026-03-15 10:00"
execution: { executedAt: "2026-03-15 10:20", nurseId: N10231, outcome: executed }
cancellation: { cancelledAt: "2026-03-15 10:10", reason: 患者外出检查 }
assessments:
- kind: 跌倒坠床风险评估 # 通过共享同义词映射匹配 completedAt: "2026-03-15 09:40"
规则来源
规则数据放在 rules/nurse-record.yaml,与代码分离。每条规则都带一份文件、文件编号、按来源自身编号体系标注的条款、逐字摘录,以及摘录读自的 URL。加载器强制三点:摘录必须是真实引用;少于八个字符的摘录会被拒绝;依据仅为一般原则(kind: derived-from-principle,最高 warn)或本地政策(kind: institutional-configuration,最高 info)的检查,永远不得声明为 error。夸大自身依据的规则包会加载失败,而不是产出一份看似可信的报告。
条款编号已对照以下文件全文核对:《病历书写基本规范》(卫医政发〔2010〕11号)、《综合医院分级护理指导原则(试行)》(卫医政发〔2009〕49号)、《电子病历应用管理规范(试行)》(国卫办医发〔2017〕8号)、《医疗质量安全核心制度要点》(国卫医发〔2018〕8号)、《进一步改善护理服务行动计划(2023—2025年)》(国卫医政发〔2023〕16号)以及《护理分级标准》(WS/T 431—2023)。
这次核对得出三点结论,塑造了整个规则包,记录在此,方便审阅者看清哪些主张是刻意没有提出的:
1. 不存在全国性的记录频次规则。 WS/T 431—2023 删除了 2013 版的「实施要求」一章,分级护理指导原则规定的是巡视间隔,从未规定记录频次。因此 NR-012 出厂时阈值为空。
2. 首次护理评估不存在全国性时限。 卫医政发〔2010〕11号第十七条的 24 小时规则管的是医师的入院记录,不是护理评估;套用到这里就是错误引用。因此 NR-008 出厂时阈值为空。
3. 没有条款禁止记录时间早于执行时间。 NR-010 依据的是第三条的一般职责,因此上限为 info。
故障排查
- 插件装上了,但工具始终不出现。 检查 main 是否指向 lib/index.mjs,以及 pnpm run build 是否产出了它;main 写错会让加载器静默跳过入口。
- dsh plugin add 以不兼容为由拒绝该包。 peer 范围覆盖 0.1.x 和 0.2.x;如果你的运行时不在其中,显式授予豁免: dsh plugin --profile <name> allow-version dsh-nurse-record-check@0.1.0 --dsh-version <runtime> --accept-risk
- 你预期的某条规则没有运行。 读 skipped 数组;它会列出规则名和原因。规则 NR-008 和 NR-012 在阈值配置好之前会一直跳过。
- check 报告 manifest-peers 失败。 静态检查器比对的是一个硬编码的 peer 范围,早于 0.2 系列。运行时在安装时强制 peer 兼容,所以声明的范围才是正确的;这是 dsh-plugin-dev 中已知的上游问题。
- 时间看起来偏移了。 所有运算都是对你提供的字符串做挂钟时间计算,不涉及时区 conversion:一条记录指的是写下来的本地时间。
开发
pnpm install
pnpm run typecheck # tsc --noEmit
pnpm test # vitest, paired fixtures per rule
pnpm run build # tsdown -> lib/index.mjs + lib/index.d.mts
node ../scripts/sync-shared.mjs dsh-nurse-record-check # refresh src/shared from ../_shared
许可证
Apache License 2.0 © 2026 dsh-nurse-record-check contributors。预览分享卡片长什么样 ↓
分享 · DeepSeek Harness Hub
PerryLink/dsh-nurse-record-check
核对护理记录时效签名与评估表完整性
相关插件 · 工具 / 效率
破甲管控台kingcharleslzy-ai/dsh-purge
dsh-purge Community · DeepSeek Harness 社区维护版:宿主兼容、状态诊断、提示词管理、更新与本机备份回滚。基于小杨 / YuJunZhiXue 的 dsh-purge。
★ 4,330已汉化DeepSeek 客户端
74.5
网文长卷lingfengQAQ/webnovel-writer
基于 Claude Code 的长篇网文辅助创作系统,解决 AI 写作中的「遗忘」和「幻觉」问题,支持 200…
★ 7,636已汉化DSH
72.2
多智能体协作HKUDS/AutoSwarm
AutoSwarm: Unify Your Agents. Unify Your Context (Codex · Claude Code · DeepSeek Harness · Muse · Grok · WorkBuddy· nanobot · and more)
★ 2,349已汉化DSH
71.6
Vox 拼贴视频生成Alisa0808/vox-director
🎬 Vox Director拼贴动效导演
★ 2,129已汉化DSH
71.4
Agent 演化引擎Q00/ouroboros
智能体 OS:智能体自己变聪明,我们只守住底线:面试准入、分阶段评估、带预算的进化循环。MCP 服务器,14 种运行时:Claude Code、Codex CLI、Gemini CLI、OpenCode、Copilot、Kiro 等。
★ 6,311已汉化DSH
71.4
智能体运行框架路由HarnessRouter/harnessrouter
智能体 harness 的统一接口。
★ 3,984已汉化DSH
71.3
这是你的仓库?认领条目