mirth connect 互联互通 第四章 通用资格服务实现 -欧洲杯足彩官网

`
ssunigate
  • 浏览: 6284 次
  • 性别:
  • 来自: 北京
最近访客
博主相关
  • 博客
  • 微博
  • 相册
  • 收藏
  • 社区版块
    • ( 1)
    • ( 0)
    • ( 0)
    存档分类
    最新评论

    mirth connect 互联互通 第四章 通用资格服务实现

    第二部分:通用资格服务实现

    第四章:通用资格服务介绍

    第五章:查询发送者通道

    第六章: 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库。

     

     

     

    • 大小: 26.7 kb
    • 大小: 48.2 kb
    分享到:
    评论

    相关推荐

      mirth connect 使用文档! 难得的一份!

      mirth connect可以进行hl7 包括构建和交换医疗保健信息的标准,以及系统集成和互操作性的其他标准。医疗保健系统可以使用这些标准、指南和方法以统一、一致的方式相互通信、共享信息和处理数据,有助于减少医疗保健...

      as mirth corporation (now is a subsidiary of quality systems, inc.) says on their web-site, “mirth connect is the swiss army knife of healthcare integration engines, specifically designed for hl7 ...

      mirth是现在国际上比较成熟的hl7引擎技术之一,它是一个开放源代码的跨平台hl7标准接口引擎,是专为hl7消息接口设计的“瑞士军刀”,它为开发、配置和监听接口提供了必要工具。mirth是一个hl7标准接口网关,它能进行...

      mirth connect在医疗信息集成中的应用

      mirth connect 3.4 使用文档,推荐下载!

      mirth connect 用户手册4.1.0

      mirth简单操作说明及常见报错,可以针对不会mirth的人一个基本的操作。要分不多,欢迎下载。

      yeovil区医院nhsft的mirth connect fhir侦听器通道,可与intersystems trakcare pas一起使用(v2020) 介绍 目的 此回购概述了为提供sider计划所需的技术可交付成果而采取的步骤,以及在开发过程中遇到的问题以及...

      way to run mirth connect with confidence in your organization. mirth appliances provide incredible value to any organization requiring heath information technology messaging capabilities. since mirth ...

      1.1 系统环境需求 4 1.2 启动服务器 5 1.3 启动管理员 5 2.1 登录 6 2.2 仪表板 7 2.3 通道10 2.4 编辑通道10 2.5

      mirth connect分析仪 报告书 听众 侦听传入连接的每个通道的列表。 channelname channelid servermode 主持人 港口 remoteaddress 远程端口 overridelocalbinding reconnectinterval receivetimeout 缓冲区...

      docker上的mirth connect实例 authors: marly cormar, surya prasanna, dileep rajput. 先决条件 最新的 。 目前的例子 这个多容器泊坞窗的目标是测试mirth connect的功能。 频道包括: json_to_hl7_dest_channel...

      此docker化版本的mirth connect配置为在平台上在nginx运行。 生成映像并使用以下命令在本地运行: docker run -i -t -d -p 3000:3000 -p 9661:9661 -e mirth_admin_pw=password image_name docker run -i -t -p ...

      医院端使用的集成平台 mirth使用说明,支持各种通讯协议,hl7,http,socket。支持各种数据库集成

      mirth手册 esb 医疗

      nextgen connect集成引擎(以前为mirth connect) 1.有用的链接 开发人员指南 示例和教程 fhir扩展指南 讨论区 松弛通道松弛注册 2.一般信息 下一代欧洲杯足彩官网的解决方案使命 nextgen solutions帮助美国许多最大,最受尊敬的...

      mirth3.9使用文档

    global site tag (gtag.js) - google analytics
    网站地图