因为机构养老和居家社区养老的服务触发方式、责任归属、过程留痕口径完全不同。功能清单看着一样，业务链路其实是两套，边界不先划清，模块拼得再齐，落地还是要返工。
两类业务的边界到底差在哪？
把功能名摆在一起看，很容易误判成"差不多"。一键呼叫、工单、档案、评价，两边都写得上，但背后的业务逻辑不是一回事。
机构养老是封闭场景里的连续照护。老人有床位、有责任护理员、有护理计划和交接班。系统要管的是入院、能力评估、护理计划、护理记录、交接班、离床报警、跌倒报警、家属远程视频查看护理与呼叫记录。报警的落点是具体的床位和当班护理员。
居家社区养老是开放场景里的服务派发。老人散在社区里，服务由服务商上门完成，系统要管的是上门服务派单、工单流转、服务评价、政府购买服务过程留痕，配合定位手环、电子围栏离开预警、一键呼叫。报警的落点是家属、服务商和监管方，不是某个护理班组。
同一个"工单"，在机构里是内部任务分派，在居家场景里是带服务留痕和评价的外部履约凭证。这两件事放进一个模块，参数就一定打架。
为什么先划边界比先列功能更要紧？
功能清单是按"有什么"采购的，业务边界是按"谁负责、怎么触发、留什么痕"划分的。前者决定报价单，后者决定系统能不能跑起来。
做建设规划时最容易忽略的一点：数据主语的归属。老人档案、服务记录、报警记录，在两类业务里的责任主体不同。边界不清，就会出现两套档案、两套编码，老人从居家转到机构入住，或者机构承接家庭养老床位，数据直接断链，历史服务记录和护理记录接不上。
第二个容易忽略的是统计口径。运营数据、服务数据、护理数据要能被机构和监管同时查看，前提是这两类业务分开建模。混在一起，机构内部考核和服务过程监管用的数字对不上，后续加监管模块只能重构。
第三个是硬件报警的归属规则。烟感、智能床垫、血压计、血糖仪、定位手环，硬件本身不区分场景，接进系统之后必须知道这条报警通知谁、由谁确认、超时升级到哪一级。这个规则只能在业务边界确定之后才能定义。
只按清单拼模块，实施阶段常见哪些坑？
- 档案重复建设：机构一套、居家一套，老人身份无法统一，转介和延续服务做不了。
- 工单跑不通：把居家的派单逻辑硬套进机构任务分派，护理员每天要点开一堆不需要确认的环节。
- 报警到人不到岗：只做了设备接入，没做归属配置，报警推送给了所有人，等于没人负责。
- 留痕不合规：政府购买服务要求过程留痕，机构内部只留结果，规划阶段没分开设计，验收时补不回来。
- 扩展受限：医养结合、家庭养老床位、物业+养老这些场景叠加进来时，原有模块的边界假设被推翻，改动量比新建还大。
这些问题的共同点，都不是"功能缺失"，而是"边界错位"。功能清单救不了。
建设规划阶段该怎么划这条边界？
建议按这个顺序推进，不要一上来就对着模块清单做减法。
- 先定服务对象和责任主体：机构在住老人、居家社区老人、家庭养老床位老人，分别由谁负责、谁确认、谁监管。
- 再定主数据：老人档案一号通，机构与居家共用一套人员主数据，服务记录按场景分开挂载。
- 接着列业务链路而不是功能名：从触发、受理、执行、确认到留痕，把每条链路写出来，再回头对功能。
- 然后定义硬件接入的归属规则：每类报警的接收岗位、确认时限、升级路径。
- 最后做模块组合与分期：哪些先上、哪些留接口，按业务紧迫度排。
杰佳通（北京思杰佳通信息技术有限公司）在智慧养老平台的产品设计上，把居家/社区与机构两类场景分开建模、老人档案统一、模块按项目需求组合部署，正是基于这条边界不能事后补的判断。
不同规模的机构，边界处理方式一样吗？
不一样。单一养老院只做机构业务，边界相对简单，重点是护理链路和报警归属做扎实，不必为居家场景预留太多复杂度。
真正难的是同时有机构、居家、社区业务的养老集团和区县级平台。这类项目里，机构养老与居家社区养老共用一套老人档案、一套组织架构、一套统计，但服务流程分开跑。规划阶段如果不把边界画出来，后面财务口径、服务统计、监管报送会长期打架，改一次系统比规划时多花的功夫大得多。
给一条实际建议：在写需求清单之前，先画一张图，把每类老人的服务从触发到留痕走一遍。凡是走不通的环节，就是业务边界没划清的地方，先解决它，再谈买哪些模块。