构建 Rx-Gated 电子商务 与 EMR 集成：Authorize-Only Payments 与 Clinical Approval Workflow 的最佳路径
发布: (2026年1月9日 GMT+8 04:09)
4 min read
原文: Dev.to
Source: Dev.to
概览
在满足以下需求的前提下，如何为一家长寿诊所构建电子商务系统？
- 某些 SKU 需要处方（包括注射剂），其他为非处方商品，还有会员和订阅套餐。
- 关键需求是对需要处方的 SKU 在最终付款捕获前进行医学审查。
高层流程
- 客户下单。
- 如果购物车中包含任何需要处方的 SKU，则仅进行 授权（不捕获）。
- 使用诊所提供的阈值和患者上下文运行医学风险评估（基于规则的二元决策模型）。
结果
| 结果 | 操作 |
|---|---|
| 批准 | 捕获付款并完成订单。 |
| 需要进一步操作 | 保持授权状态，触发在 7 天内的远程医疗会诊安排，然后由临床医生手动批准或拒绝。决定后，捕获付款或作废/退款。 |
架构路径
1. 自定义或无头电商 + 中间件编排
- 构建一个无头前端（如 React、Next.js），与 中间件编排服务 通信。
- 中间件实现 订单状态机，集成用于医学风险评估的 规则引擎，并处理 EMR 同步。
- 支付提供商收到 仅授权 请求；在临床批准后才执行捕获。
2. WooCommerce（自托管）+ 自定义插件
- 以 WooCommerce 为基础电商平台。
- 开发自定义插件以实现：
- 检测购物车中需要处方的 SKU。
- 执行 仅授权 交易。
- 调用 规则引擎 与诊所的 EMR 进行医学审查。
- 根据临床医生的决定管理保留、捕获或作废工作流。
3. 分离模型：非处方前端 + 处方登记门户
- 将公共前端（非处方商品、会员、订阅）与 处方登记门户 分离。
- 门户负责资格检查、远程医疗排程以及在 任何付款之前 完成临床批准。
- 通过仅在临床清关后处理处方商品的付款，降低电商平台的政策风险。
4. 替代架构（尚未考虑）
- 无服务器事件驱动架构：
- 使用无服务器函数（如 AWS Lambda）在订单创建时触发授权流程。
- 将订单状态存储在持久化存储中（DynamoDB、Firestore）。
- 将事件发布到消息总线（SNS、Pub/Sub），以调用规则引擎和 EMR 集成。
- 通过独立工作流（Step Functions、Cloud Workflows）处理远程医疗排程、临床审查以及最终的捕获/作废操作。
推荐问题
哪种架构在授权‑仅后、临床批准后再捕获，尤其是涉及远程医疗升级和手动覆盖的场景中最为稳健？