业务给的调整方向:去掉诊所名,加病历号、上次时间、上次医生、潜在治疗标签。
诊所名改成**按登录数据权限判断** —— 单诊所权限的人每行都是同一家,是噪音;跨诊所才有区分价值。

改的是两个组件(你截图的 10457 人那个列表是 patient-picker-rail,不是 plans-list-app 的卡片,
两处都按同一套字段改了,保持一致):

后端 plan.service.list —— 两条**整页批量**查询,不逐行发(本页 ≤25 人,都走 patient_id 索引):
- fetchLastVisits:DISTINCT ON 取每人最近一次 encounter_record ∪ emr_record。
  · 并集是必须的 —— 部分宿主 appointment.in_time 缺失,只有 EMR 能证明到过场
    (jvs-dw 实测有患者 0 encounter / 39 emr),口径与详情页 lastVisit 一致。
  · ⭐ 医生取**同一次就诊**的医生,不是"历史最常见医生",否则会「日期是A次、医生是B次」错配,
    客服照着说就露馅。doctor_name 只有 emr_record 带(encounter_record 实测两宿主都 0% 有名),
    故同一时刻并列时优先取 emr;取不到名返 null,不拿 doctor_id 顶替(工号对客服无意义)。
    测试服实测覆盖率:池内 2,990 个有就诊记录的患者里 2,966 拿得到医生名(99.2%)。
- fetchPotentialTreatments:取当前版画像 potential_treatment.labels。
  它与卡片上的"召回理由"高度重叠但不等价:画像覆盖该患者**全部**潜在治疗,
  召回理由只是其中"这次值得召回"的子集。业务要的是前者。
- patient select 补 medicalRecordNumber(jvs-dw 覆盖 91% / friday 63%,缺则前端不占位)。

前端:
- 行1 追加病历号(mono,弱色);行2 的诊所名加 showClinic 闸;
- rail 新增第三行:潜在治疗 chips(左)+ 上次到诊·医生(右),两者全缺则整行不渲染、不虚占行高;
- 列表卡片:chips 接在场景/状态之后,上次到诊放底栏 meta 位。
- PotentialTreatmentChips 刻意比 ScenarioChip 弱一档(无底色、细描边):场景 chip 是
  "这次为什么召"=主信息,潜在治疗是"这人还有哪些没做"=背景信息,抢色会让客服分不清主次。
  卡片铺 3 个、rail 铺 2 个,其余折 +N(卡片是扫读用的,标签一多就不是信息是墙)。
- ⚠️ showClinic 判据是 `visibleClinics(user).length !== 1` 而不是 `> 1`:
  诊所字典未加载时 visibleClinics 返回 0(集团级用户 clinicIds 为空 → 回退全字典 → 字典空则 0),
  按 `> 1` 会把集团级用户也误隐藏。只在**确知单诊所**时隐藏,未知一律显示。

验证(本地):rail 行实测渲染为
  「张红 女·43 岁 WY0A007548 / 177****4845 / [潜在种植][潜在根管]  2022-06-19 · 张 敏」
诊所名「元和王永口腔」在该单诊所账号下已隐藏。654 tests / 42 suites 全过;
@pac/service 与 @pac/web typecheck 通过。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>