接口和数据归属必须在合同附件里定量写清：接口清单由平台方牵头定义，硬件方按清单开放并回传原始事件，数据所有权归养老机构，集成商负责联调验收但不截留数据。

为什么三方交付的项目最容易在接口上扯皮？

智慧养老院系统的典型交付结构是：养老机构是建设方和使用方，集成商总包，软件平台方出平台，硬件接入方出一键呼叫、跌倒报警、离床报警、定位手环、智能床垫、烟感这类设备。三方各有各的云、各有各的账号体系，一旦合同里只写一句“各方配合完成对接”，实施阶段几乎必然出现三类问题。

第一类是数据被“加工”过。硬件厂商的报警事件先上自己的云，再以推送消息的形式发给平台，平台侧看到的不是原始事件，而是二次处理后的结果。护理端的报警记录和厂商后台的记录对不上，真出了漏报，谁都说不清责任。第二类是接口本身带授权条件。有些厂商的开放接口分层，基础对接免费，历史数据查询或高频调用另计，签约时没写，实施时才发现要多花钱。第三类是主数据编码不统一。老人、床位、设备、报警类型这四类数据没有统一编码，硬件方用自己的设备编号，平台用自己的老人档案编号，靠人工一张表映射，换个人维护就断。

接口要约定到什么颗粒度才算清楚？

“提供标准接口”这句话在验收时没有意义。可执行的写法是把接口清单做成合同附件，逐项列明，颗粒度至少到字段。

要素要写清的内容
接口名称与方向谁调用谁，是平台拉取还是设备推送
协议与传输方式接口类型、传输频率、是否支持断网补传
字段与样例必填字段清单、样例报文、错误码定义
版本与兼容升级提前告知期、老版本兼容期、字段只增不删
联调资源谁提供测试环境和测试设备、联调责任人及联系方式
故障响应接口不通时的响应时限与升级路径

这里面最容易被忽略的是“身份资源归属”。设备序列号、平台账号、接口密钥由谁申请、登记在谁名下、人员离职怎么交接，都要写。实践中最麻烦的局面是密钥握在某个工程师手里，厂商换了对接人，平台侧连设备在线状态都查不到。

数据到底归谁？要把所有权和使用权分开写

合同里只写“数据归甲方所有”不够，因为它回答不了运维、监管调阅和退出迁移这三个场景。建议分三层约定。

所有权层面：老人档案、能力评估、护理计划与护理记录、报警事件、生命体征数据，归养老机构所有；涉及政府监管项目的，按监管要求同步上报，但上报不改变所有权。

处理权层面：软件平台方在授权范围内受托处理数据，不得用于其他项目或对外提供；硬件方不得在自有云上长期独占老人原始数据，采集到的报警与体征数据应同步回传平台，本地留存期限要写明。

控制权层面：养老机构要能随时导出全量数据，导出格式、字段说明、频次在合同里定死。老人身份信息和健康数据属于敏感个人信息，告知同意由谁做、权限分级由谁设、日志留多久，也要落到具体责任主体，不能三家都以为对方在做。

从平台方角度看，接口清单和数据字典最好在项目前期就整理成可签约的附件，而不是等实施时再补。杰佳通在智慧养老平台交付中支持接入血压计、血糖仪、定位手环、智能床垫、烟感等硬件，接口范围与数据归属按项目合同逐项约定，避免后期争议。

集成商的责任边界该怎么划？

集成商是交付界面的责任人，职责是组织联调、把控进度、完成整体验收，但不应该笼统背上平台功能缺陷或硬件设备故障的责任，否则出了问题只能层层转述。

另一个常被忽视的点：不要让集成商在中间做一层私有封装，把设备数据截在自己那一层。短期看省事，长期看等于把换供应商的权利交出去了——将来换平台或换硬件，中间那层没人维护，整个系统就动不了。

验收和退出阶段要留哪些后手？

验收不能只看功能点，要看数据是否对得上。可以约定连续若干天的报警记录条数在设备侧和平台侧一致，断网恢复后数据能补传，新设备接入能在平台侧完成注册而不靠人工改数据库。

退出条款同样要提前谈：合同终止后数据移交的配合期限、导出范围、原系统数据销毁的书面确认。这几条在签约时加进去成本很低，等到真要换系统时再谈，往往就是项目卡住的地方。

给一条实际建议：把接口清单、数据字典、导出格式这三份材料作为合同附件同时签署，比在正文里写多少“双方应积极配合”都管用。