技术领域
[0001] 本发明涉及嵌入式界面设计的技术领域，尤其涉及一种脓毒症管理软件的嵌入式界面设计方法及系统。
相关背景技术
[0002] 脓毒症(Sepsis)是由感染引起的全身性炎症反应综合征(Systemic Inflammatory Response Syndrome,SIRS)，它不仅是一种常见且严重的临床综合征，而且是全球范围内导致病人死亡和住院的主要原因之一。脓毒症的发生是由于病原体(如细菌、病毒、真菌、寄生虫等)感染导致宿主免疫系统的异常反应，进而引发一系列复杂的病理生理变化，包括炎症反应失控、免疫功能紊乱、凝血功能障碍和组织损伤等。
[0003] 脓毒症面临的现状与挑战具体包括以下几点：
[0004] (1)高发病率与高死亡率：
[0005] 脓毒症的发病率在全球范围内逐年上升，尤其在老年人、免疫功能低下者以及慢性病患者中更为常见。尽管现代医学技术和治疗手段不断进步，但脓毒症的死亡率依然居高不下，严重威胁患者的生命健康。
[0006] (2)早期识别困难：
[0007] 脓毒症的临床表现复杂多样，早期症状不具有特异性，容易与其他疾病混淆。传统的脓毒症识别方法依赖于临床症状和实验室指标，常常延误诊断和治疗时机，导致患者病情加重。
[0008] (3)治疗复杂性：
[0009] 脓毒症的治疗涉及抗感染治疗、液体复苏、血管活性药物使用、器官支持治疗等多个方面。由于脓毒症的病因和病理机制复杂，个体间差异大，治疗方案的制定和实施存在很大挑战。
[0010] 近年来，随着人工智能(AI)、大数据分析和自然语言处理(NLP)技术的快速发展，基于数据驱动的疾病预测和管理工具逐渐成为临床研究的热点。这些技术的应用，为脓毒症的早期识别和精准治疗提供了新的思路和方法。但是，现有的基于数据驱动的疾病预测和管理工具的应用一般都是一个单独独立的系统，具备以下缺陷：
[0011] (1)操作繁琐
[0012] 多系统切换：医生需要在多个独立的系统之间频繁切换，才能完成脓毒症风险评估和管理。这种操作不仅增加了医生的工作负担，还容易导致信息遗漏和操作失误。
[0013] (2)效率低下
[0014] 时间浪费：在紧急情况下，医生需要迅速获取患者的全面信息并做出决策。如果脓毒症管理软件不能与原始医疗系统无缝集成，医生需要花费额外的时间在不同系统间进行数据查询和输入，导致决策延迟。
[0015] (3)信息孤岛
[0016] 数据不连贯：独立运行的脓毒症管理软件与原始医疗系统的数据不互通，容易形成信息孤岛。医生无法在一个平台上查看全面的患者数据，影响整体的病情评估和管理。
[0017] (4)学习成本高
[0018] 系统复杂性：医生需要熟悉和掌握多个系统的操作方式，增加了学习成本和使用难度。新系统的引入需要额外的培训时间和资源，可能影响临床工作的效率。
[0019] (5)用户接受度低
[0020] 使用不便：由于操作不便和效率低下，医生可能不愿意频繁使用独立的脓毒症管理软件，导致系统的使用率和接受度降低，无法充分发挥其预警和管理功能。
[0021] (7)反馈和改进滞后
[0022] 难以形成闭环管理：独立的脓毒症管理软件难以与原始医疗系统的数据进行实时交互，生成的辅助诊疗信息无法自动反馈到原始系统中，影响后续的跟踪和评估，难以实现闭环管理。
具体实施方式
[0073] 为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
[0074] 本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。
[0075] 第一实施例
[0076] 如图1所示，本实施例提供了一种脓毒症管理软件的嵌入式界面设计方法，包括以下步骤：
[0077] S1：为脓毒症管理软件设计包括折叠状态和展开状态两种模式的嵌入式界面。
[0078] 在本实施例中，步骤S1，具体为：
[0079] 通过CSS设置所述嵌入式界面固定在浏览器的底部，使得无论所述原始医疗系统如何滚动，所述嵌入式界面始终保持在屏幕下方，为所述嵌入式界面设计一个标题栏，当所述嵌入式界面处于所述折叠状态时，所述嵌入式界面仅显示所述标题栏，当所述嵌入式界面处于所述展开状态时，所述嵌入式界面显示所述标题栏和全部内容区域。
[0080] 其中，通过CSS设置所述嵌入式界面固定在浏览器的底部，具体代码的示例如下：
[0081]
[0082]
[0083]
[0084]
[0085] 代码详细解释：
[0086] HTML结构:
[0087]
：创建嵌入式界面容器，初始状态为折叠(collapsed)。[0088]
：创建一个按钮，用于切换界面的折叠和展开状态。[0089]
：包含嵌入式界面内的主要内容，显示在界面展开时。[0090] CSS样式:
[0091] .embedded‑interface：定义嵌入式界面的样式和位置，使其固定在浏览器底部。
[0092] .collapsed&.expanded：用于控制界面的显示和隐藏状态。
[0093] .toggle‑button：定义按钮的样式和交互效果。
[0094] JavaScript:
[0095] toggleButton.addEventListener('click',function(){...})：为按钮添加点击事件监听器，控制界面的折叠和展开，并根据当前状态更改按钮的文本。
[0096] 这个代码可以直接嵌入到网页中，完成后嵌入式界面将在浏览器底部显示，可以根据需要进行折叠和展开。
[0097] 所述嵌入式界面的所述折叠状态和所述展开状态通过改变所述嵌入式界面的高度或通过对所述内容区域进行显示与隐藏来实现。
[0098] 当用户点击所述标题栏时，通过JavaScript监听标题栏的点击事件实现所述嵌入式界面在所述折叠状态和所述展开状态之间切换。
[0099] 在所述标题栏上设置提醒标志用于当医生录入患者信息过程中触发到风险评估提示时，提示医生点开所述嵌入式界面进入所述展开状态进行查看。
[0100] S2：将所述嵌入式界面通过Web集成方式嵌入到原始医疗系统中，固定于所述原始医疗系统的底部。
[0101] 所述Web集成方式采用以下任意一种方式：
[0102] 将所述嵌入式界面嵌入到一个iFrame框架中，所述iFrame框架作为HTML元素将所述嵌入界面嵌入到所述原始医疗系统的界面中；
[0103] iFrame框架的举例如下：
[0104]
[0105]
[0106] 详细解释：
[0107] 嵌入式界面(embedded_interface.html):
[0108] 这是一个独立的HTML文件，定义了嵌入式界面的结构、样式和功能。
[0109] 当这个文件加载到iFrame中时，将显示在浏览器的底部，初始状态为折叠。
[0110] 原始医疗系统页面(original_system.html):
[0111] 这是原始医疗系统的页面，在该页面中，通过iFrame元素嵌入了上面定义的嵌入式界面。
[0112] iFrame的样式使其固定在浏览器底部，并且宽度占满整个页面。
[0113] iFrame的作用:
[0114] 通过iFrame，嵌入式界面与原始医疗系统的页面保持独立。嵌入式界面可以通过加载独立的HTML文件实现，无需修改原始系统的代码，确保了嵌入的灵活性和隔离性。
[0115] 或
[0116] 通过JavaScript SDK，将所述脓毒症管理软件的功能与所述嵌入式界面集成到所述原始医疗系统中。
[0117] 此外，本实施例还包括：采用SSO单点登录的方式以实现用户在登录所述原始医疗系统之后，无缝访问所述脓毒症管理软件，具体为：
[0118] 当访问所述原始医疗系统的登录页面时进行身份验证，SSO机制通过包括OAuth 2.0、SAML或JWT在内的方式生成和分发认证凭据。
[0119] 所述原始医疗系统在登录成功后，所述SSO机制将包括Access Token、SAML断言或JWT在内的所述分发认证凭据传递给所述脓毒症管理软件。
[0120] 所述脓毒症管理软件接收到所述认证凭据后，验证所述认证凭据的有效性，若所述认证凭据验证通过，用户直接访问所述脓毒症管理软件的功能。
[0121] 所述脓毒症管理软件根据用于的角色和权限，展示对应的界面和功能，所述SSO机制还提供了处理会话的管理和过期处理，确保安全性。
[0122] 其中，OAuth 2.0、SAML或JWT分别为：
[0123] (1)OAuth 2.0
[0124] 概述：OAuth 2.0是一种授权框架，允许第三方应用访问用户的资源而无需暴露用户的凭据。适合需要授权访问资源的场景。
[0125] 实现流程：
[0126] 用户通过原始系统(如EMR或HIS)登录并获得访问令牌(Access Toke n)。
[0127] 脓毒症管理软件通过令牌验证用户身份。
[0128] 验证通过后，脓毒症管理软件允许用户直接访问，而无需再次输入登录凭据。
[0129] 优点：广泛应用于Web和移动应用，灵活性高，适合与RESTAPI集成。
[0130] (2)SAML(Security Assertion Markup Language)
[0131] 概述：SAML是一种基于XML的开源标准，用于在身份提供者(Identit y Provider,IdP)和服务提供者(Service Provider,SP)之间交换认证和授权数据。
[0132] 实现流程：
[0133] 医生在原始系统登录时，SAML IdP对用户进行身份验证。
[0134] SAML IdP生成一个SAML断言(Assertion)，包含用户的认证信息。
[0135] 脓毒症管理软件作为SP接收SAML断言并验证其真实性。
[0136] 验证通过后，医生可以访问脓毒症管理软件而无需再次登录。
[0137] 优点：适合企业级应用，支持复杂的企业SSO场景，安全性高。
[0138] (3)JWT(JSON Web Token)
[0139] 概述：JWT是一种轻量级的自包含令牌，包含用户的认证信息和权限声明。JWT通常用于无状态的认证机制。
[0140] 实现流程：
[0141] 医生在原始系统登录后，系统生成一个JWT，包含用户的身份信息和权限。
[0142] 脓毒症管理软件接收并解码JWT，验证其签名和有效期。
[0143] 验证成功后，医生可以无缝访问脓毒症管理软件。
[0144] 优点：简单易用，适合微服务架构和RESTful API，具有自包含和无状态的特点。
[0145] S3：所述脓毒症管理软件实时获取所述原始医疗系统中的病历数据，对捕捉到的所述病历数据进行分析，自动对患者发展为脓毒症的风险进行智能评估预警。
[0146] 所述脓毒症管理软件与所述原始医疗系统通过接口连接，实时接收所述原始医疗系统中的所述病历数据，所述病历数据包括患者的基本信息、实验室检查结果、影像报告和医嘱内容；
[0147] 当所述病历数据传输到所述脓毒症管理软件中后，所述脓毒症管理软件自动对所述病历数据进行处理，提取关键信息进行分析，评估患者是否存在脓毒症的高风险。
[0148] S4：所述嵌入式界面实时对所述脓毒症管理软件评估到的达到风险预设阈值的患者进行实时提示。
[0149] 在本实施例中，步骤S4具体为：
[0150] 在所述嵌入式界面的所述标题栏上设置所述提醒标志和评估历史记录标志，在所述折叠状态时当医生在所述原始医疗系统中录入患者信息过程中触发到患者的所述风险评估阈值时，将在所述标题栏上以数字形式进行风险评估，在所述展开状态时点击所述提醒标志进行智能风险提示信息界面，或点击所述评估历史记录标志进入评估历史记录界面。
[0151] 所述嵌入式界面，还包括：
[0152] 在所述评估历史记录界面上点击任意一个历史评分结果重新打开评估表评分界面，查看历史评估的项目勾选情况明细，或点击修改结果，在当前评估表下重新评估；在所述嵌入式界面上若医生对所述脓毒症管理软件自动评估结果认可，点击快速确认按键，直接完成脓毒症风险评估，或点击界面中查看评估结果展开评估表详细结果。
[0153] 第二实施例
[0154] 本实施例提供了一种基于第一实施例的嵌入式界面的具体实施例，具备包括：
[0155] (1)如图2所示的嵌入式界面的折叠状态示意图
[0156] 脓毒症管理软件软件采用嵌入式界面，与原始的EMR、HIS系统对接，在医生书写病历时,产品以折叠框模式显示在浏览器下方。
[0157] 在医生录入患者信息过程中触发到风险评估提示时，产品将在折叠框中以红色数字形式提醒医生进行风险评估，点击折叠框可展开产品视窗。
[0158] (2)如图3所示的嵌入式界面的展开状态示意图
[0159] 在嵌入式界面的展开状态中，用户可以通过点击提示标志来进入智能风险提示信息界面、或者通过评估历史记录标志进入评估表历史记录界面。
[0160] (3)如图4所示的评估表历史记录查阅示意图
[0161] 在历史评估记录中点击任一历史评分结果、即重新打开评估表评分界面，可查看历史评估的项目勾选情况明细，或点击“修改结果”，在当前评估表下重新评估。
[0162] (4)如图5所述的脓毒症风险分析界面第一示意图和如图6所示的脓毒症风险分析详细评估界面示意图
[0163] 医生在电子病历中录入患者病程信息后，软件计算患者脓毒血症风险，提醒医护人员对尚未进行脓毒血症风险评估的患者进行评估。
[0164] 如医生对软件AI评估结果认可，可点击“快速确认”按键，直接完成SOFA风险评估。也可点击界面中“查看评估结果”展开评估表详细结果。
[0165] (5)如图7所述的脓毒症风险分析界面第二示意图和如图8所示的脓毒症风险分析SOFA示意图。
[0166] 点击产品视窗中的“sofa评分表”功能键，可展开评分表界面。
[0167] (6)如图9所述的脓毒症风险分析界面第三示意图和如图10所示的脓毒症风险分析结果示意图。
[0168] 可点击评分表的“查看评估结果”，可查看AI评估结果的勾选情况、病历原文等详细信息，系统将弹框展示相关内容。
[0169] 此外，本实施例还提供了对于脓毒症风险管理软件的硬件与网络配置建议，具体为：
[0170] 脓毒症风险管理软件采用前后端分离的微服务架构，通过2台应用服务器和1台数据库服务器提供高负载和高稳定性的服务。根据医院实际情况，建议采用三层架构，业务层、应用层、数据库，所有配置中的品牌都只是参考，采用相近配置即可。
[0171] (1)应用服务器建议
[0172] 应用服务器是交互层与中间件的集合服务器，对整个系统的性能有决定性作用，要求较高。
[0173] 配置建议：两台server(建议)组成双机热备份，要求32G以上内存,8核以上CPU。其它配制主流就行。
[0174] (2)数据库服务器
[0175] 配置建议：单台server，要求32G以上内存，8核以上CPU
[0176] (3)存储设备
[0177] 配置建议：数据库服务器负载存储动态更新知识库，建议配置500G以上硬盘，应用服务器建议配置200G以上硬盘，品牌不限。
[0178] (4)前置服务器(知识库自动更新)
[0179] 前置服务器主要用于从医学平台专用私有网络VPC下载动态更新的分析文本库更新内容，配置较低，建议内存8G以上，4核以上CPU，200G以上硬盘即可。
[0180] (5)服务器操作系统
[0181] Linux系统CentOs7.2_6464bit版本
[0182] (6)网络要求
[0183] 主干千兆，百兆到桌面，(百兆主干，十兆桌面也可以正常运行)
[0184] TCP/IP协议
[0185] (7)客户端操作系统
[0186] 由于采用B/S模式，客户端IE版本保证IE9以上版本即可
[0187] (8)数据库要求
[0188] 支持MySql 5.7.1及以上版本。
[0189] 脓毒症风险管理软件的安全性能包括：
[0190] (1)技术优势
[0191] 脓毒血症临床风险管理软件采用分布式框架，采用多级缓存策略，实现接口的快速响应、可提供高并发、高可用的服务，系统通过数据加密服务、访问控制等服务，保存业务数据的安全性。
[0192] (2)数据备份与灾备
[0193] 数据可靠性：
[0194] 系统上线后，为了保证数据库的安全，稳定性，数据库管理员会定期备份数据库，采用良好的备份策略，以维持数据的安全性；和保证数据库稳定，顺畅，高效的运行。尽最大的努力减少由于数据丢失或损坏造成的业务系统宕机，须从备份方面做好基本的保障工作。
[0195] 备份策略：
[0196] 每天凌晨1点完整备份数据库到指定目录；
[0197] 备份数据存储周期为30天，定期删除过期备份数据；
[0198] 恢复策略：由于脓毒血症临床风险管理软件的医学知识和规则为更新定期。对业务数据无依赖，可使用最新的备份数据，恢复数据库后，即可正常运行。
[0199] 第三实施例
[0200] 如图11所示，本实施例提供了一种用于执行如第一实施例中的脓毒症管理软件的嵌入式界面设计方法的脓毒症管理软件的嵌入式界面设计系统，包括：
[0201] 界面设计模块1，用于为脓毒症管理软件设计包括折叠状态和展开状态两种模式的嵌入式界面；
[0202] 界面集成模块2，用于将所述嵌入式界面通过Web集成方式嵌入到原始医疗系统中，固定于所述原始医疗系统的底部；
[0203] 数据分析模块3，用于提供给所述脓毒症管理软件实时获取所述原始医疗系统中的病历数据，对捕捉到的所述病历数据进行分析，自动对患者发展为脓毒症的风险进行智能评估预警；
[0204] 风险提示模块4，用于提供给所述嵌入式界面实时对所述脓毒症管理软件评估到的达到风险预设阈值的患者进行实时提示。
[0205] 一种计算机可读存储介质，计算机可读存储介质存储有计算机代码，当计算机代码被执行时，如上述方法被执行。本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁盘或光盘等。
[0206] 以上所述仅是本发明的优选实施方式，本发明的保护范围并不仅局限于上述实施例，凡属于本发明思路下的技术方案均属于本发明的保护范围。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理前提下的若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。
[0207] 以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
[0208] 应当说明的是，上述实施例均可根据需要自由组合。以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。
