某中医医院拟开发一套线上抓药 APP，旨在允许患者凭借该医院医生开具的处方进行线上抓药

某中医医院拟开发一套线上抓药 APP，允许患者凭借该医院医生开具的处方线上抓药，并提供免费送药上门服务。该系统的主要功能描述如下：
注册。患者扫描医院提供的二维码进行注册，注册过程中，患者需提供其病历号，系统根据病历号自动获取患者基本信息。
登录。已注册的患者可以登录系统进行线上抓药，未注册的患者系统拒绝其登陆。
确认处方。患者登录后，可以查看医生开具的所有处方。患者选择需要抓药的处方和数量（需要抓几副药），同时说明是否需要煎制。选择取药方式：自行到店取药或者送药上门，若选择送药上门，患者需要提供收货人姓名、联系方式和收货地址。系统自动计算本次抓药的费用，患者可以使用微信或支付宝等支付方式支付费用。支付成功之后，处方被发送给药师进行药品配制。
处理处方。药师根据处方配好药品。若患者要求煎制，药师对配好的药品进行煎制。煎制完成后，药师将该处方设置为已完成。若患者选择的是自行取药，取药后确认已取药。
药品派送。处方完成后，对于选择送药上门的患者，系统将给快递人员发送药品配送信息，等待快递人员取药，并给患者发送收货验证码。
送药上门。快递人员将配好的药品送到患者指定的收货地址。患者收货时，向快递人员出示收货验证码，快递人员使用该验证码确认药品已送到。

以下从用例图和类图设计角度，基于这些实体信息补充分析：

用例图（假设构建 ）

• 参与者：患者、药师、配送人员、快递人员
• 患者用例：包含注册（凭医院二维码，关联病历号获取信息 ）、登录（凭注册的账号 ）、确认处方（查看处方、选处方及数量、选煎制与否、选取药方式、填收货信息、支付 ）、接收收货验证码（药品需派送时 ）、确认已取药（自行取药时 ）
• 药师用例：接收处方（患者支付成功后 ）、药品配制（按处方和煎制要求 ）、标记处方完成（配制好后 ）
• 配送人员用例：接收药品配送信息（药师完成配制且选派送时 ）、取药（到医院取配制好的药品 ）、派送药品（送给快递人员 ，若区分配送和快递环节 ）
• 快递人员用例：接收药品（从配送人员处 ）、送药上门（到患者收货地址 ）、验证收货验证码（患者收货时 ）

类图（假设构建 ）

• 患者类：属性有病历号、账号、基本信息（姓名等 ）、收货信息（可选 ）、支付状态等；方法有注册、登录、选处方及配置、支付、确认取药等
• 药师类：属性有工号、身份信息等；方法有接收处方、配制药品、标记完成等
• 配送人员类：属性有工号、配送区域等；方法有接收配送信息、取药、派送等
• 快递人员类：属性有工号、配送范围等；方法有接收药品、送药、验证验证码等
• 处方类：属性有处方编号、药品明细、煎制要求、取药方式、费用等；关联患者、药师，被患者选择、药师处理
• 订单类（关联支付、派送等 ）：属性有订单编号、支付状态、配送状态等；关联患者、处方、支付方式、配送人员/快递人员 ，串起整个业务流程 ，体现面向对象中类的关联、协作关系，用于梳理系统中各实体的静态结构和交互逻辑 ，辅助开发时明确对象职责与数据流转 。不过因原图未展示，这是基于需求的常规推导设计，实际以完整需求和设计为准 。
  以下是提取整理后的信息：

系统概述

某中医医院拟开发一套线上抓药 APP，旨在允许患者凭借该医院医生开具的处方进行线上抓药，并为患者提供免费送药上门服务。

系统主要功能

1. 注册功能

   • 患者通过扫描医院提供的二维码来完成注册操作。
   • 在注册过程中，患者需要提供其病历号，系统会依据病历号自动获取该患者的基本信息。

2. 登录功能

   • 已经完成注册的患者能够登录系统，进而进行线上抓药的相关操作。
   • 对于未注册的患者，系统会拒绝其登录请求。

3. 确认处方功能

   • 登录后的患者可以查看由医生开具的所有处方。
   • 患者需选择需要抓药的处方以及确定具体的数量（即需要抓取的副药数量），同时要说明是否需要对药品进行煎制。
   • 患者要选择取药方式，分为自行到店取药和送药上门两种。如果患者选择送药上门这种方式，那么患者还需要提供收货人的姓名、联系方式以及收货地址等信息。
   • 系统会自动计算出本次抓药所产生的费用，患者可以使用微信、支付宝等多种支付方式来完成费用的支付。在支付操作成功完成后，所选处方会被发送给药师，以便药师进行后续的药品配制工作。

4. 处理处方功能

   • 药师会根据收到的处方来进行药品的配制工作。
   • 若患者在前面的选择中要求对药品进行煎制，那么药师在配好药品之后，还需要对这些药品进行煎制操作。煎制完成之后，药师需要将该处方的状态设置为 “已完成”。
   • 对于选择自行到店取药的患者，在其取药之后，系统要能确认该药品已被取走。

5. 药品派送功能

   • 当处方处理完成之后，针对那些选择送药上门服务的患者，系统会向快递人员发送包含药品配送相关的信息，快递人员可以根据这些信息来进行取药操作。同时，系统也会向患者发送一个收货验证码，用于后续的收货确认环节。

6. 送药上门功能

   • 快递人员负责将已经配制好的药品按照患者之前提供的收货地址进行送达。在患者收货的时候，需要向快递人员出示之前系统发送的收货验证码，快递人员通过该验证码来确认药品已经成功送达。
   • 以下从**关联、依赖、泛化（若有 ）**等常见面向对象类关系角度，结合系统需求，分析主要类（患者、药师、配送人员、快递人员、处方、订单等 ，结合常规系统设计补充必要类 ）间关系：

1. 患者类相关关系

• 与处方类：关联关系。患者登录后查看、选择处方，一个患者可关联多个处方（历史/当前 ），一个处方对应一个患者（医生开具 ），体现“患者 - 处方”的关联，患者选处方时建立关联，属性可记录所选处方集合、对应数量/煎制要求等。
• 与订单类：关联 + 依赖关系。患者确认处方、填信息后生成订单，患者是订单创建者，依赖订单完成支付、跟踪配送；订单关联患者信息（谁下单 ），二者相互关联，订单状态（支付/配送 ）变化反馈给患者。
• 与快递人员类（若选“送药上门” ）：关联关系。患者填收货信息，快递人员按此配送，患者与快递人员通过订单/配送任务间接关联，患者接收快递人员送药，验证收货码；快递人员关联患者收货信息（地址、验证码 ），完成配送闭环。

2. 药师类相关关系

• 与处方类：关联 + 依赖关系。药师接收患者支付后的处方，进行药品配制，处方是药师工作对象，药师依赖处方信息（药品明细、煎制要求 ）开展工作；药师处理处方后，更新处方状态（如“已配制” ），二者强关联，体现业务流程中“处方 - 药师”的处理关系。
• 与订单类（间接 ）：依赖关系。药师处理处方是订单履约环节（支付成功触发 ），药师操作影响订单状态（如“配制中→已完成” ），订单状态变化驱动药师任务，二者通过处方间接依赖，协同推进业务。

3. 配送人员类（若区分“院内配送”与“快递” ）

• 与处方类：关联关系。药师完成配制后，配送人员接收处方关联的药品（含配制信息 ），负责取药并交接给快递人员（若有分工 ），或直接配送（简化流程 ），关联处方的“配送任务”属性，保障药品流转。
• 与快递人员类：关联关系（若有交接 ）。配送人员将药品交接给快递人员，二者通过“药品配送任务”关联，配送人员完成“院内取/送”，快递人员承接“上门配送”，协同完成派送。

4. 快递人员类相关关系

• 与订单类：关联 + 依赖关系。快递人员接收配送任务（关联订单 ），按订单中患者收货信息送药，依赖订单的“配送地址、验证码”等信息；送药完成后，更新订单状态（“已送达” ），与订单强关联，实现配送闭环。
• 与患者类：关联关系。快递人员送药时验证患者收货码，患者是服务对象，二者通过订单/配送任务关联，完成“送药 - 收货”交互。

5. 处方类与订单类

关联关系：处方是订单的核心内容（患者下单的依据 ），订单关联处方信息（药品、费用 ），一个订单对应一个处方（单次抓药 ），处方状态（如“已支付→配制中→已配送” ）驱动订单状态更新，二者是业务流程的“内容 - 载体”关联，串联患者需求、药师操作、配送履约。

总结（简化版关系模型 ）

• 核心链条：患者 ↔ 处方 ↔ 药师 ↔（配送人员 ↔）快递人员 ，通过订单串联全流程，体现“需求发起（患者选处方 ）→ 履约处理（药师配药、配送/快递送药 ）→ 闭环确认（患者收货/取药 ）”的业务逻辑。
• 关系类型：以关联关系为主（类间长期/直接连接 ，如患者 - 处方 ），辅以依赖关系（类间临时/数据依赖 ，如药师依赖处方信息 ），无明显泛化关系（因角色职责差异大，无需继承 ），通过类间协作支撑线上抓药APP的“开方 - 配药 - 送药”完整业务。

（注：因无实际类图，基于需求做逻辑推导，实际类图需结合属性、方法细化关联强度/方向，如“1对多”“多对多”等 。 ）
在现有的系统功能描述中，未提及患者修改个人信息的具体方式。基于常见的系统设计模式，以下是患者修改个人信息的可能实现方式及相应流程：

修改个人信息的实现方式

1. 系统菜单选项

   • 在 APP 的患者个人中心或账户设置页面，设置一个 “修改个人信息” 的菜单选项。
   • 患者登录后，点击该选项，进入个人信息修改页面。

2. 二维码重新扫描（仅限部分信息更新）

   • 如果医院信息系统支持通过病历号关联更新患者信息，患者可再次扫描医院提供的更新二维码。
   • 系统识别二维码后，自动更新患者部分可变更信息（如联系方式等），但关键信息如姓名、病历号等不可通过此方式修改。

信息修改流程

1. 患者发起修改请求

   • 患者登录 APP 后，在个人中心找到 “修改个人信息” 入口，点击进入修改页面。
   • 页面展示患者当前的个人信息，包括姓名、性别、年龄、联系方式、家庭住址、紧急联系人等。

2. 信息修改与保存

   • 患者可修改除病历号外的其他个人信息，如联系方式、家庭住址等。
   • 修改完成后，点击 “保存” 按钮提交修改请求。
   • 系统在后台验证新信息的格式及合理性（如手机号码格式、地址完整性等），验证通过后保存修改，并向患者显示修改成功提示。

3. 信息修改记录与审核（可选）

   • 系统记录每次信息修改的内容、时间和操作者（患者账户）。
   • 对于涉及关键医疗信息（如过敏史、既往病史等）的修改，设置审核机制，由医院工作人员在后台审核通过后才正式生效。

安全与隐私保护

1. 身份验证

   • 在进入个人信息修改页面前，要求患者进行身份验证，如输入登录密码或手机验证码，确保操作者为患者本人。

2. 敏感信息保护

   • 对于身份证号、病历号等敏感信息，在展示时部分字段隐藏（如显示为 “身份证号：**** **** **** X”），且不允许直接修改。
   • 若患者需要修改病历号等关键信息，需引导其联系医院客服，通过人工审核流程处理。

3. 数据加密

   • 在传输和存储患者个人信息时，采用加密技术，防止信息泄露或被篡改。

以上设计确保患者能够方便、安全地修改个人信息，同时保障医院系统的数据安全和医疗信息的准确性。