队列识别系统的制作方法

本申请要求2012年10月31日提交的美国临时专利申请序列号61/720,611的优先权，其主题通过引用被并入于此。

技术领域

一种实施例涉及计算机系统，并且更具体地涉及管理临床数据的计算机系统。

背景技术：

在诸如药品安全等的健康科学领域，“病例系列”是不良事件病例的列表。“不良事件病例”或“病例”是病人出现不良事件的特定事件的数据记录。每个不良事件病例都有唯一的标识符。通常在健康科学领域，病例系列也可标识为“病人列表”或“研究对象列表”。

许多药品安全系统可以产生和消费病例系列，其中“药品安全系统”是存储药品安全数据的系统，并且其中药品安全数据包括与一种或多种药品的安全性有关的数据，诸如一个或多个不良事件病例等。通常，在这些系统中，可执行进程产生病例系列并且将它传递给操作它的一个或多个可执行进程。在常见场景中，对诸如药品安全系统等的数据源执行查询的可执行进程，可以产生病例系列并且将它传递给执行报告的可执行进程。在此场景中，所述病例系列是对所述数据源执行所述查询的所述可执行进程的结果。换句话说，包括所述病例系列的病例列表是匹配在由可执行进程对所述数据源执行的查询中规定的条件的病例列表。所述报告可以是所述病例系列的期望输出格式，并且所述报告可以由可执行进程执行。所述病例系列通常至少包含每个病例的唯一标识符(通常标识为“病例标识符”)，并且还可以包含代表所述病例系列中的不良事件病例的额外的病例数据或元数据。病例系列中的数据域不必与所述查询或所述报告中规定的数据域相同。病例系列中的数据域可通常是固定的，而报告的数据域可依赖于期望的输出格式而改变。

同样在健康科学领域，识别病人“队列”可以是必要的，其中病人“队列”是具有相同或相似特征的一组病人。在药品安全领域，所述病人可以是不良事件病例的研究对象。在更广泛的健康科学领域，所述病人可以是临床记录的研究对象。

技术实现要素：

一种实施例是队列识别系统，所述系统识别诸如病人队列等的队列。所述队列识别系统检索包括关于数据源的一个或多个数据域的信息的元数据，其中所述信息包括用于所述一个或多个数据域的每个数据域的数据类型和结构化查询语言信息。所述队列识别系统还基于检索的元数据生成对于数据源的查询。所述队列识别系统还基于一个或多个编译器规则编译所述查询。所述队列识别系统还对所述数据源执行所述查询，其中所述查询的执行生成病例系列。所述队列识别系统还基于所述病例系列生成报告，其中所述报告包括所述病例系列的可视化。

附图说明

从下面优选实施例的详细描述中，结合附图做出的进一步的实施例、细节、优点、和修改将变得清晰。

图1示出了可实施本发明的实施例的系统的框图；

图2示出了根据本发明的实施例的可互操作的病例系列系统的框图；

图3示出了根据本发明的实施例的病例系列数据模型的框图；

图4示出了根据本发明的实施例的可互操作的病例系列系统的示例实施方式的框图；

图5示出了根据本发明的实施例的可互操作的病例系列模块的功能的流程图；

图6示出了根据本发明的实施例的队列识别系统的框图；

图7示出了根据本发明的实施例的队列识别系统的示例实施方式的框图；

图8示出了根据本发明的实施例的队列识别模块的功能的流程图；

图9示出了根据本发明的实施例的生成示例病例系列的示例查询，所述实例病例系列生成示例报告。

具体实施方式

在一种实施例中提供了队列识别系统，所述队列识别系统能够检索为数据源描述所述数据源和结构化查询语言(“SQL”)的元数据，并且能够基于所述检索的元数据对所述数据源生成和执行一个或多个查询。所述数据源可以包括一个或多个不良事件病例，其中每个不良事件病例都包括代表不良事件的数据记录。在替代实施方式中，所述数据源可以包括一个或多个医疗记录，其中每个医疗记录是包括医疗数据的数据记录。所述队列识别系统还可从一个或多个执行的查询中生成一个或多个案例系列并且可以将所述一个或多个案例系列存储在案例系列库中。“案例系列”是一个或多个不良事件案例的集合。“病人列表”是一个或多个医疗记录的集合。所述队列识别系统还可基于一个或多个案例系列生成一个或多个报告。生成的一个或多个报告可用以可视化诸如病人队列等的队列。“队列”是一个或多个相关的不良事件病例的集合，或者是一个或多个相关的医疗记录的集合。例如，为确定乳腺癌多发的地理区域，队列识别系统可以分析病人数据的集合以识别具有相似特征的相似病人的队列或组，这可以允许分析队列的病人之间的共因。因为队列识别系统基于检索的元数据生成并且执行查询，所述队列识别系统可与任何数据模型一同使用，并且可与一个或多个软件应用集成。如在本说明书中所述，“计算机应用”、“软件应用”、或“应用”是计算机程序和/或模块的任意选集。例如，队列识别系统可以与任何人类健康科学数据模型一同使用。队列识别系统也可以用在使用相似数据模型的其他领域。例如，在其他实施例中，队列识别系统可以与对终端用户可用的多个数据源一同使用，其中所述多个数据源可以包括不良事件数据库和医疗历史数据库的组合。

某些实施例可以包括：(a)数据源的元数据描述，和数据源的SQL(这包括对参考数据的可扩展的方法)；(b)用于与软件应用集成的应用编程接口(“API”)；和(c)可以使得容易在报告中使用病例系列和元数据的与通用报告软件应用集成的API。对数据模型的元数据-驱动方法可允许在不改变队列识别系统的情况下在所述队列识别系统中实施新理念。

而且，某些实施例可包括三类解决方案。第一类解决方案包括特定于软件应用的工具和特定于数据模型的工具，诸如生成和修改查询结果的特征等。依赖于所述应用，查询结果被称为“病例系列”或“病人列表”。第二类解决方案包括通用商业智能(“BI”)查询解决方案。第三类解决方案包括独立的结构化查询语言(“SQL”)查询生成器。因此，本发明的实施例可在与数据模型无关(即，不依赖于数据源的特定数据模型)的同时提供广泛类型的特征。

图1示出了可以实施本发明的一种实施例的系统10的框图。系统10包括用于在系统10的组件之间信息通信的总线12或其他通信机构。系统10还包括操作性地耦接到总线12的处理器22用于处理信息并且执行指令或操作。处理器22可以是任何类型的通用处理器或专用处理器。系统10还包括用于存储要由处理器22执行的信息和指令的存储器14。存储器14可以由随机存取存储器(“RAM”)、只读存储器(“ROM”)、诸如磁盘或光盘等的静态存储器、或任何其他类型的机器可读介质或计算机可读介质的组合组成。系统10还包括诸如网络接口卡或其他通信接口等的通信设备20，以提供对网络的访问。作为结果，用户可以直接与系统10对接，或通过网络或任何其他方法远程对接。

计算机可读介质可以是能够由处理器22访问的任何可用的介质。计算机可读介质可包括易失性和非易失性介质、可移除和不可移除介质、通信介质、和存储介质。通信介质可包括计算机可读指令、数据结构、程序模块或诸如载波或其他传输机构等的调制的数据信号上的其他数据，并且可包括本领域已知的其他形式的信息传递介质。存储介质可包括RAM、闪存、ROM、可擦除可编程只读存储器(“EPROM”)、电可擦除可编程只读存储器(“EEPROM”)、寄存器、硬盘、可移除磁盘、光碟只读存储器(“CD-ROM”)、或本领域已知的任何其他形式的存储介质。

处理器22也可以经总线22操作性地耦接到诸如液晶显示器(“LCD”)等的显示器24。显示器24可向用户显示信息。键盘26和诸如计算机鼠标等的光标控制设备28也可操作性地耦接到总线12以使得用户与系统10对接。其他实施例中，用户可以使用人机接口设备(图1未示出)与系统10对接，其中人机接口设备是被配置成直接与用户交互并且从用户取得输入的设备。人机接口设备的示例包括网络摄像机、指纹扫描仪、和耳机。

根据一种实施例，存储器14可存储当由处理器22执行它时可提供功能的软件模块。所述模块可包括操作系统15、队列识别模块16、和其他功能模块18。操作系统15可为系统10提供操作系统功能。如以下详述，队列识别模块16可提供用于识别队列的功能。在某些实施例中，队列识别模块16可包括多个模块，其中每个模块都提供用于识别队列的特定的独立功能。系统10也可以是较大系统的一部分。因此，系统10可包括一个或多个额外功能模块18以包括所述额外功能。例如，功能模块18可包括提供额外功能的模块，诸如Oracle公司的“Oracle Argus Insight”产品的模块等。

处理器22也可以经总线12操作性地耦接到数据库34。数据库34可以存储在逻辑上相关的记录或文件的集成集合中的数据。数据库34可以是操作数据库、分析数据库、数据仓库、分布式数据库、终端用户数据库、外部数据库、导航数据库、存储器内数据库、面向文档的数据库、实时数据库、关系数据库、面向对象的数据库、或本领域已知的任何其他数据库。而且，数据库34可以通过API访问，并且可以支持查询语言。

图2示出了根据本发明的实施例的可互操作的病例系列系统200的框图。可互操作的病例系列系统200可包括病例系列库210、病例系列数据模型220、和病例系列API 230。在某些实施例中，可互操作的病例系列系统200也可包括提供浏览和操作一个或多个病例系列的功能的用户接口组件(图2未示出)。

根据所述实施例，病例系列库210是可以存储诸如一个或多个病例系列等的数据的库。例如，在病例系列包括一个或多个病例标识符(其中每个标识符唯一地识别包括在病例系列内的每个不良事件病例)并且还包括共同代表包括在所述病例系列内的一个或多个不良事件病例的病例数据和/或病例元数据的实施例中，病例系列库210可存储一个或多个病例标识符和关联的病例数据和/或病例元数据。而且，对每个病例系列，病例系列库210也可存储与每个病例系列有关的信息，诸如病例系列历史信息和病例修改信息，这在下面被进一步详述。病例系列库210可以是能够存储数据的任意类型的库，诸如数据库或文件等。

此外，根据所述实施例，病例系列数据模型220是可包括病例系列的规范表示和与所述病例系列有关的信息的数据模型。例如，在病例系列包括一个或多个病例标识符并且还包括共同代表包括在所述病例系列内的一个或多个不良事件病例的病例数据和/或病例元数据的实施例中，病例系列数据模型220可包括代表所述病例标识符的数据域，以及代表所述病例数据和/或病例元数据的一个或多个额外数据域。

而且，如果所述病例系列包括与所述病例系列有关的信息，则病例系列数据模型220还可包括代表与所述病例系列有关的信息的一个或多个额外数据域。在某些实施例中，与所述病例系列有关的信息可包括病例系列历史信息。病例系列历史信息可包括关于所述病例系列的历史的信息，诸如生成所述病例系列的个体、生成所述病例系列的机构、已修改过所述病例系列的一个或多个个体等。在某些实施例中，病例系列历史信息可以用可与病例系列关联的一个或多个改变日志的格式来存储。

在某些实施例中，与病例系列有关的信息可包括病例修改信息。病例修改信息可包括关于所述病例系列的一个或多个修改的信息。根据实施例，修改是对所述病例系列的不良事件病例的任意改变。因此，根据所述实施例，病例系列可包括一个或多个病例修改。此外，每个病例修改可被生成所述病例修改的伙伴应用识别。

除了包括关于所述病例系列的一个或多个修改的信息之外，或者作为替代，病例修改信息可包括关于所述病例系列的一个或多个修改的信息。根据实施例，版本是已经经历了一个质量分析周期的所述病例系列的不良事件病例的改变，并且被识别为准备用于科学分析。在一种示例中，产生软件应用包括对病例的不断的修改，而消费软件应用只支持对最终版本的工作。与病例系列API 230结合的病例系列数据模型220可允许所述软件应用解释病例修改信息以便它可以最准确地在消费软件应用中使用。因此，病例系列也可被标识为病例修改系列。此外，病例修改信息可包括同一病例的多个修改。在某些实施例中，病例修改信息可以用可与病例系列关联的一个或多个修改的格式来存储。参考图3进一步描述病例系列数据模型220的示例。

根据所述实施例，病例系列API 230是可暴露病例系列模型220的API，并且可基于由软件应用指定的格式向所述软件应用呈现病例系列数据模型220。因此，病例系列API 230可允许软件应用于病例系列库210对接。根据实施例，病例系列API 230可提供用于产生、消费、搜索和/或更新一个或多个病例系列的功能。此外，在一种实施例中，第一软件应用可产生病例系列并且使用病例系列API 230将病例系列存储在病例系列库210中。根据所述实施例，第二软件应用可消费由第一软件应用产生并且使用病例系列API 230存储在病例系列库210内的病例系列。因此，并不要求第一软件应用输出病例系列并且要求第二软件应用输入病例系列，而是所述两个软件应用使用病例系列API 230与病例系列库210对接。

根据所述实施例，病例系列库210、病例系列数据模型220、和病例系列API 230支持四种病例系列：(1)命名的病例系列；(2)活动用户病例系列；(3)单次使用的病例系列；和(4)病例清单。命名的病例系列是包括明确唯一名称的病例系列。所述名称可以由用户或由产生软件应用的函数或可执行进程赋予所述命名的病例系列。此外，软件应用可使用名称请求命名的病例系列。病例系列库210可支持对命名的病例系列的搜索或浏览功能。活动用户病例系列是与用户关联的病例系列。活动病例系列可以为与所述活动病例系列关联的用户被命名。活动病例系列的内容可一直存在直到它被覆写。因此，活动病例系列可允许生成可跨越多个软件应用的个人工作空间。单次使用的病例系列是针对执行单个报告的单个目的存在于病例系列库210内的病例系列。在事务完成后，单次使用的病例系列可被删除。病例系列库210可通过与病例系列API 230分离的API来安排所述报告的执行。病例清单是可由产生软件应用完全管理的病例系列。当病例清单存储在病例系列库210中时，所述病例清单可被赋予只被生产软件应用所知的标识。病例清单不出现在命名的病例系列的列表中，但是可由通过产生软件应用的标识的消费者访问。

另外，在一种实施例中，病例系列库210、病例系列数据模型220、和病例系列API 230支持非常类似于病例系列的其他病例系列：(1)事件系列；和(2)产品系列。对于可以对诸如药品安全系统之类的数据源执行的特定不良事件的查询可以产生可以被存储在病例系列库210之内的病例系列。病例系列中的每个病例可具有匹配所述查询的至少一个事件。但是，每个病例也可包括不匹配所述查询的额外事件。因此，病例系列可包括匹配查询的所有病例，和与那些病例相关的所有事件，而不管所述事件匹配所述查询与否。相反，从对数据源执行的查询中产生的事件系列可包括匹配所述查询的所有病例，但仅包括同样匹配所述查询的与那些病例相关的事件。此外，对特定医疗或制药产品的查询也可产生病例系列。所述病例系列的每个病例可具有匹配所述查询的至少一个产品。但是，每个病例也可包括不匹配所述查询的额外产品。因此，病例系列可包括匹配查询的所有病例，和与那些病例有关的所有产品，而不管所述产品匹配所述查询与否。相反，从对数据源执行的查询中产生的产品系列可包括匹配所述查询的所有病例，但仅包括同样匹配所述查询的与那些病例相关的产品。另外，命名的事件系列、命名的产品系列、活动事件系列、活动产品系列、单次使用的事件系列、单次使用的产品系列、事件清单和产品清单是有效变体，并可与先前以上描述的命名的病例系列、活动用户系列、单次使用的病例系列、和病例清单的类似方式工作。

根据实施例，病例系列API 230可对病例系列、事件系列、或产品系列执行以下功能：(a)查看系列；(b)保存系列；(c)使系列活动；(d)给系列赋予访问权限；(e)给系列添加病例；(f)从系列中删除病例；(g)删除系列；(h)注释病例；(i)注释系列；(j)输出系列；(k)冻结系列；和(l)合并两个系列。上述功能被进一步被更详细描述。

用户可查看存储在系列中的信息，包括一个或多个病例标识符、病例修改信息、病例系列历史信息、与系列相关的任意其他信息、生成系列的查询标准、或系列的任意其他特性和/或元数据。查看可包括搜索和排序功能。用户也可保存系列并且赋予名称，使得它成为命名的系列。用户可使得系列成为活动系列。生成系列的用户可给系列赋予访问权限，诸如读访问和/或写访问等。另外，用户可给系列添加病例。用户也可从系列中删除病例。另外，用户可从病例系列库210中删除系列。此外，用户可以在系列的上下文中对系列中的病例进行文本注释。如果同一病例出现在其他系列中，则在不同系列中的所述病例的注释可以是独立的。用户也可在系列层面进行文本注释。此外，用户可将系列输出到文件。此外，用户可冻结系列，其中在所述系列中的病例数据被冻结的日期和时间以后，即使病例在诸如药品安全系统等的包括病例数据的对应数据源中被更新，所述系列中的所述病例数据也不改变。用户可解冻系列，以便所述病例数据能再次反映最新可用的修改。用户也可使用合并、交叠和减去操作来合并两个系列，并且由此生成新系列。

病例系列API 230还可提供功能以根据所述实施例执行产生、消费、搜索、和更新功能。在执行产生功能时，病例系列API 230可接收系列并且在病例系列库210内存储所述系列。在执行消费功能时，病例系列API 230可从病例系列库210中检索系列并且在软件应用中实施所述系列(诸如在软件应用的用户接口内显示所述系列)。在执行搜索功能时，病例系列API 230可搜索存储在病例系列库210内的系列。在执行更新功能时，病例系列API 230可更新存储在病例系列库210内的系列。

在某些实施例中，实施例可通过对诸如药品安全系统等的数据源执行查询来给病例系列库210添加新病例系列，其中由所述查询返回的一个或多个病例可作为病例系列存储在病例系列库210内。另外，在这些实施例的某些中，用户可以用不同于对数据源执行查询的其他方式来给病例系列库添加新系列。更具体地，用户可通过如下来添加新系列：(a)键入系列；或(b)输入系列。通过键入系列，用户可在病例系列库210内手动键入一个或多个病例标识符以生成一个或多个新系列。替代地，用户可从含有一个或多个病例标识符的文件中将新系列输入到病例系列库210。

图3示出了根据本发明的实施例的病例系列数据模型300的框图。在某些实施例中，病例系列数据模型300等同于图2的病例系列数据模型220。如前所述，病例系列数据模型300包括一个或多个病例系列的规范表示和与每个病例系列有关的信息，诸如与每个病例系列有关的病例系列历史信息和与每个病例系列有关的病例修改信息等。如以下更详细描述的，病例系列数据模型300可包括多个数据域，其中每个数据域可代表数据系列库(诸如图2的病例系列库210等)的数据域，并且其中每个数据域可通过病例系列API(诸如图2的病例系列API 230等)以它的唯一格式代表。

根据所述实施例，病例系列数据模型300包括病例系列310。病例系列310是一个或多个病例系列的规范表示。在某些实施例中，病例系列310包括多个数据域，其中每个数据域可存储所述一个或多个病例系列的每个病例系列的病例数据或元数据。在这些实施例的某些中，病例系列310包括可存储所述病例系列的病例的病例标识符的数据域，并且包括可存储代表包括在所述病例系列内的一个或多个不良事件病例的病例数据或元数据的一个或多个数据域。因此，病例系列310可存储用于所述病例系列的每个病例的病例标识符，并且病例系列310可存储与所述病例系列的每个病例有关的数据和/或元数据。因此，在这些实施例中，病例系列310可通过在多个数据域内存储多个值来代表一个或多个病例系列。

病例系列数据模型300也包括改变日志320。改变日志320是与病例系列有关的病例系列历史信息的规范表示。如前所述，病例系列历史信息可包括关于病例系列的历史的信息，诸如生成所述病例系列的个体、生成所述病例系列的机构、已修改过所述病例系列的一个或多个个体等。在某些实施例中，改变日志320包括一个或多个数据域，其中每个数据域可存储所述一个或多个病例系列的每个病例系列的病例系列历史信息。根据这些实施例，每个数据域可存储代表病例系列历史信息的不同分量的值。例如，改变日志320的第一数据域可存储生成病例系列的个体的名称，第二数据域可存储生成所述病例系列的机构的名称，第三数据域可存储修改所述病例系列的第一个体的名称，第四数据域可存储修改所述病例系列的第二个体的名称等。根据实施例，病例系列310和改变日志320可具有一对多关系，其中一个或多个改变日志可与一个病例系列关联。在一种实施例中，改变日志320可被实施为字符大对象(“CLOB”)，其中改变日志320的每个值可附到CLOB的结尾。

病例系列数据模型300也包括病例修改330。病例修改330是与一个或多个病例系列有关的病例修改信息的规范表示。更具体地，在某些实施例中，病例系列是包含一个或多个病例修改的容器。在某些场景中，病例系列可包含相同病例的多个病例修改。在其他场景中，病例系列包含用于病例系列的每个病例的一个病例修改。如前所述，病例修改信息包括关于病例系列的一个或多个修改和/或病例系列的一个或多个版本的信息，其中修改可以是对病例系列的不良事件病例的任意改变，而版本可以是已经根据定义的查看进程被确认的对病例系列的不良事件病例的改变。在某些实施例中，病例修改330包括一个或多个数据域，其中每个数据域可存储一个或多个病例系列的每个病例系列的病例修改信息。根据这些实施例，每个数据域可存储代表病例修改信息的不同分量的值。在某些实施例中，病例系列的修改和/或版本可以用等同于原始病例系列的格式的格式表示。因此，在这些实施例中，病例修改330包括可存储病例系列的病例的病例标识符的数据域，并且包括可存储病例系列的病例的病例数据或元数据的一个或多个数据域，其中所述病例数据或元数据包括对病例系列的不良事件病例的改变。在其他实施例中，病例系列的修改和/或版本可以用只包括对病例系列的不良事件病例的改变的格式来表示。因此，在这些实施例中，病例修改330包括存储有对病例系列的不良事件病例的改变的一个或多个数据域。根据实施例，病例系列310和病例修改330可具有一对多关系，其中一个或多个病例修改可与一个病例系列关联。在某些实施例中，病例修改330也包括可由两个额外数据域代表的时间戳信息，所述两个额外数据域是有效开始日期/时间数据域，和有效结束日期/时间数据域。时间戳信息可代表病例系列的修改或版本是有效的开始日期和/或时间以及结束日期和/或时间。此外，有效开始日期/时间以及有效结束日期/时间都是源数据的特征，所述源数据可使用病例修改信息启动病例系列的产生。时间戳信息可整体或部分地标识病例系列的修改或版本。

病例系列数据模型300也包括注释340。注释340是与病例系列的一个或多个病例修改相关的注释信息的规范表示。注释信息可包括任意用户定义的信息，其中用户定义的信息可用以注释病例系列的病例修改。在某些实施例中，注释340包括一个或多个数据域，其中每个数据域可存储用户定义的值。根据实施例，病例修改330和注释340可具有一对多关系，其中一个或多个注释可与一个病例修改关联。

病例系列数据模型300也包括文件夹350。文件夹350是一个或多个病例系列的逻辑分组的规范表示。随着时间推移，用户可使用病例系列数据模型300生成数以千计的病例系列。嵌套文件夹存储系统可用以组织所述病例系列。因此，一个或多个病例系列可与一个文件夹关联，并且一个或多个文件夹可嵌套在一个文件夹内。因此，根据实施例，文件夹350和病例系列310具有一对多关系，其中一个或多个病例系列可与一个文件夹关联。在一种实施例中，文件夹350不是病例系列数据模型300的一部分，但却是文档管理系统的文件夹功能的代表，所述文档管理系统被利用以将使用病例系列数据模型300生成的一个或多个病例系列组织进一个或多个文件夹。

图4示出了根据本发明的实施例的可互操作的病例系列系统的示例实施方式的框图。更具体地，图4示出了诸如图2的可互操作的病例系列系统200等的与多个软件应用交互的可互操作的病例系列系统的示例。所述实施方式包括病例系列库400。如前所述，病例系列库400是可存储诸如一个或多个病例系列等的数据、和/或与所述一个或多个病例系列有关的信息的库。在某些实施例中，病例系列库400等同于图2的病例系列库210。所述实施方式还包括病例系列数据模型410。也如前所述，病例系列数据模型410是可包括病例系列的规范表示和与所述病例系列有关的信息的数据模型。在某些实施例中，病例系列数据模型410等同于图2的病例系列数据模型220和图3的病例系列数据模型300。根据所述实施例，病例系列数据模型410可以是代表存储在病例系列库400内的数据的数据模型。在一种实施例中，病例系列数据模型410可包括多个数据域，其中多个数据域代表包括在病例系列库400内的多个数据域。

所述实施方式还包括数据挖掘应用420和数据挖掘应用病例系列API 430。根据所述实施例，数据挖掘应用420是包括可执行数据挖掘功能以在药品安全数据内找到一个或多个有关的病例组的一个或多个可执行进程的软件应用。数据挖掘应用420可使用一个或多个数据挖掘算法产生一个或多个病例系列。数据挖掘应用420还可消费由另一个软件应用产生的一个或多个病例系列。在一种实施例中，数据挖掘应用是来自Oracle公司的“Empirica Signal”产品。

也根据所述实施例，数据挖掘应用病例系列API 430提供接口使得：将病例系列模型410暴露给数据挖掘应用420，基于由数据挖掘应用420规定的格式向数据挖掘应用420呈现病例系列数据模型410，并且因此允许数据挖掘应用420与病例系列库400交互。因此，数据挖掘应用420可产生一个或多个病例系列，并且可使用数据挖掘应用病例系列API 430在病例系列库400内存储所述一个或多个产生的病例系列。同样，数据挖掘应用420可使用数据挖掘应用病例系列API 430从病例系列库400内检索一个或多个病例系列并且可以消费所述一个或多个检索的病例系列。在某些实施例中，数据挖掘应用病例系列API 430代表图2的病例系列API 230的组件。

所述实施方式还包括报告应用440和报告应用病例系列API 450。根据所述实施例，报告应用440是包括一个或多个可执行进程的软件应用，所述可执行进程可以执行报告功能以生成将一个或多个病例系列可视化的一个或多个报告。报告应用440可使用一个或多个报告算法产生一个或多个病例系列。报告应用440还可消费由另一个软件应用产生的一个或多个病例系列。在一种实施例中，报告应用440是来自Oracle公司的“Oracle Argus Insight”产品。

也根据所述实施例，报告应用病例系列API 450提供了接口使得：将病例系列数据模型410暴露给报告应用440，基于由报告应用440规定的格式向报告应用440呈现病例系列数据模型410，并且因此允许报告应用440与病例系列库400交互。因此，报告应用440可产生一个或多个病例系列，并且可使用报告应用病例系列API 450在病例系列库400内存储所述一个或多个产生的病例系列。同样，报告应用440可使用报告应用病例系列API 450从病例系列库400内检索一个或多个病例系列并且消费所述一个或多个检索的病例系列。此外，报告应用病例系列API 450可简化在报告应用440的报告中的病例系列的使用，可允许报告应用440的报告执行查询并且使用得到的病例系列，并且如果期望，可在病例系列库400中存储得到的病例系列供后续使用。在某些实施例中，报告应用病例系列API 450代表图2的病例系列API 230的组件。

因此，根据所述实施例，数据挖掘应用420可与报告应用440交互，并且反之亦然，因为报告应用440可访问由数据挖掘应用420产生的一个或多个病例系列，并且数据挖掘应用420可访问由报告应用440产生的一个或多个病例系列。本领域技术人员会容易理解数据挖掘应用420和报告应用440是根据所述实施例的产生和消费病例系列的软件应用的示例，并且在替代实施例中，数据挖掘应用420和报告应用440可用包括替代功能的其他软件应用代替。此外，可以存在支持任意数目的软件应用的任意数目的病例系列API，并且可使用病例系列数据模型410允许任意数目的软件应用访问病例系列库400。

图5示出了根据本发明的实施例的可互操作的病例系列模块的功能的流程图。在一种实施例中，图5的流程图的功能(在下面描述)，以及图8的流程图的功能(也在下面描述)每个都由存储在存储器或某些其他计算机可读或有形介质中并且被处理器执行的软件来实施。在其他实施例中，每个功能可由硬件(例如，通过使用专用集成电路(“ASIC”)、可编程门阵列(“PGA”)、现场可编程门阵列(“FPGA”)等)或硬件和软件的任意组合执行。

所述流程开始并且行进到510。在510处接收病例系列。在某些实施例中，从伙伴应用中接收病例系列。所述病例系列包括一个或多个不良事件病例，并且每个不良事件病例包括代表不良事件的数据记录。所述病例系列可以是命名的病例系列、活动用户病例系列、单次使用的病例系列、或病例清单。所述病例系列还可以是事件系列或产品系列。在某些实施例中，代表不良事件的每个数据记录还包括药品安全数据，其中药品安全数据包括与一种或多种药品的安全性有关的一个或多个报告或病人标识符。在某些实施例中，病例系列可包括多个病例修改。所述流程行进到520。

在520，接收与所述病例系列有关的信息。在某些实施例中，从伙伴应用中接收与所述病例系列有关的信息。在某些实施例中，与所述病例系列有关的信息包括病例修改信息，其中病例修改信息可包括对病例系列的不良事件病例的至少一个改变。在这些实施例中，包括病例修改信息的病例修改被接收。在某些实施例中，如果根据定义的查看进程确认了对所述病例系列的不良事件病例的至少一个改变，则包括病例修改信息的病例版本被接收。此外，在某些实施例中，病例修改信息包括标识所述病例修改的时间戳信息。所述时间戳信息可包括有效开始日期和/或时间以及有效结束日期和/或时间。

在其他实施例中，与病例系列有关的信息包括病例系列历史信息，其中病例系列历史信息可包括关于病例系列的历史的信息，诸如生成所述病例系列的个体、生成所述病例系列的机构、已修改过所述病例系列的一个或多个个体等。在这些实施例中，生成包括病例系列历史信息的改变日志。在其他实施例中，与所述病例系列有关的信息包括用户定义的信息。在这些实施例中，生成包括所述用户定义的信息的注释。在其他实施例中，与病例系列有关的信息包括所述病例系列和一个或多个额外病例系列的逻辑组织。在这些实施例中，生成包括所述病例系列和一个或多个额外病例系列的逻辑组织的文件夹。所述流程行进到530。

在530，使用病例系列数据模型将病例系列和与所述病例系列有关的信息存储在病例系列库内。病例系列库是可存储诸如一个或多个病例系列和与所述一个或多个病例系列有关的信息等的数据的库。病例系列数据模型是病例系列的规范表示，所述病例系列数据模型定义所述病例系列库内的病例系列和与所述病例系列有关的信息的格式。

在与病例系列有关的信息包括病例修改信息的实施例中，所述病例系列数据模型定义病例系列库内的病例修改的格式。在与病例系列有关的信息包括病例系列历史信息的实施例中，所述病例系列数据模型定义病例系列库内的改变日志的格式。在与病例系列有关的信息包括用户定义的信息的实施例中，所述病例系列数据模型定义病例系列库内的注释的格式。在与病例系列有关的信息包括所述病例系列和一个或多个额外病例系列的逻辑组织的实施例中，所述病例系列数据模型定义病例系列库内的文件夹的格式。

在某些实施例中，病例系列数据模型包括代表病例系列的一个或多个病例标识符的数据域，和代表病例系列的一个或多个不良事件病例的一个或多个额外数据域。在这些实施例中，每个病例标识符唯一地标识所述一个或多个不良事件病例的不良事件病例。此外，在某些其他实施例中，病例系列数据模型包括代表与病例系列有关的信息的一个或多个额外数据域。

在与病例系列有关的信息包括病例修改信息的实施例中，所述病例系列数据模型包括代表所述病例修改信息的一个或多个额外数据域。在病例修改信息包括时间戳信息的实施例中，所述病例系列数据模型包括代表所述时间戳信息的一个或多个额外数据域。在与病例系列有关的信息包括病例系列历史信息的实施例中，所述病例系列数据模型包括代表所述病例系列历史信息的一个或多个额外数据域。在与病例系列有关的信息包括用户定义的信息的实施例中，所述病例系列数据模型包括代表所述用户定义的信息的一个或多个额外数据域。在与病例系列有关的信息包括所述病例系列和一个或多个额外病例系列的逻辑组织的实施例中，所述病例系列数据模型包括代表所述病例系列和一个或多个额外病例系列的逻辑组织的一个或多个额外数据域。所述流程行进到540。

在540，使用病例系列数据模型将与病例系列有关的信息与所述病例系列关联。在与病例系列有关的信息包括病例修改信息的实施例中，使用病例系列数据模型将所述病例修改与所述病例系列关联。在与病例系列有关的信息包括病例系列历史信息的实施例中，使用病例系列数据模型将改变日志与所述病例系列关联。在与病例系列有关的信息包括用户定义的信息的实施例中，使用病例系列数据模型将注释与所述病例修改关联。在与病例系列有关的信息包括所述病例系列和一个或多个额外病例系列的逻辑组织的实施例中，所述病例系列与所述文件夹关联。所述流程行进到550。

在550，使用病例系列API从所述病例系列库中检索病例系列和与所述病例系列有关的关联信息。病例系列API是基于由软件应用规定的格式向软件应用呈现病例数据模型的API。因此，病例系列API可为软件应用定义病例系列和与所述病例系列有关的信息的格式。病例系列API可使用病例系列数据模型从病例系列库中检索病例系列和与所述病例系列有关的信息。所述流程然后结束。

图6示出了根据本发明的实施例的队列识别系统600的框图。图6中加阴影的队列识别系统600的组件是可依赖数据源的数据模型而改变的组件，如下面更详细描述的。队列识别系统600可包括查询生成器用户接口(“UI”)605。查询生成器UI 605是可向队列识别系统600的用户显示的用户界面，其中查询生成器UI 605可允许用户生成查询。在其他实施例中，查询生成器UI 605可显示数据源的一个或多个数据域，并且用户可选择一个或多个数据域的至少一个作为查询的一部分。在这些实施例中，用户也可键入可作为查询的一部分的标准。如将更详细描述的，由用户生成的查询可对诸如药品安全系统等的数据源执行，以检索存储在诸如药品安全系统等的数据源内的数据。在某些实施例中，用户可键入SQL语法用于查询生成器UI 605内的查询。此外，在某些实施例中，查询生成器UI 605可允许查询的作者规定被识别为参数的一个或多个占位符。当执行查询时，用户可被提示为每个参数键入参数值。此外，查询生成器UI 605可允许用户执行查询。

队列识别系统600也可包括元数据610。根据所述实施例，元数据610描述数据源内的数据，诸如数据安全系统内的数据安全数据等。更具体地，元数据610描述关于可被查询的数据源的每个数据域的信息。这种信息可包括构建包括数据域的SQL查询所需的数据域和信息的数据类型。元数据610也可包括可从源数据或源数据与参考数据的组合中导出的一个或多个查询域。根据所述实施例，查询生成器UI 605可检索元数据610以便用户可使用查询生成器UI 605基于元数据610生成查询。由于元数据610，队列识别系统600不限于仅被操作性地耦接到特定数据源或数据源的特定数据模型。相反，队列识别系统600是数据模型无关的并且可操作性地与各种数据源耦接，如将更详细描述的。元数据610可存储在队列识别系统600内包含的任意数据结构中，诸如库等。

队列识别系统600还可包括查询库615。查询库615是可存储一个或多个查询的库。根据所述实施例，查询生成器UI 605可在查询库615内存储在查询生成器UI 605内生成的查询。当确定查询可能以后被重新使用时，诸如当查询可检索可能会在很多场景中使用的数据时，在查询生成器UI 605内生成的查询可存储在查询库615内。

队列识别系统600还可包括查询编译器620。查询编译器620可检索存储在查询库615内的查询并且可编译所述存储的查询。通过编译所述存储的查询，查询编译器620可将查询转换成可执行格式，以便所述存储的查询可被编译。在某些实施例中，一旦查询已经被转换为可执行格式，查询编译器620还可执行所述查询。在执行查询时，查询编译器620可对数据源执行查询，并且可检索和存储基于所述查询由所述数据源返回的数据。在某些实施例中，由所述数据源返回的数据包括药品安全数据，其中药品安全数据包括一个或多个不良事件病例，其中每个不良事件病例都是代表不良事件的数据记录。此外，执行所述查询可生成病例系列。

队列识别系统600还可包括病例系列库625。病例系列库625是可存储诸如一个或多个病例系列等的数据的库。例如，在病例系列包括一个或多个病例标识符并且还包括共同代表包括在所述病例系列内的一个或多个不良事件病例的病例数据和/或病例元数据的实施例中，病例系列库625可存储所述一个或多个病例标识符以及关联的病例数据和/或病例元数据。根据所述实施例，一旦查询编译器620执行查询并且生成病例系列，则查询编译器可在病例系列库625内存储所述生成的病例系列。在某些实施例中，病例系列库625可包括关联的病例系列数据模型(图6未示出)，所述关联的病例系列数据模型可包括病例系列的规范表示。例如，在病例系列包括一个或多个病例标识符并且还包括共同代表包括在所述病例系列内的一个或多个不良事件病例的病例数据和/或病例元数据的实施例中，所述病例系列数据模型可包括代表所述病例标识符的数据域，和代表病例数据和/或病例元数据的一个或多个额外数据域。在某些实施例中，病例系列库625等同于图2的病例系列库210和图4的病例系列库400。

队列识别系统600也可包括报告病例系列API 630。根据所述实施例，报告病例系列API 630是可暴露与病例系列库625关联的病例系列数据模型，并且可基于由报告应用(诸如报告应用640等)规定的格式向报告应用呈现与病例系列库625关联的病例系列数据模型的API。因此，报告病例系列API 630可允许报告应用(诸如报告应用640等)与病例系列库625对接。换句话说，报告病例系列API 630可从病例系列库625中检索病例系列并且在报告应用(诸如报告应用640等)内实施所述系列。在某些实施例中，报告病例系列API 630代表图2的病例系列API 230的一部分，并且等同于图4的报告病例系列API 450。报告应用640是包括一个或多个可执行进程的软件应用，所述可执行进程可以执行报告功能以生成将一个或多个病例系列可视化的一个或多个报告。生成一个或多个报告可包括在报告应用640内显示所述一个或多个报告。报告应用640也可使用一个或多个报告算法生成一个或多个病例系列。报告应用640还可使用报告病例系API 630消费由队列识别系统600产生的存储在病例系列库625内的一个或多个病例系列。在某些实施例中，报告应用640等同于图4的报告应用440。

队列识别系统600还可包括可互操作的病例系列API 635。根据所述实施例，可互操作的病例系列API 635是可暴露与病例系列库625关联的病例系列数据模型，并且可基于由伙伴应用规定的格式向伙伴应用(诸如伙伴应用650等)呈现与病例系列库625关联的病例系列数据模型的API。因此，可互操作的病例系列API 635可允许伙伴应用(诸如伙伴应用650等)与病例系列库625对接。换句话说，可互操作的病例系列API 635可从病例系列库625中检索病例系列并且在伙伴应用(诸如伙伴应用650等)内实施所述系列。伙伴应用650是可使用可互操作的病例系列API 635消费由队列识别系统600产生的存储在病例系列库625内的一个或多个病例系列的软件应用。伙伴应用650也可提供其他功能，诸如使用可互操作的病例系API 635生成可存储在病例系列库625内的一个或多个病例系列等。在某些实施例中，可互操作的病例系列API 635等同于图2的病例系列API 230。

队列识别系统600也可包括编译器规则645。根据所述实施例，编译器规则645可包括可由查询编译器620向由查询生成器UI 605生成的查询施加的一个或多个语法规则，以确定查询利用所述一个或多个语法规则编译。编译器规则645可存储在包含在队列识别系统600内的任意数据结构中，诸如库等。

队列识别系统600可包括本体(ontology)浏览器UI 655。在数据源是参考本体数据源的实施例中，其中参考本体数据源在下面被更详细描述，本体浏览器UI 655可从参考本体数据源中检索一个或多个参考本体并且在UI内向队列识别系统600的用户显示所述一个或多个参考本体。因此，来自本体的一个或多个元素可被选择和用作查询中的标准。

队列识别系统600还可包括病例系列编辑器和管理UI 665。病例系列编辑器和管理UI 665可允许队列识别系统600的用户编辑和管理存储在病例系列库625内的一个或多个病例系列。

队列识别系统600还可包括病例系列查看器UI 675。病例系列查看器UI 675可允许队列识别系统600的用户查看一个或多个病例系列。所述一个或多个病例系列可存储在病例系列库625内。替代地，所述一个或多个病例系列可存储在数据源内。

此外，根据所述实施例，队列识别系统600可操作性地耦接到一个或多个数据源。如前所述，队列识别系统600的组件(即，查询生成器UI 605和查询编译器620)可允许用户对操作性地耦接到队列识别系统600的一个或多个数据源生成和执行一个或多个查询。在某些实施例中，所述一个或多个数据源可包括药品安全数据，并且在这些实施例的某些中，药品安全数据可包括与一个或多个药品的安全性有关的数据，诸如一个或多个不良事件病例等。在图6示出的实施例中，所述一个或多个数据源包括参考本体数据源660和不良事件报告数据库670、680和690。参考本体数据源660是包括关于参考本体的数据的数据源。参考本体数据源660的示例包括医学系统命名法(“SNOMED”)数据源、用于管理活动的医学辞典(“MedDRA”)数据源、或世界卫生组织(“WHO”)药品数据源。不良事件报告数据库678、680和690是包括药品安全数据的数据源，其中所述药品安全数据包括一个或多个不良事件病例。但是，这些数据源仅是根据示出的实施例的示例数据源，并且在替代实施例中，队列识别系统600可操作性地耦接到任意数目的数据源，并且每个数据源可以是包括数据的任意类型的数据源。

队列识别系统600还可包括联合查询执行引擎685。联合查询执行引擎685可允许存储的查询对多个数据源被编译和执行。联合查询执行引擎685还可将从每个数据源中返回的一个或多个病例系列合并成单个病例系列。

队列识别系统600也可包括灵活重分类API 695。灵活重分类API695可规范化到在数据源中使用的一个或多个代码列表的接口。在多数健康相关数据库中，离散值以代码存储。代码列表可被用以显示一个或多个自然语言等效术语。此特征可允许用户以他的或她的自己的语言来规定查询标准。此外，诸如“大陆”等的一个或多个卷起(roll-up)术语可被用以指代诸如国家等的一组离散值。灵活重分类API 695也可允许诸如年龄等的连续变量的一个或多个范围被映射为诸如“成人”或“孩子”等的一个或多个离散的命名的目录。灵活重分类API 695可允许在报告中使用相同代码映射，因此确保查询与报告之间的一致性。

图7示出了根据本发明的实施例的队列识别系统的示例实施方式的框图。在710，生成查询。所述查询可对诸如药品安全系统等的数据源执行，以检索存储在数据源内的诸如药品安全数据等的数据。根据所述实施例，为生成所述查询，可检索元数据，其中所述元数据描述数据源内的数据。更具体地，元数据可描述关于可被查询的数据源的每个数据域的信息。这种信息可包括构建包括数据域的SQL查询所需的信息和数据域的数据类型。生成的查询进一步存储在查询库720中，其中查询库720是可存储诸如一个或多个查询的数据的库。

在730，从查询库720检索查询，其中所述查询对不良事件报告数据库740被编译和执行，所述不良事件报告数据库740是数据源的示例。不良事件报告数据库740是包括药品安全数据的数据源，其中药品安全数据包括一个或多个不良事件病例。在执行所述查询时，诸如药品安全数据等的数据可从不良事件报告数据库740中被检索。此外，在执行所述查询时，病例系列可在病例系列库750内被生成和存储。

在760，病例系列从病例系列库750中被检索，并且生成可以将病例系列可视化的报告770。根据实施例，报告病例系列API可与病例系列库750对接并且从病例系列库750中检索病例系列并且在报告应用内实施所述病例系列，以生成可以将病例系列可视化的一个或多个报告，其中所述报告应用可显示所述生成的一个或多个报告。在某些实施例中，在760执行的所述报告的生成，可包括从不良事件报告数据库740中检索数据。

图8示出了根据本发明的实施例的队列识别模块的功能的流程图。所述流程开始并行进到810。当用户指示他或她想生成查询时，所述流程可以开始。在810，元数据被检索，其中所述元数据包括关于数据源的一个或多个数据域的信息。根据所述实施例，所述信息可包括用于一个或多个数据域的每个数据域的数据类型和SQL信息。在某些实施例中，数据源可以是存储一个或多个不良事件病例的不良事件报告数据库。所述流程行进到820。

在820，基于检索的元数据对于数据源生成查询。所述查询可以是对数据源执行的查询，以检索数据源内存储的数据。在某些实施例中，检索的元数据可被用以确定是所述查询的一部分的数据源的一个或多个数据域。另外，在某些实施例中，检索的元数据可用以确定是所述查询的一部分的SQL。所述流程行进到830。

在830，基于一个或多个编译器规则编译查询。根据所述实施例，编译器规则可包括向查询应用的一个或多个语法规则，以确定所述查询利用一个或多个语法规则编译。在某些实施例中，所述查询可存储在查询库中。所述流程行进到840。

在840，对数据源执行查询，其中所述查询的执行生成病例系列。在某些实施例中，所述病例系列包括一个或多个不良事件病例，其中每个不良事件病例都包括代表不良事件的数据记录。在这些实施例的某些中，每个代表不良事件的数据记录还包括药品安全数据，其中药品安全数据包括与一个或多个药品的安全性有关的一个或多个报告或病人标识符。在某些实施例中，所述病例系列存储在病例系列库中。所述流程行进到850。

在850，基于所述病例系列生成报告，其中所述报告是所述病例系列的可视化。在某些实施例中，所述报告包括所述病例系列的一个或多个数据域的可视化显示。根据某些实施例，可使用报告病例系列API从病例系列库中检索所述病例系列，其中所述报告病例系列API定义用于报告应用的病例系列的格式。在这些实施例中，报告可在报告应用内显示。另外，在某些实施例中，可使用可互操作的病例系列API从病例系列库中检索所述病例系列，其中所述可互操作的病例系列API定义用于伙伴应用的病例系列的格式。在这些实施例中，所述病例系列可在伙伴应用内被消费。所述流程接着结束。

图9示出了根据本发明的实施例生成示例病例系列920的示例查询910，所述示例病例系列920生成示例报告930。根据实施例，可执行进程可对诸如药品安全系统等的数据源执行查询910，其中查询910是检索所有致命不良事件病例(即，数据域“死亡”的值为1的所有不良事件病例)的查询。

根据所述实施例，查询910的执行产生病例系列920，其中病例系列920包括匹配在查询910规定的条件的不良事件列表。病例系列920可包括用于每个不良事件病例的至少一个病例标识符，并且也可包括代表病例系列中的不良事件病例的额外病例数据或元数据。在所示实施例中，病例系列920包括多个不良事件病例，其中每个不良事件病例包括：(a)病例标识符数据域，其中每个值标识用于不良事件病例的病例标识符；以及(b)国家数据域，其中每个值标识不良事件病例与之关联的国家。

根据实施例，可执行进程可基于病例系列920生成报告930。报告930是病例系列920的可视化，其中病例系列920的数据域可基于期望格式而改变。在所示实施例中，报告930包括多个不良事件病例，其中每个不良事件病例包括：(a)病例标识符数据域，其中每个值标识用于不良事件病例的病例标识符；(b)“严重”数据域，其中每个值标识是否所述不良事件病例是严重的不良事件病例；以及(c)“列出”数据域，其中每个值标识是否所述不良事件病例是列出的不良事件病例。本领域技术人员会容易理解查询910、病例系列920和报告930的格式是根据示例实施例的示例格式，并且在替代实施例中这些查询、病例系列、和/或报告可具有其他格式。

因此，在一种实施例中，提供了可识别诸如病人队列等的队列的队列识别系统。所述队列识别系统可检索元数据，所述元数据描述数据源和用于数据源的SQL，并且所述队列识别系统可基于检索的元数据对数据源生成和执行一个或多个查询。因为元数据准确描述了数据源，所以队列识别系统可以独立于数据源的数据模型，并且可被可操作地耦接到种类繁多的数据源，并且因此可跨许多不同领域使用。因为数据源通常仅在于它的基础数据模型方面不同，并且因为队列识别系统不需要包括对数据源的基础数据模型的依赖，所以队列识别系统可应用于不限于药品安全领域的更大的领域的队列识别。因此，根据某些实施例，可以降低向任意一个伙伴应用提供队列识别的成本。此外，根据某些实施例，可给伙伴应用提供更完整的队列识别特征集合。

贯穿本说明书描述的本发明的特征、结构、或特性可在一个或多个实施例中以任何合适的方式组合。例如，贯穿本说明书的“一种实施例”、“某些实施例”、“特定实施例”或其他类似语句的使用指代了如下事实，即结合所述实施例描述的特定特征、结构、或特性可被包括在本发明的至少一种实施例中。因此，贯穿本说明书出现的短语“一种实施例”、“某些实施例”、“特定实施例”或其他类似语句不必都指代实施例的相同的组，并且所述描述的特征、结构、或特性可在一个或多个实施例中以任何合适的方式组合。

本领域技术人员会容易理解，以上讨论的发明可使用不同顺序的步骤来实践，和/或使用与本公开的那些不同的配置中的元件来实践。因此，尽管本发明已经基于这些优选实施例被描述，但是对本领域技术人员清晰的是，某些仍然落入到本发明的精神和范围内的修改、变种、和替代构建会是清晰的。为确定本发明的界线和边界，因此，应当参考所附权利要求书。