CN102073786A - 用于识别患者间关系的系统、设备和方法 - Google Patents

Abstract

一种用于在患者电子医疗数据之中识别患者间关系的示例方法(700，1100)包括检查与第一患者相关的一个或多个标识符的电子患者信息(710，720，1110)。该方法(700，1100)包括使用处理器(1210)将与第一患者相关的一个或多个标识符与来自与第二患者相关的电子患者信息的一个或多个标识符进行匹配(730，750)。该方法(700，1100)包括使用处理器(1210)、根据第一患者与第二患者之间的关系来识别第二患者与第一患者的关连(740，760，770)。该方法(700，1100)包括将第一患者的电子患者信息链接到有待批准的第二患者的电子患者信息(780，785，1120)。该方法(700，1100)包括在审阅第一患者的电子患者信息时提供对第二患者的链接的电子患者信息的电子访问(1140)。

Description

用于识别患者间关系的系统、设备和方法

技术领域

一般来说，本公开涉及处理电子患者信息的系统、方法、设备和制造产品。更具体来说，本公开的某些示例涉及识别患者之间的关系并且链接与那些患者相关的电子信息的系统、方法、设备和制造产品。

背景技术

健康护理环境、如医院或诊所包括：信息系统，例如医院信息系统(HIS)、放射信息系统(RIS)、临床信息系统(CIS)和心血管信息系统(CVIS)；以及存储系统，例如图像存档和通信系统(PACS)、图书馆信息系统(LIS)和电子病历(EMR)。所存储的信息可包括例如患者医疗病史、成像数据、测试结果、诊断信息、管理信息、保险信息和/或时间安排信息(scheduling information)。信息可集中存储或者划分在多个位置。健康护理专业人员可能希望在健康护理工作流程的各个点访问患者信息或其它信息。

正在进行全国性的工作以便连接健康护理信息系统，并且使它们以安全、可持续并且基于标准的方式可互通的。但是，对于联邦政府所领导的全国健康信息网络(NHIN)以及对于全国的许多小型地区健康信息组织(RHIO)，所需信息基础设施仍然正在发展中。对于美国和其它地方的健康信息交换仍然有许多难题。另外，需要交换网络中的参加者之间的健康信息的标准化和互通性。此外，需要提供集中与分布式数据架构的系统。

在当前医疗环境下，对患者病历的访问既麻烦且不完整。通常，病历保存在各个诊所。如果患者去过一个以上诊所，则患者可能具有多个病历。例如，患者可去第一诊所并且建立第一病历，然后该患者去第二诊所并且建立第二病因。如果第二诊所无权访问第一病历，则在第二诊所的检查和诊断可能是重复且低效的。

综合病历的缺乏对于患者也是重复且低效的。例如，患者通常在该患者所去的各诊所填写相似表格。患者可能填写具有患者医疗病史、各种健康状况、过敏性、遗传信息或其它信息的表格。单个诊所则为患者保存诊所自己的记录。由于患者在其一生中可能去过多个诊所，所以该患者可能重复填写相同的信息。在一些情况下，患者可能没有填写相同的信息，并且在不同诊所的各种病历可能包含部分和/或过时的信息。

另外，患者病历信息的非集中的性质由除了医疗诊所之外的实体永久保存。例如，病历信息可能由保险实体、调药实体和/或实验室实体保存。在这些实体的任一个的患者病历的更新不会确保更新其它实体。相应地，患者病历信息根据实体而有所不同。相应地，难以查找完全最新的病历，并且治疗医生在治疗之前可能无法获得患者健康的全貌。另外，由于患者信息是非集中的，并且患者无权访问其患者病历信息，所以患者可得到的与其健康状态有关的信息通常是一般范畴的信息。

发明内容

某些示例提供识别患者之间的关系并且链接与那些患者相关的电子信息的系统、方法、设备和制造产品。

在某些示例中，用于在患者电子医疗数据之中识别患者间关系的计算机实现方法包括检查与第一患者相关的一个或多个标识符的电子患者信息。该方法包括使用处理器将与第一患者相关的一个或多个标识符与来自与第二患者相关的电子患者信息的一个或多个标识符进行匹配。该方法包括使用处理器、根据第一患者与第二患者之间的关系来识别第二患者与第一患者的关连(connection)。该方法包括将第一患者的电子患者信息链接到有待批准的第二患者的电子患者信息。该方法包括在审阅第一患者的电子患者信息时提供对第二患者的链接的电子患者信息的电子访问。

在某些示例中，患者间关系识别系统包括处理器，它检查来自至少一个电子文档源的电子患者信息中的与第一患者相关的一个或多个标识符，并且将与第一患者相关的一个或多个标识符与来自与第二患者相关的电子患者信息的一个或多个标识符进行匹配。该处理器根据第一患者与第二患者之间的关系来识别第二患者与第一患者的关连。该系统包括患者登记(patient registry)，以便包含第一患者的电子患者信息，并且根据第一患者和第二患者中的至少一个的批准来提供到第二患者的电子患者信息的链接。患者登记便于在用户审阅第一患者的电子患者信息时访问第二患者的链接的电子患者信息。

在某些示例中，实体计算机可读存储介质包括用于在处理器上运行的指令集合。指令集合在被运行时实现患者间关系识别系统。该系统包括处理器，它检查来自至少一个电子文档源的电子患者信息中的与第一患者相关的一个或多个标识符，并且将与第一患者相关的一个或个标识符与来自与第二患者相关的电子患者信息的一个或多个标识符进行匹配。该处理器根据第一患者与第二患者之间的关系来识别第二患者与第一患者的关连。该系统包括患者登记，以包含第一患者的电子患者信息，并且根据第一患者和第二患者中的至少一个的批准来提供到第二患者的电子患者信息的链接。患者登记便于在用户审阅第一患者的电子患者信息时访问第二患者的链接的电子患者信息。

附图说明

图1示出示例健康护理信息交换(HIE)。

图2示出示例健康护理信息架构。

图3示出示例个人健康记录(PHR)系统。

图4示出示范用户接口(user interface)架构。

图5示出示例信息架构，它被提供以便支持来自多个不同类的数据源的信息的检索、合成和呈现。

图6示出示例电子病历表。

图7示出在电子病历和/或其它电子数据之中识别患者间关系的示例方法的流程图。

图8提供显示和便于链接的患者间(P2P)关系的使用的示例用户接口。

图9示出P2P关系的备选示例表示。

图10示出提供相对特定患者的等级关系的图示的示例用户接口。

图11示出将患者的唯一标识符与其家庭成员的标识符进行链接以构建家庭医疗病史的示例方法的流程图。

图12示出采用可用的电子医疗数据来识别和利用患者与其他人之间的关系的示例患者关系识别系统。

图13是可用于和/或编程为实现本文所述的示例系统、设备、制造产品和方法的示例处理器平台的示意图。

图14是可用于实现本文所述的系统、设备、制造产品和方法的示例处理器系统的框图。

通过结合附图进行阅读之后，将会更好地理解上述发明内容以及下面对本发明的某些示例实施例的详细描述。为了说明本发明，附图中示出某些实施例。但是，应当理解，本发明并不局限于附图所示的布置和手段。

具体实施方式

虽然下面公开包括在硬件上运行的软件以及其它部件的示例方法、系统、制造产品和设备，但是应当注意，这类方法和设备只是说明性的，而不应当被认为进行限制。例如，预想了这些硬件和软件部件的任一种或全部可专门通过硬件、专门通过软件、专门通过固件或者通过硬件、软件和/或固件的任何组合来体现。相应地，虽然下面描述示例方法、系统、制造产品和设备，但是所提供的示例不是实现这类方法、系统、制造产品和设备的唯一方式。

当记载的所附权利要求的任一项涵盖纯软件和/或固件实现时，至少一个示例的元件的至少一个在此明确限定为包括存储软件和/或固件的实体介质，例如存储器、数字视频光盘(DVD)、压缩盘(CD)等等。

医院企业和/或其它诊所环境可保存与该企业为其提供服务的患者有关的许多信息。许多已登记患者通过一组已定义关系而互相关。医院或其它环境可能没有客户之间的这类关系的完整信息。通过捕获以下称作患者间关系(P2P)信息的关系信息，医院企业和患者本身可获益于例如可用信息、诊断和/或治疗建议和/或在相关患者记录中的信息之间进行的其它相关性的庞大体。

通过利用可用信息，例如由于更有效的营业计划和/或经营模型，可为链接的患者提供专业的特惠服务，和/或以某个折扣率为其提供治疗。共享和/或以别的方式的链接的P2P信息可用于例如临床分析和/或调查及其它数据收集。P2P信息可提供例如改进和/或扩大的紧急联络信息。

当前，在登记过程中向患者收集家庭医疗病史信息。这种信息的准确度仅达到患者知道其家庭成员的医疗病史的程度。向患者所收集的家庭医疗病史信息没有提供在患者的将来检查方面会有帮助的粒度信息。通常，登记信息对患者收集一次，而不会随着家庭成员随时间推移感染慢性病和/或其它问题而更新。

在某些示例中，相关患者记录(例如电子病历、电子健康记录、个人健康记录等)和/或其它电子患者信息可识别为相关的。相关P2P信息可用于针对链接的患者的诊断、治疗、紧急联络、计费和/或其它临床和/或行政功能。

在某些示例中，提供一个或多个系统、方法、设备和/或制造产品，以便将患者的唯一标识符与其家庭成员的标识符进行链接以构建家庭医疗病史。家庭医疗病史可用于例如更好地帮助具有乳癌、直肠癌、糖尿病、心脏病等家庭医疗病史的患者。家庭医疗病史还可用于例如关注产前护理和遗传方面的怀孕妈妈。家庭医疗病史可以是执业医生有权访问详细家庭医疗病史时在收集与疾病发展的风险有关的信息方面的助手。

一个或多个所公开的系统、方法、设备和/或制造产品提供一种链接家庭的不同成员以共享其病历的机构。某些示例提供登记，其中以唯一标识符来登记成员，并且各成员可通过定义与他/她的唯一等级关系，来请求到其它家庭成员的链接。例如，John Doe可将其信息输入登记，并且可请求到其家庭成员Jane Doe(姊妹)、Jeff Doe(叔父)、Joanna Doe(母亲)的链接。括号中的项识别John Doe与其他人之间的等级关系。

某些示例在获得来自患者家庭成员和/或其它链接的个体的同意之后提供对病历的访问。同意可基于每个事件、定期和/或作为一次性问题(例如在链接时、在提供链接的建议时等等)来获得。在一些示例中，不是允许患者直接访问其家庭成员的病历，而是可使链接的信息匿名可用、自动提供给临床系统供帮助诊断、治疗和/或其它分析、路由到经授权的护理提供者等等。例如，信息的匿名可逐个记录地来确定。

在一些示例中，患者预期隶属于亲和域，使得该患者可共享病历并且建立链接。亲和域是一组健康护理企业，例如，它们同意使用一组共同的策略共同工作，并且共享共同基础设施。

某些示例提供生成唯一患者标识符的患者身份源。创建等级关系以帮助系统、方法、设备、制造产品和/或该系统、方法、设备和/或制造产品的临床医生用户了解患者病历上的家庭成员的医疗病史的显著性。提供患者登记以便登记和链接标识符。患者标识符还可用于提拉和/或同步多个源之间的信息。亲和域可用于关联各患者。提供一种同意机构来获得家庭成员和/或其它相关个体批准，以便在接收到链接的请求时共享病历。提供例如PACS、PHR、EMR和/或其它电子数据存储的文档源，以便访问病历。

通过链接患者，可生成合成医疗病史。当患者认识到其家庭内和/或其它有关连的个体的关连时，他或她可收集与感染特定疾病的风险有关的更多个人信息。通过使重要信息方便地可为健康护理提供者可用，医院可提高其在提供护理方面的效率。用户可根据对于从若干信息源所收集的个人病历的广泛访问，来跟踪和趋向于各种信息。

在某些示例中，在任何给定点所查看的家庭医疗病史包括与那个患者的(参与链接的)家庭成员有关的所有最近信息。例如EMR、PHR、PACS、HIE等的分布式系统中的多个数据点可集合在一起，以便帮助患者护理。某些示例可帮助执业医生根据对详细家庭医疗病史的访问来收集与疾病发展的风险有关的信息。某些示例提供对于跨企业的病历链接的服务提供。某些示例可用于通过病历来链接人。某些示例可与例如PACS、RIS、PHR、EHR、HIE等系统集成以便获得病历。

在一些示例中，等级在链接的患者之间和/或存在于其记录中的与那些患者相关的特性和/或数据之间定义。例如，等级可用于评估存在于链接的家庭病史中的健康状况(condition)的相关性，供患者诊断。

在一些示例中，可将标识符指派给个体患者以及有关连的患者的家庭。患者标识符可以在家庭中交叉链接。例如，交叉链接可自动地和/或使用请求和批准模型来确定。某些示例可搜索患者的家庭成员和/或其它关系，请求到患者记录的连接，以及定义患者与其他人之间的关系。如果其他人接受，则患者的记录也将反映相关人的信息。

算法可用于根据患者的记录来识别可能的家庭成员，并且提出与该患者的关系。该算法可适应离异的小孩等。该算法可用于查找可能在遗传学上影响患者的医疗病史的任何人，并且然后询问一个或多个个体(如果他们想要连上)。在一些示例中，患者可跨不同的系统具有多个标识符；对于该患者可以交叉联接这些标识符以供跨系统的引用。

在一些示例中，跨企业文档共享(XDS)可用于共享和/或连接机构之间的文档。可利用XDS以及集成健康护理企业(IHE)简档/协议来跨机构系统地传送文档并且连接文档供共同使用。例如，可定义用于搜索和/或识别存在于文档中的信息的文档格式标准。

例如，交叉链接功能性可构建到医院收入循环管理系统和/或各种患者信息系统中，和/或可得到独立系统支持，该独立系统从各种患者信息系统应用(其向该独立系统馈送患者信息)收集信息。例如，患者关系信息可在特定医院信息系统中聚合和/或跨若干个这类系统来聚合。

在某些示例中，可提供患者关系树的图形表示，以便允许用户更容易可视化患者关系和/或其它关连。例如，可在由操作人员、管理员等配置的诸如入院/登记、出院、转院(ADT)等的各个护理点通知操作人员关于患者与其他患者的关系。例如，通过图形显示器、通知等，关系信息可在急诊期间供患者使用。例如，关系信息可在临床研究和分析中使用。例如，关系信息可用于将输入提供到医院收入循环管理系统中，以便于提供促销活动。例如，可根据患者关系和病史信息为患者改进、量身定制和/或以其它方式更好地选择健康护理服务。根据链接和关系信息所组织的健康记录可作为例如经由万维网和/或专用网络可访问的个人健康记录端口等患者联机端口的一部分来提供和/或访问。

例如，通过实现紧急联络信息的提供以及支持患者信息的有效利用，使用电子患者家庭病史和/或其它链接信息可帮助临床医生提供改进的患者护理。通过提供可用于临床分析的信息，关系信息可帮助改进整体健康护理。例如，链接的信息可用于帮助在医院企业中生成定制护理计划和有组织的护理以及商业机会。

虽然患者信息往往分布于系统中而没有识别和可视化关系的方式，但是患者关系可通过图形方式等等来识别和描述。可识别、链接、跟踪、描述患者与其配偶、邻居、社交网络等之间的患者间关系等。例如可通过数据库来组合以及识别跨数据库的信息，从而从各种系统来收集信息。例如，可显示和/或图形表示患者间关系。

例如，患者间关系信息和交叉链接可结合EMR、PHR和/或其它连通性框架来实现。上述某些示例可适用于基于健康信息交换(HIE)标准的架构和部件，例如文档存储、查询、到数据源的连通性、数据登记/储存库、基于人口的临床质量改进以及具有报告工具、托管接口、主患者登记、主提供者登记等的研究数据库。将跨企业文档共享(XDS)与临床数据储存库(CDR)进行组合使文档的原始内容和上下文能够保存，而且还使临床相干值的捕获能够实现超过文档限制的数据的其它用途。例如，这种组合可包括跨数据源的数据的规格化。某些示例还便于跨多个数据源的数据访问和信息交换，数据源例如是付款人、金融机构、电子病历(EMR)系统、执业管理系统、索赔/处方数据库、药品公司、医师/医院端口、药房效益管理(PBM)等。此外，某些实施例提供向/来自患者、患者护理小组(专业和家庭)的成员、其它第三方和特定装置的信息的基于规则的推送/拉取(根据各数据源的简档)。例如，信息可包括安全消息传递和图像和/或扫描临床文档。规则可包括人工或自动数据交换、数据的请求和接受等。

某些示例提供万维网端口应用供向患者的数据呈现。例如，基于万维网的端口可根据患者的特定个性和生活方式评估为用户提供自适应和主动体验，包括匹配技术/工具、教育/信息和指导反馈。

某些示例将人工智能应用于顺应性工具，以便根据广泛但目标明确的数据集(例如，患者输入的数据、EMR数据、其它第三方临床和金融/行政数据等等)来形成与定制的算法组合的个性化护理计划，以便提供护理管理计划的跟踪、基于患者的选择(例如，如果您选择A、B和C，则您的血压将为x与y)的对患者的影响的文本和图形的预计模拟。例如，预计模拟可包括金融以及医疗场景。

某些示例结合非健康护理特定的技术，例如Sametime/synchronous eVisit协作工具、社交/团体站点、工具以用于帮助管理健康护理(例如，金融计算器、质量评估工具等)等等。

例如，某些示例便于经由医疗质量改进协会(MQIC)和其它基础设施工具来跟踪患者结果与顺应性的关系。某些示例为医师特定端口服务提供工具/信息交换架构的扩充。

某些示例为系统和方法提供聚合跨多个数据源(例如，医师电子病历、临床或医院电子病历、付款人索赔历史、药学慢性病管理、金融机构/帐户等)的患者健康信息的能力，并且例如使用临床健康护理信息交换(HIE)标准来进行这种操作。某些示例提供以交互方式连接到患者病历的系统，其中记录自动适合患者的偏好，以便例如实现最可能的顺应性水平和/或跟上患者变化的健康状况。

另外，某些示例通过提供自动适合患者的特定和变化的健康状态并且提供综合教育和顺应性工具来驱动肯定的健康结果的基于标准的组织工具来帮助解决便于患者了解和决策制定的复杂问题。

基于标准的部件用于信息交换。这些部件可符合最新健康行业技术标准。在向参与登记和储存库发送患者信息的临床系统不能按照一种或多种行业标准进行通信的情况下，可在将消息添加到登记或储存库之前将消息变换成符合一种或多种可适用标准的消息。

可跨多个数据源来聚合数据，以便为患者提供全局视图或纵向记录。在现有系统中，例如只有患者信息的局部视图是经由EMR、保险索赔数据库或付款人资助端口可用的。

在某些示例中，登记和储存库足够灵活以便适应关于患者的临床、金融和人口统计数据。登记和储存库可管理和维护患者一生的数据。在现有系统中，当患者不再被另一个实体(例如诊所、付款人和雇主看到或者管理时，数据对于该患者不再是可用的。另外，患者可将他或她自己的信息添加到登记和储存库。这允许患者将关于其健康的个人信息保存在个人健康记录(PHR)中。

某些示例允许通过将临床文档转发给提供者以供转诊工作(referral work)使得患者与护理提供者进行通信。某些示例还实现由提供者对患者创建的文档的审阅。某些示例允许患者容许或拒绝护理提供者访问其信息。与现有系统的患者相比，这帮助为患者提供对其记录的更大灵活性和更好的控制。

多个数据源的互连帮助实现患者护理小组的所有相干成员的参与，并且帮助改进对患者的用于管理其护理的行政和管理负担。具体来说，患者的电子病历和/或其它医疗数据的互连可帮助改进患者护理和患者信息的管理。此外，患者护理顺应性通过提供自动适合患者的特定和变化的健康状态并且提供综合教育和顺应性工具来驱动肯定的健康结果的工具来促进。

健康护理信息技术基础设施可适应成服务于多个商业兴趣，同时提供临床信息和服务。这种基础设施可包括集中的能力，包括例如数据储存库、报告、谨慎的数据交换/连通性、“智能”算法、个性化/消费者决定支持等。例如，这种集中的能力向包括下列在内的多个用户提供信息和功能性：1)PHR、装置和消费者、雇主和医师端口120；2)EMR、性能提升付费(P4P)、慢性病模型和临床HIE/RHIO；3)企业药物研究；和/或4)家庭健康，包括家庭保险和家庭装置连通性。

图1示出示例健康护理信息交换(HIE)100。HIE 100组织成提供跨多个组织的健康护理信息的存储、访问和可搜索性。HIE 100可服务于团体、地区、国家、一组相关健康护理协会等等。例如，HIE 100可作为和/或采用地区健康信息组织(RHIO)、国家健康信息网络(NHIN)、医疗质量改进协会(MQIC)等等来实现。在某些实施例中，HIE 100连接健康护理信息系统、执业管理系统和临床系统，并且帮助使它们以安全、可维持续并且基于标准的方式是可互通的。

HIE 100提供在相关与完全不同的健康护理信息系统之间交换信息的能力。HIE 100帮助便于以改进的安全性、及时性和/或效率等等对临床和其它健康护理数据的访问和检索。例如，HIE 100中的部件和/或参加者遵守对于在所提供的技术基础设施中的信息共享的一组共同原则和标准。HIE 100可用于存储、访问和/或检索各种数据，包括与门诊病人和/或住院病人看病相关的数据、实验室结果数据、急病室看病数据、药物治疗、过敏性、病理学结果数据、注册和/或符合资格数据、疾病和/或慢性病护理管理数据/服务等等。

在某些实施例中，HIE 100提供集中的数据架构。但是，在某些实施例中，HIE 100也可利用组合的集中但部分分布式的数据架构。某些实施例创建健康信息的聚合的以患者为中心的视图。在某些实施例中，HIE 100提供用于质量改进、护理管理、研究等的不用识别的人口数据的一个或多个大型数据库。例如，通过HIE 100，患者和/或提供者可控制信息访问、保密和安全性。

HIE 100包括XDS储存库和登记110、一个或多个临床系统120、一个或多个实验室或放射系统130、一个或多个执业系统140、索赔历史150和个人健康记录(PHR)端口160。系统120、130、140可包括各种信息和/或查询源，例如健康护理机构、实验室、电子病历(EMR)系统、健康护理信息系统、保险系统、药剂系统等等。例如，实验室系统可包括关于对患者所执行的测试有关的信息和测试结果。例如，临床信息系统可包括与患者有关的各种类型的临床信息。例如，药剂系统可包括与患者可正使用的处方或药物有关的信息。例如，索赔历史150可包括保险人的记录。PHR端口160可包括一个或多个万维网查看器或端口、EMR系统、应用服务提供方(ASP)系统、健康护理信息系统、执业管理系统等等。源120-160是示例，并且可使用其它源。HIE 100的部件可通过例如软件、硬件和/或固件单独地和/或按照各种组合来实现。

在某些实施例中，例如，HIE 100提供技术架构、web应用、包括EMR能力的数据储存库以及基于人口的临床质量报告系统。该架构包括用于文档存储、查询和连通性的部件，例如XDS登记和储存库110以及索赔历史150。例如，端口160可包括向医师和患者的数据呈现的web端口应用。在某些实施例中，例如，XDS登记和储存库110可包括用于医师的基于预订的EMR的选项。在某些实施例中，例如，HIE 100为基于人口的临床质量改进和研究数据库提供报告工具。

在某些实施例中，XDS登记和储存库110是数据库或其它数据存储，它适合以加密形式来存储对于患者以及经授权医疗诊所可访问的患者病历数据和关联审计日志。在一个实施例中，XDS登记和储存库110可实现为服务器或一组服务器。XDS登记和储存库110也可以是连接到位于分离物理位置的其它服务器或者其它服务器组的一个服务器或者一组服务器。XDS登记和储存库110可表示分离形式的单一单元、单独单元或单元组，并且可通过硬件和/或软件来实现。XDS登记和储存库110可接收来自多个源的医疗信息。

使用例如在HIE 100中的XDS标准，可集成文档查询和存储，以便获得更有效和统一的信息交换。使用HIE 100，质量报告和研究可集成在RHIO和/或其它环境中或者与其集成。例如，HIE 100可提供可集成并且适合其它基于标准的系统的单厂家集成系统。

在某些实施例中，HIE 100帮助便于MQIC的实现。经由HIE 100，一组EMR用户可同意共享在XDS登记和储存库110的数据。HIE 100则可为该组提供对聚合数据的访问以用于研究、患者诊断和治疗的最佳执业、质量改进工具等。例如，通过MQIC和HIE 100，用户可通过更新的工具和扩大的EMR质量改进报告来帮助改进健康护理的质量。MQIC和HIE 100向成员提供与例如糖尿病、心脏病发作、中风(stroke)、高血压、充血性心力衰竭等的患者疾病有关的更新临床信息。数据交换也可用于临床研究。在某些实施例中，用户可经由HIE 100参加或退出特定项目/协作。在某些实施例中，安全因特网线路和/或基于万维网的端口可用于访问HIE 100以参与MQIC。

XDS提供跨健康护理企业的对形成患者EMR的临床文档的登记、分发和访问。XDS经由可缩放架构提供对患者文档的存储、索引和查询/检索的支持。现有XDS登记和储存库在IHE下定义成仅支持一个亲和域，其定义为一组健康护理企业系统，它们已经商定策略来经由共同的一组策略和单个登记相互共享其医疗内容。但是，某些示例支持多个亲和域，使得各亲和域保持它作为单独亲和域的自主权，但是与其它所涉及的亲和域共享硬件和软件的一个实例。XDS登记和储存库110可维护用于描述参与各亲和域的临床系统的亲和域关系表。一旦进行对文档的请求，则请求源是已知的，并且用于确定储存库110中的哪一个(哪些)文档对请求用户公开，因而维护亲和域的自主权。

在某些示例中，XDS登记和储存库110表示用于存储包括使用历史的患者病历的加密更新事务的中央数据库。在一个示例中，XDS登记和储存库110还存储患者病历。XDS登记和储存库110存储和控制对加密信息的访问。在一个示例中，可存储病历，而无需使用病历特定的逻辑结构。通过这种方式，XDS登记和储存库110不是可搜索的。例如，患者的数据可采用唯一患者拥有密钥在数据源来加密。然后，将数据上载到XDS登记和储存库110。患者的数据可下载到例如计算机单元，并且采用加密密钥本地解密。在一个示例中，访问软件、如患者使用的软件和医疗诊所使用的软件执行加密/解密。

在某些示例中，XDS登记和储存库110维护患者的登记和医疗诊所的登记。医疗诊所可在XDS登记和储存库110中采用姓名、地址和其它识别信息来登记。向医疗诊所发出与许可证关联的电子密钥。还向医疗诊所授予安全类别。安全类别通常基于临床类型。在某些示例中，从医疗诊所发送的请求和数据采用诊所的许可证以数字方式来签署，并且由XDS登记和储存库110来认证。患者可在XDS登记和储存库410中采用患者标识符和密码哈希来登记。患者还可在XDS登记和储存库110中采用姓名、地址和其它识别信息来登记。通常，向已登记患者发出包含唯一患者标识符和加密密钥的令牌(token)。该令牌可以是例如磁卡、fob卡或者可用于识别患者的另外某种设备。患者可利用其令牌以及在一个示例中利用用户标识符和密码来访问XDS登记和储存库110。

在某些示例中，XDS登记和储存库110可包括用于获取数据的例如实现获取算法的代码等程序代码。例如，获取算法可从一个或多个源获取与患者有关的数据。例如，获取算法可从源120-160的任一个获取信息。所获取的信息可用于在XDS登记和储存库110更新患者的病历。在某些示例中，XDS登记和储存库110还包括执行规格化算法的程序代码。规格化算法可处理由获取算法所获取的信息，并且对格式进行规格化。在某些示例中，XDS登记和储存库110可把从源120-160所获取的数据规格化成标准格式。例如，规格化数据采用XDS登记和储存库110存储在患者的病历中。作为替代或补充，一旦数据被获取，源120-160的一个或多个可将数据发送给XDS登记和储存库110。例如，源120-160的一个或多个可使患者在数据源进行登记。然后，源120-160的一个或多个可使用患者标识符和患者加密密钥对数据进行加密，并且将数据发送给XDS登记和储存库110，以便更新患者的病历。另外，数据可由源120-160在发送给XDS登记和储存库110之前进行规格化。

例如，XDS登记和储存库110可从例如120、130和140等多个源获取信息。XDS登记和储存库110可将所获取数据规格化到标准格式。算法单元可作为输入来接收存储在XDS登记和储存库110的患者的数据。在XDS登记和储存库110所存储的数据可以是来自各种源、例如来自付款人、金融机构、电子病历、执业管理系统、索赔数据库、药品公司、实验室、医师、医院和/或其它源的数据的汇编。在一个示例中，将患者的报告上载到XDS登记和储存库110，并且成为患者病历的一部分。

图2示出示例健康护理信息架构200。架构200包括HIE集线器510、一个或多个数据共享源230、一个或多个数据查询源240、一个或多个万维网查看器250、医师办公室应用服务提供方(ASP)260和一个或多个EMR 270。HIE集线器210可包括多个子部件，例如查询引擎212、网关或接口214、EMR共享临床储存库216、数据储存库218和万维网查看应用服务器220。例如，集线器210还可为数据的存储、检索和查询提供安全服务。例如，数据源230可包括EMR、放射、实验室和/或其它临床数据源。例如，数据查询源240可包括保险公司、药房、处方效益管理器和/或其它服务。健康信息架构200的部件可通过例如软件、硬件和/或固件单独地和/或按照各种组合来实现。

在操作中，文档共享可由架构200经由集线器210来便利化。使用例如健康信息技术标准组(HITSP)批准并且由美国健康与人类服务部(HHS)接受的标准、健康水平七(HL7)和/或医学数字成像和通信(DICOM)通信接口和文件格式标准等接口标准从一个或多个源220来传递患者数据。数据经由网关/接口214进入集线器210。在集线器210中，包括患者标识符交叉引用(PIX)和/或患者人口统计查询(PDQ)的主患者索引(MPI)可帮助便于相干患者数据的交换。此外，例如，记录定位符服务(RLS)可在集线器210中使用以用于使用跨企业文档共享(XDS)登记来帮助定位适当的共享文档。临床数据、文档和/或图像可存储在EMR共享临床储存库216、数据储存库218和/或例如放射/实验室230等源系统中。

一个或多个查询源240可使用例如HITSP批准和HHS接受的X.12和/或全国处方药计划理事会(NCPDP)通信标准等接口标准将查询信息传送给查询引擎212。查询引擎212用作消息集线器和/或交换机，以便将查询消息路由到适当的储存库。

在某些示例中，数据储存库218包括至少部分由Continuity ofCare Documents(CCD)或来自电子病历(EMR)的其它临床概括文档、从任何源230或240或者由个人健康记录(PHR)文档来填充的XDS文档储存库。这些文档可被转发给用户260和/或270或者由他们查询。例如，数据储存库218可包括交换个人健康记录(XPHR)内容(提供由健康护理提供者所请求的共同信息)。通过XPHR，患者可将其PHR信息的概括提供给提供者，并且提供者可在遇到健康护理之后建立对患者的PHR的更新。

一个或多个医师或其它健康护理办公室系统的团体可存储、访问或交换EMR共享临床储存库216、如基于ASP办公室系统260中的信息。例如，可利用与护理管理、决定支持、报告和/或医师signoff相关的信息。作为替代和/或补充，例如，可把来自数据储存库218的数据与一个或多个EMR 270(例如主护理提供者EMR)进行交换。作为补充和/或替代，经由万维网服务器或应用220把来自数据储存库218的数据提供给一个或多个万维网查看器或端口250。

在某些示例中，例如，万维网端口可用于便于访问信息、患者护理和/或执业管理。经由万维网端口可用的信息和/或功能性包括医嘱输入(order enter)、实验室测试结果审阅系统、患者信息、临床决定支持、药物治疗管理、时间安排、电子邮件和/或消息传递、医疗资源等的一个或多个。

在某些示例中，例如，万维网端口用作访问信息和应用的中央接口。例如，数据可通过基于万维网的端口或查看器来查看。另外，例如，数据可使用万维网端口来操纵和传播。数据可被生成、修改、存储和/或使用，并且然后例如经由万维网端口和HIE集线器传递给另一个应用或系统以便进行修改、存储和/或使用。

例如，万维网端口可以是本地(例如在办公室中)和/或远程(例如经由因特网和/或其它专用网络或连接)可访问的。例如，万维网端口可配置成帮助或指导用户访问数据和/或功能，以便于患者护理和执业管理。在某些示例中，例如，万维网端口可按照某些规则、偏好和/或功能来配置。例如，用户可按照特定期望、偏好和/或要求来定制万维网端口。

在某些示例中，XDS简档和/或协议(例如医疗概述集成简档的集成健康护理企业跨企业共享(IHE XDS-MS)协议)可用于定义用于患者文档共享的一个或多个实体之间的联合或连接。例如，XDS可用于形成一个查询，它采用关于特定患者的信息和/或其它判据来识别源，确定用于关联与患者相关的临床数据的标识符和/或其它判据并且向适当的源和/或储存库、例如XDS文档储存库518请求患者信息。如上所述，记录定位符服务(RLS)也可用于便于组织之间的信息的共享。

在某些示例中，集线器210在数据的传输和查询期间提供安全服务。安全服务可包括例如审计跟踪等审计记录和节点认证(ATNA)可计帐记录的生成和存储。另外，安全服务可包括患者隐私同意管理，例如基本患者隐私同意(BPPC)。安全服务还可包括跨网络系统的时间一致性或协调。

在某些示例中，架构200支持集线器210中的委托中介或动作器，以便在数据/服务提供方和数据/服务客户端之中关联身份和信用。一旦已经认证源和/或用户，则集线器210可使用认证来建立数据的安全上下文。例如，患者隐私同意、如BPPC可提供对数据和/或系统的访问控制的简档。从患者获得患者同意，并且其建立共享和使用患者数据的规则。患者隐私同意可与认证进行组合，例如以便帮助确保架构200中的可靠性和安全性。例如，交叉用户认证和患者同意可用于认证两个健康护理实体之间的患者的EMR信息的共享。BPPC简档可提供架构200中的隐私同意策略的实现，并且例如可扩展访问控制标记语言(XACML)等语言或协议可与BPPC配合使用以用于实现访问控制规则。

使用上述系统的一个或多个，可提供端对端数字健康服务和平台以便帮助实现个性化、自适应并且更综合的患者病历，它与患者的医师/护理小组、付款人、雇主和金融机构相连接。病历可经由XDS登记和储存库来聚合和相连，并且由数据以及服务的多个源/用户来共享。例如，来自医师的患者的电子病历、诊所或医院电子病历、付款人索赔历史、药学慢性病管理和/或金融机构/帐户的信息可使用临床HIE标准交互式地聚合。例如，这类互连帮助个人健康记录自动适合患者的偏好，以便实现最可能的顺应性水平和/或跟上患者变化的健康状况。另外，患者了解和决策制定可通过提供自动适合患者的特定和变化的健康状态并且提供综合教育和顺应性工具来帮助驱动肯定的健康结果的基于标准的组织工具来便利化，。

某些示例实现跨多个治疗和健康领域的改进的文档管理和测量。某些示例提供推荐护理的递送和质量连同患者顺应性和结果管理。例如，使用上述企业模型，为各种目标听众、位置和方法采用疾病状态协议产生可测量、有意义并且可缩放(scalable)的结果。经由访问端口、如基于万维网的访问端口，例如患者、临床医生或付款人等用户可在护理点和/或看病点外面(outside a visit)来访问信息和教育服务以及生成测量的结果。

例如，某些示例通过EMR平台来提供对患者的临床医生指导干预，包括将治疗和疾病管理方针结合到EMR中、提供专业教育和训练(例如一般疾病概览)和基于患者护理的信息等以及经由EMR以电子方式提供定制的患者教育。例如，结果可经由EMR/MQIC和企业模型中的访问端口来测量和管理。

除了临床PHR/EMR系统和方法之外，信息和访问还可经由有权访问远程服务器(例如远程PHR服务器)的本地用户计算机来提供。图3示出由个体控制以便在医师办公室管理个体的临床信息的示例PHR系统300。系统300包括数据中心310、患者家庭计算机320、临床服务器330、前台或接待接口340和医师计算机350。

在一个示例中，数据中心310包括PHR数据库和/或其它数据存储器314，它用于以加密形式来存储患者以及经授权护理提供者组织(包括医院、医生办公室和/或其它诊断/治疗机构)可访问的患者病历数据和关联审计日志。在一个示例中，例如，数据中心310可以是服务器或一组服务器，和/或驻留在服务器或一组服务器上。数据中心310也可以是连接到位于分离物理位置的其它服务器或者其它服务器组的一个服务器或者一组服务器。数据中心310可表示分离形式的单一单元、单独单元或单元组，并且可通过硬件和/或软件来实现。在一个示例中，数据中心310接收来自多个源的医疗信息。例如，临床信息源可包括各种诊所、实验室、药房以及患者本身。

数据中心310还包括万维网服务312，以便提供患者计算机320、临床服务器330、前台接口340、医师计算机350和PHR数据库314之间访问控制和接口能力。例如，经由数据库314的存储和/或检索数据的请求通过数据中心万维网服务312来路由并且由其按照一个或多个规则、偏好和/或用户简档来批准。

在一个示例中，数据中心310的数据库314表示用于存储包括使用历史的患者病历的加密更新事务的中央数据库314。在一个示例中，数据库314还存储患者病历。数据中心310存储和控制对加密信息的访问。在一个示例中，可存储病历，而无需使用病历特定的逻辑结构。通过这种方式，数据库314不是可搜索的。例如，患者的数据可采用唯一患者拥有密钥在数据源来加密。然后，将数据上载到数据中心310。数据中心310不处理或者存储未加密数据，因而最小化隐私担忧。患者的数据可下载到例如计算机，并且采用加密密钥本地解密。在一个示例中，访问软件、如患者使用的软件和医疗诊所使用的软件执行加密/解密。

例如，数据库314可按照临床、患者、患者/临床关联和文档来构成。临床信息可包括例如标识符、姓名和地址、公开密钥以及一个或多个安全类别。患者信息可包括例如标识符、密码哈希和加密电子邮件地址。患者/临床关联信息可包括临床标识符、患者标识符、加密密钥以及一个或多个优先安全类别(override security category)。例如，文档信息可包括标识符、患者标识符、临床标识符、安全类别和加密数据。

数据中心310可维护患者的登记和医疗诊所的登记。医疗诊所可在数据中心310中采用姓名、地址和其它识别信息来登记。向医疗诊所发出与许可证关联的电子密钥。还向医疗诊所授予安全类别。安全类别通常基于临床类型。在一个示例中，从医疗诊所发送的请求和数据采用诊所的许可证以数字方式来签署，并且由数据中心310来认证。患者可在数据中心310中采用患者标识符和密码哈希来登记，而无需任何识别信息。通常，向已登记患者发出包含唯一患者标识符和加密密钥的令牌。该令牌可以是例如纸卡、磁卡、fob卡或者可用于识别患者的另外某种设备。患者可利用其令牌以及在一个示例中利用用户标识符和密码来访问数据中心310。

如上所述，数据中心310经由万维网服务312与患者计算机320、临床服务器330、接待接口340和医师计算机350进行通信。数据中心320、患者计算机320、临床服务器330、接待接口340和医师计算机350可经由可处理送往/来自数据中心310、患者计算机320、临床服务器330、接待接口340和物理计算机350的电子通信的任何计算机硬件、固件和/或软件进行通信。

例如，用户可从数据中心310下载病历，经由例如个人或手持计算机等患者计算机320对病历解密，并且然后本地处理该数据。例如，在患者计算机320处的查看器322可用于PHR通信、数据加密/解密和查看。例如，查看器322可便于从数据中心数据库314下载患者的PHR数据，并且将患者数据存储在患者计算机320处的PHR高速缓存324中。

类似地，医师计算机340可用于从数据中心310下载病历信息。例如，病历信息可存储在PHR数据库314中，并且是由医师计算机340经由万维网服务312可访问的。作为另一个示例，病历信息可经由临床服务器330从临床EMR 332存储在数据中心310。

在某些示例中，患者计算机320、临床服务器330、前台接口340和/或医师计算机350中的一个或多个可用于将数据发送给数据中心310供病历更新。例如，在前台接口340的接待员和/或患者可例如经由PHR卡打印机342来访问PHR数据中心310用以PHR签署、报到和/或标识生成。作为另一个示例，在医师计算机350的用户可经由便于PHR数据的PHR通信、加密/解密和显示的查看器352来访问PHR数据中心310。例如，查看器352可用于为医师从数据库314检索PHR数据，供存储在活动患者的PHR高速缓存354中。

作为替代和/或补充，例如实验室结果、药学信息、患者检查信息和图像获取等的源可提供数据供存储在数据中心310。在某些示例中，患者和/或经授权临床医生可使用患者和/或临床医生标识符、许可证等进行登记或登录。然后，数据可使用标识符和加密密钥来加密，并且发送给数据中心310，以便更新数据库314中的患者的病历。另外，数据可在发送给数据中心310之前经过规格化。

在一个示例中，数据中心310、患者计算机320、临床服务器330、接待接口340和/或医师计算机350可经由网络连接、例如通过因特网或专用网络连接到相互之间的一个或多个。

图4示出示范用户接口架构400。架构400包括用户接口变换引擎402、查询生成/扩充引擎403、信息合成引擎409、多文档概括引擎414以及到连通性框架445的一个或多个连接器419。架构400的部件是由用户经由处理装置、如计算机或手持装置上的用户接口401可访问的。例如，用户可经由用户接口401提交信息的查询。

查询生成/扩充引擎403包括刺激源(stimulus)404、一个或多个查询生成器405以及一个或多个访问机构406，以便搜索一个或多个数据源407以产生查询和收集文档408。例如，将查询和收集文档408传递给信息合成引擎409，它包括处理和应用认知推理的应用程序410、411、412、413，例如以便根据语义方针、用户偏好和域相关信息将查询和收集文档408组织为对于请求用户有意义的一个或多个单元。包括合成器的工具箱可采用例如冗余信息的聚合、消除、信息的小型概括和结果的融合等合成决定逻辑(CDL)来合成信息。例如，应用程序可包括一个或多个数据驱动应用程序410、企业应用接口411、任务/过程驱动应用程序412和数据结构特定应用程序413。应用程序410、411、412和/或413可包括与新数据类型、新数据结构、域特定任务/过程、新应用接口等相关的一个或多个模板。查询和收集文档408的合成和处理响应用户查询而产生一束信息410。

多文档概述引擎414接收文档束410，并且将这些文档分割成小节415。小节415根据相似概念416来群集。然后从概念416形成元文档417。概述418从元文档417生成。查询结果410、元文档417和/或元文档概述418可经由用户接口401提供给用户。

例如，经由到连通性框架445的连接器419，用户接口401及其引擎403、409、414可响应用户查询而经由接口401发送和接收信息。例如，查询引擎403可访问连通性框架445，以便查询一个或多个数据源407。

连通性框架445包括客户框架420。客户框架420包括一个或多个产品422的上下文管理器(context manager)421、患者搜索423、登记导航器424和查看器425。因此，在某些实施例中，连通性框架420可便于经由用户接口401对信息的查看和访问，并且与用户接口401分隔开。经由连通性框架445，查询引擎403和/或用户接口401的其它部分可通过多层(tier)来访问信息和/或服务。

例如，层可包括客户框架层426、应用层428和集成层430。例如，客户框架层426包括便于信息的输入和输出的一个或多个客户端web服务器427。应用层428包括与企业和/或部门使用相关的一个或多个应用程序429，例如商业应用程序、电子病历、企业应用程序、电子健康端口等等。集成层430包括合并互通性平台服务器435，它经由例如缺省和/或定制接口的一个或多个代理点(factory)436和/或顾客437接口、使用各种消息格式、如web服务(WS)、X12、健康水平七(HL7)等与消费者信息技术(IT)443进行通信。例如，合并互通性平台435可经由公共服务模型(CSM)和/或通用消息模型与应用层428的一个或多个应用程序429进行通信。

如图所示，例如，在图4中，合并互通性平台435包括企业服务总线(ESB)431、登记、数据和服务集合432、配置信息433和临床内容网关(CCG)接口引擎434。例如，ESB 431可以是符合Java商业智能(TBI)的ESB。ESB 431可包括用于使用例如X12、HL7、SOAP(简单对象访问协议)等特定协议/数据格式来访问万维网服务的一个或多个端点或位置，例如以便传送消息和/或其它数据。例如，使用CSM，ESB 431便于与应用层428的应用程序429的通信。经由ESB 431，例如，可响应查询而将登记、数据和服务储存库432中的信息提供给应用层431。配置信息433可用于指定一个或多个参数，例如经授权用户、个别用户和/或用户组/类型的授权等级、安全配置信息、隐私设定、审计信息等。例如，CCG接口引擎431接收来自消费者IT框架443的数据，并且将该数据提供给登记432和/或应用层431中的应用程序429。

如图所示，例如，图4中，消费者IT 443包括对第三方电子主患者索引(eMPI)438的支持、对地区健康信息组织(RHIO)439的支持、一个或多个第三方应用程序440、对跨企业文档共享(XDS)储存库441的支持、对XDS登记442的支持等等。与互通性平台435结合使用消费者IT 443，RHIO网关和第三方应用程序集成可经由一个或多个接口提供给连通性框架445和/或用户接口401的查询生成/扩充引擎403。

消费者IT框架443可组织成提供跨多个组织的健康护理信息的存储、访问和可搜索性。消费者IT框架443可服务于团体、地区、国家、一组相关健康护理协会等等。例如，消费者IT框架443可采用RHIO 439、国家健康信息网络(NHIN)、医疗质量改进协会(MQIC)等等来实现。在某些实施例中，消费者IT 443连接健康护理信息系统，并且帮助使它们是以安全、可持续并且基于标准的方式可互通的。

在某些实施例中，例如，消费者IT框架443提供技术架构、万维网应用、包括EMR能力的数据储存库以及基于人口的临床质量报告系统。该架构包括用于文档存储、查询和连通性的部件，例如XDS登记442和储存库441。在某些实施例中，例如，XDS登记442和储存库441可包括用于医师的基于预订的EMR的选项。在某些实施例中，XDS登记442和储存库441实现为数据库或其它数据存储器，它适合以加密形式来存储患者以及经授权医疗诊所可访问的患者病历数据和关联审计日志。在一个实施例中，XDS登记442和储存库441可实现为服务器或一组服务器。XDS登记442和储存库441也可以是连接到位于分离物理位置的其它服务器或者其它服务器组的一个服务器或者一组服务器。XDS登记442和储存库441可表示分离形式的单一单元、单独单元或单元组，并且可通过硬件和/或软件来实现。XDS登记442和储存库441可接收来自多个源的医疗信息。

使用例如在消费者IT框架443中的XDS标准，可集成文档查询和存储，以便获得更有效和统一的信息交换。使用消费者IT 443，质量报告和研究可集成在RHIO 439和/或其它环境中或者与其集成。例如，消费者IT 443可提供可集成并且适合其它基于标准的系统的单厂家集成系统。

经由消费者IT框架443，一组EMR用户可同意共有在XDS登记442和储存库441的数据。消费者IT框架443则可为该组提供对聚合数据的访问以用于研究、患者诊断和治疗的最佳实践、质量改进工具等。

XDS提供跨健康护理企业的对形成患者EMR的临床文档的登记、分发和访问。XDS提供对经由可缩放架构的患者文档的存储、索引和查询/检索的支持。但是，某些实施例支持多个亲和域(定义为已经商定策略来经由一组公共策略和单个登记相互共享其医疗内容的一组健康护理企业系统)，使得各亲和域保持其作为单独亲和域的自主权，但是与其它所涉及亲和域共享硬件和软件的一个实例。XDS登记442和储存库441可维护用于描述参与各亲和域的临床系统的亲和域关系表。一旦进行对文档的请求，则请求源是已知的，并且其用于确定储存库441中的哪一个(哪些)文档对请求用户公开，因而维护亲和域的自主权。

在某些示例中，XDS登记442和储存库441表示用于存储包括使用历史的患者病历的加密更新事务的中央数据库。在一个示例中，XDS登记442和储存库441还存储患者病历。XDS登记442和储存库441存储和控制对加密信息的访问。在一个实施例中，可存储病历，而无需使用病历特定的逻辑结构。通过这种方式，XDS登记442和储存库441不是可搜索的。例如，患者的数据可采用唯一患者拥有密钥在数据源来加密。然后，将数据上载到XDS登记442和储存库441。患者的数据可下载到例如计算机单元，并且采用加密密钥本地解密。在一个示例中，访问软件、如患者使用的软件和医疗诊所使用的软件执行加密/解密。

在某些示例中，XDS登记442和储存库441维护患者的登记和医疗诊所的登记。医疗诊所可在XDS登记442和储存库441中采用姓名、地址和其它识别信息来登记。向医疗诊所发出与许可证关联的电子密钥。还向医疗诊所授予安全类别。安全类别通常基于临床类型。在某些示例中，从医疗诊所发送的请求和数据采用诊所的许可证以数字方式来签署，并且由XDS登记442和储存库441来认证。患者可在XDS登记442和储存库441中采用患者标识符和密码哈希来登记。患者还可在XDS登记442和储存库441中采用姓名、地址和其它识别信息来登记。通常，向已登记患者发出包含唯一患者标识符和加密密钥的令牌。该令牌可以是例如磁卡、fob卡或者可用于识别患者的另外某种设备。患者可利用其令牌以及在一个示例中利用用户标识符和密码来访问XDS登记442和储存库441。

如图所示，例如，图5中，提供信息架构500以便支持来自多个不同类型的数据源的信息的检索、合成(例如捆绑)和呈现。架构500的部件包括查询增强引擎505、信息合成引擎510、概述引擎515、信息控制器520、知识库525、模型530和信息状态535。

查询增强引擎505生成查询、搜索数据储存库并且过滤结果，以便根据上下文503来查找相干信息。信息合成引擎510将检索信息合成并且组装成信息束，该信息束组织为与用户是相干的。概述引擎515包括单和多文档概述引擎，以便提供内容的概述、群集以及检索信息的突出主题的识别。信息控制器520提供结构以及对检索信息的交互访问，并且使本发明的不同可视化策略的使用能够更为有效。知识库525为用户、事件和信息提供模型(例如用户模型、信息模型、事件模型、本体论、语汇等)，以便实现语义关系的利用。

图5示出这些技术的高级视图，它们与用户接口系统集成以便改进相干信息的检索、将收集信息合成为有意义的信息束550并且向特定上下文503的用户显示该信息。用于查询和显示和/或处理结果的一个或多个应用程序501可以是运行于个人计算机/工作站的厚客户端或者运行于手持或者其它移动装置(例如个人数字助理或蜂窝电话)的移动应用程序。这些应用程序401可例如通过组装可显示不同种类的数据的多个信息小部件来组成。例如，一个小部件可用于显示概述患者药物治疗的文本信息，而另一个小部件可使x射线(例如图像)或超声波(例如视频)能够被显示。其它小部件可实现不同维之中的数据、如时间的显示，并且允许用户与数据交互，例如以便下探至更多细节。

信息架构500提供机构以用于使应用程序501从完全不同的数据源检索信息，并且以结构化方式将那个数据提供给应用程序501，以便实现对用户的有意义信息显示。信息小部件经由信息控制器520与架构500进行交互。经由控制器520，应用程序501可提供与用户(例如角色和偏好)和基础事件(例如患者中风诊断检查)有关的上下文503。控制器520可将这个信息提供给查询增强引擎505，以便识别数据源，并且经由连通性框架540的一个或多个查询507来检索最相干信息，以便提供结果542。然后，检索信息由信息合成引擎510来检查，供捆绑和合成。一些信息可在将信息束(或i束)550返回给应用程序501供呈现之前由概述引擎515来概述。

知识库525包含角色、用户、事件和信息的模型以及医疗本体论。这些语义概念可用于其它部件、如查询增强引擎505或信息合成引擎510，以便为用户改进信息的检索和捆绑。

对于一些应用程序501，可能希望用户输入新数据或者对已经检索的数据进行注解。信息控制器520提供用于进行这些数据更新的机构。例如，新数据和/或其它动作555可从应用程序501提供给信息控制器520，供将来使用。作为替代或补充，新数据和/或注解560可经由信息控制器520提供给连通性框架540。

因此，语义信息可由部件共享和利用，以便用于根据语义概述和关系来检索信息，根据语义关系来组织检索信息，并且使用语义概念和关系显示所检索的信息和数据之中的关系。例如，患者信息的纵向时间显示可通过实现语义相关的数据之间的各种关系的显示得到改进。可集成推理机构，以便使信息能够更有效地插入工作流中，以便实现在患者护理点的更大决定支持。可集成推理引擎，以便使信息能够在患者护理期间在不同点动态传递给用户。

某些示例允许健康护理信息系统查找和利用在患者护理的时间线上的相干信息。例如，搜索驱动、基于角色的接口将允许最终用户在健康护理网络上无缝地访问、输入和搜索医疗信息。例如，自适应用户接口通过根据个体需要量身定制并且响应工作域的变化的以工作为中心的接口来提供能力。语义技术可用于模型域概念、用户角色和任务以及信息关系。语义模型使应用程序能够根据关于用户和任务的文本信息更有效地查找、组织并且向用户呈现信息。形成框架的用于查询和结果生成的部件包括：用于构建应用程序的用户接口框架/部件；实现基于语义信息和上下文的信息的更有效检索、聚合和合成的服务器部件；以及用于连接到分布式环境中的不同类型信息源的数据访问机构。

各种用户接口框架和技术可用于构建应用程序，包括

ASP.NET、

Windows PresentationFoundation、

Web Toolkit、

Silverlight、

等等。例如，应用程序可从信息小部件库组成，以便显示多内容和多媒体信息。另外，框架使用户能够设计小部件的布局，并且与基础数据进行交互。

健康护理信息可使用各种数据库和存储技术以及数据格式分布于多个应用程序之中。为了提供公共接口以及对跨这些应用程序驻留的数据的访问，提供连通性框架(CF)，它利用共同数据和服务模型(CDM和CSM)以及面向服务的技术、如企业服务总线(ESB)来提供对数据的访问。

在某些示例中，例如HIE、EMR、PHR和/或其它临床信息存储系统或网络等健康护理信息框架可被挖掘，以便根据一些链接判据(家庭、健康状况等)来连接记录。图6示出示例电子病历表600。如图6所示，电子病历表600包括允许用户访问患者目录和所有可用病历表的选择选项610。例如姓名、年龄、性别和出生日期等患者识别信息620经由表600显示供审阅。显示包括例如正出现问题、过敏性、正进行药物治疗的列表等信息的患者状态信息630，以便通知提供者并且使他或她得到患者的最新状态。健康概述推荐640提供正出现问题的概述以及药物治疗和护理的指示。推荐640可以是如期望那样那么长且详细。例如，概述640可自动打印和/或输出到学校和营地表格，通知护士和护理人员关于患者问题。还显示可选地包括例如符合资格的儿童的疫苗等附加细节的保险信息650。

患者的图片660、如黑白或彩色照片可作为表600的一部分来显示。在一些示例中，选择图片660和/或按钮662、如紧接图片660的加号(+)允许用户查看该患者的附加图片。例如“Last”按钮664等附加选项可提供患者的最后一次访问和/或若干先前访问的概述。“Family”按钮666可用于提供与患者的例如父母、兄弟等家庭成员和/或其它有关连的个体有关的信息。作为替代或补充，“Relationship”按钮可用于提供与患者的整个关系树有关的信息，涵盖与其它患者的所有关系链(relationship linkage)。

一列和/或另一组按钮670提供对经由表600可访问的一个或多个临床系统中的工具和特征的访问。从表屏幕600，提供者可访问例如事件年表、生长表、药物治疗、注释、计划、测试等功能性。与工具/特征选项670对应的日期672通知提供者关于最后一次预防检查、生长表、药物治疗等，并且为提供者更新测试结果的状态和/或转诊介绍(referral)。

清单680提供例如医院、诊所、医师办公室等临床环境中未决任务的指示、提醒和/或状态报告。例如，清单680帮助使提供者能够在办公室将任务分派给不同的人，并且跟踪进度。

图7示出在电子病历和/或其它电子数据之中识别患者间关系的方法700的流程图。例如，患者关系信息的聚合可通过涉及自动(并且可能手动)步骤的链接过程来实现。在框710，处理电子记录(例如EMR、HER、PHR和/或其它电子患者文档)，以便识别患者间关系。例如，在例如EMR、PACS、RIS、执业管理和/或其它计算机系统等计算机系统上安排成批处理过程，以便相对于特定患者、患者组来检查P2P关系。在一些示例中，自动链接过程作为成批处理过程来运行，它定期扫描患者信息数据存储器中的匹配现有患者的“相关/依赖/关联方”细节。

在框720，为相关/依赖/关联方所提供的标识符被读取，并且与可用患者标识符进行比较。患者标识符可以是任何标识符(例如数字)和/或有助于唯一识别患者的属性的组合。在框730，确定标识符之间的匹配。如果获得精确匹配，则在框740，患者记录针对相关方来标记，并且添加到“完全匹配”列表。如果对于给定标识符的任一个获得一个以上患者记录匹配，则患者记录针对相关方来标记，并且添加到“未决匹配”列表。

如果标识符匹配失败，则在框750，该过程查找例如电话号码、姓名、地址等其它相干属性和/或属性的组合，以便帮助识别患者。这些属性可配置成包含在患者搜索中。如果对于其它属性找到一个或多个匹配，则在框760，患者记录针对相关方来标记，并且添加到“未决匹配”列表。

在一些示例中，在详细审查之后批准/拒绝匹配的人工过程遵循自动过程。如果使匹配结果评级可用于匹配算法，则评级可帮助对匹配结果确定优先顺序，并且因而帮助人工审阅和链接过程。匹配算法可配置成将一个或多个标识符用于匹配。示例标识符可包括但不限于主患者标识符(例如由本地/团体/全国机构所发出的唯一标识符)、医院病历编号(MRN)、医院住院编号、医院门诊编号、社保号、唯一纳税标识号、雇员标识符编号、保险单号、保险凭证号、保险ID卡号、保险索赔标识符(Insurance Claim Identifier)、健康计划编号、电话号码(例如住宅、办公室、移动电话等)、电子邮件标识符等等。对于匹配算法中的比较会是有用的其它属性可包括但不限于姓名(例如名字、中间名字、姓氏)、出生日期、出生时间、地址(例如办公室、住宅、通信地址等)、邮政编码(例如邮递区号)、年龄、性别、婚姻状况、血型、种族、信仰等等。

在框770，在临床系统中针对患者记录标记为“完全匹配”和“未决匹配”的相关方由管理员来审阅。根据管理员的审阅和检验，项被批准(框780)或者拒绝(框785)。来自列表的批准链接识别系统中的患者之间的相关/关联。这些患者间链接可在系统中持续，供以后参考。

在一些示例中，在患者链接过程已经完成其第一轮之后并且在可能的患者间关系已经识别和链接之后，通过入院/登记、出院或转院期间的患者信息馈送(基于HL7和/或其它)和/或操作人员输入对一个或多个临床系统中的患者信息的进一步变更可触发集成链接过程(自动和人工)。在集成链接过程中，自动链接过程与人工链接过程进行组合。通过这个过程，在对现有患者数据发生改变时和/或在添加新患者数据时识别与相关方可能的患者匹配。如果某些关系停止存在或者经过修改，则相应地更新患者间链接。提示操作人员批准/拒绝匹配和关系，并且相应地保存/丢弃该链接。

可聚合P2P关系，并且从单个信息系统(例如医院信息系统或放射信息系统)链接记录。还可从可能沿用不同数据库方案的若干这类系统来累计数据。在这类情况下，可对操作数据存储器(ODS)应用ETL(提取、变换、加载)过程。数据格式可在对ODS运行链接过程之前被清理和标准化。

在一些示例中，P2P关系使用HL7标准词汇来建模。例如，P2P关系可使用HL7 ver 2.x按照数据定义表#0063来建模。对于HL7 v3，列表更详尽且在词汇“RoleCode”(OID-2.16.840.1.113883.5.111)中可出现。为了便于说明，HL7 v2.5表#0063-Relationship复制如下：

医院信息系统可存储和交换关于患者的其它相关方的信息。例如，HL7 v 2.x消息结构在ADT(入院/登记、出院或转院)消息中提供下列段(segment)：

NK1-近亲/关联方Segment，以及IAM-患者有害反应信息Segment。这些段可用于将患者记录与信息系统链接。

图8提供显示和便于链接的P2P关系的使用的示例用户接口800。用户接口800示出图标810-813(可选地由链接个体的图片或缩影表示或者其它图形表示来替代)，其表示那些代表图标810-813之间的电子患者记录和链接820-825。患者与另一个患者的关系(例如父亲、儿子、兄弟、姐妹、母亲、女儿、丈夫、妻子)的指示830-837也可经由接口800来提供。通过经由接口800选择图标810-813和/或链接820-825，可检索与患者记录和/或P2P关系有关的附加信息。

图9示出P2P关系的备选表示900。如图9所示，患者910通过姓名和/或标识符来标识。表示900示出与患者910具有某种关系的其他患者920-923。那些患者920-923通过姓名和/或标识符来标识。患者910与其它患者920-923之间的指示930-933也在表示900中提供。

图10示出提供针对特定患者1010的等级关系的图示的示例用户接口100。在这个示例中，各种线条表示患者1010与其它个体1020-1036之间的关系中的重要性程度。作为替代或补充可采用某种颜色(例如绿色)来表示的最粗的线条1040指示会极大地影响到患者的家庭健康历史记录的关系。作为替代或补充可采用另一种颜色(例如橙色)来表示的不太粗的线条1050指示应当被适当考虑以构建患者的家庭健康历史的关系。作为替代或补充可采用另一种颜色(例如黑色)来表示的细线条1060指示可能或者可能不会影响到患者的家庭健康历史的关系。通过点击和/或以其它方式选择图标1010、1020-1036，可检索与那个个体有关的信息(例如，与此人有关的电子病历和/或其它电子信息和/或此人与患者1010之间的关系)。

在某些示例中，提供一种方法1100(图11所示)，以便将患者的唯一标识符与其家庭成员的标识符进行链接以构建家庭医疗病史。家庭医疗病史可用于例如更好地帮助具有乳癌、直肠癌、糖尿病、心脏病等医疗病史的患者。家庭医疗病史对于例如关心产前护理和遗传学的怀孕妈妈也具有极大用途。家庭医疗病史可以对执业医生在访问详细家庭医疗病史时在收集与疾病发展的风险有关的信息方面有极大帮助。

方法1100便于一种链接家庭的不同成员以便共享其病历的机构。在框1110，提供一种登记，其中采用唯一(可选地包括基本上唯一(例如对给定设施、企业、网络等是唯一的))标识符来登记成员。在框1120，各成员可请求到另一个家庭成员和/或其它亲戚的链接(通过定义与他/她的唯一等级关系)。例如，John Doe可将其信息输入登记，并且可请求到其家庭成员Jane Doe(姐妹)、Jeff Doe(叔父)和JoannaDoe(母亲)的链接。括号中的项帮助定义John Doe与其他人之间的等级关系。如以上结合图9所示和所述，这些家庭成员及其等级关系可通过图形方式来显示，供用户(例如患者、医师等)查看和/或选择以进行检索和/或输入附加信息。

在框1130，从链接的人获得同意。例如，指示为与患者具有某种关系的人可接收指示该关系并且请求确认该关系和/或批准连接以及关联地访问对家庭健康历史有影响的至少某个信息的电子消息。可直接经由电子消息和/或通过重定向到电子接口(例如基于万维网的接口)以输入同意和/或其它附加信息来直接方便该同意。

在框1140，在已经获得同意之后，将访问提供给链接的病历。在一些示例中，患者可能或者可能无法直接访问其家庭成员的病历。而是可使信息匿名可用。例如，信息的匿名可逐个记录地来确定。

在一些示例中，预计患者隶属于亲和域，使得该患者可共享病历并且建立患者之间的链接。亲和域是一组健康护理企业，它们同意使用一组共同的策略共同工作，并且共享共同基础设施。

图12示出采用可用的电子医疗数据来识别和利用患者与其他人之间的关系的示例患者关系识别系统1200。该系统包括处理器1210，它处理患者电子医疗信息，以便识别患者之间的关系，并且提供记录之间的链接。患者身份源1220生成患者标识符。(等级)关系指示器1230帮助检查和评估家庭成员和/或其它相关人员的病历对患者的病历的重要性。患者登记1240用于登记患者标识符并且链接标识符。例如，标识符还可以可用于拉取和/或同步多个源之中的信息。患者可与亲和域关联，例如以便帮助便于信息的链接和共享。例如，IHE的XDS简档/协议可用于共享和/或连接系统和/或机构之间的文档。使用IHE简档/协议、如XDS，例如可定义用于搜索和/或识别共享/连接文档中的信息的文档格式标准。

系统1200还可包括一种同意机构(consent mechanism)1250，以便获得家庭成员和/或其它相关人员对共享他们病例(在接收到与患者链接的请求时)的批准。另外，例如PACS、RIS、EMR、HER、PHR和/或其它电子数据源等文档源1260可用于提供和访问病历。

使用系统1200，可链接患者，以便构建更综合的家庭和/或其它关系(例如工作环境、地理等)医疗病史，以便帮助患者的诊断和/或治疗。当患者知道其家庭或者关系等级中的关连时，他或她可设法收集与感染特定疾病的风险有关的附加个人信息。通过使重要信息方便地可为健康护理提供者可用，医院和/或其它健康护理企业可提高护理提供的效率。例如，链接的电子病历可由系统1200使用以用于根据对于从若干信息源所收集的个人病历的更广泛访问来提供跟踪和倾向于各种信息集合的能力。

在一些示例中，采用以患者为中心的方式以及经由某些患者之间的链接或关系来存储和访问医疗数据。从电子存储的角度以及从系统呈现的角度，“家庭链接”和/或“关系链接”可用于以电子方式将不同患者链接在一起。例如，患者可请求和批准链接到父母、同胞、子女和/或其它相关个体。链接可用于输入和/或建立到例如存在于临床系统、EMR、HER、PHR等的电子医疗信息的可搜索连接。在一些示例中，建立链接的请求必须由所涉及的各方相互商定。

在一些示例中，链接可以并不局限于家庭成员链接。例如，处理相似问题的两个患者可选择相互链接，使得初次医生可跟踪各患者的治疗和进度，并且比较结果。在一些示例中，两个以上的人可相互链接，以便提供一组链接，作为对人与人之间的关系链接的替代和/或补充。

一旦批准链接到位，则当临床医生访问患者的医疗信息时，批准临床医生、如医师访问链接的记录。例如，链接的信息(例如父母、同胞和/或子女信息等)可由临床医生在患者治疗过程中使用。

例如，链接的信息可用于提供一个或多个健康毛病的早期指示。使用链接的信息，临床医生可帮助应用预防措施来针对患者对于特定疾病或毛病的易患病体质。

在一些示例中，不同患者之间的链接可维护在数据库的交叉引用表中。链接批准可维护在数据库中，并且可在个体稍后选择退出时被更新。

当查看临床系统中的患者记录时，来自链接的患者的数据可被利用以用于按需求提供最近的电子信息。治疗可针对链接的患者来多方查证，以便确定是否有不利健康状况可能出现。例如，可呈现早期健康推荐，以便使临床医生知道患者的一个或多个可能健康状况。在一些示例中，数据可被利用，并且通过例如PHR系统不仅呈现给临床医生，而且还呈现给患者。例如，如住院临床系统、门诊EMR系统、实验室系统等的其它系统可将链接的数据提供给患者和/或临床医生。

因此，某些示例可根据更详细的家庭医疗病史和/或其它相关信息来帮助执业医生收集与患者的疾病发展的风险有关的信息。通过例如EMR、PHR、PACS等的分布式系统中的多个数据点，某个示例在将信息集合在一起以审阅多个适用记录以供患者护理会是有帮助的。某些示例可与例如PACS、RIS、PHR、EMR、EHR等系统(例如GE

PACS、EMR等)集成，以便获得和/或链接病历。等级可引入患者关系中，以便强调/不强调健康状况相关性等。

某些示例将患者关系信息聚合在特定医院信息系统中和/或跨若干这类系统来聚合。例如，为关系的简易可视化而提供关系树的图形表示。可在由管理员、用户、缺省等配置的患者护理工作流程(例如，登记、ADT等)中的各个点根据患者与其他患者的关系来为操作人员生成通知。此外，除了常规患者诊断和治疗之外，某些示例还实现在急诊、临床研究、临床分析等期间利用关系信息。在某些示例中，可作为患者联机端口(例如，VPN和/或万维网可访问端口等)的一部分来访问根据关系所组织的健康记录。

图13是可用于和/或编程为实现本文所述的示例系统、设备、制造产品和方法的示例处理器平台P100的示意图。例如，处理器平台P100可由一个或多个通用处理器、处理器核心、微控制器等等来实现，它们通过基于本文所述系统和方法的编程和/或配置可成为特定或专用机器。

图13的示例的处理器平台P100包括至少一个通用可编程处理器P105。处理器P105运行存在于处理器P105的主存储器中(例如在RAM P115和/或ROM P120中)的代码化指令P110和/或P112。处理器P105可以是任何类型的处理单元，例如处理器核心、处理器和/或微控制器。处理器P105除了别的以外还还可运行图7和图11的示例过程，以便实现本文所述的示例方法、系统、设备和制造产品。

处理器P105经由总线P125与主存储器(包括ROM P120和/或RAM P115)进行通信。RAM P115可由动态随机存取存储器(DRAM)、同步动态随机存取存储器(SDRAM)和/或任何其它类型的RAM装置来实现，并且ROM可由闪速存储器和/或任何其它期望类型的存储器装置来实现。对存储器P115和存储器P120的存取可由存储控制器(未示出)来控制。示例存储器P115可用于实现本文所述的示例数据存储。

处理器平台P100还包括接口电路P130。接口电路P130可由任何类型的接口标准来实现，例如外部存储器接口、串行端口、通用输入/输出等等。一个或多个输入装置P135和一个或多个输出装置P140连接到接口电路P130。输入装置P135可用于例如接收来自远程PHR服务器和/或数据库的患者文档。示例输出装置P140可用于例如提供患者文档供在远程PHR服务器和/或数据库审阅和/或存储。

上述某些示例可适用于基于健康信息交换(HIE)标准的架构和部件，例如文档存储、查询等等。某些示例提供万维网端口应用供向患者的数据呈现。例如，基于万维网的端口可根据患者的特定个性和生活方式评估来为用户提供自适应和主动体验，包括匹配技术/工具、教育/信息和指导反馈。

图14是可用于实现本文所述的系统、设备、制造产品和方法的示例处理器系统1410的框图。如图14所示，处理器系统1410包括耦合到互连总线1414的处理器1412。例如，处理器1412可以是任何适当的处理器、处理单元或微处理器。虽然图14未示出，但是系统1410可以是多处理器系统，并且因而可包括一个或多个附加处理器，它们与处理器1412相同或相似，并且在通信上耦合到互连总线1414。

图14的处理器1412耦合到芯片组1418，该芯片组1418包括存储控制器1420和输入/输出(I/O)控制器1422。众所周知，芯片组通常提供I/O和存储器管理功能以及由耦合到芯片组1418的一个或多个处理器可访问或使用的多个通用和/或专用寄存器、计时器等。存储控制器1420执行使处理器1412(或者当存在多个处理器时的多个处理器)能够访问系统存储器1424和大容量存储存储器1425的功能。

系统存储器1424可包括任何期望类型的易失性和/或非易失性存储器，例如静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、闪速存储器、只读存储器(ROM)等等。大容量存储存储器1425可包括任何期望类型的大容量存储装置，包括硬盘驱动器、光盘驱动器、磁带存储装置等等。

I/O控制器1422执行使处理器1412能够经由I/O总线1423与外围输入/输出(I/O)装置1426和1428以及网络接口1430进行通信的功能。I/O装置1426和1428可以是任何期望类型的I/O装置，例如键盘、视频显示器或监视器、鼠标等等。网络接口1430可以是例如以太网装置、异步传输模式(ATM)装置、802.11装置、DSL调制解调器、电缆调制解调器、蜂窝调制解调器等，它使处理器系统1410能够与另一个处理器系统进行通信。

虽然存储控制器1420和I/O控制器1422在图14中示为芯片组1418中的独立块，但是，这些块所执行的功能可集成在单个半导体电路中，或者可使用两个或两个以上独立的集成电路来实现。

某些实施例考虑实现上述功能性的方法、系统和任何机器可读介质上的计算机程序产品。例如，某些实施例可使用现有计算机处理器、或者通过为这个或另一个目的而结合的专用计算机处理器、或者通过硬连线和/或固件系统来实现。

上述系统、设备和/或制造产品部件的部分或全部或者其中一部分可使用机器可访问或可读介质上存储并且由例如处理器系统(例如图13的示例处理器P105和/或图14的处理器1412)可执行的指令、代码和/或其它软件和/或固件等等来实现。当记载的所附权利要求的任一项涵盖纯软件和/或固件实现时，至少一个示例中的部件的至少一个在此明确定义成包括存储软件和/或固件的实体介质，例如存储器、DVD、CD等等。

例如，图7和图11包括表示可被运行以实现本文所述的示例系统、设备和制造产品的机器可读和可执行指令或过程的流程图。图7和图11的示例过程可使用处理器、控制器和/或任何其它适当的处理装置来执行。例如，图7和图11的示例过程可通过与处理器(例如图13的处理器P105和/或图14的处理器1412)关联的例如闪速存储器、只读存储器(ROM)和/或随机存取存储器(RAM)等实体介质上存储的代码化指令来实现。备选地，图7和图11的示例过程的部分或全部可使用专用集成电路(ASIC)、可编程逻辑装置(PLD)、现场可编程逻辑装置(FPLD)、分立逻辑、硬件、固件等的任何组合来实现。另外，图7和图11的示例过程的部分或全部可人工或者作为上述技术的任何组合、例如固件、软件、分立逻辑和/或硬件的任何组合来实现。此外，虽然图7和图11的示例过程参照图7和图11的流程图来描述，但是可采用实现图7和图11的过程的其它方法。例如，框的执行顺序可以改变，和/或所述框的一部分可以改变、消除、细分或组合。另外，图7和图11的示例过程的任一个或全部可由例如独立处理线程、处理器、装置、分立逻辑、电路等依次和/或并行执行。

上述系统的部件和/或方法的框中的一个或多个可通过硬件、固件和/或作为软件的指令集单独或结合地实现。某些实施例可作为驻留在例如存储器、硬盘、DVD或CD等计算机可读介质上的指令集来提供，以便在通用计算机或其它处理装置上运行。本发明的某些实施例可省略方法框的一个或多个，和/或以与所列顺序不同的顺序来执行这些框。例如，一些框在本发明的某些实施例中可以不执行。作为又一个实例，某些框可按照与以上所列不同的时间顺序(包括同时在内)来执行。

某些实施例包括用于携带或者其上存储计算机可执行指令或数据结构的计算机可读介质。这种计算机可读介质可以是可由通用或专用计算机或者具有处理器的其它机器可访问的任何可用介质。作为示例，这种计算机可读介质可包括RAM、ROM、PROM、EPROM、EEPROM、闪存、CD-ROM或其它光盘存储装置、磁盘存储装置或者其它磁存储装置、或者可用来携带或存储采取计算机可执行指令或数据结构形式的期望程序代码、可由通用或专用计算机或者具有处理器的其它机器可访问的其它任何介质。以上所述的组合也包含在计算机可读介质的范围之内。计算机可执行指令包括例如使通用计算机、专用计算机或者专用处理机执行某个功能或某组功能的指令和数据。

一般来说，计算机可执行指令包括执行特定任务或者实现特定抽象数据类型的例程、程序、对象、部件、数据结构等。计算机可执行指令、关联数据结构和程序模块表示用于执行本文公开的某些方法的步骤和系统的程序代码的示例。这类可执行指令或关联数据结构的特定序列表示用于实现在这类步骤中所述的功能的相应动作的示例。

本发明的实施例可在采用到具有处理器的一个或多个远程计算机的逻辑连接的组网环境中实施。逻辑连接可包括在此作为实例而不是限制所提供的局域网(LAN)和广域网(WAN)。这类组网环境是办公范围或企业范围的计算机网络、内联网和因特网中常见的，并且可采用大量不同的通信协议。本领域的技术人员会理解，这类网络计算环境通常包含许多类型的计算机系统配置，其中包括个人计算机、手持装置、多处理器系统、基于微处理器或者可编程消费电子产品、网络PC、小型计算机、大型计算机等等。本发明的实施例还可在分布式计算环境中实施，在这些环境中，任务由通过通信网络链接(通过硬连线链路、无线链路或者通过硬连线或无线链路的组合)的本地和远程处理装置来执行。在分布式计算环境中，程序模块可能位于本地以及远程存储器存储装置中。

一种用于实现本发明的实施例的整体系统或部分的示范系统可包括采取计算机形式的通用计算装置(其中包括处理单元)、系统存储器以及将包括系统存储器的各种系统部件耦合到处理单元的系统总线。系统存储器可包括只读存储器(ROM)和随机存取存储器(RAM)。计算机还可包括用于对磁硬盘进行读取和写入的磁硬盘驱动器、对可移动磁盘进行读取或写入的磁盘驱动器以及用于对可移动光盘、如CD ROM或其它光学介质进行读取或写入的光盘驱动器。驱动器及其关联的计算机可读介质提供对计算机可执行指令、数据结构、程序模块和计算机的其它数据的非易失性存储。

虽然已经参照某些实施例描述了本发明，但本领域的技术人员会理解，可进行各种变更，并且等效方案可替代，而没有背离本发明的范围。另外，可进行多种修改来将特定情况或材料修改成适合本发明教导，而没有背离其范围。因此，意图是本发明并不局限于所公开的具体实施例，相反，本发明包括落入所附权利要求书的范围内的所有实施例。

部件列表

Claims (10)

1.一种用于在患者电子医疗数据之中识别患者间关系的计算机实现方法(700，1100)，所述方法包括：

检查电子患者信息中与第一患者相关的一个或多个标识符(710，720，1110)；

使用处理器将与所述第一患者相关的所述一个或多个标识符与来自与第二患者相关的电子患者信息的一个或多个标识符进行匹配(730，750)；

使用处理器、根据所述第一患者与所述第二患者之间的关系来识别所述第二患者与所述第一患者的关连(740，760，770)；

将所述第一患者的电子患者信息链接到有待批准的所述第二患者的电子患者信息(780，785，1120)；以及

在审阅所述第一患者的电子患者信息时提供对所述第二患者的链接的电子患者信息的电子访问(1140)。

2.如权利要求1所述的方法(700，1100)，其中，所述识别步骤还包括将所述第二患者标记为完全匹配(730，740)。

3.如权利要求1所述的方法(700，1100)，其中，所述识别步骤还包括将所述第二患者标记为未决匹配供人工审阅和批准(750，760，770)。

4.如权利要求1所述的方法(700，1100)，其中，所述链接步骤还包括识别和记录所述第一患者与所述第二患者之间的关系的性质(1120)。

5.如权利要求1所述的方法(700，1100)，还包括：根据所述第二患者的所述电子患者信息以及所述第一患者与所述第二患者之间的所述关系来提供对所述第一患者的临床决定支持。

6.如权利要求1所述的方法(700，1100)，其中，所述匹配步骤还包括用于定期扫描患者信息数据存储中与所述第一患者匹配的相关方标识符的自动链接过程(1120)。

7.一种患者间关系识别系统(1200)，所述系统(1200)包括：

处理器(1210)，用于检查来自至少一个电子文档源(1260)的电子患者信息中与第一患者相关的一个或多个标识符，并且将与所述第一患者相关的所述一个或多个标识符与来自与第二患者相关的电子患者信息的一个或多个标识符进行匹配，所述处理器用于根据所述第一患者与所述第二患者之间的关系来识别所述第二患者与所述第一患者的关连；以及

患者登记(1240)，其包括所述第一患者的电子患者信息，并且根据所述第一患者和所述第二患者中的至少一个的批准来提供到所述第二患者的电子患者信息的链接，所述患者登记(124)在用户正审阅所述第一患者的所述电子患者信息时便于对所述第二患者的链接的电子患者信息的访问。

8.如权利要求7所述的系统(1200)，还包括：关系指示器(1230)，用于检查和评估所述第二患者的医疗病史对所述第一患者的病历的重要性。

9.如权利要求7所述的系统(1200)，其中，所述患者登记(1240)用于通过识别和记录所述第一患者与所述第二患者之间的关系的性质，来链接所述第一患者和所述第二患者。

10.如权利要求7所述的系统(1200)，其中，所述处理器(1210)用于根据所述第二患者的所述电子患者信息以及所述第一患者与所述第二患者之间的所述关系来提供对所述第一患者的临床决定支持。

Images