第二部分：通用资格服务实现
第四章：
通用资格服务介绍
第五章：
查询发送者通道
第六章：
HL7v2 to HL7v2
转换器通道
第七章：数据记录器通道
第八章：
HL7v3
校验通道
第九章：
应答发送者通道
第十章：
HL7v3 to HL7v2
转换器通道
第四章：通用资格服务介绍
这部分完全是假想的资格服务实现。这么做的原因是替代了业务或临床需求，比如病人管理
ADT
，医嘱信息
ORM
（通用订单信息），检验报告
ORU
（主动观察消息），上面这些你可能已经知道了，而他们全部集成在
Mirth Connect
功能上。
注意：我们开始前，我要强调在这里显示的交互和消息并不代表真实的实现，不应该直接使用。
.
资格服务介绍
资格服务由医疗健康部门使用，查询病人是否在有效期内有支付的资格。一个可以期待的答复是，根据病人是否有保险资格给出答案：是或否。这个答复也可能是个特定的代码和提供澄清病人状态的附加信息。
给你提供一个真实场景怎样工作的范例，我会引用来自
HL7v3 Normative Edition 2014
的一个故事。你也能通过
HL7v3 Standard>Universal>Eligibility Topics>Storyboards
找到原著。
当一个病人造访验光师时，确定这个病人是否享受眼镜片福利。验光师会询问病人是否有眼镜使用的扩展福利计划。病人往往确定不了，但是他们认为通过保险公司有某种扩展资格。病人查看钱包，事实上，就是一张扩展福利资格卡，卡上含有计划
ID
，团体保险号，被保险人身份正号，姓名和捐助及到期日。
验光师询问病人是否愿意让秘书确认是否享受保险公司提供购买眼镜片的扩展福利资格。病人明确表示可以，因为他们想知道购买眼镜片是否在这个计划下，如果不在，那么，病人这次就不能购买眼镜片。
秘书通过病人特定识别码，姓名，
DOB
查询扩展福利计划，即通过病人的福利资格卡查询计划细节，帮病人询问眼镜片是否在这个计划下。答复指明，一个每
2
年最高限额
$300.00
的眼镜片购买资格福利告诉了病人。病人立马意识到可以买副眼镜了。然而，保险公司的费用承诺并不是购买眼镜支付费用的承诺（向保险公司提出申请购买眼镜的费用，实际上是保险索赔）。这一点，像我国医院的报销制度，居民拿一部分，国家拿一部分，但你得有资格享受国家的这项政策，比如：你不缴纳社保，估计是没有退休金的。
.
场景概述
故事中秘书的行为就是使用发送者应用提交查询到保险公司端的服务应用，并接收保险公司的信息答复。这个场景，更加切合的描述为交互模型，例如接下来的创建、提交、处理资格查询的处理过程。
.
交互模型
下面，我们使用序列图，描述两个应用之间资格服务的交互模型：
为了增加交互模型的复杂度，临时添加了把进来的
HL7v2
查询消息转换为
HL7v3
查询消息步骤，以及相反的步骤。
.
应用角色
本章应用角色并不是
HL7
标准应用角色的定义。因此，需要一个这样的应用，使用
HL7v3
请求消息校验病人是否有保险资格或在
HL7v3
项目中有特定的名字
FICR_AR021001UV01
。然而，下面的应用角色会影响我们以后实现的通道名字。
* Sender:
创建
HL7v2
查询消息发送者启动的一个请求。消息被发送到
HL7
转换器处理。发送者也接收和处理响应消息。
* HL7 Transformer:HL7
转换器接收发送者的查询，校验查询并把它转化成
HL7v3
查询消息格式。新的构造消息发送给服务。
HL7
转换器也接收来自服务的响应。
HL7
转换器也记录
HL7v2
消息结构校验失败的信息。
* Service:
服务接收查询消息，分析和处理消息，查询数据库，形成响应消息，发送给
HL7
转换器。跟
HL7
转换器一样，服务也记录
HL7v3
消息架构校验失败的信息。
尽可能的尝试给定场景范围内更多的功能，资格查询交互模型的实际实现可能超出这三个应用角色（就是通道）。
.
消息和交互概述
HL7v2
标准把消息定义为两个系统间数据交互模型的必要部分。每个消息由消息类型和触发器事件
(
就是特定识别消息的函数
)
来确认。消息体是由预定义顺序的一组片段组成。
类似的，
HL7v3
标准把交互定义为：特定消息类型（信息传递）、启动或触发转换的特定触发器事件，与交互凭据关联的接受者职责之间的一个特定关联。简单点儿，就是触发器事件与接受者之间的关联互动。
由于两种标准的不同，所以
HL7v2
是通过消息类型和触发事件来展现，而
HL7v3
通过交互名称来展现。
场景实现使用的消息：
* QBP^E22
——
HL7v2
查询授权请求状态——提供者使用资格查询请求消息查询授权请求或在授权请求里特定产品
/
服务行项的支付者。
* RSP^E22
——
HL7v2
授权请求状态查询应答——支付者使用资格查询应答消息把响应提交给提供者（就是提交
QBP^E22
消息的提供者）。
* QUCR_IN200101UV01
——
HL7v3
资格查询请求通用——这个消息请求病人服务资格的状态。
* QUCR_IN210101UV01
——
HL7v3
资格查询应答通用——这个消息被当做一个提供关于病人资格服务的应答。
即使消息对的目的是相似的，也不意味着它们的内容有很好的相似度。有些字段在另一个消息对里没有关联，在消息对键传递信息也可能产生数据丢失。
.
这个查询通道概述在
Mirth Connect
里有许多方法完成同样的任务。下图演示了本书这部分的游戏计划（见图
4-1
）。主要的思想不是实现一个正确的服务，但是尽可能多的曝露
Mirth Connect
的选项。
模拟向服务发送资格查询请求，并接收返回来的应答：
* Query Sender
——担当处理和把原始的
QBP^E22
消息送入管道，该管道使用
MLLP(
类似于
Socket
协议层通讯
)
消息传输协议。
* v2-v3 Transformer
该通道是转换器的角色，接收
HL7v2
请求消息，校验它，创建
HL7v3
消息，并把数据从
HL7v2
映射成
HL7v3
消息。如果接收到验证失败的消息，由数据记录器执行记录此错误。
* v3
校验——这个通道接收
HL7v3
请求消息，校验它，分解它，并把数据存进数据库。如果接收到校验失败的消息，由数据记录器执行记录此错误。
* Response Sender
——扮演服务的角色。周期性的查询数据库，根据从数据库拿到的数据，创建
HL7v3
响应消息，并通过
Web Service
，发送消息给查询发送者。
* v3-v2 Transformer
——这个通道扮演转换器的角色，处理
HL7v3
应答消息，创建
HL7v2
消息，把数据从
HL7v3
映射成
HL7v2
消息，并把
RSP^E22
消息结果存成文件。
* Data Logger
——接收产生校验错误的消息，并错误细节存于日志文件里或数据库里。
图
4-1
资格查询服务通道架构
整个实现过程里，我们会看到各种连接器：
Channel Reader, TCP/IP Listener
和
Sender ,Database Writer, Reader, Web Service Listener
和
Sender, File Writer
。
我们会用到本书先前学到的所有技术，包括但不限于过滤器、转换器、代码模板、全局和通道脚本。
在这一点上，假设你已经非常熟悉
Mirth Connect Administrator
了。
.
推荐的工具和包
为使开发比较容易，不乏味，这里有工具和包的推荐列表。他们当中的一些，在先前特定通道实现上已经被安装了，例如
PostgreSQL
。
§
HL7v2
视图器，比如：由
Inner Harbour Software
出品的
HL7Spy
§
HL7v3
视图器
比如：由
Altova GmbH
出品的
Altova XMLSpy
§
MS Access
和
MS Access ODBC
驱动器
或者类似的数据库（包含驱动）
§
PostgreSQL
或
Mirth Connect
支持的数据库
§
JDBC Level 4 driver for PostgreSQL
或已选数据库驱动
§
由
Philip Helger
提供的
phLOC Schematron java
库。
