目录一、两种场景两种逻辑二、社区康复的四类主体与信息化成熟度三、社区侧已有系统全景支付成熟管理碎片化3.1 支付与结算层相对成熟的标准平台3.2 患者与档案管理层有档案无专科闭环四、与医院 HIS 对接范式的根本差异五、现状格局专科深度与基层广度的分裂5.1 医院康复专科赛道假设 HIS 存在5.2 基层医疗信息化广覆盖浅康复5.3 康养与长护赛道工单驱动临床浅5.4 市场空白与机会窗口六、社区场景下的对接对象与优先级第一档几乎必接第二档按客户类型选接第三档专项场景七、四种对接模式与适用条件模式 A有基层 HIS 的社区卫生服务中心最接近医院模式 B独立社区康复机构无完整 HIS模式 C长护险 / 居家康复模式 D医共体分级康复八、功能差异矩阵什么该保留什么该新建8.1 患者与就诊8.2 医嘱与收费8.3 治疗执行与设备8.4 矩阵结论裁剪原则九、对接接口优先级排期9.1 阶段节奏9.2 基层 HIS 适配优先级9.3 医保接口必选与可选Phase 1 必选无此不能上线社区门诊康复Phase 2 建议接入Phase 3长护险居家场景9.4 接口依赖关系十、实施成本与决策建议10.1 资源粗算10.2 五条功利主义决策原则结语当康复服务的重心从科室转向网格信息系统的设计逻辑、对接对象与产品边界都需要一次根本性的重估。过去十年国内康复信息化建设的主战场几乎锁定在医院——康复医学科作为二级学科依托成熟的 HIS 体系形成了「上游粗粒度医嘱、下游细粒度执行、执行结果回传计费」的闭环范式。随着分级诊疗、医共体建设、长期护理保险扩面以及「十四五」全民健康信息化规划的推进康复服务的重心正在不可逆地向社区、向居家迁移。这不是简单的「把医院系统缩小版搬到社区」而是一次涉及业务对象、计费逻辑、监管要求与 IT 生态的全面重构。一、两种场景两种逻辑要理解社区康复信息化的特殊性首先需要还原医院康复科信息系统的运行逻辑。在典型的三级或二级医院康复医学科信息系统扮演的角色是专科执行层医院 HIS 承担患者主索引、挂号、住院/门诊流转以及粗粒度的收费项目管理康复管理系统则承接医嘱的细分解构——将「康复评定」「物理治疗包」等宏观项目拆解为可执行、可计量、可质控的具体治疗动作管理每一次执行的频次、部位、时长与操作人员并将细粒度的执行结果回传至 HIS触发实际计费。这条链路成立的前提是上游存在一个功能完备、接口相对规范、计费体系成熟的医院信息系统。康复管理系统不必承担患者建档、挂号收费、医保结算等「平台级」职能而可以专注于康复专科的核心价值排程优化、治疗执行、疗效评估、质控追溯以及康复设备的数据采集与绑定。社区场景打破了这一前提。社区卫生服务中心、独立康复机构、养老机构以及长护险定点服务商其信息化生态呈现出高度碎片化的特征有的机构拥有基层版 HIS但康复模块极为薄弱有的机构仅有诊所级管理系统甚至没有专门的 IT 支撑有的机构则完全依赖长护险工单系统和移动 App 开展上门康复服务。支付能力医保、移动支付、长护险在社区是普遍存在的但等价于医院 HIS 的「患者主索引 医嘱 计费」一体化体系在社区往往是缺失或残缺的。社区康复信息化的核心命题不是「如何把医院那套做得更轻」而是「当上游平台不完整时康复管理系统应当延伸到哪里、止步于哪里」。二、社区康复的四类主体与信息化成熟度「社区康复」并非单一业态。从信息化需求与对接策略的角度至少可以识别出四类主体其 IT 成熟度与付费逻辑差异显著场景类型典型主体信息化特征康复管理切入点基层医疗康复社区卫生服务中心、乡镇卫生院康复室有基层 HIS偏门诊 公卫极少单独建设康复专科系统与 HIS 协同强化执行闭环与设备管理独立社区康复机构民营康复中心、残疾人康复站小型 HIS/诊所系统或几乎无系统需自建或补强患者、收费、医保上游能力医养/养老康复养老院、日间照料中心养老 SaaS 长护险为主临床康复能力弱长护险工单 简易康复记录居家/上门康复长护险定点机构、上门 PT/OT 团队长护险子系统、移动 App非传统 HIS 范式移动执行、签到签出、服务留痕与结算申报从功利视角评估基层医疗康复是当前政策与市场规模交汇的主战场——医共体建设、县域康复能力提升、社区康复科标准化建设等政策导向均指向这一群体。其信息化路径与医院最为接近迁移成本相对可控。独立机构和居家场景则代表更大的市场长尾但单客户 IT 预算低、接口配合意愿弱对产品标准化与 SaaS 化部署能力提出更高要求。三、社区侧已有系统全景支付成熟管理碎片化3.1 支付与结算层相对成熟的标准平台社区机构在支付层面并不落后。随着国家医保信息平台的全国统一建设以及 2022 年以来长护险功能模块的陆续上线社区康复所依赖的结算基础设施已高度平台化国家医保信息平台涵盖电子凭证、移动支付、即时结算等能力两定机构对接标准趋于统一地方医保经办子系统承担目录对码、事前事中审核、DRG/DIP 或按项目付费等地方规则长护险子系统国家版 地方版架构覆盖申请—评估—服务—结算全链条开封等地已率先落地第三方支付微信、支付宝及银行聚合支付承担自费与混合支付场景。支付不是问题问题在于康复项目的编码映射与计费规则。社区门诊康复多走按项目付费长护险场景则偏向服务包、按日或定额拨付住院康复在部分试点地区如攀枝花 VRG 价值付费探索按病组分期付费。同一套康复执行数据在不同结算通道下需要不同的聚合与申报逻辑——这是社区版与医院版计费模块差异的根源。3.2 患者与档案管理层有档案无专科闭环社区不存在单一的「患者管理系统」而是多套系统拼接系统类型主要职能与康复的关联度基层 HIS / 诊所系统挂号、门诊病历、开单、收费、发药高——患者入口与粗粒度收费全民健康信息平台 / 医共体平台居民电子健康档案、双向转诊、检验检查共享中高——既往史调阅与分级衔接公卫系统体检、慢病管理、随访、家医签约中——康复对象识别与院后管理长护险服务系统失能评估、护理计划、上门工单、签到签出高居家场景——服务计划与结算主通道精康转介平台精神障碍社区康复转介与档案共享专科——与躯体康复路径不同残联 / 民政平台残疾人康复补贴、政府购买服务验收中——部分机构必接现状可以概括为档案有、支付有但缺少连接「康复专科级医嘱—执行—计费—质控」的中间层。这正是医院康复管理系统所填补的缝隙到了社区这条缝隙有时更宽上游更粗有时上游根本不存在需系统自建上游能力。四、与医院 HIS 对接范式的根本差异将医院与社区的信息流并列对比差异一目了然具体差异体现在五个维度患者来源医院以住院流转和门诊挂号为主社区增加了家医签约对象、长护险失能人员、残联服务对象等多入口医嘱粒度医院 HIS 通常已配置康复相关收费包社区 HIS 往往只有通用门诊项目康复医嘱可能在康复系统内从零建立计费路径医院以「执行回传 → HIS 计费 → 医保结算」为主社区可能出现「康复系统直连医保」或「长护险工单结算」等并行路径监管重点医院侧重病历质控、康复质控指标社区额外面临医保事前审核、长护险服务留痕、虚假服务防范等监管服务连续性医院康复多在院内闭环社区需要承接上级医院下转、支持居家延续训练数据需跨机构流动。五、现状格局专科深度与基层广度的分裂5.1 医院康复专科赛道假设 HIS 存在护加加、太翼睿景、东软专科康复、华唯科技、玖云科技等厂商产品逻辑均建立在「上游有成熟 HIS」的前提之上。其核心竞争力集中在治疗排程与排点算法治疗师负荷、设备冲突、时间配比执行闭环与康复质控指标自动化与 HIS/LIS/PACS 的数据集成部分厂商延伸至院内—居家连续康复。这一赛道的产品成熟度较高但在社区直接复用面临结构性障碍社区 HIS 接口能力弱、文档缺失、定制比例高且多数基层系统未预留康复专科接口。5.2 基层医疗信息化广覆盖浅康复ABC 数字医疗云、创业慧康、东软、OpenHIS 等基层 HIS 或诊所系统强调「医疗 医保 公卫」一体化能够覆盖社区卫生服务中心的核心诊疗与公卫职能。然而康复在其产品谱系中通常只是门诊开单的一个子集缺乏治疗排程、执行频次管理、设备绑定、疗效评估等专科深度。5.3 康养与长护赛道工单驱动临床浅东软睿新智慧康养、久远银海长护险子系统等面向养老、长护险场景强项在于服务调度、过程监管、费用结算与 fraud 防范如上海宝山「长护 e 安」三级智能监管平台。其底层逻辑是「服务工单 监管留痕」而非「临床康复执行 细粒度计费」——与躯体康复的专科需求存在明显断层。5.4 市场空白与机会窗口功利评估当前社区康复信息化处于「有平台、无专科闭环」的过渡阶段。HIS 厂商不会做深康复执行康养平台不会做细临床医院康复厂商默认 HIS 完备——连接基层诊疗平台与康复专科执行能力的中间层仍是竞争相对分散的蓝海。具备设备物联网、执行闭环与分级康复衔接能力的方案在这一窗口期具备差异化空间但产品形态必须从「HIS 下游子系统」升级为「可独立运行、可平台对接的康复业务中台」。六、社区场景下的对接对象与优先级从实施可行性与业务价值两个维度社区康复管理系统需要对接的对象可按三档排列第一档几乎必接基层 HIS / 诊所管理系统——患者信息、挂号、门诊医嘱若有、收费主数据国家医保信息平台两定接口——电子凭证、目录对码、门诊结算、事前审核、对账收费项目映射引擎——HIS 收费项 ↔ 康复治疗项 ↔ 医保目录的三方映射实施成本的关键变量。第二档按客户类型选接全民健康信息平台 / 医共体平台——EHR 调阅、双向转诊、检查检验共享长护险子系统——服务计划、执行记录、签到签出、费用申报居家/上门场景公卫 / 家医签约系统——慢病康复人群、随访闭环移动支付——诊间支付、预约社区患者自助化需求高于医院。第三档专项场景残联、民政购买服务、精康转介平台康复设备物联网平台设备状态、训练数据采集、居家回传。七、四种对接模式与适用条件模式 A有基层 HIS 的社区卫生服务中心最接近医院结构与医院模式相同差异在于HIS 接口能力弱、康复医嘱可能直接在康复系统开立、需预置主流基层 HIS 适配器。适用已部署基层 HIS 且康复为正式科室的社卫中心。模式 B独立社区康复机构无完整 HIS系统从「专科执行层」升级为「康复业务中台」需补患者登记、收费项目库、医保对码、结算等上游模块。适用民营康复中心、残疾人康复站等无 HIS 或 HIS 极弱的机构。模式 C长护险 / 居家康复计费逻辑从「按治疗项目次数」转向「按服务包/时长/定额 监管留痕」。移动执行、签到签出、GPS/蓝牙留痕是刚需。适用长护险定点机构、上门 PT/OT 团队。模式 D医共体分级康复上级医院康复系统或 HIS 下转康复方案 → 社区康复系统执行并回传进度 → 全民健康平台/医共体更新档案、支持上转预警。适用已建设医共体信息平台的县域或城市区域是政策驱动下可复制性最强的区域化场景。八、功能差异矩阵什么该保留什么该新建以下矩阵以「医院康复科版」为基线对照三种社区产品形态的功能取舍。图例保留 直接复用 · 新增 社区特有 · 弱化 非核心 · 不适用 场景不存在8.1 患者与就诊功能医院版社区·有HIS社区·独立机构社区·居家住院患者接入核心不适用不适用不适用门诊/HIS 患者同步核心保留弱化弱化自主登记/建档弱弱化新增新增医保电子凭证弱新增新增新增健康档案调阅无新增新增新增双向转诊弱新增新增弱化8.2 医嘱与收费功能医院版社区·有HIS社区·独立机构社区·居家HIS 粗收费包下传核心保留不适用不适用治疗医嘱细分/方案核心保留保留改造服务包化频次/次数/疗程管理核心保留保留改造执行→计费映射核心保留保留改造细粒度回传 HIS核心保留不适用不适用系统内开单/收费无弱化新增不适用收费项目库医保对码HIS 主导新增新增新增长护险工单计费无不适用不适用新增8.3 治疗执行与设备功能医院版社区·有HIS社区·独立机构社区·居家治疗排程/排点核心保留简化保留改造路线排程每次执行登记核心保留保留新增移动签到评定→方案→执行→结案核心保留保留保留院后/居家随访弱新增新增新增设备使用绑定核心保留保留新增家用设备设备利用率分析有强化社区更关注闲置强化不适用8.4 矩阵结论裁剪原则必须保留并社区化治疗执行闭环、医嘱细分、频次/次数管理、设备绑定——这是康复专科系统的核心价值与场景无关。必须新增医保对码引擎、电子凭证、移动端执行端、统一 Adapter 层独立机构版还需轻量开单收费。可 Phase 2 延后公卫上报、精康转介、患者小程序、居家设备全链路。医院特有可剥离住院流程、复杂多科室会诊、与 EMR 深度耦合的病案质控。九、对接接口优先级排期9.1 阶段节奏阶段目标可交付客户Phase 0Adapter 框架 社区基础模块内部试点Phase 1「能收费、能执行」MVP有 HIS 社卫 / 独立机构Phase 2多 HIS 适配 平台互联区域复制Phase 3长护/居家 运营增强医共体 / 上门康复9.2 基层 HIS 适配优先级优先级厂商/产品理由首批接口P0创业慧康基层/云 HIS基层覆盖广医共体项目多患者、挂号、医嘱、收费、退费P0ABC 数字医疗云社区中心增长快HIS医保公卫一体患者、门诊医嘱、收费、医保事前P1东软基层/云 HIS区域项目多与医院产品线可复用经验患者、医嘱、费用回传P1卫宁健康WiNEX 基层头部厂商大型医共体常见患者、医嘱、结算P1久远银海医保/长护平台强相关医保侧为主P2OpenHIS / 新致天天开源县域、村卫生室、民营诊所患者、挂号、收费REST 友好P3地方小厂商单项目按需DB 视图/文件交换兜底Phase 1 建议只做 2 家 P0创业慧康 ABC可覆盖约六成目标客户画像同时建设「通用兜底 Adapter」DB 视图 CSV/HTTP 回调承接接口极弱的客户。9.3 医保接口必选与可选Phase 1 必选无此不能上线社区门诊康复接口类别典型交易/功能用途基础配置定点机构、科室、医师备案合规前提人员识别医保电子凭证解码1101 等登记入口目录对码医疗服务项目目录下载与本地映射康复计费基础门诊结算费用上传 门诊结算2204/2207 等核心收费合规控制事前/事中审核3101/3102 等基层高频违规场景对账冲正日对账、清算、结算撤销财务闭环Phase 2 建议接入医保移动支付——诊间付、小程序付社区自助化需求强全民健康信息平台——EHR 调阅、康复摘要上传医共体转诊——上转接收方案、下转回传进度。Phase 3长护险居家场景服务对象同步、服务计划下发/回传、签到签出/服务时长、费用申报/结算。9.4 接口依赖关系图 2 · Phase 1 核心接口依赖链HIS Adapter或自建登记→患者主数据→康复方案/医嘱→排程执行医保目录对码→收费项目映射→事前审核→门诊结算→对账冲正执行回传 HIS 与直连医保结算在独立机构场景互斥产品需支持双路径配置三个实施层面的关键依赖医保对码引擎必须先于结算接口——否则每家客户手工对码实施成本不可控按省预置康复项目模板库——比多接两家 HIS 更能降低边际实施成本移动端可与 Phase 1 并行——但依赖执行记录数据模型先定稿。十、实施成本与决策建议10.1 资源粗算模块阶段Adapter 框架 2 家 HISPhase 0–1社区患者/收费主数据Phase 0–1医保必选接口封装Phase 1移动端执行端Phase 1全民健康/医共体Phase 2长护险 居家Phase 310.2 五条功利主义决策原则第一Phase 1 不要贪多。两家 P0 基层 HIS创业慧康、ABC 医保必选六项足以支撑第一批社区项目上线。东软、卫宁放到 Phase 2用市场反馈验证产品方向后再扩展。第二产品层明确两条计费链。「HIS 回传计费」有 HIS 场景与「系统直连医保」独立机构场景在架构上用策略模式分离避免后期重构。二者互斥不可混为一套逻辑。第三把「收费项目模板库」当产品而非实施工具。按省预置康复医保项目、限价、自付比例实施时做配置而非开发——这比多适配两家 HIS 更能压缩边际成本也是社区项目能否规模复制的关键。第四社区客户 IT 预算低、接口配合差。SaaS/云部署 标准 Adapter 优于私有化定制。实施预期应显著低于三甲医院项目否则商业模式不成立。第五设备物联网是社区差异化的现实抓手。社区康复中心普遍存在设备利用率低、闲置率高的问题设备状态监控、使用绑定、训练数据采集以及居家训练数据回传是 HIS 厂商与康养平台均不会深做的能力——具备设备整合经验的方案在这一维度具备可验证的竞争优势但不应替代临床执行闭环这个根本。结语康复管理从医院走向社区本质上是信息系统角色边界的一次重划。在医院康复管理系统是 HIS 下游的专科执行层在社区它常常需要兼任患者入口、收费开单、医保结算、移动执行乃至长护险工单等多个「平台级」职能——同时又必须守住康复专科的核心方案制定、排程执行、频次管理、疗效评估、质控追溯与设备数据绑定。支付基础设施已高度统一患者档案体系已广泛存在但连接二者的康复专科闭环仍是空白。竞品在这一中间层尚未形成垄断窗口期取决于谁能以最低实施成本、最快复制速度把「医院级执行深度」与「社区级平台适配」结合在一起。路径是清晰的先做有 HIS 的社卫中心再做独立机构最后延伸长护与居家先接两家主流基层 HIS 与医保必选接口再扩展平台互联与区域复制。难的不是技术而是在产品架构上 early 做出正确的边界划分——什么接平台、什么自建、什么坚决不做。这决定了社区康复信息化究竟是一次成功的场景延伸还是另一场高成本低复用的定制泥潭。本文基于国内康复信息化行业实践、国家医保信息平台与长护险子系统建设进展、基层医疗卫生信息系统现状及医共体区域平台建设指南等政策与行业公开资料整理仅供行业研究与产品规划参考。