Workflow 与系统架构

更新:2026-09-19。面向产品、业务与工程协作,依据仓库代码及 canonical PRD 整理;结构图不是应用部署证明。

当前实现形态:双前端 + 模块化 Flask 后端 + PostgreSQL / Redis + 可配置外部服务。 业务模块通过同一后端与数据模型协作;下图中的模块框是职责边界,并不代表各自独立部署的微服务。

如何读图: 蓝色为已有代码路径,橙色为已有代码但尚待完整链路验证的 Lab 链路,灰色虚线为可选扩展或外部依赖。连线表示业务交接或调用关系,不表示已通过联调。具体发布、STG 运行及 UAT 状态需查看独立执行证据。

初版包含 09-16 本地开发工作区中的 Lab 改动,原始核对基线与证据见架构验证记录。09-19 复核时,Lab 基础及组织入口代码已包含在 origin/stg 24329071,因此不再称为未提交实现;完整目标环境验证仍未完成。本页只解释结构与交接,业务规则仍以各领域 PRD 为唯一正文。

1. 从患者到诊到临床交付

flowchart TB
  subgraph A[Line A · 患者与前台]
    P[患者 H5 自填 / 前台登记] --> N[护士核实资料与身份]
    N --> V[预约 / 到诊 / 候诊 · Patient + Visit]
  end
  V --> C[Line B · Consultation 问诊与临床记录]
  C --> RX[签署处方 / Pharmacy Handoff]
  C --> LX[签署检验申请 · 逐项目实验室]
  C --> DOC[临床文档 · 草稿 / 当前签署与打印]
  RX --> REVIEW[Line C · 药房审核与库存门禁]
  REVIEW --> PAY[Line A · Cashier 药品结算确认]
  PAY --> DISP[Line C · Label / Pack / Check / 整单交付]
  LX --> LPAY[Line A · 检验费用组独立结算]
  LPAY --> LAB[Line C · Lab 按实验室承接与采样 / 转介]
  LAB --> REPORT[登记正式报告 → 人工发布]
  REPORT --> RESULT[Line B · 原就诊 Results 查看 / 复诊引用]
  PAY --> FIN[账单 / 实收 / 第三方应收 / 收入报告]
  LPAY --> FIN
  DISP --> END[诊后处理 · Checkout 与后续任务]
  classDef core fill:#edf5ff,stroke:#3475b8,color:#173b62;
  classDef wip fill:#fff5e6,stroke:#bc7921,color:#6d4716;
  class P,N,V,C,RX,DOC,REVIEW,PAY,DISP,FIN,END core;
  class LX,LPAY,LAB,REPORT,RESULT wip;
交接 系统传递什么 必须保留的边界与产品入口
前台 → 医生 Patient、Visit、预约与候诊上下文 自填提交与护士核实是不同事实;前台 PRD
医生 → 药房 → Cashier 已签处方版本、Handoff、审核与库存门禁证据 药品审方后结算;结算确认不等于已经发药。真实库存分配闭环仍有缺口;药房、Cashier
医生 → Cashier → Lab 检验申请行、实验室、对应费用组及结算结果 检验可独立结算,不被药品审核阻断;Lab 基础代码已进入 STG 分支,完整验证未完成;Lab
Lab → 医生 原 Patient / Visit / Order、报告版本与人工发布记录 报告收到、发布、医生查看互不替代;LIS 检测与专业授权在系统外,当前不做接口对接;Lab 报告
Cashier → 诊后 结算、实际收款、应收与 Checkout 结果 不把第三方应收当到账;Checkout、临床 Closed、检验报告完成是独立事实;自动关闭调度等缺口见交付边界

临床完成并不等待全部检验报告回来;图中报告回流不表示重新开启已关闭就诊。Central Pharmacy / WDL 是采购、供应与库存协作域,与诊所发药衔接,但不能把现有目录或库存字段视为完整库存闭环;详见 Central Pharmacy。

2. 系统分层与技术框架

采用 C4 的 Context / Container 两级视角;容器表示应用或数据存储单元,Flask 内部业务模块不是独立部署服务。为兼容现有 PRD 与 Markdown,图形使用标准 Mermaid flowchart 表达。每个节点注明类型、职责和适用技术,调用线注明动作。

2.1 系统上下文 · 谁使用系统,系统依赖谁

flowchart LR
  PATIENT["患者 · Person<br/>提交登记资料"]
  STAFF["诊所 / 医生 / 药房 / Lab 人员 · Person<br/>按授权处理业务"]
  CMS["AI-CLIP CMS · Software System<br/>就诊、临床、收费与履约协作"]
  SSO["Virtus SSO · External System<br/>提供身份认证"]
  AI["AI / 算法服务 · External System<br/>语音、识别与草稿生成"]
  EMMS["eMMS · External System<br/>药物资料与检查接口"]
  PATIENT -->|通过 H5 提交资料| CMS
  STAFF -->|通过员工桌面操作| CMS
  CMS -.->|请求身份校验| SSO
  CMS -.->|请求辅助生成 / 识别| AI
  CMS -.->|查询药物 / 请求检查| EMMS
  classDef person fill:#e9f1f9,stroke:#7294b7,color:#173b62;
  classDef system fill:#1e5d9b,stroke:#164978,color:#fff;
  classDef external fill:#f3f4f6,stroke:#8391a1,color:#425466,stroke-dasharray:5 4;
  class PATIENT,STAFF person;
  class CMS system;
  class SSO,AI,EMMS external;

本图中的 AI 连线表示逻辑依赖;Azure Speech 的浏览器直连路径见下一节。LIS 本轮无系统接口,人工报告交接已在业务 Workflow 表达。

2.2 应用与数据容器 · 当前如何运行

flowchart TB
  subgraph UI[前端应用 · Browser Applications]
    DESK["员工桌面 · Vue 3 / Vue Router / Vite<br/>临床与运营工作台 · Tailwind / Element Plus"]
    H5["患者 H5 · Vue 3 / Vant / Pinia / Axios<br/>移动端登记与自填"]
  end
  subgraph CMS[AI-CLIP 服务边界]
    API["后端 API · Python / Flask 3<br/>Blueprints + 领域 Services<br/>Patient / Consultation / Pharmacy / Cashier / Catalogue / CP<br/>Lab 完整链路待验证"]
    PG[("业务数据库 · PostgreSQL<br/>业务记录 / 版本 / 审计 / 文件元数据")]
    REDIS[("会话存储 · Redis 7<br/>Flask 服务端 Session")]
    STORE["文件存储 · 按配置选择<br/>Local FS / OSS / S3 / MinIO"]
  end
  DESK -->|发起业务请求 · HTTP API| API
  H5 -->|提交登记资料 · 受限 HTTP API| API
  API -->|事务读写 · psycopg2 / SQLAlchemy| PG
  API -->|保存 / 读取会话| REDIS
  API -->|授权上传 / 下载 · Storage Adapter| STORE
  API -.->|可选任务分发 · 默认同步 stub| MQ["消息扩展 · RabbitMQ + Celery<br/>默认关闭"]
  API -.->|可选 DAG 触发 · REST| AIR["调度扩展 · Airflow<br/>独立容器 / 默认关闭"]
  classDef core fill:#edf5ff,stroke:#3475b8,color:#173b62;
  classDef optional fill:#f3f4f6,stroke:#8391a1,color:#425466,stroke-dasharray:5 4;
  class DESK,H5,API,PG,REDIS,STORE core;
  class MQ,AIR optional;

所有业务请求仍需经过各入口适用的身份/令牌、权限与数据范围校验。员工任职/临床授权与患者自填令牌不是同一种授权;业务模块的页面可见性不代替服务端校验。

层次 当前代码方案 代码依据(仓库相对路径)
员工桌面 Vue 3、Vue Router 4、Vite 5;Tailwind 与 Element Plus;App 工作台、组件、API 模块分层 varclip_vue/package.json、src/components/desktop/apps/、src/api/
患者入口 单独的 Vue H5 应用,Vant 移动组件、Pinia 状态与 Axios;共享后端,不是独立患者数据库 varclip_h5/package.json、vite.config.js
后端 Flask 3,通过 Blueprints 汇入同一 app;领域服务实现流程与校验 varclip_flask/src/app.py、blueprints/、services/
数据访问 PostgreSQL;既有 psycopg2 访问与 SQLAlchemy Engine / QueuePool / request-scoped session 并存,不表示全部服务已 ORM 化 src/utils/db.py、src/utils/database.py、requirements.txt
会话与访问 Redis 保存 Flask Session;服务端检查权限、任职和临床数据范围;前端可见性不能替代授权 src/app.py、services/auth_context.py、services/auth_service.py、services/access_http_audit.py
文件 文件登记及授权与实际字节存储分离;支持 Local FS / OSS / S3 / MinIO,默认 Compose 为 local services/file_service.py、utils/storage_backend.py、docker-compose.yml
后台扩展 MQ 未启用时同步 stub;Airflow 独立容器,通过 REST 触发,默认关闭 services/mq_sdk.py、services/airflow_trigger_service.py、deploy/docker-compose.airflow.*.yml

贯穿各模块的数据主线: Patient → Visit → 已签版本/申请 → 收费与结算 → 履约/报告。临床签署、财务结算、发药与报告发布分别拥有状态和来源,跨模块通过稳定标识关联,不能用一个“Completed”字段概括全部进度。权限与组织契约见 Platform。

3. AI 与外部系统如何参与

flowchart LR
  U[员工浏览器] -->|申请短期语音令牌| F[Flask · 权限 / Visit / Consent 校验]
  F -.->|用服务端密钥换令牌| SPEECH[Azure Speech]
  U -.->|短期令牌 · 浏览器语音识别| SPEECH
  U -->|文本 / 文件 / 用户动作| S[Flask 领域服务]
  S -.-> NOTE[问诊记录 / 临床文档算法 HTTP 服务]
  S -.-> OCR[登记 OCR / 附件识别适配]
  S -.-> CHAT[Chat · 配置的模型 API]
  S -.-> EMMS[eMMS · 药物资料 / 检查接口]
  S --> D[结果 / 草稿 / 文件关联]
  D --> R[获授权人员核实 / 保存 / 签署]
  AUTH[身份认证服务] -.-> SSO[Virtus Internal SSO]
  classDef core fill:#edf5ff,stroke:#3475b8,color:#173b62;
  classDef external fill:#f3f4f6,stroke:#8391a1,color:#425466,stroke-dasharray:5 4;
  class U,F,S,D,R,AUTH core;
  class SPEECH,NOTE,OCR,CHAT,EMMS,SSO external;
能力 当前接入方式与约束 核对入口
语音 Flask 换取短期令牌,浏览器调用 Azure Speech;问诊语音入口检查 Visit 与 Consent。不能画成所有音频均经 Flask 中转 blueprints/speech/routes.py
问诊记录/文档生成 后端调用配置的算法 HTTP 服务;生成内容与最终人工签署分开 services/consultation_note_algorithm.py、services/clinical_document_algorithm.py
OCR/Chat 已有登记 OCR、附件与对话接入代码;具体供应商、模型、可用性和数据审批以环境与独立证据核实 services/patient_registration_ocr.py、blueprints/chat/routes.py、services/clinical_file_access.py
eMMS 服务端 HTTP 适配;接口代码存在不表示临床检查策略或外部联调已验收 services/emms_integration.py;临床非阻断与待确认项见交付边界
SSO Virtus 内部 SSO 接入与本地开发登录按认证模式配置;业务角色和临床授权仍由 CMS 校验 services/auth_service.py、services/auth_context.py
LIS/财务外围 当前 Lab 由人工登记和发布正式报告,本轮不做 LIS 接口;不把 NetSuite、外部支付或保险实时核赔画成已接通链路 Lab、Cashier

Line D 提供 AI/集成能力,业务结果仍归 Line A、B、C 的源对象管理。AI 结果不自动构成处方放行、收款事实或正式报告的专业授权。

4. 运行部署与 PRD 平台

flowchart TB
  subgraph CMS[CMS 应用 · Docker Compose 管理]
    B[用户浏览器] --> ENTRY[Web 入口 / 环境代理]
    ENTRY --> V[员工 Vue / 患者 H5]
    ENTRY --> F[Flask API]
    F --> P[(PostgreSQL)]
    F --> R[(Redis)]
    F --> S[文件存储 / 可配置外部服务]
  end
  subgraph DOC[PRD 文档平台 · 独立 Vercel 项目]
    MD[Canonical Markdown] --> BUILD[Python / Pandoc 构建<br/>HTML / Mermaid / 检索语料]
    BUILD --> SITE[PRD 页面 · Workflow 与架构 / 业务规范]
    SITE --> ASK[Node Vercel Function · PRD 问答]
    BUILD --> CORPUS[允许名单中的文档语料 · BM25 检索]
    CORPUS --> ASK
    ASK -.-> MODEL[配置的模型 API]
    ASK --> FEED[私有 Blob · 未解决问题 / 负反馈]
  end
  classDef core fill:#edf5ff,stroke:#3475b8,color:#173b62;
  classDef external fill:#f3f4f6,stroke:#8391a1,color:#425466,stroke-dasharray:5 4;
  class B,ENTRY,V,F,P,R,S,MD,BUILD,SITE,ASK,CORPUS,FEED core;
  class MODEL external;
环境/平台 实际角色 本图不作出的承诺
本地完整链路 Docker Compose;Mac 可经 Lima 运行,验证使用隔离合成数据及 Docker 内官方 Chrome 本地通过不等于 STG 或 UAT
STG / UAT / PROD 各自配置和受保护分支发布;基础 Compose 与环境 overlay 不完全相同 配置文件存在不证明服务器正在运行该版本;图中入口是逻辑入口,不固定端口或声称所有环境均用同一代理
Vercel App 预览 前端演示/预览入口 不等于 CMS 后端、数据库和第三方服务同步发布
Vercel PRD 现有文档站,Markdown 是唯一来源;问答检索允许名单中的文档,再调用模型 不连接 CMS 临床数据库;文档发布不等于业务功能发布

部署配置核对:docker-compose.yml、docker-compose.stg.yml、docker-compose.uat.yml、docker-compose.prod.yml。PRD 构建及问答代码核对:agent_docs/product/prd_preview/build_preview.py、rag/build_index.py、rag/service.mjs、rag/feedback-store.mjs。本架构页作为工程说明随整套下载提供,暂不扩展问答的业务语料允许名单。

5. 责任与实施定位

交付责任 主要内容 实施域
Line A 患者、预约、到诊、候诊、Cashier、诊后与新 Cashier 收入报告 WS1 / WS5,共享 WS6 / WS7;现金盘点关账及 Period Close 不在本次收入报告范围
Line B Consultation、处方、检验开单、临床文档与完成 WS2 / WS3,共享 WS6 / WS7
Line C Pharmacy、Lab、CP / WDL 及供应库存协作 WS4;Lab 衔接 WS3 / WS5 / WS6,CP / WDL 由 Samuel 主责、NeosAI 支持
Line D AI 与第三方集成 WS2 / WS3 的 AI,WS7 平台集成;业务状态归源领域

Line 是交付责任,WS 是实施领域,均不代表独立服务。业务细节进入业务主线;代码缺口进入实现与待确认;不在此页重复维护一份验收清单。

6. 图表方法与维护

本页采用开源 C4 Architecture skill 的分层和关系标注方法,以及 Mermaid Diagrams skill 的单图单主题、可版本化源码和渲染校验方法。技能仅指导表达,节点及关系仍以本仓库代码和领域 PRD 为依据;没有套用样例中的技术栈。

每张图可以放大查看、缩放,并下载 SVG 或 Mermaid 源码。后续调整在本页源文件就地修改,再按原发布流程构建和验证;不另存一套手工维护的业务规则。