1. 引言
1.1. 背景和动机
向患者提供可信的医疗信息是健康信息学中长期存在的问题之一。患者越来越多地在临床就诊前已经咨询过数字资源，而这些资源的质量差异极大。设计良好的工具可以改善预约准备，支持共同决策，并帮助患者组织他们希望讨论的问题和病史。设计不良的工具可能会误导患者，替代专业判断，并造成难以追踪的伤害。这些结果之间的设计空间非常狭窄，很大程度上取决于工具拒绝做什么，而不仅仅是它提供什么。
大多数患者信息应用程序都是为单一疾病构建的。一个团队确定一种感兴趣的疾病，汇集领域内容，围绕该内容设计界面，实施适当的安全和免责声明，并发布一个独立的产品。当处理第二种疾病时，大部分工作会被重复。数据模型经常被重新实现；用户界面被重新设计；最重要的是，安全框架被重新创建，且常常不一致。结果是一个应用程序组合，它们共享内容很少，并且每个都带有自己的潜在缺陷。
本报告描述了一种经过长期开发努力构建和改进的替代方案：一个单一的应用程序，其中疾病是参数而不是常量。医疗应用生成器（以下简称"生成器"）持有一个声明式配置对象库，每种精选疾病对应一个，并根据当前选择的配置渲染其整个界面——页面、字段、术语、内容，甚至其装饰性图标。至关重要的是，疾病不限于固定菜单：用户输入疾病名称，应用程序在识别该名称时将其解析为精选内容，在无法识别时解析为功能性的空白模板。安全框架在共享外壳中实现一次，因此均匀地应用于生成器可以表达的每种疾病。
1.2. 规模论证
使用生成器而非组合的根本动机是一个规模问题。已知的人类疾病数量庞大，并且取决于如何精细地区分疾病状况，但任何可信的统计都将其置于任何手工构建的单一疾病应用程序集合无法覆盖的范围之外。Orphanet（罕见疾病的主要精选参考）描述了约6,000至7,000种临床不同的罕见疾病；一项广泛引用的Orphanet数据库分析报告了6,172种临床独特的罕见疾病[1]，而对该资源的最新描述表明其覆盖超过7,000种疾病，涵盖30多个分类类别[2]。这些数字仅统计罕见疾病。当包括常见疾病，并转向一般临床术语而非罕见疾病登记册时，总数会增长一到两个数量级：当代诊断本体列举了数万种可编码疾病实体，而全面的临床术语则编录了数十万种临床概念。
其含义是直接的。即使罕见疾病子集也达到数千种，那么为每种疾病构建和维护一个应用程序的策略不仅效率低下，而且不可行。组合方法可以处理数十种疾病，或许在大量机构投资下可以处理数百种，但无法接近全部范围。生成器将生产单位从应用程序改为配置。添加疾病成为编写数据对象的问题，而不是构建软件的问题。这并不会使内容问题消失——为数千种疾病编写准确的临床内容仍然是一个主要任务——但它将内容问题与软件工程和安全工程问题分离，而生成器一次性解决了后者。
1.3. 问题陈述
因此，生成器旨在回答一个具体问题：一个单一的、受安全约束的应用程序外壳能否为开放的疾病集合呈现结构化的、特定疾病的信息，同时(a)为工作子集提供真正精选的内容，(b)优雅地降级为一个空白但可导航的模板以应对尚未覆盖的疾病，以及(c)实施统一的安全姿态，防止工具越过信息到建议或处方的界限？本报告描述了回答这一问题的架构、填充它的临床内容方法、约束它的安全机制，以及对其当前覆盖和未覆盖内容的诚实说明。
1.4. 贡献
本报告做出以下贡献，每项贡献都在后续部分中详细阐述：
- 一种配置驱动的架构（第4节和第5节），其中单个声明式对象完全确定特定疾病的患者信息应用程序，包括页面、字段、内容、术语和图标。
- 一个自由文本疾病解析层（第4.4节），它接受任何疾病名称，将已知名称绑定到精选内容，并为未知名称生成功能性的空白模板，使可表达疾病的集合是开放的而非固定的。
- 一个字段重要性和消除模型（第5.3节和第8.2节），它将每个输入分类为关键、有用或不必要，隐藏不必要的字段，并在记录症状后逐步移除字段，只让用户关注影响治疗、剂量或安全的内容。
- 一个分层安全架构（第7节），包括明确的预处理接受门、受安全输入限制且从不计算特定患者剂量的剂量参考、故意屏蔽并重定向的疾病，以及完整的医学、担保、责任和知识产权通知。
- 一个透明的覆盖范围分析和临床内容方法（第6节和第10节），包括用于生成合并症和实验室内容的结构化提示，明确区分代表性数据和全面数据，以及按疾病的计数。
- 将应用程序设计映射到美国食品药品监督管理局（FDA）对非设备临床决策支持软件的标准（第7.6节）。
在整个报告中，我们区分基于外部文献的主张（带有编号引用）和描述应用程序自身设计决策的主张（我们明确标记为设计原理）。我们有意采用这种惯例：关于单一应用程序的报告不能诚实地将其内部选择呈现为独立建立的发现，混淆两者会歪曲工作证据状态。
1.5. 组织结构
第2节回顾了临床决策支持、移动健康监管、医学中生成式人工智能和配置驱动软件的相关工作。第3节阐述了设计目标、要求和明确的非目标。第4节和第5节详细描述了架构和配置架构。第6节描述了临床内容方法，包括提示。第7节介绍了安全架构及其监管映射。第8节描述了用户交互和工作流程。第9节涵盖了实现。第10节提供了评估和讨论，包括覆盖范围分析和对局限性的坦率说明。第11节处理了伦理、法律和监管考虑。第12节概述了未来工作，第13节是结论。附录提供了完整的配置架构、提示和按疾病的表格。
2. 相关工作
生成器位于四个研究领域的交叉点：临床决策支持系统、移动和软件医疗工具的监管、医学中生成式人工智能的应用，以及配置驱动或模型驱动的软件工程。我们回顾了每一项，然后确定生成器所解决的空白。
2.1. 临床决策支持系统
计算机化临床决策支持系统（CDSS）的历史可以追溯到20世纪80年代，已成为电子健康记录的常规组成部分[3]。关于其有效性的文献相当丰富，重要的是，这种有效性是有条件的：当存在特定设计特征时，决策支持最可靠地改善护理。对162项随机试验的元回归确定了特征，如在临床医生工作流程中自动提供支持、提供推荐而非仅仅评估，以及在决策的时间和地点提供支持，作为效果的预测因子[4]。对对照试验的元分析发现，CDSS对目标护理过程产生可测量但通常适度的绝对改善[5]，早期的系统性综述得出了关于效果可变性的兼容结论[6]。采用本身就是一个挑战：对CDSS采用的系统性综述和元回归发现，临床医生的使用远非保证，而是由可用性、信任和工作流程适应性所决定[7]。
文献中的两个主题直接影响生成器的设计。首先，提供信息并对其依据透明的决策支持比断言结论的支持更具可辩护性，更可能被适当使用。其次，有效决策支持的规范性指导——通常被总结为一系列实用的"戒律"，强调速度、与工作流程的契合度以及提供可操作的信息而非原始数据[17]——同样适用于面向患者的工具和面向临床医生的工具。生成器在受监管的意义上不是CDSS；它是面向患者的，且明确不提供建议。但它继承了文献的核心教训：一个组织和呈现相关信息的工具，将判断留给专业人士，比试图做出决策的工具占据更安全、更有用的位置。
2.2. 移动健康应用及其监管
移动健康应用数量众多且质量参差不齐，这促使了结构化质量工具的开发，例如移动应用评级量表，涵盖参与度、功能性、美学和信息质量[20]。在监管方面，美国食品药品监督管理局（FDA）制定了基于风险的政策，重点关注那些故障可能伤害患者的软件，同时对较低风险工具行使执法自由裁量权[8]。《21世纪治愈法案》修改了医疗器械的法定定义，将某些临床决策支持软件从设备监管中排除[10]，FDA关于临床决策支持软件的指导详细说明了区分非设备决策支持与受监管软件的标准[9]。
对患者信息工具最相关的标准是，软件应告知而非指导临床决策，不应获取或分析信号以提供取代专业判断的特定患者特定输出，并且其呈现信息的依据应透明且可独立审查[9]。生成器的设计考虑了这些标准；第7.6节明确地将它的功能与这些标准进行了映射。我们并不声称获得监管批准或断言监管状态，这是相关机构保留的决定；我们描述了一种与已发布标准一致的设计意图。
2.3. 医学中的生成式人工智能
大型语言模型（LLMs）在医疗知识任务方面展示了惊人的能力，在某些设置中编码临床知识，足以在考试式问题上接近或超过人类基准[11]，在其他情况下生成患者面对的响应，人类评分者在共情等维度上对其评价高于医生响应[12]。适应性模型在临床文本摘要等受限任务上已超越专家[13]。这些结果表明生成式模型可以产生有用的医疗文本。
同样，文献对风险也是明确的。模型会产生幻觉——产生流利、看似合理但错误的陈述——并且它们可能以非专家难以检测的方式在事实上出错。即使在文本摘要方面，仔细评估也发现存在非微不足道的幻觉和遗漏率[15]。更重要的是，最近的研究认为，当前模型缺乏知道何时不知道的元认知能力，这削弱了对它们进行医疗推理的天真依赖[14]，并且已经开发出专门的安全基准，正是因为医学安全不能通过一般能力保证[16]。出现的共识不是生成式模型在医学中不可用，而是它们的输出必须被视为需要专家验证的草稿，而不是权威结论。
这一结论是生成器安全架构的承重前提。该应用使用AI辅助、文献衍生的内容，并反复显著声明这一事实。它从不将该内容呈现为建议，并将用户引导至持证临床医生进行任何决策。设计将生成式模型记录的不可靠性视为必须显露和管理的事实，而不是需要隐藏的障碍。
2.4. 配置驱动和模型驱动软件
应用程序的行为可以从声明式模型派生而不是为每个案例手工编码的想法在软件工程中早已确立，在模型驱动方法中，将抽象级别从代码提升到领域模型并从中生成或解释实现[18]。现代声明式用户界面框架将这种精神扩展到表示层：Apple的SwiftUI将界面描述为状态的函数，因此底层数据的任何更改都会自动反映在渲染视图中[19]。生成器以一种狭窄、特定于领域的方式结合了这些想法：每种疾病的单个声明式配置作为模型，SwiftUI外壳将其解释为完整的响应式应用。这不是一个通用的模型驱动平台；它是对患者信息领域的模式的有针对性应用。
2.5. 空白分析
回顾的文献留下了一个特定空白。CDSS研究涉及面向临床医生、通常是受监管的系统，并不解决面向患者、疾病无关的生成。移动健康和监管工作建立了患者工具应遵守的规则，但并未规定安全地跨越多种疾病的架构。生成式AI文献既确立了模型衍生医疗内容的前景，也确立了危险，但很大程度上没有规定产品层面的框架，使此类内容在消费者工具中安全。模型驱动工程提供了生成模式，但没有将其专门化为临床安全。生成器的贡献是占据这一空白：一种配置驱动、面向患者的架构，对疾病开放，并在其共享外壳中嵌入了其他文献所暗示的保守安全姿态。
3. 设计目标、要求和非目标
3.1. 功能要求
生成器是根据以下功能要求开发的，这些要求在项目过程中经过迭代完善（设计原理）：
- 疾病应作为运行时参数，可作为自由文本输入，而不是编译时常量或固定菜单。
- 识别的疾病名称应加载精选内容；无法识别的名称应加载该名称下的可导航但空白的模板。
- 每种疾病应通过单个声明式配置对象表达，该对象涵盖元数据、合并症、指标、症状、血液检测和治疗方法。
- 应用程序应为每种疾病提供结构化页面，包括患者信息、临床指标、合并症、症状严重程度、症状摘要、血液检测、治疗候选方案、随访笔记以及患者临床医生的问题。
- 内容应可沿多个字段和模式进行搜索。
- 应用程序应能够组装适合交接给患者临床医生的摘要。
3.2. 非功能要求
非功能要求（设计原理）：
- 单工件可部署性：应用程序应从一个自包含的源文件构建，简化作者工作流程中的维护和审查。
- 从共享代码库在macOS和iOS上进行跨平台操作。
- 响应一致性：对底层状态的任何更改应自动反映在界面中。
- 优雅降级：缺乏疾病内容绝不应产生错误状态，而应仅显示明确、信息丰富的缺失。
- 本地优先数据处理：患者输入的数据应保留在设备上，除非用户明确启动交接。
3.3. 安全和伦理要求
安全要求被视为首要且不可协商的（设计原理，受[9,14,16]的启发）：
- 应用程序应提供信息而非医疗建议，并应显著声明这一点。
- 在用户明确接受综合医学、安全、担保、责任和知识产权通知之前，不应能访问治疗内容。
- 应用程序绝不应计算或显示特定患者的药物剂量；任何剂量内容应为参考级别，并在完成所需安全字段后才能访问。
- AI辅助内容应在其出现的任何地方标记为AI辅助。
- 至少一种疾病（长新冠及其同义词）应被故意屏蔽并重定向，以演示和执行范围边界。
3.4. 范围和明确的非目标
同样重要的是生成器刻意不尝试做的事情（设计原理）：
- 它不是诊断引擎，也不输出诊断。
- 它不是开处方工具，也不计算个性化剂量。
- 它不自主传输患者健康信息；临床医生交接组成一条用户审查和发送的消息。
- 它不声称全面的临床内容；捆绑数据是在药物类别和主要关联层面上的代表性样本。
- 它不声称获得监管批准；它描述了与已发布非设备标准一致的设计。
4. 系统架构
4.1. 概述
生成器在声明式领域模型、响应式运行时状态和通过后者渲染前者的视图层之间保持清晰的分离。核心是配置对象，它完全描述了一种疾病。单个应用程序存储持有当前选择的配置以及患者的运行数据和当前选择的页面。视图层是一个导航外壳，其侧边栏和详细窗格从配置的页面列表和内容生成。由于框架是声明式的，改变存储——通过选择不同的疾病或编辑字段——会自动重新渲染受影响的视图，而无需指令性更新代码。
这种结构产生三个属性。首先，疾病确实是参数：切换配置会在一个操作中替换整个应用程序的内容、术语和图标。其次，安全框架位于外壳中，而不是任何配置中，因此它不能为特定疾病省略。第三，新疾病不需要新的视图：编写的配置就足够了。
4.2. 配置模型
配置类型聚合了区分一种疾病与另一种的所有内容：显示名称和副标题；疾病核心信号的简短描述；一个标志，指示该疾病是否为心理性的（这会抑制装饰性生化动画）；选择疾病特定插图的图标类型；应用程序应呈现的页面列表；以及五个内容集合——合并症、数值指标、症状、血液检测和治疗方法。每个内容集合是小型自描述记录的列表，在第5节中详细说明。配置是一个值对象：它包含数据和除了派生便利方法之外的行为，这使得每种疾病定义具有声明性和可检查性。
4.3. 运行时状态
患者输入的数据存在于与配置分开的可观察配置文件对象中。配置文件持有运行和患者标识符、数值指标的值、切换的合并症集合、标记的血液检测集合、症状严重程度、恢复日志、随访笔记、临床医生交接字段以及用户的过滤器偏好。将配置文件与配置分开是有意的：配置是固定的参考内容，而配置文件是可变的用户状态，两者具有不同的生命周期。配置文件是可序列化的，因此用户状态可以跨会话持久化；开发过程中添加的新字段以防御性方式解码，以便旧的保存数据仍可加载。
应用程序存储将配置和配置文件绑定在一起并在它们之间进行中介。当选择疾病时，存储安装新配置并重置配置文件的内容绑定字典为源自该配置的默认值——例如，为配置定义的每个指标初始化一个指标条目。存储还包含推荐逻辑，该逻辑根据患者当前活动的症状和过滤器设置对治疗候选方案进行排名。
4.4. 自由文本的疾病解析
生成器的定义性交互是用户输入疾病名称而不是从列表中选择。解析例程解释输入的文本。首先尝试与精选配置名称进行完全、不区分大小写的匹配；如果失败，则尝试两个方向上的宽松包含匹配，以便缩写和部分名称解析为预期的疾病。如果两者都不匹配，该例程会即时构造一个通用配置：一个带有输入名称、中性副标题、默认分子图标、标准页面列表和空内容集合的值对象。应用程序然后像渲染精选疾病一样渲染此模板，只是内容页面显示明确通知，表明没有为输入条件捆绑精选数据集。
此设计使可表达疾病的集合成为开放式的。生成器可以呈现的疾病数量因此不是捆绑配置的数量；它在原则上是无界的，仅限于用户命名条件的能力。呈现精选内容的疾病数量是一个单独的、较小的数字，在第10节中透明报告。对长新冠及其同义词的故意阻止是在此层实现的：测试输入名称与同义词集，识别的同义词会将整个详细窗格路由到重定向通知，而不管配置的其余部分如何。
4.5. 视图层和导航
界面是一个两窗格导航结构。侧边栏包含疾病输入字段和从活动配置中提取的页面列表；详细窗格渲染所选页面。页面列表是数据，而不是代码：添加或重新排序页面是编辑配置的页面集合的问题，详细窗格根据页面标识符分派到相应的视图。由于框架作为状态函数重新渲染，选择页面或编辑值会更新显示而无需手动刷新逻辑。
4.6. 持久化和数据处理
患者数据在本地处理。配置文件是可序列化的，旨在在设备上持久化；架构中没有任何内容将患者数据作为普通使用的副作用传输到远程服务。数据离开设备的唯一一点是临床医生交接（第8.4节），即使在那里，应用程序也会在用户自己的邮件客户端中组成消息，供用户审查和发送，而不是自主传输。这种本地优先姿态是有意的隐私决定（设计原理）。
5. 领域配置架构
本节详细记录配置架构，因为它是每种疾病必须满足的合同，也是内容作者工作的表面。表1总结了顶级字段。
5.1. 合并症
每个合并症记录携带标签、类别和机制。类别不是任意分组，而是病因或生理驱动因素——例如神经源/自主神经、内分泌/代谢、自身免疫/炎症、结构/机械、遗传/遗传、感染后或医源/药物诱导。机制是陈述将合并症与主要疾病联系起来的路径的单个子句。选择此结构是为了使应用程序教授关联而不仅仅是列出它们，并且使合并症列表可以根据机制以及名称进行搜索（设计原理）。生成这些记录的内容方法在第6节中描述。
5.2. 数值指标和字段重要性
每个指标记录携带键、标签、数字范围和默认值、重要性级别和目的。重要性取三个值之一——必需、推荐或可选——界面分别将它们渲染为关键（红色）字段、有用（绿色）字段或完全隐藏的字段。目的将指标分类为影响治疗、剂量、安全或背景。这两个属性驱动第8.2节中描述的字段消除行为：可选字段从不显示，一旦患者记录至少一个活动症状，背景字段就会被移除，因此只有与治疗、剂量或安全相关的字段保留。表2总结了重要性和目的词汇表。
5.3. 症状
每个症状记录携带标签、零到十严重程度量表上的激活阈值和机制。当患者记录的严重程度达到其阈值时，症状被视为活动的。活动症状驱动两种行为：它们触发上述字段消除逻辑，并为治疗排名逻辑提供信息，该逻辑根据每种候选治疗解决患者活动症状的数量对其进行评分。
5.4. 血液检测
每个血液检测记录携带名称、临床目的类别和理由。类别词汇表反映了实验室医学顾问会使用的结构：诊断、严重程度/预后、病因工作、治疗安全/监测以及基线/筛查。理由用一个子句陈述临床上显著结果的含义。血液检测页面在导航中位于治疗方法页面之前，反映了临床排序，其中工作在选择治疗方法之前进行（设计原理）。生成这些记录的提示在第6.2节和附录B中给出。
5.5. 治疗数据库
每个治疗记录携带名称、类别、针对的症状、机制、证据级别、临床医生注释、注意事项、试验样本量以及指示其是否经过同行评审和试验是否完成的标志。样本量映射到队列规模带，允许用户根据支持它们的证据规模过滤候选者。证据级别和同行评审标志允许进一步过滤。这些元数据存在是为了使应用程序不仅可以呈现干预是什么，还可以呈现支持它的证据的强度和成熟度——这是一种诚实机制而不是推荐机制（设计原理）。
我们强调治疗架构的一个有意限制：它不包含特定患者剂量的字段，应用程序从不计算一个。剂量讨论（如果有的话）是参考级别的，并且受到所需安全字段完成的限制，如第7.3节所述。这是安全边界，而不是疏忽。
6. 临床内容和方法论
6.1. 来源方法
与生成器捆绑的临床内容被编写为在药物类别和主要关联层面上准确，而不是全面的。这种区分对于诚实地说明系统至关重要。对于给定疾病，治疗集合列出代表性的干预措施，涵盖主要治疗类别，而不是使用中的每个制剂；合并症集合列出主要的以及一些较少见的关联条件，而不是完整枚举；血液检测集合列出临床医生通常会考虑的检测，而不是每种可能的检测。没有伪造的引用附加到任何记录，因为架构不包含引用字段，我们拒绝制造参考以创建数据不具有的来源外观（设计原理）。
这种代表性而非全面的姿态对计数有直接影响。像长新冠这样的条件，在作者维护的单独专用数据库中，可能携带数百种编目的治疗方法；这里捆绑的急性疾病携带个位数到低两位数的治疗计数，因为这些条件的特定、证据支持的急性干预空间确实更小。应用程序在治疗页面上明确显示捆绑的总数——显示活动疾病的治疗候选者数量以及数据库中存在多少——因此用户永远不会被误导关于底层内容的广度。第10.1节完整报告这些计数。
几个单独的治疗条目锚定在标志性试验中，我们在此引用以证明内容，即使运行应用程序不显示引用：地塞米松在低氧血症新冠中的死亡率益处由RECOVERY试验确立[23]；奈玛特韦-利托那韦在门诊的益处由EPIC-HR试验确立[24]；单克隆抗体治疗在埃博拉病毒病中的生存益处由PALM试验确立[25]。这些引用说明捆绑内容基于临床文献，即使架构不携带参考。
6.2. 结构化提示
两个内容集合——合并症和血液检测——是使用结构化提示编写的，旨在产生全面、分类的输出。提示被编写为强制广度（包括罕见和跨系统关联）、要求根据原则轴进行分类，并要求每个条目的机制或理由。合并症提示指示模型充当多系统病理学和流行病学专家，并映射主要、次要、罕见和新兴的合并症、并发症、易感性以及重叠的综合征，按病因或生理驱动因素分类，并带有每个条目的确切链接机制。血液检测提示指示模型充当实验室医学顾问，并列举诊断、严重程度/预后、病因、治疗安全和基线检测，包括分析物、显著结果的含义以及每个条目的链接机制。两个提示都在附录B中逐字复制。
使用AI助手起草此内容正是应用程序将其内容标记为AI辅助并将用户路由到临床医生的原因。提示被设计为提高广度和结构，而不是赋予权威；关于此类模型可靠性的文献14是呈现结果内容作为验证输入而不是既定事实的原因。
6.3. 按疾病的内容摘要
表3总结了捆绑内容。五种疾病携带所有集合的精选数据；一种，长新冠，不携带任何数据，因为它被故意屏蔽并重定向。完整按疾病列表在附录C中。
7. 安全架构
安全架构是我们认为最重要的系统部分，它完全在共享外壳中实现，因此均匀地应用于每种疾病，无论是精选的还是模板化的。它包括五个机制，依次描述，然后是与已发布非设备决策支持标准的映射。
7.1. 信息，而非建议
基本立场是应用程序提供信息，而非医疗建议。这不仅是一行免责声明；它是塑造每个输出的设计约束。应用程序从不声称诊断，从不推荐特定患者采取特定行动，也从不计算个性化剂量。其内容始终被框定为AI辅助、文献衍生的材料，供持证临床医生讨论，由临床医生决定什么（如果有）是适当的。这种框架与CDSS文献[3,7]和医学生成式AI文献[14,16]的核心教训一致：提供信息并推迟的工具比做出决策的工具更安全。
7.2. 预治疗接受门
治疗内容是应用程序中风险最高的材料，它被隐藏在明确的接受门之后。在治疗页面上，在显示任何候选之前，应用程序呈现一个综合通知，包括医学免责声明、明确声明内容是AI生成的且可能包含错误、指示用户不要基于应用程序开始、停止或更改任何治疗的安全段落，以及完整的担保、责任和知识产权通知。治疗候选者、恢复轨迹可视化、剂量参考和临床医生交接部分都被抑制，直到用户切换明确确认。撤回确认会重新隐藏它们。这模仿了作者在先前工作中使用的免责声明接受模式，并确保没有用户在未被显示并接受管理通知的情况下到达治疗内容（设计原理）。
7.3. 剂量门和非个性化剂量边界
应用程序包括剂量参考，但它以两种方式受到限制，共同防止其成为开处方工具。首先，它是受门限制的：在显示任何剂量参考之前，用户必须已完成所需的安全部分——特别是已知过敏和不良反应，以及当前药物和尝试的治疗方法。如果缺少任何一个，应用程序会列出缺失的字段，并在提供之前抑制参考。其次，也是更重要的，参考从不计算或显示特定患者的剂量。它呈现所选治疗的安全注意事项以及明确声明，剂量必须由使用患者完整病史的持证临床医生确定，并且应用程序不提供特定患者的剂量。这个边界是有意的，在我们看来，是系统中最重要的安全决策：计算用户输入数据的个性化药物剂量的消费者应用程序会从信息跨越到处方，如果计算错误，会导致伤害风险[14,16]。
7.4. 故意屏蔽的疾病
应用程序屏蔽一种疾病——长新冠，及其同义词，如SARS-CoV-2的急性后遗症和新冠后综合征——并将用户重定向到为该条件单独维护的专用应用程序。该屏蔽是在疾病解析层（第4.4节）实现的：与同义词集匹配的任何输入名称将整个详细窗格路由到重定向通知，相应的配置不携带内容。这种机制有两个目的。实际上，它将用户引导至该特定条件的更完整资源。从架构上讲，它演示了生成器可以强制执行范围边界——疾病可以被识别并有意拒绝，而不仅仅是覆盖或未覆盖（设计原理）。
7.5. 免责声明、担保、责任和知识产权
应用程序携带四类通知，取自作者先前工作的既定语言。医学免责声明说明建议来自从已发表医学研究中提取的治疗数据库，它们是AI生成的，不是医疗建议，应仅作为与持证医师对话的起点使用。担保免责声明说明使用是在用户唯一风险下，并且应用程序按"原样"和"可用"提供，所有担保均被否认。责任限制说明作者对因使用而产生的间接、偶然、特殊或后果性损害不承担责任。知识产权通知主张作者对数据库、内容和设计的版权。这些通知在欢迎页面上以摘要形式出现，并在治疗页面上的接受门内完整显示。
7.6. 映射到非设备决策支持标准
FDA对排除设备监管的临床决策支持软件的标准强调，软件应告知而非指导决策，不应提供取代专业判断的特定患者定向输出，并且其信息基础应透明且可独立审查[9,10]。表4将生成器的功能映射到这些主题。我们呈现此映射作为与已发布标准一致的设计意图声明，而不是监管状态的断言，这是相关机构保留的决定。
8. 用户交互和工作流程
8.1. 导航和页面
典型会话按配置列出的顺序通过页面进行：介绍条件的欢迎页面；用于标识符的运行和患者页面；临床指标页面；合并症页面；症状严重程度页面；症状摘要；血液检测页面；治疗候选页面；随访笔记页面；以及"给医生的问题"页面。排序反映了临床工作流程，其中背景和病史在症状评估之前，症状评估在工作之前，工作在考虑治疗之前。血液检测页面刻意位于治疗方法之前，因为工作在治疗选择之前。
8.2. 字段重要性和渐进消除
指标界面根据其重要性渲染每个字段：关键字段标记为红色，有用字段标记为绿色，不必要字段根本不显示。一旦患者记录至少一个活动症状，界面会移除背景字段，只保留与治疗、剂量或安全相关的字段。效果是，随着评估的进行，用户看到的表格变得更短、更集中，将注意力集中在对即将做出的决策重要的内容上。此行为实现了第5.2节中描述的字段重要性元数据，并反映了来自决策支持文献的可用性原则：突出可操作内容并抑制不相关内容可提高效率和适当使用[4,17]。
8.3. 搜索
合并症、症状、血液检测和治疗方法可以搜索。搜索支持三种模式：匹配单个命名字段、跨所有字段匹配以及针对字段连接的自由文本匹配。因为每个内容记录都暴露其可搜索字段——包括机制和理由文本——用户可以定位例如每个链接机制涉及特定路径的合并症，而不仅仅是名称包含搜索词的合并症。这使机制和理由内容可导航，而不仅仅是装饰性的。
8.4. 临床医生交接
应用程序可以为患者的临床医生组装信息。在治疗页面上，在接受门之后，用户可以选择将其记录摘要发送给医生。这样做需要医生的姓名、电话号码和验证的电子邮件地址；应用程序列出任何缺失的必填字段，并在所有字段都存在之前禁用操作。当执行此操作时，应用程序在用户自己的邮件客户端中组成消息，预填充摘要和请求接收临床医生通过回复提供其医疗标识符；用户自己审查并发送消息。当提供时，应用程序记录临床医生的医疗标识符并显示确认指示器。没有患者数据被自主传输；交接始终由用户启动并由用户审查（设计原理）。
我们坦率地指出，接收临床医生的确认是在单个患者端应用程序内建模的，而不是作为单独的身份验证临床医生门户实现的。医疗标识符在组成的消息中请求并在输入时记录；更完整的实现将涉及单独的面向临床医生的接收流程。第12节将其列为未来工作。
8.5. 视觉和动画层
对于非心理条件，欢迎页面呈现疾病生化结构的小型循环插图——冠状病毒病毒体、流感病毒体、丝状丝状病毒、蜱虫或通用分子，由配置的图标类型选择。插图作为矢量图形渲染，由框架动画，而不是嵌入视频。应用程序还包含一个可选功能，当这些资产存在于应用程序包中时播放捆绑的循环视频和可选背景音频，当它们缺失时回退到矢量动画。我们明确表示应用程序不生成视频或音乐；它播放开发者提供的资产，矢量动画是默认值。此视觉层面向参与度，不携带临床内容（设计原理）。
9. 实现
9.1. 单文件SwiftUI架构
应用程序在SwiftUI中实现为单个自包含源文件。此打包选择反映了作者的工作方法，其中整个应用程序作为单元进行审查和重建，它简化了分发和检查。SwiftUI的声明性质[19]对架构至关重要：视图是可观察状态的函数，因此设计所需的响应一致性（第3.2节）由框架提供，而不是由手写更新逻辑提供。
9.2. 视图分解
一个实际约束塑造了实现。SwiftUI的类型推断在视图主体太大或嵌套太深时可能无法编译，表现为编译器超时而不是普通错误。因此，实现将复杂页面分解为许多小型子视图和计算属性，每个都足够简单以快速进行类型检查。此分解对用户是不可见的，但在维护单文件结构时是一个反复考虑的因素（设计原理）。
9.3. 跨平台操作
应用程序从一个代码库针对macOS和iOS。平台特定关注点——例如循环视频视图的构造，在两个平台上使用不同的底层视图类——通过条件编译隔离，因此共享代码路径保持相同。导航结构通过框架的自适应容器适应平台约定。
9.4. 资产管道
应用程序图标通过平台资产目录提供，而不是通过代码；项目包括一个生成的图标集，跨越所需macOS和iOS尺寸，从单个高分辨率源图像生成，扁平化为平台要求的不透明格式。可选的疾病特定视频和音频资产（如果存在）通过名称从应用程序包中加载。资产与代码的分离使源文件专注于逻辑和内容结构。
10. 评估和讨论
10.1. 覆盖范围分析
我们透明地报告覆盖范围。生成器可以呈现用户输入的任何疾病名称，因此可呈现疾病的计数是开放式的。具有精选内容的疾病数量是五种——新冠（急性）、体位性低血压、流感、埃博拉病毒病和长莱姆病（治疗后莱姆病综合征）。一种疾病，长新冠，被故意屏蔽并重定向。所有其他名称解析为空白但完全可导航的模板。表3报告了精选疾病的按集合计数；总的来说，捆绑内容包括五种精选疾病的74个合并症记录、38个症状记录、28个治疗记录和48个血液检测记录。
与第1.2节的规模论证相比——仅罕见疾病就有数千种[1,2]，总体疾病数量更多——此覆盖范围按设计只是可能空间的一小部分。架构的重点不是覆盖五种疾病，而是第六种或第六十种的边际成本是编写配置，而不是构建应用程序。空白模板行为意味着对于尚未教给它的疾病，应用程序已经功能正常，而不是损坏的。
10.2. 优势
设计的主要优势有三个。首先，内容与软件的解耦意味着安全框架实现一次，不能在疾病之间不一致地应用——这是对困扰单一疾病组合的不一致性的一种直接回应。其次，明确、分层的安全姿态——接受门、非个性化剂量边界、来源标记和范围屏蔽——朝着文献推荐的方向是保守的[9,14,16]。第三，透明机制——可见机制和理由、可见证据级别和队列规模、可见内容计数以及明确的AI辅助标记——将工具定位为信息的诚实组织者，而不是神谕。
10.3. 局限性
局限性同样真实，我们坦率地陈述它们。捆绑的临床内容是代表性的，而不是全面的，并且不携带每条记录的引用；寻求全面、有来源内容的临床医生或研究人员会发现当前数据是一个起点，而不是参考。内容是使用AI辅助起草的，尽管它被编写为在药物类别和主要关联层面上准确，但它尚未经过正式专家审查或外部验证，并且生成式AI文献给出了充分理由来验证而不是信任此类内容[14,15,16]。应用程序尚未评估临床效果、可用性或患者结果；没有进行用户研究。临床医生交接确认是在模型中建模的，而不是作为身份验证流程完全实现的。装饰性视觉层虽然面向参与度，但不贡献任何临床内容，可能会被误读为暗示内容所不主张的复杂性。
10.4. 有效性威胁
由于本报告描述了由其倡导者编写的单一系统，最严重的有效性威胁是缺乏独立评估。设计论证是有根据的，并且尽可能基于外部文献，但关于安全性和有用性的主张，目前是设计原理而不是经验发现。第二个威胁是内容有效性：代表性内容可能包含我们由于缺乏正式审查而未检测到的错误。第三个是覆盖范围主张的构造有效性："应用程序可以处理的疾病"是开放式的，仅在任何名称产生可导航模板的意义上，这是一个比"应用程序覆盖的疾病"更弱的主张。我们一直小心区分这些。
10.5. 与决策支持文献的关系
生成器与CDSS文献一致，而不是对其的测试。该文献发现决策支持在工作流程契合度、可操作输出和透明度的条件下有效[4,5,6,7]。生成器面向患者且非建议性，因此其输出是信息性的而不是指令性的，但它直接采用透明度和可操作性原则：它突出相关、组织良好的信息并抑制不相关的内容。这是否转化为改善预约准备或共同决策是一个经验证问题，本报告未回答，第12节将其确定为未来工作。
11. 伦理、法律和监管考虑
三点值得明确处理。首先，患者安全：系统的保守姿态——提供信息而非建议、从不计算剂量、限制治疗内容以及披露AI来源——既是伦理承诺也是设计选择，由医学中生成式模型的记录不可靠性[14,16]和一个原则驱动，即非专家使用的工具必须安全故障。关于人工智能健康伦理和治理的国际指南强调透明度、人类监督和问责[21]，生成器的来源标记和临床医生推迟与此重点一致。
其次，监管定位：应用程序设计为与区分非设备临床决策支持的标准一致[9,10]，主要是通过提供信息而非指导并保持其基础透明和可审查。这是设计意图的声明；任何操作监管决定取决于相关机构，并将取决于应用程序的具体主张和使用。
第三，知识产权和内容来源：应用程序主张作者对其数据库和设计的版权，并且不为无法来源的临床记录附加引用。我们认为不伪造引用的决定是一个伦理问题。如果装饰性图标从第三方艺术品中提取，则需要适当的权利才能分发——开发者必须在软件之外解决的问题。
12. 未来工作
几种扩展自然地来自当前设计（设计原理）：
- 有来源的内容：扩展架构以包含引用字段，并为治疗、合并症和实验室记录附加可验证的参考，使数据集成为参考级而非代表性。
- 批量内容导入：提供导入路径，使精选的外部数据库——例如作者的数百条长新冠治疗数据集——可以直接填充疾病配置。
- 专家验证：使捆绑内容接受正式临床审查并报告评审员间一致性，将设计原理转化为证据。
- 身份验证的临床医生交接：用单独的、身份验证的面向临床医生的流程替换建模的接收确认。
- 可用性和结果评估：进行用户研究，测量预约准备、理解程度和临床医生推迟的适当性。
- 基于检索的内容编写：在使用AI辅助时，将生成基于检索的、验证的文献以减少幻觉，与文献中出现的缓解策略一致[15]。
13. 结论
人类疾病的数量远大于任何单一疾病应用程序组合可以解决的；即使仅罕见疾病子集也达到数千种[1,2]。本报告认为，配置驱动的生成器是对该规模的更适当回应，而不是组合，并详细描述了这样的生成器。通过使疾病成为自由文本参数，该参数在识别时解析为精选内容，否则解析为空白模板，医疗应用生成器将编写临床内容的问题与构建软件和工程安全的问题分离，后者在共享外壳中一次性解决。
系统最重要的设计决策是其安全决策：提供信息而非建议、在明确接受前限制治疗内容、拒绝计算特定患者剂量、披露AI来源，以及通过故意屏蔽疾病来实施范围边界。这些选择朝着临床决策支持和生成式AI文献推荐的方向是保守的[9,14,16]。我们小心区分基于该文献的内容和目前是等待评估的设计原理。诚实的结论是，该架构是患者信息工具的一种可辩护模式，其价值现在取决于剩余工作：来源内容、验证它并在使用中评估工具。
【全文结束】