养老机构照护记录：老人档案、护理执行与家属探视

痛点：照护确实做了，但说不清做了几遍

养老机构最怕的不是检查，而是检查时答不上来。护理员每天在做的事——翻身、喂饭、测血压、协助如厕、更换尿垫、观察皮肤——都是"按次发生"的动作。动作一过，除了当事人，没有东西记得住。

常见的三种状态：

• 纸卡挂在床头或护士站。一班一勾，勾完就堆在文件柜里。家属问"昨天下午有没有帮我妈翻身"，得翻卡、找班次、对日期。护理等级调整或出现压疮时，纸卡既帮不上辩护，也帮不上复盘。
• 微信群报平安。护理员拍张照片发群里，配一句"302 已翻身"。信息是真实的，但没有老人编号、没有护理项、没有时间约束，一个月后谁也检索不出来，还时不时被别的消息顶掉。
• 有个登记本，但只记录"异常"。平时正常的不记，出了事才补一段。结果是：做得好没有证据，出了问题也没有过程可查。

对院长和护理主管来说，真正需要能回答的是这四个问题：

1. 今天这一班，哪些老人该做什么，做完了没有？（应做与实际对不对得上）
2. 某个老人这一周的执行记录是什么样？（家属沟通、复评护理等级要用）
3. 异常发生后，谁在跟进、跟到哪一步、有没有复评？
4. 交接班时，哪些事必须交到下一班手里，不能靠口头？

这四个问题本质上是一组结构化数据关系，不是一张更漂亮的表格。这一篇讲的是：用 Inkwell AI 构建器把"照护记录"做成一个业务模块，需要建哪些数据、页面按角色怎么分、手机上怎么走一遍、上线前核对什么。它属于典型的"业务数据 + 管理页面 + 流程审批 + 移动端伴同"形态，是构建器可以直接交付的模块类型。

先定三个口径，否则表一定返工

照护模块最容易失败的地方不在页面，而在动工前没把三个口径定死。这三个口径定不下来，后面每张表都会互相打架。

口径一：护理等级是谁的标准、怎么表述。 自理、半自理、不能自理，还是机构自己的分级？不同机构叫法不同，同一个机构里，护理部、财务、家属告知书上也常常不一致。做法是把它收进数据字典（选项集中维护的地方，改一次全系统同步），先定一套机构内统一的分级，再让床位、护理项目模板、收费口径都引用这一套。参考 数据字典 的做法。

口径二：护理项目按什么粒度记。 "生活照料"太粗，记了等于没记；"翻身、叩背、口腔清洁、擦浴、协助进食、测血压、血糖监测、更换尿垫"这种粒度才可执行、可统计。粒度定的规则是：一项护理动作对应一个明确频次，且能在一个班次内完成。定好之后作为护理项目的基础清单，同样走数据字典。

口径三：班次怎么切。 白班/夜班两班倒，还是早中晚三班？交接班是照护记录的时间轴单位，班次口径不定，"今天执行完了没有"就没法判断。班次与人员的排班关系，可以复用在排班侧已有的做法上，见 考勤与排班；如果机构还没有排班模块，先在照护模块里用一张简单的班次字典表（班次名、起止时间）起步即可，不必为了照护记录去上一整套考勤。

这三个口径的共同点是：都属于"会变、但要变得有记录"的配置。分级会调、项目会增减、班次时间可能换季调整。所以它们不该硬编码在页面里，也不该让每个护理员自己手填，而应该由护理主管在一处维护，记录侧只做引用。

顺带说清一件常被混淆的事："应做"和"实际"要分开存。 护理等级决定这个老人每天应该做哪些项目、每个项目几次，这是"应做"；护理员在现场按次登记的是"实际"。两者分开，才能算出"漏了几次、补在什么时候"。这个"模板管应做、记录管实际"的思路，和制造业例行检查的建模是同一套——可对照 设备点检巡检 里的做法，只是把检查项换成了护理项。

数据怎么建：八张表，各有各的职责

在构建器里用业务语言把需求讲清楚，AI 会生成对应的数据模型。下面这个骨架建议直接拿去提要求——每一张表为什么存在、不建会出什么问题，都写明了。

1. 老人档案（一人一档）

主档只放"这个人是谁"和"现在处于什么照护状态"，字段不必多：姓名、性别、出生日期、身份证号、籍贯、紧急联系人及电话、既往病史、过敏史、饮食禁忌、入住日期、退住日期、当前护理等级、当前床位、状态（在住/请假外出/退住）。

两个设计决定值得提前想清楚：

• 身份证号设唯一约束。养老机构里同名同姓、同音不同字的情况不算罕见，用姓名做识别早晚重复建档，费用和记录会分散在两条档案上。
• 过敏史、饮食禁忌这类"会要命的信息"要结构化。做成独立的文本字段加上字典勾选，并让移动端的老人卡片页显著展示，而不是埋在备注里。

2. 房间床位主档 + 床位占用关系表

床位是机构里最典型的"分配类"资源，必须下沉到最细粒度：一张床一行，记房间号、床位号、床型（多人间/单间）、所属楼层区域。

老人与床位的关系不要写成老人档案上的一个"当前床位"字段就结束——那样换床之后历史就断了，查不到"上个月 302-2 床住的是谁"。做法是单独立一张占用关系表：老人、床位、开始日期、结束日期、换床原因。换床时新增一行，同时把上一行的结束日期填上，而不是覆盖旧值。

同一张床在同一时点只允许一条在占用记录。 这个约束时段重叠无法用简单唯一约束表达，交给数据流规则（保存时自动执行的校验）在保存时比对起止日期并拦截。只弹提醒不拦单，等于不拦。

3. 护理项目模板（管"应做"）

这张表回答"这个老人每天/每班应该做哪些事、各几次"。结构是：

• 模板头：适用护理等级、适用人群说明、版本、生效状态
• 明细行：护理项目（引用字典）、频次（每班 N 次／每日 N 次／每周 N 次）、建议时段、是否需记录数值（如血压、体温）、是否需留附件、执行岗位

一个护理等级对应一套模板，老人入住时按等级挂上模板；等级调整时挂新模板并留痕。频次的具体数值（一天翻几次身、几小时测一次）按机构护理标准和医嘱定，系统不内置默认值——这类数值写死在系统里，一旦和机构实际做法不一致，记录就会失真。

4. 护理执行记录（管"实际"）

这是整个模块里数据量最大的一张表，设计原则只有一条：按次一行，只增不改。

字段：老人（引用档案）、护理项目、班次、执行时间、执行人、执行结果（已完成／拒绝／老人不在／其他）、数值（若该项目需记读数）、异常标记、附件（照片等）、备注。

为什么"只增不改"这么重要：照护记录是过程证据。允许护理员事后编辑，就等于把证据的可信度自己拆掉了。需要更正时，正确做法是作废原行（记作废原因与作废人）+ 新增一行更正记录，两条都留着。这样时间线上看得出"什么时候发现记错了、谁改的"。附件挂在记录行上而不是老人档案上，才能做到"从一张照片反查是哪一次照护"。

5. 异常主表 + 处置跟进子表

跌倒、压疮、噎食、走失风险、突发不适、家属投诉——这类事件不能只写在执行记录的备注里。备注里的事件既不会进入待办，也没法统计频次。

• 异常主表：一次事件一行，记老人、发生时间、发现人、异常类型（走字典）、现场描述、初步处置、严重程度、状态（待处置／处置中／已复评／已关闭）、是否已告知家属及告知时间。
• 处置跟进子表：一行一个动作，只增不改——换药、送医、通知家属、调整护理等级、加装防护、复评结论，谁做的、什么时候做的。

异常单不能靠"状态改成已关闭"收口，而要收口在复评上：异常处置完成后，由系统自动生成一条复评任务，复评记录填完之前异常单不允许关闭。否则"整改完忘记复评"会成为常态，下次同样的事还会发生。

6. 代管药品与用药交接

机构代管老人药品是高风险环节，也是检查重点。两张表分工：

• 药品登记子表（一人一药一行）：药品名、规格、批号、有效期、数量、服用方式、开药医院、接收人、接收时间。效期是必填字段，到期提醒由后面讲的定时任务负责。
• 用药交接记录（按次一行）：发药/用药时间、药品、应服数量、实服数量、执行人、家属或本人确认情况、剩余数量。数量对不上时必须填原因才能保存——这条校验交给数据流规则。

7. 家属探视与代领物品

探视登记本身简单，但有两个坑：一是"谁把老人接出去了、说好什么时候回"没有记录；二是老人随身物品或药品被家属带走，事后扯不清。

• 探视登记：一次一行，记探视人姓名、与老人关系、证件后四位、进入时间、离开时间、是否带老人外出及预计返回时间、实际返回时间、登记人。外出未按时返回的，由定时任务算进超时清单。
• 代领物品：物品名、数量、领走人、时间、是否需带回、带回时间。这类"出去要回"的记录同样只增不改，归还另起一行。

8. 交接班单

交接班是把"上一班的事交到下一班手上"的单据。一次交班一张单（班次、交班人、接班人、交班时间），单下可以引用多条待交接事项——可以直接引用未关闭的异常单、需继续观察的项目、家属特别交代。用一张单据引用多条明细的方式，避免同一件事在两个班里各记一次、统计翻倍。

交班单提交后由接班人确认收到，未确认的交班单在清单里保持高亮，这是"口头交代漏掉"最直接的补救。

页面按角色分：一个人只看他该看的那一屏

模块上线后最常见的抱怨是"页面太复杂"。问题不在字段多，而在把所有人放在同一个界面上。照护模块至少有三类人，各自的关注点完全不同：

页面上具体这么安排：

• 老人档案页：主档信息在上，下面用分页签挂护理记录、异常记录、用药记录、探视记录、床位变更史。这一屏是家属沟通和迎检时被翻得最多的。
• 执行记录列表：默认按"今天、本班次"过滤，列显示老人姓名、床位、护理项目、执行时间、执行人、结果。异常结果高亮，可一键跳到异常单。
• 应做清单（护理任务清单）视图：不是护理员手填，而是由定时任务按模板和班次算出来的"待执行清单"。护理员执行完勾掉一条，清单和执行记录一一对应。
• 异常台账页：按状态分栏，未关闭的排前面，显示距发生时长的天数。这一栏是护理主管每天开工先看的东西。
• 交接班页：交班人新建单据、勾选待交事项、提交；接班人确认收到的动作留痕。

权限上按岗位切：护理员只看到自己负责的房间与老人，看不到全院异常台账；护理主管看本楼层；院长与质控看全院并可导出。角色的搭建方式参照 角色与权限配置，不必新建角色体系，在既有角色上挂模块权限点即可。

四类自动化：让系统替人盯住"该发生的事"

照护模块的价值有一半不在录入，而在于系统会主动把该发生的事推到人面前。四类自动化各管一段：

1. 数据流规则（保存时自动校验）

• 同一床位同一时点只允许一条在占用记录，时段重叠拦截提交。
• 用药交接的应服与实服数量不一致时，原因必填才允许保存。
• 护理等级变更必须同时生成一条变更记录（含变更前后等级、依据、审批人），不允许直接改主档字段。
• 异常单在无复评记录时不允许置为已关闭。
• 执行记录禁止编辑：只能作废重开。

这些校验的价值是在录入的那一刻拦住，在 PC 端、手机端、Excel 导入三个入口同一口径执行，而不是靠月底人工核对。

2. 审批流（需要有人点头的事）

• 入住与退住办理。
• 护理等级调整（升档/降档都会影响收费与人力，必须留审批痕迹）。
• 重大异常上报（如跌倒致伤、送医）——上报后可继续走处置跟进，不宜把整张异常单卡在审批节点上。
• 请假外出超过机构规定时长。

审批节点数量按机构规模定，两三级即可，不要把日常照护动作也塞进审批，否则护理员会绕着系统走。

3. 定时任务（每天自己跑的事）

• 每班开始前，按护理项目模板生成本班次的应做清单。
• 每日汇总前一日漏做项，推送给护理主管。
• 代管药品有效期临近提醒（提前多少天按机构制度定），过期药品自动进入待处理清单。
• 探视外出未按时返回、交接班未确认的超时清单。
• 护理等级复评到期提醒（复评周期按机构标准与医嘱定）。

定时任务的配置方式见 工作流与定时任务，是平台既有的能力，不需要额外开发。

4. 审计日志（事后查得到）

档案修改、护理等级调整、执行记录作废、异常单关闭、权限变更都会留痕，谁在什么时间改了什么，可查可导出。照护数据的特殊性在于：它既要服务日常管理，也可能被家属、监管、保险机构追问。留痕不是防员工，是给做得对的人留证据。

移动端：护理员那一屏决定了这套东西能不能用起来

照护发生在床边，不在办公室。PC 端页面再完整，护理员不会为一笔记录去开电脑——流程一旦要求"回办公室补录"，记录就会变成班末凭记忆批量填，时间戳全部失真。

移动端这一屏的设计目标只有一个：在床边三十秒填完一次照护。

• 进入后先是按房间/楼层分组的老人列表，卡片上直接显示床号、姓名、护理等级、今日待执行项数量。
• 点进老人，出现本班次待执行项目清单，一项一行，点一下即完成登记；需记数值的项目（血压、体温、血糖）弹出数字输入；需留证的项目直接调用手机拍照，照片作为附件上传并挂在这次记录行上。
• 异常上报放在最显眼的位置：选异常类型（字典）、填现场描述、拍照、提交，系统随即生成异常单并通知护理主管。
• 家属探视登记、代领物品登记也在同一个移动端模块里，前台或护理员随手就能记。

移动端的页面是构建模块时同步生成的，PC 端与手机端使用同一套数据与权限，操作方式见 移动端使用指南。

需要说明一条现实约束：手机端的可靠性取决于现场网络。老院区、地下楼层信号不好是常态，因此设计上要留一手——断网时先按机构既有做法用纸质单记录，回到有网环境再补录，补录的记录保留"实际发生时间"与"录入时间"两个字段，两者不一致不影响记录有效性，但必须如实填写。这类兜底口径要在上线培训时讲清楚，不能默认"有手机就能填"。

上线前查什么：七件事，一件都不能省

系统建好不等于能用。照护模块上线前建议逐条核对：

1. 字典先定死再建数据。 护理等级、护理项目、异常类型、执行结果、班次这几套选项要先定完整；上线后再改字典，历史记录的统计口径会跟着变。做法见 数据字典。
2. 床位先建全、老人再进来。 先建全院房间与床位（一张床一行），再导入在住老人并补录当前的床位占用行。漏建床位，后面每一次换床都会缺一个落点。
3. 模板逐条核对频次。 按护理等级把模板配好之后，请护理主管一条一条对着机构实际做法核一遍。"一天翻身几次"这类数值不能默认，配错一次，后面所有执行率统计都是错的。
4. 期初数据要补两类。 一是当前代管药品清单（含批号与有效期）；二是近一段时间的未关闭异常——不补这两类，药品到期提醒和异常复评清单上线第一天就是空的，等于没人会去看它。
5. 权限按岗位过一遍。 护理员只看到自己负责的房间，主管看本楼层，院长可看全院并导出。用真实账号各登一次验证，别只用管理员账号试。
6. 端到端跑通一个班次。 定时任务生成应做清单 → 手机端按房间登记 → 报一次异常 → 主管处置 → 生成复评任务 → 复评关闭 → 交班确认。这条链路走不通，说明某张表的关联没接上。
7. 明确讲课口径：从上线日起算，不追补历史。 历史纸质记录扫描归档即可，不要组织护理员倒着补录三个月，那样只会产出不可信的数据。发布前用平台的预检与移动端同步核对一遍，方法见 模块的测试与发布。

之后怎么延伸

这套数据结构稳下来之后，往四个方向延伸都比较自然：

• 人力投入：应做清单与实际执行记录可以反推各班次的照护工作量，配合排班数据看人力是否匹配。排班侧的做法见 考勤与排班。
• 收费与等级联动：护理等级决定收费档时，等级调整审批通过后自动带出费用变更，不必财务再对一次。
• 耗材与用品：纸尿垫、护理耗材的领用可以与执行记录挂钩，按人次估算用量，减少"每月盘一次、每次都差"。
• 质量复盘：按异常类型、楼层、班次做月度分布，找出反复发生的场景（例如夜间翻身漏做集中出现在某楼层），这是护理质量改进最实在的输入。

不做什么：把边界说在前面

诚实的方案要写清做不到的部分，否则上线后会被当成缺陷：

• 不接硬件。 床旁呼叫器、生命体征监测仪、智能床垫、定位手环、门禁闸机都不接——平台做的是业务数据与管理页面，硬件对接属于另一类工程。
• 不做身份核验与定位。 人脸识别、指纹打卡、GPS/蓝牙定位考勤不作为本模块能力；执行人取自登录账号，真实性靠管理与排班约束。
• 不做腕带扫码核对。 扫码识别不是平台内置能力，老人身份核对通过移动端列表按房间点选完成；如果机构已有腕带与扫码设备，需要另行评估对接，不在本方案范围内。
• 不做评估判定。 跌倒风险评分、压疮分期结论、护理等级自动建议这类专业评估，不作为系统自动输出的结论；系统只记录护理人员填写的评估结果与依据。
• 不做家属端自助。 家属不建账号、不开放自助查询，告知与确认通过机构既有的沟通方式完成，系统只留"已告知时间与告知人"的记录。
• 不承诺"零事故"。 系统能保证的是：做过的查得到、漏做的看得见、异常有人跟进且跟进过程留痕。这四条本身已经能覆盖大部分检查场景，但它不等于事故不会发生，也不该被这样承诺。

一句话总结

照护记录这个模块真正的难点不是把表格搬到屏幕上，而是三件事："应做"由模板算出来，不由人凭记忆列；"实际"按次只增不改，更正留两条；"异常"必须有处置与复评两段，不靠一句备注收口。 把这三条在数据层做对，其余页面、移动端与提醒都是构建器可以直接生成的部分。