患者、预约、到诊与护理 PRD

更新：2026-09-14 · 责任：Line A · 配套：业务总流程／测试用例

本篇说明患者从资料登记、预约到实际到诊的工作流程。前台负责预约和基础资料维护，护士按所在诊所及服务医生关系完成签到和护理准备。各入口共用同一份患者资料，访问范围见 权限方案。

本次权限调整已写入需求，仍待对应实现和验证。此前回归及发布记录见权限验证。

功能地图

按患者建档、预约、实际到诊三个业务对象组织；界面、字段与异常放在所属功能内。

1. 三个入口如何协作

Patient & eMR 管一个人的长期资料，Appointment 管某次预约安排，Registration 管当天到诊和准备。三者共用患者主档和同一预约／Visit 关联。患者从哪个入口来，不应决定他有几份档案。

旧设计的“只保留 Overview／Timeline”不覆盖后来确认的患者级历史 Tab。页面数量也不构成业务验收指标。

2. Patient & eMR

Patient & eMR 保存患者的长期资料，也是查询历次就诊的入口。工作人员先搜索患者，核对身份后打开已有档案；确实没有记录时，再按建档权限新建，避免重复登记。

前台可以维护基础信息；护士和医生按各自权限维护其他资料。患者可以关联多家诊所，查询基础信息、修改主档和查看完整病历分别判断。保存后的主档由各业务入口共同使用，历次就诊仍引用原记录。

2.1 字段定义

患者卡片的诊所标识： 只展示患者资料返回的有效诊所关联名称；多个诊所并列，不建立单一 Primary Clinic。没有诊所名称时，只有后端明确标记与当前诊所有关联，才可显示当前诊所名称并标明关联；其他诊所显示 Other clinic，关联未知则显示未记录。当前岗位、Nurse／Doctor 角色和工作场景不能填入患者卡片，也不能因患者可被搜索就将其归到当前诊所；当前操作者身份仍可在工作台顶部显示。此展示修正不扩大历史读取或护理授权。

2.2 创建、重复校验与修正

PT-01～PT-04： 先搜索再创建；证件完全匹配或规范化姓名＋主手机号同时匹配时阻止重复保存，显示命中依据，允许打开已有患者或返回修正。单姓名或单电话相同只提示候选。本期不自动合并患者；治理人员处理误匹配／确需合并的操作规程仍待确认。

保存后各获授权业务入口读取同一最新主档。修改需要原因及新版本；恢复旧内容也应形成新版本，不销毁后续历史。同集团具角色查询权限的人员均可搜索和查看患者基础信息，不受当前诊所关联限制；修改、确认与临床历史分别校验。前台可新建、修正和确认基础信息，不能维护医疗／安全资料或保险计划。护士创建或管理预约仍限当前 Clinic 的有效服务医生范围。预约可以保留运营关联，但不产生患者资料维护资格；有效首次建档来源、既往 Visit 或另行批准的接收资格按 患者资料维护规则 判断，也不开放他医 Note／处方。搜索精确字段和脱敏默认见 组织、数据权限与授权方案。此规则取代旧的 Patient & eMR 一律仅显示当前诊所患者口径。

患者资料保存边界： 基础资料查询按集团及角色授权返回，敏感字段默认隐藏；申请查看须提示操作审计并经独立字段权限判断，详见 Platform §3.2。有维护动作权限，且当前诊所为患者所属诊所或已取得转诊／推荐／另行批准的新预约资格时，才能维护相应患者资料；普通登记 link 和预约 Confirmed 不代替批准。编辑页只提交实际修改的可维护字段，未返回的病史或保险数据不视为空值。最小安全摘要的更正另需选择本人负责的 Visit，并保留原详细备注；身份版本与安全摘要版本分开分类。

保险资料独立保存： 保险卡按当前诊所运营权限单独加载与保存，不随患者资料版本隐式覆盖或删除。保存前校验整组待修改卡片，仅可删除本次确实加载过的卡片；新增、修改及删除记录实际操作者和变更原因。若多卡保存部分成功，必须重新读取当前记录再继续，不能将保险保存结果描述为患者资料版本已整体保存。

2.3 历史查看与附件

疫苗为同集团公共记录，获独立公共医疗信息角色读取授权的医生与护士跨诊所读取无需原医生逐记录批准，旧记录缺少 Visit 来源不影响读取；写入仍保留原医生权限及修改审计。其余信息按 数据分类与读写矩阵 逐项判断：同集团公共医疗摘要、生命体征等共享资料仍需角色级读取授权，不因来源医生不同逐记录审批；完整 Note、诊断详情、检查结果、正式临床文档、历史附件及处方按来源医生授权判断，药房执行读取另按对应诊所范围，隐私字段独立检查；当前患者可搜索或本次已预约，不表示全部历史可读。受限时提供共用申请入口，不返回正文后再遮罩，也不显示为“无病史”。

2.4 患者持有的保险与企业计划

患者资料编辑的 Insurance cards 页签、共享维护组件及 Overview 汇总统一为 Insurance & Benefit Programmes。Add programme 从一个共享目录选择保险、企业计划、员工福利；保留真实类型和 Policy／Benefit Contract 来源，不合并成 insurance 类型。空记录不代表 Self-pay。

• 保险字段为 Insurer、Member no.、Policy no.；企业为 Organisation、Member / employee no.、Programme no.；员工为 Organisation、Employee no.、Programme no.。有效期与患者计划备注一并维护。
• Primary 文案改为 Patient default，表达患者档案偏好；它只用于展示排序，不替患者选择本次付款安排。
• 更换目录计划时保留患者持有记录及默认标记，但清空旧个人编号、有效期、资格和备注，防止将旧计划资料套入新计划；重复选择同一计划保留已填信息。
• 患者计划维护及预约选择共用类型语义；读回时保留元数据中的企业／员工来源，维护无目录 ID 的旧计划亦不得丢失已记录的类型。修改患者主档不自动重写预约／Visit 的历史快照。
• 公开预览仅使用显式 preview 路由的合成患者及目录；资料编辑可应用到页面会话，刷新重置，不调用真实主档保存接口，也不模拟正式版本审计完成。

2.5 附件上传与识别

本次附件由关联护士管理。 护士在当前诊所服务本次负责医生，并具有附件操作权限时，可以上传、查看和删除本次问诊附件，无需额外申请临床记录授权。前台不管理附件。

查看历史附件时，应检查原记录授权；当前服务关系或将文件复制到本次，都不能代替批准。删除操作保留来源和审计，保护已签版本及引用证据。附件管理也不授予正式临床文档撤销权，详见 权限方案 §3.5。

• 每个附件最大 10 MB（10 × 1024 × 1024 字节），允许等于上限；多选时逐个文件上传，不把多个文件合并计算。超限在选择时明确提示；服务端仍独立校验。该上限用于统一文件接口，不改变 Excel 导入或录音专用接口的独立规则。
• 选择文件后的状态是「Ready to upload」，必须点击 Save attachments 才写入。发送时显示 Uploading，失败显示 Upload failed 及可重试错误；每个成功文件立即显示 Uploaded 并关联 Patient＋Visit，后续文件失败不反转已成功结果、不重复上传成功文件。
• 文件保存与 OCR 是两个独立结果：识别尚未完成／失败不使已保存附件变成 Pending。识别失败保留原件；同内容文件在另一 Patient／Visit／Clinic 必须分别建关联，不能按文件内容直接复用别的问诊附件。
• 当前改动待本轮专项验证；Git、预览发布、STG 配置生效和业务 UAT 分别记录，执行证据见 agent_docs/test_cases/attachments/validation-20260908.md。

3. H5 自助填报与审核

功能目的： 减少重复录入，由患者确认信息、护士审核后写入正式资料。

使用者与对象： 患者处理专属填报草稿，获授权护士发码与审核。

操作与结果： 预填发码 → 患者填写并确认身份关联 → 提交 → 护士核对／修正 → 批准或退回澄清。

关键边界： 提交不直接覆盖主档；身份修正或旧确认缺失由护士核实处理，修正、核实依据与患者原始 Consent 分开留痕。

2026-09-07 用户确认（取代旧的提交后常规重复患者核验）： 在患者填写后的核对确认环节完成匹配；患者确认本人信息一致后关联已有患者。护士审核页展示已确认结果，不常驻疑似重复提示或再次要求关联同一患者。

PT-06 状态： Intake Draft → 有效患者专属链接 → 身份匹配／患者确认关联或新患者 → Submitted → Awaiting review／Needs clarification → Approved 或 Rejected。身份更正导致确认失效时保留待审核，由护士核实后继续；链接 Expired 由服务端控制，不使已提交资料必须重填。

界面： 审核时收起非当前任务的患者搜索栏和重复待办横幅；主区使用全部可用宽高。列表与详情随 App 容器宽度改变，760px 以下变为横向选择列表＋纵向详情，480px 以下详情字段单列。正文滚动、主要动作保持可达。Pending／Clarification／Reviewed 可切换；历史及原始提交在处理后仍可查看。编辑中取消须确认丢弃。

审核权限与归属： 正式审核由获授权护士按当前有效 Clinic 任职及生效权限执行；前台的基础字段维护权不包含整份 H5 提交批准：查看需要 patient.read，修正、批准、拒绝、待澄清及重发需要 patient.write。填报草稿绑定发码时的集团与 Clinic；有预约关联时必须与该 Clinic 和患者一致，不能凭患者姓名、预约地点或 Confirmed 状态自动跨诊所转移草稿。护理的 Provider 服务范围与患者基本资料登记分别管控，审核不授予完整 Note／历史处方权限。

审核中的保障卡选择使用患者登记所需的最小有效卡种目录，不额外要求保险合同管理权限，也不开放合同配置或图片管理接口。首次队列加载失败必须明确显示错误及重试入口，不能显示为没有待审核资料；保存过程中禁止继续修改字段，避免提交后遗漏修改。

批准与资料写入： 审核使用服务端保存的患者确认或护士核实结果，界面不能提交另一个 Patient ID 强行关联。已有患者仍必须满足当前 Clinic 的主档维护资格；仅有普通预约不绕过该资格。新患者在批准事务中完成重复身份检查、建档及注册来源 Clinic 归属；批准失败不留下半条患者或保障记录。提交、修正和最终批准保留原始提交、当前版本、操作原因和实际操作者，批准同时校验填报版本和已有主档版本；另一人已处理或主档发生变化时必须刷新核对，不能用旧画面覆盖新资料。

护士核实与异常处理（2026-09-14 用户确认，取代默认退回病人重新确认）： 正常自填审核由护士处理。非身份修正保存后可继续批准；身份字段实质变化、旧记录缺少可信身份确认凭据，均显示「待护士核实身份」，不自动退回病人。当前 Clinic 下具 patient.write 的有效 Nurse 可在审核页记录核实依据并执行「护士核实身份」。服务端依据当前提交重新匹配，返回已匹配病人编号或新病人结果；护士核对该结果后批准。患者原始提交及 Consent 保持不变，护士核实单独记录来源、操作者、诊所、时间、依据及草稿版本，不伪装为患者重新确认。

护士核实不能绕过已有病人的主档维护资格、预约病人一致性、重复身份检查或并发版本控制。匹配冲突时护士应核对修正资料或按现有主档流程解决冲突；系统不允许任选其他病人或强行新建。已提交资料即使旧链接过期、已经重发或处于待澄清，也可由护士核实后继续审核；没有提交内容的空草稿不能核实，已批准／拒绝／撤销／旧版 reviewed 不可重开批准。

仅在护士无法解决的信息疑问、确实需要病人补充时才使用待澄清及可选重发链接；重发的 48 小时有效期、旧链接失效和历史保留规则继续适用。护士不能代填个人资料 Consent 或通信同意；缺少必要 Consent 的记录仍需补齐真实患者同意，不得通过身份核实动作自动生成。旧版 reviewed 仍仅表示旧版已审核，新 approved 才表示本流程事务写入成功。

实现边界： 已有正式令牌／提交服务；本轮接通真实审核页面与审核状态、原始提交／修正历史、版本校验、患者确认及事务写入。独立预览仍只使用合成数据，不充当保存结果。2026-09-14 护士核实改动及本轮验证／发布状态见护士核实执行证据；此前流程验证见原执行证据；本段不声明目标环境已发布或 UAT 已通过。

4. 预约与资源日历

功能目的： 把患者、医生／资源、时间和本次付款安排组成可执行的预约。

使用者与对象： 前台／护士及获授权医生；对象为 Appointment、Provider 和 Resource。

操作与结果： 选择患者和有效时段 → 填写预约与付款安排 → 保存／确认 → 到诊时进入 Registration。

关键边界： 保存预约不等于签到，不赋予跨诊所资料编辑或他医病历权限。

4.1 新建及编辑字段

4.2 操作、状态和异常

AP-05 未指定医生： 先记录诉求、症状及必要背景，按专科、诊所、排班、语言和付款限制提供候选医生及理由，由患者或授权人员最终确认。信息不足或无匹配转人工；推荐不构成诊断，也不自动保存预约。该推荐闭环仍是目标，不能以固定医生列表或专科字段代表已实现。

AP-01～AP-04： 新增、日历空格、Reception、患者档案与复诊共用同一预约入口；一般保存状态按明确选择，Reception 新增默认 Confirmed。Unconfirmed 可确认或由 Confirmed 退回；改约与换医生走 Reschedule。取消保留记录并释放有效时段，当日取消排在有效日程之后。

日历布局： 左侧日历与右侧所选日期 Grid 使用同一时间比例，卡片位置及高度反映实际开始时间和时长；短预约不能因文字或按钮的最小高度而覆盖相邻预约。左侧优先显示时间与患者姓名，再按可用高度逐层显示预约类型、医生及状态；右侧短卡及重叠列使用紧凑内容，较长卡片才展开补充资料。完整姓名、医生、类型、状态及预约备注可通过悬浮或键盘聚焦提示查看，不把被省略的内容画到卡片背景外。Grid 保留 Detail 与 More 两个紧凑入口，确认／退回未确认、Check-in、打印标签、提醒、历史及取消仍通过原权限与状态校验后操作；不足以容纳按钮的极短预约使用整个事件条打开完整详情及全部操作。More 可用键盘打开、遍历并以 Escape 关闭。List 保留现有资料列与操作排列。

预约范围（2026-09-08 用户确认）： 护士可查询同集团各诊所预约并创建预约；跨诊所总览不提供直接改期／取消。只有原本具目标诊所维护权，切换到该诊所作为当前工作诊所后才能修改；无维护权不允许靠切换或修改请求参数取得。医生的有医生参与预约按本人或有效显式授权过滤，列表、日期统计、医生选项和直接详情一致，完整关系规则见 组织、数据权限与授权方案。Calendar 显示当前操作诊所与记录来源；切换后清除失效编辑表单并丢弃旧请求。

新预约仅提供本次业务资料。医生需要其他医生既往记录时，从患者详情的共用申请抽屉发起申请，不因为预约成功或恢复诊所关系而直接开放历史。申请流程不阻塞已获授权的身份核验和预约工作。

仅关联护士可使用 Calendar 的 Check-in 跳转 Registration，跳转不提前签到；前台不显示签到入口且直接接口拒绝。Ready 后须带原因回 Preparation 才允许修改或取消；已 In Consultation 的患者不能从前台取消。已到诊记录的回退／取消由获授权关联护士按状态处理；涉及 Appointment 与 Visit 时同一事务提交，失败整体回滚，前台不能借取消预约操作改变签到／护理状态。

Doctor Block-out 填医生、日期、开始／结束、原因及备注。普通问诊与 Prescription-only 不能落入 Block-out；No Consultation 只按护士服务例外处理，仍需检查资源。已有预约不能因新增 Block-out 被悄悄删除或改期。

完整资源需要稳定 Resource ID、诊所、能力、容量、开放时间、Block-out、启停及权限；同预约多个 Assignment 共享主预约。容量冲突、多资源改约、资源停用影响分析仍为待开发设计。

No-show 宽限时间、迟到优先级及收费、资源冲突允许的例外尚待确认；没有确定参数就不预设“迟到多少分钟自动取消”。

4.3 本次付款安排

New / Edit Appointment 与 Registration 共用 Payment Arrangement 组件。它选择本次主要付款／保障安排；Cash／Credit Card 等实际收款方式及金额仍由 Cashier 确认。

• 上层仅三项：To be confirmed、Self-pay、Insurance & Benefit Programme。保险／Corporate／Staff 共用一个可搜索的患者已持有计划列表，小标签说明类型，不要求用户先区分合同来源。选择一个具体计划后，系统保留 insurance／corporate_membership／staff_benefit 的真实类型。
• 新预约初始为待确认。患者主卡／默认计划只决定展示优先级，不自动成为本次选择；无卡也不自动意味着自费。待确认可以保存及签到，但必须在完成 Preparation 前明确。
• 选了计划入口但没有选具体计划时不得保存，应选择计划或改为待确认。资格有效日期按预约／Visit 日期判断；选计划不等于已核验，更不等于已获全额支付保证。
• 自费只显示本次自付说明，不显示保险卡、资格或 Case 字段。计划显示机构、个人编号、保单／计划号、有效期与本次 Reference／人工计划审核／Coverage notes；企业与员工不叫 Insurer／Policy。
• 编辑和重新打开必须恢复本次已保存的选择与 Snapshot，不按患者当前默认计划或数组第一项重新选。患者主档后续修改不覆盖历史预约／Visit 的付款快照；同一已选计划重复点击保留本次填写内容。
• 更换患者、类型或具体计划，清除原计划的 Case、资格及备注；换后重新录入的本次信息明确绑定当前选择，不继承旧核验结论。患者个人主档不会被预约修改。
• 计划来自患者自己的已持有记录。后端验证患者归属和类型并生成 Snapshot，不信任客户端伪造的计划详情。保险引用 Policy；企业／员工引用对应 Benefit Contract，继续沿用现有主档。
• 预约保存至既有 clinic_appointments.metadata.payment_arrangement，包含版本、类型、持有记录 ID 和来源／基本资料 Snapshot；兼容旧 insurance_* 字段，保留其他 metadata。Check-in 传入 Visit 的 payer_snapshot，登记准备可保存本次安排并同步原预约；本次修改记录审计。
• 已进入 Ready／问诊后的安排变更需先按现有流程回 Preparation；存在账单时拒绝通过预约／登记直接更换，走 Cashier 调整。不会重写原发票、付款金额或临床签署记录。
• 企业／员工计划可能仅提供协议价或福利；不能仅凭选中计划建立企业应收或假定企业付款。后续保险全额／CoPay、实际收款及欠款确认统一进入 Cashier 付款责任，本次选择和人工核验只作为该步骤输入。
• 旧预约按其自身保存信息兼容读取，明确旧 Self-pay 保留自费，已有保险 Snapshot 保留保险，空值为待确认；无法可靠辨认的旧企业记录不按名称猜测类型，需重新选明确计划。旧 Visit 无新版付款快照时继续原有准备契约。
• 查询失败保留已保存选择并显示重试；搜索无结果与患者无计划分别显示空状态。选择器支持键盘焦点，所有新／编辑预约入口继续共享实现。

代码、本地浏览器、隔离 API／CI、预览发布与正式后台／UAT分别记录于 agent_docs/test_cases/appointment_payment/validation-20260907.md。

4.4 本次计划人工审核

Appointment 与 Check-in／Preparation 的计划板块统一提供 Review and confirm manually（人工审核确认）。展开后逐项确认：已核对患者卡及所选计划、已核对计划或个人资料变化、已核对本次日期的有效期；另分别记录资格结果和预先申请结果。此入口不调用旧保险 Check／Benefit QR 校验，不将本地资料比对表示为保险公司实时答复。

• 资格结果：Eligible（人工确认）、Not eligible、Awaiting confirmation。预先申请：确认不需要、需要且已获批、申请／批核待处理、尚待确认；选择已获批时必须填批核凭据编号。审核备注可记录确认方式、变化、限制及跟进事项。
• Confirm manual review 记录本次表单审核；保存预约／登记后，服务端记录实际登录审核人、UTC 时间、上述核对项及结果，绑定本次计划快照和就诊日期，并随 Appointment → Visit 保存。界面显示明确的人工审核结果；单独提交旧 Checked 或伪造嵌套审核人／时间不能建立审核证据。
• 待确认、不合资格、申请待批可以保存、签到或继续 Preparation，但不能完成准备交接。只有三项核对完成、人工确认合资格、无需预先申请或已获批，且计划在就诊日期有效，才能完成准备。自费继续不需要计划审核。
• 相同计划和日期再次保存保留审核人、时间和结果；更换计划／患者或就诊日期后重新审核。旧计划 Snapshot 的历史内容不由患者主档更新自动覆盖。已进入临床阶段或已有账单的变更继续沿用 §4.3 限制。
• 人工确认不是付款保证；第三方责任、自付金额、最终收费复核和实际收款仍由 Cashier 处理。旧 Visit 无新版付款快照的兼容契约不在本次进行历史数据迁移。

代码与验证证据见 agent_docs/test_cases/appointment_payment/manual-review-validation-20260907.md；公开预览使用合成记录及 Preview staff，真实审核人由后端认证上下文写入。正式后台部署、端到端联调与业务 UAT 单独验收。

5. Registration 与护理

功能目的： 把实际到诊患者完成必要准备后交给正确的医生或服务队列。

使用者与对象： 当前 Clinic 与负责医生有有效服务关系的护士；对象为同一 Appointment 关联的 Visit 及准备记录。前台无签到及护理执行权。

操作与结果： Check-in → Preparation → Ready；回退到相邻阶段保留同一 Visit、已填资料和原因。

关键边界： 准备未完成不交接；已经问诊的患者不从前台直接取消。

RG-01： 当日 Confirmed 进入 Awaiting check-in；未确认只留 Calendar。核对真实到诊后，写入一次关联 Visit、付款保障快照与到达记录。Check-in 读当前主档，仅回写员工实际修改字段，自动带值不能触发无意覆盖。

RG-02： Checked in → Preparation → Ready for consultation 必须逐步推进。身份三项齐全，本次付款安排已明确；选择计划时本次资格核验和有效期准备完成；被要求的 Vitals／Doctor pre-check 真实填写。页面自动读取核验结果，不新增几套重复“已核验”勾选。

RG-03 队列排序目标： 默认按实际到达时间优先，无到达时间才用预约时间；人工排序限同一运营分组。下游追踪记录不混入待处理队列；共享排序持久化未完成前，不声称跨终端已同步。

RG-03～RG-04： 护士成功后留在 Registration；Visit 同时出现在正确队列。No Consultation 到护士／服务队列，其余医生参与类型目标进入医生队列。Ready → Preparation 需原因且从医生队列移除；Preparation → Checked in 保留同一 Visit 和已录资料。

Walk-in 无预先预约也必须建立可追踪 Visit，来源标清。具体是否强制先建即时 Appointment 仍需确认，不能允许后续临床记录没有 Visit。

6. 测试入口与已知缺口

PT、AP、RG 用例检验正常流程、重复患者、跨诊所关系、取消／回退及幂等。H5 服务端、完整资源、共享队列排序、可配置准备门禁及特殊类型分流必须按实现记录标为部分实现／待开发；不能因页面可以点过就记 Pass。

全局主体切换与 Registration 范围（已确认）

Registration 只使用全局 Context Selector 的当前 Clinic／主体，不提供 App 内跨诊所混合筛选。Reception/Nurse 只能读取当前主体授权范围内的登记、到诊、候诊队列和患者基础资料；Nurse 还必须满足本人有效服务关系及医生授权。切换到另一有效主体后，重新获取 auth context/ui_access 并加载该主体数据；切换清空旧患者、队列、历史、角标、未保存表单及进行中请求，迟到响应不得回写新主体。列表、详情、签到、准备、回退和队列动作均由服务端再次校验主体、对象关系、状态和 capability。

Appointment Calendar 的受控跨诊所日程视图（已确认）

Calendar 可提供“我的有效诊所”汇总视图，但只展示当前用户在各有效 Clinic 的日程元数据；Doctor 仅展示本人 Provider，Nurse 仅展示本人有效岗位／服务关系覆盖的诊所日程。该汇总视图不得展开跨主体患者、当前问诊、历史记录或附件；跳转其他 App 前，目标按全局当前主体重新校验，查看另一诊所必须先通过全局 Context Selector 切换主体。