CN119580976A - 一种医院支撑平台 - Google Patents

Abstract

本说明书实施例提供一种医院支撑平台,包括：硬件设备，被配置为采集医院业务相关的数据；数据中心，包括数据湖，数据湖被配置为以防篡改的方式对数据进行持久化存储；处理设备，配置有用于数据处理的数据处理单元，数据处理单元包括扩展现实单元、人工智能单元、数字孪生体单元和数据流通单元；用户空间应用，被配置为供医院业务的相关用户获取与医院业务有关的用户服务，其中，用户服务由处理设备利用至少一个数据处理单元对存储在数据中心的至少一部分所述数据进行处理而实现。

Description

一种医院支撑平台

交叉引用

本申请要求于2024年7月31日提交的申请号为PCT/CN2024/109064的国际申请的优先权，上述申请的完整内容通过引用被包含于此。

技术领域

本说明书涉及医疗服务领域，特别涉及一种医院支撑平台。

背景技术

医疗业务场景通常较为复杂。尽管医疗行业中已引入数字化和信息化系统，但医疗业务涉及众多种类的硬件设备和庞大的数据处理需求。此外，患者病情个体差异很大，这使得提供高效的医疗服务依然需要耗费大量的时间、人力和物力资源。尤其是在涉及多部门、多系统以及多医疗机构之间的信息交互方面，效率通常较低。因此，整合和调度医院内外的硬件与软件资源，以有效支撑医疗服务，成为亟待解决的问题。

另外，一些长期困扰医疗行业的问题，如患者就诊难、体验感差(如长时间排队)，医护人员短缺，诊断高度依赖医生经验等，依然存在。传统的医疗数据处理技术通常只针对特定的医疗任务，难以满足复杂多变的医疗业务场景需求。

因此，期望提供一种更加可靠和高效的医院支撑平台。

发明内容

本说明书实施例之一提供一种医院支撑平台，包括硬件设备，被配置为采集医院业务相关的数据；数据中心，包括数据湖，所述数据湖被配置为以防篡改的方式对所述数据进行持久化存储；处理设备，配置有用于数据处理的数据处理单元，所述数据处理单元包括扩展现实单元、人工智能单元、数字孪生体单元和数据流通单元；用户空间应用，被配置为供医院业务的相关用户获取与所述医院业务有关的用户服务，其中，所述用户服务由所述处理设备利用至少一个所述数据处理单元对存储在所述数据中心的至少一部分所述数据进行处理而实现。

在一些实施例中，所述系统还包括软硬件接口，被配置为从所述硬件设备获取所述数据，并将所述数据发送至所述数据中心进行存储。

在一些实施例中，所述从所述硬件设备获取所述数据，并将所述数据发送至所述数据中心进行存储包括：获取所述硬件设备的硬件配置信息，所述硬件配置信息包括身份唯一标识；确定所述硬件配置信息是否满足预设条件；响应于所述硬件配置信息满足所述预设条件，将所述数据发送至数据中心进行存储。

在一些实施例中，所述硬件配置信息还包括所述硬件设备的运行状态；所述确定所述硬件配置信息是否满足预设条件包括：基于所述身份唯一标识，确定所述硬件设备是否为多个可信任设备中的一个；和/或基于所述硬件设备的运行状态，确定所述硬件设备是否为正常状态。

在一些实施例中，所述系统还包括开放接口，被配置为供应用开发者调用至少一部分所述数据处理单元，并利用所述至少一部分数据处理单元进行应用开发。

在一些实施例中，所述硬件设备包括物联网设备和扩展现实设备。

在一些实施例中，所述数据中心进一步包括数据仓，被配置为存储所述数据的索引。

在一些实施例中，所述处理设备进一步被配置为：确定所述数据的评估信息；基于所述评估信息，确定所述数据的存储策略；基于所述存储策略，将所述数据存储至所述数据湖。

在一些实施例中，所述评估信息包括所述数据的安全等级、数据量大小和/或数据采集频率、重要性系数中的一种或多种的组合；所述基于所述评估信息，确定所述数据的存储策略包括：响应于所述数据对应的所述安全等级高于预设安全阈值，确定所述数据的存储策略为对所述数据进行加密存储；和/或响应于所述数据的数据量和/所述数据采集频率高于预设阈值，确定所述数据的存储策略为对所述数据进行分布式存储；和/或基于所述数据的所述重要性系数，确定所述数据的存储期限。

在一些实施例中，所述扩展现实单元被配置为利用扩展现实技术对所述数据进行处理，以实现扩展现实服务；所述人工智能单元被配置为利用人工智能技术对所述数据进行处理，以实现人工智能服务；所述数字孪生体单元被配置为利用数字孪生技术对所述数据进行处理，以实现数字孪生服务；所述数据流通单元被配置为利用数据流通技术对所述数据进行处理，以实现数据流通服务。

在一些实施例中，至少一部分所述数字孪生体单元被配置为调用所述扩展现实单元和/或人工智能单元对所述数据进行处理，以实现所述数字孪生服务。

在一些实施例中，所述数据流通技术包括区块链技术和数据隐私计算技术。

在一些实施例中，所述处理设备进一步被配置为利用所述扩展现实单元、人工智能单元、数字孪生体单元中的至少一部分将至少一部分所述数据映射至虚拟医院；所述用户空间应用被配置为供所述相关用户与所述虚拟医院进行交互，以使得所述相关用户获得至少一部分所述用户服务。

在一些实施例中，所述处理设备进一步被配置为：当所述相关用户与所述虚拟医院进行交互时，通过所述扩展现实单元利用扩展现实技术将所述虚拟医院的至少一部分呈现给所述相关用户。

在一些实施例中，所述医院支撑平台中的数据交互满足预设数据隐私规则和数据安全规则。

在一些实施例中，所述人工智能单元包括智能体单元，所述智能体单元被配置为维护智能体，所述智能体基于AI技术和所述医院业务相关的数据实现自主学习和演化。

在一些实施例中，所述智能体包括预问诊服务对应的预问诊智能体，所述预问诊智能体被配置为：基于患者挂号的医生所在的科室，通过所述患者的患者终端对所述患者进行预问诊询问；基于所述患者终端在所述预问诊询问中采集的数据，生成所述预问诊记录。

在一些实施例中，所述预问诊智能体进一步被配置为基于患者挂号的医生所在的科室，确定预问诊询问的询问内容，包括：获取所述医生所在的科室对应的预问诊记录模板和所述患者的已知信息；通过比对所述预问诊记录模版和所述患者的已知信息，确定所述预问诊记录模板中还未采集到的遗漏信息；基于所述遗漏信息确定所述询问内容。

在一些实施例中，所述预问诊智能体进一步被配置为基于患者挂号的医生所在的科室，确定预问诊询问的询问内容，包括：利用遗漏信息确定模型处理所述医生所在的科室和所述患者的已知信息，以确定所述患者待采集的遗漏信息；利用询问内容确定模型处理所述遗漏信息，以确定所述询问内容，其中，所述遗漏信息确定模型和所述询问内容确定模型为训练好的机器学习模型。

在一些实施例中，所述预问诊询问基于询问内容进行且包括多轮询问，所述询问内容包括每轮询问的询问内容，所述向所述患者发起所述预问诊询问，包括：对除第一轮询问外的每轮预问诊询问，基于当前轮次询问之前采集的数据，确定所述患者的历史回答的语义信息和情绪信息；基于所述语义信息和所述情绪信息，对当前轮次询问的询问内容进行调整；基于调整后的当前轮次询问的询问内容，通过所述患者终端进行当前轮次询问。

在一些实施例中，所述预问诊包括多轮询问，所述对所述患者进行预问诊询问，包括：对于除了首轮询问之外的每一当前轮次询问，基于历史询问的询问内容、所述患者的历史回答和所述患者的已知信息，利用询问内容确定模型，确定当前轮次询问对应的询问内容，所述询问内容确定模型为训练好的机器学习模型；基于所述当前轮次询问对应的询问内容，通过所述患者终端进行所述当前轮次询问。

在一些实施例中，所述智能体包括问诊服务对应的问诊智能体，所述问诊智能体被配置为：在患者的问诊过程中，基于感知设备在所述问诊过程中采集的感知信息，确定所述患者是否需要与远程陪诊者进行沟通；响应于确定所述患者需要与所述远程陪诊者进行沟通，控制至少一个终端设备放大所述与远程陪诊服务有关的界面元素。

在一些实施例中，所述智能体包括住院服务对应的住院智能体，所述住院智能体被配置为：基于病房中的感知设备采集的感知信息，确定患者是否满足在病房中进行入院检查的条件；响应于确定所述患者满足入院检查的条件，控制智能护理推车将护士引导进入所述病房，以及控制所述智能护理推车呈现与所述入院检查相关的信息；基于所述入院检查时采集的所述患者的体检数据，生成入院记录。

在一些实施例中，所述智能体包括住院服务对应的住院智能体，所述住院智能体被配置为：对于患者住院的每一天，根据患者的患者数据和医生对所述患者的医嘱，确定所述患者的每日计划，所述每日计划包括当天需要对所述患者执行的至少一项医疗操作；通过所述患者的病房中的终端设备向所述患者展示所述每日计划；并且通过所述患者对应的护士的终端设备向所述护士展示所述每日计划。

在一些实施例中，所述智能体包括手术服务对应的手术智能体，所述手术智能体被配置为：确定从患者的当前位置到手术室等候区的计划路线；控制智能轮椅将所述患者沿着所述计划路线运送到所述等候区；在所述患者被运送到所述等候区的过程中，基于所述患者的患者数据和手术计划，通过患者的患者终端对所述患者进行术前教育；以及在所述患者被运送到所述等候区后，基于所述等候区中的感知设备采集的患者的生物信息，对所述患者的身份进行验证。

附图说明

本说明书将以示例性实施例的方式进一步说明，这些示例性实施例将通过附图进行详细描述。这些实施例并非限制性的，在这些实施例中，相同的编号表示相同的结构，其中：

图1是根据本说明书一些实施例所示的示例性医疗服务系统的框图；

图2是根据本说明书一些实施例所示的示例性医疗服务系统的示意图；

图3是根据本说明书一些实施例所示的医院支撑平台的架构示意图；

图4是根据本说明书一些实施例所示的对硬件设备进行验证的过程的示例性流程图；

图5是根据本说明书一些实施例所示的数据湖仓的示例性示意图；

图6是根据本说明书一些实施例所示的数据处理方法的示例性示意图；

图7是根据本说明书一些实施例所示的存储数据的方法的示例性示意图；

图8是根据本说明书一些实施例所示的应用开发层的示例性示意图；

图9A是根据本说明书一些实施例所示的提供预问诊服务的示例性流程的示意图；

图9B是根据本说明书一些实施例所示的进行第二询问的示例性流程的示意图；

图10是根据本说明书一些实施例所示的基于感知信息提供医疗门诊服务的示例性流程的示意图；

图11是根据本说明书一些实施例所示的向入院办理环节的相关用户提供服务的示例性流程的示意图；

图12是根据本说明书一些实施例所示的提供护理服务的示例性流程的示意图；

图13是根据本说明书一些实施例所示的术前引导流程的示意图；以及

图14是根据本说明书一些实施例所示的执行手术的示例性流程的示意图。

具体实施方式

为了更清楚地说明本说明书实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单的介绍。显而易见地，下面描述中的附图仅仅是本说明书的一些示例或实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图将本说明书应用于其它类似情景。除非从语言环境中显而易见或另做说明，图中相同标号代表相同结构或操作。

应当理解，本文使用的“系统”、“装置”、“单元”和/或“模块”是用于区分不同级别的不同组件、元件、部件、部分或装配的一种方法。然而，如果其他词语可实现相同的目的，则可通过其他表达来替换所述词语。

除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。

本说明书中使用了流程图用来说明根据本说明书的实施例的系统所执行的操作。应当理解的是，前面或后面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各个步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。

本说明书一些实施例提供一种医院支撑平台，包括硬件层(也称为硬件设备模块)、接口层(也称为接口模块)和数据处理层(也称为数据处理模块)、应用开发层(也称为应用开发模块)和服务层(也称为元服务层、元服务模块、服务模块)。硬件层被配置为采集医院业务相关的数据；接口层被配置为从硬件层获取数据，并将数据发送至数据处理层；数据处理层包括多个数据处理单元，被配置为获取接口层发送的数据，并利用多个数据处理单元中的至少一个对数据进行处理，以实现医院业务相关的用户服务；应用开发层被配置为提供开放接口，以供开发者调用至少一部分数据处理单元，并利用至少一部分数据处理单元进行应用开发；服务层被配置为提供用户空间应用，以供医院业务的相关用户获取与医院业务有关的用户服务。

在一些实施例中，医院支撑平台包括硬件设备(作为硬件层)、软硬件接口(作为接口层)、数据中心和处理设备(作为数据处理层)、开放接口(作为应用开发层)、用户空间应用(作为服务层)。硬件设备被配置为采集医院业务相关的数据。软硬件接口被配置为从硬件设备获取数据，并将数据发送至数据中心进行存储。数据中心包括数据湖，被配置为以防篡改的方式对数据进行持久化存储。处理设备配置有数据处理单元，例如，扩展现实单元、人工智能单元、数字孪生体单元和数据流通单元。处理设备可以利用上述数据处理单元中的至少一个对存储在数据中心的至少一部分数据进行处理，从而实现用户服务。开放接口被配置为供应用开发者调用至少一部分数据处理单元，并利用至少一部分数据处理单元进行应用开发。关于硬件设备、数据中心、处理设备、用户空间应用、开放接口和软硬件接口的更多描述可以参见图3。

本说明书一些实施例提供一种医院支撑平台，被配置为对医院的各类资源进行综合管理，包括硬件资源、软件资源、数据资源等。在一些实施例中，医院支撑平台集成了支持各类先进技术的多个数据处理单元，包括人工智能(AI)技术、扩展现实(XR)技术、数字孪生技术和区块链技术等，这些先进技术被用来提高医疗行业的服务效率和质量。例如，人工智能技术能够实现医院运营的自主进化和持续优化，XR技术和数字孪生技术能够实现虚拟医院的创建和维护。虚拟医院可以与用户进行交互，以及为用户提供身临其境和新颖的虚实融合服务体验。另外，医院支撑平台还包括应用开发层，使得医疗行业的第三方开发者能够访问这些先进技术，从而构建一个开放的医疗生态系统，促进应用的开发与创新，进而推动医疗行业的发展。

图1是根据本申请的一些实施例所示的示例性医疗服务系统的框图。

医疗服务系统100也可称为元医院系统，是基于多种创新技术构建的，包括元宇宙技术、XR技术(例如，augmented reality(AR)技术、virtual reality(VR)技术、mixedreality(MR)技术等)、AI技术、数字孪生体技术、IOT技术、数据流通技术(例如，区块链技术、数据隐私计算技术)、空间计算技术、图像渲染技术等。

如图1所示，医疗服务系统100可以包括物理医院110、虚拟医院130、用户空间应用120和医院支持平台140。在一些实施例中，医院支持平台140可以将与物理医院110相关的数据映射到与物理医院110对应的虚拟医院130中，并通过用户空间应用120向物理医院110的相关用户提供用户服务。

物理医院110是指存在于物理世界中并且具有有形属性的医院。在本文中，为人们提供内科、外科和精神病护理和治疗的卫生保健机构统称为医院。

如图1所示，物理医院110可以包括多个物理实体。例如，多个物理实体可以包括科室、用户、硬件设备、用户服务、公共区域、医疗服务流程等，或其任何组合。

科室是指专门提供特定类型的医疗护理、治疗和服务的专门单位或部门。每个科室可以专注于某一个特定的医学领域，并可以配备具有该领域专业知识的医疗保健专业人员。例如，科室可以包括门诊科室、住院科室、外科科室、支持科室(例如，挂号科室、药房科室)、内科、外科、专科医学、儿童保健科等，或其任何组合。

用户可以包括与物理医院110相关联的任何用户(或称为物理医院110的相关用户)。例如，用户可以包括患者(或患者的一部分(例如，器官))、陪诊者、患者的探视者、物理医院110的医院工作人员、物理医院110的供应商、物理医院110的应用开发人员等，或其任何组合。物理医院110的医院工作人员可以包括医疗服务提供者(例如，医生、护士、技术人员等)、医院管理人员、支持人员或类似人员，或其任何组合。示例性的医院管理人员可以包括科室护理管理人员、临床管理人员、科室院长、医院院长、医院行政人员、职能管理人员或类似人员，或其任何组合。

硬件设备可以包括位于物理医院110中的硬件设备和/或与物理医院110中的硬件设备通信的硬件设备。示例性的硬件设备可以包括终端设备、医疗服务设备、感知设备、基础设备等，或其任何组合。

终端设备可以包括与医疗服务系统100的用户交互的终端设备。例如，终端设备可以包括与患者交互的终端设备(也称为患者终端)、与患者的医生交互的终端设备(也称为医生终端)、与护士交互的终端装备(也称为护士终端)、与远程探视者交互的终端器件(也称为远程终端设备)或医院的公共终端(例如，诊室终端、床边终端设备、等候区中的终端设备、智能手术终端)等，或其任何组合。在本申请中，除非明显地从上下文中获得或上下文另有说明，否则将由用户拥有的终端设备和由物理医院110提供给用户的终端设备统称为用户的终端设备或与用户交互的终端设备。

终端设备可以包括移动终端、XR设备、智能可穿戴设备等。移动终端可以包括智能手机、个人数字助理(PDA)、显示器、游戏设备、导航设备、手持终端(POS)、平板电脑等，或其任何组合。

XR设备可以包括允许用户参与扩展现实体验的设备。例如，XR设备可以包括VR组件、AR组件、MR组件等，或其任何组合。在一些实施例中，XR设备可以包括XR头盔、XR眼镜、XR贴片、立体耳机等，或其任何组合。例如，XR设备可以包括GoogleGlass^TM、OculusRift^TM、GearVR^TM、AppleVisionpro^TM等。具体地，XR设备可以包括可以在其上呈现和/或显示虚拟内容的显示组件。在一些实施例中，XR设备可进一步包括输入组件。输入组件可以实现用户与显示组件显示的虚拟内容(例如，虚拟手术环境)之间的交互。例如，输入组件可以包括触摸传感器、麦克风、图像传感器等，其被配置为接收用户输入，用户输入可提供给XR设备，并用于通过改变呈现在显示组件上的视觉内容来控制虚拟世界。输入组件可以包括手柄、手套、触控笔、控制台等。

智能可穿戴设备可以包括智能手环、智能鞋袜、智能眼镜、智能头盔、智能手表、智能衣服、智能背包、智能配件等，或其任何组合。在一些实施例中，智能可穿戴设备可以获取用户的生理数据(例如，心率、血压、体温等)。

医疗服务设备可以被配置为向患者提供医疗服务。例如，医疗服务设备可以包括检查设备、护理设备、治疗设备等，或其任何组合。

检查设备可配置为向患者提供检查服务，例如，采集患者的检查数据。示例性的检查数据可以包括心率、呼吸频率、体温、血压、医学成像数据、体液测试报告(例如，血液测试报告)等，或其任何组合。相应地，检查设备可以包括生命体征监测器(例如，血压监测器、血糖仪、心率计、温度计、数字听诊器等)、医学成像设备(例如，计算机断层扫描(CT)设备、数字减影血管造影(DSA)设备、磁共振(MR)设备等)、实验室设备(例如，血液常规检查设备等)等，或其任何组合。

护理设备可被配置为向患者提供护理服务和/或协助医疗服务提供者提供护理服务。示例性的护理设备可以包括医院病床、患者护理机器人、智能护理推车、智能药箱、智能轮椅等。

治疗设备可以被配置为向患者提供治疗服务和/或协助医疗服务提供者提供治疗服务。示例性的治疗设备可以包括手术设备、放射治疗设备、物理治疗设备等，或其任何组合。

感知设备可被配置为采集与其所处环境相关的感知信息。例如，感知设备可以包括图像传感器、声音传感器等。图像传感器可配置为在物理医院110中采集图像数据，声音传感器可配置为在物理医院110中采集语音信号。在一些实施例中，感知设备可以是独立的设备，也可以集成到另一个设备中。例如，声音传感器可以是医疗服务设备或终端设备的一部分。

基础设备可以被配置为支持数据传输、存储和处理。例如，基础设备可以包括网络、机房设施、计算设备、计算芯片、存储设备等。

在一些实施例中，物理医院110的至少一部分硬件设备是IoT设备。物联网设备是指具有传感器、处理能力、软件和其他技术的设备，这些设备通过互联网或其他通信网络与其他设备和系统连接和交换数据。例如，物理医院110的一个或多个医疗服务设备和/或感知设备是物联网设备，并配置为将采集的数据传输到医院支持平台140进行存储和/或处理。

用户服务可以包括医院支持平台140向用户提供的任何服务。例如，用户服务包括向患者和/或陪诊者提供的医疗服务、向物理医院110的工作人员和/或物理医院110的供应商提供的支持服务等。在一些实施例中，可以通过用户空间应用120向患者、医生和医院管理人员提供用户服务，这些将在下面的描述中详细描述。

公共区域是指物理医院110中用户(或部分用户)可访问的共享空间。例如，公共区域可以包括接待区(例如，前台)、等候区、走廊和走廊等，或其任何组合。

医疗服务流程是指向患者提供相应医疗服务的流程。医疗服务流程通常包括几个环节和/或步骤，用户需要通过这些环节和/或步骤才能获得相应的医疗服务。示例性的医疗服务流程可以包括门诊流程、住院流程、手术流程或类似流程，或其任何组合。在一些实施例中，医疗服务流程可以包括不同科室、不同疾病等对应的医疗服务流程。在一些实施例中，可以设置预设的数据采集协议并指定医疗服务流程中涉及的标准环节以及如何采集与医疗服务流程相关的数据。

用户空间应用120向用户提供对医院支持平台140提供的用户服务的访问入口。用户空间应用120可以是应用、插件、网站、小程序或任何其他合适的形式。例如，用户空间应用120是安装在用户终端设备上的应用，该应用包括用户发起请求和接收相应服务的用户界面。

在一些实施例中，用户空间应用120可以包括对应不同类型的用户的不同应用。例如，用户空间应用120包括对应患者的患空间应用、对应医生的医空间应用、对应管理者的管空间应用等，或其任何组合。通过患空间应用、医空间应用和管空间应用提供的用户服务也分别称为患空间服务、医空间服务和管空间服务。示例性的患空间服务包括挂号服务、路径引导服务、预问诊服务、远程就诊服务、住院服务、出院服务等。示例性的医空间服务包括日程安排服务、手术计划服务、手术模拟服务、患者管理服务、远程查房服务、远程门诊服务等。示例性的管理者空间服务包括监控服务、医疗服务评估服务、设备参数设置服务、服务参数设置服务、资源调度服务等。

在一些实施例中，患空间应用、医空间应用和管空间应用可以集成到一个用户空间应用120中，并且用户空间应用120可以配置为为每种类型的用户(例如，患者、医疗服务提供者、管理者等)提供访问入口。仅作为示例，特定用户可以具有相应的账号，可用于登录用户空间应用，查看相应的诊疗数据，并获得相应的用户服务。

根据本说明书的一些实施例，通过为不同类型的用户提供用户空间应用，每种类型的用户可以轻松地获得他/她在其相应的用户空间应用上可以需要的各种用户服务。此外，目前用户通常需要安装各种应用才能获得不同的用户服务，这导致用户体验差和开发成本高。因此，本申请的用户空间应用可以改善用户体验，提高服务质量和效率，增强服务安全性，降低开发或运营成本。

在一些实施例中，可以将用户空间应用120配置为物理医院110的相关用户提供与虚拟医院130交互的访问入口。例如，通过用户空间应用120，用户可以输入用于检索虚拟医院130(例如，硬件设备、患者器官、公共区域的数字孪生体模型)的数字内容的指令，查看数字内容，并与数字内容交互。作为另一示例，通过用户空间应用120，用户可以与代表智能体的虚拟人物沟通。在一些实施例中，医院的公共终端可以安装管空间应用，并且可以在管空间应用中登录该公共终端对应的科室的管理员帐户。用户可以通过安装在公共终端中的管空间应用接受用户服务。

虚拟医院130是物理医院110的数字孪生体(即，虚拟表示或虚拟副本)，用于模拟、分析、预测和优化物理医院110的运行状态。例如，虚拟医院130可以是物理医院110的实时数字副本。

在一些实施例中，可以使用数字技术将虚拟医院130呈现给用户。例如，当相关用户与虚拟医院130交互时，可以使用XR技术将虚拟医院130的至少一部分呈现给相关用户。仅作为示例，可以使用MR技术将虚拟医院130的至少一部分叠加在相关用户的真实世界视图上。

在一些实施例中，虚拟医院130可以包括与物理医院110相关的物理实体的数字孪生体。数字孪生体是指物理实体的虚拟表示(例如，虚拟副本、映射体、数字模拟器)。数字孪生体可以实时反映和预测物理实体的状态、行为和性能。例如，虚拟医院130可以包括物理医院110的医疗服务、科室、用户、硬件设备、用户服务、公共区域、医疗服务流程等至少一部分的数字孪生体。物理实体的数字孪生体可以有多种形式，包括模型、图像、图形、文本、数值等。例如，数字孪生体可以是与物理医院相对应的虚拟医院，与人员实体(例如，医生、护士和患者)相对应的虚拟人员(例如，虚拟医生、虚拟护士和虚拟患者)，与医疗服务设备(例如，成像设备和手术刀)相对应的虚拟设备(例如，虚拟成像设备和虚拟手术刀)等。

在一些实施例中，数字孪生体可以包括一个或多个第一数字孪生体和/或一个或多个第二数字孪生体。每个第一数字孪生体的状态可以基于相应物理实体状态的更新被更新。例如，在将与物理医院110相关的数据映射到虚拟医院130的过程中，可以更新一个或多个第一数字孪生体。一个或多个第二数字孪生体可以通过用户空间应用120中的至少一个进行更新，并且每个第二数字孪生体的更新可以导致相应物理实体的状态更新。换句话说，当相应的物理实体改变其状态时，可以相应地更新第一数字孪生体；当第二数字孪生体被更新时，相应的物理实体的状态也随之改变。例如，一个或多个第一数字孪生体可以包括公共区域、医疗服务、用户、硬件设备等的数字孪生体，一个或多个第二数字孪生体可以包括硬件设备、用户服务、医疗服务流程等的数字孪生体。应当理解，数字孪生体可以是第一数字孪生体，也可以是第二数字孪生体。

根据本说明书的一些实施例，通过生成包括与物理医院110相关的物理实体的数字孪生体的虚拟医院130，可以在安全可控的环境中模拟和测试物理医院110(包括硬件设备、用户、用户服务、医疗服务流程等)。通过虚拟现实联动(例如，物理医院110与虚拟医院130之间的实时交互)，可以更准确地预测和响应各种医疗场景，从而提高医疗服务的质量和效率。此外，XR技术和虚拟现实集成技术的运用，使相关用户的交互更加自然、直观，提供更加舒适、高效的医疗环境，从而提升用户体验。

在一些实施例中，虚拟医院130可以进一步包括基于与物理医院110和AI技术相关的数据实现自我进化的智能体。

智能体是指以智能方式行动的代理体。例如，智能体可以包括一个计算/软件实体，该实体可以自主学习和进化，并感知和分析数据以执行特定任务和/或实现特定目标(例如，医疗服务流程)。通过AI技术(例如，强化学习、深度学习等)，智能体可以在与环境的交互中不断学习和自我优化。此外，智能体可以通过大数据技术采集和分析海量数据(例如，物理医院110的相关数据)，并从数据中挖掘模式和学习规则，优化决策流程，从而在不确定或动态环境中识别环境变化，快速响应，做出合理判断。例如，智能体可以基于AI技术自主学习和进化，以适应物理医院110的变化。仅作为示例，智能体可以基于NLP技术(例如，大型语言模型等)构建，并可以通过大量语言文本(例如，医院业务数据和患者反馈信息)自动学习和自主更新，以提高物理医院110提供的用户服务质量。

在一些实施例中，智能体可以包括对应不同的医疗服务流程、不同的用户服务、不同的科室、不同的疾病、不同的医院职位(例如，护士、医生、技术人员等)、医疗服务流程的不同环节等不同类型的智能体。特定类型的智能体用于处理与特定类型相对应的任务。在一些实施例中，一个智能体可以对应不同的医疗服务流程(或不同的医疗服务，或不同的科室，或不同的疾病，或不同的医院位置)。在一些实施例中，智能体可以参照与智能体对应的科室和/或疾病的基本配置数据(例如，字典、知识图、模板等)进行操作。在一些实施例中，多个智能体可以通过网络通信相互协作并共享信息，共同完成复杂任务。

在一些实施例中，可以设置智能体的配置。例如，可以设置智能体在操作中使用的基本配置数据。基本配置数据可以包括字典、知识数据库、模板等。又如，智能体的使用权限可以针对不同的用户进行设置。在一些实施例中，物理医院110的管理者可以通过管空间应用设置智能体的配置。

在一些实施例中，智能体可以集成到硬件设备中或部署在硬件设备上。例如，可将与住院服务相对应的智能体集成到医院病床或医院病床的呈现设备中。在一些实施例中，智能体可以集成到具身智能机器人中或部署在具身智能机器人上。具身智能机器人是指将物理存在(体现)与智能行为(认知)相结合的机器人系统。具身智能机器人可以被配置为以模仿或补充人类能力的方式与现实世界交互，利用物理形态和认知功能来执行任务、做出决策和适应环境。通过利用人工智能和传感器技术，具身智能机器人可以自主操作，与环境互动，并不断提高性能。例如，具身智能机器人可配置与手术服务相对应的智能体，并协助医生进行手术。

在一些实施例中，可以基于智能体提供至少一部分用户服务。例如，可以基于处理结果向相关用户提供至少一部分用户服务，其中处理结果由智能体中的至少一个基于与物理医院110相关的数据生成。仅作为示例，与物理医院110有关的数据可以包括与物理医院110的医疗服务流程有关的数据，智能体可以包括与医疗服务流程相对应的智能体，并且可以通过使用与医疗服务流程相对应的智能体处理数据来向医疗服务流程的相关用户提供用户服务。

医院支持平台140可被配置为向医疗服务系统100提供技术支持。例如，医院支持平台140可以包括计算硬件和软件，以支持创新技术，包括XR技术、AI技术、数字孪生技术、数据流通技术等。在一些实施例中，医院支持平台140可至少包括用于数据存储的存储设备和用于数据计算的处理设备。

在一些实施例中，医院支持平台140可以支持物理医院110和虚拟医院130之间的交互。例如，医院支持平台140的处理设备可以从硬件设备获取与物理医院110相关的数据，并将与物理医院110相关的数据映射到虚拟医院130中。例如，医院支持平台140的处理设备可以基于所获得的数据更新虚拟医院130中的数字孪生体的一部分(例如，一个或多个第一数字孪生体)，以便虚拟医院130中的数字孪生体的每一部分都可以反映物理医院110中相应物理实体的更新状态。基于这种与相应的物理实体不断更新的数字孪生体，用户可以实时了解与物理医院110相关的物理实体的状态，从而实现对物理实体的监控和评估。作为另一示例，与物理医院110相关的数据相对应的智能体可以基于与物理医院110相关的数据进行训练和/或更新，从而自我进化和自我学习。

在一些实施例中，医院支持平台140可以支持和/或向物理医院110的相关用户提供用户服务。例如，响应于从用户接收到用户服务请求，医院支持平台140的处理设备可提供与该服务请求相对应的用户服务。又如，响应于检测到需要向用户提供用户服务，医院支持平台140的处理设备可以控制与该用户服务相对应的物理实体或虚拟实体，来提供该用户服务。例如，响应于检测到患者被送入医院病房，医院支持平台140的处理设备可以控制智能护理推车，引导护士到医院病房对患者进行入院检查。

在一些实施例中，可以基于相关用户与虚拟医院130之间的交互向相关用户提供至少一部分用户服务。交互是指相关用户和虚拟医院130之间的相互作用或影响(例如，对话、行为等)。例如，相关用户与虚拟医院130之间的交互可以包括相关用户与虚拟医院130中的数字孪生体之间的交互、相关用户与智能体之间的交互、相关用户与虚拟人物之间的交互等，或其任何组合。

在一些实施例中，可以基于相关用户与数字孪生体中的至少一个之间的交互，向相关用户提供至少一部分用户服务。例如，可以通过用户空间应用120接收由相关用户输入的第二数字孪生体的更新指令，并且可以根据该更新指令更新第二数字孪生体的相应物理实体。作为另一示例，用户可以通过用户空间应用120查看物理实体的第一数字孪生体(例如，患者器官或硬件设备的3D数字孪生体模型)，以了解物理实体的状态。可选地，用户可改变数字孪生体的显示角度、显示尺寸等。

在一些实施例中，医院支持平台140的处理设备可以通过用户空间应用呈现与智能体相对应的虚拟人物，与相关用户进行交互，并基于相关用户与虚拟人物之间的交互，向相关用户提供至少一部分用户服务。

在一些实施例中，医院支持平台140可以具有五层结构，包括硬件设备层、接口层、数据处理层、应用开发层和服务层，可以参见图3及其相关描述。在一些实施例中，物理医院110的硬件设备可以是医院支持平台140的一部分。

根据本说明书的一些实施例，通过综合整合物理医院的各种内部和外部资源(例如，医疗服务设备、医院人员、药品和耗材等)，可以建立与物理医院相对应的虚拟医院。该虚拟医院可以反映与物理医院相关的物理实体的实时状态(例如，变化、更新等)，从而实现对物理实体的监控和评估。这种集成可以为医疗服务的运营和智能决策提供准确的数据支持。此外，通过虚拟医院，与医疗服务相关的用户可以共同建立一个开放共享的生态系统，从而促进医疗服务的创新和提升。

此外，可以提供医院内外联动的全生命周期患者医疗保健服务。医疗服务的视角从单纯的疾病治疗扩展到涵盖患者的整个生命周期，包括预防、诊断、治疗、康复、健康管理等。通过建立院内外联动，物理医院可以更好地整合线上线下资源，为患者提供全面、持续的医疗卫生服务。例如，通过远程监控和在线就诊，可以实时随访患者的健康状况，及时调整治疗方案，改善治疗效果。

图2是根据本申请的一些实施例所示的示例性医疗服务系统的示意图。

如图2所示，医疗服务系统200可以包括处理设备210、网络220、存储设备230、一个或多个医疗服务设备240、一个或多个感知设备250、患者261的一个或多个患者终端260、以及与患者261相关联的医生271的一个或多个医生终端270。在一些实施例中，医疗服务系统200中的组件可以通过无线连接、有线连接或其组合相互连接和/或通信。医疗服务系统200各组件之间的连接可以是可变的。

处理设备210可以处理从存储设备230、医疗服务设备240、感知设备250、患者终端260和/或医生终端270获得的数据和/或信息。例如，处理设备210可以将与物理医院有关的数据映射到与物理医院相对应的虚拟医院，并通过处理与物理医院有关的数据，分别通过患者终端260和/或医生终端270向患者261和医生271提供用户服务。作为另一示例，处理设备210可以维持数字智能对象，并通过使数字智能对象参与处理与物理医院有关的数据，分别通过患者终端260和/或医生终端270向患者261和医生271提供用户服务。

在一些实施例中，处理设备210可以是单个服务器或服务器组。服务器组可以是集中式的，也可以是分布式的。在一些实施例中，处理设备210可以位于医疗服务系统200的本地或远程。在一些实施例中，处理设备210可以在云平台上实现。例如，云平台可以包括私有云、公共云、混合云、社区云、分布式云、云间云、多云等，或其任何组合。

在一些实施例中，处理设备210可以包括一个或多个处理器(例如，单核处理器或多核处理器)。仅为了说明，在医疗服务系统200中只描述了一个处理设备210。然而，应当注意的是，本申请中的医疗服务系统200还可以包括多个处理设备。因此，如本申请，由一个处理设备210执行的操作和/或方法步骤也可以由多个处理设备联合或单独执行。

网络220可以包括能够促进医疗服务系统200的信息和/或数据交换的任何合适的网络。网络220可以是或包括有线网络、无线网络(例如，802.11网络、Wi-Fi网络)、蓝牙^TM网络、近场通信(NFC)网络等，或其任何组合。

存储设备230可以存储数据、指令和/或任何其他信息。在一些实施例中，存储设备230可以存储从医疗服务系统200的其他组件获得的数据。在一些实施例中，存储设备230可以存储处理设备210可以执行或用于执行本申请中描述的示例性方法的数据和/或指令。

在一些实施例中，存储在存储设备230中的数据可以包括多模态数据。多模态数据可以包括多种形式的数据(例如，图像、图形、视频、文本等)、各种类型的数据、从不同来源获得的数据、与不同医疗业务(例如，诊断、手术、康复等)有关的数据、与不同用户(例如，患者、医务人员、管理人员等)有关的数据。例如，存储在存储设备230中的数据可以包括反映患者261的健康状况的医疗数据。例如，医疗数据可以包括患者261的电子健康档案。电子健康档案是指记录各类患者数据(例如，基本信息、检查数据、成像数据)的电子文件。例如，电子健康档案可以包括患者261的多个器官和/或组织的三维模型。

在一些实施例中，存储设备230可以包括大容量存储设备、可移动存储设备、易失性读写存储器、只读存储器(ROM)等，或其任何组合。在一些实施例中，存储设备230可以包括数据湖和数据仓，将结合图3进行详细描述。

医疗服务设备240可用于提供或辅助医疗服务。如图2所示，医疗服务设备240包括诊室终端240-1、医院病床240-2、智能手术终端240-3、智能护理推车240-4、智能轮椅240-5等，或其任何组合。

诊室终端240-1是指配置在诊室内供医生和患者在医疗门诊流程中使用的终端设备。例如，诊室终端240-1可以包括屏幕、声音输出组件、图像传感器或声音传感器中的一个或多个。诊室终端240-1的屏幕上可以显示就诊界面，就诊界面上可以显示数据，以促进医患之间的交流。示例性的数据可以包括电子健康档案(或其一部分)、预问诊记录、医学图像、3D器官模型、检查结果、看诊建议等。

医院病床240-2是指医院病房内能够支持住院患者并向患者提供用户服务的病床。医院病床240-2可以包括床、床边终端设备、床边检查设备、传感器等，或其任何组合。床边终端设备可以包括XR设备、显示设备、移动设备等，或其任何组合。在一些实施例中，医院病床240-2可由住院服务相对应的智能体控制，其中医院病床也可称为智能医院病床或元医院病床。

智能手术终端240-3是指配置有用于辅助手术的智能体的设备，以及由与手术服务相对应的智能体控制。智能手术终端240-3可以感知医疗服务提供者、患者和智能体之间的交互(例如，对话、行为等)，并获取由感知设备250捕获的数据，从而提供手术辅助。在一些实施例中，智能手术终端240-3可以配置为基于其中配置的智能体执行外科手术的风险警告、生成手术流程的手术记录等。

智能护理推车240-4是指具有自动驱动功能，能够辅助患者治疗和护理的护理车。例如，可以将智能护理推车240-4配置为引导护士到医院病房对患者进行入院检查。在一些实施例中，智能护理推车可由智能体(例如，与住院服务相对应的智能体、护理智能体)控制。在一些实施例中，智能护理护理推车240-4可以包括手推车、呈现设备、一个或多个检查设备和/或护理工具、感知设备(如图像传感器、GPS传感器、声音传感器等)等。在一些实施例中，智能护理推车240-4可配置为获取患者的相关治疗和护理信息，并生成查体数据、护理数据等。查体数据可以包括患者的生命体征数据。护理数据可以包括护理操作的详细记录，例如，护理时间、护理操作员、护理措施、患者反应等。

智能轮椅240-5是指一种用于智能接送患者的运输设备。在一些实施例中，智能轮椅240-5可以配置为通过集成传感器和地图执行自主导航，使用射频识别设备(RFID)、蓝牙或Wi-Fi信号定位患者的位置，通过生物识别技术识别患者。在一些实施例中，智能轮椅240-5可由智能体(例如，与住院服务相对应的智能体、与手术服务相对应的智能体)控制。在一些实施例中，智能轮椅240-5可以配置为通过内置摄像头/传感器感知交互数据来生成数据(例如，智能体与患者之间交互内容的记录)。

感知设备250可以被配置为采集与其所处环境相关的感知信息。在一些实施例中，感知设备250可以包括物理医院110中的感知设备。例如，感知设备250可以包括图像传感器250-1、声音传感器250-2、温度传感器、湿度传感器等。

患者终端260可以是与患者261相互作用的终端设备。在一些实施例中，患者终端260可以包括移动终端260-1、XR设备260-2、智能可穿戴设备260-3等。医生终端270可以是与医生271交互的终端设备。在一些实施例中，医生终端270可以包括移动终端270-1、XR设备270-2等。在一些实施例中，患者261可以通过患者终端260访问用户空间应用(例如，患空间应用)，医生271可以通过医生终端270访问用户空间应用(例如，医空间应用)。在一些实施例中，患者261和医生271可以通过患者终端260和医生终端270彼此进行远程沟通，从而提供远程医疗服务，例如，远程门诊服务、远程查房服务、远程随访服务等。

可以将感知设备250、患者终端260和医生终端270配置为数据源，以向医疗服务系统200提供信息。例如，这些设备可以将采集到的数据传输到处理设备210，并且处理设备210可以基于接收到的数据提供用户服务。

应当注意的是，上述医疗服务系统100和200的描述旨在说明性，而不是限制本申请的范围。对于本领域技术人员来说，许多替代、修改和变化将是显而易见的。本文的示例性实施例的特征、结构、方法和其他特征可以以各种方式组合，以获得附加的和/或可选的示例性实施例。例如，医疗服务系统200可以包括一个或多个附加组件，例如，其他用户的终端设备、医院的公共终端设备等。作为另一示例，可以将医疗服务系统200的两个或多个组件可以集成到单个组件中。

图3是根据本说明书一些实施例所示的医院支撑平台的架构示意图。

如图3所示，医院支撑平台300可以包括硬件层310、接口层320、数据处理层330、应用开发层340和服务层350。在本说明书中，除非明显地从上下文中获得或上下文中另有说明，否则术语“层”和术语“模块”可以互换使用。例如,硬件层也可以被称为硬件模块，接口层也可以被称为接口模块，数据处理层也可以被称为数据处理模块，应用开发层也可以被称为应用开发模块，服务层也可以被称为服务模块。应当理解，本说明书中的“层”和“模块”仅用于对医院支撑平台中的组件进行逻辑划分，而并旨在于对此进行限定。

医院支撑平台可以指用于为医院的运行和管理提供支撑的平台。例如，医院支撑平台可以用于支撑资源(如硬件资源、数据资源等)的调度、协调、控制与处理；也可以用于支撑提供给各类用户和机构的服务(如医疗服务、人工智能服务、运营服务等)。

硬件层310可以为现实世界和数字世界的交互提供硬件基础，其可以包括一个或多个与医院运行有关的硬件设备。示例性的硬件设备包括医疗服务设备、感知设备、终端设备、基础设备等。

医疗服务设备可以包括医疗业务(如诊断、治疗、康复等)中所用的各类设备。例如，其可以包括医学扫描设备(如CT设备、PET/CT设备、MRI/CT设备、超声成像设备等)、手术机器人等大型医疗器械。又例如，医疗服务设备可以包括床旁监护仪、助听器、智能手表、心脏起搏器等便携式或可植入的小型医疗健康设备或传感器。

感知设备用于对其所在的环境进行感知并采集相应的感知信息。示例性的感知设备包括图像传感器、声音传感器、温度传感器、湿度传感器等各类传感器。感知设备可以是独立的设备，例如，安装在诊室中的监控设备。感知设备也可以集成于其他设备中，例如，声音传感器可以集成在终端设备中。

终端设备可以与用户(如病人、医生、护士、医院管理者等)进行交互。示例性的终端设备包括手机、平板电脑、笔记本电脑、可穿戴设备、显示器等。在一些实施例中，终端设备还可以包括扩展现实(Extended Reality，XR)设备，用于让用户体验沉浸式数字环境并与之进行交互。XR设备可以包括VR设备、AR设备、MR设备等中的一种或组合。

基础设备用于为数据的传输、存储和处理提供硬件基础。基础设备可以包括网络、机房设施、计算机设备(如处理设备)、计算芯片、存储设备等。

在一些实施例中，硬件层310中的硬件设备可以用于采集与医院业务有关的数据。例如，医学扫描设备可以用于采集医学影像数据；终端设备可以用于采集其与用户的交互数据；感知设备可以用于采集感知信息。

在一些实施例中，上述硬件设备中的一个和多个可以是物联网(Internet ofThings，IoT)设备。物联网设备指的是通过互联网互联互通，可以感知、收集和传输数据的硬件设备。例如，上文所述的医疗服务设备、感知设备可以是物联网设备，其可以将采集的数据通过通信技术(如有线/无线网络、蓝牙、Zigbee、LoRaWAN等)发送给医院支撑平台300的其他层进行存储和/或处理。

在一些实施例中，硬件层310中的至少部分硬件设备(如每一个硬件设备)需要符合预设硬件标准。预设硬件标准可以包括但不限于设备规格(设备的尺寸、型号)、数据传输协议(如数据传输的方式、数据的结构、数据类型等)、设备厂商等。

在一些实施例中，硬件层310可以包括硬件管理装置，其可以用于生成和更新硬件设备的硬件配置信息。更多关于硬件配置信息的内容参见图4及其描述。

接口层320与硬件层310和数据处理层330相连接。接口层320可以用于获取硬件层310中的硬件设备采集的数据，并将该数据发送给数据处理层进行存储和/或处理。接口层320也可以用于对硬件层310中的至少部分硬件设备进行控制。

在一些实施例中，接口层320可以包括硬件接口和软件接口(也可以称之为软硬件接口)。

硬件接口可以用于实现与硬件层310的硬件设备的物理连接或通讯连接。硬件接口可以包括有线通信接口，例如，串行通信接口、并行通信接口、通用串行总线(UniversalSerial Bus，USB)接口、以太网接口等。硬件接口可以包括无线通信接口，例如，Wi-Fi接口、Bluetooth接口、Near Field Communication接口等。

软件接口定义了不同的软件组件或系统相互交互的方式。与涉及物理和电气连接的硬件接口不同，软件接口是支持软件实体之间通信、数据交换和功能调用的抽象方法。软件接口可以包括Application programming interface(API)、协议(如超文本传输协议(Hyper Text Transfer Protocol，HTTP)、文件传输协议(File Transfer Protocol，FTP)、简单对象访问协议(Simple Object Access Protocol，SOAP)等。

在一些实施例中，软件接口可以包括数据接口，用于实现与硬件设备之间的数据交互。不同的硬件设备可以对应不同的数据接口。例如，医疗影像设备可以通过医疗数据接口将其所采集的医疗影像数据传输至接口层320。

接口层320通过数据接口获取或接收硬件设备采集的数据，以为数据处理层330提供数据基础。需要说明的是，数据接口在传输数据时不会对数据内容进行任何修改，从而保证硬件设备采集的原始数据可以被传输至数据处理层330进行存储和/或处理。在一些实施例中，数据接口定义了数据的传输标准信息，用于指示数据传输的协议、格式和模式等。数据传输标准信息可以包括行业内的标准数据传输协议，如医学数字成像和通信(DigitalImaging and Communications in Medicine，DICOM)协议等。数据传输标准信息可以包括自定义数据传输协议，其可以根据实际情况(如安全性要求)进行设置。

在一些实施例中，接口层320可以被配置为对硬件设备的至少一部分进行控制。如图3所示，软件接口还可以包括控制接口，其可以用于控制硬件设备的至少一部分。例如，其可以通过控制接口向硬件设备发送控制指令(如命令、代码指令)，以使得硬件设备执行控制指令对应的功能或行为，并反馈相关的信息(如状态信息)。

在一些实施例中，控制指令可以由数据处理层330(如数据处理单元)生成，即数据处理层330可以通过接口层320与硬件层310进行交互。其中，控制指令可以根据不同的硬件设备及其控制协议生成。例如，控制指令可以包括但不限于硬件设备标识、控制参数(如旋转角度、移动方向等操作参数)等。

需要说明的是，数据接口和/或控制接口可以作为软件实现，并且可以被存储在任何类型的非暂时性计算机可读介质或存储设备中。在一些实施例中，数据接口和/或控制接口可由其他单元/模块(如数据处理层330的数据处理单元)、或硬件设备(如硬件层310的硬件设备)调用，和/或可以响应于检测到的事件而被调用。

在一些实施例中，接口层320还可以包括与医疗业务解耦的预设算法(图中未示出)，用于进行与医疗业务无关或弱相关的处理。作为示例，与医疗业务解耦的预设算法可以包括数据流量分析算法、基础AI算法等。例如，在不影响数据内容的情况下，通过数据流量分析算法和/或基础AI算法，对数据流量(如数据传输频率、数据量等)进行分析，以实现数据流量的监控。又例如，接口层320中的基础AI算法可以被数据处理层330中的数据处理单元调用，以用于实现与医院业务有关的处理任务。

在一些实施例中，接口层320或其一部分可以与数据处理层330集成一体的。例如，数据接口和/或控制接口可以部署在数据处理层330，以作为数据处理层330的一部分。示例性的，数据接口和/或控制接口可以以接口单元或模块的形式设置在数据处理层330。

数据处理层330用于对数据进行存储和/或处理。例如，数据处理层330可以包括数据处理单元。数据处理层330被配置为从接口层320获取数据，并通过数据处理单元中的至少一个对数据进行处理，以实现与医院业务相关的用户服务。

数据处理单元可以包括各类用于实现数据处理的预设算法，其可以是通过各类计算机编程语言(如Java、C/C++)实现的软件、程序、计算机代码和/或指令的形式。在一些实施例中，数据处理层330包括处理设备(如图2所示的处理设备220)，数据处理单元可以配置在处理设备上。

在一些实施例中，数据处理单元可以包括扩展现实(XR)单元，其被配置为利用扩展现实技术实现扩展现实服务。其中，扩展现实服务可以包括VR服务、AR服务和MR服务等。例如，通过提供MR服务，可以将虚拟医院中的数字内容(如三维器官模型、虚拟人物)叠加到用户的真实视野上，以使得用户能够与数字内容进行交互。

本说明书一些实施例中，通过集成扩展现实单元，使得医院支撑平台能够具备支持扩展现实服务的能力，在医疗业务中为用户(如医护人员、患者)提供更直观、更自然的交互方式，提升用户服务效率和质量。

在一些实施例中，数据处理单元可以包括人工智能(Artificial Intelligence，AI)单元，其被配置为利用人工智能技术来实现人工智能服务。其中，人工智能技术包括但不限于机器学习(Machine Learning，ML)、深度学习(Deep Learning，DL)、自然语言(Natural Language Processing，NLP)处理、计算机视觉(Computer Vision，CV)、语音识别等技术。

在一些实施例中，AI单元可以包括多个AI子单元，至少有部分AI子单元可以对应不同的医院业务和/或任务，用于对不同的医院业务有关的数据进行处理和/或实现不同的任务。示例性的，AI单元可以包括自然语言处理子单元、图像识别子单元、语音识别子单元等。

在一些实施例中，人工智能单元可以包括基于AI技术构建的智能体单元。每个智能体单元用于维护一种智能体。智能体可以指能够代表用户和/或应用程序进行自动执行任务的软件实体，其可以感知环境，处理信息，做出决策，并执行动作以实现特定的目地。智能体被设计成具有适应性、学习性、自主性和目标导向行为等的特性。在一些实施例中，可以针对不同的医院业务场景(如诊断、手术等)、角色(如医生、护士等)、用户服务等设置不同的智能体单元(即不同的智能体)，以提供相应的智能体服务。例如，智能体单元可以包括医生智能体单元、护士智能体单元、技师智能体单元等。

在一些实施例中，智能体可以基于AI技术和硬件设备采集的医院业务相关的数据进行自主学习和演化，以适应医院业务或其所提供的医疗服务的变化。仅作为示例，智能体可以基于自然语言处理技术(如大预言模型等)构建，通过对大量语言文本(如医院业务数据、患者的反馈信息)进行自动地学习和自主更新，以提升其所提供的服务的质量。

本说明书一些实施例中，通过集成人工智能单元，使得医院支撑平台能够具有支撑人工智能服务的能力，以实现在医疗业务中结合人工智能算法进行高效的数据分析和处理。另外，通过配置智能体单元来维护多种智能体，使得不同的医院业务场景或医疗任务的处理更加智能化，并使得医院支撑平台能够自我演化从而提供更高质量的服务。

在一些实施例中，数据处理单元可以包括数字孪生单元，其被配置为利用数字孪生技术实现数字孪生服务。

数字孪生(Digital Twin)技术可以用于对现实世界的物理实体进行数字化，并实现现实世界与数字化(虚拟化)世界之间的虚实联动。其中，物理实体可以是医院相关的各类现实实体，如物理空间、人员(如医生、护士等)、硬件设备、用户服务、医疗流程等。数字孪生体可以是物理实体的数字化副本，其可以包括但不限于3D模型、图像、文字等表示形式。示例性的，数字孪生体可以是医院实体对应的虚拟医院、人员实体(如医生、护士、患者)对应的虚拟人员(如虚拟医生、虚拟护士、虚拟患者)、医疗服务设备(如成像设备、手术刀)对应的虚拟设备(如虚拟成像设备、虚拟手术刀)等。

数字孪生服务可以指现实世界的物理实体与数字孪生体的联动或互动服务。例如，当现实世界的物理实体的状态发生改变时，其对应的数字孪生体可以被相应更新。仅作为示例，医疗服务设备的状态更新、人员的表情体态的更新等会引起其对应的数字孪生体的更新。基于这类会随对应的物理实体不断更新的数字孪生体，用户可以了解医院有关的物理实体的实时状况，从而实现对物理实体的监控、评估等。又例如，当虚拟世界的数字孪生体被更新时，其在物理世界中对应的物理实体可以被相应更新。仅作为示例，医院管理者可以通过管空间应用对硬件设备、医疗服务、医疗流程等对应的数字孪生体的参数进行更新。相应地，现实世界中的硬件设备、医疗服务、医疗流程等的参数也会对应更新。基于这类可以影响对应的物理实体的状态的数字孪生体，用户可以实现对医院有关的物理实体的控制、更新等。再例如，数字孪生体(如三维的虚拟患者模型)可以通过XR技术呈现给现实世界的用户，该用户可以与数字孪生体进行交互。

在一些实施例中，数字孪生单元可以基于XR单元和/或AI单元对数据进行处理，以实现高质量的数字孪生服务。例如，数字孪生单元可以调用XR单元，以利用XR技术向用户呈现数字孪生体、实现用户与数字孪生体的交互。又例如，数字孪生单元可以调用AI单元，以利用AI技术实现更准确的状态映射和状态预测。

本说明书一些实施例中，通过设置数字孪生单元，使得医院支撑平台能够具备支撑数字孪生服务的能力，并基于数字孪生服务实现现实世界与虚拟世界之间的实时联动与互动，从而提升各类用户服务的服务质量。

在一些实施例中，数据处理单元可以包括数据流通单元，其被配置为利用数据流通技术对数据进行处理，以实现数据流通服务。

数据流通服务可以包括数据的传输服务、共享服务、交换服务等。例如，数据流通服务可以包括不同系统之间的数据传输与交换服务。在一些实施例中，数据流通服务可以包括跨医疗机构的数据流通服务。例如，数据流通服务可以实现不同医疗机构之间进行数据共享、传输与交换。

数据流通技术可以包括各类数据隐私计算技术和/或数据安全技术。数据隐私计算技术可以用于根据各种预设的隐私保护规则对数据进行处理，以保障数据流通中隐私信息(如用户的个人信息)不受侵犯和泄露。其中，预设的隐私保护规则可以是医疗行业通用的规则或法律等。数据隐私计算技术包括加密技术、联邦学习技术、隐私差分技术、多方安全计算技术、安全外包技术等。数据隐私计算可以实现数据的所有权、管理权和使用权的分离以及数据价值的流通。

数据安全技术可以用于保障数据在流通过程中的安全性、完整性和可用性，防止数据受未经授权的访问、泄露、篡改或破坏。数据安全技术可以包括但不限于加密技术、哈希函数、数字签名技术、密钥交换协议等。

在具体应用中，可以根据实际的情况或需求(如数据量的大小、数据流通的效率、数据的隐私程度、安全等级等)确定采用的数据隐私计算技术和/或数据安全技术。

在一些实施例中，数据流通技术可以至少包括区块链(Block Chain)技术和数据隐私计算(Privacy Computing)技术。区块链技术是一种去中心化的分布式账本技术，旨在安全地记录、验证和共享网络中多个节点的信息，而无需中心机构。

本说明书一些实施例中，通过设置数据流通模块，使得医院支撑平台具有支撑跨医疗机构和/或跨系统之间进行数据流通的能力。另外，引入区块链技术和隐私计算技术，能够提高数据流通的安全性，避免了数据被滥用或泄露。

在一些实施例中，数据处理层330还包括数据中心，以对数据进行存储。数据中心可以包括各类存储设备/存储介质，例如大容量存储设备、可移动存储设备、易失性读写内存、只读存储器(ROM)等，或其任意组合。示例性的，数据中心可以包括大容量存储设备(如磁盘、光盘、固态驱动器)、可移动存储设备(光盘、内存卡)、随机存取内存(RAM)等。在一些实施例中，数据中心可以部署在云平台(如公有云、私有云)上。

在一些实施例中，数据中心采用湖仓一体的架构，其包括数据湖和数据仓(也称数据仓库)。数据湖用于持久化存储海量数据。数据仓用于存储数据湖中的数据对应的索引数据。数据湖中存储的数据可以包括硬件设备采集的原始数据、基于该原始数据生成的数据等。数据湖中存储的数据是多模态的，可以包括不同数据来源(如不同的硬件设备)的数据、不同医疗业务(如诊断、手术、康复等)有关的数据、不同用户(如患者、医护人员、管理人员等)有关的数据、不同数据类型(如图像、声音、视频、文件)的数据。在一些实施例中，数据湖被配置为以防篡改的方式对硬件设备采集的医院业务相关的数据进行持久化存储。更多关于数据湖仓的内容参见图5及其描述。

应用开发层340可以用于支持应用开发、发布、订阅等，其也可以被称为生态套件层。

在一些实施例中，应用开发层340被配置为提供开放接口，以供应用开发者访问或调用数据处理单元或其一部分，并利用数据处理单元的至少一部分进行应用开发。也就是说，数据处理层的各种数据处理能力可以通过应用开发层340开放给应用开发者，以供应用开发者在此基础上开发各类应用。开发者可以包括个人、机构(如医院、IT技术公司)或任意实体。开放接口可以指使开发者能够访问或调用数据处理单元的入口。在一些实施例中，开放接口可以包括应用程序编程接口(Application Programming Interface，API)等。

在一些实施例中，如图3所示，应用开发层340可以提供开发工具、应用市场、多租户运营平台、云官网、工作空间等协助开发者工作的支持套件。关于开发工具、应用市场、运营平台的更多内容参见图8及其描述。云官网为开放门户网站，用于供开发者获取应用开发层的340提供的各类支持服务(如开发工具)。工作空间用于组合和配置用户工作空间，并为医生、患者和护士提供工作化的体验。

本说明书一些实施例中，通过设置应用开发层，能够为多方(如个人开发者、医疗机构、医疗服务设备厂商、药品供应商、IT技术公司等)提供获取各类数据处理单元的入口和各类支持套件，以促进相关应用的开发，共同推动医疗业务和/或医疗生态的发展。

服务层350用于通过用户空间应用使相关用户可以访问和获取与医院业务相关的用户服务。

用户服务可以包括各类与医院业务相关的服务。示例性的用户服务可以包括用于影像服务、电子健康档案服务、医疗服务设备管理服务、扩展现实服务、疾病筛查服务、可视计算服务、医患沟通服务等。在一些实施例中，用户服务可以包括针对患者的患空间服务、针对医护人员的医空间服务、针对医院或医疗机构的管空间服务等。在一些实施例中，用户服务可以是由数据处理层330提供的原生服务，也可以是通过应用开发层340提供的第三方服务。例如，用户可以通过应用开发层340的应用市场获取第三方发布的用户空间应用，从而获得第三方服务。

用户空间应用是用户获取各类用户服务的入口，也是用户与医院支撑平台进行交互的交互接口。其中，用户空间应用包括但不限于应用程序(如App)、网站(如Website)、服务接口(如Service Interface)等中的一种或多种组合的形式。

在一些实施例中，如图3所示，用户空间应用可以包括患空间应用、医空间应用、管空间应用。其中，患空间应用可以指为患者提供患空间服务的应用；医空间应用可以指为医护人员提供医空间服务的应用；管空间应用可以指为医院或医疗机构的管理人员提供管空间服务的应用。示例性的患空间应用包括挂号服务、导航服务、预问诊服务、远程问诊服务、住院办理服务、出院办理服务等。示例性的医空间服务包括日程安排服务、手术规划服务、手术模拟服务、患者管理服务、远程查房服务、远程问诊服务等。示例性的管空间服务包括区域监控服务、医疗服务评估服务、设备参数设置服务、服务参数设置服务、资源调度服务等。

在一些实施例中，用户空间应用可以由医院提供或开发得到。在一些实施例中，用户空间应用可以由第三方提供或开发。例如，第三方可以通过将用户空间应用发布到应用开发层340的应用市场上。

在本说明书的一些实施例中，通过为各类用户分别提供用户空间应用，使每类用户可以在其对应的用户空间应用上方便地获取各类他/她可能会用到的服务。在现有的医院服务体系中，通常需要用户安装各类应用来分别获取不同的服务，导致用户体验差、开发成本高。与现有的技术相比，本说明书中的方案可以提高用户体验，且提高服务质量，降低开发成本。

在一些实施例中，数据处理层330可以利用数据处理单元将至少一部分数据映射至虚拟医院，进一步的，用户空间应用可以包括为用户提供与虚拟医院进行交互的入口，以使得用户获得服务层350中的至少一部分用户服务。在一些实施例中，当用户与虚拟医院进行交互时，虚拟医院或其一部分可以基于XR技术呈现给用户。在一些实施例中，虚拟医院或其一部分可以通过MR技术叠加在用户的真实世界视野上。更多关于虚拟医院的内容参见图1及其描述。

应当注意的是，医院支撑平台300仅仅是为了说明的目的而提供的，并不意图限制本说明书的范围。对于本领域的普通技术人员来说，可以根据本说明书的描述，做出多种修改或变化。然而，这些变化和修改不会背离本说明书的范围。在一些实施例中，一个或多个层(如，应用开发层340)可以省略。在一些实施例中，医院支撑平台300还可以包括一个或多个其他的层。在一些实施例中，医院支撑平台300中的两个或多个层可以合并为一个层，例如，接口层320可以集成在数据处理层330。在一些实施例中，医院支撑平台300中的一个层也可以被分成多个子层，例如，数据处理层330可以被分成数据存储子层和数据处理子层。在一些实施例中，医院支撑平台300的一个或多个层可以是依次连接的，例如，硬件层310、接口层320和数据处理层330可以是依次连接并彼此间依次互相交互的。在一些实施例中，医院支撑平台300的不同的层之间的连接方式可以是多样化的。例如，服务层350可以直接连接到数据处理层330(如图3示出的虚线)。

在一些实施例中，医院支撑平台300的数据交互(例如硬件层310、接口层320、数据处理层330、应用开发层340和服务层350中的每一个层内部或者不同层之间的数据交互)需要符合预设的数据隐私规范和数据安全规则。具体来说，任何数据获取方(包括软件和硬件)在获取特定数据时，需要经过身份验证和隐私验证。身份验证用于验证数据获取方是否有权限获取数据。隐私验证用于验证所述特定的数据中是否包含隐私数据(如患者的个人数据)、数据获取方是否有权限访问该隐私数据。仅作为示例，数据处理层330的数据处理单元和应用开发层340的API在获取或访问数据湖中的数据时，需要先进过身份验证和隐私验证，验证通过后才能获取或访问相应的数据。又例如，应用开发层340的多租户在访问其他租户的数据时，需要先进行身份验证，当该租户有访问权限时才能访问其他租户的数据。在一些实施例中，预设的数据隐私规范和数据安全规则可以包括“健康保险可携性和责任法案”(Health Insurance Portability and Accountability Act，HIPPA)、“通用数据保护条例”(General Data Protection Regulation，GDPR))等医疗领域中常用的数据隐私规范和数据安全规范。

图4是根据本说明书一些实施例所示的对硬件设备进行验证的过程的示例性流程图。在一些实施例中，流程400可以由接口层320执行。例如，接口层320包括的软硬件接口可以用于对与其连接的硬件设备进行验证。如图4所示，流程400包括下述步骤。

步骤410，获取硬件设备的硬件配置信息。

硬件配置信息可以包括硬件的基本信息，例如，硬件设备的名称、型号、制造厂商、生产日期等。

在一些实施例中，硬件配置信息可以包括设备身份信息，其为硬件的唯一标识。设备身份信息可以根据预设的规则生成，例如，其可以基于设备的Mac地址或者具有唯一性的设备id或设备编号确定。

在一些实施例中，硬件配置信息可以包括硬件设备的运行状态信息，其可以显示硬件设备的运行状况(如当前运行状况)。例如，硬件配置信息可以显示硬件设备是否异常、异常类型、异常次数、历史维修次数、服务时长等。

在一些实施例中，硬件的硬件配置信息可以由硬件设备自己生成并发送给接口层320。在一些实施例中，硬件层310包括硬件管理设备，其被配置为生成至少部分硬件设备的硬件配置信息，并将该硬件配置信息发送给接口层320。例如，硬件管理设备可以对至少部分硬件设备进行状态监控(如基于心跳机制进行监控)，并将监控结果作为运行状态信息发送给接口层320。

步骤420，确定硬件配置信息是否满足预设条件。

预设条件可以用于评估硬件设备的身份和/或运行状态是否符合期望的要求。

例如，对硬件设备(或其一部分)中的每个硬件设备，接口层320可以基于设备身份信息，确定硬件设备是否为多个可信任设备中的一个；响应于确定该硬件设备为多个可信任设备中的一个，接口层320可以确定该硬件设备对应的硬件配置信息满足预设条件。在一些实施例中，多个可信任设备可以由硬件层310中的硬件管理设备预设配置。示例性的，硬件管理设备可以存储多个可信任设备的id列表。

又例如，对硬件设备(或其一部分)中的每个硬件设备，接口层320可以基于运行状态信息，确定硬件设备的当前运行状态是否正常；响应于确定硬件设备的当前运行状态是正常的，接口层320可以确定该硬件设备对应的硬件配置信息满足预设条件。

步骤430，响应于硬件配置信息满足预设条件，将数据传输至数据处理层。

在本说明书的一些实施例中，接口层320可以先对硬件设备的身份和/或运行状态进行验证，只有当硬件通过验证时才会将其采集的数据发送给数据处理层。通过这种方式，可以防止恶意设备或者异常设备对医院支撑平台的影响，提高数据的可靠性和准确性，从而保证后续提供的用户服务的准确性。

图5是根据本说明书一些实施例所示的数据湖仓的示例性示意图。

数据湖仓520包括数据湖521和数据仓522。数据湖521可以持久化存储数据510。持久化存储是在预设的时间段内保存数据的一种方式，其能够确保即便系统断电或重启时，存储的数据依然能够被访问和保持完整性。

数据510可以包括各种类型、结构或格式的数据。如图5所示，数据510可以包括结构化数据511、半结构化数据512和非结构化数据513。结构化数据511是高度组织化的数据，通常具有固定的数据结构。示例性的结构化数据511包括医生基本信息、硬件设备基本信息、档案、管理/运营数据等。半结构化数据512具有一定的结构，但这种结构并不严格。示例性的半结构化数据512包括临床信息/文档、可穿戴设备健康数据、用户行为日志、设备运行状态日志、服务度量/日志/链路信息等。非结构化数据513没有预定义模式或组织方式。示例性的非结构化数据513包括音频、视频、图像、扫描文档、三维模型、机器学习模型、数字孪生模型、心电/病理/细胞/电镜数据、蛋白质/基因组学数据等。在一些实施例中，结构化数据511可以以二维数据表的形式储存于数据库(如关系型数据库)中，半结构化数据512或非结构化数据513可以以文件或对象的形式进行存储。

在一些实施例中，数据510可以包括原始数据，其指的是由硬件设备采集的、未经任何内容修改的数据。原始数据可以基于原始(Native)存储模式进行存储，避免文件格式转化导致信息丢失。在一些实施例中，数据510可以包括基于原始数据生成的衍生数据。例如，当数据510被数据处理单元处理时，可能会生成中间处理结果和最终处理结果，这些处理结果可以作为衍生数据存储在数据湖521中。

在一些实施例中，数据湖521可以被配置为以不可篡改的形式存储数据510或其一部分。例如，存储在数据湖521中的原始数据可以被设置为只读(Read Only)模式，以避免其被改写。

由于医疗领域发展快速，某一类型的原始数据可能会被用在各种医疗业务或任务中。通过数据湖521，可以确保硬件设备采集的原始数据被完整、安全地存储起来，以供未来在各种医疗业务或任务中使用。

数据仓522用于存储数据510对应的数据索引，以提高数据510的检索效率。可以针对不同类型的数据510构建不同类型的索引。例如，针对结构化数据511，可以构建数据库索引；对于半结构化数据512和/或非结构化数据513，可以构建文件索引(如目录索引、全文索引、元数据索引等)。对同一个数据记录，可以构建多个数据索引，以实现多维度的数据检索。例如，对CT图像，可以构建患者ID、扫描设备ID、采集时间等数据索引。

在一些实施例中，数据湖仓520还可以包括缓存区域(Cache Layer)，用于存储临时数据或热点数据。临时数据可以是数据510的衍生数据，例如，其可以是在医疗业务处理中生成的临时数据，具有较短的生命周期/存储周期。示例性的，临时数据可以在医疗业务处理完成后被清理。热点数据可以是访问或读取频率较高的数据，其可以与一个或多个医疗业务有关，具有较长的生命周期/存储周期。例如，某个医疗业务处理完成后，其可以继续存储在缓存区域，以供处理其他的医疗业务时被访问或读取。

在一些实施例中，如图5所示，数据湖仓520可以为各类医疗业务处理任务提供数据支持，以实现各类用户服务540。用户服务540可以包括报表服务(如报表的生成与查询)、AI服务、可视化/XR服务、数字孪生服务、数据交易服务等各类用户服务。更多关于用户服务的内容参见图3及其描述。

在一些实施例中，数据湖仓520中的数据可以由处理设备530来处理。处理设备530可以包括数据处理层330中的一个或多个数据处理单元(如XR单元、数字孪生单元等)。更多数据处理层处理数据的方法的内容参见图6及其描述。

本说明书一些实施例中，通过湖仓一体的架构对数据进行存储，在满足大数据存储的需求的同时，也能够为复杂的医疗业务处理任务提供可靠的数据支持，从而为用户提供更加高效的用户服务。

图6是根据本说明书一些实施例所示的数据处理方法的示例性示意图。

在一些实施例中，流程600可以由医院支撑平台(如医院支撑平台300)执行。流程600包括下述步骤。

步骤610，从硬件设备获取数据601。

如图6所示，数据601可以包括接口层320通过数据接口从硬件层310的硬件设备(如医疗服务设备、感知设备、终端设备、基础设备等)获取的数据。更多关于接口层、硬件层的内容参见图3及其描述。

步骤620，将数据601存储至数据湖521。

数据601可以以结构化、半结构化或非结构化的数据格式持久化存储到数据湖521中。更多关于数据湖521的内容参见图5及其描述。

下述步骤630至步骤661可以是由数据处理层(如其中的数据处理单元)执行。

步骤630，利用XR单元对数据进行处理。

XR单元可以利用扩展现实技术对数据601进行处理，以实现扩展现实服务。例如，其可以基于数据601，利用VR、AR、MR技术中的一种或组合，将数据601映射到虚拟医院中，以实现数据601的可视化展示与人机交互。

步骤640，利用AI单元对数据进行处理。

AI单元可以利用AI技术对数据601进行分析、预测等处理，以实现人工智能服务。例如，AI单元可以利用语音识别技术对数据601进行识别，以得到语音识别结果。在一些实施例中，AI单元可以基于用户输入的数据，利用智能体单元(如医生智能体单元、护士智能体单元)与用户进行交互，并生成对应的反馈信息。

在一些实施例中，流程600还可以包括步骤641，XR单元可以调用AI单元对数据601进行处理。

XR单元可以调用AI单元以利用AI技术在扩展现实服务中对数据601进行分析和处理。例如，在虚实融合的场景中，利用AI技术对数据601(如用户反馈的信息)进行分析和预测。

步骤650，利用数字孪生单元对数据进行处理。

数字孪生单元可以利用数字孪生技术对数据601进行处理，以实现数字孪生服务。在一些实施例中，数字孪生单元可以调用XR单元和/或AI单元对数据601进行处理以实现数字孪生服务。

步骤660，利用数据流通单元对数据进行处理。

数据流通单元可以利用数据流通技术对数据601进行处理，以实现数据流通服务。例如，数据流通单元可以对数据601进行数据隐私计算、加密处理，以实现数据601在跨系统和/或跨医疗机构传输、共享和/或交换的安全性。

在一些实施例中，流程600还可以包括步骤661，利用数据流通单元对衍生数据进行处理。

衍生数据是指在医疗业务中实时动态生成的数据。例如，衍生数据可以包括XR单元、AI单元、数字孪生单元等根据医疗业务需求，在对数据601处理的过程中生成的数据。例如，其可以是XR单元获取的用户反馈信息(如语音、文本等)，也可以是AI单元生成的预测结果，还可以是数字孪生单元的处理结果(如患者诊断报告等)。在一些实施例中，衍生数据也可以被持久化存储至数据湖仓520的数据湖521中，以供后续的医疗业务处理任务中使用。在一些实施例中，衍生数据也可以缓存至数据湖仓520的缓存区域。

进一步的，数据流通单元可以根据实际的需求，对衍生数据进行处理，以实现数据流通服务。

需要说明的是，不同的数据处理单元可以对数据湖521中的相同或不同的数据进行处理。除了由硬件设备采集的原始数据601，数据处理单元也可以对数据湖521中存储的其他数据，包括衍生数据、索引数据等进行处理。

本说明书一些实施例中，通过XR单元、AI单元、数字孪生单元、数据流通单元对数据进行处理，使得医院支撑平台可以支撑传统医院无法支持的新生技术(包括XR技术、AI技术、数字孪生技术、数据流通技术等)。将这些新生技术用于医疗业务处理任务中，可以提升数据处理效率和准确性，从而提升用户服务的质量。

图7是根据本说明书一些实施例所示的存储数据的方法的示例性示意图。图7所示的流程700可以由数据处理层(如其中的处理设备)执行。

步骤710，确定数据的评估信息。所述数据指的是经由接口层320获取的由硬件层310的硬件采集的数据。

评估信息可以包括对数据的各类特征(如完整度、质量、安全性、大小)进行评估后得到的信息。例如，评估信息可以包括数据完整度，其可以通过对数据进行完整性评估得到。例如，可以确定数据是否缺少数据、是否缺少关键数据或者缺失数据的比例，以确定数据完整度。可选地，当数据完整度越低(如缺失数据的比例高于阈值)时，可以发出警示，以重新对数据进行获取。又例如，对于图像类型的数据，数据评估信息可以包括图像质量(如清晰度、信噪比)的评估结果。

在一些实施例中，评估信息可以包括数据的安全等级。安全等级可以用于表示数据需要保护的程度。安全等级可以基于数据的敏感性和重要性来确定。一些实施例中，安全等级可以与数据是否包含用户的隐私信息、敏感信息、机密信息有关。如果数据包含隐私信息、敏感信息、机密数据等，数据具有相对较高的安全等级。

在一些实施例中，评估信息可以包括数据量和/或数据采集频率。数据量用于衡量预设的时间段内(如一天、一周)内数据的占用的存储空间大小。数据采集频率用于衡量预设的时间段内数据的采集次数。在一些实施例中，数据处理层330可以基于数据统计的方法确定数据量和数据采集频率。例如，可以统计预设时间段的数据量(如最大值、最小值、平均值等)、数据采集频率(如最大次数、最小次数、平均次数)以得到数据量和数据采集频率。

在一些实施例中，数据处理层330还可以基于评估模型，确定某类数据在未来一段时间的数据量和/或数据采集频率。评估模型可以是长短期记忆网络(LongShort-TermMemory，LSTM)模型或其他基于时间序列的机器学习网络模型。以数据量为例，数据量评估模型的输入包括时间序列数据，输出包括未来一段时间的数据量。其中，时间序列数据包括该类数据在多个历史时间段中的历史数据量。通过评估模型可以自动预测各类数据在未来一段时间中的数据量和/或数据采集频率，从而更好地对数据进行监控。

在一些实施例中，评估信息可以包括数据重要性系数。重要性系数可以反映数据的重要程度。重要性系数可以基于数据与医院业务的关联程度、数据被使用的可能性、数据被使用的频率、数据的安全等级等多个因素综合确定。

步骤720，基于评估信息，确定目标存储策略。

目标存储策略是指数据存储的方式，包括加密存储策略、分布式存储策略等。例如，对于安全等级较高(如安全等级超过阈值)的数据，可以将加密存储策略作为目标存储策略，基于加密算法对其进行加密存储。又例如，当数据对应的数据量和/或数据频率大于阈值时，可以确定数据对应的目标存储策略为分布式存储策略。分布式存储策略可以缓解存储设备的压力。

在一些实施例中，目标存储策略还可以包括数据的存储期限。例如，重要性系数越大，存储期限越长。

步骤730，基于目标存储策略，将数据存储在数据湖中。

图8是根据本说明书一些实施例所示的应用开发层的示例性示意图。如图8所示，应用开发层340可以包括开发工具810、应用市场820和多租户运营平台830。

开发工具810可以包括软件开发工具、库和框架等，以用于进行开发、测试和发布应用程序。开发工具810可以用于简化开发过程，减少编码工作，并确保应用开发人员能够高效地构建功能丰富、用户体验友好且可维护的软件应用程序。开发工具810可以包括API、示例代码(demo source code)、代码开发工具(如代码编辑器、调试器、打包与发布装置等)、技术文档等。

在一些实施例中，各类开发资源可以以软件开发套件(Software DevelopmentKit，SDK)的形式提供给开发者。如图8所示，开发工具810可以包括扩展现实(XR)SDK、人工智能(AI)SDK、数字孪生SDK等。不同的SDK可以包括对应的应用程序编程接口、演示源代码。开发者(如医院开发者、第三方开发者)可以根据需求通过应用开发层340从开发工具810中下载期望的SDK以进行应用的开发。例如，开发者可以通过扩展现实SDK开发与扩展现实有关的应用。

应用市场820用于支持应用的在线发布、订阅、下载、交易等。如图8所示，应用市场820可以包括应用1、应用2、应用3等多个应用。其中，每个应用可以由发开者利用开发工具810开发和/或更新，并发布至应用市场820中。用户可以从应用市场820中下载应用，并利用下载的应用获取相应的用户服务。

在一些实施例中，应用市场820中的应用可以用于实现服务层350中的一个或多个用户服务(如患空间服务、医空间服务、管空间服务)。如图8所示，应用市场820中的应用可以包括服务层350中针对患者的患空间应用、针对医护人员的医空间应用、针对管理人员的管空间应用。

多租户运营平台830是指为多个医疗机构提供运营服务的平台，其可以为不同的医疗机构提供跨院区运营、院区运营、科室运营等服务。示例性的运营服务包括人员管理、跨院区/科室资源调度、院区/科室评估、账号权限管理等。如图8所示，多租户运营平台830可以包括医疗机构1、医疗机构2、医疗机构1等对应的运营平台。

在一些实施例中，应用开发层340可以基于多租户模式构建。多租户模式是一种软件架构模式，其允许软件应用程序或数据库的单个实例为多个租户(即应用程序开发人员、医院、医疗保健组织或用户组)提供服务。

在一些实施例中，应用开发层340可以是部署在云平台(如公有云、私有云)上，每个租户可以拥有其独立的空间和/或资源。例如，不同医疗机构(如医疗机构1和医疗机构2)对应的营运平台之间是独立和相互隔离的。

在一些实施例中，应用开发层340可以为租户提供开放服务。开放服务可以包括资源的访问服务等。资源可以包括但不限于应用开发层提供的开发资源、其他租户的资源和数据(如其他租户的工作空间、运营平台的数据)等。在一些实施例中，租户可以对自己的资源和/数据进行权限设置，例如，选择部分资源共享或开放给其他租户。当应用开发层340为租户提供开放服务时，需要考虑其他租户的权限信息。

本说明书一些实施例中，通过多租户架构来构建的应用开发层340，使得每个租户能够操作逻辑上互相独立的数据集，并确保这些数据集彼此之间不会相互干扰。通过引入多租户架构、服务器、存储设备和网络资源等基础设备在多个租户之间实现资源共享，每个租户可以自定义配置、接口和功能，以满足各自的特定需求，而不会影响其他租户。

本说明书一些实施例还提供一种医院支撑平台，包括：硬件设备，被配置为采集与医院业务有关的数据；软硬件接口，被配置为从硬件设备获取数据，并将其发送至数据中心进行存储；处理设备，配置有用于数据处理的数据处理单元；用户空间应用，被配置为供医院业务的相关用户获取与医院业务有关的用户服务，其中，用户服务由处理设备通过对存储在数据中心的至少一部分数据进行处理而实现。可选的，医院支撑平台还可以包括开放接口，被配置为供开发者调用至少一部分数据处理单元，并利用至少一部分数据处理单元进行应用开发。

本说明书另一些实施例还提供一种医院支撑平台，包括：硬件设备，被配置为采集与医院业务有关的数据；软硬件接口，被配置为从硬件设备获取数据，并将其发送至数据中心进行存储；处理设备，配置有用于数据处理的数据处理单元；开放接口，被配置为供开发者调用至少一部分所述数据处理单元，并利用至少一部分数据处理单元进行应用开发。可选地，医院支撑平台还可以包括用户空间应用，被配置为供医院业务的相关用户获取与医院业务有关的用户服务，其中，用户服务由处理设备通过对存储在数据中心的至少一部分数据进行处理而实现。

本说明书另一些实施例还提供一种医院支撑平台，包括硬件设备，被配置为采集与医院业务有关的数据；数据湖，被配置为以防篡改的方式对数据进行持久化存储；处理设备，配置有用于数据处理的数据处理单元，数据处理单元包括扩展现实(XR)单元、人工智能(AI)单元、数字孪生体单元和数据流通单元；用户空间应用，被配置为供医院业务的相关用户获取与医院业务有关的用户服务，其中，用户服务由处理设备通过对存储在数据中心的至少一部分数据进行处理而实现。在一些实施例中，对至少一部分数据进行处理包括利用至少一部分的数据孪生单元、AI单元和XR单元将所述至少一部分数据映射至虚拟医院；用户空间应用进一步被配置为供相关用户与虚拟医院进行交互，以使得相关用户获得至少一部分用户服务。例如，数字孪生单元可以基于所述至少一部分数据对虚拟医院中的数字孪生体进行更新；AI单元可以基于所述至少一部分数据对虚拟医院中的智能体进行更新；XR单元可以基于至少一部分数据对虚拟医院对应的图像数据进行更新、渲染。在一些实施例中，在用户与虚拟医院进行交互时，XR单元被配置为利用XR技术将虚拟医院的至少一部分呈现给相关用户(如基于MR技术叠加在相关用户的真实世界视野上)。关于虚拟医院的更多内容可以参考图1的相关描述。

图9A是示意图根据本说明书的一些实施例所示的提供预问诊服务的示例性流程的示意图。预问诊服务可用于在患者进入诊室进行正式问诊之前，通过对患者进行初步询问来收集有关患者的信息。具体来说，在患者候诊时，处理设备210可以通过患者的患者终端设备或配置在候诊区域的候诊终端对患者进行预问诊，以缓解患者在候诊时的焦虑情绪，并生成预问诊记录模板，以及将记录模板提供给医生参考，从而提高医生的问诊效率。在一些实施例中，流程900A的至少一部分由配置在处理设备210上与预问诊服务相对应的预问诊智能体执行。

步骤910，基于医生(例如，患者的挂号医生)的科室确定预问诊询问的询问内容。

预问诊询问用于在正式问诊前对患者进行初步询问。预问诊询问可以包括多轮询问。询问内容可以包括每轮询问的询问内容。或者，询问内容仅包括首轮查询的查询内容。在一些实施例中，处理设备210可以获取与医生的科室相对应的预问诊记录模板，并根据预问诊记录模板确定询问内容。

在一些实施例中，处理设备210可以获得关于患者的已知信息(例如，电子病历、主诉等)，通过比对预问诊记录模板与已知信息来确定预问诊记录模板中还未采集的遗漏信息。此外，处理设备210可以基于遗漏信息确定询问内容。

在一些实施例中，处理设备210可以使用询问模型基于医生的科室和患者的已知信息确定询问内容。询问模型可以包括CNN模型、RNN模型、LSTM模型、BERT模型、ChatGPT模型等。在一些实施例中，询问模型可以包括遗漏信息确定模型和第一询问内容确定模型。遗漏信息确定模型被配置为通过处理医生的科室和患者的已知信息来输出遗漏信息。第一询问内容确定模型被配置为基于患者的遗漏信息输出询问内容。

步骤920，基于询问内容，控制患者终端对患者进行预问诊询问。

在一些实施例中，在患者向医生挂号后，处理设备210可以确定患者接受医疗问诊服务的预估等待时间。例如，预估等待时间可以是当前时刻与患者的挂号时间的时间差。又例如，预估等待时间可以基于医生的当日问诊记录和患者的挂号记录确定。医生的当日问诊记录是反映医生当日门诊情况的记录。

在一些实施例中，响应于确定预估等待时间大于第一预设时间阈值，处理设备210可以使患者的患者终端对患者发起预问诊询问或展示进行预问诊的建议。这种方式可以保证有充足的时间进行预问诊，避免医生在预问诊的过程中打电话给患者。

在一些实施例中，响应于确定预估等待时间小于第二预设时间阈值，处理设备210可以使患者的患者终端对患者发起预问诊询问或者展示进行预问诊询问的建议。第二预设时间阈值可以大于第一预设时间阈值。例如，当检测到当前时刻距离挂号时间段短于24小时(即预估等待时间小于24小时)时，患者终端可以向患者展示进行预问诊询问的建议(例如，通过虚拟人物来向患者提出建议)，从而及时提醒患者进行预问诊询问。

在一些实施例中，处理设备210可以检测到患者通过患者终端发起预问诊询问请求，然后使患者的患者终端对患者进行预问诊询问。

在一些实施例中，患者终端可以呈现虚拟人物，以基于询问内容进行预问诊询问。虚拟人物是指具有特定特征(例如，特定的外观特征、声音特征等)的数字化人物，并且可以与患者进行交流以对患者进行预问诊。具体地，处理设备210可以通过患者终端(例如，XR设备)的屏幕展示虚拟人物，并通过患者终端的声音输出设备播放询问内容。同时，虚拟人物可以模拟人类的语言表达、手势等，为患者提供逼真的交流体验。在一些实施例中，虚拟人物可以是预问诊智能体的可视化表征。

在一些实施例中，虚拟人物可以具有预设的外形特征。在一些实施例中，虚拟人物的外形特征可以基于患者挂号的医生的光学图像数据来确定。在一些实施例中，虚拟人物可以根据患者的基本信息确定虚拟人物的外形特征。在一些实施例中，处理设备210可以基于医生的外形特征和/或患者的基本信息，从虚拟人物库中选择合适的虚拟人物作为虚拟人物。

在一些实施例中，预问诊询问可包括多轮询问。预问诊内容可以包括预问诊询问中每轮询问的询问内容，预问诊询问可以通过图9B中所示的流程900B执行。

如图9B所示，对于首轮查询，处理设备210可以使患者终端基于对应的询问内容进行首轮查询。

对于除首轮询问外的每个当前轮次的询问(简称为当前询问)，处理设备210可以基于当前询问之前采集的参考数据，对当前询问的询问内容(简称为当前询问内容)进行调整，以使询问内容更加符合患者的病情状况。具体来说，处理设备210可以基于当前询问之前采集的参考数据，确定患者的历史回答的语义信息和情感信息。参考数据可以包括患者终端采集的语音信号、图像数据、文本数据等。历史回答是患者对历史轮次的询问内容的回答。

历史回答的语义信息表征历史回答的内容。历史回答的情绪信息可以表明患者在提供历史回答时的情绪(例如，平静、紧张、焦虑、害怕、怀疑、烦躁等)。处理设备210可以通过对参考数据执行文本转录、语音内容识别等以确定语义信息。处理设备210可以通过分析参考数据的内容、音调、语调、语速等特征来确定情感信息。

继续参考图9B，处理设备210可以基于语义信息和情感信息调整当前询问内容。例如，当患者的情绪信息是“紧张”或“害怕”时，处理设备210可以在当前询问内容中增加安抚话语。又如，当语义信息表明患者未明确回答历史询问时，处理设备210可以调整当前询问内容以重复历史询问，从而引导患者明确回答历史询问。原本确定的当前询问内容可以作为下一轮次询问的询问内容。这样可以根据患者的病情及时调整当前的问诊内容，从而提高预问诊的服务质量。

在一些实施例中，除了调整当前询问内容外，还可以基于患者的状态对询问所用的声音特征进行实时调整。声音特征包括语音速率特征、语气特征、语调特征、音量特征等。如图9B所示，处理设备210可以根据患者历史回答的语义信息和情感信息确定当前询问的声音特征，并使患者终端根据调整后的询问内容和当前询问的声音调整进行当前询问。这种方法可以更好地照顾到患者的情绪变化，从而增强虚拟人物的拟人化效果，提高预问诊服务的质量。

在一些实施例中，如图9B所示，处理设备210可以进一步获取患者的生理状态信息。患者的生理状态信息可以反映患者的实时生理状态。生理状态信息可以包括患者的生理参数值(例如，心率、脉搏率、呼吸率等)。生理状态信息还可包括与患者的姿势、肢体行为、面部表情、肌肉状态等有关的信息。在一些实施例中，患者的生理状态信息可以通过患者穿戴的可穿戴设备、患者环境中的图像传感器获得。

此外，处理设备210可以基于语义信息、情感信息和生理状态信息调整当前询问内容。具体地，处理设备210可以根据患者的生理状态信息更新患者的情绪信息。可以理解的，患者的内心情绪可能并不总是通过患者的回答得到充分的表达，因此患者的情绪信息可以会根据患者的生理状态信息进行更新或修改。此外，处理设备210可以根据语义信息和更新的情感信息调整当前的询问内容。

在本说明书的一些实施例中，通过进一步考虑患者的生理状态数据，可以提高患者情绪信息的准确性，从而提高当前问询内容调整的准确性，进而提高预问诊服务的服务质量。

如图9B所示，在一些实施例中，处理设备210可以根据语义信息、情感信息和生理状态信息的至少一部分确定反馈参数，并控制可穿戴设备根据反馈参数向患者施加反馈。反馈可以包括力反馈或温度反馈中的至少一种。反馈参数可用于控制施加反馈的方式，例如，反馈类型、施加反馈的身体部位、反馈的强度等。在一些实施例中，处理设备210可以根据语义信息、情绪信息和生理状态信息的至少一部分确定患者的情绪和情绪等级，并根据情绪和情绪等级确定反馈参数。这种方法可以及时安抚患者的不良情绪，从而提高预问诊服务的质量。

在一些实施例中，处理设备210可以根据预设条件结束预问诊询问。预设条件可以是剩余的遗漏信息的数量为0。预设条件也可以是患者的当前时间和预估等待时间之间的时间差小于阈值。

在一些实施例中，步骤910中确定的询问内容可以仅包括首轮询问的询问内容。除首轮询问中的每个当前询问的当前询问内容可以在预问诊询问的进行过程中被确定。例如，在当前询问中，处理设备210可以将历史询问的询问内容、患者的历史回答、患者的已知信息等输入到第二询问内容确定模型，由第二询问内容确定模型输出当前询问内容。

步骤930，基于患者终端在预问诊询问中采集的参考数据生成预问诊记录。

参考数据可以包括患者在进行预问诊询问中通过患者终端输入的语音数据、文本数据和图像数据等。预问诊记录可用于记录在预问诊询问中采集的患者信息。可选地，患者的一些已知信息也可以记录在预问诊记录中。在一些实施例中，预问诊记录按照预问诊记录模板生成。预问诊记录模板可以是与医生所在科室对应的模板，也可以是医生设置的模板。

例如，当参考数据包括语音信号时，处理设备210可以首先将语音信号转录为文本，并通过关键字提取算法从文本中提取关键字。此外，处理设备210可将关键字转换为医学术语。此外，处理设备210可以获取预问诊记录模板中的多个模板字段，从医学术语中检索与各个模板字段对应的内容并填写到预问诊记录模板的相应位置。关键字的转化可以基于术语转换模型执行，也可以基于知识字典进行。术语转换模型可配置为将口语描述转换为医学术语。

在一些实施例中，预问诊询问可以通过患者终端以外的终端设备(例如，候诊终端)执行。

图10是根据本说明书的一些实施例所示的用于基于感知信息提供医疗门诊服务的示例性流程的示意图。示意图医疗问诊服务。在一些实施例中，流程1000可以包括子流程1010、1020、1030和1040中的一个或多个。在一些实施例中，流程1000的至少一部分由处理设备210上配置的对应于医疗问诊服务的问诊智能体执行。

在问诊环节，患者可与挂号医生进行交流，以接受问诊服务(例如，在诊室内的现场问诊服务、远程问诊服务)。在一些实施例中，可以通过至少一个终端设备向相关用户(如，医生、患者、远程陪伴者)提供与问诊环节的相关用户服务。至少一个终端设备包括诊室中的公共终端设备、患者终端设备、医生终端设备、远程陪诊者的终端设备等。诊室中的公共终端设备是指安装在诊室现场的终端设备，其可以包括显示设备、声音输出设备、声音传感器、XR设备、可穿戴设备等或其任意组合。感知信息可以由患者、医生、远程陪诊者所在的环境中的感知设备在问诊过程中采集。感知设备可以是独立的设备，也可以是至少一个终端设备的一部分。

子流程1010可用于基于感知信息提供看诊建议。子流程1010可以在问诊环节中执行。如图10所示，子流程1010可以包括步骤1012和步骤1014。

步骤1012，基于感知信息和患者的患者数据生成看诊建议。看诊建议是指协助医生提供医疗问诊服务的建议。示例性的，看诊建议可以包括补充询问建议、查体建议、处方建议、治疗方案建议等。

在一些实施例中，看诊建议可以基于与挂号科室相对应的知识数据库、看诊规范等来确定。例如，处理设备210可以基于声音传感器采集的语音信号确定医生和患者之间的对话内容，并基于该对话内容和/或患者数据在知识数据库、看诊规范等中进行检索，以确定看诊建议。仅作为示例，可以基于对话内容和/或患者数据在问诊规范中进行检索，以确定看诊规范中哪些信息尚未采集，并基于这些信息提供补充询问建议。

在一些实施例中，看诊建议可以基于诊断模型生成。具体地，处理设备210可以根据感知到的感知信息和患者数据确定模型输入，将模型输入输入到诊断模型，诊断模型可以输出与对应的看诊建议。例如，模型输入可以包括患者数据、基于语音信号确定的对话内容、基于图像数据确定的患者的状态信息等，或其任意组合。

在一些实施例中，看诊建议可以由问诊智能体生成。问诊智能体可从各种数据(例如，历史问诊记录、知识数据库和看诊规范)中学习生成看诊建议的生成机制，并根据该机制对感知信息和患者数据进行处理，从而提供看诊建议。

步骤1014，控制至少一个终端设备的至少一部分以呈现看诊建议。

例如，当患者在诊室接受现场医疗门诊服务时，处理设备210可以控制公共终端设备或医生终端来呈现看诊建议。又如，当患者接受远程医疗门诊服务时，处理设备210可以控制医生的医生终端和患者的患者终端分别呈现看诊建议。看诊建议可以提高诊断和处方的准确性，并提高医疗问诊服务的效率。

子流程1020可用于基于感知信息生成目标诊断记录。子流程1020可在问诊环节结束时执行。如图10所示，子流程1020可以包括步骤1022、1024和1026。

步骤1022，基于感知信息生成初始诊断记录。

初始诊断记录可以是自动生成的诊断记录。在一些实施例中，初始诊断记录可以包括初始患者病历、初始诊断意见、初始诊断处方(例如，初始治疗处方和初始检查处方)、初始医嘱等。在一些实施例中，可以基于诊断记录模板从感知信息中提取关键内容。关键内容是指与诊断记录模板中的模板字段有关的内容。可以根据知识字典或术语转换模型将关键内容转换为专业内容。进一步的，可以基于专业内容和知识数据库更新诊断记录模板，生成初始诊断记录。知识数据库是指挂号科室的知识数据库，例如，包括科室的看诊规范(例如，疾病描述规范、诊断规范、处方规范、医嘱规范等)。

在一些实施例中，可以获取由一个或多个检查设备在门诊流程中采集的患者的体检数据，并且可以根据体检数据进一步生成初始诊断记录。在一些实施例中，初始诊断记录可以由问诊智能体生成。问诊智能体可以从各种数据(例如，诊断记录模板、知识字典、知识数据库等)中学习生成诊断记录的机制，并根据学习的机制对感知信息和患者数据进行处理，生成诊断记录。

步骤1024，将初始诊断记录呈现给医生。

例如，当患者开始问诊时，处理设备210可以控制公共终端以呈现初始诊断记录。作为另一示例，处理设备210可以控制医生终端向医生呈现初始诊断记录。在一些实施例中，医生终端可以在预设时间(例如，在医生结束当天的问诊工作后)向医生呈现初始诊断记录。

步骤1026，基于初始诊断记录和医生输入的对初始诊断记录的反馈信息生成目标诊断记录。

医生输入的反馈信息可包括医生对初始诊断记录的修改和/或确认。目标诊断记录是指由医生修改和/或确认的诊断记录。在一些实施例中，目标诊断记录可以包括目标患者病历、目标诊断意见、目标诊断处方(例如，目标治疗处方和目标检查处方)、目标医嘱等。

通过生成目标诊断记录，一方面，可以减少目标诊断记录的人工书写错误，提高生成目标诊断记录的效率。另一方面，可以减少医生的文书工作，使得医生有更多精力给予患者关怀，从而提高医疗门诊服务的质量。

子流程1030可用于基于感知信息提供远程陪诊服务。患者可在问诊前发起远程陪诊服务的请求。子流程1030可以在问诊环节中执行。如图10所示，子流程1030可以包括步骤1032和步骤1034。

步骤1032，基于感知信息，确定患者是否需要与远程陪诊者交流。

在一些实施例中，处理设备210可以基于感知信息(例如，语音数据和/或图像数据)检测患者是否发出了与远程陪诊者交流的请求。在一些实施例中，处理设备210可以根据感知信息确定患者的状态信息，并根据患者的状态信息确定患者是否需要与远程陪诊者进行交流。例如，当状态信息提示患者处于高度紧张、恐惧等状态时，处理设备210可以确定患者需要与远程陪诊者进行交流。

当确定患者需要与远程陪诊者进行交流时，处理设备210可以执行步骤1034。

步骤1034，控制至少一个终端设备的至少一部分以放大界面元素。

当患者在诊室接受现场医疗问诊服务时，处理设备210可以控制公共终端设备放大界面元素。当患者接受远程医疗问诊服务时，处理设备210可以控制患者的患者终端放大界面元素。通过放大的界面元素，患者可以查看远程陪诊者的实时画面，并更好地与远程陪诊者进行交流。

在一些实施例中，当患者在诊室中接受现场医疗问诊服务时，当检测到患者需要与远程陪诊者进行通信时，处理设备210可以提醒患者佩戴XR设备，并控制XR设备呈现远程陪诊者的图像数据。

在本说明书的一些实施例中，可以基于感知信息检测患者的沟通需求，并可及时满足沟通需求，从而为患者提供更加人性化的护理，并提供更加真实、身临其境的陪伴体验。

子流程1040可用于基于感知信息向目标用户呈现医疗数据。如图10所示，子流程1040可包括步骤1042和步骤1044。

步骤1042，基于感知信息，获取至少一个目标用户发出的控制指令，用于检索至少一部分医疗数据。

目标用户可以至少包括患者和医生。在一些实施例中，目标用户还可以包括患者的远程陪诊者。患者的医疗数据可以包括反映患者健康状况的各种数据(例如，电子病历、医学图像、医学体检结果等)。

控制指令是指用于调取医疗数据(例如，电子病历)中的至少一部分进行显示的指令。例如，控制指令可以用于调取电子病历中患者感兴趣器官的三维模型以进行显示。在一些实施例中，控制指令可用于设置显示参数(如显示角度、显示尺寸或显示位置)。在一些实施例中，控制指令还可以用于在医疗数据(例如，感兴趣器官的三维模型)上标注关键数据。

在一些实施例中，感知信息可以包括由声音传感器采集的语音信号，并且可以通过对语音信号执行语义分析来获取控制指令。在一些实施例中，目标用户可以通过说出预设的唤醒词发出控制指令。在一些实施例中，感知信息可以包括由图像传感器采集的目标用户(例如，患者和/或医生)的光学图像数据，并且可以通过在光学图像数据中对目标用户进行手势识别来获取控制指令。在一些实施例中，目标用户可以使用控制设备(例如，遥控器、智能控制手套等)发出控制指令。

在本说明书的一些实施例中，目标用户可以灵活地调整显示内容和/或显示参数，例如，通过语音、手势等，从而优化用户体验，提高医疗问诊服务的效率。

步骤1044，响应于控制指令，调取医疗数据的至少一部分并通过至少一个终端设备呈现医疗数据的至少一部分。

例如，处理设备210可以从存储设备中调取医疗数据的至少一部分，并控制至少一个终端设备来呈现医疗数据的至少一部分。当控制指令包括显示参数时，处理设备210可以控制至少一个终端设备基于该显示参数来呈现医疗数据的至少一部分。

在本说明书的一些实施例中，多个目标用户可以通过至少一个终端设备共同浏览医疗数据，并且可以同步更改不同终端设备上医疗数据的呈现内容和呈现方式，这有助于提高目标用户的沟通效率，增强就诊过程的交互性。

图11是根据本说明书的一些实施例所示的向入院办理环节的相关用户提供服务的示例性流程的示意图。在入院办理环节，患者可以办理相关手续以入院。在一些实施例中，流程1100的至少一部分由与配置在处理设备210上的住院服务相对应的住院智能体执行。在一些实施例中，流程1100的至少一部分(例如，步骤1130-步骤1150)由配置在处理设备210上的护理服务对应的护理智能体执行。

步骤1110，处理设备210可以将患者引导至病房。

例如，处理设备210可指示患者的患者终端将患者引导至病房。例如，响应住院引导请求，处理设备210可以获取患者的患者终端的第一位置和病房的第二位置，并基于医院的实时地图确定从第一位置到第二位置的计划路线。然后，处理设备210可以指示患者终端设备向患者呈现与计划路线相关的引导信息。

步骤1120，向患者提供入院宣教信息。

入院宣教信息可以用于向患者介绍入院信息(例如，入院手续、入院操作、入院前费用、支付方式等)、入院住院规则、医院环境、患者的医生和/或护士等。在一些实施例中，处理设备210可以使患者终端设备(例如，XR设备260-2)呈现提供入院宣教信息的虚拟人物。

在1130中，处理设备210可以协助护士进行入院准备。

入院准备可由护士执行，为患者准备医院用品。在一些实施例中，处理设备210可以通过护士工作站或智能护理推车240-4中的护士终端1105呈现患者的入院通知，以便协助护士执行入院准备。入院通知可以包括患者的患者数据、患者的医院用品清单、患者的病房信息、患者的初始检查信息等。

入院检查也可称为住院患者检查，其可以在患者被送进病房后进行。入院检查可用于采集患者当前医疗状况的相关信息(例如，生命体征、基本健康数据等)。初始检查可包括血压、血糖、心率、体温或类似项目的检查，或其任意组合。

步骤1140，处理设备210可以发出执行入院检查的提醒。提醒可以包括消息提醒、声音提醒、弹出提醒等。例如，处理设备210可以指示护士终端1105或智能护理推车240-4呈现提醒。

在一些实施例中，处理设备210可以基于病房中的感知设备采集的感知信息，确定患者是否满足在病房中进行入院检查的条件。在病房进行入院检查的条件可以包括患者已抵达病房一段时间。如果患者满足条件，则处理设备210可以发出进行入院检查的提醒。

步骤1150，处理设备210可以将护士引导到病房。在一些实施例中，处理设备210可以控制智能护理推车240-4的移动，以引导护士进入病房。

步骤1160，对患者进行入院检查。

例如，在护士到达病房后，可以使用一个或多个检查设备对患者进行入院检查以采集患者的查体数据。在一些实施例中，在智能护理推车到达病房后，处理设备210可以指示智能护理推车在入院检查期间向护士呈现与入院检查相关的信息。例如，智能护理推车可以呈现入院检查图示、患者的电子病历等。

步骤1170，处理设备210生成入院记录。

入院记录是指显示患者已入住病房和/或患者入住病房时的状态的记录。入院记录可以包括入院信息(例如，入院号、临床信息、入院时间、预收住院费金额、支付方式等)、入院检查时采集的体检数据等。

在一些实施例中，处理设备210可以基于入院记录模版和体检数据生成入院记录。在一些实施例中，处理设备210可以基于患者的电子病历进一步生成入院记录。在一些实施例中，处理设备210可以基于智能护理推车240-4或护士终端1105向护士呈现入院记录，并基于入院记录和根据护士通过智能护理推车240-4或护士终端1105输入的入院记录的反馈信息，来生成目标入院记录。反馈信息可以包括由护士输入的确认指令、修改指令等。

在本说明书的一些实施例中，可以在医疗服务系统(例如，智能护理推车240-4)和/或智能体的协助下，以半自动化的方式为患者提供入院服务，从而可以降低人工成本并提高入院服务的效率。

图12是根据本说明书的一些实施例所示的用于提供护理服务的流程的示意图。在一些实施例中，可以在患者住院期间每天执行流程1200，以便为患者提供护理服务。在一些实施例中，流程1200的至少一部分可以由配置在处理设备210上的住院服务对应的住院智能体执行。在一些实施例中，流程1200的至少一部分可以由配置在处理设备210上的护理服务对应的护理智能体执行。

步骤1202，处理设备210根据患者的患者数据和医生对患者的医嘱，确定患者的每日计划。

医生对患者的医嘱是指医生给患者的指示或指令。在一些实施例中，患者的医嘱可以存储在存储设备中，并且在任何医生为患者下达了新的医嘱时，可以对其进行更新。处理设备210可以从存储设备中获取最新版本的医嘱。在一些实施例中，处理设备210可以监控各种硬件设备以检测患者的医嘱是否被更新。例如，当向患者提供入院查询服务和/或查房服务时，患者的医生可以向患者下达新的医嘱。处理设备210可根据入院询问服务和/或查房服务期间基于感知设备采集的感知信息来检测新医嘱。一旦检测到新医嘱，就可以将新的医嘱存储在存储设备中。作为另一示例，医生可以通过医生终端更新存储设备中的医嘱。在一些实施例中，处理设备210可以基于患者的电子病历确定医生的医嘱。

在一些实施例中，处理设备210可以根据患者的患者数据和患者的医嘱，来确定患者的每日计划。每日计划可以包括当天需要对患者进行的至少一次医疗操作。示例性的，医疗操作可包括护理操作、检查操作等。

步骤1204，处理设备210可以通过病房内的公共终端设备(例如，床边终端240-6)向患者呈现每日计划。

步骤1206，处理设备210可以通过护士终端(例如，护士工作站中的终端设备等)向与患者对应的护士呈现每日计划。

步骤1208，当每日计划包括至少一次护理操作时，护士可对患者实施至少一次护理操作，处理设备210可以根据每日计划协助护士实施至少一次护理操作。

如图12所示，对于至少一种护理操作中的每一个，处理设备210可以控制智能护理推车，根据护理操作的计划时间，引导护士前往病房进行护理操作。例如，在护理操作的计划时间之前，可以控制智能护理推车移动到护士的工作站，以通知护士需要为患者执行护理操作。然后，可以控制智能护理推车移动并引导护士前往患者的病房。处理设备210可以进一步控制智能护理推车，使其在护士到达病房后呈现有关护理操作的护理说明。

步骤1210，处理设备210可以生成护理记录。

护理记录是指在护理操作之前、之后或进行时应用于患者和/或患者状态(例如，生命体征和其他生理测量)的护理操作记录。在一些实施例中，处理设备210可以在执行至少一种护理操作时，获取由病房中的一个或多个感知设备采集的感知信息，并基于该感知信息生成护理记录。在一些实施例中，护理记录可以通过智能护理推车或护士终端设备显示给护士进行确认。

在本说明书的一些实施例中，每日计划和护理记录的自动生成可以显著减轻护士的工作量。这种自动化使护士能够更多地专注于直接护理患者，而不是行政任务上。此外，对医嘱更新的监控确保了每日计划的及时更新。这种积极主动的方法可确保根据最新医嘱及时调整干预措施和护理计划，从而提高护理效果和护理质量。

图13是根据本说明书的一些实施例所示的术前引导流程的示例性示意图。在一些实施例中，流程1300的至少一部分可以由配置在处理设备210上的手术服务对应的手术智能体执行。

术前指导可包括患者护送、患者确认、术前教育、术前清洁、静脉通路建立等。患者护送是指将患者从他/她目前的位置运送到手术室的等候区。

患者验证是指验证患者是否符合手术标准。例如，患者验证可包括：验证验证对象的身份信息是否与执行当前手术过程的目标患者匹配；验证验证对象的手术流程当前是否安排；验证验证对象的当前身体状况是否符合手术流程的要求。可以理解的是，如果验证对象不符合任何一项手术标准，则患者的手术流程可能会被推迟或延迟。

在一些实施例中，处理设备210可以通过等待区中的一个或多个感知设备采集患者的生物信息，并基于该生物信息验证患者的身份。例如，如图13所示，在患者被运送到等候区1310后，处理设备210可以通过等候区1310中的一个或多个感知设备1311(例如，图像采集设备、麦克风、指纹传感器等)采集患者261的生物信息，并基于该生物信息验证患者261的身份。在一些实施例中，处理设备210可以利用护士智能体来验证患者的身份。例如，护士智能体可以验证采集到的生物信息，或者通过与患者的语音交互(例如，询问患者的年龄、姓名、性别等)来验证患者的身份。

术前护理可以包括术前安抚和术前教育。术前安抚是指术前准备工作，通过语言交流、视频、音乐等方式帮助患者减轻负面情绪(例如，焦虑、紧张、恐惧等)。术前教育是指术前准备，帮助患者了解手术过程。术前清洁是指术前的准备工作，如身体清洁、脱毛(例如，头发、体毛等)、患者穿上手术服等。静脉通路的建立是指在患者身上建立静脉通路进行药物注射，以保证在手术过程中药物能够有效地给到患者体内。

在一些实施例中，处理设备210可以确定从患者的当前位置到等候区的规划路径，并控制智能轮椅沿规划路径将患者运送到等候区。例如，如图13所示，在根据手术计划对患者执行术前操作之前，处理设备210可以确定从患者261的当前位置(例如，病房1303)到等待区1310的规划路径。处理设备210可以控制智能轮椅240-5沿规划路径将患者261从病房1303运送到等候区1310。

在一些实施例中，处理设备210可以基于医院地图确定从当前位置到等待区的规划路径。在一些实施例中，处理设备210可以配置护士智能体，该护士智能体代替护士执行某些任务，并可呈现虚拟护士角色。处理设备210可以使用护士智能体来控制智能轮椅，以将患者从当前位置运送到等候区。在一些实施例中，在将患者运送到等候区后，处理设备210可以执行患者验证。

在一些实施例中，处理设备210可以根据患者数据和手术计划确定患者的术前护理材料。在将患者运送到等待区的过程中，处理设备210可以使用患者终端，根据术前护理材料向患者进行术前教育。术前护理材料可以包括视频、音乐、图像、文本和其他手术解释和/或情绪放松等相关的材料。

在一些实施例中，处理设备210可以使用护士智能体向患者提供术前教育。例如，如图13所示，处理设备210可以在患者261佩戴的XR设备260-2上呈现虚拟护士角色1323，虚拟护士角色1323向患者261讲解术前护理材料。在一些实施例中，虚拟护士角色1323可以与患者261进行语音交互，以减轻患者的负面情绪或通过交流回答患者的问题。在一些实施例中，处理设备210可以通过采集患者的面部表情、生理体征、语调等来确定是否有必要缓解患者的情绪。

在一些实施例中，处理设备210可以使用护士智能体来指导护士执行术前清洁和/或建立静脉通道。

在一些实施例中，在将患者运送到等候区的过程中，处理设备210可以通过医院中的一个或多个感知设备(如图像传感器1313)获取与从智能轮椅的当前位置到等候区的规划路径的一部分(例如，智能轮椅尚未行进的规划路径的一部分)相关的感知信息。基于感知信息，处理设备210可以确定规划路径中的未行进部分中的潜在风险，并基于潜在风险更新未行进部分。

在本说明书的一些实施例中，通过上述术前引导流程，可以提供人性化、透明化、高效率的术前准备流程，并可以根据患者反馈动态调整术前准备项目，提高术前准备效率。通过上述运送患者和验证患者身份的流程，避免了人为失误，提高了整个手术过程的安全性。利用虚拟护士图像协助完成许多术前准备工作，可以节省人工成本。

图14是根据本说明书的一些实施例所示的手术执行流程的示意图。手术执行流程1400可以包括术前准备、术中事项和术后事项。在一些实施例中，流程1400的至少一部分可以由配置在处理设备210上的手术服务对应的手术智能体执行。如图14所示，术前准备(例如，手术执行前的步骤)可包括步骤1411、步骤1413和步骤1415。

步骤1411，激活手术室。

激活手术室可包括打开手术室门、激活手术室内的手术设备、监控设备、调整手术室内的参数、验证手术设备的状态等。在一些实施例中，处理设备210可以控制智能机器人护士激活手术室或引导护士激活手术室。例如，处理设备210可以控制智能机器人护士在手术的预定时间自动启动手术室设备，并调节室内温度、湿度和空气质量。

步骤1413，准备手术工具。

手术工具可以包括手术器械和手术耗材。在一些实施例中，处理设备210可以根据手术计划控制智能机器人护士在手术前在手术室中准备手术工具。在一些实施例中，处理设备210可进一步控制智能机器人护士对手术台进行消毒并布置手术台(例如，在手术台上布置各种手术工具的位置)。

步骤1415，患者确认和/或患者麻醉。患者确认是指确认患者的身份。患者麻醉是指对患者实施麻醉。

步骤1420，执行手术过程。在一些实施例中，如图14所示，手术过程中的事项(例如，术中事项)可包括远程协作、工具转移、图像交互、术中规划和导航以及实时警报。

远程协作是指手术过程中的远程参与和/或远程指导。

工具交付是指在手术过程中将手术工具交付给手术执行者。在一些实施例中，处理设备210可以根据手术期间手术室中的一个或多个第一感知设备采集的第一感知信息，识别由手术参与者发出的用于目标手术工具的指令。基于这些指令，处理设备210可以控制智能机器人护士将目标手术工具交付给手术参与者。

图像交互是指通过手术室内的交互设备(例如，手术室内的显示屏、医生终端设备270)向手术参与者(例如，本地手术参与者、远程手术参与者)和/或患者显示患者的数字人体模型(例如，手术部位的三维解剖模型)、患者的电子病历、当前手术的手术计划、患者手术部位的实时图像等。

术中规划导航是指在手术过程中，将患者的病变图像(例如，病变的CT扫描图像)与患者的数字人体模型融合，将病变图像投影到患者的身体上，或叠加手术工具的定位和跟踪，以指导手术参与者进行手术。

实时警报可包括手术参与者的行为警报、患者生命体征警报和设备运行状态警报等。行为警报是指手术参与者术中操作行为的监视和警报。当患者的生命体征(例如，心电图、血压等)出现异常时，可启动患者生命体征警报。设备运行状态警报是指当手术设备出现异常运行状态时发出的警报。

如图14所示，手术执行后的流程(例如，手术后事项)可包括步骤1431、1433和步骤1435。

步骤1431，转移患者。转移患者是指在手术流程完成后，将患者从手术室转移到康复区的过程。在一些实施例中，转移患者可以由医疗保健专业人员在智能机器人护士的协助下进行。

步骤1433，进行手术室清理。手术室清理是指对手术设备和工具进行清洁或消毒的过程。在一些实施例中，处理设备210可以控制智能机器人护士来执行手术室清理。

步骤1435，生成手术报告。

手术报告可以包括手术相关信息、患者相关记录、参与者相关记录等。在一些实施例中，处理设备210可以根据手术过程中采集的数据(例如，手术室中一个或多个感知设备采集的感知信息)生成初始手术报告。处理设备210可根据初始手术报告和医生就初始手术报告输入的反馈信息生成手术报告。

在一些实施例中，处理设备210还可以通过病房中的生命体征监测设备(例如，心电监护仪、血压计等)对患者的术后体征进行监测，以确定患者术后生命体征是否在正常范围内、是否存在异常、或恢复进度是否正常。此外，处理设备210可以根据患者的术后体征更新医疗建议报告。在一些实施例中，处理设备210可以根据医生的指示更新医疗建议报告。在一些实施例中，处理设备210可以将更新的医疗建议报告发送到护士工作站的显示设备和/或医生工作站的显示设备。

在一些实施例中，处理设备210可以根据更新的医疗建议报告确定术后护理计划。术后护理计划是指在患者术后住院期间需要由护理人员(例如，护士、护理助理等)执行的护理任务。在一些实施例中，处理设备210可以控制智能手术设备(例如，智能护理推车240-4)，以根据术后护理计划为患者提供护理。在一些实施例中，处理设备210可以将术后护理计划发送给护士，以便护士为患者提供术后护理。在一些实施例中，处理设备210可以在护理过程中根据患者的情况实时更新术后护理计划。术后护理计划的执行类似于与图12中所描述的每日计划。

在一些实施例中，处理设备210可以根据手术报告和医疗建议报告生成医生的手术结果和手术记录，以便医生查看手术过程。手术结果是指反映手术过程结果的数据。在一些实施例中，手术结果还包括医生在预定时间段(例如，一个月)内的手术结果汇总数据。手术记录是指医生在手术过程中的操作记录。操作记录可以包括动作记录、用力记录、站位记录等。在一些实施例中，处理设备210可以根据手术报告和医疗建议报告生成手术结果和手术记录。

在一些实施例中，对手术过程进行回顾。例如，处理设备210可以将医生的手术成果和操作记录呈现给医生，从而允许医生审查手术过程。

在一些实施例中，处理设备210(例如，配置在处理设备210上的智能体)可以调用数据处理层330中的数据处理单元进行数据处理，以便实现或支持如上所述的过程900A-1400中的至少部分操作。

应当注意的是，上述对相关流程的描述仅为举例和说明，并不限制本公开的适用范围。对于本领域技术人员，可以在本说明书的指导下对该过程进行各种修改和更改。

上文已对基本概念做了描述，显然，对于本领域技术人员来说，上述详细披露仅仅作为示例，而并不构成对本说明书的限定。虽然此处并没有明确说明，本领域技术人员可能会对本说明书进行各种修改、改进和修正。该类修改、改进和修正在本说明书中被建议，所以该类修改、改进、修正仍属于本说明书示范实施例的精神和范围。

同时，本说明书使用了特定词语来描述本说明书的实施例。如“一个实施例”、“一实施例”、和/或“一些实施例”意指与本说明书至少一个实施例相关的某一特征、结构或特点。因此，应强调并注意的是，本说明书中在不同位置两次或多次提及的“一实施例”或“一个实施例”或“一个替代性实施例”并不一定是指同一实施例。此外，本说明书的一个或多个实施例中的某些特征、结构或特点可以进行适当的组合。

此外，除非权利要求中明确说明，本说明书所述处理元素和序列的顺序、数字字母的使用、或其他名称的使用，并非用于限定本说明书流程和方法的顺序。尽管上述披露中通过各种示例讨论了一些目前认为有用的发明实施例，但应当理解的是，该类细节仅起到说明的目的，附加的权利要求并不仅限于披露的实施例，相反，权利要求旨在覆盖所有符合本说明书实施例实质和范围的修正和等价组合。例如，虽然以上所描述的系统组件可以通过硬件设备实现，但是也可以只通过软件的解决方案得以实现，如在现有的服务器或移动设备上安装所描述的系统。

同理，应当注意的是，为了简化本说明书披露的表述，从而帮助对一个或多个发明实施例的理解，前文对本说明书实施例的描述中，有时会将多种特征归并至一个实施例、附图或对其的描述中。但是，这种披露方法并不意味着本说明书对象所需要的特征比权利要求中提及的特征多。实际上，实施例的特征要少于上述披露的单个实施例的全部特征。

一些实施例中使用了描述成分、属性数量的数字，应当理解的是，此类用于实施例描述的数字，在一些示例中使用了修饰词“大约”、“近似”或“大体上”来修饰。除非另外说明，“大约”、“近似”或“大体上”表明所述数字允许有±20％的变化。相应地，在一些实施例中，说明书和权利要求中使用的数值参数均为近似值，该近似值根据个别实施例所需特点可以发生改变。在一些实施例中，数值参数应考虑规定的有效数位并采用一般位数保留的方法。尽管本说明书一些实施例中用于确认其范围广度的数值域和参数为近似值，在具体实施例中，此类数值的设定在可行范围内尽可能精确。

针对本说明书引用的每个专利、专利申请、专利申请公开物和其他材料，如文章、书籍、说明书、出版物、文档等，特此将其全部内容并入本说明书作为参考。与本说明书内容不一致或产生冲突的申请历史文件除外，对本说明书权利要求最广范围有限制的文件(当前或之后附加于本说明书中的)也除外。需要说明的是，如果本说明书附属材料中的描述、定义、和/或术语的使用与本说明书所述内容有不一致或冲突的地方，以本说明书的描述、定义和/或术语的使用为准。

最后，应当理解的是，本说明书中所述实施例仅用以说明本说明书实施例的原则。其他的变形也可能属于本说明书的范围。因此，作为示例而非限制，本说明书实施例的替代配置可视为与本说明书的教导一致。相应地，本说明书的实施例不仅限于本说明书明确介绍和描述的实施例。

Claims (23)

1.一种医院支撑平台，其特征在于，包括：

硬件设备，被配置为采集医院业务相关的数据；

数据中心，包括数据湖，所述数据湖被配置为以防篡改的方式对所述数据进行持久化存储；

处理设备，配置有用于数据处理的数据处理单元，所述数据处理单元包括扩展现实单元、人工智能单元、数字孪生体单元和数据流通单元；

用户空间应用，被配置为供医院业务的相关用户获取与所述医院业务有关的用户服务，其中，所述用户服务由所述处理设备利用至少一个所述数据处理单元对存储在所述数据中心的至少一部分所述数据进行处理而实现。

2.根据权利要求1所述的医院支撑平台，其特征在于，还包括：

软硬件接口，被配置为从所述硬件设备获取所述数据，并将所述数据发送至所述数据中心进行存储。

3.根据权利要求2所述的医院支撑平台，其特征在于，所述从所述硬件设备获取所述数据，并将所述数据发送至所述数据中心进行存储包括：

获取所述硬件设备的硬件配置信息，所述硬件配置信息包括身份唯一标识；

确定所述硬件配置信息是否满足预设条件；

响应于所述硬件配置信息满足所述预设条件，将所述数据发送至数据中心进行存储。

4.根据权利要求3所述的医院支撑平台，其特征在于，所述硬件配置信息还包括所述硬件设备的运行状态；

所述确定所述硬件配置信息是否满足预设条件包括：

基于所述身份唯一标识，确定所述硬件设备是否为多个可信任设备中的一个；和/或

基于所述硬件设备的运行状态，确定所述硬件设备是否为正常状态。

5.根据权利要求1所述的医院支撑平台，其特征在于，还包括：

开放接口，被配置为供应用开发者调用至少一部分所述数据处理单元，并利用所述至少一部分数据处理单元进行应用开发。

6.根据权利要求1所述的医院支撑平台，其特征在于，所述硬件设备包括物联网设备和扩展现实设备。

7.根据权利要求1所述的医院支撑平台，其特征在于，所述数据中心进一步包括数据仓，被配置为存储所述数据的索引。

8.根据权利要求1所述的医院支撑平台，其特征在于，所述处理设备进一步被配置为：

确定所述数据的评估信息；

基于所述评估信息，确定所述数据的存储策略；

基于所述存储策略，将所述数据存储至所述数据湖。

9.根据权利要求8所述的医院支撑平台，其特征在于，所述评估信息包括所述数据的安全等级、数据量大小和/或数据采集频率、重要性系数中的一种或多种的组合；所述基于所述评估信息，确定所述数据的存储策略包括：

响应于所述数据对应的所述安全等级高于预设安全阈值，确定所述数据的存储策略为对所述数据进行加密存储；和/或

响应于所述数据的数据量和/所述数据采集频率高于预设阈值，确定所述数据的存储策略为对所述数据进行分布式存储；和/或

基于所述数据的所述重要性系数，确定所述数据的存储期限。

10.根据权利要求1所述的医院支撑平台，其特征在于，

所述扩展现实单元被配置为利用扩展现实技术对所述数据进行处理，以实现扩展现实服务；

所述人工智能单元被配置为利用人工智能技术对所述数据进行处理，以实现人工智能服务；

所述数字孪生体单元被配置为利用数字孪生技术对所述数据进行处理，以实现数字孪生服务；

所述数据流通单元被配置为利用数据流通技术对所述数据进行处理，以实现数据流通服务。

11.根据权利要求10所述的医院支撑平台，其特征在于，至少一部分所述数字孪生体单元被配置为调用所述扩展现实单元和/或人工智能单元对所述数据进行处理，以实现所述数字孪生服务。

12.根据权利要求10所述的医院支撑平台，其特征在于，所述数据流通技术包括区块链技术和数据隐私计算技术。

13.根据权利要求1所述的医院支撑平台，其特征在于，

所述处理设备进一步被配置为利用所述扩展现实单元、人工智能单元、数字孪生体单元中的至少一部分将至少一部分所述数据映射至虚拟医院；

所述用户空间应用被配置为供所述相关用户与所述虚拟医院进行交互，以使得所述相关用户获得至少一部分所述用户服务。

14.根据权利要求13所述的医院支撑平台，其特征在于，所述处理设备进一步被配置为：

当所述相关用户与所述虚拟医院进行交互时，通过所述扩展现实单元利用扩展现实技术将所述虚拟医院的至少一部分呈现给所述相关用户。

15.根据权利要求1所述的医院支撑平台，其特征在于，

所述医院支撑平台中的数据交互满足预设数据隐私规则和数据安全规则。

16.根据权利要求1所述的医院支撑平台，其特征在于，所述人工智能单元包括智能体单元，所述智能体单元被配置为维护智能体，所述智能体基于AI技术和所述医院业务相关的数据实现自主学习和演化。

17.根据权利要求16所述的医院支撑平台，其特征在于，所述智能体包括预问诊服务对应的预问诊智能体，所述预问诊智能体被配置为：

基于患者挂号的医生所在的科室，通过所述患者的患者终端对所述患者进行预问诊询问；

基于所述患者终端在所述预问诊询问中采集的数据，生成所述预问诊记录。

18.根据权利要求17所述的医院支撑平台，其特征在于，所述预问诊询问基于询问内容进行且包括多轮询问，所述询问内容包括每轮询问的询问内容，所述向所述患者发起所述预问诊询问，包括：

对除第一轮询问外的每轮预问诊询问，

基于当前轮次询问之前采集的数据，确定所述患者的历史回答的语义信息和情绪信息；

基于所述语义信息和所述情绪信息，对当前轮次询问的询问内容进行调整；

基于调整后的当前轮次询问的询问内容，通过所述患者终端进行当前轮次询问。

19.根据权利要求17所述的医院支撑平台，其特征在于，所述预问诊包括多轮询问，所述对所述患者进行预问诊询问，包括：

对于除了首轮询问之外的每一当前轮次询问，

基于历史询问的询问内容、所述患者的历史回答和所述患者的已知信息，利用询问内容确定模型，确定当前轮次询问对应的询问内容，所述询问内容确定模型为训练好的机器学习模型；

基于所述当前轮次询问对应的询问内容，通过所述患者终端进行所述当前轮次询问。

20.根据权利要求16所述的医院支撑平台，其特征在于，所述智能体包括问诊服务对应的问诊智能体，所述问诊智能体被配置为：

在患者的问诊过程中，

基于感知设备在所述问诊过程中采集的感知信息，确定所述患者是否需要与远程陪诊者进行沟通；

响应于确定所述患者需要与所述远程陪诊者进行沟通，控制至少一个终端设备放大所述与远程陪诊服务有关的界面元素。

21.根据权利要求16所述的医院支撑平台，其特征在于，所述智能体包括住院服务对应的住院智能体，所述住院智能体被配置为：

基于病房中的感知设备采集的感知信息，确定患者是否满足在病房中进行入院检查的条件；

响应于确定所述患者满足入院检查的条件，控制智能护理推车将护士引导进入所述病房，以及控制所述智能护理推车呈现与所述入院检查相关的信息；

基于所述入院检查时采集的所述患者的体检数据，生成入院记录。

22.根据权利要求16所述的医院支撑平台，其特征在于，所述智能体包括住院服务对应的住院智能体，所述住院智能体被配置为：

对于患者住院的每一天，

根据患者的患者数据和医生对所述患者的医嘱，确定所述患者的每日计划，所述每日计划包括当天需要对所述患者执行的至少一项医疗操作；

通过所述患者的病房中的终端设备向所述患者展示所述每日计划；并且

通过所述患者对应的护士的终端设备向所述护士展示所述每日计划。

23.根据权利要求16所述的医院支撑平台，其特征在于，所述智能体包括手术服务对应的手术智能体，所述手术智能体被配置为：

确定从患者的当前位置到手术室等候区的计划路线；

控制智能轮椅将所述患者沿着所述计划路线运送到所述等候区；

在所述患者被运送到所述等候区的过程中，基于所述患者的患者数据和手术计划，通过患者的患者终端对所述患者进行术前教育；以及

在所述患者被运送到所述等候区后，基于所述等候区中的感知设备采集的患者的生物信息，对所述患者的身份进行验证。