1 医疗行业方案要回答什么
医疗行业方案首先回答：什么人在什么诊疗关系下，为了什么任务，可以接触哪些数据；系统暂时不可用时，临床工作怎样继续。医疗信息既关联个人隐私，也关联诊疗连续性。把数据放进加密存储，只解决了保护链条中的部分问题；若医生看不到必要报告，或离职账号仍能查询病历，方案仍然没有完成目标。入门设计应从使用场景、责任边界和可验证结果出发，再选择计算、网络与存储资源。
本系列始终用零售订单 API 练习方案设计：顾客提交订单，订单服务校验请求并保存状态，库存与支付通过明确接口协作，查询端读取订单结果。医疗章节保留这个案例，用它对照医院中的检查申请、影像阅片与病历查询。订单仍是零售订单，患者也不会被简化成顾客；可以迁移的是需求拆分、权限收敛、故障隔离与决策记录的方法。诊疗规则、法律依据与紧急授权，必须由医疗机构中有相应职责的人确认。
先为订单 API 写出业务事实：提交成功意味着订单已可靠保存，重复提交不能产生重复订单，支付结果未知时不能直接显示已付款。再为医疗查询写出相同粒度的事实：检查申请已接收不等于影像已生成，影像已生成不等于报告已审核，网络超时也不等于检查不存在。状态语义清楚，才能定义超时、重试、告警与人工处理。直接把界面上的“成功”当作后端所有环节完成，容易让临床人员误判数据完整性。
需求至少覆盖使用者、数据、时限与故障后果。门诊医生需要当次就诊的摘要和相关报告，影像技师需要检查任务与必要身份信息，运维人员通常需要服务健康信息。不同角色不能共用“内部员工可以看全部数据”的规则。数量也要写进需求：假设门诊高峰有 120 个并发查询，摘要查询目标为 95% 请求在 2 秒内完成，影像首次可阅览目标为 5 秒。这些只是本课演练值，应由真实工作流测量和评审后替换。
方案输出可沿着需求、候选方案、ADR、成本、风险、高可用展开。ADR 是架构决策记录，用简短文字留下背景、选择、理由和后果。例如“病历摘要走交互接口，原始影像走独立传输通道”，就要说明它怎样保护门诊响应、增加哪些维护工作、遇到什么证据需要重新评估。这样，采购清单与拓扑图才有共同依据。验收时也能沿着需求追问结果，而不是只检查服务器是否启动。
2 隐私、可用性与互操作
隐私保护从最小必要访问开始。“最小”包含字段、对象、时间与用途：医生能查询哪些患者，返回哪些内容，授权持续多久，是否允许导出。身份认证只证明请求者是谁，授权还要判断这次请求是否应当发生。某位医生拥有阅片角色，并不自动意味着可以浏览全院影像。可将角色、科室、当次诊疗关系和数据敏感程度组合为容易解释的规则，先让正常访问路径明确，再讨论例外。
对照订单 API，顾客可以看自己的订单，客服根据工单处理相关订单，仓储只需收货与发货所需字段。医疗系统的差别在于诊疗关系会变化，协作可能跨科室，而且某些紧急情况需要特殊通道。紧急访问应成为受控功能：限定有资格的人员，填写原因，设置短时有效期，触发审计和事后复核。不能把“救急”做成长期开放的超级账号，也不能把权限审批拖延到妨碍紧急救治；具体流程需由机构共同制定。
可用性需要按业务区分。门诊摘要查询、影像上传、历史归档和统计报表，不应只有相同的优先级。摘要接口可在影像拥塞时继续服务；报表可推迟执行；尚未完成的影像任务应显示明确状态。只读缓存能帮助展示已确认的信息，但必须显示更新时间与来源，避免陈旧数据被误认作最新结论。对影响诊疗决策的信息，允许陈旧多久、何时必须回源，都需要业务负责人确认。
互操作解决不同系统能否准确交换和理解信息。DICOM 常用于医学影像及相关信息，HL7 FHIR 提供医疗信息交换的资源模型与接口约定。采用标准名称并不保证接入就完成：患者标识、检查编号、时间、单位、编码与版本仍须对齐。例如“36.8”没有单位和测量时间，接收端就无法可靠解释。接口合同应写明必填字段、未知值、状态转换、错误处理与兼容策略，并通过样例验证含义。
保护传输与存储仍是必要基础。接口采用加密传输，数据落盘加密，密钥有独立管理和访问记录；同时避免在错误消息、监控标签和浏览器地址中放入敏感信息。可用性方面，应区分服务副本故障、网络故障与依赖故障。增加副本只能覆盖部分故障，共享数据库、身份服务或院内出口仍可能成为共同失效点。把隐私、可用性与互操作同时列入验收，才能防止只优化速度而扩大数据暴露范围。
3 影像、病历与设备接入
医疗数据不是大小相近的普通记录。病历摘要以结构化字段和文本为主，影像检查可能包含大量文件，设备还会持续产生带有时间信息的测量结果。若所有内容都经过同个同步接口，原始影像传输就可能占住连接和带宽，使轻量查询也排队。订单 API 中也有类似区分：订单状态属于交互数据，商品图片和批量对账文件适合独立承载。医疗方案可借用这种分流方式，但保留更严格的数据关系校验。
设计时将申请、元数据和大文件分开考虑。申请服务记录检查任务，元数据记录检查编号、来源、生成时间和可用状态，影像存储保存文件。临床查询先获得授权后的检查列表，再获取允许查看的影像入口。入口可以短时有效并限定对象；每次生成入口和实际访问都要遵循权限边界。不能因为地址难猜就把它当作授权，也不能让下载入口在患者关系变更后长期可用。
设备接入先经过受控接入区，由适配服务完成协议转换、来源校验与格式检查，再进入业务系统。旧设备可能不支持现代身份或加密能力，此时需要通过网络隔离、受控网关和明确的补偿措施缩小风险，并记录尚未解决的限制。不要为了方便调试，让设备网段直接访问全部业务数据库。接入区暂时断连时，可以在容量允许范围内暂存待传数据，但必须说明上限、保存期限与满载后的处理方式。
可靠接入依靠可识别的任务和明确的确认点。重复到达的检查文件要能识别，部分上传要有未完成状态，校验失败要保留可追踪的错误。系统只有在约定的数据已可靠接收后才能确认相应阶段完成。对照订单 API 的幂等请求，重试必须围绕稳定业务标识判断，避免因超时重发而产生重复记录。患者标识匹配存在歧义时，应进入人工核对流程，不能按姓名相同就自动合并。
保留原始信息与规范化结果的关系也很重要。适配服务转换单位或代码后，应能追溯来源和转换版本，以便发现映射错误时修正。设备时间不准可能使事件顺序混乱，因此需要记录采集时间与接收时间，并治理时钟偏差。这里先掌握输入校验、状态确认、重复处理与来源追踪，不展开影像编码或设备协议内部实现。架构图应让临床人员也能指出：哪里产生数据，哪里确认完成，哪里可能延迟。
4 动手：设计一次最小必要访问
本节做 1 次纸面接口演练。先写订单 API 的查询要求：顾客 A 查询自己的订单，只返回订单状态、商品摘要和必要配送信息；顾客 B 不能通过修改订单编号获得 A 的数据。再写医疗对照：门诊医生查询当前接诊患者的检查摘要，只返回本次任务需要的检查名称、时间、状态与已审核结论。练习重点是把访问条件与返回字段同时写出来，避免只在页面上隐藏按钮。
把请求拆成身份、对象、动作、用途与上下文。身份来自经过校验的登录凭据，对象是检查记录，动作是读取摘要，用途是本次诊疗，上下文包括当前就诊关系与授权有效期。服务端应根据可信来源核对这些条件，不能相信客户端自行提交的“我是主治医生”。如果关系服务暂时不可用，普通访问应按事先约定的安全失败方式处理；紧急通道使用独立规则，不能让所有失败请求自动升级为紧急访问。
接着列出字段白名单。阅片列表可以返回检查编号、检查类型、完成状态和必要日期，通常不需要同时附带完整住址、联系方式或与当前任务无关的历史记录。需要患者识别信息时，也应按具体工作流选择足够区分身份的字段，避免过度删减造成认错患者。最小必要不是机械地删到最少，而是在完成明确任务的前提下控制范围。对导出、批量查询和跨患者检索，应单独定义条件与限制。
然后写出能由旁观者复核的步骤：提交携带身份凭据的请求，验证凭据，查询诊疗关系，判断权限，读取所需字段，生成受限响应，记录审计事件。审计记录包含操作者、对象标识、用途类别、时间、授权结果与关联请求编号，通常不需要复制病历正文。审计系统本身也有权限与保存期限，不能把敏感数据从业务库搬进人人可查的日志平台。客户端展示结果时应标明状态，未审核内容不能被包装成正式结论。
最后准备 6 个验收样例：合法当次访问、无诊疗关系访问、过期凭据、篡改对象编号、授权依赖超时、已获批的紧急访问。每个样例同时写预期响应、是否返回字段、审计结果和业务提示。订单 API 使用同样方式覆盖本人查询、越权查询与依赖失败。这样的测试能检验权限边界；仅验证“正确账号能打开页面”，无法证明错误账号看不到数据。演练产物是访问规则表和样例结果，后续实现可据此逐项验收。
5 临床效率与隐私保护取舍
临床效率与隐私保护经常共享目标：准确呈现与任务有关的信息，可以减少查找时间，也能减少无关暴露。但它们并非总能同时改善。授权范围越窄，遇到跨科室会诊时越可能需要补充授权；缓存越久，读取越快，却增加信息陈旧和权限变更未及时生效的风险。方案需要说明在哪些任务上接受什么代价，而不是写“兼顾安全与效率”后就结束。
比较 3 个候选方案：方案 A 每次都从源系统查询摘要，结果较新，但依赖源系统的响应与可用性；方案 B 使用有期限的摘要缓存，响应较稳定，但要处理更新时间、失效与敏感数据副本；方案 C 大范围复制完整病历，查询便利，却增加数据治理、权限同步、存储和删除的负担。对本课的门诊摘要场景，可优先评估 B，并为必须确认最新状态的字段回源；能否采用仍取决于临床要求和实测结果。
缓存不能绕过授权。每次访问仍需检查适用的权限，缓存键与内容组织要防止不同用户或患者的数据串用，权限撤销还应有明确传播时限。可以将共享的非敏感配置与受限患者摘要分开处理。若权限判断本身也缓存，必须记录有效期以及撤销后的最长残留窗口；窗口是否可接受，需要由负责人员评审。滑块演示只帮助观察负载和陈旧窗口的关系，不会替方案自动给出合规答案。
成本应包含网络、存储、请求、审计、备份和人员工作。假设每日新增 200 GB 影像，保留策略使在线数据持续增长，即使接口请求数不多，存储和传输也会成为主要成本。重复副本、备份与恢复演练也占容量。分层存储可降低部分长期成本，但取回时间必须符合使用要求；不常访问不等于可以随时延迟。订单 API 的图片与历史订单分层可作为理解入口，医疗资料的保留与删除规则则需独立确认。
ADR 可以写成可反驳的判断：“为保护门诊摘要响应，原始影像采用独立通道与流量限制；摘要缓存有效期暂定 30 秒，界面显示更新时间，需实时确认的状态回源。接受额外缓存运维成本和最多约 30 秒的源数据陈旧窗口，但权限检查独立执行。”同时标明评审人、假设和重新评估条件，例如跨科室访问失败率超过目标或源系统容量变化。量化假设使取舍可讨论，也使上线后的调整有依据。
6 常见坑：测试环境用真实数据
把生产库复制到测试环境，是医疗项目中后果明显的捷径。测试环境通常账号更多、访问更松、临时脚本更多，数据还可能进入开发电脑、缺陷附件与流水线日志。即使业务库随后删除，副本仍可能散落在备份与截图中。订单 API 的测试也应避免复制真实顾客资料；医疗数据包含更细的诊疗信息，方案必须从数据准备阶段就写清边界，不能等上线评审才补说明。
优先使用合成数据，构造足够覆盖业务的患者、检查、状态与时间关系。合成不是随意造几个名字：需要覆盖重复姓名、缺失字段、跨日检查、重复上传、撤销授权、影像未完成和报告修订等情况。生成的数据应明确标为测试用途，避免进入真实诊疗系统造成误认。用于性能测试时，可用不含真实患者信息的文件构造数据规模，并说明测试文件与真实影像在大小、数量和访问模式上的差异。
必须使用来源数据进行特定验证时，应先确认使用依据、授权范围、处理方法和环境条件。删除姓名并不等于无法识别个人：证件号、时间组合、罕见诊断、文件名、影像头部和图像中直接显示的文字都可能泄露身份。去标识化需要覆盖结构字段、文本、文件元数据和像素内容，并评估重识别风险。假名化数据若仍可通过映射表关联个人，也应继续按相应敏感数据要求保护；本课不把具体处理方法当作合规结论。
测试链路还包括日志、工单与可观测平台。接口调试工具的历史请求、自动截图、异常堆栈和第三方分析脚本，都可能留下正文。可以使用字段白名单记录、限制请求体采集、将测试凭据与生产隔离，并设置数据到期清理机制。发现泄露时，应按机构流程控制访问、保全必要证据、评估影响并处理副本，不能仅删掉当前页面里的记录就宣告结束。
验收应检查数据从哪里来、谁能取走、何时清理、如何证明清理有效。至少演练 1 次测试数据到期删除和 1 次权限撤销，确认对象存储、导出目录与备份策略也在范围内。订单 API 的合成订单生成器可复用生成关系与状态的方法，医疗数据则需增加诊疗语义约束。把测试数据治理写进交付条件，能让进度压力出现时仍有可执行路径，也减少后来追查未知副本的成本。
7 案例：影像带宽打满门诊网络
假设某院门诊摘要接口平时响应稳定，某天上午开始大量超时。应用副本的处理器占用不高，数据库查询也没有明显变慢。值班人员发现，影像系统刚启动历史检查回传，原始文件与门诊交互请求共用院内某段 1 Gbit/s 链路。上传任务持续占满链路，轻量请求虽然数据很小，仍因排队和重传出现延迟。这个案例说明，服务副本健康不能证明用户路径健康。
先统一故障时间线，比较接口延迟、超时率、链路利用率、丢包与影像任务启动时间。检查数据应按服务、通道和任务汇总，避免把患者信息作为监控标签。再从门诊终端测试摘要查询与影像访问，确认受影响路径；只在机房内部测接口，可能绕过拥塞链路。若证据显示网络拥塞，应先按预案限制后台回传并保障交互流量，再观察响应是否恢复。临床中正在进行的关键传输不能未经协调直接中止。
容量估算帮助解释现象。假设单次检查需要传输 500 MB，20 次检查就是 10000 MB。按十进制单位换算，共约 80000 Mbit；在 1 Gbit/s 链路上，即使不计协议开销和其他业务，传完也至少需要约 80 秒。真实有效速率还会受到端点、协议和共享流量影响。若继续允许更多并发传输，队列可能变长，交互请求尾部延迟随之恶化。并发数增加并不保证整体完成更快。
长期改进有多个层次：为影像传输设置速率和并发上限，把历史回传安排到低峰，缩略或分段阅览按业务需要评估，交互与批量任务使用适当的网络隔离和带宽保障。逻辑隔离能帮助管理流量，但若底层仍共用相同瓶颈，就需要检查保障机制是否实际生效。对已存在的文件重复上传，也应检查任务去重和重试策略，避免恢复后产生重试洪峰。
高可用改造不能只增加摘要服务副本。要追问备用路径是否仍经过相同交换设备、相同出口或相同供电区域；存储可访问时，身份服务和授权服务是否也可用。恢复验证应覆盖用户端真实路径，并确认暂停的影像任务能安全继续、文件完整、状态正确。订单 API 发生商品图片批量同步拥塞时，也用同样的方法：先确认共享资源，再隔离流量和控制恢复速度，避免把网络问题误判成应用容量不足。
8 把医疗合规写进方案
合规应成为设计输入和交付证据。先明确机构、处理活动和适用范围，由负责法律、隐私、安全和业务的人共同确认适用要求，再把要求转成技术与流程约束。不同地区、机构与数据用途可能有不同规则，架构师不能仅凭某个产品的认证就推导整个方案合规。产品能力、部署方式、人员操作和持续管理共同决定实际效果。方案应标明哪些事项已确认，哪些需要负责人员给出结论。
建立要求到证据的对应关系。例如，“仅授权人员访问”对应身份管理、诊疗关系校验、字段控制与权限验收记录；“访问可追溯”对应审计字段、时间同步、受控保存和抽样复核；“数据可恢复”对应备份策略、恢复演练和结果记录。每项要求都写责任人、检查方法与例外处理。审计记录本身也有敏感性，应限制读取与修改，并根据确认的规则保存，不能默认无限期保留。
数据生命周期从采集延伸到删除。采集时说明用途和必要范围，传输时控制接收方，使用时约束查询与导出，共享时确认边界和责任，归档时执行保留策略，到期时按适用要求处理。备份中的数据如何到期、法律保留要求如何覆盖删除请求，也需要记录。跨机构交换和跨区域部署要单独评审，不能因为接口符合 FHIR 就默认允许传输。技术标准解决交换方式，授权依据与数据边界需要另外确认。
高可用指标要与工作恢复安排绑定。RTO 表示目标恢复时间，RPO 表示可接受的数据丢失时间窗口；备份间隔不能自动证明已达到 RPO，恢复速度也要实测。可为门诊摘要设置演练目标 RTO 15 分钟、RPO 5 分钟，并要求由临床和技术共同确认其可接受性。对已确认提交的订单或已接收的检查申请，还需说明故障切换后如何核对缺失和重复记录。恢复过程不能绕过授权或把生产数据随意复制到临时环境。
当核心系统不可用时，机构应有经批准的业务连续性流程，包括受控的离线工作、必要信息获取与恢复后的核对。纸面或离线记录同样需要身份识别、保管和补录控制。演练不能只证明备用节点能启动，还要证明人员知道如何切换，关键工作能继续，恢复后信息能对齐。把演练发现写回风险清单与 ADR，才能让合规要求持续影响运行，而不是停留在交付时的签字页。
9 从医疗行业方案走向端边云协同（P30）
医疗场景自然引出数据应在哪里处理的问题。设备附近可以先做来源校验和暂存，院内节点可以承接低延迟查询与局部协作，集中平台可以承担跨系统管理、归档和获准的分析。端、边、云是位置与职责的划分，并不意味着必须建设 3 套完整平台。先根据网络稳定性、响应时限、数据范围与运维能力决定职责，再选择实现。把所有处理集中起来可能增加链路依赖，把所有数据复制到边缘也会增加治理负担。
继续沿用零售订单 API：门店端提交订单，靠近门店的节点可在获准范围内处理缓存或暂存，中心服务维护权威订单状态。网络中断时，端侧究竟允许接受哪些动作，要由库存、支付和重复处理规则决定。医疗对应的是设备断连时可否继续采集、院内阅览可否读取已确认缓存、恢复后怎样补传。类比提供问题清单，不能将零售的离线交易规则直接套入诊疗流程。
在 P30 之前，先画清数据权威来源和状态归属。原始影像在哪里首次可靠接收，报告由哪个系统审核，摘要缓存多久更新，授权变更由哪里发布，都应有明确答案。边缘节点保存副本时，需要容量上限、过期策略、物理保护、访问限制与运维责任；连接恢复后也要限制补传速度。否则，原本为了断网可用而增加的暂存，可能在恢复时再次打满门诊链路。
本课的迁移条件是可测的：若院内网络延迟妨碍关键任务，或设备必须在断连期间持续采集，就值得进一步评估靠近现场处理；若只是后台报表慢，未必需要新增边缘节点。增加节点会带来版本分发、凭据更新、监控与现场维护成本。方案要比较改善的业务结果与新增责任，而不能把“更靠近设备”直接当成优势。高级同步机制、冲突处理和调度细节留到后续，本课先守住数据边界与故障语义。
进入下课前，可带走 1 份连续的方案草稿：需求中有角色与响应目标，候选方案中有数据分流和位置比较，ADR 中有取舍与触发条件，成本表中有存储和网络假设，风险表中有测试数据与共享链路，高可用部分有恢复演练和人工流程。任何读者都应能从业务任务追到技术选择，再追到验收证据。这样，端边云协同才是在已有约束上继续设计，而不是另起与业务无关的拓扑图。
放进方案里
本方案以零售订单 API 为持续练习对象，保留订单提交、状态查询及库存支付协作边界；医疗对照场景采用门诊摘要查询与影像阅览。目标是验证最小必要访问、大文件分流和故障隔离的设计方法。患者身份匹配、临床使用规则及适用法律要求，由医疗机构指定责任人确认，并作为上线前置条件记录。
交互接口仅返回任务所需字段，服务端校验身份、对象关系、用途与有效期。影像通过受控接入区接收，元数据与原始文件分开管理，下载入口限定对象与期限。普通访问失败与紧急访问使用各自明确的流程，紧急授权具备原因记录、短时有效期和事后复核。审计记录关联请求编号，避免复制病历正文。
ADR 选择将摘要交互与影像批量传输分流，并评估 30 秒摘要缓存；缓存显示更新时间，权限判断独立执行。暂以 120 个并发查询、95% 摘要请求在 2 秒内完成为演练目标。成本按每日新增 200 GB 影像估算，并计入副本、备份、传输、审计与运维。实际容量与保存期限经测量和评审后替换。
主要风险包括共享链路拥塞、身份误匹配、权限撤销延迟和测试数据泄露。对应措施是限制影像并发与速率、歧义记录人工核对、验证撤销传播时限、使用合成测试数据。高可用演练暂设 RTO 15 分钟、RPO 5 分钟，覆盖授权依赖、用户端网络路径、备份恢复及业务连续性流程。验收须提交越权访问样例、带宽压测、恢复核对与数据清理记录；未达目标的事项登记责任人与复验日期。另以报告修订样例验收摘要更新：保留修订前后版本号与审核时间，核对缓存到期后展示的新结论及其来源；未审核版本不得作为正式报告返回，结果由临床责任人签认。
10 小结：下一步端边云协同（P30）
医疗行业方案要把诊疗任务、访问边界、数据语义和故障后果连起来。最小必要访问控制谁在何种条件下看到哪些字段；影像与摘要分流保护交互体验；合成测试数据、审计与恢复演练使保护要求进入日常交付。零售订单 API 继续作为方法练习的主线，医疗场景补充更严格的角色关系与连续性要求。
自测时尝试回答：医生具备阅片角色，为何仍需判断诊疗关系？影像传输拥塞时，增加应用副本为何可能无效？备份成功为何不能证明恢复目标已经达成？若能分别用访问上下文、共享链路和恢复证据解释，就可以进入 P30，继续判断哪些职责应放在端、边与云，以及断连后怎样恢复协作。