1.本发明涉及计算机领域，具体涉及一种用于临床试验的系统与方法。
背景技术：
：：2.在临床试验的场景中，往往需要pm（临床试验项目经理）制定项目sop（标准操作程序），临床项目的项目大都十分复杂，中间设计多个参与方，各个参与方的分工和协作都需要pm来协调处理，十分考验pm的经验，因此，以往的临床试验非常依赖pm的能力和经验，一旦pm人员发生变动，项目交接十分困难，另一方面，不同的临床试验项目，在一些细节的场景上或多或少都存在需要特殊处理的情况，项目方难以从一个成功执行的项目复制到另一个项目上；另外，在传统的场景中，各个参与方之间的协作大多是通过人员间的线上或线下沟通，pm需要定期召开项目会议，或逐个询问参与方进度，来把控项目的整体进度，存在沟通费事费力、时效性差等问题，项目进度难以有效把控；目前，在临床试验领域缺少一种可自动化控制的系统，来有效控制临床试验项目进度，简化沟通流程，降低沟通成本。技术实现要素：3.本发明要解决的技术问题是现有的场景中，存在沟通费时费力、时效性差等问题，项目进度难以有效把控，本发明提供一种用于临床试验的系统，ctdl（临床试验描述语言），通过抽象临床试验的模型，为每个参与方分配任务，用任务间的流转关系将任务组织成流程，将传统的sop文档转化为程序可以执行、计算的语言，在运行的时候，只用传入项目参数、项目人员等信息，就可以自动复制、扩展到不同的项目上，解决了sop文档复杂、难扩展的弊端，同时，ctdl的执行引擎可以自动为每个任务排期、根据任务乃至整体项目进度，解决了传统场景下沟通协作难的问题，在bpmn的流程模型基础上，增加动作信息（action）和上下文（context）等概念，定义了一种全新的临床试验描述语言，配合临床试验执行引擎，在临床试验的场景上运用、落地，用以解决现有技术导致的缺陷。4.本发明还提供一种用于临床试验的方法。5.为解决上述技术问题，本发明提供以下的技术方案：第一方面，一种用于临床试验的系统，其中，包含数据存储模块（actionqueue）、流程执行引擎（workflowengine）、元素动作执行服务模块（elementactionservice）、流动作执行服务模块（flowactionservice）；所述元素动作执行服务模块与所述流动作执行服务模块内均设置有临床试验流程模型模块；所述临床试验流程模型模块用于定义临床试验中的多个业务单元（element）及它们之间的流转关系，所述元素动作执行服务模块与所述流动作执行服务模块分别根据所述临床试验流程模型模块执行任务；所述数据存储模块内存储有动作消息队列，所述动作消息队列中记载有待执行的动作信息（action）；所述流程执行引擎实时监控所述数据存储模块内是否有可消费的动作信息（action），当有动作信息（action）可消费时，所述流程执行引擎消费一条动作信息（action）并根据动作信息（action）的类型分类为元素动作和流动作分发至所述元素动作执行服务模块与所述流动作执行服务模块，分发完成后继续监听所述数据存储模块，消费下一条动作信息（action）；所述元素动作执行服务模块获取并执行所述元素动作；所述流动作执行服务模块获取并执行所述流动作；所述元素动作执行服务模块执行后的元素动作及所述流动作执行服务模块执行后的流动作传输至所述数据存储模块并存储在所述数据存储模块中动作消息列队的末端。6.上述的一种临床试验场景的系统，其中，所述元素动作执行服务模块内设置的临床试验流程模型模块包含业务单元分类模块；所述流动作执行服务模块内设置的临床试验流程模型模块包含流转关系分类模块。7.上述的一种临床试验场景的系统，其中，element（业务单元）是临床试验中的业务单元的统称，所述业务单元分类模块将业务单元（element）分为以下类别：开始事件（startevent）、结束事件（endevent）、通知事件（notificationevent）、等待事件（waitingevent）、用户任务（task）、一次性机器人程序（disposablebot，该机器人程序只会执行一次）、可重复机器人程序（repeatablebot，该机器人程序会按照设定的时间周期，重复地执行）、流程（process）。8.上述的一种临床试验场景的系统，其中，flow（流）定义了同一个流程中的业务组件间的流转（不同流程内部的业务组件间不允许流转），从流的起点（上游组件）流向终点（下游组件）。以下称一个组件的outputflow（输出流）是起点为该组件的流，类似的，inputflow（输入流）为终点为该组件的流。流是基于动作信息（action）触发的。所述流转关系分类模块将业务单元之间的流转关系即流转单元分为以下类别：顺序流（sequenceflow）、调用流（invokeflow）、消息流（messageflow）、返回流（returnflow）。9.上述的一种临床试验场景的系统，其中，所述元素动作执行服务模块内置的所述临床试验流程模型模块创建的动作算法模型用于控制执行所述业务单元的等待中（pending）、进行中（ongoing）、已完成（finished)、取消（cancel）的任务；所述动作算法模型还用于控制执行所述业务单元的开始事件（start）、结束事件、通知事件（notificationevent）、等待事件、用户任务、一次性机器人程序、可重复机器人程序、流程；所述通知事件和等待事件用一个消息组的字段关联；所述通知事件用来发送消息，所述等待事件用来接收消息；所述流动作执行服务模块内置的所述临床试验流程模型模块创建的流算法模型用于控制执行所述流转单元的等待中（pending）、已激活（active）、撤回（withdraw）和取消（cancel）的任务；所述流算法模型还用于控制执行所述流单元的顺序流（sequenceflow）、调用流（invokeflow）、消息流（messageflow）、返回流（returnflow）的任务；所述业务单元内置有业务上下文（context），所述业务上下文中存储有业务参数；所述流转单元内置有流上下文（context），所述流上下文中存储有交付参数；上下文（context）是参数的集合，业务单元（element）里有业务上下文，业务上下文里有多个业务参数；流转单元里有流上下文；流上下文里有交付参数；所述动作信息包括以下分类：元素动作、流动作、临床试验开始动作、临床试验结束动作；所述元素动作执行服务模块获取并执行的所述元素动作包含以下几种动作：元素开始动作、元素完成动作、元素调用动作、元素撤回动作、元素退回动作、元素取消动作；所述流动作执行服务模块获取并执行所述流动作包含以下几种动作：流激活动作、流撤回动作、流取消动作；所述临床试验开始动作是在临床试验开始的时候执行的，只执行一次，触发主流程的元素开始动作；所述临床试验结束动作标记着临床试验的结束。10.上述的一种临床试验场景的系统，其中，参数包含临床试验中使用到模板、产生的交付物、或临床试验执行引擎（ctee，clinicaltrialexecuteengine）执行过程中的临时变量、或ctdl中定义的参数等，临床试验执行引擎的核心是基于actionqueue，通过不停地消费动作信息（action），执行对应的动作，触发后续的动作，达到流程自动化的效；所述业务参数包含文件、文件目录、数字、日期、时间、文本、布尔、列表、确认列表、用户列表；所述交付参数包含文件、文件目录、数字、日期、时间、文本、布尔、列表、确认列表、用户列表；其中，布尔（boolean）是计算机中的一种数据结构，只有真（true）和假（false）两种值。11.与传统的流程引擎不同，ctdl并不是让一个流程中的所有节点都共享一个参数域，而是让每个业务单元（element）都拥有各自的上下文（context），上下文中存放着运行所需的参数；业务单元（element）与业务单元（element）之间的参数传递是由ctee根据流（flow）上的参数定义自动进行传递的；流（flow）也有自己的上下文（context），流（flow）在被触发的时候，会先根据参数定义，从上游的上下文（context）中将对应的参数取出来，放到自己的上下文（context）里，待下游组件可以开始的时候（满足开始条件），再由下游将对应的参数从流（flow）的上下文（context）里取出装载到自己的上下文（context）里；这样把上下文（context）在流上暂存的做法，相比直接把变量从上游传给下游，有几点好处：1.当一个组件存在多个输入流（incomingflow）的时候，方便人为设置流加载的顺序（根据优先级，而不是时间顺序）；2.若下游组件运行出错，方便进行回滚；特别的，为了方便处理、简化ctdl定义，每个组件的上下文会自动继承其所在流程的上下文（所在的流程在其被创建的时候，亦会自动继承父流程的上下文）；制定计划：ctdl的一个很主要的功能是可以为临床试验项目制订计划，帮助pm合理安排时间、把控项目进度，在ctdl中定义了若干的时间约束条件，如下：业务单元（element）的计划开始时间不早于项目的计划开始时间；业务单元（element）的计划开始时间不早于其incomingsequenceflow的上游业务单元（element）的计划结束时间；业务单元（element）的计划开始时间不早于其incominginvokeflow的上游业务单元（element）的计划开始时间；startevent的开始时间等于所在流程的开始时间；业务单元（element）的计划结束时间不早于其计划开始时间 计划周期；业务单元（element）的计划结束时间不早于其incomingreturnflow的上游业务单元（element）的计划结束时间；流程（process）的计划结束时间不早于其中的任何一个endevent的计划结束时间；初始时，将所有主流程的计划开始时间和计划结束时间设置为项目的开始实际，然后把主流程的所有startevent加入队列中，开始执行下列步骤：步骤d1：取出队列头部的业务单元（element），根据上述依赖条件，计算任务的计划时间；步骤d2：若计划时间未发生变化，则跳过；否则：步骤d3：沿着当前业务单元（element）的outgoingflow，把后续的业务单元（element）加入队列中，特别地，endevent没有outgoingflow，需要特殊处理，把其归属的流程（process）加入队列中；步骤d4：回到步骤d1，持续迭代更新，直到队列为空。12.动态调整：以下情况出现时，会触发计划的动态调整：创建一个新的实例，人工调整了业务单元（element）的计划；动态调整策略：与上述的初始化计划时间的步骤相同，区别是一开始只把对应的业务单元（element）加入队列中。13.上述的一种临床试验场景的系统，其中，所述元素动作执行服务模块包含执行开始模块（dostart）、执行完成模块（docomplete）、执行调用模块（doinvoke）、执行撤回模块（dowithdraw）、执行退回模块（doreject）、执行取消模块（docancel）；所述执行开始模块（dostart）获取并执行所述元素开始动作，用于检查输入依赖是否满足每个定义的输入序列流（incomingsequenceflow）都被触发或被取消，若不满足，跳过处理；还用于装载流程上下文；还用于把当前组件(所有的动作信息（action）都是对某个对象执行的,元素动作执行服务模块（elementactionservice）就是对某个业务单元（element）执行的，流动作执行服务模块（flowactionservice）就是对某个flow执行的，这里写的当前组件就是指业务单元（element））的状态变为进行中（ongoing）状态；若当前执行start的组件为流程（process），则触发流程（process）内所有开始事件（startevent）的元素开始动作（startaction）；若为用户任务（task），不执行动作；否则，触发完成任务（completeaction）；所述执行完成模块（docomplete）用于获取并执行所述元素完成动作，检查当前组件是否满足完成条件：若当前组件存在未完成的返回流（returnflow），则不允许执行完成动作，未完成的返回流（returnflow）表示已经调用，但还未返回结果；还用于检查业务单元（element）的参数，若参数设置为必填required，检查业务单元（element）的上下文（context）中是否存在对应的参数，若不存在则报错；若当前组件为结束事件（endevent），则触发所在流程的元素完成动作（completeaction）；若当前组件为流程（process），则触发流程内所有未完成的组件的元素取消动作（cancelaction），并触发当前组件所有的输出流（outgoingflow）的流激活动作（activateaction）；若当前组件为通知事件（notificationevent），则将当前组件的上下文（context）发送到消息组（messagegroup）中；还用于把当前组件的状态变成已完成（finished）；还用于判断当前组件是否为主流程，若是则触发临床试验开始动作（trialendaction）；还用于触发当前组件所有的输出流（outgoingflow）的流激活动作（activateaction）；所述执行调用模块（doinvoke）用于获取并执行所述元素调用动作，将调用（invoke）动作传递的变量与调用流（invokeflow）的上游组件（指invokeflow的上游组件，所有的流（flow）都是从一个业务单元（element）流到另一个业务单元（element）的，比如从a到b。那么a就是这个流（flow）的上游，b是下游）的上下文（context）合并，作为调用的流程的上下文（context）；还用于创建调用流（invokeflow）和对应的返回流（returnflow），递归创建流程中的组件及流；还用于触发调用流（invokeflow）的流激活动作（activateaction）；所述执行撤回模块（dowithdraw）用于执行需撤回的流程的元素撤回动作（withdrawaction）；所述执行退回模块（doreject）用于执行需退回的流程的元素退回动作（withdrawaction）；所述执行取消模块（docancel）用于获取并执行所述元素取消动作，判断出本次元素取消动作（cancelaction）不是强制取消，则确认是否满足取消条件：所有的输入流（inputflow）均已取消；若不满足，则跳过；还用于判断出当前组件为结束事件（endevent），则检查所在流程的所有的结束事件（endevent），若所有结束事件（endevent）均已取消，则触发所在流程的元素取消动作（cancelaction）；若当前组件为流程（process），则触发流程内所有未完成的组件的元素取消动作（cancelaction）；还用于把当前组件的状态变为取消状态（cancel）；还用于判断当前组件是否为主流程，若为主流程则触发临床试验结束动作（trialendaction）；还用于触发当前组件所有的输出流（outgoingflow）的流取消动作（cancelaction）。14.上述的一种临床试验场景的系统，其中，所述执行开始模块（dostart）用于装载流程上下文的具体方式如下：继承所在流程的上下文；检查当前业务单元（element）上定义的参数，若有定义默认值，则创建默认值；若当前组件为等待事件（waitingevent），则从对应的消息组（messagegroup）中读取消息，跳过下一步；将所有的输入流（inputflow）排序，按照顺序流（sequenceflow）、调用流（invokeflow）、消息流（messageflow）、返回流（returnflow）的顺序加载；对于同一类型的流，优先级越高的流越迟加载，加载时遇到同名的变量会自动覆盖，所以优先级高的需要迟加载。15.上述的一种临床试验场景的系统，其中，所述流动作执行服务模块包含执行激活模块（doactivate）、执行撤回模块（dowithdraw）、执行取消模块（docancel）；所述执行激活模块（doactivate）用于获取并执行所述流激活动作，从上游的上下文（context）中取出流（flow）上定义的交付参数，存放在当前流（flow）的上下文（context）中，若存在required的参数的值为null的情况，则报错；还用于把当前流（flow）的状态变为激活状态（active）；还用于触发下游的元素开始动作（startaction）；所述执行撤回模块（dowithdraw）用于获取并执行所述流撤回动作，把流（flow）的上游切换为进行中（ongoing）状态，把流（flow）的下游切换为等待中（pending）状态，当前流（flow）切换为撤回（withdraw）状态；所述执行取消模块（docancel）用于获取并执行所述流取消动作，把当前流（flow）切换为取消（cancel）状态；还用于触发下游的元素取消动作（cancelaction）。16.上述的一种临床试验场景的系统，其中，还包含临床试验开始动作执行（trialstartaction）模块和临床试验结束动作执行（trialendaction）模块；所述临床试验开始动作执行（trialstartaction）模块用于在临床试验开始时将主流程中的业务单元（element）和流（flow）都预先创建出来，初始都为等待中（pending）状态；所述临床试验结束动作执行（trialendaction）模块标记着临床试验的结束，用于结束整个流程。17.一次临床试验项目(project)由临床试验模型（trial）与临床试验方案（protocol）两部分组成，临床试验模型与临床试验方案之间的关系可以近似理解为函数表达式project=trial(protocol)的关系，临床试验方案（protocol）是参数，临床试验项目(project)是临床试验模型在特定临床试验方案下运行的结果，临床试验模型（trial）是一个流程（process）；流程（process）描述了临床试验中的多个业务单元及它们之间的流转关系，流程（process）是一个有向图，包含业务单元（element）与流（flow）两个部分，流（flow）是有方向的；业务单元（element）是临床试验中的业务单元的统称，以下均是临床试验的业务单元：开始事件、结束事件、通知事件、等待事件、用户任务、一次性机器人程序、可重复机器人程序、流程；业务单元（element）具有等待中（pending）、进行中（ongoing）、完成（finished)、取消（cancel）4个生命周期状态；流（flow）定义了同一个流程中的业务组件间的流转（不同流程内部的业务组件间不允许流转），从流的起点（上游组件）流向终点（下游组件），以下称一个组件的输出流（outputflow）是起点为该组件的流，类似的，输入流（inputflow）为终点为该组件的流，流是基于动作信息（action）触发的，流分为顺序流、调用流、消息流、返回流四种；流（flow）具有等待中（pending）、已激活（active）、撤回（withdraw）和取消（cancel）；业务单元（element）与流（flow）之间的流转是通过动作信息（action）来触发的，其中业务单元（element）有开始（start）、完成（complete）、调用（invoke）、撤回（withdraw）、退回（reject）、取消（cancel）几种动作信息（action）；流（flow）有激活（activate）、撤回（withdraw）、取消（cancel）几种动作信息（action）；不同的动作信息（action）有不同的执行逻辑，并且能够切换业务单元（element）与流（flow）的状态，由elementactionservice和flowactionservice两个模块实现，两个模块均会根据不同的动作信息（action）类型，执行对应的逻辑，并返回后续需要触发的动作信息（action）列表。18.第二方面，一种用于临床试验的方法，其中，包含以下步骤：步骤a1：元素动作执行服务模块内置的临床试验流程模型模块创建动作算法模型并存储在元素动作执行服务模块内；流动作执行服务模块内置的临床试验流程模型模块创建的流算法模型存储在流动作执行服务模块内；步骤a2：流程执行引擎实时监控数据存储模块内的动作消息队列是否有可消费的动作信息，并将可消费的动作信息发送至元素动作执行服务模块或流动作执行服务模块；步骤a3：元素动作执行服务模块获取动作信息并依据动作算法模型执行后续操作；或者，流动作执行服务模块获取动作信息并依据流算法模型执行后续操作；步骤a4：元素动作执行服务模块将执行完的动作信息传输至数据存储模块并存储在所述数据存储模块中动作消息列队的末端；或者，流动作执行服务模块将执行完的动作信息传输至数据存储模块并存储在所述数据存储模块中动作消息列队的末端。19.上述的一种用于临床试验的方法，其中，步骤a1中，所述元素动作执行服务模块内置的临床试验流程模型模块包含业务单元分类模块；所述流动作执行服务模块内置的临床试验流程模型模块包含流转关系分类模块。上述的一种用于临床试验的方法，其中，所述业务单元分类模块将业务单元分为以下类别：开始事件（start）、结束事件、通知事件（notificationevent）、等待事件、用户任务、一次性机器人程序、可重复机器人程序、流程。20.上述的一种用于临床试验的方法，其中，所述流转关系分类模块将业务单元之间的流转关系分为以下类别：顺序流（sequenceflow）、调用流（invokeflow）、消息流（messageflow）、返回流（returnflow）。21.上述的一种用于临床试验的方法，其中，步骤a2中，所述动作信息包括以下分类：元素动作、流动作、临床试验开始动作、临床试验结束动作；所述元素动作执行服务模块获取并执行的所述元素动作包含以下几种动作：元素开始动作、元素完成动作、元素调用动作、元素撤回动作、元素退回动作、元素取消动作；所述流动作执行服务模块获取并执行所述流动作包含以下几种动作：流激活动作、流撤回动作、流取消动作；所述临床试验开始动作是在临床试验开始的时候执行的，只执行一次，触发主流程的元素开始动作；所述临床试验结束动作标记着临床试验的结束。22.上述的一种用于临床试验的方法，其中，步骤a3中，所述元素动作执行服务模块内置的所述临床试验流程模型模块创建的动作算法模型用于控制执行所述业务单元的等待中、进行中、完成、取消的任务；所述动作算法模型还用于控制执行所述业务单元的开始事件、结束事件、通知事件、等待事件、用户任务、一次性机器人程序、可重复机器人程序、流程；所述通知事件和等待事件用一个消息组的字段关联；所述通知事件用来发送消息，所述等待事件用来接收消息；所述流动作执行服务模块内置的所述临床试验流程模型模块创建的流算法模型用于控制执行所述流转单元的等待中、已激活、撤回和取消的任务；所述流算法模型还用于控制执行所述流单元的顺序流、调用流、消息流、返回流的任务。23.基于开源的bpmn的定义，将临床试验总结、归纳成计算机中可以运行的流程，进而定义出了ctdl（clinicaltrialdescriptionlanguage）；bpmn是标准的业务流程描述模型，是由bpmi(thebusinessprocessmanagementinitiative)开发了一套标准叫业务流程建模符号(bpmnꢀ‑ꢀbusinessprocessmodelingnotation)，在bpminotationworkinggroup超过2年的努力，于2004年5月对外发布了bpmn1.0规范，后bpmi并入到omg组织，omg于2011年推出bpmn2.0标准，对bpmn进行了重新定义(businessprocessmodelandnotation)；bpmn的主要目标是提供一些被所有业务用户容易理解的符号，从创建流程轮廓的业务分析到这些流程的实现，直到最终用户的管理监控，bpmn也支持提供一个内部的模型可以生成可执行的bpel4ws，因此bpmn的出现，弥补了从业务流程设计到流程开发的间隙。24.bpmn定义了一个业务流程图（businessprocessdiagram），该业务流程图基于一个流程图（flowcharting），该流程图被设计用于创建业务流程操作的图形化模型。而一个业务流程模型（businessprocessmodel），指一个由图形对象（graphicalobjects）组成的网状图，图形对象包括活动（activities)和用于定义这些活动执行顺序的流程控制器（flowcontrols），本专利申请的ctdl借鉴了bpmn的部分定义，在bpmn的基础上针对临床试验的场景做了归纳和调整；流程、元素及流等基本概念大多是借鉴bpmn的，包括子流程、事件（开始事件、结束事件）、用户任务、顺序流、消息流等。创造性的部分有：1.细分了上下文的概念,在bpmn中，没有对上下文或流程参数等运行态的概念进行定义；在某些公开的基于bpmn的流程引擎中（如activiti），对上下文的定义更多是在流程层面，类似公共盘的概念，流程中的节点都可以读取或修改这个上下文。而在临床试验的场景中，由于交付物等参数非常多，并且某些敏感信息不宜公开，只能在相关责任人中流转，需要细分出“私有空间”,在ctdl的定义中，每个元素、每个流，都具有自己的上下文（私有空间）,并且，创造性地在流上定义了交付参数信息（假设有个流f，是从业务单元a指向业务单元b的。a中定义了一个参数x，b中也定义了一个x。在没有定义交付参数的情况下，a和b中虽然都有x，但他们是没有任何联系的。此时若在f上定义了一个关于x的交付参数(delivery)，就可以把a和b中的x关联起来，表示将a中x的值传给b中的x），从而把参数从一个上下文传递到另一个上下文（传递交付物），在bpmn中并没有类似的概念。25.2.将bpmn中的消息事件及信号事件的概念合并（在临床试验的场景中，二者含义相近，故合并）,同时，将上述消息的概念拆成了两部分，定义了通知事件（用来发送消息）和等待事件（用来接收消息），分别用来处理消息的发送和接收，使得业务处理更加灵活,（普通的消息流只能在同一个流程中通信，通知事件和等待事件用一个消息组的字段关联，可以实现跨流程的一对多或多对一通信。实际的场景中，跨流程通信的例子很多，例如pm需要通知每个中心的crc（临床协调员），pm触发通知的任务是在主流程中的，crc们执行的任务是在中心子流程中的，这个例子就是一个一对多的通信；又比如，crc在中心子流程中执行完一个任务后，除了继续进行后续的任务外，还需要给pm发一个通知，发送通知的任务有很多，但接收通知的任务只有一个，这个场景就是个多对一的通信）;3.拓展了动作的概念：在某些公开的基于bpmn的流程引擎中（如activiti），只有例如“开始”、“完成”等基本的、技术层面的动作。如果直接用来解决具体的业务场景中的问题，需要将这些基本的动作进行组装,对于常用的操作，会带来大量重复且繁琐的配置工作。ctdl归纳了临床试验中常见的操作，延伸拓展了动作的概念，补充了诸如退回/撤回、调用、取消等动作，大大降低了编写和配置ctdl的难度;ctdl（clinicaltrialdescriptionlanguage,临床试验描述语言）是一种临床试验项目的定义形式，与传统的项目sop文档不同的是，ctdl可以通过ctee（clinicaltrialexecuteengine，临床试验执行引擎）执行，也更方便修改和扩展。26.依据上述本发明一种用于临床试验的系统与方法的技术方案具有一下技术效果：ctdl（临床试验描述语言），通过抽象临床试验的模型，为每个参与方分配任务，用任务间的流转关系将任务组织成流程，将传统的sop文档转化为程序可以执行、计算的语言，在运行的时候，只用传入项目参数、项目人员等信息，就可以自动复制、扩展到不同的项目上，解决了sop文档复杂、难扩展的弊端，同时，ctdl的执行引擎可以自动为每个任务排期、根据任务乃至整体项目进度，解决了传统场景下沟通协作难的问题，在bpmn的流程模型基础上，增加动作信息（action）和上下文（context）等概念，定义了一种全新的临床试验描述语言，配合临床试验执行引擎，在临床试验的场景上运用、落地。本发明可实现自动化、有效控制临床试验项目进度，简化沟通流程，降低沟通成本，大大提高了沟通效率，解决了本领域的技术难题，达到了预料不到的技术效果。附图说明27.图1为本发明一种用于临床试验的系统的结构示意图；图2为本发明一种用于临床试验的系统中元素动作执行服务模块的结构示意图；图3为本发明一种用于临床试验的系统中流动作执行服务模块的结构示意图；图4为本发明一种用于临床试验的系统具体实施例的流程图；图5为本发明一种用于临床试验的系统具体实施例中系统自动开始的流程图；图6为本发明一种用于临床试验的系统具体实施例中用户任务1提交前的图；图7为本发明一种用于临床试验的系统具体实施例中用户任务2等待中的图；图8为本发明一种用于临床试验的系统具体实施例中用户任务1完成的图；图9为本发明一种用于临床试验的系统具体实施例中用户任务2进行中的图；图10为本发明一种用于临床试验的系统具体实施例中用户任务1完成后的图；图11为本发明一种用于临床试验的系统具体实施例中流程结束的图；图12为本发明一种用于临床试验的系统真实场景的流程图；图13为本发明一种用于临床试验的系统真实场景的流程图a部的放大图；图14为本发明一种用于临床试验的系统真实场景的流程图b部的放大图；图15为本发明一种用于临床试验的系统真实场景的流程图c部的放大图；图16为本发明一种用于临床试验的系统真实场景的流程图d部的放大图；图17为本发明一种用于临床试验的系统真实场景的流程图e部的放大图；图18为本发明一种用于临床试验的系统真实场景的流程图f部的放大图；图19为流程在业务上的概念图。具体实施方式28.为了使发明实现的技术手段、创造特征、达成目的和功效易于明白了解，下结合具体图示，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。29.基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。30.须知，本说明书所附图式所绘示的结构、比例、大小等，均仅用以配合说明书所揭示的内容，以供熟悉此技术的人士了解与阅读，并非用以限定本发明可实施的限定条件，故不具技术上的实质意义，任何结构的修饰、比例关系的改变或大小的调整，在不影响本发明所能产生的功效及所能达成的目的下，均应仍落在本发明所揭示的技术内容得能涵盖的范围内。31.同时，本说明书中所引用的如“上”、“下”、“左”、“右”、“中间”及“一”等的用语，亦仅为便于叙述的明了，而非用以限定本发明可实施的范围，其相对关系的改变或调整，在无实质变更技术内容下，当亦视为本发明可实施的范畴。32.本发明的一较佳实施例是提供一种临床试验场景的系统，目的是ctdl（临床试验描述语言），通过抽象临床试验的模型，为每个参与方分配任务，用任务间的流转关系将任务组织成流程，将传统的sop文档转化为程序可以执行、计算的语言，在运行的时候，只用传入项目参数、项目人员等信息，就可以自动复制、扩展到不同的项目上，解决了sop文档复杂、难扩展的弊端，同时，ctdl的执行引擎可以自动为每个任务排期、根据任务乃至整体项目进度，解决了传统场景下沟通协作难的问题，在bpmn的流程模型基础上，增加动作信息（action）和上下文（context）等概念，定义了一种全新的临床试验描述语言，配合临床试验执行引擎，在临床试验的场景上运用、落地。33.如图1所示，第一方面，一种用于临床试验的系统，其中，包含数据存储模块（actionqueue）、流程执行引擎（workflowengine）、元素动作执行服务模块（elementactionservice）、流动作执行服务模块（flowactionservice）；所述元素动作执行服务模块与所述流动作执行服务模块内均设置有临床试验流程模型模块；所述临床试验流程模型模块用于定义临床试验中的多个业务单元（element）及它们之间的流转关系，所述元素动作执行服务模块与所述流动作执行服务模块分别根据所述临床试验流程模型模块执行任务；所述数据存储模块内存储有动作消息队列，所述动作消息队列中记载有待执行的动作信息（action）；所述流程执行引擎实时监控所述数据存储模块内是否有可消费的动作信息（action），当有动作信息（action）可消费时，所述流程执行引擎消费一条动作信息（action）并根据动作信息（action）的类型分类为元素动作和流动作分发至所述元素动作执行服务模块与所述流动作执行服务模块，分发完成后继续监听所述数据存储模块，消费下一条动作信息（action）；所述元素动作执行服务模块获取并执行所述元素动作（elementaction）；所述流动作执行服务模块获取并执行所述流动作（flowaction）;所述元素动作执行服务模块执行后的元素动作（elementaction）及所述流动作执行服务模块执行后的流动作（flowaction）传输至所述数据存储模块并存储在所述数据存储模块中动作消息列队的末端。34.其中，所述临床试验流程模型模块包含业务单元分类模块和流转关系分类模块。35.其中，element（业务单元）是临床试验中的业务单元的统称，所述业务单元分类模块将业务单元（element）分为以下类别：开始事件（startevent）、结束事件（endevent）、通知事件（notificationevent）、等待事件（waitingevent）、用户任务（task）、一次性机器人程序（disposablebot，该机器人程序只会执行一次）、可重复机器人程序（repeatablebot，该机器人程序会按照设定的时间周期，重复地执行）、流程（process）。[0036][0037]其中，所述流转关系分类模块将业务单元之间的流转关系分为以下类别：顺序流（sequenceflow）、调用流（invokeflow）、消息流（messageflow）、返回流（returnflow）。[0038]其中，所述元素动作执行服务模块内置的所述临床试验流程模型模块创建的动作算法模型用于控制执行所述业务单元的等待中（pending）、进行中（ongoing）、已完成（finished)、取消（cancel）的任务；所述动作算法模型还用于控制执行所述业务单元的开始事件（start）、结束事件、通知事件（notificationevent）、等待事件、用户任务、一次性机器人程序、可重复机器人程序、流程；所述流动作执行服务模块内置的所述临床试验流程模型模块创建的流算法模型用于控制执行所述流转单元的等待中（pending）、已激活（active）、撤回（withdraw）和取消（cancel）的任务；所述流算法模型还用于控制执行所述流单元的顺序流（sequenceflow）、调用流（invokeflow）、消息流（messageflow）、返回流（returnflow）的任务；所述业务单元内置有业务上下文（context），所述业务上下文中存储有业务参数；所述流转单元内置有流上下文（context），所述流上下文中存储有交付参数；所述动作信息包含业务开始信息、业务完成信息（complete）、业务调用信息（invoke）、业务撤回信息（withdraw）、业务退回信息（reject）、业务取消信息（cancel）、流激活信息（activate）。[0039]上述的一种临床试验场景的系统，其中，参数包含临床试验中使用到模板、产生的交付物、或临床试验执行引擎（ctee，即clinicaltrialexecuteengine）执行过程中的临时变量、或ctdl中农定义的参数等，临床试验执行引擎的核心是基于actionqueue，通过不停地消费动作信息（action），执行对应的动作，触发后续的动作，达到流程自动化的效；所述业务参数包含文件、文件目录、数字、日期、时间、文本、布尔、列表、确认列表、用户列表；所述交付参数包含文件、文件目录、数字、日期、时间、文本、布尔、列表、确认列表、用户列表；与传统的流程引擎不同，ctdl并不是让一个流程中的所有节点都共享一个参数域，而是让每个业务单元（element）都拥有各自的上下文（context），上下文中存放着运行所需的参数；业务单元（element）与业务单元（element）之间的参数传递是由ctee根据流（flow）上的参数定义自动进行传递的；流（flow）也有自己的上下文（context），流（flow）在被触发的时候，会先根据参数定义，从上游的上下文（context）中将对应的参数取出来，放到自己的上下文（context）里，待下游组件可以开始的时候（满足开始条件），再由下游将对应的参数从流（flow）的上下文（context）里取出装载到自己的上下文（context）里；这样把上下文（context）在流上暂存的做法，相比直接把变量从上游传给下游，有几点好处：1.当一个组件存在多个输入流（incomingflow）的时候，方便人为设置流加载的顺序（根据优先级，而不是时间顺序）；2.若下游组件运行出错，方便进行回滚；特别的，为了方便处理、简化ctdl定义，每个组件的上下文会自动继承其所在流程的上下文（所在的流程在其被创建的时候，亦会自动继承父流程的上下文）；制定计划：ctdl的一个很主要的功能是可以为临床试验项目制订计划，帮助pm合理安排时间、把控项目进度，在ctdl中定义了若干的时间约束条件，如下：业务单元（element）的计划开始时间不早于项目的计划开始时间；业务单元（element）的计划开始时间不早于其incomingsequenceflow的上游业务单元（element）的计划结束时间；业务单元（element）的计划开始时间不早于其incominginvokeflow的上游业务单元（element）的计划开始时间；startevent的开始时间等于所在流程的开始时间；业务单元（element）的计划结束时间不早于其计划开始时间 计划周期；业务单元（element）的计划结束时间不早于其incomingreturnflow的上游业务单元（element）的计划结束时间；流程（process）的计划结束时间不早于其中的任何一个endevent的计划结束时间；初始时，将所有主流程的计划开始时间和计划结束时间设置为项目的开始实际，然后把主流程的所有startevent加入队列中，开始执行下列步骤：步骤d1：取出队列头部的业务单元（element），根据上述依赖条件，计算任务的计划时间；步骤d2：若计划时间未发生变化，则跳过；否则：步骤d3：沿着当前业务单元（element）的outgoingflow，把后续的业务单元（element）加入队列中，特别地，endevent没有outgoingflow，需要特殊处理，把其归属的流程（process）加入队列中；步骤d4：回到步骤d1，持续迭代更新，直到队列为空。[0040]动态调整：以下情况出现时，会触发计划的动态调整：创建一个新的实例，人工调整了业务单元（element）的计划；动态调整策略：与上述的初始化计划时间的步骤相同，区别是一开始只把对应的业务单元（element）加入队列中。[0041]如图2所示，上述的一种临床试验场景的系统，其中，所述元素动作执行服务模块包含执行开始模块（dostart）、执行完成模块（docomplete）、执行调用模块（doinvoke）、执行撤回模块（dowithdraw）、执行退回模块（doreject）、执行取消模块（docancel）；所述执行开始模块（dostart）用于获取并执行所述元素开始动作，检查输入依赖是否满足每个定义的输入顺序流（incomingsequenceflow）都被触发或被取消，若不满足，跳过处理；还用于装载流程上下文；还用于把当前组件(所有的动作信息（action）都是对某个对象执行的,elementaction就是对某个业务单元（element）执行的，flowaction就是对某个flow执行的，这里写的当前组件就是指业务单元（element））的状态变为进行中（ongoing）状态；若当前执行start的组件为流程（process），则触发流程（process）内所有开始事件（startevent）的元素开始动作（startaction）；若为用户任务（task），不执行动作；否则，触发完成任务（completeaction）；所述执行完成模块（docomplete）用于获取并执行所述元素完成动作，检查当前组件是否满足完成条件：若当前组件存在未完成的返回流（returnflow），则不允许执行完成动作，未完成的返回流（returnflow）表示已经调用，但还未返回结果；还用于业务单元（element）的检查参数，若参数设置为必填（required），检查业务单元（element）的上下文（context）中是否存在对应的参数，若不存在则报错；若当前组件为结束事件（endevent），则触发所在流程的元素完成动作（completeaction）；若当前组件为流程（process），则触发流程内所有未完成的组件的元素取消动作（cancelaction），并触发当前组件所有的输出流（outgoingflow）的流激活动作（activateaction）；若当前组件为通知事件（notificationevent），则将当前组件的上下文（context）发送到消息组（messagegroup）中；还用于把当前组件的状态变成已完成（finished）；还用于判断当前组件是否为主流程，若是则触发临床试验开始动作（trialendaction）；还用于触发当前组件所有的输出流（outgoingflow）的流激活动作（activateaction）；所述执行调用模块（doinvoke）模块用于获取并执行所述元素调用动作，将调用（invoke）动作传递的变量与调用流（invokeflow）的上游组件（指invokeflow的上游组件，所有的流（flow）都是从一个业务单元（element）流到另一个业务单元（element）的，比如从a到b。那么a就是这个流（flow）的上游，b是下游）的上下文（context）合并，作为调用的流程的上下文（context）；还用于创建调用流（invokeflow）和对应的returnflow，递归创建流程中的组件及流；还用于触发调用流（invokeflow）的流激活动作（activateaction）；所述执行撤回模块（dowithdraw）用于执行需撤回的流程的元素撤回动作（withdrawaction）；所述执行退回模块（doreject）模块用于执行需退回的流程的元素退回动作（withdrawaction）；所述执行取消模块（docancel）用于获取并执行所述元素取消动作，判断出本次元素取消动作（cancelaction）不是强制取消，则确认是否满足取消条件：所有的输入流（inputflow）均已取消；若不满足，则跳过；还用于判断出当前组件为结束事件（endevent），则检查所在流程的所有的结束事件（endevent），若所有结束事件（endevent）均已取消，则触发所在流程的元素取消动作（cancelaction）；若当前组件为流程（process），则触发流程内所有未完成的组件的元素取消动作（cancelaction）；还用于把当前组件的状态变为取消（cancel）状态；还用于判断当前组件是否为主流程，若为主流程则触发临床试验结束动作（trialendaction）；还用于触发当前组件所有的输出流（outgoingflow）的流取消动作（cancelaction）。[0042]上述的一种临床试验场景的系统，其中，所述执行开始模块（dostart）用于装载流程上下文的具体方式如下：继承所在流程的上下文；检查当前element上定义的参数，若有定义默认值，则创建默认值；若当前组件为等待事件（waitingevent），则从对应的消息组（messagegroup）中读取消息，跳过下一步；将所有的输入流（inputflow）排序，按照顺序流（sequenceflow）、调用流（invokeflow）、消息流（messageflow）、返回流（returnflow）的顺序加载；对于同一类型的流，优先级越高的流越迟加载，加载时遇到同名的变量会自动覆盖，所以优先级高的需要迟加载。[0043]如图3所示，上述的一种临床试验场景的系统，其中，所述流动作执行服务模块包含执行激活模块（doactivate）、执行撤回模块（dowithdraw）、执行取消模块（docancel）；所述执行激活模块（doactivate）用于获取并执行所述流激活动作，从上游的上下文（context）中取出流（flow）上定义的交付参数，存放在当前流（flow）的上下文（context）中，若存在required的参数的值为null的情况，则报错；还用于把当前流（flow）的状态变为激活状态（active）；还用于触发下游的元素开始动作（startaction）；所述执行撤回模块（dowithdraw）用于获取并执行所述流撤回动作，把流（flow）的上游切换为进行中（ongoing）状态，把流（flow）的下游切换为等待中（pending）状态，当前流（flow）切换为撤回（withdraw）状态；所述执行取消模块（docancel）用于获取并执行所述流取消动作，把当前流（flow）切换为取消（cancel）状态；还用于触发下游的元素取消动作（cancelaction）。[0044]上述的一种临床试验场景的系统，其中，还包含临床试验开始动作执行（trialstartaction）模块和临床试验结束动作执行（trialendaction）模块；所述临床试验开始动作执行（trialstartaction）模块用于在临床试验开始时将主流程中的业务单元（element）和流（flow）都预先创建出来，初始都为等待中（pending）状态；所述临床试验结束动作执行（trialendaction）模块标记着临床试验的结束，用于结束整个流程。[0045]如图19所示，一次临床试验项目(project)由临床试验模型（trial）与临床试验方案（protocol）两部分组成，临床试验模型与临床试验方案之间的关系可以近似理解为函数表达式project=trial(protocol)的关系，临床试验方案（protocol）是参数，临床试验项目(project)是临床试验模型在特定临床试验方案下运行的结果，临床试验模型（trial）是一个流程（process）；流程（process）描述了临床试验中的多个业务单元及它们之间的流转关系，流程（process）是一个有向图，包含业务单元（element）与流（flow）两个部分，流（flow）是有方向的；业务单元（element）是临床试验中的业务单元的统称，以下均是临床试验的业务单元：开始事件、结束事件、通知事件、等待事件、用户任务、一次性机器人程序、可重复机器人程序、流程；业务单元（element）具有等待中（pending）、进行中（ongoing）、完成（finished)、取消（cancel）4个生命周期状态；流（flow）定义了同一个流程中的业务组件间的流转（不同流程内部的业务组件间不允许流转），从流的起点（上游组件）流向终点（下游组件），以下称一个组件的输出流（outputflow）是起点为该组件的流，类似的，输入流（inputflow）为终点为该组件的流，流是基于动作信息（action）触发的，流分为顺序流、调用流、消息流、返回流四种；流（flow）具有等待中（pending）、已激活（active）、撤回（withdraw）和取消（cancel）；业务单元（element）与流（flow）之间的流转是通过动作信息（action）来触发的，其中业务单元（element）有开始（start）、完成（complete）、调用（invoke）、撤回（withdraw）、退回（reject）、取消（cancel）几种动作信息（action）；流（flow）有激活（activate）、撤回（withdraw）、取消（cancel）几种动作信息（action）；不同的动作信息（action）有不同的执行逻辑，并且能够切换业务单元（element）与流（flow）的状态，由elementactionservice和flowactionservice两个模块实现，两个模块均会根据不同的动作信息（action）类型，执行对应的逻辑，并返回后续需要触发的动作信息（action）列表。[0046]第二方面，如图1所示，本发明提供一种用于临床试验系统的实现方法，其中，包含以下步骤：步骤a1：元素动作执行服务模块内置的临床试验流程模型模块创建动作算法模型并存储在元素动作执行服务模块内；流动作执行服务模块内置的临床试验流程模型模块创建的流算法模型存储在流动作执行服务模块内；步骤a2：流程执行引擎实时监控数据存储模块内的动作消息队列是否有可消费的动作信息，并将可消费的动作信息发送至元素动作执行服务模块或流动作执行服务模块；步骤a3：元素动作执行服务模块获取动作信息并依据动作算法模型执行后续操作；或者，流动作执行服务模块获取动作信息并依据流算法模型执行后续操作；步骤a4：元素动作执行服务模块将执行完的动作信息传输至数据存储模块并存储在所述数据存储模块中动作消息列队的末端；或者，流动作执行服务模块将执行完的动作信息传输至数据存储模块并存储在所述数据存储模块中动作消息列队的末端。[0047]一个具体实施例如下：如图4所示，这个流程图描述了一个简单的提交材料、审核材料的流程，由crc收集并提交材料，再由pm对材料进行审核；在task1中，定义了两个参数，一个参数task1_file_template，用来展示信息收集表的模板，参数类型是file，并且是不可编辑的（editable为false）；另一个参数是task1_file，是crc基于模板补充必要的信息后，上传的交付物，该参数同样为file类型，是可编辑的（editable为true），且为必须的（required为true）；task2是pm的审核任务，只有一个参数，task1_file，这个参数是需要从task1传过来的，因此设置的是不可编辑的；在task1和task2之间的sequenceflow上，定义了task1_file的传递（如下的delivery信息）；系统动作详解：1.对于上面的样例，项目初始化的时候，会默认创建如下内容，并且他们的状态都是pending：element：mainprocess项目主流程pending；startevent开始节点pending；task1用户任务1pending；task2用户任务2pending；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1pending；flow2顺序流，用户任务1——用户任务2pending；flow3顺序流，用户任务2——结束节点pending；2.执行项目的“启动”后，系统会添加一个trialstartaction到动作队列中，上文提到，trialstartaction是一个特殊处理的动作，会触发主流程的elementstartaction（添加到动作队列，此时动作队列中只有这一个action）；3.流程引擎从动作队列中取出一个动作（主流程的elementstartaction），根据其类型，自动转交给elementactionservice执行，elementactionservice会执行dostart模块。根据上文的定义，会触发主流程中所有startevent的elementstartaction（这个样例中只有一个startevent，添加到队列中），这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点pending；task1用户任务1pending；task2用户任务2pending；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1pending；flow2顺序流，用户任务1——用户任务2pending；flow3顺序流，用户任务2——结束节点pending；4.流程引擎继续从动作队列取出动作进行处理，此时执行的是startevent的elementstartaction（主流程的elementstartaction已经被消费了）；继续转交给elementactionservice执行，elementactionservice会执行dostart模块；根据上文的定义，会触发这个startevent的elementcompleteaction；这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点ongoing；task1用户任务1pending；task2用户任务2pending；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1pending；flow2顺序流，用户任务1——用户任务2pending；flow3顺序流，用户任务2——结束节点pending；5.流程引擎继续从动作队列取出动作进行处理，此时执行的是startevent的elementcompleteaction；转交给elementactionservice执行，elementactionservice会执行docomplete模块；根据上文的定义，会触发这个startevent后续的流的flowactivateaction（对应flow1的flowactivateaction）；这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1pending；task2用户任务2pending；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1pending；flow2顺序流，用户任务1——用户任务2pending；flow3顺序流，用户任务2——结束节点pending；6.流程引擎继续从动作队列取出动作进行处理，此时执行的是flow1的flowactivateaction；转交给flowactionservice执行，flowactionservice会执行doactivate模块；由于flow1上未定义任何交付参数，直接触发该流的下游（task1）的elementstartaction。这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1pending；task2用户任务2pending；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2pending；flow3顺序流，用户任务2——结束节点pending；7.流程引擎继续从动作队列取出动作进行处理，此时执行的是task1的elementstartaction，转交给elementactionservice执行，elementactionservice会执行dostart模块，由于该任务类型是task，需要等待用户响应，不会自动触发elementcompleteaction，这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1ongoing；task2用户任务2pending；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2pending；flow3顺序流，用户任务2——结束节点pending；如图5所示，至此，项目“启动”后，系统自动完成的动作结束，等待用户处理，动作队列为空，流程引擎处于等待中，在界面上，可以看到此时的流程状态如下（系统自动开始.png）；如图6所示，此时，crc用户看到的任务界面如下（用户任务1——提交前.png）；如图7所示，pm用户看到的任务界面如下（用户任务2——等待中.png）；8.crc用户提交了“信息收集表”，并点击完成，“完成”接口会触发task1的elementcompleteaction，将其添加到任务队列；9.流程引擎继续停止等待，从动作队列取出动作进行处理，此时执行的是task1的elementcompleteaction，转交给elementactionservice执行，elementactionservice会执行docomplete模块，根据上文定义，会触发flow2的flowactivateaction，这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1finished；task2用户任务2pending；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2pending；flow3顺序流，用户任务2——结束节点pending；10.流程引擎继续从动作队列取出动作进行处理，此时执行的是flow2的flowactivateaction；转交给flowactionservice执行，flowactionservice会执行doactivate模块；flow2上定义了一个交付参数——task1_file，doactivate会从流的上游（task1）的上下文中取出这个参数（task1_file），暂存在flow2的上下文中，并触发该流的下游（task2）的elementstartaction。这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1finished；task2用户任务2pending；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2activate；flow3顺序流，用户任务2——结束节点pending；11.流程引擎继续从动作队列取出动作进行处理，此时执行的是task2的elementstartaction，转交给elementactionservice执行，elementactionservice会执行dostart模块，根据上文定义，dostart会从所有的输入流（inputflow）中按照优先级加载上下文（此例子中只有一个输入流（inputflow）一个参数），将task1_file从flow2的上下文中取出，加载到task2的上下文中，同样，由于该任务类型是task，需要等待用户响应，不会自动触发elementcompleteaction，这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1finished；task2用户任务2ongoing；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2activate；flow3顺序流，用户任务2——结束节点pending；至此，crc上传文件，并完成用户任务1后，系统自动完成的动作结束，等待用户处理。动作队列为空，流程引擎处于等待中；如图8所示，此时crc用户的任务界面如下（用户任务1——完成.png）；如图9所示，pm用户的任务界面如下（用户任务2——进行中.png）；如图10所示，流程状态如下（用户任务1完成后.png）；12.pm完成了审批，点击完成，会触发task2的elementcompleteaction，将其添加到任务队列；13.流程引擎继续停止等待，从动作队列取出动作进行处理，此时执行的是task2的elementcompleteaction，转交给elementactionservice执行，elementactionservice会执行docomplete模块，根据上文定义，会触发flow3的flowactivateaction，这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1finished；task2用户任务2finished；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2activate；flow3顺序流，用户任务2——结束节点pending；14.流程引擎继续从动作队列取出动作进行处理，此时执行的是flow3的flowactivateaction，转交给flowactionservice执行，flowactionservice会执行doactivate模块，最终触发该流的下游（endevent）的elementstartaction。这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1finished；task2用户任务2finished；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2activate；flow3顺序流，用户任务2——结束节点activate；15.流程引擎继续从动作队列取出动作进行处理，此时执行的是task3的elementstartaction，转交给elementactionservice执行，elementactionservice会执行dostart模块，根据上文中的定义，dostart模块会自动触发endevent的elementcompleteaction，这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1finished；task2用户任务2finished；endevent结束节点ongoing；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2activate；flow3顺序流，用户任务2——结束节点activate；16.流程引擎继续从动作队列取出动作进行处理，此时执行的是task3的elementcompleteaction，转交给elementactionservice执行，elementactionservice会执行docomplete模块，根据上文中的定义，docomplete模块会自动触发endevent所在流程（即主流程）的elementcompleteaction，这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1finished；task2用户任务2finished；endevent结束节点finished；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2activate；flow3顺序流，用户任务2——结束节点activate；16.流程引擎继续从动作队列取出动作进行处理，此时执行的是mainprocess的elementcompleteaction，转交给elementactionservice执行，elementactionservice会执行docomplete模块，特殊的，主流程完成后会触发trialendaction，这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程finished；startevent开始节点finished；task1用户任务1finished；task2用户任务2finished；endevent结束节点finished；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2activate；flow3顺序流，用户任务2——结束节点activate；如图11所示，17.流程引擎接收到trialendaction，结束流程（流程结束.png）；如图12-18所示，真实场景比上面的例子要复杂得多得多，以下是一个真实场景中某个阶段的流程图（真实场景流程图.png）。[0048]综上，本发明的一种用于临床试验的系统与方法，ctdl（临床试验描述语言），通过抽象临床试验的模型，为每个参与方分配任务，用任务间的流转关系将任务组织成流程，将传统的sop文档转化为程序可以执行、计算的语言，在运行的时候，只用传入项目参数、项目人员等信息，就可以自动复制、扩展到不同的项目上，解决了sop文档复杂、难扩展的弊端，同时，ctdl的执行引擎可以自动为每个任务排期、根据任务乃至整体项目进度，解决了传统场景下沟通协作难的问题，在bpmn的流程模型基础上，增加动作信息（action）和上下文（context）等概念，定义了一种全新的临床试验描述语言，配合临床试验执行引擎，在临床试验的场景上运用、落地。[0049]以上对发明的具体实施例进行了描述。需要理解的是，发明并不局限于上述特定实施方式，其中未尽详细描述的设备和结构应该理解为用本领域中的普通方式予以实施；本领域技术人员可以在权利要求的范围内做出各种变形或修改做出若干简单推演、变形或替换，这并不影响发明的实质内容。当前第1页12当前第1页12
背景技术：
：：2.在临床试验的场景中，往往需要pm（临床试验项目经理）制定项目sop（标准操作程序），临床项目的项目大都十分复杂，中间设计多个参与方，各个参与方的分工和协作都需要pm来协调处理，十分考验pm的经验，因此，以往的临床试验非常依赖pm的能力和经验，一旦pm人员发生变动，项目交接十分困难，另一方面，不同的临床试验项目，在一些细节的场景上或多或少都存在需要特殊处理的情况，项目方难以从一个成功执行的项目复制到另一个项目上；另外，在传统的场景中，各个参与方之间的协作大多是通过人员间的线上或线下沟通，pm需要定期召开项目会议，或逐个询问参与方进度，来把控项目的整体进度，存在沟通费事费力、时效性差等问题，项目进度难以有效把控；目前，在临床试验领域缺少一种可自动化控制的系统，来有效控制临床试验项目进度，简化沟通流程，降低沟通成本。技术实现要素：3.本发明要解决的技术问题是现有的场景中，存在沟通费时费力、时效性差等问题，项目进度难以有效把控，本发明提供一种用于临床试验的系统，ctdl（临床试验描述语言），通过抽象临床试验的模型，为每个参与方分配任务，用任务间的流转关系将任务组织成流程，将传统的sop文档转化为程序可以执行、计算的语言，在运行的时候，只用传入项目参数、项目人员等信息，就可以自动复制、扩展到不同的项目上，解决了sop文档复杂、难扩展的弊端，同时，ctdl的执行引擎可以自动为每个任务排期、根据任务乃至整体项目进度，解决了传统场景下沟通协作难的问题，在bpmn的流程模型基础上，增加动作信息（action）和上下文（context）等概念，定义了一种全新的临床试验描述语言，配合临床试验执行引擎，在临床试验的场景上运用、落地，用以解决现有技术导致的缺陷。4.本发明还提供一种用于临床试验的方法。5.为解决上述技术问题，本发明提供以下的技术方案：第一方面，一种用于临床试验的系统，其中，包含数据存储模块（actionqueue）、流程执行引擎（workflowengine）、元素动作执行服务模块（elementactionservice）、流动作执行服务模块（flowactionservice）；所述元素动作执行服务模块与所述流动作执行服务模块内均设置有临床试验流程模型模块；所述临床试验流程模型模块用于定义临床试验中的多个业务单元（element）及它们之间的流转关系，所述元素动作执行服务模块与所述流动作执行服务模块分别根据所述临床试验流程模型模块执行任务；所述数据存储模块内存储有动作消息队列，所述动作消息队列中记载有待执行的动作信息（action）；所述流程执行引擎实时监控所述数据存储模块内是否有可消费的动作信息（action），当有动作信息（action）可消费时，所述流程执行引擎消费一条动作信息（action）并根据动作信息（action）的类型分类为元素动作和流动作分发至所述元素动作执行服务模块与所述流动作执行服务模块，分发完成后继续监听所述数据存储模块，消费下一条动作信息（action）；所述元素动作执行服务模块获取并执行所述元素动作；所述流动作执行服务模块获取并执行所述流动作；所述元素动作执行服务模块执行后的元素动作及所述流动作执行服务模块执行后的流动作传输至所述数据存储模块并存储在所述数据存储模块中动作消息列队的末端。6.上述的一种临床试验场景的系统，其中，所述元素动作执行服务模块内设置的临床试验流程模型模块包含业务单元分类模块；所述流动作执行服务模块内设置的临床试验流程模型模块包含流转关系分类模块。7.上述的一种临床试验场景的系统，其中，element（业务单元）是临床试验中的业务单元的统称，所述业务单元分类模块将业务单元（element）分为以下类别：开始事件（startevent）、结束事件（endevent）、通知事件（notificationevent）、等待事件（waitingevent）、用户任务（task）、一次性机器人程序（disposablebot，该机器人程序只会执行一次）、可重复机器人程序（repeatablebot，该机器人程序会按照设定的时间周期，重复地执行）、流程（process）。8.上述的一种临床试验场景的系统，其中，flow（流）定义了同一个流程中的业务组件间的流转（不同流程内部的业务组件间不允许流转），从流的起点（上游组件）流向终点（下游组件）。以下称一个组件的outputflow（输出流）是起点为该组件的流，类似的，inputflow（输入流）为终点为该组件的流。流是基于动作信息（action）触发的。所述流转关系分类模块将业务单元之间的流转关系即流转单元分为以下类别：顺序流（sequenceflow）、调用流（invokeflow）、消息流（messageflow）、返回流（returnflow）。9.上述的一种临床试验场景的系统，其中，所述元素动作执行服务模块内置的所述临床试验流程模型模块创建的动作算法模型用于控制执行所述业务单元的等待中（pending）、进行中（ongoing）、已完成（finished)、取消（cancel）的任务；所述动作算法模型还用于控制执行所述业务单元的开始事件（start）、结束事件、通知事件（notificationevent）、等待事件、用户任务、一次性机器人程序、可重复机器人程序、流程；所述通知事件和等待事件用一个消息组的字段关联；所述通知事件用来发送消息，所述等待事件用来接收消息；所述流动作执行服务模块内置的所述临床试验流程模型模块创建的流算法模型用于控制执行所述流转单元的等待中（pending）、已激活（active）、撤回（withdraw）和取消（cancel）的任务；所述流算法模型还用于控制执行所述流单元的顺序流（sequenceflow）、调用流（invokeflow）、消息流（messageflow）、返回流（returnflow）的任务；所述业务单元内置有业务上下文（context），所述业务上下文中存储有业务参数；所述流转单元内置有流上下文（context），所述流上下文中存储有交付参数；上下文（context）是参数的集合，业务单元（element）里有业务上下文，业务上下文里有多个业务参数；流转单元里有流上下文；流上下文里有交付参数；所述动作信息包括以下分类：元素动作、流动作、临床试验开始动作、临床试验结束动作；所述元素动作执行服务模块获取并执行的所述元素动作包含以下几种动作：元素开始动作、元素完成动作、元素调用动作、元素撤回动作、元素退回动作、元素取消动作；所述流动作执行服务模块获取并执行所述流动作包含以下几种动作：流激活动作、流撤回动作、流取消动作；所述临床试验开始动作是在临床试验开始的时候执行的，只执行一次，触发主流程的元素开始动作；所述临床试验结束动作标记着临床试验的结束。10.上述的一种临床试验场景的系统，其中，参数包含临床试验中使用到模板、产生的交付物、或临床试验执行引擎（ctee，clinicaltrialexecuteengine）执行过程中的临时变量、或ctdl中定义的参数等，临床试验执行引擎的核心是基于actionqueue，通过不停地消费动作信息（action），执行对应的动作，触发后续的动作，达到流程自动化的效；所述业务参数包含文件、文件目录、数字、日期、时间、文本、布尔、列表、确认列表、用户列表；所述交付参数包含文件、文件目录、数字、日期、时间、文本、布尔、列表、确认列表、用户列表；其中，布尔（boolean）是计算机中的一种数据结构，只有真（true）和假（false）两种值。11.与传统的流程引擎不同，ctdl并不是让一个流程中的所有节点都共享一个参数域，而是让每个业务单元（element）都拥有各自的上下文（context），上下文中存放着运行所需的参数；业务单元（element）与业务单元（element）之间的参数传递是由ctee根据流（flow）上的参数定义自动进行传递的；流（flow）也有自己的上下文（context），流（flow）在被触发的时候，会先根据参数定义，从上游的上下文（context）中将对应的参数取出来，放到自己的上下文（context）里，待下游组件可以开始的时候（满足开始条件），再由下游将对应的参数从流（flow）的上下文（context）里取出装载到自己的上下文（context）里；这样把上下文（context）在流上暂存的做法，相比直接把变量从上游传给下游，有几点好处：1.当一个组件存在多个输入流（incomingflow）的时候，方便人为设置流加载的顺序（根据优先级，而不是时间顺序）；2.若下游组件运行出错，方便进行回滚；特别的，为了方便处理、简化ctdl定义，每个组件的上下文会自动继承其所在流程的上下文（所在的流程在其被创建的时候，亦会自动继承父流程的上下文）；制定计划：ctdl的一个很主要的功能是可以为临床试验项目制订计划，帮助pm合理安排时间、把控项目进度，在ctdl中定义了若干的时间约束条件，如下：业务单元（element）的计划开始时间不早于项目的计划开始时间；业务单元（element）的计划开始时间不早于其incomingsequenceflow的上游业务单元（element）的计划结束时间；业务单元（element）的计划开始时间不早于其incominginvokeflow的上游业务单元（element）的计划开始时间；startevent的开始时间等于所在流程的开始时间；业务单元（element）的计划结束时间不早于其计划开始时间 计划周期；业务单元（element）的计划结束时间不早于其incomingreturnflow的上游业务单元（element）的计划结束时间；流程（process）的计划结束时间不早于其中的任何一个endevent的计划结束时间；初始时，将所有主流程的计划开始时间和计划结束时间设置为项目的开始实际，然后把主流程的所有startevent加入队列中，开始执行下列步骤：步骤d1：取出队列头部的业务单元（element），根据上述依赖条件，计算任务的计划时间；步骤d2：若计划时间未发生变化，则跳过；否则：步骤d3：沿着当前业务单元（element）的outgoingflow，把后续的业务单元（element）加入队列中，特别地，endevent没有outgoingflow，需要特殊处理，把其归属的流程（process）加入队列中；步骤d4：回到步骤d1，持续迭代更新，直到队列为空。12.动态调整：以下情况出现时，会触发计划的动态调整：创建一个新的实例，人工调整了业务单元（element）的计划；动态调整策略：与上述的初始化计划时间的步骤相同，区别是一开始只把对应的业务单元（element）加入队列中。13.上述的一种临床试验场景的系统，其中，所述元素动作执行服务模块包含执行开始模块（dostart）、执行完成模块（docomplete）、执行调用模块（doinvoke）、执行撤回模块（dowithdraw）、执行退回模块（doreject）、执行取消模块（docancel）；所述执行开始模块（dostart）获取并执行所述元素开始动作，用于检查输入依赖是否满足每个定义的输入序列流（incomingsequenceflow）都被触发或被取消，若不满足，跳过处理；还用于装载流程上下文；还用于把当前组件(所有的动作信息（action）都是对某个对象执行的,元素动作执行服务模块（elementactionservice）就是对某个业务单元（element）执行的，流动作执行服务模块（flowactionservice）就是对某个flow执行的，这里写的当前组件就是指业务单元（element））的状态变为进行中（ongoing）状态；若当前执行start的组件为流程（process），则触发流程（process）内所有开始事件（startevent）的元素开始动作（startaction）；若为用户任务（task），不执行动作；否则，触发完成任务（completeaction）；所述执行完成模块（docomplete）用于获取并执行所述元素完成动作，检查当前组件是否满足完成条件：若当前组件存在未完成的返回流（returnflow），则不允许执行完成动作，未完成的返回流（returnflow）表示已经调用，但还未返回结果；还用于检查业务单元（element）的参数，若参数设置为必填required，检查业务单元（element）的上下文（context）中是否存在对应的参数，若不存在则报错；若当前组件为结束事件（endevent），则触发所在流程的元素完成动作（completeaction）；若当前组件为流程（process），则触发流程内所有未完成的组件的元素取消动作（cancelaction），并触发当前组件所有的输出流（outgoingflow）的流激活动作（activateaction）；若当前组件为通知事件（notificationevent），则将当前组件的上下文（context）发送到消息组（messagegroup）中；还用于把当前组件的状态变成已完成（finished）；还用于判断当前组件是否为主流程，若是则触发临床试验开始动作（trialendaction）；还用于触发当前组件所有的输出流（outgoingflow）的流激活动作（activateaction）；所述执行调用模块（doinvoke）用于获取并执行所述元素调用动作，将调用（invoke）动作传递的变量与调用流（invokeflow）的上游组件（指invokeflow的上游组件，所有的流（flow）都是从一个业务单元（element）流到另一个业务单元（element）的，比如从a到b。那么a就是这个流（flow）的上游，b是下游）的上下文（context）合并，作为调用的流程的上下文（context）；还用于创建调用流（invokeflow）和对应的返回流（returnflow），递归创建流程中的组件及流；还用于触发调用流（invokeflow）的流激活动作（activateaction）；所述执行撤回模块（dowithdraw）用于执行需撤回的流程的元素撤回动作（withdrawaction）；所述执行退回模块（doreject）用于执行需退回的流程的元素退回动作（withdrawaction）；所述执行取消模块（docancel）用于获取并执行所述元素取消动作，判断出本次元素取消动作（cancelaction）不是强制取消，则确认是否满足取消条件：所有的输入流（inputflow）均已取消；若不满足，则跳过；还用于判断出当前组件为结束事件（endevent），则检查所在流程的所有的结束事件（endevent），若所有结束事件（endevent）均已取消，则触发所在流程的元素取消动作（cancelaction）；若当前组件为流程（process），则触发流程内所有未完成的组件的元素取消动作（cancelaction）；还用于把当前组件的状态变为取消状态（cancel）；还用于判断当前组件是否为主流程，若为主流程则触发临床试验结束动作（trialendaction）；还用于触发当前组件所有的输出流（outgoingflow）的流取消动作（cancelaction）。14.上述的一种临床试验场景的系统，其中，所述执行开始模块（dostart）用于装载流程上下文的具体方式如下：继承所在流程的上下文；检查当前业务单元（element）上定义的参数，若有定义默认值，则创建默认值；若当前组件为等待事件（waitingevent），则从对应的消息组（messagegroup）中读取消息，跳过下一步；将所有的输入流（inputflow）排序，按照顺序流（sequenceflow）、调用流（invokeflow）、消息流（messageflow）、返回流（returnflow）的顺序加载；对于同一类型的流，优先级越高的流越迟加载，加载时遇到同名的变量会自动覆盖，所以优先级高的需要迟加载。15.上述的一种临床试验场景的系统，其中，所述流动作执行服务模块包含执行激活模块（doactivate）、执行撤回模块（dowithdraw）、执行取消模块（docancel）；所述执行激活模块（doactivate）用于获取并执行所述流激活动作，从上游的上下文（context）中取出流（flow）上定义的交付参数，存放在当前流（flow）的上下文（context）中，若存在required的参数的值为null的情况，则报错；还用于把当前流（flow）的状态变为激活状态（active）；还用于触发下游的元素开始动作（startaction）；所述执行撤回模块（dowithdraw）用于获取并执行所述流撤回动作，把流（flow）的上游切换为进行中（ongoing）状态，把流（flow）的下游切换为等待中（pending）状态，当前流（flow）切换为撤回（withdraw）状态；所述执行取消模块（docancel）用于获取并执行所述流取消动作，把当前流（flow）切换为取消（cancel）状态；还用于触发下游的元素取消动作（cancelaction）。16.上述的一种临床试验场景的系统，其中，还包含临床试验开始动作执行（trialstartaction）模块和临床试验结束动作执行（trialendaction）模块；所述临床试验开始动作执行（trialstartaction）模块用于在临床试验开始时将主流程中的业务单元（element）和流（flow）都预先创建出来，初始都为等待中（pending）状态；所述临床试验结束动作执行（trialendaction）模块标记着临床试验的结束，用于结束整个流程。17.一次临床试验项目(project)由临床试验模型（trial）与临床试验方案（protocol）两部分组成，临床试验模型与临床试验方案之间的关系可以近似理解为函数表达式project=trial(protocol)的关系，临床试验方案（protocol）是参数，临床试验项目(project)是临床试验模型在特定临床试验方案下运行的结果，临床试验模型（trial）是一个流程（process）；流程（process）描述了临床试验中的多个业务单元及它们之间的流转关系，流程（process）是一个有向图，包含业务单元（element）与流（flow）两个部分，流（flow）是有方向的；业务单元（element）是临床试验中的业务单元的统称，以下均是临床试验的业务单元：开始事件、结束事件、通知事件、等待事件、用户任务、一次性机器人程序、可重复机器人程序、流程；业务单元（element）具有等待中（pending）、进行中（ongoing）、完成（finished)、取消（cancel）4个生命周期状态；流（flow）定义了同一个流程中的业务组件间的流转（不同流程内部的业务组件间不允许流转），从流的起点（上游组件）流向终点（下游组件），以下称一个组件的输出流（outputflow）是起点为该组件的流，类似的，输入流（inputflow）为终点为该组件的流，流是基于动作信息（action）触发的，流分为顺序流、调用流、消息流、返回流四种；流（flow）具有等待中（pending）、已激活（active）、撤回（withdraw）和取消（cancel）；业务单元（element）与流（flow）之间的流转是通过动作信息（action）来触发的，其中业务单元（element）有开始（start）、完成（complete）、调用（invoke）、撤回（withdraw）、退回（reject）、取消（cancel）几种动作信息（action）；流（flow）有激活（activate）、撤回（withdraw）、取消（cancel）几种动作信息（action）；不同的动作信息（action）有不同的执行逻辑，并且能够切换业务单元（element）与流（flow）的状态，由elementactionservice和flowactionservice两个模块实现，两个模块均会根据不同的动作信息（action）类型，执行对应的逻辑，并返回后续需要触发的动作信息（action）列表。18.第二方面，一种用于临床试验的方法，其中，包含以下步骤：步骤a1：元素动作执行服务模块内置的临床试验流程模型模块创建动作算法模型并存储在元素动作执行服务模块内；流动作执行服务模块内置的临床试验流程模型模块创建的流算法模型存储在流动作执行服务模块内；步骤a2：流程执行引擎实时监控数据存储模块内的动作消息队列是否有可消费的动作信息，并将可消费的动作信息发送至元素动作执行服务模块或流动作执行服务模块；步骤a3：元素动作执行服务模块获取动作信息并依据动作算法模型执行后续操作；或者，流动作执行服务模块获取动作信息并依据流算法模型执行后续操作；步骤a4：元素动作执行服务模块将执行完的动作信息传输至数据存储模块并存储在所述数据存储模块中动作消息列队的末端；或者，流动作执行服务模块将执行完的动作信息传输至数据存储模块并存储在所述数据存储模块中动作消息列队的末端。19.上述的一种用于临床试验的方法，其中，步骤a1中，所述元素动作执行服务模块内置的临床试验流程模型模块包含业务单元分类模块；所述流动作执行服务模块内置的临床试验流程模型模块包含流转关系分类模块。上述的一种用于临床试验的方法，其中，所述业务单元分类模块将业务单元分为以下类别：开始事件（start）、结束事件、通知事件（notificationevent）、等待事件、用户任务、一次性机器人程序、可重复机器人程序、流程。20.上述的一种用于临床试验的方法，其中，所述流转关系分类模块将业务单元之间的流转关系分为以下类别：顺序流（sequenceflow）、调用流（invokeflow）、消息流（messageflow）、返回流（returnflow）。21.上述的一种用于临床试验的方法，其中，步骤a2中，所述动作信息包括以下分类：元素动作、流动作、临床试验开始动作、临床试验结束动作；所述元素动作执行服务模块获取并执行的所述元素动作包含以下几种动作：元素开始动作、元素完成动作、元素调用动作、元素撤回动作、元素退回动作、元素取消动作；所述流动作执行服务模块获取并执行所述流动作包含以下几种动作：流激活动作、流撤回动作、流取消动作；所述临床试验开始动作是在临床试验开始的时候执行的，只执行一次，触发主流程的元素开始动作；所述临床试验结束动作标记着临床试验的结束。22.上述的一种用于临床试验的方法，其中，步骤a3中，所述元素动作执行服务模块内置的所述临床试验流程模型模块创建的动作算法模型用于控制执行所述业务单元的等待中、进行中、完成、取消的任务；所述动作算法模型还用于控制执行所述业务单元的开始事件、结束事件、通知事件、等待事件、用户任务、一次性机器人程序、可重复机器人程序、流程；所述通知事件和等待事件用一个消息组的字段关联；所述通知事件用来发送消息，所述等待事件用来接收消息；所述流动作执行服务模块内置的所述临床试验流程模型模块创建的流算法模型用于控制执行所述流转单元的等待中、已激活、撤回和取消的任务；所述流算法模型还用于控制执行所述流单元的顺序流、调用流、消息流、返回流的任务。23.基于开源的bpmn的定义，将临床试验总结、归纳成计算机中可以运行的流程，进而定义出了ctdl（clinicaltrialdescriptionlanguage）；bpmn是标准的业务流程描述模型，是由bpmi(thebusinessprocessmanagementinitiative)开发了一套标准叫业务流程建模符号(bpmnꢀ‑ꢀbusinessprocessmodelingnotation)，在bpminotationworkinggroup超过2年的努力，于2004年5月对外发布了bpmn1.0规范，后bpmi并入到omg组织，omg于2011年推出bpmn2.0标准，对bpmn进行了重新定义(businessprocessmodelandnotation)；bpmn的主要目标是提供一些被所有业务用户容易理解的符号，从创建流程轮廓的业务分析到这些流程的实现，直到最终用户的管理监控，bpmn也支持提供一个内部的模型可以生成可执行的bpel4ws，因此bpmn的出现，弥补了从业务流程设计到流程开发的间隙。24.bpmn定义了一个业务流程图（businessprocessdiagram），该业务流程图基于一个流程图（flowcharting），该流程图被设计用于创建业务流程操作的图形化模型。而一个业务流程模型（businessprocessmodel），指一个由图形对象（graphicalobjects）组成的网状图，图形对象包括活动（activities)和用于定义这些活动执行顺序的流程控制器（flowcontrols），本专利申请的ctdl借鉴了bpmn的部分定义，在bpmn的基础上针对临床试验的场景做了归纳和调整；流程、元素及流等基本概念大多是借鉴bpmn的，包括子流程、事件（开始事件、结束事件）、用户任务、顺序流、消息流等。创造性的部分有：1.细分了上下文的概念,在bpmn中，没有对上下文或流程参数等运行态的概念进行定义；在某些公开的基于bpmn的流程引擎中（如activiti），对上下文的定义更多是在流程层面，类似公共盘的概念，流程中的节点都可以读取或修改这个上下文。而在临床试验的场景中，由于交付物等参数非常多，并且某些敏感信息不宜公开，只能在相关责任人中流转，需要细分出“私有空间”,在ctdl的定义中，每个元素、每个流，都具有自己的上下文（私有空间）,并且，创造性地在流上定义了交付参数信息（假设有个流f，是从业务单元a指向业务单元b的。a中定义了一个参数x，b中也定义了一个x。在没有定义交付参数的情况下，a和b中虽然都有x，但他们是没有任何联系的。此时若在f上定义了一个关于x的交付参数(delivery)，就可以把a和b中的x关联起来，表示将a中x的值传给b中的x），从而把参数从一个上下文传递到另一个上下文（传递交付物），在bpmn中并没有类似的概念。25.2.将bpmn中的消息事件及信号事件的概念合并（在临床试验的场景中，二者含义相近，故合并）,同时，将上述消息的概念拆成了两部分，定义了通知事件（用来发送消息）和等待事件（用来接收消息），分别用来处理消息的发送和接收，使得业务处理更加灵活,（普通的消息流只能在同一个流程中通信，通知事件和等待事件用一个消息组的字段关联，可以实现跨流程的一对多或多对一通信。实际的场景中，跨流程通信的例子很多，例如pm需要通知每个中心的crc（临床协调员），pm触发通知的任务是在主流程中的，crc们执行的任务是在中心子流程中的，这个例子就是一个一对多的通信；又比如，crc在中心子流程中执行完一个任务后，除了继续进行后续的任务外，还需要给pm发一个通知，发送通知的任务有很多，但接收通知的任务只有一个，这个场景就是个多对一的通信）;3.拓展了动作的概念：在某些公开的基于bpmn的流程引擎中（如activiti），只有例如“开始”、“完成”等基本的、技术层面的动作。如果直接用来解决具体的业务场景中的问题，需要将这些基本的动作进行组装,对于常用的操作，会带来大量重复且繁琐的配置工作。ctdl归纳了临床试验中常见的操作，延伸拓展了动作的概念，补充了诸如退回/撤回、调用、取消等动作，大大降低了编写和配置ctdl的难度;ctdl（clinicaltrialdescriptionlanguage,临床试验描述语言）是一种临床试验项目的定义形式，与传统的项目sop文档不同的是，ctdl可以通过ctee（clinicaltrialexecuteengine，临床试验执行引擎）执行，也更方便修改和扩展。26.依据上述本发明一种用于临床试验的系统与方法的技术方案具有一下技术效果：ctdl（临床试验描述语言），通过抽象临床试验的模型，为每个参与方分配任务，用任务间的流转关系将任务组织成流程，将传统的sop文档转化为程序可以执行、计算的语言，在运行的时候，只用传入项目参数、项目人员等信息，就可以自动复制、扩展到不同的项目上，解决了sop文档复杂、难扩展的弊端，同时，ctdl的执行引擎可以自动为每个任务排期、根据任务乃至整体项目进度，解决了传统场景下沟通协作难的问题，在bpmn的流程模型基础上，增加动作信息（action）和上下文（context）等概念，定义了一种全新的临床试验描述语言，配合临床试验执行引擎，在临床试验的场景上运用、落地。本发明可实现自动化、有效控制临床试验项目进度，简化沟通流程，降低沟通成本，大大提高了沟通效率，解决了本领域的技术难题，达到了预料不到的技术效果。附图说明27.图1为本发明一种用于临床试验的系统的结构示意图；图2为本发明一种用于临床试验的系统中元素动作执行服务模块的结构示意图；图3为本发明一种用于临床试验的系统中流动作执行服务模块的结构示意图；图4为本发明一种用于临床试验的系统具体实施例的流程图；图5为本发明一种用于临床试验的系统具体实施例中系统自动开始的流程图；图6为本发明一种用于临床试验的系统具体实施例中用户任务1提交前的图；图7为本发明一种用于临床试验的系统具体实施例中用户任务2等待中的图；图8为本发明一种用于临床试验的系统具体实施例中用户任务1完成的图；图9为本发明一种用于临床试验的系统具体实施例中用户任务2进行中的图；图10为本发明一种用于临床试验的系统具体实施例中用户任务1完成后的图；图11为本发明一种用于临床试验的系统具体实施例中流程结束的图；图12为本发明一种用于临床试验的系统真实场景的流程图；图13为本发明一种用于临床试验的系统真实场景的流程图a部的放大图；图14为本发明一种用于临床试验的系统真实场景的流程图b部的放大图；图15为本发明一种用于临床试验的系统真实场景的流程图c部的放大图；图16为本发明一种用于临床试验的系统真实场景的流程图d部的放大图；图17为本发明一种用于临床试验的系统真实场景的流程图e部的放大图；图18为本发明一种用于临床试验的系统真实场景的流程图f部的放大图；图19为流程在业务上的概念图。具体实施方式28.为了使发明实现的技术手段、创造特征、达成目的和功效易于明白了解，下结合具体图示，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。29.基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。30.须知，本说明书所附图式所绘示的结构、比例、大小等，均仅用以配合说明书所揭示的内容，以供熟悉此技术的人士了解与阅读，并非用以限定本发明可实施的限定条件，故不具技术上的实质意义，任何结构的修饰、比例关系的改变或大小的调整，在不影响本发明所能产生的功效及所能达成的目的下，均应仍落在本发明所揭示的技术内容得能涵盖的范围内。31.同时，本说明书中所引用的如“上”、“下”、“左”、“右”、“中间”及“一”等的用语，亦仅为便于叙述的明了，而非用以限定本发明可实施的范围，其相对关系的改变或调整，在无实质变更技术内容下，当亦视为本发明可实施的范畴。32.本发明的一较佳实施例是提供一种临床试验场景的系统，目的是ctdl（临床试验描述语言），通过抽象临床试验的模型，为每个参与方分配任务，用任务间的流转关系将任务组织成流程，将传统的sop文档转化为程序可以执行、计算的语言，在运行的时候，只用传入项目参数、项目人员等信息，就可以自动复制、扩展到不同的项目上，解决了sop文档复杂、难扩展的弊端，同时，ctdl的执行引擎可以自动为每个任务排期、根据任务乃至整体项目进度，解决了传统场景下沟通协作难的问题，在bpmn的流程模型基础上，增加动作信息（action）和上下文（context）等概念，定义了一种全新的临床试验描述语言，配合临床试验执行引擎，在临床试验的场景上运用、落地。33.如图1所示，第一方面，一种用于临床试验的系统，其中，包含数据存储模块（actionqueue）、流程执行引擎（workflowengine）、元素动作执行服务模块（elementactionservice）、流动作执行服务模块（flowactionservice）；所述元素动作执行服务模块与所述流动作执行服务模块内均设置有临床试验流程模型模块；所述临床试验流程模型模块用于定义临床试验中的多个业务单元（element）及它们之间的流转关系，所述元素动作执行服务模块与所述流动作执行服务模块分别根据所述临床试验流程模型模块执行任务；所述数据存储模块内存储有动作消息队列，所述动作消息队列中记载有待执行的动作信息（action）；所述流程执行引擎实时监控所述数据存储模块内是否有可消费的动作信息（action），当有动作信息（action）可消费时，所述流程执行引擎消费一条动作信息（action）并根据动作信息（action）的类型分类为元素动作和流动作分发至所述元素动作执行服务模块与所述流动作执行服务模块，分发完成后继续监听所述数据存储模块，消费下一条动作信息（action）；所述元素动作执行服务模块获取并执行所述元素动作（elementaction）；所述流动作执行服务模块获取并执行所述流动作（flowaction）;所述元素动作执行服务模块执行后的元素动作（elementaction）及所述流动作执行服务模块执行后的流动作（flowaction）传输至所述数据存储模块并存储在所述数据存储模块中动作消息列队的末端。34.其中，所述临床试验流程模型模块包含业务单元分类模块和流转关系分类模块。35.其中，element（业务单元）是临床试验中的业务单元的统称，所述业务单元分类模块将业务单元（element）分为以下类别：开始事件（startevent）、结束事件（endevent）、通知事件（notificationevent）、等待事件（waitingevent）、用户任务（task）、一次性机器人程序（disposablebot，该机器人程序只会执行一次）、可重复机器人程序（repeatablebot，该机器人程序会按照设定的时间周期，重复地执行）、流程（process）。[0036][0037]其中，所述流转关系分类模块将业务单元之间的流转关系分为以下类别：顺序流（sequenceflow）、调用流（invokeflow）、消息流（messageflow）、返回流（returnflow）。[0038]其中，所述元素动作执行服务模块内置的所述临床试验流程模型模块创建的动作算法模型用于控制执行所述业务单元的等待中（pending）、进行中（ongoing）、已完成（finished)、取消（cancel）的任务；所述动作算法模型还用于控制执行所述业务单元的开始事件（start）、结束事件、通知事件（notificationevent）、等待事件、用户任务、一次性机器人程序、可重复机器人程序、流程；所述流动作执行服务模块内置的所述临床试验流程模型模块创建的流算法模型用于控制执行所述流转单元的等待中（pending）、已激活（active）、撤回（withdraw）和取消（cancel）的任务；所述流算法模型还用于控制执行所述流单元的顺序流（sequenceflow）、调用流（invokeflow）、消息流（messageflow）、返回流（returnflow）的任务；所述业务单元内置有业务上下文（context），所述业务上下文中存储有业务参数；所述流转单元内置有流上下文（context），所述流上下文中存储有交付参数；所述动作信息包含业务开始信息、业务完成信息（complete）、业务调用信息（invoke）、业务撤回信息（withdraw）、业务退回信息（reject）、业务取消信息（cancel）、流激活信息（activate）。[0039]上述的一种临床试验场景的系统，其中，参数包含临床试验中使用到模板、产生的交付物、或临床试验执行引擎（ctee，即clinicaltrialexecuteengine）执行过程中的临时变量、或ctdl中农定义的参数等，临床试验执行引擎的核心是基于actionqueue，通过不停地消费动作信息（action），执行对应的动作，触发后续的动作，达到流程自动化的效；所述业务参数包含文件、文件目录、数字、日期、时间、文本、布尔、列表、确认列表、用户列表；所述交付参数包含文件、文件目录、数字、日期、时间、文本、布尔、列表、确认列表、用户列表；与传统的流程引擎不同，ctdl并不是让一个流程中的所有节点都共享一个参数域，而是让每个业务单元（element）都拥有各自的上下文（context），上下文中存放着运行所需的参数；业务单元（element）与业务单元（element）之间的参数传递是由ctee根据流（flow）上的参数定义自动进行传递的；流（flow）也有自己的上下文（context），流（flow）在被触发的时候，会先根据参数定义，从上游的上下文（context）中将对应的参数取出来，放到自己的上下文（context）里，待下游组件可以开始的时候（满足开始条件），再由下游将对应的参数从流（flow）的上下文（context）里取出装载到自己的上下文（context）里；这样把上下文（context）在流上暂存的做法，相比直接把变量从上游传给下游，有几点好处：1.当一个组件存在多个输入流（incomingflow）的时候，方便人为设置流加载的顺序（根据优先级，而不是时间顺序）；2.若下游组件运行出错，方便进行回滚；特别的，为了方便处理、简化ctdl定义，每个组件的上下文会自动继承其所在流程的上下文（所在的流程在其被创建的时候，亦会自动继承父流程的上下文）；制定计划：ctdl的一个很主要的功能是可以为临床试验项目制订计划，帮助pm合理安排时间、把控项目进度，在ctdl中定义了若干的时间约束条件，如下：业务单元（element）的计划开始时间不早于项目的计划开始时间；业务单元（element）的计划开始时间不早于其incomingsequenceflow的上游业务单元（element）的计划结束时间；业务单元（element）的计划开始时间不早于其incominginvokeflow的上游业务单元（element）的计划开始时间；startevent的开始时间等于所在流程的开始时间；业务单元（element）的计划结束时间不早于其计划开始时间 计划周期；业务单元（element）的计划结束时间不早于其incomingreturnflow的上游业务单元（element）的计划结束时间；流程（process）的计划结束时间不早于其中的任何一个endevent的计划结束时间；初始时，将所有主流程的计划开始时间和计划结束时间设置为项目的开始实际，然后把主流程的所有startevent加入队列中，开始执行下列步骤：步骤d1：取出队列头部的业务单元（element），根据上述依赖条件，计算任务的计划时间；步骤d2：若计划时间未发生变化，则跳过；否则：步骤d3：沿着当前业务单元（element）的outgoingflow，把后续的业务单元（element）加入队列中，特别地，endevent没有outgoingflow，需要特殊处理，把其归属的流程（process）加入队列中；步骤d4：回到步骤d1，持续迭代更新，直到队列为空。[0040]动态调整：以下情况出现时，会触发计划的动态调整：创建一个新的实例，人工调整了业务单元（element）的计划；动态调整策略：与上述的初始化计划时间的步骤相同，区别是一开始只把对应的业务单元（element）加入队列中。[0041]如图2所示，上述的一种临床试验场景的系统，其中，所述元素动作执行服务模块包含执行开始模块（dostart）、执行完成模块（docomplete）、执行调用模块（doinvoke）、执行撤回模块（dowithdraw）、执行退回模块（doreject）、执行取消模块（docancel）；所述执行开始模块（dostart）用于获取并执行所述元素开始动作，检查输入依赖是否满足每个定义的输入顺序流（incomingsequenceflow）都被触发或被取消，若不满足，跳过处理；还用于装载流程上下文；还用于把当前组件(所有的动作信息（action）都是对某个对象执行的,elementaction就是对某个业务单元（element）执行的，flowaction就是对某个flow执行的，这里写的当前组件就是指业务单元（element））的状态变为进行中（ongoing）状态；若当前执行start的组件为流程（process），则触发流程（process）内所有开始事件（startevent）的元素开始动作（startaction）；若为用户任务（task），不执行动作；否则，触发完成任务（completeaction）；所述执行完成模块（docomplete）用于获取并执行所述元素完成动作，检查当前组件是否满足完成条件：若当前组件存在未完成的返回流（returnflow），则不允许执行完成动作，未完成的返回流（returnflow）表示已经调用，但还未返回结果；还用于业务单元（element）的检查参数，若参数设置为必填（required），检查业务单元（element）的上下文（context）中是否存在对应的参数，若不存在则报错；若当前组件为结束事件（endevent），则触发所在流程的元素完成动作（completeaction）；若当前组件为流程（process），则触发流程内所有未完成的组件的元素取消动作（cancelaction），并触发当前组件所有的输出流（outgoingflow）的流激活动作（activateaction）；若当前组件为通知事件（notificationevent），则将当前组件的上下文（context）发送到消息组（messagegroup）中；还用于把当前组件的状态变成已完成（finished）；还用于判断当前组件是否为主流程，若是则触发临床试验开始动作（trialendaction）；还用于触发当前组件所有的输出流（outgoingflow）的流激活动作（activateaction）；所述执行调用模块（doinvoke）模块用于获取并执行所述元素调用动作，将调用（invoke）动作传递的变量与调用流（invokeflow）的上游组件（指invokeflow的上游组件，所有的流（flow）都是从一个业务单元（element）流到另一个业务单元（element）的，比如从a到b。那么a就是这个流（flow）的上游，b是下游）的上下文（context）合并，作为调用的流程的上下文（context）；还用于创建调用流（invokeflow）和对应的returnflow，递归创建流程中的组件及流；还用于触发调用流（invokeflow）的流激活动作（activateaction）；所述执行撤回模块（dowithdraw）用于执行需撤回的流程的元素撤回动作（withdrawaction）；所述执行退回模块（doreject）模块用于执行需退回的流程的元素退回动作（withdrawaction）；所述执行取消模块（docancel）用于获取并执行所述元素取消动作，判断出本次元素取消动作（cancelaction）不是强制取消，则确认是否满足取消条件：所有的输入流（inputflow）均已取消；若不满足，则跳过；还用于判断出当前组件为结束事件（endevent），则检查所在流程的所有的结束事件（endevent），若所有结束事件（endevent）均已取消，则触发所在流程的元素取消动作（cancelaction）；若当前组件为流程（process），则触发流程内所有未完成的组件的元素取消动作（cancelaction）；还用于把当前组件的状态变为取消（cancel）状态；还用于判断当前组件是否为主流程，若为主流程则触发临床试验结束动作（trialendaction）；还用于触发当前组件所有的输出流（outgoingflow）的流取消动作（cancelaction）。[0042]上述的一种临床试验场景的系统，其中，所述执行开始模块（dostart）用于装载流程上下文的具体方式如下：继承所在流程的上下文；检查当前element上定义的参数，若有定义默认值，则创建默认值；若当前组件为等待事件（waitingevent），则从对应的消息组（messagegroup）中读取消息，跳过下一步；将所有的输入流（inputflow）排序，按照顺序流（sequenceflow）、调用流（invokeflow）、消息流（messageflow）、返回流（returnflow）的顺序加载；对于同一类型的流，优先级越高的流越迟加载，加载时遇到同名的变量会自动覆盖，所以优先级高的需要迟加载。[0043]如图3所示，上述的一种临床试验场景的系统，其中，所述流动作执行服务模块包含执行激活模块（doactivate）、执行撤回模块（dowithdraw）、执行取消模块（docancel）；所述执行激活模块（doactivate）用于获取并执行所述流激活动作，从上游的上下文（context）中取出流（flow）上定义的交付参数，存放在当前流（flow）的上下文（context）中，若存在required的参数的值为null的情况，则报错；还用于把当前流（flow）的状态变为激活状态（active）；还用于触发下游的元素开始动作（startaction）；所述执行撤回模块（dowithdraw）用于获取并执行所述流撤回动作，把流（flow）的上游切换为进行中（ongoing）状态，把流（flow）的下游切换为等待中（pending）状态，当前流（flow）切换为撤回（withdraw）状态；所述执行取消模块（docancel）用于获取并执行所述流取消动作，把当前流（flow）切换为取消（cancel）状态；还用于触发下游的元素取消动作（cancelaction）。[0044]上述的一种临床试验场景的系统，其中，还包含临床试验开始动作执行（trialstartaction）模块和临床试验结束动作执行（trialendaction）模块；所述临床试验开始动作执行（trialstartaction）模块用于在临床试验开始时将主流程中的业务单元（element）和流（flow）都预先创建出来，初始都为等待中（pending）状态；所述临床试验结束动作执行（trialendaction）模块标记着临床试验的结束，用于结束整个流程。[0045]如图19所示，一次临床试验项目(project)由临床试验模型（trial）与临床试验方案（protocol）两部分组成，临床试验模型与临床试验方案之间的关系可以近似理解为函数表达式project=trial(protocol)的关系，临床试验方案（protocol）是参数，临床试验项目(project)是临床试验模型在特定临床试验方案下运行的结果，临床试验模型（trial）是一个流程（process）；流程（process）描述了临床试验中的多个业务单元及它们之间的流转关系，流程（process）是一个有向图，包含业务单元（element）与流（flow）两个部分，流（flow）是有方向的；业务单元（element）是临床试验中的业务单元的统称，以下均是临床试验的业务单元：开始事件、结束事件、通知事件、等待事件、用户任务、一次性机器人程序、可重复机器人程序、流程；业务单元（element）具有等待中（pending）、进行中（ongoing）、完成（finished)、取消（cancel）4个生命周期状态；流（flow）定义了同一个流程中的业务组件间的流转（不同流程内部的业务组件间不允许流转），从流的起点（上游组件）流向终点（下游组件），以下称一个组件的输出流（outputflow）是起点为该组件的流，类似的，输入流（inputflow）为终点为该组件的流，流是基于动作信息（action）触发的，流分为顺序流、调用流、消息流、返回流四种；流（flow）具有等待中（pending）、已激活（active）、撤回（withdraw）和取消（cancel）；业务单元（element）与流（flow）之间的流转是通过动作信息（action）来触发的，其中业务单元（element）有开始（start）、完成（complete）、调用（invoke）、撤回（withdraw）、退回（reject）、取消（cancel）几种动作信息（action）；流（flow）有激活（activate）、撤回（withdraw）、取消（cancel）几种动作信息（action）；不同的动作信息（action）有不同的执行逻辑，并且能够切换业务单元（element）与流（flow）的状态，由elementactionservice和flowactionservice两个模块实现，两个模块均会根据不同的动作信息（action）类型，执行对应的逻辑，并返回后续需要触发的动作信息（action）列表。[0046]第二方面，如图1所示，本发明提供一种用于临床试验系统的实现方法，其中，包含以下步骤：步骤a1：元素动作执行服务模块内置的临床试验流程模型模块创建动作算法模型并存储在元素动作执行服务模块内；流动作执行服务模块内置的临床试验流程模型模块创建的流算法模型存储在流动作执行服务模块内；步骤a2：流程执行引擎实时监控数据存储模块内的动作消息队列是否有可消费的动作信息，并将可消费的动作信息发送至元素动作执行服务模块或流动作执行服务模块；步骤a3：元素动作执行服务模块获取动作信息并依据动作算法模型执行后续操作；或者，流动作执行服务模块获取动作信息并依据流算法模型执行后续操作；步骤a4：元素动作执行服务模块将执行完的动作信息传输至数据存储模块并存储在所述数据存储模块中动作消息列队的末端；或者，流动作执行服务模块将执行完的动作信息传输至数据存储模块并存储在所述数据存储模块中动作消息列队的末端。[0047]一个具体实施例如下：如图4所示，这个流程图描述了一个简单的提交材料、审核材料的流程，由crc收集并提交材料，再由pm对材料进行审核；在task1中，定义了两个参数，一个参数task1_file_template，用来展示信息收集表的模板，参数类型是file，并且是不可编辑的（editable为false）；另一个参数是task1_file，是crc基于模板补充必要的信息后，上传的交付物，该参数同样为file类型，是可编辑的（editable为true），且为必须的（required为true）；task2是pm的审核任务，只有一个参数，task1_file，这个参数是需要从task1传过来的，因此设置的是不可编辑的；在task1和task2之间的sequenceflow上，定义了task1_file的传递（如下的delivery信息）；系统动作详解：1.对于上面的样例，项目初始化的时候，会默认创建如下内容，并且他们的状态都是pending：element：mainprocess项目主流程pending；startevent开始节点pending；task1用户任务1pending；task2用户任务2pending；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1pending；flow2顺序流，用户任务1——用户任务2pending；flow3顺序流，用户任务2——结束节点pending；2.执行项目的“启动”后，系统会添加一个trialstartaction到动作队列中，上文提到，trialstartaction是一个特殊处理的动作，会触发主流程的elementstartaction（添加到动作队列，此时动作队列中只有这一个action）；3.流程引擎从动作队列中取出一个动作（主流程的elementstartaction），根据其类型，自动转交给elementactionservice执行，elementactionservice会执行dostart模块。根据上文的定义，会触发主流程中所有startevent的elementstartaction（这个样例中只有一个startevent，添加到队列中），这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点pending；task1用户任务1pending；task2用户任务2pending；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1pending；flow2顺序流，用户任务1——用户任务2pending；flow3顺序流，用户任务2——结束节点pending；4.流程引擎继续从动作队列取出动作进行处理，此时执行的是startevent的elementstartaction（主流程的elementstartaction已经被消费了）；继续转交给elementactionservice执行，elementactionservice会执行dostart模块；根据上文的定义，会触发这个startevent的elementcompleteaction；这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点ongoing；task1用户任务1pending；task2用户任务2pending；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1pending；flow2顺序流，用户任务1——用户任务2pending；flow3顺序流，用户任务2——结束节点pending；5.流程引擎继续从动作队列取出动作进行处理，此时执行的是startevent的elementcompleteaction；转交给elementactionservice执行，elementactionservice会执行docomplete模块；根据上文的定义，会触发这个startevent后续的流的flowactivateaction（对应flow1的flowactivateaction）；这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1pending；task2用户任务2pending；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1pending；flow2顺序流，用户任务1——用户任务2pending；flow3顺序流，用户任务2——结束节点pending；6.流程引擎继续从动作队列取出动作进行处理，此时执行的是flow1的flowactivateaction；转交给flowactionservice执行，flowactionservice会执行doactivate模块；由于flow1上未定义任何交付参数，直接触发该流的下游（task1）的elementstartaction。这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1pending；task2用户任务2pending；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2pending；flow3顺序流，用户任务2——结束节点pending；7.流程引擎继续从动作队列取出动作进行处理，此时执行的是task1的elementstartaction，转交给elementactionservice执行，elementactionservice会执行dostart模块，由于该任务类型是task，需要等待用户响应，不会自动触发elementcompleteaction，这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1ongoing；task2用户任务2pending；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2pending；flow3顺序流，用户任务2——结束节点pending；如图5所示，至此，项目“启动”后，系统自动完成的动作结束，等待用户处理，动作队列为空，流程引擎处于等待中，在界面上，可以看到此时的流程状态如下（系统自动开始.png）；如图6所示，此时，crc用户看到的任务界面如下（用户任务1——提交前.png）；如图7所示，pm用户看到的任务界面如下（用户任务2——等待中.png）；8.crc用户提交了“信息收集表”，并点击完成，“完成”接口会触发task1的elementcompleteaction，将其添加到任务队列；9.流程引擎继续停止等待，从动作队列取出动作进行处理，此时执行的是task1的elementcompleteaction，转交给elementactionservice执行，elementactionservice会执行docomplete模块，根据上文定义，会触发flow2的flowactivateaction，这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1finished；task2用户任务2pending；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2pending；flow3顺序流，用户任务2——结束节点pending；10.流程引擎继续从动作队列取出动作进行处理，此时执行的是flow2的flowactivateaction；转交给flowactionservice执行，flowactionservice会执行doactivate模块；flow2上定义了一个交付参数——task1_file，doactivate会从流的上游（task1）的上下文中取出这个参数（task1_file），暂存在flow2的上下文中，并触发该流的下游（task2）的elementstartaction。这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1finished；task2用户任务2pending；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2activate；flow3顺序流，用户任务2——结束节点pending；11.流程引擎继续从动作队列取出动作进行处理，此时执行的是task2的elementstartaction，转交给elementactionservice执行，elementactionservice会执行dostart模块，根据上文定义，dostart会从所有的输入流（inputflow）中按照优先级加载上下文（此例子中只有一个输入流（inputflow）一个参数），将task1_file从flow2的上下文中取出，加载到task2的上下文中，同样，由于该任务类型是task，需要等待用户响应，不会自动触发elementcompleteaction，这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1finished；task2用户任务2ongoing；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2activate；flow3顺序流，用户任务2——结束节点pending；至此，crc上传文件，并完成用户任务1后，系统自动完成的动作结束，等待用户处理。动作队列为空，流程引擎处于等待中；如图8所示，此时crc用户的任务界面如下（用户任务1——完成.png）；如图9所示，pm用户的任务界面如下（用户任务2——进行中.png）；如图10所示，流程状态如下（用户任务1完成后.png）；12.pm完成了审批，点击完成，会触发task2的elementcompleteaction，将其添加到任务队列；13.流程引擎继续停止等待，从动作队列取出动作进行处理，此时执行的是task2的elementcompleteaction，转交给elementactionservice执行，elementactionservice会执行docomplete模块，根据上文定义，会触发flow3的flowactivateaction，这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1finished；task2用户任务2finished；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2activate；flow3顺序流，用户任务2——结束节点pending；14.流程引擎继续从动作队列取出动作进行处理，此时执行的是flow3的flowactivateaction，转交给flowactionservice执行，flowactionservice会执行doactivate模块，最终触发该流的下游（endevent）的elementstartaction。这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1finished；task2用户任务2finished；endevent结束节点pending；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2activate；flow3顺序流，用户任务2——结束节点activate；15.流程引擎继续从动作队列取出动作进行处理，此时执行的是task3的elementstartaction，转交给elementactionservice执行，elementactionservice会执行dostart模块，根据上文中的定义，dostart模块会自动触发endevent的elementcompleteaction，这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1finished；task2用户任务2finished；endevent结束节点ongoing；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2activate；flow3顺序流，用户任务2——结束节点activate；16.流程引擎继续从动作队列取出动作进行处理，此时执行的是task3的elementcompleteaction，转交给elementactionservice执行，elementactionservice会执行docomplete模块，根据上文中的定义，docomplete模块会自动触发endevent所在流程（即主流程）的elementcompleteaction，这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程ongoing；startevent开始节点finished；task1用户任务1finished；task2用户任务2finished；endevent结束节点finished；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2activate；flow3顺序流，用户任务2——结束节点activate；16.流程引擎继续从动作队列取出动作进行处理，此时执行的是mainprocess的elementcompleteaction，转交给elementactionservice执行，elementactionservice会执行docomplete模块，特殊的，主流程完成后会触发trialendaction，这个步骤完成后，各element和flow的最新状态如下：element：mainprocess项目主流程finished；startevent开始节点finished；task1用户任务1finished；task2用户任务2finished；endevent结束节点finished；flow：flow1顺序流，开始节点——用户任务1activate；flow2顺序流，用户任务1——用户任务2activate；flow3顺序流，用户任务2——结束节点activate；如图11所示，17.流程引擎接收到trialendaction，结束流程（流程结束.png）；如图12-18所示，真实场景比上面的例子要复杂得多得多，以下是一个真实场景中某个阶段的流程图（真实场景流程图.png）。[0048]综上，本发明的一种用于临床试验的系统与方法，ctdl（临床试验描述语言），通过抽象临床试验的模型，为每个参与方分配任务，用任务间的流转关系将任务组织成流程，将传统的sop文档转化为程序可以执行、计算的语言，在运行的时候，只用传入项目参数、项目人员等信息，就可以自动复制、扩展到不同的项目上，解决了sop文档复杂、难扩展的弊端，同时，ctdl的执行引擎可以自动为每个任务排期、根据任务乃至整体项目进度，解决了传统场景下沟通协作难的问题，在bpmn的流程模型基础上，增加动作信息（action）和上下文（context）等概念，定义了一种全新的临床试验描述语言，配合临床试验执行引擎，在临床试验的场景上运用、落地。[0049]以上对发明的具体实施例进行了描述。需要理解的是，发明并不局限于上述特定实施方式，其中未尽详细描述的设备和结构应该理解为用本领域中的普通方式予以实施；本领域技术人员可以在权利要求的范围内做出各种变形或修改做出若干简单推演、变形或替换，这并不影响发明的实质内容。当前第1页12当前第1页12
再多了解一些
本文用于企业家、创业者技术爱好者查询，结果仅供参考。
