CN101299265A - 用于健康保障数据传送的方法和系统 - Google Patents

Abstract

一种用于在消费者健康保障应用与多个健康保障信息源之间传送健康保障数据的方法。该方法包括：从多个健康保障信息源的第一健康保障信息源请求与消费者相对应的第一部分健康保障数据，从第一健康保障信息源接收第一部分健康保障数据，将第一部分健康保障数据存储在健康保障数据库中，从多个健康保障信息源的第二健康保障信息源请求与消费者相对应的第二部分健康保障数据，从第二健康保障信息源接收第二部分健康保障数据，将第二部分健康保障数据存储在健康保障数据库中，以及从健康保障数据库访问第一部分健康保障数据和第二部分健康保障数据。

Description

用于健康保障数据传送的方法和系统

技术领域

本发明涉及用于在消费者健康保障应用与多个健康保障信息源之间传送健康保障数据的方法。

背景技术

消费者通常管理健康保障的多个方面。由于消费者执行关于健康保障的各种管理任务(例如，决定是否订阅健康计划，监视健康保障计划要求的支付，决定向健康保障储蓄账户供款和/或健康保障储蓄帐户提款，等等)，消费者可以使用来自多个不同源(例如，健康计划提供者、控制健康储蓄帐户的金融机构、健康保障服务提供者等等)的信息。

消费者需要用于健康保障管理的一些信息可以是对于消费者可从这些源电子地获得的。另外，一些源可以向应用提供消费者可以使用来访问和管理从源可用的与健康保障相关的信息的有限能力。例如，健康计划提供者维持订户健康计划数据库，包括从服务提供者接收的健康要求，在订户利益计划(benefit plan)下对这些提供者做出的支付状态，订户保障范围和限制等。多个健康计划提供者还为订户(即，加入提供的健康计划的消费者)提供访问数据的能力。具体地，订户可以经由健康计划提供者网站上提供的应用来查看和可能修改关于订户的健康要求和利益计划的一些订户健康保障数据。例如，使用这样的应用，订户可以查看在健康计划提供的利益计划下的未决要求的状态。类似地，金融机构可以为消费者提供以下能力，即查看健康保障储蓄账户的余额以及从所述账户对健康保障提供者进行电子支付。

消费者可能需要的其他健康保障信息通过纸质报告(例如，账单、实验报告等)或者口头地(例如，来自/去往健康保障提供者的电话呼叫)对于消费者可用，甚至该信息由信息源进行电子式维持。这些信息源中的多个源具有以下能力，即将消费者健康保障信息的相关部分与其他信息源进行电子地交换(例如，医生或牙医可以向健康计划提供者电子地提交针对提供给该消费者的服务的要求，医生可以从实验室电子地接收关于针对该消费者执行的测试的报告，等等)。消费者不能电子地访问或传送这样的信息。

发明内容

总体上，在一个方面，本发明涉及一种用于在消费者健康保障应用与多个健康保障信息源之间传送健康保障数据的方法。该方法包括：从多个健康保障信息源的第一健康保障信息源请求与消费者相对应的第一部分健康保障数据，从第一健康保障信息源接收第一部分健康保障数据，将第一部分健康保障数据存储在健康保障数据库中，从多个健康保障信息源的第二健康保障信息源请求与消费者相对应的第二部分健康保障数据，从第二健康保障信息源接收第二部分健康保障数据，将第二部分健康保障数据存储在健康保障数据库中，以及从健康保障数据库访问第一部分健康保障数据和第二部分健康保障数据。

总体上，在一个方面，本发明涉及一种用于在消费者健康保障应用与健康保障信息源之间传送健康保障数据的方法。该方法包括：发送第一请求消息，该第一请求消息包括针对执行与第一部分健康保障数据相对应的第一动作的第一请求；接收与第一请求消息相对应的第一响应消息，其中第一响应消息包括执行第一动作的结果；以及处理第一响应消息，其中第一请求消息和第一响应消息遵循健康保障数据传送协议。

总体上，在一个方面，本发明涉及一种健康保障数据传送系统，该系统包括：健康保障信息源，被配置为存储与消费者相对应的健康保障数据的一部分；以及健康保障数据访问服务，其操作性地连接到健康保障信息源。该健康保障数据访问服务包括以下功能性：向健康保障信息源发送请求消息，该请求消息包括针对执行与健康保障数据的所述部分相对应的动作的请求；接收与请求消息相对应的响应消息，其中响应消息包括执行该动作的结果；以及处理响应消息，其中请求消息和响应消息遵循健康保障数据传送协议。

总体上，在一个方面，本发明涉及一种健康保障数据传送系统，该系统包括：与第一健康保障业务域相对应的第一健康保障信息源，其中第一健康保障信息源包括与消费者相对应的第一部分健康保障数据；与第二健康保障业务域相对应的第二健康保障信息源，其中第二健康保障信息源包括与消费者相对应的第二部分健康保障数据；以及健康保障数据访问服务，其操作性地连接到第一健康保障信息源和第二健康保障信息源。健康保障数据访问服务包括以下功能性：接收第一部分健康保障数据和第二部分健康保障数据，以及存储第一部分健康保障数据和第二部分健康保障数据。

总体上，在一个方面，本发明涉及一种健康保障数据传送系统，包括：健康保障数据库，其被配置为存储与多个消费者相对应的健康保障数据，其中从多个健康保障信息源接收健康保障数据；以及健康保障数据导入部件，其被配置为使用遵循健康保障数据传送协议的消息从多个健康保障信息源导入健康保障数据。

总体上，在一个方面，本发明涉及一种计算机可读介质，包括在该计算机可读介质上实现的计算机程序代码，用于使得计算机系统在消费者健康保障应用与多个健康保障信息源之间传送健康保障数据。该计算机程序代码包括用于以下的程序指令：从多个健康保障信息源的第一健康保障信息源请求与消费者相对应的第一部分健康保障数据；从第一健康保障信息源接收第一部分健康保障数据；将第一部分健康保障数据存储在健康保障数据库中；从多个健康保障信息源的第二健康保障信息源请求与消费者相对应的第二部分健康保障数据；从第二健康保障信息源接收第二部分健康保障数据；将第二部分健康保障数据存储在健康保障数据库中；以及从健康保障数据库访问第一部分健康保障数据和第二部分健康保障数据。

总体上，在一个方面，本发明涉及一种计算机可读介质，包括在该计算机可读介质上实现的计算机程序代码，用于使得计算机系统在消费者健康保障应用与健康保障信息源之间传送健康保障数据。该计算机程序代码包括用于以下的程序指令：发送第一请求消息，该第一请求消息包括针对执行与第一部分健康保障数据相对应的第一动作的第一请求；接收与第一请求消息相对应的第一响应消息，其中第一响应消息包括执行第一动作的结果；以及处理第一响应消息，其中第一请求消息和第一响应消息遵循健康保障数据传送协议。

根据以下的描述和所附的权利要求，本发明的其他方面和优点将更加明显。

附图说明

图1示出根据本发明的一个或多个实施例的系统的图示。

图2示出根据本发明的一个或多个实施例的健康保障数据传送(HCDT)请求消息和响应消息。

图3-39示出根据本发明的一个或多个实施例的HCDT主题和目录；

图40A-40D示出根据本发明的一个或多个实施例的HCDT请求/响应消息对。

图41A-41B示出根据本发明的一个或多个实施例的用于健康保障数据的传送的调用流程。

图42-44示出根据本发明的一个或多个实施例的流程图。

图45示出根据本发明的一个或多个实施例的计算机系统的图示。

具体实施方式

现在将参考附图详细描述本发明的特定实施例。各个图中的相似元件由相似的参考标记表示，以便保持一致性。

在本发明的实施例的以下详细描述中，描述了大量特定细节，以便提供对本发明的更加透彻的理解。然而，对于本领域的技术人员很明显的是，在没有这些特定细节的情况下，可以实践本发明。在其他情况下，没有详细描述公知的特征，以避免使描述不必要地复杂化。

本发明的实施例总体上提供一种用于在健康保障信息源与消费者之间进行健康保障数据传送的方法和系统。这里所用的消费者包括直接(例如，病人、雇员、测试主体或健康保障服务的其他直接消费者)或间接(例如，健康计划消费者服务代表、医疗专业人员或健康保障服务的其他间接消费者)消费健康保障服务的任何人。

更具体地，在本发明的一个或多个实施例中，可以使用健康保障数据传送(HCDT)协议在健康保障信息源、消费者健康保障应用、和/或中间健康保障数据访问服务之间传送健康保障数据。HCDT协议提供一种用于健康保障信息源怎样将健康保障数据提供给消费者健康保障应用和/或中间健康保障数据访问服务的标准。即，HCDT协议定义用于发送和接收健康保障数据的消息和该消息中使用的数据结构，以表示健康保障信息源的健康保障业务域中的健康保障数据。健康保障业务域可以包括任何方面的消费者健康保障(例如，健康计划业务域、金融业务域、病人记录业务域、药品业务域、实验室业务域、医疗成像业务域、医疗设备业务域、提供者计费业务域、医疗研究/分析业务域、病人教育业务域、牙科业务域、视力护理业务域、备选医疗业务域、体能业务域、物疗业务域、康复业务域、辅助护理业务域、实践管理业务域、心理学业务域、等等)。

图1示出根据本发明的一个或多个实施例的健康保障数据传送系统的图示。在本发明的一个实施例中，健康保障数据传送系统包括一个或多个健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114)、健康保障信息源C(116))、一个或多个HCDT服务器(例如，HCDT服务器A(106)、HCDT服务器B(108))、健康保障数据访问服务(例如，健康保障数据访问服务(104))、以及一个或多个消费者系统(例如，消费者系统A(100)、消费者系统B(102))。尽管为了简化呈现和解释的目的，在图1的系统中仅示出了两个消费者系统、两个HCDT服务器和三个健康保障信息源，但是本领域的技术人员可以理解，可以包括多个消费者系统、HCDT服务器和健康保障信息源。

在本发明的一些实施例中，健康保障数据传送系统的部件经由网络(例如，诸如因特网的广域网(WAN)、无线网络、局域网(LAN)或网络组合)彼此通信。每个健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114)、健康保障信息源C(116))对应于消费者健康保障信息源(例如，诸如Aetna、United Healthcare、Humana等的健康计划提供者、金融机构、诸如医生、牙医、药剂师、医院或实验室的健康保障提供者，等等)，并可以被配置为存储与健康保障信息源的业务域相关的消费者健康保障数据。例如，如果健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114)、健康保障信息源C(116))是健康计划提供者，则消费者健康保障数据可以包括来自利益要求(例如，医疗要求、牙医要求、药品要求、视觉要求等)的健康要求数据，这些数据由成员(即健康计划提供者所提供的健康计划下覆盖的消费者)或代表成员提交给包括在健康计划提供者提供的健康计划中的一个或多个利益计划。

每个健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114)、健康保障信息源C(116))可以被配置为允许健康保障数据访问服务(例如，健康保障数据访问服务(104))利用适当的认证来下载(即，导入)对应于一个或多个消费者的健康保障数据。例如，如果健康保障信息源是健康计划提供者，则健康保障数据服务(例如，健康保障数据访问服务(104))可以下载对应于一个或多个成员的健康计划数据。在本发明的一个或多个实施例中，健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114)、健康保障信息源C(116))被配置为，在允许下载与成员相关联的健康计划数据之前，以本领域公知的方式，按照健康保险携带和责任法案(HIPAA)的私有性和安全性要求，根据健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114)、健康保障信息源C(116))上存储的成员认证信息，认证健康保障数据访问服务(例如，健康保障数据访问服务(104))。

在本发明的一个或多个实施例中，健康保障数据访问服务(例如，健康保障数据访问服务(104))被配置为，使用消费者系统(例如，消费者系统A(100)、消费者系统B(102))向消费者可访问的消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))提供后端服务(例如，信息的存储和取回)。健康保障数据访问服务(例如，健康保障数据访问服务(104))还被配置为，接收与来自消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))的健康保障数据相关的请求，以及产生针对这些请求的响应。健康保障数据访问服务(例如，健康保障数据访问服务(104))包括健康保障数据导入部件(130)、消费者认证部件(128)、管理实用工具(utility)(132)、通知部件(138)和健康保障数据库(126)。

在本发明的一些实施例中，健康计划数据导入部件(128)被配置为从每个消费者注册信息(以下详细解释)中标识的每个健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114)、健康保障信息源C(116))导入与消费者相关联的健康保障数据，以及将导入的健康保障数据存储在健康保障数据库(126)中。在本发明的一个或多个实施例中，健康保障数据库(126)可以例如是数据库、文件系统、配置在健康保障数据访问服务(例如，健康保障数据访问服务(104))的存储器中的一个或多个数据结构、或者其适当组合。在本发明的一个或多个实施例中，健康计划数据导入部件(128)被配置为仅导入新的健康保障数据(即，自最后一次导入健康保障数据起，添加到健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114)、健康保障信息源C(116))中的健康保障数据)。另外，在本发明的一个或多个实施例中，健康计划数据导入部件(130)配置为从健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114)、健康保障信息源C(116))周期性地(例如，每天晚上午夜之后)导入健康保障数据。

在本发明的一个或多个实施例中，消费者认证部件(128)被配置为从消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))接收消费者注册信息。在本发明的一些实施例中，消费者认证部件(128)被配置为接收和存储消费者的注册信息(即，消费者用于访问健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114)、健康保障信息源C(116))的认证信息以及消费者用于访问健康保障数据访问服务(例如，健康保障数据访问服务(104))的认证信息)。例如，消费者的注册信息可以包括登录名、密码、账户号码、以及针对每个具有消费者健康保障数据的健康保障信息源的利益计划标识信息。在本发明的一个或多个实施例中，消费者认证部件(128)被配置为将消费者的认证信息提交给健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114)、健康保障信息源C(116))，以获取对与消费者相关联的健康保障数据的访问。

在本发明的一个或多个实施例中，管理实用工具(132)包括用于健康保障数据访问服务(例如，健康保障数据访问服务(104))的管理的功能性。这样的功能性可以包括例如以下功能性：查看和控制健康保障数据访问服务(例如，健康保障数据访问服务(104))的状态，维持关键错误的日志，维持每个HIPAA需求的访问日志，提供系统使用率度量，以及净化旧数据。

在本发明的一个或多个实施例中，通知部件(138)包括将可能发生的关于消费者健康保障数据的各个事件通知给注册到健康保障数据访问服务(例如，健康保障数据访问服务(104))的消费者的功能性。例如，通知部件可以包括以下功能性，即在消费者初始注册到健康保障数据访问服务(例如，健康保障数据访问服务(104))之后，通知消费者该消费者健康保障数据是可用的。通知部件(138)还可以包括当从一个或多个消费者标识的健康保障信息源接收到用于消费者的新的健康保障数据时通知消费者的功能性。此外，在本发明的一些实施例中，通知部件可以配置为从健康保障信息源接收目标通知以及向一个或多个消费者发送通知。例如，健康保障信息源可能希望将新的服务向多个消费者进行广告，或者通知向多个消费者通知特定事件(例如，公开加入)。在本发明的一个或多个实施例中，通知部件(138)可以通过当消费者登录到消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))时发送电子邮件消息、发送短消息服务(SMS)消息、显示消息、和/或任何其他适当的通知方式，将通知提供给消费者。

在本发明的一个或多个实施例中，健康保障数据访问服务(例如，健康保障数据访问服务(104))可以包括一个或多个服务器(未具体示出)，该服务器被配置为提供健康保障数据访问服务(例如，健康保障数据访问服务(104))的功能性。例如，一个或多个服务器可以被配置为导入和存储来自健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114)、健康保障信息源C(116))的消费者健康保障数据，和/或一个或多个服务器可以被配置为管理健康保障数据访问服务(例如，健康保障数据访问服务(104))中的其他服务器与消费者系统(例如，消费者系统A(100)、消费者系统B(102))之间的网络业务。另外，在本发明的一个或多个实施例中，健康保障数据访问服务(例如，健康保障数据访问服务(104))中的一个或多个服务器可以被配置为对消费者健康保障应用B(124)进行主控。

在本发明的一个或多个实施例中，消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))包括以下功能性，即向消费者显示消费者健康保障数据以及接收来自消费者的关于该健康保障数据的请求。消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))还可以包括以下功能性，即向健康保障数据访问服务(例如，健康保障数据访问服务(104))发送对于消费者健康保障数据的请求以及接收对于这些请求的响应。在本发明的一些实施例中，消费者健康保障应用B(124)可以安装在Web服务器上，并可以由消费者使用Web浏览器B(136)访问。在本发明的一些实施例中，消费者健康保障应用A(122)可以安装在消费者系统A(100)上。此外，在本发明的一些实施例中，消费者健康保障应用A(122)可以从健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114)、健康保障信息源C(116))下载并安装在消费者系统A(100)上。

在本发明的一个或多个实施例中，消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))被配置为使消费者注册到健康保障数据访问服务(例如，健康保障数据访问服务(104))。更具体地，在本发明的一个或多个实施例中，消费者健康保障应用被配置为接收来自消费者的注册信息，该信息包括消费者访问健康保障数据访问服务的认证信息(例如，用户标识和密码)。另外，消费者健康保障应用被配置为接收具有消费者健康保障数据的健康保障信息源的标识，以及针对每个健康保障信息源的消费者认证信息。例如，如果健康保障信息源是健康计划提供者，则消费者注册信息可以包括标识消费者订阅的健康计划的信息、以及针对每个健康计划的消费者认证信息。在本发明的一个或多个实施例中，消费者认证信息可以包括消费者的用户标识和用于登录到健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114)、健康保障信息源C(116))的访问接口(未具体示出)的密码。

消费者系统(例如，消费者系统A(100)、消费者系统B(102))可以是台式计算机、膝上型计算机、诸如蜂窝电话或个人数字助理的移动设备、或适于使用消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))的任何其他计算系统。在本发明的一些实施例中，消费者使用安装在消费者系统(例如，消费者系统A(100)、消费者系统B(102))上的Web浏览器(Web浏览器A(134)、Web浏览器B(136))(例如，

Internet Explorer、Mozilla的Firefox、Opera Software的Opera等)，以访问消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))。

尽管图1中没有具体示出，在本发明的一些实施例中，消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))可以被配置为与一个或多个健康保障信息源(例如，健康保障信息资源A(112)、健康保障信息资源B(114)、健康保障信息源C(116))直接通信以交换健康保障数据，而不是与诸如健康保障数据访问服务(例如，健康保障数据访问服务(104))的中介进行通信来交换健康保障数据，或者在除了与诸如健康保障数据访问服务(例如，健康保障数据访问服务(104))的中介进行通信来交换健康保障数据之外，也与一个或多个健康保障信息源直接通信以交换健康保障数据。更具体地，健康保障数据访问服务(例如，健康保障数据访问服务(104))的部分功能性可以包括在消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))中。例如，消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))可以包括健康保障数据导入部件、消费者认证部件和消费者专用的健康保障数据库(即，其仅存储消费者的健康保障数据)。

在这种实施例中，消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))被配置为从消费者的健康保障信息源直接导入消费者的健康保障数据，并将该导入的健康保障数据存储到消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))中的健康保障数据库中。此外，在本发明的一些实施例中，健康保障数据访问服务(例如，健康保障数据访问服务(104))可以被配置为导入和存储来自对于多个消费者是公共的健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114)、健康保障信息源C(116))的健康保障数据(例如，利益要求代码描述、制药的药物描述等)，以及将该信息提供给消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))，而不是需要每个消费者健康保障应用存储和维持这样的公共健康保障数据。

如以下关于图2和图40A-40D进行的更详细的解释，在本发明的一个或多个实施例中，HCDT协议规定关于健康保障数据的动作(即，针对健康保障数据的请求和针对健康保障数据修改的请求)在对应于动作的请求消息中传送。此外，HCDT协议规定动作的结果在对应于请求消息的响应消息中传送。在本发明的一个或多个实施例中，在健康保障数据访问服务(例如，健康保障数据访问服务(104))与健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114)、健康保障信息源C(116))之间交换HCDT协议消息。另外，在本发明的一些实施例中，在消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))与健康保障数据访问服务(例如，健康保障数据访问服务(104))和/或健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114)、健康保障信息源C(116))之间交换HCDT协议消息。

在本发明的一些实施例中，健康保障信息源(例如，健康保障信息源C(116))可以被配置为使用HCDT协议接收消息和发送消息至健康保障数据访问服务(例如，健康保障数据访问服务(104))和/或消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))。不支持HCDT协议的其他健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114))可以操作性地连接到HCDT服务器(例如，HCDT服务器A(106)、HCDT服务器B(108))，该HCDT服务器用作HCDT接口，用于将HCDT协议消息转换成健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114))所理解的消息格式，反之亦然。

即，在本发明的一个或多个实施例中，HCDT服务器(例如，HCDT服务器A(106)、HCDT服务器B(108))被配置为接收来自健康保障数据传送系统中的另一实体的HCDT请求消息(例如，健康保障数据访问服务(例如，健康保障数据访问服务(104)))，或者消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))，基于该消息确定需要哪个动作，并将该动作转换为按健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114))所理解的格式的、对于相应的健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114))的一个或多个请求。HCDT服务器(例如，HCDT服务器A(106)、HCDT服务器B(108))还被配置为接收来自健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114))的一个或多个请求的结果，将该结果转换为与HCDT请求消息相对应的包括该结果的HCDT响应消息，并将该HCDT响应消息发送回发出请求的实体。

此外，HCDT服务器(例如，HCDT服务器A(106)、HCDT服务器B(108))被配置为接收来自相应的健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114))的请求，将该请求转换为HCDT请求消息，并将该HCDT请求消息发送至健康保障数据传送系统中的另一HCDT有关实体。HCDT服务器(例如，HCDT服务器A(106)、HCDT服务器B(108))还配置为接收对应于请求消息的HCDT响应消息，将该响应消息的内容转换为按健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114))理解的格式的一个或多个消息，并将该一个或多个消息发送至源。

在本发明的一个或多个实施例中，健康护理数据传送系统中被配置为使用HCDT协议交换健康保障数据的那些部件(例如，健康保障数据访问服务(例如，健康保障数据访问服务(104))、HCDT服务器(例如，HCDT服务器A(106)、HCDT服务器B(108))、和健康保障信息源C(116))包括被配置为执行通信的HCDT Web服务(未具体示出)。如以下参考图40A-40D进行的更详细的解释，每个HCDT Web服务被配置为接收HCDT请求消息，使得执行该请求消息中的动作，并将执行该动作的结果以与HCDT请求消息相对应的HCDT响应消息返回给请求者。

此外，每个HCDT Web服务包括可以用于传送到该HCDT Web服务和由该HCDT Web服务传送的HCDT消息中的数据结构的定义。这些数据结构中的多个数据结构专用于由HCDT Web服务表示的健康保障业务域。更具体地，对应于健康保障信息源(例如，健康保障信息源A(112)、健康保障信息源B(114)、健康保障信息源C(116))的HCDT Web服务包括专用于健康保障信息源的健康保障业务域的数据结构定义。例如，如果健康保障信息源是健康计划提供者，则对应的HCDT Web服务包括与健康计划业务域相对应的数据结构定义。并且，如果健康保障信息源是金融机构，则对应的HCDT Web服务包括与金融业务域相对应的数据结构定义。

在本发明的一个或多个实施例中，健康保障数据访问服务(例如，健康保障数据访问服务(104))可以包括一个针对健康保障信息源(例如，健康保障信息资源A(112)、健康保障信息资源B(114)、健康保障信息源C(116))的每个健康保障业务域的HCDT Web服务，用于与这些源交换健康保障数据。此外，在本发明的其中消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))与健康保障信息源(例如，健康保障信息资源A(112)、健康保障信息资源B(114)、健康保障信息源C(116))直接通信的那些实施例中，消费者健康保障应用还可以包括一个针对每个健康保障业务域的HCDT Web服务。例如，如果一个健康保障信息源对应于健康计划业务域，并且另一个健康保障信息源对应于金融业务域，则健康保障数据访问服务(例如，健康保障数据访问服务(104))和/或消费者健康保障应用(例如，消费者健康保障应用A(122)、消费者健康保障应用B(124))包括两个HCDT Web服务器，其中一个专用于健康计划业务域，而另一个专用于金融领域。

图2和图40A-40D示出根据本发明的一个或多个实施例的HCDT协议消息的格式。如先前解释的那样，在HCDT协议中，关于健康保障数据的动作(即，针对健康保障数据的请求和针对健康保障数据修改的请求)在与该动作对应的请求消息中传送。该动作的结果在与该请求消息对应的响应消息中传送。图2示出了HCDT请求消息(200)和对应的HCDT响应消息(202)的格式。

HCDT请求消息(200)包括动作标识符(204)和参数(206)。该动作标识符(204)唯一标识将由HCDT请求消息(200)的接收者执行的动作。参数(206)包括接收者执行所请求的动作需要的任何附加信息。HCDT响应消息(202)包括动作结果(208)。该动作结果(208)包含执行所请求的动作的结果。

在本发明的一个或多个实施例中，动作标识符(204)可以规定以下四个动作之一：获取(即，取得)与健康保障主题或健康保障目录相对应的健康保障数据，或设置(即，修改)与健康保障主题或健康保障目录相对应的健康保障数据。这里用于描述设置的请求的术语修改及其任何变体包括现有健康保障数据的改变和新健康保障数据的增加。以下将更详细地解释健康保障主题和健康保障目录。

将针对其取得数据的健康保障主题或健康保障目录被规定为获取请求消息的参数(206)之一。另外，搜索准则可以被规定为获取请求消息的参数(206)之一。搜索准则可以用于进一步限定将取得的数据。例如，搜索准则可以是一个日期范围，其规定仅应该返回落入该日期范围内的数据。此外，与获取请求消息相对应的响应消息中的动作结果(208)可以是包含所请求的健康保障数据或者所请求的获取动作没有完成的指示(例如异常)的数据结构。该数据结构对应于该获取请求消息中规定的健康保障主题或健康保障目录。

将待修改的健康保障主题或健康保障目录规定为设置请求消息的参数(206)之一。此外，与规定的健康保障主题或健康保障目录相对应的、包含将用于修改该健康保障主题或健康保障目录的数据的数据结构也被包括作为设置请求消息的参数(206)之一。与设置请求消息相对应的响应消息中的动作结果(208)可以是成功完成的所请求的设置动作的指示(例如，确认)，或者没有完成的所请求的设置动作的指示(例如，异常)。

可以使用一个或多个通信协议(例如，超文本传送协议(HTTP)、传输控制协议(TCP)和因特网协议(IP))将HCDT消息通过网络传送到指定的接收者。在本发明的一些实施例中，例如使用扩展标记语言(XML)对HCDT消息编码。然后使用一个或多个通信协议将该编码的HCDT消息发送到指定的接收者。

在发送编码的HCDT消息之前，元数据与编码的HCDT消息相关联。该元数据对应于网络通信协议所需的数据。例如，如果使用HTTP发送该编码的HCDT消息，则后续的元数据块中的一个或多个必须伴随编码的数据：通用头部数据、请求头部数据、响应头部数据和实体头部数据。

当接收到编码的HCDT消息和元数据时，指定的接收者使用元数据处理编码的HCDT消息。处理该编码的HCDT消息通常包括：使用元数据通过接收者中的开放系统互联(OSI)模型的各个层(即，物理层、网络层、传输层等)发送编码的数据，使用元数据对编码的HCDT消息进行解码，以及执行HCDT消息的规定动作来产生结果。

一旦产生了结果，则接收者执行以上描述的关于发起传输的相同步骤，从而将包括结果的响应消息发送到发起者。具体地，接收者对响应消息进行编码，产生需要的元数据，并使用一个或者多个通信协议将该元数据和编码的响应消息发送到发起者。在本发明的一个或多个实施例中，请求/响应消息交换是按照简单对象访问协议(SOAP)的。

在本发明的一个或多个实施例中，在HCDT协议中，健康保障信息源的每个健康保障业务域中的健康保障数据被分类为主题和目录。这些主题和目录定义用于在健康保障数据传输系统内交换健康保障数据的数据结构。主题是相关健康保障数据的可寻址的逻辑分类，并且目录是相关主题的可寻址的逻辑分类，其将主题组织成可管理的群组。用于特定健康保障业务域的主题和目录定义了健康保障数据(即，数据结构)的群组划分，其可以在HCDT消息中被参考，所述HCDT消息针对该健康保障业务域中具有健康保障数据的健康保障信息源或者健康保障数据访问服务。

通常，针对健康保障业务域定义的主题和目录对于在该领域中找到的健康保障数据类型是唯一的。例如，在健康计划业务域中，定义的主题可以包括医疗要求主题、药品要求主题、成员主题、利益计划主题等。以下更详细地解释这些主题。另外，例如，健康计划业务域中的定义的目录可以是包括针对一个用户(例如，使用消费者健康保障应用的消费者)的主题的集合的用户目录。这样的目录可以包括医疗要求主题、药品要求主题、成员主题等，并可以用于HCDT消息，以取回或修改所包括的主题中的、针对一个用户的数据，而不是需要针对每个主题的消息。

此外，在本发明的一个或多个实施例中，HCDT协议包括针对健康保障数据传输系统中找到的每种类型的健康数据业务域的主题和目录的预定义集合。相同健康保障业务域中的每个健康保障信息源需要使用针对该领域的预定义集合中的所有主题和目录进行通信，使得健康保障信息源可以提供主题或目录呈现的数据。然而，如果健康保障信息源没有与主题或主题的元素相对应的数据，则健康保障信息源可以指示如果请求提供对应的数据则主题或元素得不到支持。例如，在健康计划业务域中，健康计划提供者可以提供医疗利益而不是药品利益。因此，健康计划提供者不具有与药品要求和药品要求主题相对应的数据、以及与健康计划提供者不支持的用户目录中的药品要求相对应的元素。

此外，在本发明的一个或多个实施例中，健康保障业务域的一些实例可以具有这些实例专有的健康保障数据。因此，HCDT协议包括针对该健康保障业务域定义附加主题和/或扩展预定义主题及目录的功能性，从而包括该专有健康保障数据。

在本发明的一个或多个实施例中，HCDT协议包括一些主题和目录，这些主题和目录对于所有健康保障业务域都是公共的，并且这些主题和目录包括在针对每种类型的健康保障业务域的主题和目录的每个预定义集合中。更具体地，HCDT协议可以包括关于主题和目录的每个预定义集合中的异常处理的主题和目录，其提供了对与当处理HCDT请求消息时发生的异常相关的信息进行通信的一致方式。

图3-39示出根据本发明的一个或多个实施例的、针对健康计划业务域的在HCDT协议中定义的主题和目录。具体定义针对该领域的主题和目录，用于在健康计划提供者和健康保障数据访问服务中的健康保障数据库之间传输大量数据。更具体地，在本发明的一些实施例中，一些定义的主题可以不单独用于HCDT请求消息中。相反，这些主题用作其他主题和目录的子主题，其被定义为允许取回或修改多个这样的主题。例如，医疗要求主题定义单个医疗要求的内容，而医疗要求主题定义用于取回多个医疗要求的数据结构。该数据结构可以包括医疗要求主题的多个实例。

在图3-39中，以虚线包围的主题或目录的条目是可选的，而以实现包围的是需要的。而且，在以下的这些附图的描述中，除非特别描述，所描述的数据结构中的每个数据值可以在适于表示该值的任何适当表示中。例如，标识符可以是串、整数、名称或任何其他适当值。另外，除非在以下指出，这些包括搜索准则的主题和目录可以单独用于HCDT消息，而那些不包括搜索准则的主题和目录是子主题。

图3示出根据本发明的一个或多个实施例的成员主题(300)。成员主题(300)表示关于健康计划的成员的信息。健康计划的成员是健康计划的订户或者订户的健康计划覆盖的订户的家属。成员主题(300)可以包括成员记录标识符(302)、成员标识(304)、成员订户关系(306)、名称(308)、地址(310)、人口统计信息(312)以及最近更新(314)。

成员记录标识符(302)是唯一标识成员主题(300)表示的成员记录的值。成员标识(304)包括唯一标识健康计划的成员的信息。该信息可以包括成员标识符和数据源系统标识符，其中该成员标识符唯一标识成员，该数据源系统标识符标识产生该成员标识符的、健康计划提供者中的系统。

成员订户关系(306)包括关于成员与订户关系的信息。该信息可以包括指示该关系的代码、以及标识与该成员对应的订户的订户标识信息。该订户指示信息可以包括订户标识符和数据资源系统标识符，其中该订户标识符唯一标识订户，该数据资源系统标识符唯一标识产生该成员标识符的、健康计划提供者中的系统。

名称(308)可以包括成员的姓、名、中间名和姓名后缀。地址(310)可以包括成员的当前邮寄地址、城市、国家、州、邮政编码、国家、省份和/或都市统计区域(MSA)码。人口统计信息(312)可以包括成员的出生日期和指示成员性别的性别码。最近更新(314)是最近更新成员主题(300)中的成员信息的日期。

图4示出根据本发明的一个或多个实施例的成员主题(400)。成员主题(400)表示关于健康计划的多个成员的信息。更具体地，成员主题(400)可以用于对关于订户和订户健康计划所覆盖的订户家属的信息进行通信。成员主题(400)可以包括搜索准则(402)、总结(404)和若干成员主题(406、408、410)。搜索准则(402)包括用于定位包括在成员主题中的成员主题的搜索准则。当在与包括搜索准则的获取请求消息相对应的响应消息中返回成员主题(400)时，包括搜索准则(402)。当成员主题(400)用在设置请求消息中时，不包括搜索准则(402)。当响应于获取请求消息而返回成员主题(400)时，总结(404)包括针对取回的成员主题(406、408、410)的总结统计。该总结统计包括取回的成员主题的总数目，并可以包括获取请求消息的搜索准则中规定的日期范围。当成员主题(400)用于设置请求消息中时，必须包括总结，但是忽略总结的内容。

图5示出根据本发明的一个或多个实施例的健康计划细节主题(500)。健康计划细节主题(500)表示关于健康计划提供者提供的健康计划的信息。健康计划细节主题(500)可以包括健康计划细节记录标识符(502)、标记(branding)(504)、网站信息(506)、标识(508)、HCDT细节(510)以及最近更新(512)。健康计划细节记录标识符(502)是唯一标识健康计划细节主题(500)表示的健康计划细节记录的值。标记(504)包括用于该健康计划的标记信息。标记信息可以包括标签线(tag line)、标识用于用户安全数据字段的标记的信息、以及标志细节。标志细节包括标志的统一资源定位符(URL)地址和标志的图像尺寸。

网站信息(506)包括健康计划主页的URL，健康计划用户偏好网页、健康计划电子邮件偏好网页、要求细节网页、提供者查询网页和用户认证网页。网站信息(506)还包括标识健康计划提供者怎样处理用户支持的信息。用户支持信息可以包括支持网页的URL、电话号码、传真号码、一个或多个电子邮件地址、以及支持组织的工作时间。此外，网站信息(506)包括争议解决的联系信息。该联系信息包括一个或多个电子邮件地址、邮寄地址和争议解决网页的URL。在本发明的一些实施例中，网站信息可以由消费者健康保障应用所使用，以将URL和其他信息提供给消费者。

标识(508)包括支付者标识符、支付者的名称和地址、以及组织标记。支付者标识符唯一标识健康计划的支付者组织。组织标记是健康计划的支付者组织的名称。HCDT细节(510)包括关于健康计划提供者的HCDT安装的细节。这些细节包括健康计划域规范的版本信息和URL。最近更新(512)可以包括最近更新健康计划细节主题(500)中的信息的日期。

图6示出根据发明的一个或多个实施例的健康计划细节主题(600)。健康计划细节主题(600)表示关于健康计划提供者提供的多个健康计划的信息。更具体地，健康计划提供者可以提供多于一个的健康计划(例如，医疗健康计划、药品健康计划、牙科健康计划、视力健康计划等)。健康计划细节主题可以用于对关于多个健康计划的信息进行通信。健康计划细节主题(600)可以包括搜索准则(602)、总结(604)和若干健康计划细节主题(606、608、610)。搜索准则(602)包括用于选择包括在健康计划细节主题(600)中的健康计划细节主题的搜索准则。当在与包括搜索准则的获取请求消息相对应的响应消息中返回健康计划细节主题(600)时，包括搜索准则(602)。当健康计划细节主题(600)用在设置请求消息中时，不包括搜索准则(602)。当响应于获取请求消息而返回健康计划细节主题(600)时，总结(604)包括针对取回的健康计划细节主题(606、608、610)的总结统计。该总结统计包括取回的健康计划细节主题的总数目，并可以包括获取请求消息的搜索准则中规定的日期范围。当健康计划细节主题(600)用在设置请求消息中时，必须包括总结，但是忽略总结的内容。

图7示出根据本发明的一个或多个实施例的利益计划主题(700)。利益计划主题(700)表示关于健康计划提供者提供的利益计划(例如，HMO、PPO等)的信息。利益计划可以是医疗保险计划、牙科保险计划、药品保险计划、视力保险计划等。利益计划主题(700)包括支付者标识(702)、利益计划标识(704)和利益计划细节(706)。支付者标识(702)包括支付者标识符，其针对在利益计划下做出的要求而唯一标识健康计划提供者的支付者组织。利益计划标识(704)包括唯一标识利益计划的详细信息。该信息包括唯一标识利益计划的利益计划标识符和利益计划开始的日期。

利益计划细节(706)包括唯一标识利益计划主题(700)表示的利益计划记录的利益计划记录标识符、利益计划的简称(shortname)、利益计划的文本描述、利益计划结束的日期、关于利益计划的信息变为有效或将变为有效的日期。利益计划细节(706)还可以包括利益计划覆盖的雇主群组的群组名称、利益计划的网站的URL、产生利益计划记录的健康计划提供者中的系统的标识符、以及最近更新利益计划记录的日期。

图8示出根据本发明的一个或多个实施例的利益计划主题(800)。利益计划主题(800)表示关于健康计划提供者的多个有益计划的信息。利益计划主题(800)可以包括搜索准则(802)、总结(804)和若干利益计划主题(806、808、810)。搜索准则(802)包括用于选择包括在利益计划主题(800)中的利益计划主题的搜索准则。当在与包括搜索准则的获取请求消息相对应的响应消息中返回利益计划主题(800)时，包括搜索准则(802)。当利益计划主题(800)用在设置请求消息中时，不包括搜索准则(802)。当响应于获取请求消息而返回利益计划主题(800)时，总结(804)包括针对取回的利益计划主题(806、808、810)的总结统计。该总结统计包括取回的利益计划主题的总数目，并可以包括获取请求消息的搜索准则中规定的日期范围。当利益计划主题(800)用在设置请求消息中时，必须包括总结，但是忽略总结的内容。

图9示出根据本发明的一个或多个实施例的利益限制主题(900)。利益限制主题(900)包括关于对利益计划下覆盖范围的任何限制的信息。更具体地，利益限制主题(900)包含多个利益计划都可能遇到的关于每个病人责任量的数据(例如，家庭可扣除量、个人可扣除量、家庭最大损失(out of pocket)量)。利益限制主题(900)包括支付者标识(902)、利益计划标识(904)、以及利益限制细节(906)。支付者标识(902)包括支付者标识符，其针对在应用了利益限制的利益计划下做出的要求而唯一标识健康计划提供者的支付者组织。利益计划标识(904)包括唯一标识应用了利益限制的利益计划的详细信息。

利益限制细节(906)可以包括利益限制记录标识符和责任标识符，其中该利益限制记录标识符唯一标识利益限制主题(900)表示的利益限制记录，该责任标识符唯一标识与应用了利益限制的利益计划相关联的病人责任属性的集合。利益限制细节(906)还可以包括由利益限制主题(900)表示的病人责任类型(例如，共同支付、共同保险、可扣除、损失等)、病人责任的金额(如果可应用)、以及针对病人责任类型的利益百分比(如果可应用)。此外，利益限制细节(906)可以包括计划网络指示符，其指示病人责任值将在利益计划网络中考虑还是在利益计划网络之外考虑。另外，利益限制细节(906)可以包括与病人责任相关联的文本标记、与病人责任相关联的覆盖范围类型(例如，医疗、药品、视力、牙科等)、利益限制是家庭还是个人限制的指示、以及最近更新利益限制记录的日期。

图10示出根据本发明的一个或多个实施例的利益限制主题(1000)。利益限制主题(1000)表示关于利益计划下的多个利益限制的信息。利益限制主题(1000)可以包括搜索准则(1002)、总结(1004)和若干利益限制主题(1006、1008、1010)。搜索准则(1002)包括用于选择包括在利益限制主题(1000)中的利益限制主题的搜索准则。当在与包括搜索准则的获取请求消息相对应的响应消息中返回利益限制主题(1000)时，包括搜索准则(1002)。当利益限制主题(1000)用在设置请求消息中时，不包括搜索准则(1002)。当响应于获取请求消息而返回利益限制主题(1000)时，总结(1004)包括针对取回的利益限制主题(1006、1008、1010)的总结统计。该总结统计包括取回的利益限制主题的总数目，并可以包括获取请求消息的搜索准则中规定的日期范围。当利益限制主题(1000)用在设置请求消息中时，必须包括总结，但是忽略总结的内容。

图11示出根据本发明的一个或多个实施例的覆盖范围主题(1100)。覆盖范围主题(1100)表示关于利益计划下的成员的覆盖范围的信息。覆盖范围主题(1100)包括成员标识(1102)、支付者标识(1104)、利益计划标识(1106)、和覆盖范围细节(1108)。成员标识(1102)包括支付者标识符，其针对在利益计划下做出的要求而唯一标识健康计划提供者的支付者组织。利益计划标识(1106)包括唯一标识提供覆盖范围的利益计划的详细信息。该信息包括利益计划标识符，其唯一标识利益计划和该利益计划开始的日期。

覆盖范围细节(1108)包括成员的覆盖范围的细节。覆盖范围细节(1108)可以包括覆盖范围记录标识符，其唯一标识由覆盖范围主题(1100)表示的覆盖范围记录、以及针对利益计划下的成员利益覆盖范围的有效开始和结束日期。覆盖范围细节(1108)还可以包括医疗覆盖范围指示符、药品覆盖范围指示符、牙科覆盖范围指示符和视力覆盖范围指示符。这些指示符中每一个指示符的值标识利益计划是否包括该覆盖范围。另外，覆盖范围细节(1108)可以包括针对成员或相关联的订户的雇主的标识号(即，群组号)、群组名称、联系信息和最近更新覆盖范围记录的日期。

图12示出根据本发明的一个或多个实施例的覆盖范围主题(1200)。覆盖范围主题(1200)表示关于订户的多个覆盖范围的信息。更具体地，覆盖范围主题(1200)可以用于对订户和利益计划所覆盖的订户家属的覆盖范围信息进行通信。覆盖范围主题(1200)可以包括搜索准则(1202)、总结(1204)和若干覆盖范围主题(1206、1208、1210)。搜索准则(1202)包括用于选择包括在覆盖范围主题(1200)中的覆盖范围主题的搜索准则。当在与包括搜索准则的获取请求消息相对应的响应消息中返回覆盖范围主题(1200)时，包括搜索准则(1202)。当覆盖范围主题(1200)用在设置请求消息中时，不包括搜索准则(1202)。当响应于获取请求消息而返回覆盖范围主题(1200)时，总结(1204)包括针对取回的覆盖范围主题(1206、1208、1210)的总结统计。该总结统计包括取回的覆盖范围主题的总数目，并可以包括获取请求消息的搜索准则中规定的日期范围。当覆盖范围主题(1200)用在设置请求消息中时，必须包括总结，但是忽略总结的内容。

图13示出根据本发明的一个或多个实施例的累积器(accumulator)主题(1300)。累积器主题(1300)表示关于由利益计划所覆盖的成员的累积器的信息。累积器是针对病人责任或家庭责任的累积金额。累积器主题(1300)包括成员标识(1302)、支付者标识(1304)、利益计划标识(1306)和累积器细节(1308)。成员标识(1302)包括唯一标识成员的标识符。支付者标识(1304)包括支付者标识符，其针对在利益计划下做出的要求而唯一标识健康计划的提供者的支付者组织。利益计划标识(1306)包括唯一标识成员的利益计划的细节信息。该信息包括利益计划标识符，其唯一标识利益计划和该利益计划开始的日期。

病人责任细节(1308)可以包括病人责任记录标识符和责任标识符，其中该病人责任记录标识符唯一标识由累积器主题(1300)表示的病人责任记录，该责任标识符唯一标识与利益计划相关联的病人责任属性的集合。病人责任细节(1308)还可以包括由累积器主题(1300)表示的病人责任类型(例如，共同支付、共同保险、可扣除、损失等)、与病人责任类型相关联的文字标记、以及与病人责任相关联的覆盖范围类型(例如，医疗、药品、视力、牙科等)。另外，病人责任细节(1308)可以包括针对病人责任的当前累积金额、以及计算当前费用量的日期范围。此外，病人责任细节(1308)可以包括计划网络指示符，其指示病人责任值在利益计划网络之内考虑还是在利益计划网络之外考虑、以及最近更新病人责任记录最近更新的日期。

图14示出根据本发明的一个或多个实施例的累积器主题(1400)。累积器主题(1400)表示关于订户的多个累积器的信息。更具体地，累积器主题(1400)可以用于对订户和利益计划所覆盖的订户家属的累积器进行通信。累积器主题(1400)可以包括搜索准则(1402)、总结(1404)和若干累积器主题(1406、1408、1410)。搜索准则(1402)包括用于选择包括在累积器主题(1400)中的累积器主题的搜索准则。当在与包括搜索准则的获取请求消息相对应的响应消息中返回累积器主题(1400)时，包括搜索准则(1402)。当累积器主题(1400)用在设置请求消息中时，不包括搜索准则(1402)。当响应于获取请求消息而返回累积器主题(1400)时，总结(1404)包括针对取回的累积器主题(1406、1408、1410)的总结统计。该总结统计包括取回的累积器主题的总数目，并可以包括获取请求消息的搜索准则中规定的日期范围。当累积器主题(1400)用在设置请求消息中时，必须包括总结，但是忽略总结的内容。

图15示出根据本发明的一个或多个实施例的基本保障提供者主题(1500)。基本保障提供者主题(1500)表示关于成员已经选择其作为基本保障提供者的医生的信息。基本保障提供者主题(1500)包括基本保障提供者记录标识符(1502)、成员标识(1504)、提供者标识(1506)、提供者分类(1508)、有效开始日期(1510)、有效结束日期(1512)、名称(1514)和最近更新(1516)。基本保障提供者记录标识符(1502)唯一标识由基本保障提供者主题(1500)表示的基本保障提供者记录。成员标识(1504)包括唯一标识成员的标识符。

提供者标识(1506)包括唯一标识基本保障提供者的信息。该信息可以包括提供者标识符和数据源系统标识符，其中该提供者标识符唯一标识基本保障提供者，该数据源系统标识符标识产生基本保障提供者标识符的、健康保障提供者中的系统。提供者分类(1508)包括关于基本保障提供者的特长的信息。该信息可以包括针对每个基本保障提供者的特长的分类代码。

有效开始日期(1510)规定基本保障提供者与成员相关联的日期。有效结束日期(1512)规定基本保障提供者不再与该成员相关联的日期。名称(1514)可以包括基本保障提供者的姓、名、中间名和姓名后缀。最近更新(1516)是最近更新基本保障提供者主题(1500)中的基本保障提供者信息的日期。

图16示出根据本发明的一个或多个实施例的基本保障提供者主题(1600)。基本保障提供者主题(1600)表示关于订户和所覆盖的订户家属的基本保障提供者的信息。基本保障提供者主题(1600)可以包括搜索准则(1602)、总结(1604)和若干基本保障提供者主题(1606、1608、1610)。搜索准则(1602)包括用于选择包括在基本保障提供者主题(1600)中的基本保障提供者主题的搜索准则。当在与包括搜索准则的获取请求消息相对应的响应消息中返回基本保障提供者主题(1600)时，包括搜索准则(1602)。当基本保障提供者主题(1600)用在设置请求消息中时，不包括搜索准则(1602)。当响应于获取请求消息而返回基本保障提供者主题(1600)时，总结(1604)包括针对取回的基本保障提供者主题(1606、1608、1610)的总结统计。该总结统计包括取回的基本保障提供者主题的总数目，并可以包括获取请求消息的搜索准则中规定的日期范围。当基本保障提供者主题(1600)用在设置请求消息中时，必须包括总结，但是忽略总结的内容。

图17示出根据本发明的一个或多个实施例的提供者主题(1700)。提供者主题(1700)表示关于可以向利益计划成员提供服务的服务提供者的信息。提供者主题(1700)可以包括提供者记录标识符(1702)、提供者标识(1704)、提供者群组细节(1706)、提供者分类(1708)、名称(1710)、地址(1712)、电话(1714)、电子邮件(1716)、Web链接(1718)和最近更新(1720)。提供者记录标识符(1702)是唯一标识由提供者主题(1700)表示的提供者记录的值。

提供者标识(1704)包括唯一标识提供者的信息。该信息可以包括提供者标识符和数据源系统标识符，其中该提供者标识符唯一标识提供者，该数据源系统标识符标识产生提供者标识符的、健康保障提供者中的系统。提供者群组细节(1706)可以包括唯一标识提供者加入的群组实践或医疗中心(clinic)的标识符和群组实践或医疗中心的名称。提供者群组细节(1706)还可以包括关于提供者是否参与健康计划提供者的提供者网络的信息。提供者分类(1708)包括关于提供者特长的信息。该信息可以包括针对提供者的每个特长的分类代码。

名称(1710)可以包括提供者的姓、名、中间名和姓名后缀。地址(1712)可以包括提供者的当前邮寄地址、城市、国家、州、邮政编码、国家、省份和/或都市统计区域(MSA)码。电话(1714)可以包括提供者的电话号码。电子邮件(1716)可以包括提供者的电子邮件。Web链接1718)可以包括提供者的网站的URL。最近更新(1720)可以包括最近更新提供者主题(1700)中的信息的日期。

图18示出本发明的一个或多个实施例的提供者主题(1800)。提供者主题(1800)表示关于健康计划提供者已知的多个服务提供者的信息。提供者主题(1800)可以包括搜索准则(1802)、总结(1804)和若干基本保障提供者主题(1806、1808、1810)。搜索准则(1802)包括用于选择包括在提供者主题(1800)中的提供者主题的搜索准则。当在与包括搜索准则的获取请求消息相对应的响应消息中返回提供者主题(1800)时，包括搜索准则(1802)。当提供者主题(1800)用在设置请求消息中时，不包括搜索准则(1802)。当响应于获取请求消息而返回提供者主题(1800)时，总结(1804)包括针对取回的提供者主题(1806、1808、1810)的总结统计。该总结统计包括取回的提供者主题的总数目，并可以包括获取请求消息的搜索准则中规定的日期范围。当提供者主题(1800)用于设置请求消息中时，必须包括总结，但是忽略总结的内容。

图19示出根据本发明的一个或多个实施例的医疗要求主题(1900)。医疗要求主题(1900)表示关于成员的单个医疗要求的信息。医疗要求主题(1900)包括医疗要求记录标识符(1902)、成员标识(1904)、利益计划标识(1906)、支付者标识(1908)、要求支付者参考(1910)、要求状态(1912)和要求处理日期(1914)。医疗要求主题(1900)还可以包括准入退出(admission discharge)细节(1916)、服务地点(1918)和要求代码(1920)。此外，医疗要求主题(1900)可以包括要求提供者参考(1922)、诊断(1924)、要求程序(1926)、要求提供者收费(1928)、要求计划支付(1930)、要求利益协调(COB)支付(1932)、要求成员余额(balance)(1934)、要求提供者(1936)、以及一个或多个医疗服务主题(1938、1940、1942)。

医疗要求记录标识符(1902)唯一标识由医疗要求主题(1900)表示的医疗要求记录。成员标识(1904)包括唯一标识成员的标识符。利益计划标识(1906)包括唯一标识与医疗要求相关联的利益计划的详细信息。该信息包括唯一标识利益计划的利益计划标识符和利益计划开始的日期。支付者标识(1908)包括支付者标识符，其唯一标识负责对医疗要求支付的健康计划提供者的支付者组织。

要求支付者参考(1910)包括关于旨在用于该要求的支付者内部使用的医疗要求的参考信息。该信息可以包括唯一标识在遭遇(encounter)下的服务的支付者要求控制号码、或要求审核号码或者病人控制号码。要求状态(1912)包括关于医疗要求的状态的信息。该信息可以包括标识同意或拒绝医疗要求状态的要求状态代码。要求处理日期(1914)包括关于医疗要求处理的各个日期的信息。该信息可以包括最近更新健康保障数据库中的医疗要求记录的日期、医疗要求上所包括的时段的开始和结束日期、以及支付者接收医疗要求的日期。

准入退出细节(1916)包括关于包括在医疗要求中的服务的准入和退出信息。该信息可以包括指示准入的优先权的代码、指示准入的源的代码、准入日期和时间、以及退出日期和时间。服务地点(1918)包括关于针对成员执行医疗要求中包括的医疗服务的地点的信息。该信息可以包括标识服务在何处执行的代码、以及标识服务在该处执行的设施类型的代码。该设施代码可以是以电子医疗要求国家标准格式的服务代码位置或者机构服务统账单类型代码的第一和第二位。

要求代码(1920)包括描述要求的附加代码。这些代码可以包括规定要求的频率的频率代码；指示在准入时的成员状态、门诊病人服务、或护理开始的病人状态代码；以及诊断相关的群组代码，该诊断相关的群组代码表示病人分类方案中的成员分类，该分类方案基于病情、疾病和医疗问题将病人聚类到各个种类。频率代码可以是统一记账要求表格账单类型(Uniform Billing Claim Form BillType)的第三位。

要求提供者参考(1922)包括关于由提交要求的服务提供者内部使用的医疗要求的参考信息。该信息可以包括指示针对医疗要求提供的服务由被支付者(payee)授权的号码、代码或值，以及由提供者唯一分配给成员的用于取回成员的医疗记录的医疗记录号码。

诊断(1924)包括关于与在医疗要求中所要求的服务相关联的诊断的信息。该信息包括主要诊断代码，其标识主要负责所要求的医疗服务的医疗条件，并且还可以包括一个或多个附加诊断代码，其标识在提供医疗服务时共存的其他条件。

要求程序(1926)包括关于作为包括在医疗要求中的服务的部分执行的医疗程序的信息。该信息可以包括主要ICD9程序代码，其标识针对确定性治疗而不是针对诊断或试探性目的而执行的程序，或者对于照顾并发症(complication)所必需的程序。该主要程序还是最相关于主要诊断的程序。该信息还可以包括一个或多个附加的ICD9程序代码，该代码标识包括在医疗要求中的其他程序。ICD-9是用于医疗领域的首字母缩略词，其代表第九版的国际疾病分类。ICD9代码是表示任何已知疾病或医疗条件的字母数字编排的代码。

要求提供者收费(1928)包括关于由与医疗要求相关联的服务提供者的收费量的信息。该信息可以包括要求收费量，其是医疗要求中包括的所有收费总和。要求计划支付(1930)包括根据成员利益计划对医疗要求的支付的信息。该信息包括支付者对于医疗要求的支付量，并可以包括指示是否对该成员或对服务提供者进行支付的支付指示符。

要求COB支付(1932)包括关于成员的其他支付者(即，该成员是另一健康计划提供者的成员)对医疗要求进行支付的信息。该信息可以包括要求COB指示符、以及其他支付者对医疗要求的支付量，其中该要求COB指示符指示是否对医疗要求的任何支付涉及利益协调。要求成员余额(1934)包括关于成员对医疗要求的支付量或可支付量的信息。该信息还可以包括病人责任量，该病人责任量是成员负责支付的要求收费量。

要求提供者(1936)包括关于由要求所覆盖的医疗服务中所涉及的任何服务提供者的信息。该信息可以包括针对将成员与提供医疗服务的提供者相关的提供者、记账提供者和提供医疗服务的提供者的提供者信息。该提供者信息可以包括提供者标识符和数据源系统标识符，其中提供者标识符唯一标识提供者，数据原系统标识符标识产生提供者标识符的、健康计划提供者中的系统。提供者分类包括关于提供者特长的信息。该信息可以包括针对提供者每个特张的分类代码。针对提供服务(rendering)的提供者，提供者信息还可以包括关于提供服务的提供者是否参与健康计划提供者的提供者网络的信息。

每个医疗服务主题(1938、1940、1942)表示关于包括在医疗要求中的医疗服务的信息。以下关于图21更加详细地解释医疗服务主题。

图20示出本发明的一个或多个实施例的医疗要求主题(2000)。医疗要求主题(2000)表示关于多个医疗要求的信息。医疗要求主题(2000)可以包括搜索准则(2002)、总结(2004)和若干基本保障医疗要求主题(2006、2008、2010)。搜索准则(2002)包括用于选择包括在医疗要求主题(2000)中的医疗要求主题的搜索准则。当在与包括搜索准则的获取请求消息相对应的响应消息中返回医疗要求主题(2000)时，包括搜索准则(2002)。当医疗要求主题(2000)用在设置请求消息中时，不包括搜索准则(2002)。当响应于获取请求消息而返回医疗要求主题(2000)时，总结(2004)包括针对取回的医疗要求主题(2006、2008、2010)的总结统计。该总结统计包括取回的医疗要求主题的总数目，并可以包括获取请求消息的搜索准则中规定的日期范围。当医疗要求主题(2000)用在设置请求消息中时，必须包括总结，但是忽略总结的内容。

图21示出根据本发明的一个或多个实施例的医疗服务主题(2100)。医疗服务主题(2100)包括关于包括在医疗要求中的医疗服务的信息。医疗服务主题(2100)可以包括医疗服务记录标识符(2102)、服务参考(2104)、服务日期(2106)、服务诊断(2108)、服务的服务地点(2110)、以及服务程序(2112)。医疗服务主题(2100)还可以包括服务调整原因(2114)、服务评论代码(2116)、服务提供者收费(2118)、服务计划支付(2120)、以及服务COB支付(2122)。另外，医疗服务主题(2100)可以包括服务成员余额(2124)、服务未覆盖的支付(2126)、服务提供者(2128)和最近更新(2130)。

医疗服务记录标识符(2102)唯一标识由医疗要求主题(1900)表示的医疗服务记录。服务参考(2104)包括关于旨在用于由包括医疗服务的医疗要求的支付者内部使用的医疗服务的参考信息。该信息可以包括支付者要求控制服务线路号码和隐私限制指示符，其中该支付者要求控制服务线路号码唯一标识要求内的服务，该隐私限制指示符指示有关该服务的细节是否由于隐私限制而被忽略。

服务日期(2106)包括关于与医疗服务相关的各个日期的信息。该信息包括医疗服务的开始和结束日期、以及该服务的支付日期、或支付者拒绝针对医疗服务的支付的日期。服务诊断(2108)包括关于与医疗服务相关联的诊断的信息。该信息包括主要诊断代码，其标识主要负责医疗服务的医疗条件，并且还可以包括一个或多个附加诊断代码，其标识在提供医疗服务时共存的其他条件。

服务的服务地点(2110)包括关于医疗服务执行的地点的信息。该信息可以包括标识服务在何处执行的代码。服务程序(2112)包括关于执行的医疗服务的信息。该信息可以包括服务线路收入代码，其表示如国家统一记账委员会定义的那样指示医院收费的分类。该信息还可以包括程序类型代码、程序代码和一个或多个程序修改器，其中该程序类型代码标识对医疗服务进行标识的程序代码的类型和源，该过程修改器标识与医疗服务性能相关的特定情境。另外，该信息可以包括表示定价或重新定价实体所允许的服务单元数目的服务单元计数。

服务调整原因(2114)包括关于为什么对医疗服务进行调整的信息。该信息可以包括一个或多个线路条目病人责任原因代码和/或一个或多个未覆盖的原因代码。线路条目病人责任原代码是指示病人为何负责对医疗服务支付的代码。未覆盖的原因代码指示一定量的医疗服务被拒绝或没有被覆盖的原因。

服务评论代码(2116)包括与非金融信息相关的代码，所述非金融信息涉及包括医疗服务的要求的判决。这些代码可以包括一个或多个评论代码和/或一个或多个自定义信息代码，其中该评论代码表示非金融信息，该自定义信息代码专用于处理包括医疗服务的要求的健康计划提供者。

服务提供者收费(2118)包括服务提供者针对医疗服务的收费量。服务计划支付(2120)包括关于根据医疗服务的利益计划做出的支付的信息。该信息可以包括对医疗服务的提供者的实际支付量、以及由于与服务提供者的合同安排而在医疗服务上节省的量。服务COB支付(2122)包括在利益协调下为医疗服务支付的量。

服务成员余额(2124)包括关于成员针对医疗服务可支付量或已支付量的信息。该信息可以包括线路项目可扣除量和线路条目共同保险量，其中该线路项目可扣除量是应用于对医疗服务收费的成员的可扣除量，该线路条目共同保险量是成员对医疗服务的共同保险的支付量。该信息还可以包括线路条目共同支付量和线路条目病人责任量，其中该线路条目共同支付量是成员对医疗服务的共同支付量，该线路条目病人责任量是对确定为成员支付责任的医疗服务的收费量。

服务未覆盖支付(2126)包括关于被拒绝或未覆盖的医疗服务的收费量。服务提供者(2128)包括关于提供医疗服务的提供者的信息。该信息可以包括提供者标识符和数据源系统标识符，其中该提供者标识符唯一标识服务提供者，该数据源系统标识符标识产生服务提供者标识符的、健康计划提供者内的系统。提供者分类包括关于提供者特长的信息。该信息可以包括针对服务提供者的每个特长的分类代码。最近更新(2130)是最近更新健康保障数据库中的医疗服务信息的日期和时间。

图22示出根据本发明的一个或多个实施例的药品要求主题(2200)。药品要求主题(2200)表示关于成员的单个药品要求。药品要求主题(2200)可以包括药品要求记录标识符(2202)、成员标识(2204)、利益计划标识(2206)、支付者标识(2208)、要求支付者参考(2210)、以及要求提供者参考(2212)。药品要求主题(2200)还可以包括要求状态(2214)、要求提供者收费(2216)、要求支付计划(2218)、要求COB支付(2220)、要求成员余额(2222)、要求未覆盖支付(2224)、处方(2226)、以及服务提供者(2228)。

药品要求记录标识符(2202)唯一标识由药品要求主题(2200)表示的药品要求记录。成员标识(2204)包括唯一标识成员的标识符。利益计划标识(2206)包括唯一标识与药品要求相关联的利益计划的详细信息。该信息包括唯一标识利益计划的利益计划标识符和利益计划开始的日期。支付者标识(2208)包括支付者标识符，其唯一标识负责对药品要求支付的健康计划提供者的支付者组织。

要求支付者参考(2210)包括关于旨在由要求的支付者内部使用的药品要求的参考信息。该信息可以包括唯一标识在遭遇下的药品服务的支付者要求控制号码、或要求审核号码或者病人控制号码。要求提供者参考(2212)包括关于由提交要求的服务提供者内部使用的药品要求的参考信息。该信息可以包括指示针对药品要求提供的、由被支付者授权的服务的号码、代码或值，以及由提供者唯一分配给成员的、用于取回成员的药品记录的药品记录号码。

要求状态(2214)包括与非金融信息相关的代码，非金融信息涉及药品要求的判决。这些代码可以包括一个或多个评论代码和/或一个或多个自定义信息代码，其中该评论代码表示非金融信息，该自定义信息代码专用于处理药品要求的健康计划提供者。要求提供者收费(2216)包括关于与药品要求相关联的服务提供者收费量的信息。该信息可以包括要求收费量，该要求收费量是包括在药品要求中的所有收费之和。

要求支付计划(2218)包括关于根据成员的利益计划对药品要求进行的支付的信息。该信息包括由支付者对药品要求的支付量，并可以包括指示是否对该成员或对服务提供者进行支付的支付指示符。要求COB支付(2220)包括关于成员的其他支付者(即，该成员是另一健康计划提供者的成员)对药品要求进行支付的信息。该信息可以包括要求COB指示符，其中该要求COB指示符指示对药品要求的任何支付是否涉及利益协调和其他支付者对医疗要求的支付量。

要求成员余额(2222)包括关于成员对药品要求的已支付量或可支付量的信息。该信息可以包括病人责任量，该病人责任量是成员负责支付的要求收费量。要求未覆盖支付(2224)包括与被拒绝或未覆盖的药品要求相关的收费量。

处方(2226)包括关于包括在药品要求中的成员处方的信息。该信息可以包括针对填入处方的药品的国家药物处方委员会(NCPDP)提供者标识号码、分发药品的名称、以及处方药物的11位数字国家药物代码(NDC)。该信息还可以包括：DAW(按处方配药)代码，其指示是否依照处方者关于通用替换物的指令、估计的处方将持续的天数、分发的数量；以及指示该处方是原始或重填写的代码。此外，该信息还可以包括处方的填写日期、写该处方的日期、以及最近更新健康保障数据库中处方要求信息的日期和时间。

服务提供者(2228)包括关于填写处方的提供者的信息。该信息可以包括提供者标识符和数据源系统标识符，其中该提供者标识符唯一标识服务提供者，该数据源系统标识符标识产生服务提供者标识符的、健康计划提供者中的系统。提供者分类包括关于提供者特长的信息。该信息可以包括针对服务提供者的每个特长的分类代码。

图23示出根据本发明的一个或多个实施例的药品要求主题(2300)。药品要求主题(2300)表示关于多个药品要求的信息。药品要求主题(2300)可以包括搜索准则(2302)、总结(2304)和若干基本保障药品要求主题(2306、2308、2310)。搜索准则(2302)包括用于选择包括在药品要求主题(2300)中的药品要求主题的搜索准则。当在与包括搜索准则的获取请求消息相对应的响应消息中返回药品要求主题(2300)时，包括搜索准则(2302)。当药品要求主题(2300)用在设置请求消息中时，不包括搜索准则(2302)。当响应于获取请求消息而返回药品要求主题(2300)时，总结(2304)包括针对取回的药品要求主题(2306、2308、2310)的总结统计。该总结统计包括取回的药品要求主题的总数目，并可以包括获取请求消息的搜索准则中规定的日期范围。当药品要求主题(2300)用在设置请求消息中时，必须包括总结，但是忽略总结的内容。

图24示出根据本发明的一个或多个实施例的用户分批主题(2400)。用户分批主题(2400)表示针对单个用户(即，注册到健康保障数据访问服务的消费者)选择的主题。用户分批主题旨在用于来自健康计划提供者的健康保障数据库的分批更新。用户分批主题可以包括异常主题(2402)、成员主题(2404)、覆盖范围主题(2406)、累积器主题(2408)、医疗要求主题(2410)、药品要求主题(2412)、以及基本保障提供者主题(2414)。如果在获取请求或设置请求期间在访问用户分批主题(2400)中的任何信息中发生异常，则可以出现异常主题(2402)。以下参考图34详细描述异常主题(2402)。以上更详细地描述了其他主题(2404-2414)的格式。这些主题(2404-2414)中的每个主题可以包括如上所述的用于用户和用于是一个或多个用户健康保障计划成员的每个用户家属的信息。例如，医疗要求主题(2410)可以包括用于用户和用户家属的医疗要求。

图25示出了根据本发明的一个或多个实施例的用户分批主题(2500)。用户分批主题(2500)包括关于健康保障数据访问服务的多个用户的信息。更具体地，用户分批主题(2500)包括一个或多个用户分批主题(2502-2506)。每个用户分批主题(2502-2506)表示如上所述的关于单个用户的信息。用户分批主题(2500)用于将用户数据从健康计划提供者大量传输到健康保障数据库。

图26示出了根据本发明的一个或多个实施例的代码描述主题(2600)。代码描述主题(2600)表示关于可以由健康计划提供者使用的非标准代码的信息。例如，健康计划提供者可以具有包括在要求中的用于评论的代码、或者用于表示不同于其他健康计划提供者的性别的代码。健康保障数据访问服务可以将针对该主题的获取请求发送到健康计划提供者，以请求健康计划提供者使用的任何非标准代码的描述。用在获取请求中的该搜索准则可以用于请求针对特定代码或针对所有代码的描述。这些搜索准则可以包括支付者标识，其唯一标识健康计划提供者的支付者组织、代码集合和一个或多个代码。

代码描述主题包括搜索准则(2602)和一个或多个代码描述(2604、2606、2608)。搜索准则(2602)包括用于定位代码描述(2604、2606、2608)的搜索准则。代码描述(2604、2606、2608)可以包括用于代码和代码描述的标识符。

图27示出根据本发明的一个或多个实施例的应用订阅主题(2700)。应用订阅主题(2700)表示使用应用访问来自健康计划提供者的数据的用户的订阅状态。在本发明的一个或多个实施例中，应用可以是被配置为使用HCDT协议访问健康保障数据的任何应用。在本发明的一些实施例中，应用可以是健康保障数据访问服务。应用订阅主题(2700)包括用户证书(2702)、应用(2704)和订阅(2706)。用户证书(2702)包括认证健康计划提供者的用户所需的元素。这些元素可以包括用户标识和用户的密码。用户标识可以是用户名称、签约(sign-on)名称、经由健康计划的授权过程选择或分配的标识符、或者任何其他适当类型的标识。应用(2704)是唯一标识应用的值。订阅(2706)是指示用户是否订阅以通过应用从健康计划提供者接收用户的健康保障数据。

图28示出根据本发明的一个或多个实施例的用户认证主题(2800)。用户认证主题(2800)表示认证健康计划的用户所需的信息。用户认证主题(2800)包括用户证书(2802)。用户证书(2802)包括利用用户的健康计划认证用户所需的元素。这些元素可以包括用户标识和用户的密码。用户标识可以是用户名称、签约名称、经由健康计划的授权处理选择或分配的标识符、或者任何其他适当类型的标识。

图29示出根据本发明的一个或多个实施例的版本信息主题(2900)。版本信息主题(2900)表示关于由健康计划提供者支持的HCDT协议的版本的信息。版本信息主题(2900)包括版本信息(2902)。版本信息(2902)可以包括版本标识符、修订等级、最近修改版本的日期、以及版本的状态(即，未决、接受、拒绝、延期、或反对)。在本发明的一个或多个实施例中，该主题可以用于确定由健康计划提供者的HCDT服务器支持的HCDT协议的版本与由健康保障数据访问服务支持的版本相兼容。

图30示出本发明的一个或多个实施例的带有更新的用户主题(3000)。带有更新的用户主题(3000)表示具有包括在用户目录中的更新主题的用户的用户标识符列表。以下参考图32解释用户目录。当执行从健康计划提供者到健康保障数据访问服务的健康保障数据库的更新时，使用带有更新的用户主题(3000)。在本发明的一个或多个实施例中，当更新处理由健康保障数据访问服务发起时，带有更新的用户主题(3000)作为针对该主题的获取请求的结果而被返回。此外，当由健康计划提供者发起更新处理时，带有更新的用户主题(3000)在设置请求中被发送到健康保障数据访问服务。在本发明的一些实施例中，带有更新的用户主题(3000)可以响应于针对主题的获取请求而返回，或根据设置请求而发送。更具体地，如果将被返回的用户标识符的数目超过某预定数目(例如100)，则向健康保障数据访问服务发送多个消息，每个消息包括带有更新的用户主题(3000)，其包含达到预定数目的用户标识符。所需要的响应消息的数目依赖于用户标识符的数目。

带有更新的用户主题(3000)包括一个或多个用户标识(3002、3004、3006)。用户标识(3002、3004、3006)可以是用户名称、签约名称、经由健康计划提供者的授权处理选择或分配的标识符、或者唯一标识用户的任何其他适当类型的标识。

图31示出本发明的一个或多个实施例的用户目录请求分批主题(3100)。用户目录请求分批主题(3100)针对具有与用户目录相关联的主题更新的用户标识符列表表示用户证书和查询日期范围。以下参考图32解释用户目录。在本发明的一个或多个实施例中，当执行从健康计划提供者到健康保障数据访问服务的健康保障数据库的更新时，使用用户目录请求分批主题(3100)。更具体地，在健康保障数据访问服务从健康计划提供者接收带有更新的用户主题(以上参考图30描述)，健康保障数据访问服务在设置请求中向健康计划提供者发送用户目录请求分批主题(3100)，以发起对与在所接收的带有更新的用户主题中标识的一个或多个用户相对应的更新数据的传送。用户目录请求分批主题(3100)的内容是基于带有更新的用户主题(3000)的内容的。

用户目录请求分批主题(3100)包括一个或多个用户目录搜索准则(3102、3104、3106)。用户目录搜索准则(3102、3104、3106)包括认证用户和从健康计划提供者请求用户目录数据所需的元素。这些元素可以包括支付者标识、用户证书和日期搜索准则。支付者标识包括唯一标识健康计划提供者的支付者组织的支付者标识符。用户证书包括将用户向收费者组织进行认证所需的元素。这些元素可以包括用户标识和用户密码。用户标识可以是用户名称、签约名称、经由健康计划的授权处理选择或分配的标识符、或者任何其他适当类型的标识。日期搜索准则包括请求用户目录数据的日期范围(即，开始日期/时间和结束日期/时间)。

图32示出根据本发明的一个或多个实施例的用户目录(3200)。用户目录(3200)表示用于单个用户的主题集合。用户目录可以包括搜索准则(3202)、成员主题(3204)、覆盖范围主题(3206)、累积器主题(3208)、医疗要求主题(3210)、药品要求主题(3212)、以及基本保障提供者主题(3214)。搜索准则(3202)包括用于定位包括在主题(3202-3214)中的数据的搜索准则。关于图4、12、14、20、23和16更加详细地描述了主题(3202-3214)的格式。这些主题(3202-3214)中的每一个都可以包括如上所述的、用于用户和用于作为用户的一个或多个健康保障计划的成员的每个用户家属的信息。例如，医疗要求主题(3210)可以包括用于用户和用户家属的医疗主题。

图33示出根据本发明的一个或多个实施例的计划管理目录(3300)。计划管理目录(3300)表示由健康计划提供者管理者所管理的主题集合。更具体地，计划管理目录(3300)包括管理主题，其表示来自健康计划提供者的信息，该健康计划提供者对于健康集合的多个成员是公共的。在本发明的一个或多个实施例中，计划管理目录(3300)用于周期性地更新健康保障数据访问服务的健康保障数据库中的健康计划提供者的管理数据。在本发明的一个或多个实施例中，健康计划数据访问服务将针对计划管理目录(3300)的获取请求发送到健康计划提供者，以请求更新一个或多个管理主题(即，主题3304-3310)。针对计划管理目录(3300)的获取请求可以包括计划管理目录专用的搜索准则。这些搜索准则可以包括副官者标识和数据搜索准则。支付者标识包括支付者标识符，其唯一标识健康计划提供者的支付者组织。数据搜索准则包括请求计划管理目录数据的日期范围(即，开始日期/时间和结束日期/时间)。此外，在本发明的一个或多个实施例中，健康计划提供者将管理数据更新在包括计划管理目录(3300)的设置请求中发送到健康计划数据访问服务。

计划管理目录(3300)可以包括搜索准则(3302)、健康计划细节主题(3304)、利益计划主题(3306)、利益限制主题(3308)、以及提供者主题(3310)。搜索准则(3302)包括用于定位包括在主题(3304-3310)中的数据的搜索准则。以上更加详细地描述了主题(3304-3310)的格式。这些主题(3304-3310)的每一个可以包括以上关于图6、8、10和18描述的健康计划提供者的信息。例如，提供者主题(3310)可以包括关于健康计划提供者的网络中的服务提供者的信息。

图34示出根据本发明的一个或多个实施例的分批用户目录(3400)。分批用户目录(3400)表示与多个用户相对应的分批数据。更具体地，分批用户目录(3400)表示针对每个用户的用户分批主题(2400)。在本发明的一个或多个实施例中，当执行从健康计划提供者到健康保障数据访问服务的健康保障数据库的更新时，使用分批用户目录(3400)。更具体地，在健康保障访问服务将用户目录请求分批主题(以上参考图31描述)发送到健康计划提供者之后，健康计划提供者在设置请求中将分批用户目录(3400)发送到健康保障数据访问服务，以传送针对用户目录请求分批主题中标识的用户的更新数据。

分批用户目录(3400)可以包括搜索准则(3402)和用户分批主题(3404)。搜索准则(3402)包括用于定位包括在用户分批主题(3404)中的数据的搜索准则。以上参考图25更加详细地描述了用户分批主题(3404)的格式。包括在用户分批主题(3404)中的每一个用户分批主题可以包括以上参考图24描述的用户分批主题的信息。

图35示出根据本发明的一个或多个实施例的异常目录(3500)。异常目录(3500)包括关于在关于目录的设置请求或获取请求处理期间发生的一个或多个异常的信息。异常目录可以在与获取请求相对应的响应消息中与所请求的目录一起或代替所请求的目录返回。例如，如果获取请求用于请求针对一千个用户的用户目录数据，并且提供给那些用户中的十个用户的用户证书是无效的，则与获取响应相对应的响应消息包括针对那些具有有效用户证书的用户的用户目录数据，并且异常目录包含与针对具有无效证书的十个用户中的每个用户的无效用户证书相关的异常。

异常目录(3500)可以包括搜索准则(3502)、异常总结(3504)、和异常数据主题(3506)。搜索准则(3502)包括用于导致异常的获取请求的搜索准则。异常总结(3504)包括关于异常的总结信息。该总结信息可以包括标识异常类型的代码和当异常发生时被访问的目录的标识符。异常数据主题(3506)包括关于异常的附加数据。以下参考图37解释异常数据主题的格式。

图36示出根据本发明的一个或多个实施例的异常主题(3600)。异常主题(3600)包括关于在关于主题的设置请求或获取请求的处理期间发生的异常的信息。异常主题可以在与获取请求相对应的响应消息中与请求的主题或代替请求的主题返回。另外，如果在设置请求的处理期间发生异常，异常主题可以在与设置请求相对应的响应消息中返回。

异常主题(3600)可以包括搜索准则(3602)、异常总结(3604)、和异常数据主题(3606)。搜索准则(3602)包括导致异常的获取请求中包括的搜索准则。异常总结(3604)包括关于异常的总结信息。该总结信息可以包括标识异常类型的代码和当异常发生时被访问的主题的标识符。异常数据主题(3606)包括关于异常的附加数据。以下参考图37解释异常数据主题的格式。

图37示出根据本发明的一个或多个实施例的异常数据主题(3700)。异常数据主题(3700)包括关于一个或多个异常的一个或多个异常数据细节(3702、3704、3706)。每个异常数据细节(3702、3704、3706)可以包括异常主题标识符，其标识异常主题和对应于异常主题的数据。

图38示出根据本发明的一个或多个实施例的确认主题(3800)。确认主题(3800)表示针对设置请求消息的确认响应。确认主题(3800)可以包括确认(3802)。确认(3802)可以是向请求者指示接收到设置请求消息以及该设置请是否成功完成的任何适当值。例如，在本发明的一些实施例中，确认值1指示设置请求成功完成，而任何其他值是错误代码。

图39示出本发明的一个或多个实施例的异常系统细节主题(3900)。异常系统细节主题(3900)包括关于异常的系统级别细节。该主题包括需要用于日志记录、监视或调试目的的信息。异常系统细节主题(3900)可以包括事件ID名称(3902)、事件ID(3904)、日期/时间(3906)、源(3908)、格式化消息(3910)、自变量(arguments)(3912)、机器ID(3914)、内部堆栈跟踪(3916)、内部异常类型(3918)、以及内部异常消息(3920)。事件ID名称(3902)是事件的文本名称(例如，Authenticate_InvalidUser)事件ID(3904)是事件的枚举代码。日期/时间(3906)是异常的日期和时间。源(3908)标识检测事件的位置(即，代码模块)。格式化消息(3910)是描述异常细节主题(3900)中的剩余条目的人工可读消息。自变量(3912)是进入格式化消息(3910)的特定数据。机器ID(3914)标识异常发生的物理机器。内部堆栈跟踪(3916)是实现语言的堆栈跟踪。内部异常类型(3918)是实现语言所抛出的异常类型。内部异常消息(3920)是与实现语言异常相关联的消息。

如先前描述的那样，在本发明的一个或多个实施例中，HCDT协议可以由配置为执行通信的HCDT Web服务实现。在这样的实施例中，HCDT Web服务(即，HCDT协议的消息格式和协议绑定)的服务接口可以使用Web服务描述语言(WSDL)定义。WSDL描述提供HCDT Web服务的概述，包括支持的HCDT Web服务的操作和消息以及HCDT Web服务位于何处。此外，与HCDT Web服务相对应的健康保障域的健康保障目录和健康保障主题可以被定义作为在一个或多个XML计划定义(XSD)文件中的可扩展标记语言(XML)计划。

WSDL描述可以与HCDT Web服务一起存储在主服务器(例如，健康保障数据访问服务、HCDT服务器等)上，或可以注册到Web服务注册处。HCDT Web服务的客户端可以通过使用SOAP消息调用HCDT WSDL文件中定义的功能来调用如WSDL描述定义的HCDT Web服务。例如，在本发明的一些实施例中，消费者健康保障应用可以使用SOAP来调用在HCDT WSDL文件中定义的功能，其中HCDT WSDL文件描述健康保障数据访问服务上的Web服务应用。类似地，健康保障数据访问服务可以使用SOAP调用在描述HCDT服务器上的HCDT Web服务的WSDL文件中定义的功能，反之亦然。

每个HCDT Web服务提供了实现HCDT协议的四个动作的四个方法：设置主题数据方法、获取主题数据方法、设置目录数据方法和获取目录数据方法。参考图2，在每个HCDT请求消息(200)中，动作标识符(204)标识调用的方法，并且参数(206)是该方法的参数。相应的HCDT响应消息的动作结果(208)是执行所标识的动作的结果。

图40A-40D示出根据本发明的一个或多个实施例的、如HCDTWeb服务中实现的那样的HCDT请求/响应消息的格式。如图40A所示，获取主题数据请求消息(4000)包括与获取主题数据方法(4002)相对应的标识符、主题标识符(4004)、以及可选的主题搜索准则(4006)。主题搜索准则(4006)(如果存在)用于进一步规定与主题对应的哪一部分数据被请求。获取主题数据响应消息(4008)包括请求的主题数据(4010)。在与获取主题数据请求消息(4000)中标识的主题相对应的数据结构中返回请求的主题数据。

如图40B所示，设置主题数据请求消息(4012)包括与设置主题数据方法(4014)相对应的标识符、主题标识符(4016)和主题数据(4018)。主题数据(4018)是与主题标识符(4016)标识的主题相对应的数据结构，该主题标识符(4016)包含由主题表示的健康保障数据。设置主题数据响应消息(4020)包括设置主题结果(4022)，其可以是成功完成的设置请求的确认或者HCDT异常。

如图40C所示，获取目录数据请求消息(4024)包括与获取目录数据方法(4026)相对应的标识符、目录标识符(4028)、和可选的目录搜索准则(4030)。目录搜索准则(4030)(如果存在)用于进一步规定与主题对应的哪一部分数据被请求。获取目录数据响应消息(4032)包括请求的目录数据(4034)。在与获取主题数据请求消息(4000)中标识的目录相对应的数据结构中返回请求的目录数据。

如图40D所示，设置目录数据请求消息(4036)包括与设置目录数据方法(4038)相对应的标识符、目录标识符(4040)和目录数据(4042)。目录数据(4042)是与目录标识符(4040)标识的目录相对应的数据结构，该目录标识符(4040)包含由目录表示的健康保障数据。设置目录数据响应消息(4044)包括设置目录结果(4046)，其可以是成功完成的设置请求的确认或者HCDT异常。

图41A和41B示出根据本发明的一个或多个实施例的传送的调用流程。更具体地，图41A和41B示出在本发明的一个或多个实施例中的、在健康保障数据访问服务(例如，健康保障数据访问服务HCDT Web服务(4100))上操作的HCDT Web服务与和健康计划提供者(例如，健康计划提供者HCDT Web服务(4102))进行接口连接的HCDT Web服务之间的请求/响应消息的流程。在本发明的一些实施例中，如果健康计划提供者不支持HCDT协议，则健康计划提供者HCDT Web服务(例如健康计划提供者HCDT Web服务(4102))可以在HCDT服务器上执行。

在示出的调用流程中，如以上参考图40A-40B所述，getTopicData是获取主题数据方法(4002)，setTopicData是设置主题数据方法(4014)，getCatalogData是获取目录数据方法(4026)，并且setCatalogData是设置目录数据方法(4038)。此外，这些调用流程中所示的主题和目录是针对健康计划业务域的HCDT协议中定义的主题和目录，如参考图3-39所述的那样。

图41A示出认证用户调用流程(4104)、订阅/未订阅用户调用流程(4106)、用户数据请求调用流程(4108)、计划管理数据调用流程(4110)、以及分批更新调用流程(4112)。在认证用户调用流程(4104)中，健康保障数据访问服务HCDT Web服务(4100)向健康计划提供者HCDT Web服务(4102)发送设置主题数据请求消息以认证用户。设置主题数据请求消息包括与setTopicData方法相对应的标识符以及用于setTopicData方法的参数。这些参数是用于用户认证主题的主题标识符(即，UserAuthenticationTopicID)、以及用户认证主题数据(即，UserAuthenticationTopic)。

健康计划提供者HCDT Web服务(4102)利用规定的参数调用setTopicData方法以使用用户认证主题数据来认证用户，并将设置主题数据响应消息返回给健康保障数据访问服务HCDT Web服务(4100)，以报告setTopicData方法的执行结果。如果认证成功，则设置主题数据响应消息包括确认主题(即，AcknowledgeTopic)，如果认证不成功，则设置主题数据响应消息包括异常主题(即，ExceptionTopic)。

在订阅/未订阅调用流程(4106)中，健康保障数据访问服务HCDT Web服务(4100)将设置主题数据请求消息发送到健康计划提供者HCDT Web服务(4102)，以更新用户的订阅状态。设置主题数据请求消息包括与setTopicData方法相对应的标识符和用于setTopicData方法的参数。这些参数是用于应用订阅主题的主题标识符(即，ApplicationSubscriptionTopicID)、以及应用订阅主题数据(即，ApplicationSubscriptionTopic)。

健康计划提供者HCDT Web服务(4102)利用规定的参数来调用setTopicData方法，以基于应用订阅主题数据来更新用户的订阅状态，并将设置主题数据响应消息返回给健康保障数据访问服务HCDTWeb服务(4100)，以报告setTopicData方法的执行结果。如果更新成功，则设置主题数据响应消息包括确认主题(即，AcknowledgeTopic)，如果更新不成功，则设置主题数据响应消息包括异常主题(即，ExceptionTopic)。

在用户数据请求调用流程(4108)中，健康保障数据访问服务HCDT Web服务(4100)向健康计划提供者HCDT Web服务(4102)发送获取目录数据请求消息，以请求用户的健康保障数据的所有或某一部分。获取目录数据请求消息包括与getCatalogData方法相对应的标识符和用于getCatalogData方法的参数。这些参数是用于用户目录的目录标识符(即，UserCatalogID)、以及可选的搜索准则(即，UserCatalogSearchCriteria)。如果存在搜索准则，则搜索准则规定哪一部分用户健康保障数据被请求。如果没有包括搜索准则，则该请求针对的是用户目录规定的所有用户健康保障数据。

健康计划提供者HCDT Web服务(4102)利用规定的参数调用getCatalogData方法以取回用户的健康保障数据，并将获取目录数据响应消息返回给健康保障数据访问服务HCDT Web服务(4100)。获取目录数据响应消息包括用户目录(即，UserCatalog)，如果请求成功完成，则用户目录包含用户的健康保障数据，如果请求没有成功完成，则用户目录包含异常目录(即，ExceptionCatalog)。

在计划管理数据调用流程(4110)中，健康保障数据访问服务HCDT Web服务(4100)将获取目录数据请求消息发送到健康计划提供者HCDT Web服务(4102)，以请求健康计划提供者的管理数据的所有或某一部分。获取目录数据请求消息包括与getCatalogData方法相对应的标识符和用于getCatalogData方法的参数。这些参数是用于计划管理目录的目录标识符(即，PlanAdminCatalogID)、以及可选的搜索准则(即，PlanAdminCatalogSearchCriteria)。如果存在搜索准则，则搜索准则规定哪一部分健康计划提供者的管理数据被请求。如果没有包括搜索准则，则该请求针对的是由计划管理目录规定的所有的健康计划提供者的管理数据。

健康计划提供者HCDT Web服务(4102)利用规定的参数调用getCatalogData方法，以取回健康计划提供者的管理数据，并将获取目录数据响应消息返回给健康保障数据访问服务HCDT Web服务(4100)。获取目录数据响应消息包括计划管理目录(即，PlanAdminCatalog)，如果请求成功完成，则计划管理目录包含健康计划提供者的管理数据，如果请求没有成功完成，则计划管理目录包含异常目录(即，ExceptionCatalog)。

在分批更新调用流程(4112)中，健康计划提供者HCDT Web服务(4102)向健康保障数据访问服务HCDT Web服务(4100)发送设置主题数据请求消息，以通知健康保障数据访问服务所更新的健康保障数据对于健康保障数据访问服务的用户是可用的。该设置主题数据请求消息包括与setTopicData方法相对应的标识符和用于setTopicData方法的参数。这些参数是用于带有更新的用户主题的主题标识符(即，UsersWithUpdatesTopicID)、以及带有更新的用户主题数据(即，UsersWithUpdatesTopic)。

健康保障数据访问服务HCDT Web服务(4100)利用规定的参数调用setTopicData方法，以通知健康保障数据访问服务，来自健康计划提供者的更新对于带有更新的用户主题中标识的用户是可用的。健康保障数据访问服务HCDT Web服务(4100)还将设置主题数据响应消息返回给健康计划提供者HCDT Web服务(4102)，以报告setTopicData方法的执行结果。如果设置请求成功完成，则设置主题数据响应消息包括确认主题(即，AcknowledgeTopic)，如果设置请求没有成功完成，则设置主题数据响应消息包括异常主题(即，ExceptionTopic)。

如果设置请求成功，则健康保障数据访问服务HCDT Web服务(4100)向健康计划提供者HCDT Web服务(4102)发送设置主题数据请求消息，以请求用于带有更新的用户主题数据中标识的用户的更新的健康保障数据。设置主题数据请求消息包括与setTopicData方法相对应的标识符以及用于setTopicData方法的参数。这些参数是用于用户目录请求分批主题的主题标识符(即，UserCatalogRequestBatchTopicID)、以及用户目录请求分批主题数据(即，UserCatalogRequestBatchTopic)。

健康计划提供者HCDT Web服务(4102)利用规定参数来调用setTopicData方法，以来认证每个用户，并基于用户目录请求分批主题数据发起对用户的更新的健康保障数据的传送。健康计划提供者HCDT Web服务(4102)还将设置主题数据响应消息返回给健康保障数据访问服务HCDT Web服务(4100)，以报告setTopicData方法的执行结果。如果认证和发起成功完成，则设置主题数据响应消息包括确认主题(即，AcknowledgeTopic)，如果认证和发起没有成功完成，则设置主题数据响应消息包括异常主题(即，ExceptionTopic)。

如果认证和发起成功完成，则健康计划提供者HCDT Web服务(4102)将设置目录数据请求消息发送到具有用户的更新的健康保障数据的健康保障数据访问服务HCDT Web服务(4100)。该设置目录数据请求消息包括与setCatalogData方法相对应的标识符和用于setCatalogData方法的参数。这些参数是用于分批用户目录的主题标识符(即，BatchUserCatalogID)、以及分批用户目录数据(即，BatchUserCatalog)。

健康保障数据访问服务HCDT Web服务(4100)利用规定的参数调用setCatalogData方法，以更新用户的健康保障数据。健康保障数据访问服务HCDT Web服务(4100)还将设置主题数据响应消息返回给健康计划提供者HCDT Web服务(4102)，以报告setCatalogData方法的执行结果。如果更新成功，则该设置目录数据响应消息包括确认主题(即，AcknowledgeTopic)如果更新不成功，则设置目录数据响应消息包括异常主题(即，ExceptionTopic)。

图41B示出代码描述调用流程(4114)、用户数据排序响应调用流程(4116)、计划管理数据排序响应调用流程(4118)、以及健康检查调用流程(4120)。在代码描述调用流程(4114)中，健康保障数据访问服务HCDT Web服务(4100)向健康计划提供者HCDT Web服务(4102)发送获取主题数据请求消息，以请求代码描述数据。获取主题数据请求消息包括与getTopicData方法相对应的标识符和用于getTopicData方法的参数。这些参数是用于代码描述主题的主题标识符(即，CodeDescriptionTopicID)、以及可选的搜索准则(即，CodeDescriptionTopicSearchCriteria)。

健康计划提供者HCDT Web服务(4102)利用规定的参数调用getTopicData方法，以取回代码描述数据，并将获取主题数据响应消息返回给健康保障数据访问服务HCDT Web服务(4100)。如果请求成功完成，获取主题数据响应消息包括包含代码描述数据的代码描述主题(即，CodeDescriptionTopic)，如果请求没有成功完成，获取主题数据响应消息包括异常目录(即，ExceptionCatalog)。

用户数据排序响应调用流程(4116)示出了当如以上参考第一使用调用流程(4108)描述的那样，针对用户目录的获取目录数据请求消息导致大量健康保障数据从健康计划提供者传送到健康保障数据访问服务时的调用流程。健康保障数据作为一系列较小的数据传送进行发送，而不是在单个获取目录数据响应消息中传送大量健康保障数据。该系列中的第一数据传送是获取目录数据响应消息中返回的用户目录。剩余的数据传送是根据用户数据排序响应调用流程(4116)的。

在用户数据排序响应调用流程(4116)中，健康计划提供者HCDTWeb服务(4102)向健康保障数据访问服务HCDT Web服务(4100)发送设置目录数据请求消息。设置目录数据请求消息包括与setCatalogData方法相对应的标识符和用于setCatalogData方法的参数。这些参数是用于用户目录的目录标识符(即，UserCatalogID)、以及用户目录(即，UserCatalog)，该用户目录包含响应于针对用户目录的获取目录数据请求消息而返回的一部分健康保障数据。健康保障数据访问服务HCDT Web服务(4100)利用规定的参数调用setCatalogData方法，以基于用户目录的内容来更新用户的健康保障数据。

计划管理数据排序响应调用流程(4118)示出了当如以上参考计划管理数据调用流程(4110)描述的那样的，针对计划管理目录的获取目录数据请求消息导致大量管理数据从健康计划提供者传送到健康保障数据访问服务时的调用流程。管理数据作为一系列较小的数据传送进行发送，而不是在单个获取目录数据响应消息中传送大量管理数据。该系列中的第一数据传送是获取目录数据响应消息中返回的计划管理目录。剩余的数据传送是根据计划管理数据排序响应调用流程(4118)的。

在计划管理数据排序响应调用流程(4118)中，健康计划提供者HCDT Web服务(4102)向健康保障数据访问服务HCDT Web服务(4100)发送设置目录数据请求消息。设置目录数据请求消息包括与setCatalogData方法相对应的标识符和用于setCatalogData方法的参数。这些参数是用于计划管理目录的目录标识符(即，UserCatalogID)、以及计划管理目录(即，PlanAdminCatalog)，该计划管理目录包含响应于针对计划管理目录的获取目录数据请求消息而返回的一部分管理数据。健康保障数据访问服务HCDT Web服务(4100)利用规定的参数调用setCatalogData方法，以基于计划管理目录的内容来更新健康计划提供者的管理数据。

在健康检查调用流程(4120)中，健康保障数据访问服务HCDTWeb服务(4100)向健康计划提供者HCDT Web服务(4102)发送获取主题数据请求消息，以请求版本信息。该获取主题数据请求消息包括与getTopicData方法相对应的标识符和用于getTopicData方法的参数。这些参数是用于版本信息主题的主题标识符(即，VersionInfoTopicID)。

健康计划提供者HCDT Web服务(4102)利用规定的参数调用getTopicData方法，以取回版本信息，并将获取主题数据响应消息返回给健康保障数据访问服务HCDT Web服务(4100)。如果请求成功完成，获取主题数据响应消息包括包含版本信息的版本信息主题(即，VersionInfoTopic)，如果请求没有成功完成，获取主题数据响应消息包括异常主题(即，ExceptionTopic)。

图42-44示出根据本发明的一个或多个实施例的健康保障数据的交换的方法的流程图。尽管这些流程图中的各个步骤顺序地呈现和描述，本领域的普通技术人员将可以理解，部分或全部步骤可以按不同顺序执行，并且部分或全部步骤可以并行执行。

图42示出根据本发明的一个或多个实施例的用于请求与健康保障数据相对应的动作的方法的流程图。在本发明的一些实施例中，以下描述的消息传送可以遵循HCDT协议。初始地，与健康保障数据相对应的请求消息从健康保障数据传送系统中的一个实体发送到健康保障数据传送系统中的另一个实体(ST4210)。健康保障数据可以在请求消息的参数中表示为健康保障业务域的目录或主题。请求消息可以是获取请求消息或者设置请求消息，其中该获取请求消息请求与主题或目录相对应的健康保障数据，该设置请求消息请求对与主题或目录相对应的健康保障数据的修改。如果请求消息是获取请求消息，则该消息的参数还可以包括进一步定义将返回的健康保障数据的搜索准则。例如，搜索准则可以是规定仅返回日期范围内创建的或更新的主题数据。如果请求消息是设置请求消息，则该请求消息还包括对与主题或目录相对应的数据结构中的修改。

在本发明的一个或多而实施例中，发送请求消息的实体可以是健康保障数据访问服务，并且接收请求消息的实体可以是健康保障信息源(反之亦然)。在本发明的一些实施例中，发送请求消息的实体可以是消费者健康保障应用，并且接收请求消息的实体可以是健康保障信息源和/或健康保障数据访问服务(并且反之亦然)。另外，在本发明的一些实施例中，HCDT服务器可以与健康保障信息源相关联，并可以发送或接收针对健康保障信息源的请求消息。此外，在本发明的一个或多个实施例中，请求消息可以针对接收该请求消息的实体上的Web服务。

在请求消息被请求实体处理之后，由发送请求消息的实体接收与请求消息相对应的响应消息(ST4220)。如果请求消息是获取请求消息，则响应消息包括请求的健康保障数据。更具体地，响应消息包括按照与所请求的主题或目录相对应的数据结构的请求的健康保障数据。如果请求消息是设置请求消息，则响应消息可以包括对请求的确认或异常，其中该确认指示设置请求成功完成，该异常指示设置请求没有成功。

然后初始发送请求消息的实体处理响应消息(ST4230)。如果请求消息是获取请求消息，则对响应消息的处理可以包括：如果请求实体是健康保障数据访问服务或消费者健康保障应用，则将响应消息中的健康保障数据存储在健康保障数据库中。如果请求实体是健康保障消息源，则对响应消息的处理可以包括将健康保障数据存储在由健康保障信息源维护的一个或多个数据库中。如果请求实体是HCDT服务器，则对响应消息的处理可以包括将响应消息转换为按照与该HCDT服务器相关联的健康保障信息源理解的格式的一个或多个消息。

如果请求消息是设置请求消息，则对响应消息的处理可以包括将响应消息中包括的确认或异常进行日志记录，向接收请求消息的实体请求关于异常的附加信息，和/或将确认或异常通知给用户。此外，如果请求实体是HCDT服务器，则对响应消息的处理可以包括将响应消息转换为按照与该HCDT服务器相关联的健康保障信息源理解的格式的一个或多个消息。

图43示出根据本发明的一个或多个实施例的用于对针对与健康保障数据相对应的动作的请求作出响应的方法。在本发明的一些实施例中，以下描述的消息交换可以遵循HCDT协议。初始地，由健康保障数据传送系统中的实体从健康保障数据传送系统中的另一实体接收与健康保障数据相对应的请求消息(ST4310)。健康保障数据可以在请求消息的参数中被表示为健康保障业务域中的主题或目录。请求消息可以是请求与主题或目录对应的健康保障数据的获取请求消息或者请求对与主题或者目录的健康保障数据进行修改的设置请求数据。如果请求消息是获取请求消息，则该消息的参数还可以包括进一步限定将被返回的健康保障数据的搜索准则。例如，搜索准则可以是日期范围，其规定仅返回在该日期范围内创建和更新的主题数据。如果请求消息是设置请求消息，则该请求消息还可以包括与主题或目录相对应的数据结构中的修改。

在本发明的一个或多个实施例中，接收请求消息的实体可以是健康保障数据访问服务，并且发送请求消息的实体可以是健康保障信息源(反之亦然)。在本发明的一些实施例中，接收请求消息的实体可以是消费者健康保障应用，并且发送请求消息的实体可以使健康保障信息源和/或健康保障数据访问服务(反之亦然)。另外，在本发明的一些实施例中，HCDT服务器可以与健康保障信息源相关联，并可以发送或接收针对健康保障信息源的请求消息。此外，在本发明的一个或多个实施例中，请求消息可以针对接收该请求消息的实体上的Web服务。

在接收到请求消息之后，识别由该请求消息规定的动作(ST4320)，并且通过接收实体使用包括在请求消息中的参数(如果存在)来执行该动作(ST4330)。如果请求消息是获取请求消息，则标识的动作是提取所请求的、与参数和搜索准则(如果存在)中标识的主题或目录相对应的健康保障数据。执行该动作包括定位所请求的健康保障数据以及生成响应消息，该响应消息包括所请求的、与主题或目录相对应的数据结构中的数据。

如果接收实体是健康保障数据访问服务或消费者健康保障应用，则定位所请求的数据包括访问健康保障数据库中的数据。如果接收实体是健康保障信息源，则定位所请求的数据包括访问由健康保障信息源维护的一个或多个数据库中的数据。如果接收实体是HCDT服务器，则定位所请求的数据包括：将动作转换为按照与该HCDT相关联的健康保障信息源理解的格式的一个或多个消息，将该消息发送到健康保障信息源来访问所请求的数据，以及接收对于该消息的响应，该响应包括所请求的数据。

如果请求的消息是设置请求消息，则标识的动作是由接收实体按照包括在请求消息中的主题或目录数据结构的内容来修改所存储的健康保障数据。执行该动作包括进行请求的修改以及产生响应消息，该响应消息包括用于指示成功执行该动作的确认或者用于指示该动作没有成功完成的异常。

如果接收实体是健康保障数据访问服务或消费者健康保障应用，则进行所请求的修改包括将与修改相对应的数据存储在健康保障数据库中。如果接收的实体是健康保障信息源，则进行所请求的修改包括将与修改相对应的数据存储在由健康保障信息源维护的一个或多个数据库中。如果接收实体是HCDT服务器，则进行所请求的修改包括：将动作转换为按照与该HCDT相关联的健康保障信息源理解的格式的一个或多个消息，将该消息发送到健康保障信息源来进行所请求的修改，以及接收对于该消息的响应，该响应指示该修改是否成功完成。

一旦产生与请求消息相对应的响应消息，则将响应消息发送到请求实体(ST4340)。如以上解释，响应消息包括执行所请求的动作的结果(例如，与主题或目录相关联的数据结构、确认或异常)。

图44示出根据本发明的一个或多个实施例的用于由健康保障数据访问服务维护健康保障数据的方法。初始地，由健康保障数据访问服务接收来自消费者健康保障应用的用户的注册信息(ST4410)。注册信息可以包括：维护与用户相对应的健康保障数据的健康保障信息源的标识、以及针对每个所标识的健康保障信息源的用户认证信息(例如，用户ID和密码)。

然后，健康保障数据访问服务请求来自每个所标识的健康保障信息源的与用户相对应的健康保障数据。请求处理包括：使用由用户提供的认证信息将用户向每个标识的健康保障信息源进行认证(ST4420)，以及将请求消息发送到每个标识的健康保障信息源(ST4430)，该请求消息请求与用户相对应的健康保障数据。

然后，健康保障数据访问服务从每个健康保障信息源接收与请求消息相对应的、包括所请求的健康保障数据的响应消息(ST4440)。当接收时，健康保障数据访问服务处理该响应消息，以将健康保障数据存储在健康保障数据库中(ST4450)。

在接收和处理来自每个健康保障信息源的响应消息之后，健康保障数据访问服务向用户通知健康保障数据在健康保障数据库中现在是可用的(ST4460)。用户则可以使用消费者健康保障应用来访问该数据。

在从标识的健康保障信息源初始下载健康保障数据之后，从每个用户的健康保障信息源周期性地更新与该用户相对应的健康保障数据(ST4470)。在本发明的一个或多个实施例中，健康保障数据访问服务或健康保障信息源可以发起周期性更新。当作为周期性更新的结果而针对用户下载新的健康保障数据时，健康保障数据访问服务向用户通知新的健康保障数据在健康保障数据库中是可用的(ST4480)。本领域的技术人员可以理解，在一个或多个实施例中，本发明提供给消费者从单个消费者健康保障应用访问来自多个健康保障信息源的健康保障数据的能力。此外，本发明的实施例提供用于请求和修改不同健康保障业务域中的健康保障数据的标准协议。该协议可以用于在健康保障业务域相对应的健康保障信息源与消费者健康保障应用和/或健康保障数据访问服务之间传送健康保障数据。在本发明的一些实施例中，该协议还可以用于在消费者健康保障应用与健康保障数据访问服务之间传送健康保障数据。

本发明的实施例实质上可以在任何类型的计算机上实现，而不管计算机使用何种平台。例如，如图45所示，计算机系统(4500)包括处理器(4502)、相关联的存储器(4504)、存储设备(4506)、以及现代计算机典型的功能性和多个其他元件(未示出)。计算机(4500)还可以包括诸如键盘(4508)和鼠标(4510)的输入装置、以及诸如监视器(4512)的输出装置。计算机系统(4500)可以经由网络接口连接(未示出)而连接到局域网(LAN)或广域网(例如，互联网)(未示出)。此外，计算机系统(4500)可以是连接到无线连接的移动设备。本领域的技术人员将可以理解，这些输入和输出装置可以采用其他形式。

此外，本领域的技术人员将可以理解，前述计算机系统(4500)的一个或多个元件可以位于远程位置，并可以通过网络连接到其他元件。此外，本发明的实施例可以在具有多个节点的分布式系统上实现，其中本发明的每个部分可以位于该分布式系统内的不同节点上。在本发明的一个或多个实施例中，节点对应于计算机系统。作为备选，节点可以与具有相关联的物理存储器的处理器相对应。作为备选，节点可以与具有共享存储器和/或资源的处理器相对应。此外，执行本发明的实施例的软件指令可以存储在诸如致密盘(CD)、磁盘、磁带、文件或任何其他计算机可读存储设备的计算机可读介质上。

尽管参考数目有限的实施例描述了本发明，本领域的技术人员根据本公开可以理解，在不偏离在此公开的本发明的范围的前提下可以设计其他实施例。因此，本发明的范围应当仅限于所附权利要求。

Claims (79)

1.一种用于在消费者健康保障应用与多个健康保障信息源之间传送健康保障数据的方法，所述方法包括：

从多个健康保障信息源的第一健康保障信息源请求与消费者相对应的第一部分健康保障数据；

从第一健康保障信息源接收第一部分健康保障数据；

将第一部分健康保障数据存储在健康保障数据库中；

从多个健康保障信息源的第二健康保障信息源请求与消费者相对应的第二部分健康保障数据；

从第二健康保障信息源接收第二部分健康保障数据；

将第二部分健康保障数据存储在健康保障数据库中；以及

从所述健康保障数据库访问第一部分健康保障数据和第二部分健康保障数据。

2.根据权利要求1的方法，其中通过消费者健康保障应用访问第一部分健康保障数据和第二部分健康保障数据。

3.根据权利要求1的方法，还包括：

从消费者健康保障应用接收与所述第一健康保障信息源相对应的第一认证信息；以及

从消费者健康保障应用接收与所述第二健康保障信息源相对应的第二认证信息。

4.根据权利要求1的方法，还包括：

向消费者通知第一部分健康保障数据和第二部分健康保障数据在所述健康保障数据库中。

5.根据权利要求1的方法，其中所述第一健康保障信息源是第一健康计划提供者，并且所述第二健康保障信息源是第二健康计划提供者。

6.根据权利要求1的方法，其中所述第一健康保障信息源与第一健康保障业务域相对应，并且所述第二健康保障信息源与第二健康保障业务域相对应。

7.根据权利要求6的方法，其中所述第一健康保障业务域和所述第二健康保障业务域中的每一个都是从包括以下内容的群组中选择的一个业务域：健康计划业务域、金融业务域、病人记录业务域、药品业务域、实验室业务域、医疗成像业务域、医疗设备业务域、提供者记账业务域、医疗研究/分析业务域、病人教育业务域、牙科业务域、视力护理业务域、备选医疗业务域、体能业务域、理疗业务域、康复业务域、辅助护理业务域、实践管理业务域、和心理学业务域。

8.根据权利要求1的方法，其中第一部分健康保障数据和第二部分健康保障数据中的每一个都是从包括以下内容的群组中选择的至少一个部分：成员数据、医疗要求数据、药品要求数据、利益限制数据、覆盖范围数据、累积器数据、提供者数据、和基本保障提供者数据。

9.根据权利要求1的方法，还包括：

向第一健康保障信息源发送与消费者相对应的第三部分健康保障数据，其中所述第一健康保障信息源存储第三部分健康保障数据。

10.根据权利要求1的方法，其中请求第一部分健康保障数据还包括发送请求消息，所述请求消息包括与获取数据请求相对应的动作标识符以及与第一部分健康保障数据相对应的标识符，并且其中接收第一部分健康保障数据还包括接收与所述请求消息相对应的响应消息，所述响应消息包括第一部分健康保障数据。

11.根据权利要求10的方法，其中所述动作标识符标识从包括以下内容的群组中选择的健康保障数据传送协议方法：获取主题数据、设置主题数据、获取目录数据和设置目录数据，并且其中第一部分健康保障数据是从包括主题和目录的群组中选择的一个部分，其中所述主题和目录包括与所述第一健康保障信息源的健康保障业务域中的健康保障数据相对应的数据结构。

12.根据权利要求9的方法，其中发送第三部分健康保障数据还包括：

发送请求消息，所述请求消息包括与设置数据请求相对应的动作标识符、与第三部分健康保障数据相对应的标识符、和第三部分健康保障数据；以及

接收与所述请求消息相对应的响应消息。

13.根据权利要求12的方法，其中所述请求消息还包括搜索准则。

14.根据权利要求1的方法，还包括：

从所述第一健康保障信息源接收针对与消费者相对应的第四部分健康保障数据的请求；

向所述第一健康保障信息源发送第四部分健康保障数据；以及

存储第四部分健康保障数据。

15.根据权利要求14的方法，其中由所述第一健康保障信息源存储第四部分健康保障数据。

16.根据权利要求1的方法，其中所述消费者健康保障应用包括所述健康保障数据库。

17.一种用于在消费者健康保障应用与健康保障信息源之间传送健康保障数据的方法，所述方法包括：

发送第一请求消息，所述第一请求消息包括针对执行与第一部分健康保障数据相对应的第一动作的第一请求；

接收与所述第一请求消息相对应的第一响应消息，其中所述第一响应消息包括执行所述第一动作的结果；以及

处理所述第一响应消息，

其中所述第一请求消息和所述第一响应消息遵循健康保障数据传送协议。

18.根据权利要求17的方法，其中所述第一动作是从包括以下内容的群组中选择的动作：获取主题数据、设置主题数据、获取目录数据和设置目录数据，并且其中第一部分健康保障数据是从包括主题和目录的群组中选择的一个部分，其中所述主题和目录包括与所述健康保障信息源的健康保障业务域中的健康保障数据相对应的数据结构。

19.根据权利要求17的方法，还包括接收与所述健康保障信息源相对应的认证信息。

20.根据权利要求17的方法，其中所述健康保障信息源与从选自包括以下内容的群组的健康保障业务域相对应：健康计划业务域、金融业务域、病人记录业务域、药品业务域、实验室业务域、医疗成像业务域、医疗设备业务域、提供者记账业务域、医疗研究/分析业务域、病人教育业务域、牙科业务域、视力护理业务域、备选医疗业务域、体能业务域、理疗业务域、康复业务域、辅助护理业务域、实践管理业务域、和心理学业务域。

21.根据权利要求17的方法，其中第一部分健康保障数据是从包括以下内容的群组中选择的至少一个部分：成员数据、医疗要求数据、药品要求数据、利益限制数据、覆盖范围数据、累积器数据、提供者数据、和基本保障提供者数据。

22.根据权利要求17的方法，其中所述第一请求消息包括将所述第一动作标识为获取数据请求的第一动作标识符、和与第一部分健康保障数据相对应的标识符，并且其中所述第一响应消息包括第一部分健康保障数据。

23.根据权利要求22的方法，其中处理所述第一响应消息还包括将第一部分健康保障数据存储在健康保障数据库中。

24.根据权利要求23的方法，其中所述消费者健康保障应用从所述健康保障数据库访问第一部分健康保障数据。

25.根据权利要求17的方法，其中所述第一请求消息还包括搜索准则。

26.根据权利要求17的方法，其中所述第一请求消息包括将所述第一动作标识为设置数据请求的动作标识符、与第一部分健康保障数据相对应的标识符、以及所述部分健康保障数据，并且所述第一响应消息包括从包含确认和异常的群组中选择的一个。

27.根据权利要求17的方法，还包括：

接收第二请求消息，所述第二请求消息包括针对执行与第二部分健康保障数据相对应的第二动作的请求；

执行所述第二动作；以及

生成与所述第二请求消息相对应的第二响应消息，其中所述第二响应消息包括执行所述第二动作的结果，

其中所述第二请求消息和所述第二响应消息遵循健康保障数据传送协议。

28.根据权利要求27的方法，其中，

所述第二请求消息包括将所述第二动作标识为获取数据请求的动作标识符、和与第二部分健康保障数据相对应的标识符；以及

所述第二响应消息包括第二部分健康保障数据。

29.根据权利要求28的方法，其中执行所述第二动作还包括从所述健康保障数据库提取第二部分健康保障数据。

30.根据权利要求27的方法，其中所述第二请求消息包括将所述第二动作标识为设置数据请求的动作标识符、与第二部分健康保障数据相对应的标识符、以及第二部分健康保障数据，并且其中所述第二响应消息包括从包含确认和异常的群组中选择的一个。

31.一种健康保障数据传送系统，包括：

健康保障信息源，被配置为存储与消费者相对应的一部分健康保障数据；以及

健康保障数据访问服务，其操作性地连接到所述健康保障信息源，其中所述健康保障数据访问服务包括以下功能性：

向健康保障信息源发送请求消息，所述请求消息包括针对执

行与所述部分健康保障数据相对应的动作的请求，

接收与所述请求消息相对应的响应消息，其中所述响应消息

包括执行所述动作的结果，以及

处理所述响应消息，

其中所述请求消息和所述响应消息遵循健康保障数据传送协议。

32.根据权利要求31的健康保障数据传送系统，还包括：

健康保障数据服务器，其操作性地连接到所述健康保障信息源和所述健康保障数据访问服务，其中所述健康保障数据服务器包括以下功能性：

接收请求消息，

与所述健康保障信息源交互，以执行所述动作，以及

向健康保障数据访问服务发送响应消息。

33.根据权利要求31的健康保障数据传送系统，其中所述动作是从包括以下内容的群组中选择的动作：获取主题数据、设置主题数据、获取目录数据和设置目录数据，并且其中所述部分健康保障数据是从包括主题和目录的群组中选择的一个部分，其中所述主题和目录包括与所述健康保障信息源的健康保障业务域中的健康保障数据相对应的数据结构。

34.根据权利要求31的健康保障数据传送系统，其中与健康保障业务域相对应的健康保障信息源从包括以下内容的群组中选择：健康计划业务域、金融业务域、病人记录业务域、药品业务域、实验室业务域、医疗成像业务域、医疗设备业务域、提供者记账业务域、医疗研究/分析业务域、病人教育业务域、牙科业务域、视力护理业务域、备选医疗业务域、体能业务域、理疗业务域、康复业务域、辅助护理业务域、实践管理业务域、和心理学业务域。

35.根据权利要求31的健康保障数据传送系统，其中所述部分健康保障数据是从包括以下内容的群组中选择的至少一个部分：成员数据、医疗要求数据、药品要求数据、利益限制数据、覆盖范围数据、累积器数据、提供者数据、和基本保障提供者数据。

36.根据权利要求31的健康保障数据传送系统，其中所述请求消息包括将所述动作标识为获取数据请求的动作标识符、和与健康保障数据的所述部分相对应的标识符，并且其中所述响应消息包括所述部分健康保障数据。

37.根据权利要求36的健康保障数据传送系统，还包括：

健康保障数据库，其操作性地连接到健康保障数据访问服务，并被配置为将所述部分健康保障数据存储在所述健康保障数据库中。

38.根据权利要求37的健康保障数据传送系统，还包括：

消费者健康保障应用，其操作性地连接到健康保障数据访问服务，其中消费者使用所述消费者健康保障应用来访问所述部分健康保障数据。

39.根据权利要求31的健康保障数据传送系统，其中所述请求消息还包括搜索准则。

40.根据权利要求31的健康保障数据传送系统，其中所述请求消息包括将所述动作标识为设置数据请求的动作标识符、与所述部分健康保障数据相对应的标识符、以及所述部分健康保障数据，并且其中所述响应消息包括从包含确认和异常的群组中选择的一个。

41.一种健康保障数据传送系统，包括：

与第一健康保障业务域相对应的第一健康保障信息源，其中所述第一健康保障信息源包括与消费者相对应的第一部分健康保障数据；

与第二健康保障业务域相对应的第二健康保障信息源，其中所述第二健康保障信息源包括与消费者相对应的第二部分健康保障数据；以及

健康保障数据访问服务，其操作性地连接到所述第一健康保障信息源和所述第二健康保障信息源，其中所述健康保障数据访问服务包括以下功能性：

接收第一部分健康保障数据和第二部分健康保障数据，以及

存储第一部分健康保障数据和第二部分健康保障数据。

42.根据权利要求41的健康保障数据传送系统，还包括：

消费者健康保障应用，其操作性地连接到所述健康保障数据访问服务，并被配置为访问第一部分健康保障数据和第二部分健康保障数据。

43.根据权利要求42的健康保障数据传送系统，其中所述健康保障数据访问服务还包括以下功能性：从所述消费者健康保障应用接收与所述第一健康保障信息源相对应的第一认证信息和与所述第二健康保障信息源相对应的第二认证信息。

44.根据权利要求41的健康保障数据传送系统，其中所述健康保障数据访问系统向消费者通知第一部分健康保障数据和第二部分健康保障数据由所述健康保障数据访问服务存储。

45.根据权利要求41的健康保障数据传送系统，其中所述第一健康保障信息源是第一健康计划提供者，并且所述第二健康保障信息源是第二健康计划提供者。

46.根据权利要求41的健康保障数据传送系统，其中所述第一健康保障信息源与第一健康保障业务域相对应，并且所述第二健康保障信息源与第二健康保障业务域相对应。

47.根据权利要求46的健康保障数据传送系统，其中所述第一健康保障业务域和所述第二健康保障业务域中的每一个都是从包括以下内容的群组中选择的一个业务域：健康计划业务域、金融业务域、病人记录业务域、药品业务域、实验室业务域、医疗成像业务域、医疗设备业务域、提供者记账业务域、医疗研究/分析业务域、病人教育业务域、牙科业务域、视力护理业务域、备选医疗业务域、体能业务域、理疗业务域、康复业务域、辅助护理业务域、实践管理业务域、和心理学业务域。

48.根据权利要求41的健康保障数据传送系统，其中第一部分健康保障数据和第二部分健康保障数据中的每一个都是从包括以下内容的群组中选择的至少一个部分：成员数据、医疗要求数据、药品要求数据、利益限制数据、覆盖范围数据、累积器数据、提供者数据、和基本保障提供者数据。

49.根据权利要求41的健康保障数据传送系统，其中所述健康保障数据访问服务还包括通过以下动作来接收第一部分健康保障数据的功能性：

向所述第一健康保障信息源发送请求消息，所述请求消息包括与获取数据请求相对应的动作标识符以及与第一部分健康保障数据相对应的标识符；以及

从所述健康保障信息源接收与所述请求消息相对应的响应消息，所述响应消息包括第一部分健康保障数据。

50.根据权利要求49的健康保障数据传送系统，其中所述动作标识符标识从包括以下内容的群组中选择的健康保障数据传送协议方法：获取主题数据、设置主题数据、获取目录数据和设置目录数据，并且其中第一部分健康保障数据是从包括主题和目录的群组中选择的一个部分，其中所述主题和目录包括与所述健康保障信息源的健康保障业务域中的健康保障数据相对应的数据结构。

51.根据权利要求41的健康保障数据传送系统，其中所述健康保障数据访问服务还包括通过以下动作来接收第一部分健康保障数据的功能性：

从所述第一健康保障信息源接收请求消息，其中所述请求消息包括与设置数据请求相对应的动作标识符、与第一部分健康保障数据相对应的标识符、以及第一部分健康保障数据，以及

向所述第一健康保障信息源发送与所述请求消息相对应的响应消息。

52.根据权利要求41的健康保障数据传送系统，其中所述健康保障数据访问服务使用遵循健康保障数据传送协议的消息接收第一部分健康保障数据和第二部分健康保障数据。

53.一种健康保障数据访问服务，包括：

健康保障数据库，其被配置为存储与多个消费者相对应的健康保障数据，其中从多个健康保障信息源接收所述健康保障数据；以及

健康保障数据导入部件，其被配置为使用遵循健康保障数据传送协议的消息从多个健康保障信息源导入所述健康保障数据。

54.根据权利要求53的健康保障数据访问服务，其中所述健康保障数据传送协议包括：

请求消息，用于请求与一部分健康保障数据相对应的动作，以及

与所述请求消息相对应的响应消息，用于返回执行所述动作的结果，

其中所述动作是从包括以下内容的群组中选择的动作：获取主题数据、设置主题数据、获取目录数据和设置目录数据，以及

其中所述部分健康保障数据是从包括主题和目录的群组中选择的一个部分，其中所述主题和目录是与对应于多个健康保障信息源的多个健康保障业务域中的健康保障数据相对应的数据结构。

55.根据权利要求53的健康保障数据访问服务，其中多个健康保障信息源中的每个健康保障信息源与从包括以下内容的群组中选择的健康保障业务域相对应：健康计划业务域、金融业务域、病人记录业务域、药品业务域、实验室业务域、医疗成像业务域、医疗设备业务域、提供者记账业务域、医疗研究/分析业务域、病人教育业务域、牙科业务域、视力护理业务域、备选医疗业务域、体能业务域、理疗业务域、康复业务域、辅助护理业务域、实践管理业务域、和心理学业务域。

56.根据权利要求53的健康保障数据访问服务，其中所述健康保障数据是从包括以下内容的群组中选择的至少一个数据：成员数据、医疗要求数据、药品要求数据、利益限制数据、覆盖范围数据、累积器数据、提供者数据、和基本保障提供者数据。

57.一种计算机可读介质，包括在所述计算机可读介质上实现的计算机程序代码，用于使得计算机系统在消费者健康保障应用与多个健康保障信息源之间传送健康保障数据，所述计算机程序代码包括用于以下的程序指令：

从多个健康保障信息源的第一健康保障信息源请求与消费者相对应的第一部分健康保障数据；

从第一健康保障信息源接收第一部分健康保障数据；

将第一部分健康保障数据存储在健康保障数据库中；

从多个健康保障信息源的第二健康保障信息源请求与消费者相对应的第二部分健康保障数据；

从第二健康保障信息源接收第二部分健康保障数据；

将第二部分健康保障数据存储在健康保障数据库中；以及

从所述健康保障数据库访问第一部分健康保障数据和第二部分健康保障数据。

58.根据权利要求57的计算机可读介质，其中通过消费者健康保障应用访问第一部分健康保障数据和第二部分健康保障数据。

59.根据权利要求57的计算机可读介质，还包括用于以下的程序指令：

从消费者健康保障应用接收与所述第一健康保障信息源相对应的第一认证信息；以及

从消费者健康保障应用接收与所述第二健康保障信息源相对应的第二认证信息。

60.根据权利要求57的计算机可读介质，还包括用于以下的程序指令：

向消费者通知第一部分健康保障数据和第二部分健康保障数据在所述健康保障数据库中。

61.根据权利要求57的计算机可读介质，其中所述第一健康保障信息源是第一健康计划提供者，并且所述第二健康保障信息源是第二健康计划提供者。

62.根据权利要求57的计算机可读介质，其中所述第一健康保障信息源与第一健康保障业务域相对应，并且所述第二健康保障信息源与第二健康保障业务域相对应。

63.根据权利要求62的计算机可读介质，其中所述第一健康保障业务域和所述第二健康保障业务域中的每一个都是从包括以下内容的群组中选择的一个业务域：健康计划业务域、金融业务域、病人记录业务域、药品业务域、实验室业务域、医疗成像业务域、医疗设备业务域、提供者记账业务域、医疗研究/分析业务域、病人教育业务域、牙科业务域、视力护理业务域、备选医疗业务域、体能业务域、理疗业务域、康复业务域、辅助护理业务域、实践管理业务域、和心理学业务域。

64.根据权利要求57的计算机可读介质，其中第一部分健康保障数据和第二部分健康保障数据中的每一个都是从包括以下内容的群组中选择的至少一个部分：成员数据、医疗要求数据、药品要求数据、利益限制数据、覆盖范围数据、累积器数据、提供者数据、和基本保障提供者数据。

65.一种计算机可读介质，包括在所述计算机可读介质上实现的计算机程序代码，用于使得计算机系统在消费者健康保障应用与健康保障信息源之间传送健康保障数据，所述计算机程序代码包括用于以下的程序指令：

发送第一请求消息，所述第一请求消息包括针对执行与第一部分健康保障数据相对应的第一动作的第一请求；

接收与所述第一请求消息相对应的第一响应消息，其中所述第一响应消息包括执行所述第一动作的结果；以及

处理所述第一响应消息，

其中所述第一请求消息和所述第一响应消息遵循健康保障数据传送协议。

66.根据权利要求65的计算机可读介质，其中所述第一动作是从包括以下内容的群组中选择的动作：获取主题数据、设置主题数据、获取目录数据和设置目录数据，并且其中第一部分健康保障数据是从包括主题和目录的群组中选择的一个部分，其中所述主题和目录包括与所述健康保障信息源的健康保障业务域中的健康保障数据相对应的数据结构。

67.根据权利要求65的计算机可读介质，还包括接收与所述健康保障信息源相对应的认证信息的程序指令。

68.根据权利要求65的计算机可读介质，其中所述健康保障信息源与从选自包括以下内容的群组的健康保障业务域相对应：健康计划业务域、金融业务域、病人记录业务域、药品业务域、实验室业务域、医疗成像业务域、医疗设备业务域、提供者记账业务域、医疗研究/分析业务域、病人教育业务域、牙科业务域、视力护理业务域、备选医疗业务域、体能业务域、理疗业务域、康复业务域、辅助护理业务域、实践管理业务域、和心理学业务域。

69.根据权利要求65的计算机可读介质，其中第一部分健康保障数据是从包括以下内容的群组中选择的至少一个部分：成员数据、医疗要求数据、药品要求数据、利益限制数据、覆盖范围数据、累积器数据、提供者数据、和基本保障提供者数据。

70.根据权利要求65的计算机可读介质，其中所述第一请求消息包括将所述第一动作标识为获取数据请求的动作标识符、和与第一部分健康保障数据相对应的标识符，并且其中所述第一响应消息包括第一部分健康保障数据。

71.根据权利要求65的计算机可读介质，其中还包括用于通过将第一部分健康保障数据存储在健康保障数据库中来处理所述第一响应消息的程序指令。

72.根据权利要求65的计算机可读介质，其中所述消费者健康保障应用从所述健康保障数据库访问所述部分健康保障数据。

73.根据权利要求65的计算机可读介质，其中所述第一请求消息还包括搜索准则。

74.根据权利要求65的计算机可读介质，其中

所述第一请求消息包括将所述第一动作标识为设置数据请求的动作标识符、与第一部分健康保障数据相对应的标识符、以及第一部分健康保障数据；以及

所述第一响应消息包括从包含确认和异常的群组中选择的一个。

75.根据权利要求65的计算机可读介质，还包括用于以下的程序指令：

接收第二请求消息，所述第二请求消息包括针对执行与第二部分健康保障数据相对应的第二动作的请求；

执行所述第二动作；以及

生成与所述第二请求消息相对应的第二响应消息，其中所述第二响应消息包括执行所述第二动作的结果，

其中所述第二请求消息和所述第二响应消息遵循健康保障数据传送协议。

76.根据权利要求75的计算机可读介质，其中所述第二请求消息包括将所述第二动作标识为获取数据请求的动作标识符、和与第二部分健康保障数据相对应的标识符；并且其中所述第二响应消息包括第二部分健康保障数据。

77.根据权利要求76的计算机可读介质，还包括通过从所述健康保障数据库取回第二部分健康保障数据来执行所述第二动作的程序指令。

78.根据权利要求75的计算机可读介质，其中所述第二请求消息包括将所述第二动作标识为设置数据请求的动作标识符、与第二部分健康保障数据相对应的标识符、以及第二部分健康保障数据，并且其中所述第二响应消息包括从包含确认和异常的群组中选择的一个。

79.根据权利要求75的计算机可读介质，还包括通过将第二部分健康保障数据存储在健康保障数据库中来执行所述第二动作的程序指令。

Images