交付出件箱

C 端方案 · 第二轮自检(针对参照品B/影像回填等新决策)

dev2 · 2026-08-21 · 方法同上轮:把新决策里每条"能自动填/字段没有/复用现成"的话回代码验
结论:1 个必须先解决的架构级问题 · 2 个真窟窿 · 1 条我上轮说错了要更正

🔴🔴 架构级:系统里有两套检查数据模型,自动回填该写哪张没定

grep 出来的物理事实 —— 两张表都挂 patients,都存眼轴/视力/眼压:

	`vision_exams`(VisionExam)	`refractive_records`(Phase 63)
挂档案	✅ patient_id	✅ patient_id
谁在写	秒读/4L 的 OCR 写这张(`four_l_orchestrator.py:665` / `ocr_persistence_service.py:96` / `md_parser_service.py:381` / `bulk_importer.py:189` 四处 `VisionExam(`)	平板端席位手工录入
视力/眼压/眼轴/K1K2	✅ 全有	✅ 全有
主诉 / 既往史 / 身高 / 体重	✅ 全有	❌ 无
Worth4孔灯 / 交替遮盖 / 眼位	✅ 有(单字段文本)	✅ 有(结构化:数值+方向+AC/A)
球柱轴 / 矫正视力	✅ `rx_*`(处方口径)	✅ 自镜 `current_` + 主觉 `subjective_`
角膜散光 / 角膜中央厚度	✅ `ast_` / `cct_`	❌ 无
眼前节 / 眼底 / OCT 结论	❌ 无	✅ 有
视功能细项(立体视等)	❌ 无	✅ 独立表
防控手段	✅ 记录级 `prevention_history`	仅档案级(在 patients 上)

问题:方案说"拍照上传→自动回填检查记录",可 OCR 现在写的是 vision_exams,
而方案的档案检查记录是按 refractive_records 设计的。不定清楚会出现:
- 家长传的图识别后进 A 表,手填的进 B 表 ⇒ 同一个孩子两套记录、曲线取数不知道取哪张
- 或者要写同步逻辑,双写一致性又是新的坑

必须先拍板(三选一):
1. 归 vision_exams:顺 OCR 的势,补它缺的(眼前节/眼底/OCT 结论、视功能细项)
2. 归 refractive_records:顺 Phase 63 的势,补它缺的(主诉/既往史/身高体重/角膜散光/CCT),
并把 OCR 结果转写进来
3. 分工:秒读产生的进 vision_exams(它本来就是报告解读的产物),
家长手动建的检查单进 refractive_records,曲线从两张表合并取数

我倾向 2 或 3;但这是架构决策,影响后面所有实施,不敢替长官定。

🔴 窟窿 3:识别要不要吃「秒读 6 次/年」的额度

方案两条已定的事撞上了:
- 秒读限 6 次 / 账号 / 年
- 档案录入主路径是 拍照 → 识别 → 回填

而识别用的就是 4L/秒读那条链路。若照旧计数,家长一年只能建 6 条检查记录(还得跟"解读报告"抢额度)——
按 3 个月一查,一年 4 次检查 + 想解读几次报告就爆了。

要定:档案里的"识别回填"是否计入 6 次?
我的建议:不计入。两者成本口径不同(回填只做字段提取、不出 4L 解读长文),
且额度的本意是限"AI 解读",不是限"录数据"。⇒ 但需要在实现上把两条链路分开计量。

🔴 窟窿 4:OCR 出来的值,落库前有三处要转换(直接写会脏数据)

OCR 给的	模型要的	差在哪
`va_od` 字符串 "0.8"	`unaided_va_raw` + `unaided_va_decimal`(Numeric)+ `visual_acuity_notation`(decimal/five_point)+ `va_map_version`	要判记法、要换算、要带版本号(四元组口径)
`ref_od_ds/dc`(电脑验光的球柱镜)	模型只有自镜 `current_` 和主觉 `subjective_`	🔴 没有"客观/电脑验光"这一档 —— 电脑验光值落自镜是错的(自镜=现戴眼镜度数),落主觉也是错的(主觉=人工插片结果)
OCR 无轴位(`axis` 当前 prompt 不提取)	模型有 `*_axis`	回填后轴位仍需家长手填,UI 要提示

⇒ 建议:给记录加一档"客观验光(电脑验光)"球柱轴字段,别硬塞进自镜/主觉。

✏️ 更正:我上轮说错了一条

上轮我说「主诉/既往史/身高/体重咱没有」——错了。
我当时只 grep 了 refractive_record.py 一个文件,就写成了全仓结论;
实际 vision_exams 里 chief_complaint / medical_history / height / weight 全都有。

这正是仓库铁律里记过的坑(限定范围的 grep 写成全仓断言)。已在方案里改正。

顺带的好消息(验过)

影像上传有现成受管表:report_image 的 kind 枚举正好是
("refraction","axial","oct","fundus") = 电脑验光单 / 眼轴曲率报告单 / OCT / 眼底照相,
与长官定的四类一一对应,只需把 report_ref 从"4L task_id"扩展到能挂档案记录
但注意它同样带 org_id ⇒ 隔离改造要一并覆盖这张表(与窟窿 1 同源)

建议的下一步

先拍架构级那一条(检查数据归哪张表),它定了,窟窿 3、4 的实现方式才有唯一解;
再进阶段 2 出线框图。

云机环境 · 非验收证据。