CN114446423A - 一种医学数据处理方法、***、存储介质及设备 - Google Patents

Abstract

本发明公开了一种医学数据处理方法、装置、设备及计算机可读存储介质，通过检测第一医学业务模块的数据状态，并在在所述数据状态为第一设定状态的情况下，发布第一事件，进一步基于所述第一事件触发第二医学业务模块执行响应于所述第一事件的医学数据处理操作。如此，通过业务模块的数据状态和事件等定义，清晰的描述了业务流程，从而更好地对医疗数据进行业务流程的管理。并且通过事件驱动的方式，优化了业务模块之间的调用链路，有效缩短响应时间，显著提升用户体验。

Description

一种医学数据处理方法、***、存储介质及设备

技术领域

本发明涉及数据处理技术领域，尤其涉及一种医学数据处理方法、装置、计算机可读存储介质及设备。

背景技术

随着计算机和互联网等技术的发展，医学中较多数据和业务通过网络平台展开。目前较多医学业务与健康管理医疗平台结合相对紧密，耦合较重，较多的业务逻辑通过“调用函数-输入参数-返回结果”的方式来实现。数据模型的状态变更通过返回值或者复杂的耦合逻辑确定，并由此推进下一步任务的流转。如图1所示，医疗平台中多个模块之间采用函数调用的方式执行任务的流转，存在较多的流程编排逻辑。例如：需要生成医疗咨询小结，则该“医疗咨询小结”业务流程涉及A、B和C三个模块，且相互间存在依赖调用关系，流程由模块A统一编排，模块A先后调用模块B和模块C，其中模块B在处理过程中又需要调用模块C完成一部分数据处理。对于模块数量较少并且业务流程相对简单的情况，业务流程的调用和数据处理较为顺利。

但是，随着业务流程复杂度和业务模块数量的增加，模块之间的调用和数据处理将逐渐变得难以维护。并且各个模块之间的函数调用与依赖关系将越来越复杂，模块之间的边界也将越来越模糊。由此带来的问题是，难以从外部视角简明清晰的了解整个业务流程，以及各个分支流程的处理过程和每一个流程的响应动作。业务处理流程发生问题的情况下，维护操作困难。此外，随着调用链的增长，接口的响应时间随之增长，业务处理效率严重下降，严重影响用户体验。

发明内容

本发明实施例提供一种医学数据处理方法、装置及计算机可读存储介质。

根据本发明第一方面，提供了一种医学数据处理方法，所述方法包括：检测第一医学业务模块的数据状态；在所述数据状态为第一设定状态的情况下，发布第一事件；基于所述第一事件触发第二医学业务模块执行响应于所述第一事件的医学数据处理操作。

根据本发明一实施方式，所述基于所述第一事件触发第二医学业务模块执行响应于所述第一事件的医学数据处理操作，包括：所述第二业务处理模块监听所述第一事件；在所述第二业务处理模块监听到所述第一事件的发布的情况下，检测所述第二业务模块的数据状态；在所述数据状态为第二设定状态的情况下，发布第二事件。

根据本发明一实施方式，所述方法还包括：在所述第一事件对第二医学业务模块触发失败的情况下，在第一设定时间内对所述第一事件进行存储，并且每间隔第二设定时间重新发布所述第一事件；其中，所述第一设定时间大于或等于所述第二设定时间。

根据本发明一实施方式，所述方法还包括：在对所述第一事件执行设定次数的重新发布操作，并且所述第一事件对第二医学业务模块触发失败的情况下，发出用于示出所述第二业务模块触发失败的提醒。

根据本发明一实施方式，所述对所述第一事件进行存储，包括：采用持久化数据库，对所述第一事件进行存储。

根据本发明一实施方式，所述每间隔第二设定时间重新发布所述第一事件，包括：基于消息队列，每间隔第二设定时间重新发布所述第一事件。

根据本发明一实施方式，所述检测第一医学业务模块的数据状态，包括：接收目标对象的第一业务数据；判断所述第一业务数据是否符合发布所述第一事件的所述第一设定状态。

根据本发明第二方面，又提供了一种医学数据处理装置，所述装置包括：数据状态检测模块，用于检测第一医学业务模块的数据状态；事件发布模块，用于在所述数据状态为第一设定状态的情况下，发布第一事件；触发模块，用于基于所述第一事件触发第二医学业务模块执行响应于所述第一事件的医学数据处理操作。

根据本发明第三方面，又提供了一种健康管理医疗***，包括：多个业务模块，所述多个业务模块基于软件平台上的健康管理模型的基础业务流程进行配置；软件平台，用于配置基于所述多个业务模块的健康管理模型，所述健康管理模型用于实现如上所述的医学数据处理方法；数据库，用于采用持久化数据库对所述多个业务模块和所述软件平台的数据进行存储和处理；其中，所述软件平台基于消息列队与所述多个业务模块进行消息的接收与发送。

根据本发明第四方面，又提供了一种计算机设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如上所述的医学数据处理方法。

根据本发明第五方面，又提供了一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行如上所述的医学数据处理方法。

本发明实施例医学数据处理方法、装置、设备及计算机可读存储介质，通过检测第一医学业务模块的数据状态，并在在所述数据状态为第一设定状态的情况下，发布第一事件，进一步基于所述第一事件触发第二医学业务模块执行响应于所述第一事件的医学数据处理操作。如此，通过业务模块的数据状态和事件等定义，清晰的描述了业务流程，从而更好地对医疗数据进行业务流程的管理。并且通过事件驱动的方式，优化了业务模块之间的调用链路，有效缩短响应时间，显著提升用户体验。

需要理解的是，本发明的教导并不需要实现上面所述的全部有益效果，而是特定的技术方案可以实现特定的技术效果，并且本发明的其他实施方式还能够实现上面未提到的有益效果。

附图说明

通过参考附图阅读下文的详细描述，本发明示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本发明的若干实施方式，其中：

在附图中，相同或对应的标号表示相同或对应的部分。

图1示出了现有技术中健康管理医疗平台的架构示意图；

图2示出了构建本发明实施例健康管理医疗***的***架构示意图；

图3示出了本发明实施例医学数据处理方法的实现流程示意图；

图4示出了本发明实施例健康管理医疗***的***框架图；

图5示出了本发明实施例医学数据处理方法的具体应用示例的实现流程示意图；

图6示出了本发明实施例医学数据处理装置的组成结构示意图；

图7示出了本发明实施例设备的组成结构示意图。

具体实施方式

下面将参考若干示例性实施方式来描述本发明的原理和精神。应当理解，给出这些实施方式仅仅是为使本领域技术人员能够更好地理解进而实现本发明，而并非以任何方式限制本发明的范围。相反，提供这些实施方式是为使本发明更加透彻和完整，并能够将本发明的范围完整地传达给本领域的技术人员。

下面结合附图和具体实施例对本发明的技术方案进一步详细阐述。

图2示出了构建本发明实施例健康管理医疗***的***架构示意图。

参考图2，本发明实施例健康管理医疗***的***架构中，配置了多个服务器端服务，可以包括：DTx-kernel、DTx-brain、DTx-archive和DTx-doc。多个服务端之间可以利用RPC(Remote Procedure Call Protocol，远程调用协议)和HTTP(Hyper Text TransferProtocol，超文本传输协议)等进行通信。其中，各个服务端可以根据如下，内容进行配置：

DTx-kernel：负责业务逻辑的组装与网关服务，可以包括权限认证、请求路由、对业务提供组装接口和业务逻辑流程配置的管理等。

DTx-brain：负责算法的实现，如基线数据的入组分型、处方开具、运动/饮食方案确立和小结生成等。

DTx-archive：负责医学数据Schema(标准)的存储与标准医学指标的定义。

DTx-doc：负责各医疗素材类的管理与维护，如健康饮食食谱、运动动作等。

在本发明这一实施方式中，健康管理医疗***可以包括多个业务模块、软件平台和数据库等。其中，业务模块可以包括就诊模块、基线模块、处方模块、随访模块和小结模块等，软件平台用于配置基于多个业务模块的健康管理模型，健康管理模型的数量可以是多个。例如：可以配置仅包括就诊模块、处方模块和随访模块的健康管理模型，还可以配置包括就诊模块、基线模块、处方模块、随访模块和小结模块的健康管理模型。这里，可以在DTx-brain中对多个业务模块的基础业务流程进行配置。

在本发明这一实施方式中，健康管理医疗***的基线模块、处方模块和小结模块等所用到的标准医学指标的定义等可以在DTx-archive中进行配置。并且可以将各个业务模块所用到的医疗素材类资料在DTx-doc中配置。例如：健康饮食食谱、运动动作等。

在本发明这一实施方式中，可以在DTx-kernel中对健康管理模型进行配置，每一个健康管理模型中，对各个业务模块的调用关系可以根据实际需求灵活配置。并且，健康管理模型中各个业务模块的状态与响应事件可以根据需要自定义配置。进一步的，可以在DTx-kernel中，基于多个健康管理模型进行用户权限认证、请求路由、业务提供组装接口和业务逻辑流程配置等进行配置和管理。

在本发明这一实施例中，使用持久化数据库对各个服务端的数据进行存储和处理，并使用消息队列实现消息的接收与发送。

由此，基于上述***架构，可以快速的对多个健康管理模型结合或将健康管理模型进行扩展，使得健康管理医疗平台可以快速组装出可扩展的、清晰的业务流转流程。

需要说明的是，本发明实施例中，结合医学应用场景，使用医学术语对***架构进行详细描述，但实际应用过程中，该***架构也可以应用于其他适用的场景。

图3示出了本发明实施例医学数据处理方法的实现流程示意图。

参考图3，本发明实施例医学数据处理方法，至少包括如下操作流程：操作301，检测第一医学业务模块的数据状态；操作302，在数据状态为第一设定状态的情况下，发布第一事件；操作303，基于第一事件触发第二医学业务模块执行响应于第一事件的医学数据处理操作。

在操作301中，检测第一医学业务模块的数据状态。

在本发明这一实施方式中，可以基于图2的***架构，构建用于实现本发明实施例医学数据处理方法的健康管理医疗***，根据实际情况为健康管理医疗***配置多个业务模块。例如：可以配置就诊模块、基线模块、处方模块、随访模块和小结模块等。每一业务模块的数据可以配置为多个数据状态。这里仅对健康管理医疗***的业务模块进行简单描述，其他具体实现细节将在下文结合图4和图5进行详细描述，此处不再赘述。

其中，就诊模块用于维护具有医疗普遍意义的就诊流程，可以提供就诊的创建与维护，相关医生与患者的关联，就诊中各节点的运转机制等。

基线模块用于维护医学普遍意义的基线数据采集与应用流程，可以将就诊模块获取的信息，转换为具有医学普遍意义的基线数据，并判断基线数据是否收集完成，以及基线数据是否可以入组。基线数据是否可以入组的判断过程主要是为了判断基线数据是否符合本发明实施例医学数据处理方法可以管理的数据要求。管理目标的设定计算等。

处方模块用于维护医学普遍意义的处方管理，可以包括处方的用药方案、生活习惯管理方案、执行方案管理等。可以执行诊疗处方的开具、运动健康和饮食健康等方案的确认以及健康食谱和运动动作的执行方案等。

随访模块用于维护医学普遍意义的随访管理，包括医学指标的上传和管理等。

小结模块用于维护小结类型数据的管理，这里，小结是指针对一段周期内患者按照本次处方与方案执行的情况总结。

这里，就诊模块的数据可以配置为包括“待补充患者信息”、“已完善患者信息，待关联医生”和“已完善患者信息，已关联医生”等数据状态。基线模块的数据可以配置为包括数据待收集、数据已收集、基线数据可入组和基线数据不可入组等数据状态。处方状态的数据配置为处方待开具和处方已开具等数据状态。随访模块的数据可以配置为包括医学指标已上传和医学指标待上传等数据状态。小结模块的数据可以配置为包括待小结和已小结等数据状态。

需要说明的是，这里以以上五个业务模块为例对实现本发明医学数据处理方法的健康管理医疗***进行说明，实际应用过程中可以根据需要灵活进行业务模块的设计。

在本发明这一实施方式中，可以采用以下操作实现检测第一医学业务模块的数据状态：接收目标对象的第一业务数据，并判断第一业务数据是否符合发布第一事件的第一设定状态。

举例说明，第一医学业务模块为就诊模块，就诊模块能够接收目标对象的第一业务数据。例如：目标对象的性别和年龄等基本信息、以及基础疾病信息和所选择的医生信息等。第一医学业务模块能够根据所接收到的第一业务数据，判断当前的数据状态为“待补充患者信息”、“已完善患者信息，待关联医生”或“已完善患者信息，已关联医生”。当判定当前的数据状态为“已完善患者信息，已关联医生”的情况下，可以判定符合发布“已创建就诊信息”事件的条件。

在操作302中，在数据状态为第一设定状态的情况下，发布第一事件。

举例说明，可以在就诊模块的数据状态为“已完善患者信息，已关联医生”的情况下，发布“已创建就诊信息”事件。

在操作303中，基于第一事件触发第二医学业务模块执行响应于第一事件的医学数据处理操作。

在本发明这一实施方式中，基于第一事件触发第二医学业务模块执行响应于第一事件的医学数据处理操作，可以采用以下操作实现：第二业务处理模块监听第一事件，在第二业务处理模块监听到第一事件的发布的情况下，检测第二业务模块的数据状态，并在数据状态为第二设定状态的情况下，发布第二事件。

举例说明，第二医学业务模块为基线模块，基线模块在监听到就诊模块发布“已创建就诊信息”事件的情况下，执行数据收集动作，并检测基线模块的数据状态。并在检测到基线模块的数据状态为“基线数据可入组”的情况下，发布“基线可入组”事件。

在本发明这一实施方式中，还在第一事件对第二医学业务模块触发失败的情况下，在第一设定时间内对第一事件进行存储，并且每间隔第二设定时间重新发布第一事件。其中，第一设定时间大于或等于第二设定时间。

在本发明另一实施方式中，还在对第一事件执行设定次数的重新发布操作，并且第一事件对第二医学业务模块触发失败的情况下，发出用于示出第二业务模块触发失败的提醒。

在本发明这一实施方式中，可以采用持久化数据库，对第一事件进行存储。

在本发明这一实施方式中，可以基于消息队列，每间隔第二设定时间重新发布第一事件。

举例说明，若“已创建就诊信息”事件发布之后，未能成功触发基线模块执行数据收集动作并检测基线模块的数据状态。则可以将“已创建就诊信息”事件存储至持久化数据库中，并且可以基于消息列队的形式，周期性重新发布“已创建就诊信息”事件。若重新发布设定次数后，仍未成功触发基线模块执行数据收集动作并检测基线模块的数据状态。则可以发送用于示出第二业务模块触发失败的提醒信息，以提醒需要检查第一医学业务模块或第二医学业务模块是否配置异常。此时，可以对第一医学业务模块或第二医学业务模块的配置进行检查。由此，可以对各个医学业务模块进行统一管理，保证各个医学业务模块配置的兼容性和一致性。并且在此过程中，中间数据可以依托持久化数据库进行存储，无需额外引入其他备用方案。有效提升了实现本发明实施例医学数据处理方法的健康管理医疗***的配置效率。

图4示出了本发明实施例健康管理医疗***的***框架图。

参考图4，本发明实施例健康管理医疗***，可以用于实现本发明实施例医学数据处理方法，并且本发明实施例健康管理医疗***可以包括多个业务模块、软件平台和数据库。其中，多个业务模块基于软件平台上的健康管理模型的基础业务流程进行配置。软件平台用于配置基于多个业务模块的健康管理模型，健康管理模型用于实现如上所述的医学数据处理方法。持久化数据库，用于对多个业务模块和软件平台的数据进行存储和处理。软件平台基于消息列队与多个业务模块进行消息的接收与发送。

举例说明，健康管理医疗***可以包括多个业务模块和健康管理医疗软件平台，多个业务模块和健康管理医疗软件平台的数据可以采用持久化数据库进行存储和处理，并使用消息队列实现消息的接收与发送。健康管理模型的基础业务流程可以包括，就诊、基线处理、处方开具、随访、小结等。据此，业务模块可以包括就诊模块、基线模块、处方模块、随访模块和小结模块等。健康管理医疗软件平台上的状态与响应事件可以根据需要自定义配置。例如：可以配置健康管理模型1，数据状态包括状态11、状态12和状态1n，响应事件包括事件11和事件12。还可以配置健康管理模型2，数据状态包括状态21、状态22和状态2n，响应事件包括事件21和事件22。

由此，可以将多个健康管理模型结合或将健康管理模型进行扩展，使得健康管理医疗平台可以快速组装出可扩展的、清晰的业务流转流程。

举例来说，基线数据配置为数据待收集、数据已收集、基线数据可入组和基线数据不可入组等状态。处方状态为待开具、已开具，并配置当基线数据状态流转到基线数据可入组时，将触发处方开具动作，执行开具处方动作。由此在基线数据流转到可入组的情况下，发布基线数据可入组事件。处方模块监听到基线数据可入组事件的发布并消费，执行开具处方的动作。在处方模块的数据状态由处方待开具流转至处方已开具的情况下，进一步发布处方已开具事件，进而继续驱动健康管理医疗软件平台的其他业务模块的流转。需要说明的是，健康管理模型与业务模块之间的调用可以采用钩子(Hook)机制，钩子是Windows消息处理机制的一个平台，应用程序可以在上面设置子程序以监视指定窗口的某种消息，而且所监视的窗口可以是其他进程所创建的。当消息到达后，在目标窗口处理函数之前处理它。钩子机制允许应用程序截获处理Windows消息或特定事件。

在本发明这一实施例中，利用状态与消息维护了健康管理医疗软件平台的中间状态，从而使得健康管理医疗软件平台的各个健康管理模型更好的达成最终一致性。通过标准模块能力的定义与扩展，实现了业务需求与平台能力的分离。通过状态、事件等模型的定义，更加清晰的描述业务流程，从而更好地梳理与管控业务流程。并且，通过较多的事件驱动，进一步优化了业务模块的调用链路，有效缩短响应时间，显著提升用户体验。

图5示出了本发明实施例医学数据处理方法的具体应用示例的实现流程示意图；

参考图5，实现本发明实施例医学数据处理方法的健康管理医疗***包括5个业务模块，分别是就诊模块、基线模块、处方模块、随访模块和小结模块。

就诊模块的数据可以配置为包括“待补充患者信息”、“已完善患者信息，待关联医生”和“已完善患者信息，已关联医生”等数据状态。基线模块的数据可以配置为包括数据待收集、数据已收集、基线数据可入组和基线数据不可入组等数据状态。处方状态的数据配置为处方待开具和处方已开具等数据状态。随访模块的数据可以配置为包括医学指标已上传和医学指标待上传等数据状态。小结模块的数据可以配置为包括待小结和已小结等数据状态。

就诊模块在检测到数据状态为“已完善患者信息，已关联医生”的情况下，发布“已创建就诊信息”事件。基线模块监听到“已创建就诊信息”事件的情况下，触发基线模块执行数据收集动作，并在检测到基线模块的数据状态为基线数据可入组的情况下，发布“基线可入组”事件。处方模块监听到“基线可入组”事件的情况下，触发处方模块执行处方开具动作，并在检测到处方模块的数据状态为处方已开具的状态下，发布“处方已开具”事件。随访模块监听到“处方已开具”事件的情况下，触发随访模块执行随访动作，并在检测到随访模块的数据状态为医学指标已上传的情况下，发布“本次随访完成”事件。这里，可以配置多次随访动作，并在发布“本次随访完成”事件过程中，确认是否为最后一次随访，则发布“最后一次随访完成”事件。并且这里可根据随访频次和随访时间，生产消息列队。小结模块监听到“最后一次随访完成”事件的情况下，触发小结模块执行小结动作，并在检测到小结模块的数据状态为“已小结”的情况下，发布“全程就诊完成”事件，判定全程就诊完成。

本发明实施例医学数据处理方法、装置、设备及计算机可读存储介质，通过检测第一医学业务模块的数据状态，并在在数据状态为第一设定状态的情况下，发布第一事件，进一步基于第一事件触发第二医学业务模块执行响应于第一事件的医学数据处理操作。如此，通过业务模块的数据状态和事件等定义，清晰的描述了业务流程，从而更好地对医疗数据进行业务流程的管理。并且通过事件驱动的方式，优化了业务模块之间的调用链路，有效缩短响应时间，显著提升用户体验。

如图6所示，为本发明医学数据处理装置的一个具体实施例。本实施例装置，即用于执行图2～5方法的实体装置。其技术方案本质上与上述实施例一致，上述实施例中的相应描述同样适用于本实施例中。参考图6，本发明实施例提供一种医学数据处理装置，装置60包括：数据状态检测模块601，用于检测第一医学业务模块的数据状态；事件发布模块602，用于在数据状态为第一设定状态的情况下，发布第一事件；触发模块603，用于基于第一事件触发第二医学业务模块执行响应于第一事件的医学数据处理操作。

图7是本发明实施例提供的一种设备的结构示意图。在硬件层面，该设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatilememory)，例如至少1个磁盘存储器等。当然，该设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放执行指令。具体地，执行指令即可被执行的计算机程序。存储器可以包括内存和非易失性存储器，并向处理器提供执行指令和数据。

在一种可能实现的方式中，处理器从非易失性存储器中读取对应的执行指令到内存中然后运行，也可从其它设备上获取相应的执行指令，以在逻辑层面上形成医学数据处理装置。处理器执行存储器所存放的执行指令，以通过执行的执行指令实现本发明任一实施例中提供的医学数据处理方法。

上述如本发明图6所示实施例提供的医学数据处理装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

本发明实施例还提出了一种可读介质，该可读存储介质存储有执行指令，存储的执行指令被电子设备的处理器执行时，能够使该电子设备执行本发明任一实施例中提供的医学数据处理方法，并具体用于执行如图2～图5所示的方法。

前述各个实施例中的电子设备可以为计算机。

本领域内的技术人员应明白，本发明的实施例可提供为方法或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例，或软件和硬件相结合的形式。

本发明中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上仅为本发明的实施例而已，并不用于限制本发明。对于本领域技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本发明的权利要求范围之内。

Claims (11)

1.一种医学数据处理方法，其特征在于，所述方法包括：

检测第一医学业务模块的数据状态；

在所述数据状态为第一设定状态的情况下，发布第一事件；

基于所述第一事件触发第二医学业务模块执行响应于所述第一事件的医学数据处理操作。

2.根据权利要求1所述的方法，其特征在于，所述基于所述第一事件触发第二医学业务模块执行响应于所述第一事件的医学数据处理操作，包括：

所述第二业务处理模块监听所述第一事件；

在所述第二业务处理模块监听到所述第一事件的发布的情况下，检测所述第二业务模块的数据状态；

在所述数据状态为第二设定状态的情况下，发布第二事件。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述第一事件对第二医学业务模块触发失败的情况下，在第一设定时间内对所述第一事件进行存储，并且每间隔第二设定时间重新发布所述第一事件；

其中，所述第一设定时间大于或等于所述第二设定时间。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：在对所述第一事件执行设定次数的重新发布操作，并且所述第一事件对第二医学业务模块触发失败的情况下，发出用于示出所述第二业务模块触发失败的提醒。

5.根据权利要求3所述的方法，其特征在于，所述对所述第一事件进行存储，包括：

采用持久化数据库，对所述第一事件进行存储。

6.根据权利要求3所述的方法，其特征在于，所述每间隔第二设定时间重新发布所述第一事件，包括：

基于消息队列，每间隔第二设定时间重新发布所述第一事件。

7.根据权利要求1所述的方法，其特征在于，所述检测第一医学业务模块的数据状态，包括：

接收目标对象的第一业务数据；

判断所述第一业务数据是否符合发布所述第一事件的所述第一设定状态。

8.一种医学数据处理装置，其特征在于，所述装置包括：

数据状态检测模块，用于检测第一医学业务模块的数据状态；

事件发布模块，用于在所述数据状态为第一设定状态的情况下，发布第一事件；

触发模块，用于基于所述第一事件触发第二医学业务模块执行响应于所述第一事件的医学数据处理操作。

9.一种健康管理医疗***，包括：

多个业务模块，所述多个业务模块基于软件平台上的健康管理模型的基础业务流程进行配置；

软件平台，用于配置基于所述多个业务模块的健康管理模型，所述健康管理模型用于实现权利要求1-7中任一项所述的医学数据处理方法；

数据库，用于采用持久化数据库对所述多个业务模块和所述软件平台的数据进行存储和处理；

其中，所述软件平台基于消息列队与所述多个业务模块进行消息的接收与发送。

10.一种计算机设备，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1-7中任一项所述的医学数据处理方法。

11.一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行如权利要求1-7中任一项所述的医学数据处理方法。

Images