CN101529453A - 医疗评估支持系统及方法 - Google Patents

Abstract

本发明专注于一种医疗评估支持系统。在一个实施例中，用户输入查询，该查询识别患者已经历的不良事件、以及患者已经历的疾病(病症、紊乱、症状、状况等等)。作为响应，系统促使执行一个或多个数据库搜索以为具有被识别的疾病的患者识别该不良事件的一个或多个可能的原因。在另一实施例中，用户输入患者已服用的一个或多个药物、以及患者已经历的一个或多个疾病的组合。系统操作以确定是否存在与所指定的组合相关联的不良事件，并且向用户报告任何这样的不良事件。系统保持任何这样的报告的副本，用于与随后的搜索进行比较，以便避免多次报告相同的可能的不良事件。系统以预定的日程进行任何这样的搜索，或者可以以用户的请求进行任何这样的搜索。在另一实施例中，系统将不良事件－药物－疾病的相关性与电子医疗记录(EMR)系统相结合，以便向卫生保健机构或者用户识别可能潜在地处于针对这些不良事件的危险中的患者。

Description

医疗评估支持系统及方法

技术领域

本发明涉及一种基于计算机的医疗评估支持系统，用于接收由用户提供的与患者相关的数据、处理该数据以识别可能影响对患者的治疗的信息源、并且向用户提供对患者进行治疗中可能有用的信息。

背景技术

在一些情形下，患者经过治疗而随后经历了不良事件，即，患者的状况恶化。当前，存在大量的可用于分析在该不良事件和治疗之间是否存在因果关系的计算机系统。

参照图1，一个这样的系统允许用户指定患者正在经历或者已经历的不良事件。作为响应，系统执行数据库搜索以识别涉及该不良事件的数据库中的所有的信息源，并且将搜索的结果提供给用户。例如，如果用户指定“心悸”作为不良事件，则该系统搜索数据库以识别涉及“心悸”的数据库中的所有的信息源，并且将搜索的结果提供给用户。

参照图2，当前可用的另一系统允许用户指定正在给患者吃(administer)或者已经给患者吃的药物、以及该患者随后经历的不良事件。作为响应，系统搜索药物说明书(Pharmaceutical Package Insert)(“PPI”)(由处方药的制造商准备的书面材料并且伴随着给患者的处方(dispensation))的数据库，用于讨论所指定的药物的PPI内的不良事件。例如，如果用户指定“流血”作为不良事件，并且指定药物为法华林(warfin)钠，则该系统搜索针对法华林钠PPI的PPI的数据库，并且确定用于法华林钠的PPI是否将流血识别为不良事件。将搜索的结果提供给用户。

参照图3，当前已知的又一系统确定是否存在与药物的组合相关联的任何已知的不良事件。在这个系统中，用户输入患者正服用或者已服用的两个或多个药物。系统利用此信息来搜索牵涉所指定的药物的组合或者多个组合的已知的不良事件。将搜索的结果提供给用户。例如，如果用户指示患者正在服用或者已服用了“药物A”和“药物B”，则系统搜索数据库以确定是否存在与已服用了“药物A”和“药物B”的患者相关联的一个或多个已知的不良事件，并且将结果报告给用户。

发明内容

本发明专注于一种医疗评估支持系统，该系统能够向系统的用户提供关于不良事件的原因是否与患者正经受或者已经受的治疗相关的更精确的评估。向患者提供的治疗可以采取许多的形式。通常，治疗是以已经给患者吃的药物或者多个药物的形式。术语“药物”包括但不限于任何治疗的试剂，无论是小的分子(molecule)、生物学的、同种疗法的混合物(homeopathicconcoction)，或者可以治疗地(therapeutically)给予服用的任何物质。治疗也可以是以疗法(therapy)的形式(诸如辐射疗法)。典型地，系统的用户是医疗机构(“HCP”)。然而，系统可以被用于或者适于非HCP的个人(诸如患者)使用。

在一个实施例中，系统包含通信接口，该通信接口向系统提供了以下能力：(a)与用户进行通信；以及(b)与可能具有与一个或多个不良事件相关的信息的信息源进行通信。该系统还包含处理引擎，该处理引擎经由通信结构从用户接收查询，搜索可能具有与该查询相关的信息的一个或多个信息源，并且经由通信接口向用户传送搜索的结果。该系统的另一部分是包含由处理引擎响应查询所搜索的信息的数据结构。典型地，该数据结构由一个或多个数据库、以及保存(多个)数据库的记录介质组成。应当理解的是：可以将通信接口、处理引擎以及数据结构集成到能够位于有限的空间或者能够分布在网络上的结构中。此外，该系统能够在这样的系统内运行：在其中，通信接口便利于通过广域网(例如互联网)、局域网与一个或多个用户进行通信，或者其作为没有网络环境也能运作的独立系统。

由该系统接收的查询，指定患者在治疗之后已经历的一个或多个不良事件、以及已知患者正经历的并且患者正在被治疗所针对的(多个)疾病(即，疾患、紊乱、症状、状况等等)。系统搜索一个或多个信息源以识别展示每个指定的不良事件和每个指定的疾病之间的相关性的信息。将搜索的结果(其可以是正面的或者是负面的)经由通信接口传达给用户。在一些情形下，该结果将识别用于治疗疾病、并且已知与所指定的不良事件具有一些联系的药物或者多个药物。在许多情形中，这种类型的结果通常引起HCP与患者之间关于患者的药物治疗方案的更集中的讨论。

在系统的另一实施例中，由系统接收并且处理的查询指定：(a)患者在治疗之后经历的一个或多个不良事件；(b)已知患者正经历的并且该患者正被治疗所针对的(多个)疾病(即，疾患、紊乱、症状、状况等等)；以及(c)正对患者应用的或者已应用的治疗。处理引擎促使搜索一个或多个信息源以识别信息，其展示：(a)每个指定的不良事件和每个指定的疾病之间的相关性；以及(b)每个指定的不良事件和每个指定的治疗之间的相关性。将搜索的结果(其可以是正面的或者是负面的)经由通信接口传达给用户。在一些实例中，与搜索不良事件与所指定的疾病之间的相关性有关的结果，将识别与所指定的事件具有一些联系但没有在查询中被识别的药物或者多个药物。这种类型的结果通常导致对患者的药物治疗方案的进一步调查。

在系统的另一实施例中，由系统接收并且处理的查询指定一个或多个不良事件、以及已知患者已经历的药物和/或(多个)治疗。响应于所接收的查询，处理引擎促使搜索一个或多个信息源以识别展示每个指定的不良事件和指定的药物和/或(多个)治疗的每一个之间的相关性的信息。将结果(正面的或者负面的)经由通信接口传达给用户。应当理解的是，当指定多个药物时，系统同时提供针对所有指定的药物的结果，由此避免多重搜索。

系统的另一实施例还包含查询扩展(expansion)处理引擎，其实施实体论(ontology)以在促使对一个或多个信息源的一个或多个搜索中扩展由处理引擎使用的术语(term)，从而潜在地识别在搜索被局限于如提交的查询中所提出的术语的情况下将不会被识别的信息。例如，如果查询是“升高的(elevated)肝功能测试”，则实体论可扩展搜索术语或者短语以包括：升高的肝酶、肝毒性(liver toxicity)、肝中毒(hepatotoxicity)、异常肝测试、黄疸等等。在静态的实体论的情形下，处理引擎基于该查询、以及依据努力地将该实体论应用到该查询以扩展随后要被搜索的术语和/或短语的结果，执行搜索。允许用户在进行搜索之前和/或之后修改基于实体论的扩展搜索术语的结果也是可行的。修改可以包含向将查询应用到实体论上的结果移除术语或短语和/或增加术语或短语，从而更改实体论的结构。自然语言处理引擎(“NLP”)是作为对实体论处理引擎的可替换项或者补充，所述自然语言处理引擎辨别查询的情境，并且这样做能够推导出或者提示用于搜索的可替换的术语或者短语，由此返回给用户的结果可以比单独使用实体论处理引擎得出的结果更多处于预期的情境中。

系统的另一实施例能够警告用户对用户的查询的响应所依赖的信息已经改变，从而警告用户由用户基于该响应所做出的任何决定可能需要修改。例如，如果对于查询的响应指示：在搜索中所识别的引用(reference)指示未知在该查询中指定的不良事件与也在该查询中指定的药物的相关联，但是，该引用随后被修改以指示：现在已知所指定的不良事件与所指定的药物相关联，则系统将通知用户这种改变，这样用户可以考虑是否需要响应该查询所采取的行动的过程中的任何改变。在一个实施例中，将查询、与识别在向该查询提供响应中所依赖的引用的信息存储在一起。系统也存储生成响应中已依赖的每个引用的“旧”的副本，并且有时从引用的源恢复引用的“新”的副本，并且将“旧”的副本与“新”的副本进行比较。如果在引用中已存在改变，则通知用户并且向用户提供新的信息。

在另一实施例中，系统能够警告用户已报告了不良事件与药物、两个或多个药物、疾病、两种或多种疾病、或者它们的组合有关。用户指定药物、多个药物、疾病、以及多个疾病的感兴趣的组合。处理引擎26然后以指定的次数(典型地是以每天为基础)进行一个或多个搜索以识别满足用户的指定的不良事件的报告。如果识别出满足用户的指定的不良事件的报告，则将该结果报告给用户。也将该结果存储，并且将该结果与来自随后的搜索的结果进行比较，以便确定随后的搜索是否正在识别应当报告给用户的任何新的不良事件的报告。无论如何，一旦用户被告知这样的不良事件的报告，则用户可以随后做出关于是否搜索他们的医疗记录系统(电子的(EMR)或相反的(or otherwise))决定，以便识别潜在地处于危险中的患者。可替换地，系统可以存储用户的EMR(去识别(de-identified)的或相反的)，并且自动地或者基于用户的授权而搜索EMR以识别处于或者可能处于危险中的患者，并且将结果报告给用户，该用户然后可以采取可能是适当的任何行动。

在另一实施例中，系统包括EMR“命中(hit)报告器”，其允许系统识别以下这些状况：在其中，进行对用户的EMR系统或者用户的去识别的EMR的搜索，并且，该搜索基于依照用户对所感兴趣的药物、多个药物、疾病、多个疾病、或者它们的组合的指定而进行的搜索，识别潜在地处于不良事件的危险中的一个或多个个人。

附图说明

图1图示了向用于识别与个人经历的不良事件相关联的原因或多个原因的已知系统的输入(不良事件)；

图2图示了向用于识别药物是否是、或者是否可能是个人经历的不良事件的原因的已知系统的输入(不良事件、以及个人正在或者已服用的药物)；

图3图示了向用于识别药物-药物相互作用是否是、或者是否可能是个人经历的不良事件的原因的已知系统的输入(不良事件、以及个人正在或者已服用的药物)；

图4图示了本发明的系统的一个实施例；

图5A图示了形成由图4中图示的系统所处理的查询的输入(不良事件和(多个)疾病)；

图5B图示了由图4中所示的系统在处理如图5A中所图示的查询中实施的方法；

图6图示了形成由图4中图示的系统所处理的查询的输入(不良事件和药物/(多种)治疗)；

图7图示了形成由图4中图示的系统所处理的查询的输入((多个)不良事件、(多个)药物、以及(多种)疾病)；

图8是能够用于对将升高的肝功能测试识别为不良事件的查询进行扩展的实体论的例子；

图9是对图8中所图示的实体论的修改的例子，该例子向实体论增加了术语；

图10A和10B图示了：查询；基于实体论的搜索术语扩展；基于该查询和经扩展的搜索术语的、自然语言处理器搜索或者发掘操作(miningoperation)的结果；该搜索或者发掘操作的未进行优先级区分(unprioritized)的结果；以及该搜索或者发掘操作的经过优先级区分(prioritized)的结果。

具体实施方式

图4图示了根据本发明的、用于提供与不良事件有关的信息的医疗评估支持系统的实施例。下文中将系统的这个实施例称为系统20。系统20由以下组成：(a)用户接口22，其便利于系统20和与用户相关联的电子设备或计算设备之间的通信；(b)数据接口24，其便利于系统20和一个或多个数据源或者信息源之间的通信，所述数据源或者信息源用于对用户通过用户接口22传达到系统20的查询进行服务；以及(c)处理引擎26，其响应于通过用户接口22所提交的用户查询，促使进行数据源或信息源的一个或多个搜索，并且通过用户接口22向用户提供该搜索或者多个搜索的结果。

继续参照图4，用户接口22由网络服务器28组成，该网络服务器28能够和与用户相关联的电子设备或者计算设备所实现的客户端网络浏览器进行通信。服务器28能够与之通信的电子设备或者计算设备包括但不限于：能够运行网络浏览器的个人计算机、PDA、以及蜂窝电话。服务器28给客户端浏览器提供包含经由高速缓存服务器页面(CSP)链接到数据库管理系统的字段(field)的表格(form)的显示。服务器28和客户端浏览器保持一对一相关联，其包括但不限于以下：(1)药物信息条目(entry)(多个)字段；(2)疾病信息条目(多个)字段；(3)数据源信息条目(多个)字段；以及(4)不良事件信息条目(多个)字段。将所有的字段链接到DBMS中内部存储的信息。应当理解的是，如果需要通过除了该网络之外的网络(广域或者局域)进行与一个或多个用户通信，则可以以另一类型的服务器来取代或补充网络服务器28。服务器28还能够和与用户相关联的电子设备或者计算设备通信并且能够进行HL7消息传送(messaging)(在卫生保健业(healthcare industry)中被广泛使用的消息传送标准)。服务器28适于卫生保健业中出现的、或者由卫生保健业将来所采用的其他消息传送协议。将服务器28图示为具有网络浏览器端口和HL7端口的单个服务器。然而，应当理解的是，服务器28可以包含多个服务器，其每个具有一个或多个端口。

用户接口22还由传统(custom)集成解决方案接口30组成，所述传统集成解决方案接口30允许用户绕过(bypass)服务器28，并且直接访问与处理引擎26相关联的、数据库管理系统或者多个数据库管理系统。传统集成解决方案接口30接受根据有关数据库或者面向对象的数据库协议的查询。例如，接口30能够接收利用用于SQL类型查询的ODBC或者JDBC协议的有关数据库查询，并且能够以SQL格式传送响应。该接口还能够接收基于JAVA、C++、VB、SOAP，.NET等等的查询，并且能够以适当的格式传送响应。如果出现需要，则接口30能够适于与其他的协议进行集成。通过将处理引擎26基于高速缓存(CACHE)来实现处理有关的、或者面向对象的数据库查询的能力，所述高速缓存(CACHE)是协议智能的(protocol-intelligent)，即，能够辨别查询所基于的协议。应当理解的是，也可以采用协议智能的其他任何系统。

系统20通过每个与服务器26和传统集成解决方案接口30相关联的浏览器端口和HL7端口来提供与用户的通信。应当理解的是，可以使系统20适于采用这些各种接口的子集来用于与用户相关联的电子设备或者计算设备进行通信。此外，该系统可以适于采用现在可用的或者可能在将来成为可用的其他的接口用于和与用户相关联的电子设备或者计算设备进行通信。

继续参照图4，使用数据接口24向数据源传送对数据或者信息的请求，并且从这些源接收数据或者信息，利用所述数据或者信息来建立成为处理引擎26的一部分的一个或多个数据库，所述数据源典型地是商用数据源，但还可以包括私有的、专有的、或者公开的数据源。在所图示的实施例中，数据接口24用于向数据源传送请求，并且接收对任何这样的请求的响应，所述数据源提供生物标志(biomarker)数据、安全数据、药物说明书(PPI)数据、药物公司医疗信息(MT)证(letter)、白皮书(未示出)、临床试验数据、微阵列(microarray)数据、染色体组的和/或蛋白质组(proteomic)的数据、单核苷多态(SNP)、药物反应仿真系统等等。数据接口24能够向提供著名(noted)类型的数据或者信息的子集的一个或多个数据源，传送请求并且接收响应。数据接口24也能够适于向提供来自著名类型的数据或者信息的不同类型的数据的一个或多个数据源，传送请求并且接收响应。在所图示的实施例中，数据接口24是后端通信接口，其支持包括HL7、XML、JDBC、ODBC和其他的所有主要的通信协议。数据接口24具有与异类(disparate)的外部系统进行通信的能力，并且使用内部的类结构(class structure)来迅速地并且高效地对数据进行解析并且将其合并入DBMS中。DBMS以各种不同的方式(对象、有关表格和/或其他)来存储数据，并且可以迅速地响应有关的或者对象的查询。

继续参照图4，处理引擎26包含：(a)应用服务器32，其处理用户经由服务器28提出的每个查询；(b)数据库管理系统(DBMS)34；(c)更新处理器36，其以指定的次数(典型地，每日)更新由系统20维持的一个或多个数据库；(d)实体论和/或自然语言处理器38；(e)客户端数据库管理系统40，其能够基于用户指定的(多个)药物和(多个)疾病的组合而促使对不良事件的搜索或者多个搜索，基于用户指定的(多个)不良事件、以及(多个)疾病和(多个)药物的至少之一而促使搜索或多个搜索，向用户提供用于量化(quantify)系统对用户的益处的量度(metrics)，并且基于系统的使用而监视作为卫生保健机构的用户的、持续的医疗教育信用；以及(f)(i)去识别的电子医疗记录数据库42，其包含已被去识别的(即，不能通过个人的姓名或者其他识别信息(诸如住址)而与个人相关联的)例如HMO的患者的电子医疗记录，和/或(f)(ii)应用程序接口(API)，其允许(经由电子医疗记录接口43)访问驻留在系统20之外、但是对系统20是可访问的电子医疗记录数据库(去识别的或相反的)。在图示的实施例中，处理引擎26是将数据存储为对象(多个对象)和表格(SQL有关的)的多维的后(post)数据库管理系统。使用面向对象语言(.net，Java，XML等等)和/或遵循SQL、DBMS有关的工业标准的数据库语言，可以直接访问数据。DBMS 34利用交互的(transactional)位图索引方案来提高用户的响应时间。

在图示的实施例中，处理引擎26的一个或多个元件(element)能够响应来自用户的大量的不同类型的查询。参照图5A和5B，处理引擎26所处理的一种类型的查询是由患者已经历的不良事件和该患者的已知疾病组成的查询。处理引擎26进行操作以对由系统20所维持的或者对系统20可用的数据库进行一个或多个数据库搜索，以便识别用于指示在被指定疾病和/或合病(comorbidity)的情境下所指定的不良事件的可能原因的信息源。例如，该搜索可以识别其中在所指定的不良事件和所指定的疾病之间存在关联的一个或多个药物。将搜索的结果传送至用户的电子设备或者计算设备。图5A和图5B图示了在当被指定的不良事件是升高的肝功能测试、并且患者患有疾病A-C时的情形中的处理。

参照图6，处理引擎26能够从事的另一种类型的查询是由不良事件和已知患者已服用的药物和/或经受的(多个)治疗组成的查询。处理引擎26进行操作以对由系统20所维持的或者对系统20可用的数据库进行一个或多个数据库搜索，以便识别用于指示在所指定的不良事件、与患者所服用的药物和/或经受的治疗之间存在联系的信息源。将搜索的结果传送至用户的电子设备或者计算设备。

参照图7，处理引擎26能够处理的又一种类型的查询是由不良事件、已知患者已服用的药物和/或经受的(多个)治疗、以及该患者的已知疾病组成的查询。在此情形下，处理引擎26进行操作以对由系统20所维持的或者对系统20可用的数据库进行一个或多个数据库搜索，以便识别用于指示在所指定的不良事件、与患者所服用的药物和/或经受的治疗之间存在联系的信息源。另外，处理引擎26进行操作以对由系统20所维持的或者对系统20可用的数据库进行一个或多个数据库搜索，以便识别用于指示在所指定疾病的情境下被指定的不良事件的可能原因的信息源。在所述可能的原因中，可以是不必由患者、卫生保健专业人员所指定的、或在患者的医疗记录中指定的、非处方(Over-the-Counter)(OTC)药物或者治疗、草药、以及处方配药。将搜索的结果传送至与用户相关联的电子设备或者计算设备。

参照图8和图9，由用户提交的任何查询可以经过实体论和/或自然语言处理器38以努力地识别有关的搜索术语来捕捉比仅仅使用该查询的术语将发现的信息源更多的、与该查询相关的信息源。图8图示了用于升高的肝功能测试的实体论，其建议了大量的其它术语，所述其它术语可以得出超过在搜索的术语或者短语仅仅是升高的肝功能测试的情况下将识别的信息源的另外的信息源。搜索术语的实体论扩展的列表可以涉及(多个)不良事件、(多个)药物、(多个)疾病、或者涉及用户查询的任何其他组分。查询可以自动地经过处理器38，或者可以按用户的请求经过处理器38。图4示出实体论/NLP处理器38包含SNOMED、SOPHIA、特定的实体论、以及NLP，但是应当理解的是，可以采用其他的实体论(包括非特定的实体论、药物实体论)以及其他融入情境的术语(term-contextualizing)的系统。SOPHIA搜索引擎提供了如与传统的基于关键字的搜索能力相对的、主题(thematical)搜索能力。参照图9，如果用户想要这样做，则该用户可以编辑扩展的搜索术语，以便在执行搜索或者多个搜索之前删除一个或多个术语或者增加一个或多个术语。图9图示了其中用户向图8中所示的实体论增加了术语的情形。一旦用户已决定了搜索什么集合的术语，则应用服务器32向DBMS子系统34发送请求，所述DBMS子系统34处理该请求，并且使用基于多个因素对搜索结果进行优先级区分的优先级算法，所述多个因素包括但不限于：所指定的文档的部分中的搜索术语命中(hit)数量、管理机构的警告(regulatory agencywarning)(黑盒警告等等)、不良事件的频率、以及其他优先级区分的权重因素(AI推导出的或者未推导出的)。

图10A和10B图示了一个例子，其关于：用户指定的查询；用户指定的查询的、基于实体论的搜索术语扩展；相对于用以产生搜索结果的一个或多个数据源(例如，数据库等等)的、NLP驱动搜索或者发掘操作；未经优先级区分的搜索结果；以及经过优先级区分的搜索结果。更具体地，查询输入表格50示出用户已输入具有药物A、药物B、药物C、以及升高的肝功能测试的不良事件的查询。基于实体论的搜索术语扩展表格52示出涉及升高的肝功能测试的不良事件的几个用实体论识别的附加搜索术语。搜索术语扩展不限于用户指定的不良事件，而是可以应用于由用户指定的查询中的术语或者短语的任何组合。表格52具有挨着每个用实体论识别的扩展术语的“复选框”，其允许用户选择哪一个用实体论识别的搜索术语被用于基于用户指定的查询术语和所选择的用实体论识别的扩展术语的随后的搜索。显示54图示了对系统20可用的一个或多个数据源的基于NLP的搜索的、根据药物而归类的结果。参照图10B，在显示56中示出了通过药物归类、并且未经优先级区分的搜索的结果。通常不向用户提供未经优先级区分的结果。因此，通常不生成并且不向用户提供显示56。然而，显示56对于图示未经优先级区分的结果是有用的。在与搜索结果中的每个引用相关联的“击中(bang)”或“命中”的数量中反映了结果的未经优先级区分的特性。例如，与药物A相关联的首先的三个结果分别具有两个击中、三个击中、以及两个击中。作为对比，显示58图示了提供给用户的经过优先级区分的结果。在显示58中，不再通过药物而是通过击中数量来对结果进行归类，列表中最上面的条目与药物B相关联并且具有七个击中，并且，最下面的条目与药物C相关联并且具有1个击中。

处理引擎26还能够：(a)存储客户端查询、以及提供给用户作为该查询的处理结果的、结果中被识别的每个信息源的副本；(b)以一次或多次的指定次数(其可以是由系统设置的默认次数、或者由用户指定的次数)，将提供给用户的结果中所识别的每个信息源、与信息源的新副本进行比较；以及(c)如果自从将查询的结果提供给用户以后信息源改变了，则向用户通知已存在改变，并且向用户识别该改变。然后，用户可以评估该改变对于特定的个人或者患者是否重要。

处理引擎26还能够：(a)存储(多个)药物或者(多个)疾病或者它们的组合；(b)以一次或多次指定的次数(其可以是由系统建立的默认次数、或者由用户指定的次数)，促使对由系统维持的、和/或对于系统可访问的数据库进行一个或多个搜索，以便确定是否已报告了满足所指定的准则(criteria)的不良事件；以及(c)如果识别出这样的不良事件，则经由用户的电子设备或者计算设备向用户报告该不良事件和有关的信息源。此外，处理引擎26能够搜索由用户提供的EMR的数据库(去识别的或相反的)，以便识别现在可能处于基于用户指定的搜索参数的危险中的这些患者(匿名的或相反的)，并且以便向用户识别这些患者(匿名的或相反的)。可替换地，可以通过例如服务器28的HL7端口，将搜索的结果提供给用户的EMR系统。然后，用户可以在他们的EMR系统上运行搜索以识别潜在地处于危险中的患者。应当理解的是，系统20的、使用来自全世界的各个国家(在其中，相同的药物可能被批准用于不同的疾病)的后端市场(post-marketing)的药物安全数据的能力，向卫生保健专业人员提供益处，其包括：当相反在药物未被批准为用于特定的疾病的国家中将不能得到这样的数据时、增强对与标示外使用的(off-label)药物处方实践相关联的安全性危险的意识。

处理引擎能够执行的另一功能是监视“命中”，即，当搜索去识别的EMR时、或者当基于用户指定的(多个)药物、(多个)疾病、或者其组合的准则来识别不良事件时用户搜索他们的EMR系统时、对潜在地处于危险中的患者的识别。在当向用户报告不良事件、并且用户为可能处于该不良事件的危险中的患者搜索他们的EMR系统时的情形下，使用驻留在用户的EMR系统中的“插件”程序或者相当的设备，以便监视命中并且将命中报告回系统20。应当理解地是，可以使用命中来量化系统20对用户的益处。此外，可以经由量度的可视化(visual)显示向用户提供这样的量化，即，在用户的电子设备或者计算设备的一个或多个页面上呈现、并且示出例如系统为该用户已识别的命中的数量的显示。也可以将这样的信息用于根据系统20给用户的益处来赋予(place)货币价值。

为了利用系统20，用户最初经由用户接口22建立与系统20的通信链接。可以利用具有网络浏览器的通信设备，或者利用采用由系统20支持的消息传送协议的任何其他合适的通信设备，来建立该链接。无论如何，在建立通信链接之后，用户具有这样的接口，该接口允许用户：(a)向处理引擎26输入查询；并且(b)接收由处理引擎26基于查询所进行的搜索的结果。更具体地，系统20向用户的通信设备提供在与用户的通信设备相关联的监视器(或者其他合适的显示设备)上显示的表格。用户通过向与该表格相关联的一个或多个字段键入数据而输入查询。可以使用用户的通信设备支持的、并且能够键入合适数据的任何输入外设来键入数据。典型地，输入外设是键盘。然而，其他输入外设也是可行的(例如，触摸屏、光笔，麦克风等等)。系统20能够接收并处理至少每个以下查询：

(a)(i)患者经历的不良事件(AE)和(ii)患者的已知疾病；

(b)(i)患者经历的AE和(ii)给患者应用的(多个)药物和/或(多个)治疗；

(c)(i)患者经历的AE、(ii)给患者应用的(多个)药物和/或(多个)治疗、以及(iii)患者的已知疾病；

关于任何这样的查询，用户还能够使用在与用户的通信设备相关联的监示器或者其他显示外设上显示的表格，以便通知系统20：特定的查询要经过基于实体论的搜索术语扩展。该表格还允许用户在基于查询的搜索之前和/或之后编辑任何基于实体论的搜索术语扩展。基于实体论的搜索术语扩展可以基于任何实体论。然而，实施主题搜索方法的复杂搜索引擎(像SOPHIA)提供了可以用于或者不可以用于补充基于实体论的搜索术语扩展结果的、附加的相关搜索术语。

该搜索可以基于如由用户指定的查询，或者可以是基于由用户指定的查询、并且随后经过基于实体论的搜索术语扩展的搜索。

通常在与用户的通信设备相关联的监视器上显示所接收的结果。作为在监视器上显示结果的可替换的或者另外的方式，可以将结果提供给与用户的通信设备相关联的任何合适的外设。例如，可以将结果发送给存储设备(例如，磁带(tape)驱动器、磁盘驱动器等等)和/或打印机。

在与用户的通信设备相关联的监示器或者其他显示外设上显示的表格，允许用户请求系统20：(a)存储或者识别特定的查询，并且当所指定的查询被初始处理时存储所识别的每个引用的副本；(b)在已产生初始的结果之后，一次或多次将当查询被初始处理时所识别的每个引用、与该引用的更新的副本进行比较；并且(c)通知用户在一个或多个引用中是否已存在改变。处理引擎28处理请求，并且通过消息通知用户在引用中是否已存在改变，其中，处理引擎28向用户通信设备提供该消息，用于在与用户通信设备相关联的监视器或者其他显示外设上显示。

在与用户的通信设备相关联的监示器或者其他显示外设上显示的表格，允许用户请求：在表格中将与通过用户指定的(多个)药物和/或(多个)疾病或者其组合相关联的、未来的、备有证明文件的(documented)不良事件通知给该用户。随后，处理引擎28基于用户指定的信息进行搜索。如果处理引擎28在基于所指定的信息的任何在前的搜索、以及基于信息的当前搜索之后，识别出已备有证明文件的不良事件，则引擎28促使向用户的通信设备提供消息，用于在与用户的通信设备相关联的监视器或者其他显示外设上显示。用户可以使用这样的信息来查询其自身的EMR系统，以便确定是否存在处于危险中的(多个)患者，或者用户可以指示系统搜索用户的EMR系统以识别是否存在处于危险中的(多个)患者。

可以通过广域网或者局域网进行系统20和用户的通信设备之间的通信。可替换的，可以在独立的计算机系统中实施系统20的搜索和报告能力。

Claims (16)

1.一种用于向用户提供医疗评估支持信息的方法，包括：

使用电子通信设备，建立与医疗评估支持系统的通信链接；

使用所述电子通信设备向医疗评估支持系统发送查询，所述查询包含患者的已知疾病的识别、以及患者所经历的不良事件的识别；

响应于所述发送步骤，接收由医疗评估支持系统进行的并且基于所述查询的数据库搜索的结果。

2.如权利要求1所述的方法，其中：

所述医疗评估查询还包含已对患者应用的药物/治疗的识别。

3.如权利要求1所述的方法，其中：

所述结果是下列至少之一的、基于实体论的搜索术语扩展的产物：(a)所述已知疾病和(b)所述不良事件。

4.如权利要求1所述的方法，其中：

所述结果是下列两者的、基于实体论的搜索术语扩展的产物：(a)所述已知疾病和(b)所述不良事件。

5.如权利要求1所述的方法，其中：

所述结果是基于所述查询的、自然语言处理搜索的产物。

6.如权利要求1所述的方法，其中：

所述结果是下列的产物：(a)所述查询的至少一部分的、基于实体论的搜索术语扩展；以及(b)基于所述查询、以及由基于实体论的搜索术语扩展导致的任何附加搜索术语的自然语言处理的数据库搜索。

7.如权利要求1所述的方法，其中：

所述发送步骤还包含：请求所述查询的至少一部分的、基于实体论的搜索术语扩展。

8.如权利要求1所述的方法，还包含：

在所述接收结果的步骤之前，从所述医疗评估支持系统接收基于所述查询的至少一部分的、基于实体论的搜索术语扩展的附加搜索术语。

9.如权利要求8所述的方法，还包含：

跟随在所述接收附加搜索术语的步骤之后、并且在所述接收结果的步骤之前，向所述医疗评估支持系统提供经修改的附加搜索术语。

10.如权利要求9所述的方法，其中：

所述经修改的附加搜索术语不具有所有的所述附加搜索术语。

11.如权利要求9所述的方法，其中：

所述经修改的附加搜索术语具有不在所述附加搜索术语中的至少一个术语。

12.如权利要求1所述的方法，其中：

基于下列的一个或者其组合对所述结果进行优先级区分：(a)在文档的预定部分中发现的、所述查询中的术语的数量；(b)管理机构强制的优先级区分；和(c)不良事件的频率。

13.如权利要求1所述的方法，还包含：

跟随在所述接收结果的步骤之后，接收消息，该消息即：所述结果中被识别的引用已改变。

14.一种用于向卫生保健机构或者其他个人提供医疗评估支持的系统，包含：

用户接口，用于从与卫生保健机构或者其他个人相关联的电子通信设备接收查询，并且将基于所述查询的搜索的结果发送给与所述卫生保健机构或者其他个人相关联的电子通信设备；

处理引擎，用于基于由所述输入接口接收的查询而搜索至少一个数据源，并且向所述用户接口提供所述搜索结果，用于随后传送到与所述卫生保健机构或者其他个人相关联的电子通信设备，所述查询识别：

(a)患者的已知疾病和该患者所经历的不良事件；

(b)患者的已知疾病、已对该患者应用的药物/治疗、以及该患者所经历的不良事件；或者

(c)已对该患者应用的药物和/或治疗、以及该患者所经历的不良事件；

其中，所述处理引擎包含实体论处理器，用于处理所述查询的至少一部分以产生附加搜索术语；

其中，所述处理引擎包含自然语言处理器，用于基于所述查询和所述附加搜索术语来搜索至少一个数据库；

其中，所述处理引擎包含优先级区分器，用于对由自然语言处理器产生的结果进行优先级区分；以及

数据接口，用于进行与可能能够提供与查询有关的信息的外部数据源的通信。

15.如权利要求14所述的系统，其中：

所述处理引擎包含比较器，该比较器用于将基于查询的搜索结果中所识别的引用的旧的版本、与所述引用的更新的版本进行比较，如果存在差别，则向所述用户接口提供与该差别有关的消息，用于随后传送到与该用户相关联的电子通信设备。

16.如权利要求14所述的系统，其中：

所述查询是重复的查询，其识别(a)正在给患者应用的一个或多个药物/治疗、和/或(b)患者正经历的一个或多个疾病；

所述处理装置基于所述重复的查询而重复地搜索不良事件。

Images