FreeSeek
联系我们
MED · 医疗健康服务

智能体承接诊疗文书事务，让医生专注治疗

医生和护士每个班次都有大量时间耗在病历书写、电话沟通和支付方表单上。FreeSeek 在您的电子病历系统和消息渠道中部署智能体，承接这一层行政事务。诊断和治疗决策始终由您的临床团队负责。

可对接的系统
EpicOracle Health (Cerner)HL7 FHIRHISPACSLISWhatsApp Business API
应用场景 案例分析
行业现状

医疗运营现状

医院和诊所网络已经实现大部分病历的电子化，但围绕病历的工作仍以人工为主。护士对照表格逐个给出院患者打电话；医生在下班后补写出院小结；前台人员把传真和 PDF 里的转诊信息重新录入 HIS。即使已有 HL7 FHIR 接口，各系统之间也很少共用统一的数据模型，每一步都要靠人在系统间复制信息。

支付方的要求又叠加了一层负担。事前授权申请、编码质询和理赔拒付占用了大量收费人员的时间，还常把医生拉进与支付方的同行沟通。与此同时，慢病人群持续增长，按价值付费的合同依据就诊数月后的结局给予回报。医疗机构需要在两次就诊之间与患者保持持续联系，仅靠电话和人力，护士与协调员的数量远远不够。

医生文书负担

医生每天要在电子病历中花费数小时，其中很多在门诊结束之后完成。文书负担是职业倦怠和人员流失的主要原因之一。

出院后的照护断档

再入院考核和按价值付费合同让出院后 30 天同时成为临床风险和财务风险。多数随访仍依赖人工电话清单。

支付方摩擦

事前授权和理赔拒付会延误诊疗，并给收费团队带来大量返工。每家支付方都有各自的规则、表单和门户。

人手短缺

护士、编码员和前台人员难招难留。行政工作量持续上升，人员编制却基本不变。

智能体运行 · 示例

看智能体如何完成一项真实任务

每一步都是对业务系统的工具调用，全程留痕、可复核；结果交给指定负责人签字确认。

智能体运行 · 示例run_c2a57e
任务随访过去 7 天内因心衰住院后出院的患者。
  1. fhir.query()
    找到过去 7 天内心衰出院的 38 名患者，并加载其照护计划。
  2. whatsapp.send()
    发送第 5 天随访问询。31 人回复，其中 1 人报告 3 天内体重增加 2.4 kg，并新出现脚踝水肿。
  3. ehr.task_create()
    命中心内科危险信号规则，创建紧急任务，附上读数和患者原话。
结果 · 已将 1 名患者上报给心衰护士当天回电，后续处置由护士决定。
应用场景

四个业务流程，逐步拆解。

每个场景都说明：现在怎么做、智能体接手哪些环节、在哪里由人签字，以及我们衡量哪些指标。

MED-1出院随访与慢病随访MED-2出院小结与转诊信起草MED-3患者接诊登记与预约分流MED-4事前授权与理赔编码支持
MED-1

出院随访与慢病随访

智能体按计划持续联系出院患者和慢病患者，跟踪用药依从性，并将危险信号上报给护士。

集成深度 中等
典型试点周期8–10 周
现状

照护协调员根据导出的出院名单逐个给患者打电话。很多电话无人接听，记录写成自由文本，糖尿病或心衰患者可能几周都无人联系。漏服药物和症状加重往往要等到患者再次来急诊才被发现。随访覆盖面取决于协调员一个班次能打多少电话。

调用的系统
EpicHL7 FHIRWhatsApp Business APIWeComTwilio
智能体做什么
  1. 根据电子病历中的出院医嘱套餐、照护计划和用药清单，为每位患者制定随访计划。
  2. 使用照护团队审定的方案问题，通过短信、WhatsApp 或企业微信，以患者的语言按时发送随访问询。
  3. 将服药情况、居家监测读数和症状等回答记录为结构化数据，并把摘要写回病历。
  4. 按照临床人员制定的危险信号清单进行匹配，一旦命中立即转入值班护士队列；方案要求时，提示患者尽快就医。
  5. 每天早上向协调员汇报依从性趋势和未能联系上的患者。
人工把关点
每一条上报都由护士审阅并决定临床处置。问题集、危险信号规则和上报阈值在上线前及每次修订时都须经临床人员批准。
衡量指标
  • 30 天再入院率
  • 随访触达率
  • 危险信号到护士联系的时长
  • 用药依从率
MED-2

出院小结与转诊信起草

智能体根据病历整理出院小结和转诊信草稿，交由主管医生修改并签署。

集成深度 深度集成
典型试点周期10–12 周
现状

住院医师和主治医师需要翻阅病程记录、检验结果和用药变更来整理出院小结，常常在患者离院数小时后才完成。转诊信每次都要针对不同专科从头写。出院小结送达基层医生时已经滞后，有时遗漏待回报结果，或者用药清单与最终医嘱不一致。

调用的系统
EpicOracle Health (Cerner)LISPACSHL7 FHIR
智能体做什么
  1. 从电子病历和 LIS 中提取入院记录、病程记录、操作记录、最终用药核对结果和待回报结果。
  2. 按医院模板起草出院小结，每一句陈述都链接到对应的原始记录或结果。
  3. 标出矛盾之处，例如已停用的药物仍出现在出院带药清单中，或出院时仍有待回报的结果。
  4. 按接收专科的格式准备转诊信，并附上 PACS 中的相关影像报告。
  5. 将未签署的草稿放入医生的电子病历收件箱，并记录医生所做的每一处修改。
人工把关点
每份文书都由主管医生阅读、修改并签署。没有该签名，任何文书都不会发给患者或外部医疗机构。
衡量指标
  • 出院到小结签署的时长
  • 每份文书的医生修改时间
  • 带来源链接的陈述占比
  • 用药差异率
MED-3

患者接诊登记与预约分流

智能体收集登记信息，整理分诊队列，并按照工作人员设定的规则预约合适的科室和时段。

集成深度 中等
典型试点周期6–8 周
现状

转诊通过传真、邮件、门户和电话进入医院。前台人员手工录入人口学信息和保险信息，催要缺失材料，再凭经验判断该挂哪个科室或哪位医生。预约错配浪费专科号源，紧急转诊可能在共享邮箱里搁置好几天。分诊护士拿到的信息不完整，必须先回电患者才能排定优先级。

调用的系统
HISEpic CadenceHL7 FHIRe-fax gatewayWhatsApp Business API
智能体做什么
  1. 读取转诊单和门户消息，提取人口学信息、保险、转诊原因和随附结果。
  2. 通过患者门户或消息渠道联系患者，补齐缺失的登记表和知情同意。
  3. 对照各科室的接诊标准检查转诊材料是否完整，并为分诊护士起草优先级建议及其依据。
  4. 根据专科规则、支付方网络和患者偏好推荐科室、医生和时段，分诊确认后完成预约。
  5. 发送就诊提醒和检查前准备说明，并用候补名单填补取消的号源。
人工把关点
每份转诊的临床优先级由分诊护士确定。紧急病例以及智能体无法匹配规则的转诊，均由工作人员确认预约。
衡量指标
  • 转诊到就诊的时长
  • 转诊材料不全率
  • 爽约率
  • 专科号源利用率
MED-4

事前授权与理赔编码支持

智能体准备事前授权申请材料，并附病历证据给出编码建议，由编码员和收费人员审批。

集成深度 深度集成
典型试点周期8–12 周
现状

收费人员逐一查询各支付方的授权规则，把临床记录复制到门户表单中，再用表格跟踪回复。编码员通读整次就诊记录来分配 ICD-10-CM 和 CPT 编码，病历记录不充分时还要发消息询问医生。很多拒付的原因是病历里其实有相关记录，却没有提交给支付方。

调用的系统
Epic ResoluteX12 278/837HL7 FHIRpayer portalsICD-10-CM / CPT code sets
智能体做什么
  1. 对照支付方当前的授权要求，检查已排期的操作和药物。
  2. 汇总申请材料，将相关病历、影像和检验证据对应到支付方的审核标准。
  3. 为已完成的就诊建议 ICD-10-CM 和 CPT 编码，每个编码都关联到病历中的依据语句。
  4. 在记录不足以支撑编码精确度时，起草合规的医生质询，不诱导医生选择特定编码。
  5. 跟踪提交和拒付情况，并针对支付方指出缺失的证据起草申诉函。
人工把关点
理赔提交前，每个编码都由持证编码员接受或修改。每份授权申请由收费人员提交，每条文书质询由医生本人回复。
衡量指标
  • 授权周转时间
  • 首次拒付率
  • 编码员产能
  • 质询回复时长
案例分析

这个领域里的项目是怎么落地的。

示意案例：综合多个典型项目整理而成，已隐去客户信息。数据代表我们设计试点时的目标区间。

心衰随访覆盖到电话清单遗漏的患者

客户: 区域医院集团，4 家急症医院，心内科条线地区: 南欧
84%7 天内联系到的患者比例，此前为 46%
−21%心衰 30 天再入院率
−35%协调员用于常规电话的时间
挑战

心衰患者 30 天再入院率高于全国基准。两名协调员每月要电话随访约 300 名出院患者，一周内能联系上的不到一半。随访记录为自由文本，心内科医生无法看到两次就诊之间体重和症状的变化趋势。

我们做了什么
  • 搭建 WhatsApp 和短信随访智能体，问题集和危险信号规则由心内科护士编写。
  • 通过 FHIR Observation 资源将结构化回答和每日摘要写回电子病历。
  • 将命中危险信号的回答转入心衰护士队列，响应标准为 2 小时内。
  • 全部数据存放在欧盟境内环境中，并完成 GDPR 数据保护影响评估。
周期: 在 1 家医院试点 10 周，第 6 个月推广至全部 4 家

出院小结在出院当天完成签署

客户: 私立三级医院，600 张床位，内科和外科地区: 海湾地区
−42%每份出院小结的医生用时
71%出院当天签署的小结比例，此前为 18%
−30%审计中发现的用药差异
挑战

出院小结签署时间的中位数是出院后 3 天，基层医生反映常缺少待回报结果。住院医师表示晚上经常在补写小结。医院要求任何工具都必须将患者数据保留在境内，最终措辞由医生决定。

我们做了什么
  • 在医院内网部署起草智能体，通过 FHIR API 读取电子病历和 LIS 数据。
  • 草稿中每一句都链接到原始记录，并高亮待回报结果和用药矛盾。
  • 以未签署状态将草稿送入医生的电子病历收件箱，并记录所有修改供质控审查。
周期: 在 2 个病区试点 12 周，第 5 个月正式上线
风险与合规

患者数据、监管合规与临床安全

健康数据保护

部署遵循美国 HIPAA、欧洲 GDPR 第 9 条关于健康数据的规定，以及中国 PIPL 对敏感个人信息的要求，包括单独同意和必要时的数据本地化。我们签署业务伙伴协议或数据处理协议，数据保存在客户指定的地区。

限定在行政事务范围

具备诊断或治疗建议功能的软件，可能依据 FDA SaMD 政策、EU MDR 第 11 条规则和 NMPA 规定被认定为医疗器械。我们的智能体负责起草、收集、分流和提醒，诊断、分诊优先级和治疗始终由持证临床人员决定。

临床人员全程参与

临床内容只有在指定临床人员批准后才会发出，形式为签署的文书或预先审定的方案。每份草稿都标明来源，便于审核人员快速核对。

审计日志与危险信号上报

智能体的每一次操作、数据访问和人工审批都会记录用户、时间和来源记录。危险信号规则由临床人员编写，命中后立即上报至有人值守的队列，每次变更前都要经过测试。

常见问题
你们的智能体会诊断患者或推荐治疗方案吗？

不会。智能体负责文书草稿、接诊登记、预约、随访和支付方事务。包括分诊优先级在内的所有临床判断都由您的持证人员作出，这也使智能体处于医疗器械监管范围之外。

可以对接哪些电子病历系统？

我们通过 HL7 FHIR、HL7 v2 或厂商 API 对接 Epic、Oracle Health (Cerner) 以及各地的 HIS 平台。没有 API 时，我们与您的 IT 团队商定只读数据抽取方式。

患者报告危险症状时会怎样处理？

智能体将回答与临床人员编写的危险信号规则进行匹配，并立即转入有人值守的护士队列。方案有要求时，智能体会提示患者尽快就医或拨打急救电话。

患者数据在哪里存储和处理？

在您选择的地区，包括您自己的数据中心或本地云区域。模型调用运行在同一数据协议覆盖的端点上，患者数据绝不用于训练共享模型。

你也有类似的业务流程？

简单描述一下现在的做法，我们会在两个工作日内回复。

开始沟通
其他行业
MFG先进制造MAT新材料研发ENG工程设计FIN金融科技MKT市场营销