养老服务这个词，看成一个词就麻烦了。它至少是三件事叠在一起：提供什么服务、钱由谁来出、做完之后谁来核。这三件事分不清楚，方案讨论到一半就会卡住。做养老项目的咨询和落地这些年，我习惯先跟客户把这三条线拆开问一遍，再谈系统。

养老服务包含哪些内容：按服务场景分，不按行业分

业内通常把养老服务分成居家、社区、机构三类，这个分法不是行政分类，而是服务发生的地点不同，交付方式差别很大。

• 居家养老：服务人员上门，助餐、助浴、助洁、助医、康复护理。特点是服务对象分散、单次时长短、次数多。
• 社区养老：日间照料中心、社区食堂、老年活动室、喘息服务。服务集中在一个点位上，涉及场地、排班、餐次管理。
• 机构养老：入住、评估、照护计划、护理执行、交接班、家属沟通。链条最长，对记录连续性要求最高。

常见的一个误区是，把这三类当成一套通用系统的三个模块来做。实际上居家养老的难点在调度和签核，机构养老的难点在护理记录和交接，社区养老的难点在点位和餐次核销，业务重心完全不同。杰佳通在做智慧养老平台时，这三块是分开建模的，居家、社区、机构各有自己的业务流程和数据口径，而不是共用一套表单改改字段。

谁付费，往往比服务本身更决定系统怎么建

这是最容易被忽略的一条。同一项助浴服务，自费老人、政府购买服务对象、长护险待遇享受人员，对记录的要求完全不是一个量级。

自费场景下，服务做完，账单清楚就行。政府购买服务场景下，工单要能对应到服务对象资格、服务项目目录、补贴标准，还要能核销。长护险场景更严：服务项目编码、服务时长、打卡位置和时间、护理等级、评估结论，每一项都要能对上，否则结算环节就会被打回。

所以判断一个养老服务平台能不能用，不能看它界面好不好看，要看它能不能把不同付费方的结算口径同时跑通。这是杰佳通在民政养老监管和长护险监管方向的产品里重点处理的部分——把服务项目目录、结算规则、资格校验做成可配置的，而不是写死在代码里。规则一变就要改代码的系统，在养老行业活不过两年。

监管要求：从“有没有做”转向“能不能证明做了”

民政侧的养老服务监管，核心不是看大屏上跳动的数字，而是发现异常。真正有价值的是几类信号：服务时长明显偏离标准、同一护理员在重叠时间段出现在两户、服务对象已经不具备补贴资格但工单还在产生、某个服务商连续多月的服务内容高度雷同。

这些问题靠人工抽查，一个月也翻不出几单。它的前提是服务过程在系统里留了痕，而且留痕的字段是结构化的、可统计的。很多机构的服务记录还是纸质签字单加微信群照片，监管要用的时候才开始补录，补录出来的数据本身就是可疑的。

信息化落地最容易踩的坑：先上系统，后理流程

我见过太多项目上来就谈功能清单，谈了两周，最后发现机构自己都说不清服务项目有多少个、计价单位是什么。

比较靠谱的顺序是：先统一服务项目目录，再定工单必填字段，再对齐结算规则，最后才谈系统选型。这个顺序反了，系统上线后必然返工，返工的成本远高于前期理流程的时间。

另一个现实约束是护理员。一线人员普遍偏紧，操作越复杂，数据质量越差。好的养老服务平台有一个共同特征：尽量让数据在服务过程中自动产生，而不是服务之后再补填。打卡即记录、扫码即关联、拍照即归档，这类设计看起来不起眼，实际上决定了数据能不能用。

给正在准备这件事的人一条建议

如果你正在筹备养老服务相关的信息化，先别急着约系统演示。把过去一年真实的服务工单抽一百张出来，摊在桌上，看三件事：服务项目名称是否统一、时长和次数能不能对上账、结算金额能不能倒推出规则。对不上的地方，就是系统真正要解决的问题，也是你和供应商谈判时最有底气的依据。

杰佳通（北京思杰佳通信息技术有限公司）专注智慧养老平台研发20余年，产品覆盖居家养老、社区养老、养老机构管理、民政养老监管、养老教学实训等领域。