医疗健康

门诊可及性分析代理

找出预约为何被错过,以及那些没人记为损失的产能

版本 2发布于 2026年9月2日
医疗健康Extractclaude-opus-5Read-only · auto9 hard rules5 handover rulesResult
9条硬性规则
它绝不能做的事,每次运行都强制执行
5条移交规则
它停下并把工作交给人的条件
12个输出字段
结构化的结果,而不是一段需要反复阅读的文字
≤6步每次运行
有界的工作:最多 4 次工具调用,由运行时强制执行

设计上即为只读。 该智能体没有任何发送、支出、发布或提交的途径。当这一限制本身就是产品时,取消它就等于取消了信任其输出的理由。

版本 2 的实时接线图。工具节点是这个智能体被登记可以调用的能力——除此之外什么都跑不起来。

概览

每一家诊所都有相当一部分产能,损失在没人来赴约的号上,而标准回应——收费、超额预约、更多提醒——全都把它当成患者行为,而且全都让最难来的那群人更难获得就诊。

那些模式说的是另一回事。爽约是集中的:集中在提前很久预约的号上、集中在一天里的第一个时段上、集中在难以抵达的时段上、集中在那些通知信在就诊日之后才寄到的人群上。这些都是排程和沟通层面的事实,而每一样都在诊所自己的掌控之内。

同一批数据里的第二样东西,是那些根本不是因为患者而损失掉的产能:提前充分告知取消、本来来得及重新排上、却从来没被排上的号;候诊名单还排着队、诊次却提前结束;房间被预定给了根本没有发生的诊次。没有人把那记为损失,因为并没有人「没来」。

这个智能体把两者都报出来,附上能挽回每一项的排程改动,以及它折算成多少个号。它只处理运营层面的模式。它不作任何临床判断,绝不对任何一位患者作画像或评分,也绝不建议任何会让某个人被降低优先级的做法。

价值

不加诊次就挽回产能

其中大部分本来就在那儿,只是没被用上。

改善就诊可及性,而不是配给它

这些修补是排程层面的,不是处罚。

会动起来的候诊名单

因为那些可以被重新排上的号,真的被重新排上了。

功能说明

  • 先检验预约提前期

    爽约率随着「提前多久预约」陡峭上升。这是最强的那根杠杆,而且完全在你手里。

  • 找出人们到不了的时段

    一天里的第一个时段,或者一个要换两趟公交才能到的时段。那是排程事实,不是患者的过错。

  • 把没人记为损失的产能数出来

    提前告知取消却从来没被重新排上的号,以及候诊名单还排着队、诊次却提前结束。

  • 核对通知信是否及时送达

    某个人群的沟通落在了就诊日之后。看不见,而且完全可以修。

  • 把每一处改动折算成号数

    这处修补能挽回多少,好让它能和其他选项公平地竞争。

  • 绝不对患者作画像

    它不产出任何个人风险分,也绝不建议任何会让某人被降低优先级的做法。只看模式。

这会改变什么

这会如何改变你的一周

它接手的工作
找出号为什么被爽约,以及产能实际去哪了。
目前由谁完成
用收费、超额预约和更多提醒来回应。
多久一次
只被当成一个比率来看,从不被当成一种模式。
通常的人工投入
预约提前期、时段、人群和沟通时点,都要分别分析。

为什么偏偏是医疗健康。爽约集中在诊所自己控制的东西上——预约提前期、一天里的第一个时段、迟到的通知信。而那些因未被重排的取消而损失的产能,从来没被记为损失,因为并没有患者「没来」。

  • 无人值守运行

    由你或某个事件启动,然后自行完成。没有什么需要等人坐到工位前。

  • 每一次都是同一标准

    第两百件与第一件用同一把尺子衡量。一致性正是人做不到长期保持的部分。

  • 它无法自行采取行动

    门诊可及性分析代理 没有任何发送、支出或承诺的途径。正是这个限制,让依据它的输出行动是安全的。

运行方式

该智能体通过 PROMIVO 运行时在服务器端运行。每次运行都会逐步记录,每次工具调用在执行前都会进行权限检查。

  1. 1输入按智能体的输入结构进行校验
  2. 2模型claude-opus-5,并自动回退
  3. 3工具extract_structured_data
  4. 4权限自动执行 READ 级操作;更高的等待你批准
  5. 5输出符合输出结构的结构化结果
  6. 6日志记录 token、耗时和每一个步骤

演示

演示数据Illustrative sample output, abridged.

输入

{
  "period": "H1 2026",
  "appointments": [],
  "suppressionThreshold": 10
}

输出

{
  "escalate": true,
  "disclaimer": "An operational analysis of appointment records. No clinical judgement has been made, no individual patient has been scored, profiled or identified, nothing recommends deprioritising or charging any patient, no appointment has been changed, and cohorts below ten are suppressed.",
  "slotPatterns": [
    "The 08:00 slot is missed at 2.4x the clinic average. The first bus arriving at that site is 07:52."
  ],
  "cohortPatterns": [
    "One cohort's non-attendance is 2.1x the average. The communication timing finding below appears to account for most of it, which makes it a fixable operational cause rather than a patient one."
  ],
  "leadTimePattern": [
    {
      "leadTime": "0–7 days",
      "appointments": 2100,
      "nonAttendanceRate": 4.1
    },
    {
      "leadTime": "8–28 days",
      "appointments": 4800,
      "nonAttendanceRate": 9.8
    },
    {
      "leadTime": "29–84 days",
      "appointments": 3900,
      "nonAttendanceRate": 19.4
    },
    {
      "leadTime": "85+ days",
      "appointments": 1400,
      "nonAttendanceRate": 31.2
    }
  ],
  "escalationReason": "Non-attendance differs materially between cohorts and appears linked to communication arriving late, which is an equity of access finding; and 610 refillable cancellations went unfilled against a waiting list of 1,900.",
  "cohortsSuppressed": 4,
  "fixesWithATradeOff": [
    "Overbooking the 08:00 slot would recover roughly 120 appointments and would transfer waiting time to patients who did attend. Listed last for that reason."
  ],
  "communicationTiming": [
    "For 340 appointments, the letter was sent fewer than 3 days before the date. Those show a 27% non-attendance rate against 9.8% for the same lead time band overall."
  ],
  "suppressionThresholdUsed": 10,
  "fixesWithNoCostToPatients": [
    {
      "change": "Cap routine booking lead time at 28 days with a partial booking model",
      "appointmentsRecovered": 740
    },
    {
      "change": "Refill cancellations with more than 48 hours notice from the waiting list",
      "appointmentsRecovered": 610
    },
    {
      "change": "Send communication at least 7 days ahead for every appointment",
      "appointmentsRecovered": 90
    }
  ],
  "capacityLostWithoutAPatient": [
    {
      "note": "A waiting list of 1,900 existed throughout. Nobody failed to attend these — they were simply never offered to anyone.",
      "cause": "Cancellations with more than 48 hours notice, never refilled",
      "appointmentsLost": 610
    },
    {
      "note": "",
      "cause": "Sessions finishing early against booked capacity",
      "appointmentsLost": 180
    }
  ]
}

使用条件

集成

无需集成。

开始之前

  • 预约记录:预约日期、就诊日期、结果、时段、诊次
  • 取消记录,含提前告知时长,以及该号是否被重新排上
  • 沟通发出日期,如果你有的话
  • 候诊名单规模
  • 需要 全量访问 套餐或更高

使用场景

可及性与产能复核

产能实际去哪了。

爽约率在上升

是哪一种模式在推高它。

在增加诊次之前

现有产能是不是已经先被用满了。

就诊公平性复核

出勤率在不同人群之间是否有差异,以及哪些排程因素能解释它。

价格

全量访问

通过您的 PROMIVO 订阅按月计费,可随时取消。

运行会消耗您套餐中的智能体执行次数与 token 额度。参见 套餐限额

常见问题

它会给患者个人打分吗?

不会,而且它拒绝这么做。对个人爽约作预测,会导向把最需要照护的人降低优先级。它只报告运营层面的模式。

它会作临床决定吗?

绝不。它不作任何形式的临床判断,不评估紧急程度,也绝不建议改变任何人的临床优先级。

它会建议超额预约吗?

只有在数据支持「重新排号」而不是「重复排号」的时候,而且它会明说超额预约是把代价转嫁给那些真的来了的患者。它会优先给出不产生这种代价的改动。

它会处理患者数据吗?

它分析预约记录,并报告汇总层面的模式。它不复述任何患者标识符,并对低于你所设定规模的人群作抑制处理。

评价

客户运行过该智能体后,评价功能将开放。

需要这个智能体换一种做法?

告诉我们要改什么,我们的团队会为您的业务规划一个定制版本。

定制此智能体