开篇:Mirth Connect系统集成与数据交换引擎

Mirth最初的目的是作为HL7接口引擎('引擎'释意：IT方面的术语，指经包装过的函数库，方便别人调用；如搜索引擎、图形引擎、物理引擎等)，HL7 v2.x和HL7 v3标准通常在医疗系统间用于系统集成时的数据交换 - 包括但不限于临床，财务，后勤和管理信息。

平常我们做不同系统间的互联互通接口时离不开许多词法分析工具，并且深刻的了解编写和维护复杂接口协议解析器所要进行的繁重工作。

最简单地说，接口引擎充当两个系统之间的桥梁,源系统生成消息并将其提交给接口系统,接口系统转换并将修改后的消息发送到目标系统。

随着“互联网＋”浪潮的不断推进，越来越多的医疗卫生信息系统在医院被使用，各系统间数据的交换和共享显得越发重要。在传统医疗卫生事业中，各种医疗信息系统的开发商都是相对独立地研发自己的系统，具有各自独立的接口规范和数据结构，软硬件环境差异也很大，导致各系统之间数据传输共享困难，造成了医疗信息系统中一个个的“信息孤岛”，严重妨碍了信息的传递。在不改变原有医疗信息系统的原则下，通过设计集成引擎来实现数据在系统间的传输，这个过程要求支持多种传输协议，并能够在不同的信息标准下进行数据转换。 Mirth Connect 是用Java语言实现的 HL7 标准的接口网关，它是一个开源、跨平台的接口集成引擎，其作为一个跨网络、跨协议、支持应用与数据集成的平台软件，主要专注于医疗领域系统集成和数据交换，具有稳定、灵活、接口广泛等优点，可以很好地实现各应用系统之间的数据传输。

当前Mirth Connect的典型应用已经不再局限于医疗信息化行业，因为它的架构完全可用作消息传递系统中间件，该系统支持读取和写入数据库/FTP/SOAP/TCP/Local或网络共享文件/JMS/DICOM信道等。数据通过信道与至少两个端点(源和目标)交互（尽管单个源通道可以有多个目标通道），通过信道传递的数据可以使用SQL、Javascript和Java的组合进行过滤、映射、转换和路由。Mirth官方论坛上的大多数示例都包含非常简单的Javascript示例，但是底层是一个完整的Java API，允许实现更复杂的逻辑。[旁白：必须使用奇怪的混合语法创建Java对象，其中在声明Java类的实例时使用松散类型的变量。]

1.首先，这个产品并不容易入门，但它非常强大和灵活。(例如：当源目标发送一个版本的HL7，而收件人的系统只能处理较旧的HL7时，会发生什么？使用Mirth Connect，您可以即时转换HL7版本。)

2.Mirth Connect被称为医疗保健一体化的瑞士军刀（系统集成、数据交换），目标是为医疗保健领域提供安全、高效、经济的共享健康信息的接口开发工具，并简化其管理流程并满足监管需求。

3.就像翻译人员将外语翻译成您理解的语言一样，Mirth Connect会将接收到的原始消息标准转换为您的系统理解的标准。每当“外国”系统向您的系统发送消息时，Mirth Connect的集成功能将加速以下操作：

过滤 - Mirth Connect读取消息参数并将消息传递给转换阶段。
转换 - Mirth Connect将传入消息标准转换为另一个标准（例如，HL7转换为XML）。
提取 - Mirth Connect可以“拉”数据并将数据“推送”到数据库。
路由 - Mirth Connect确保消息到达指定的目的地。

4.在不卸载原有旧版本的服务器上，安装最新版本的Mirth Connect会自动升级以前的Mirth Connect安装（从1.5版开始）。

5.安装后，Mirth Connect目录布局如下所示：

/appdata/mirthdb：嵌入式数据库（如果指定DerbyDB作为数据库，请勿删除）。这将在启动Mirth Connect Server时创建。appdata的路径由mirth.properties中的dir.appdata属性定义。
/cli-lib：Mirth Connect Command Line Interface库（如果已安装）
/client-lib：Mirth Connect Administrator库
/conf：配置文件
/custom-lib：将自定义用户库放在此处。这些库在启动时将加载到Mirth Connect Server类路径中，使其可供通道脚本访问。
/docs：本文档和Mirth Connect许可证的副本
/docs/javadocs：为已安装的Mirth Connect版本生成javadoc。当服务器在http://[server address]:8080/javadocs/（即http://localhost:8080/javadocs/）运行时，这些文档也可用。
/extensions： Plug-ins and Connectors的库和元数据
/logs：Mirth Connect及其子组件生成的日志的默认位置
/manager-lib：MMirth Connect Server Manager库
/public_html：嵌入式Web服务器公开的目录
/server-lib：Mirth Connect Server库
/webapps：嵌入式Web服务器公开的目录，用于托管Web应用程序

6.初次安装默认用户名为:admin,密码为：admin 。从Mirth Connect 3.7开始推荐使用新工具Mirth Connect Administrator Launcher来启动https://localhost:8443地址以运行Mirth Connect Administrator来进行信道操作。

7.案例说明（翻译自：http://irwinj.blogspot.com/2008/10/mirth-is-open-source.html）

意识到我们的客户不太可能重新设计一个已经成功运行了十年的HL7系统，我放弃了使用Mirth的想法。然而，不久之后，一个有趣的挑战出现在另一个项目中。要求很简单：从SQL Server 2000数据库读取数据，将数据转换为XML（第三方XML模式 - 不仅仅是SOAP信封），并通过SOAP将其发送到第三方JSP Web服务。需要一些辅助功能模块（日志记录，消息审核，故障通知等），但核心要求非常简单。

显然，这个有一些解决方案：

1.使用.NET框架的Web服务API创建SQL Server CLR存储过程，以调用Web服务。

（参见：http://www.cnblogs.com/Brambling/p/8000911.html）

打开 Visual Studio 新建一个 SQL Server 数据库项目，这里需要注意 .NET Framework 的版本。

Microsoft SQL Server 2005之后，实现了对 Microsoft .NET Framework 的公共语言运行时(CLR)的集成。

CLR 集成使得现在可以使用 .NET Framework 语言编写代码，从而能够在 SQL Server 上运行，现在就可以通过 C# 来编写 SQL Server 自定义函数、存储过程、触发器等。

坦率地说，如果数据存在于SQL 2005数据库中，这不会是一个糟糕的选择。不幸的是，这是一个较旧的数据库，没有使用CLR的可能性。而且在我们的生产环境中强调数据库的隔离，因此不希望在单独的数据库服务器上链接其他服务器和调用CLR过程。而且这虽然在执行基本功能方面肯定是一种可行的方法，但是这种方法不易实现此需求关联的辅助功能模块（日志记录，消息追溯，故障通知等）。

2.创建扩展存储过程

这是SQL2005之前的方法，这样的扩展存储过程需要用C / C ++编程语言进行开发。

我们是.NET技术架构下的产品线，而且我们所有的开发人员使用.NET可以进行舒适和高效的编程。即使用C / C ++编程语言实现了这个功能模块，另外所生成的系统可维护性是一个关键问题，毕竟我们的团队是都不精通C/C ++编程语言。很难说解决这个问题后未来所要面对的一系列其他未知挑战，所以我们反对使用我们团队不熟悉的技术解决问题的这一个解决方案。

3.编写外部.NET应用程序以从数据库中读取并调用第三方JSP Web服务

这一个解决方案明显的负面影响是所需的时间投入。实现基本功能非常简单。但是创建一个健壮的接口系统其实并不容易。

最后我们选择使用Mirth Connect

使用Mirth实现上述场景的经验令人兴奋。第一次使用此应用程序时的第一印象是它的成熟度。显而易见，该产品已经过了开发生命周期的多次迭代，界面和功能（我敢说）是完全专业的。为了实现上述目标，我能够使用数据库读取器从我的SQL 2000数据库读取数据，同时利用SOAP发送器以将转换的数据传递给第三方JSP Web服务。SOAP Sender允许我指定第二个通道来处理从第三方JSP Web服务返回的信息。

启动和运行基本信道非常简单。数据库读取器允许我编写自己的SQL语句来从我选择的数据库中提取信息。SOAP Sender设置很简单，借助它很快就可以与第三方JSP Web服务进行通信。此外，日志和通知能力超过了我为这个项目设想的任何东西。Mirth Connect允许为特定信道和特定事件设置警报，并通过SMTP发送。仪表板（主Mirth屏幕）允许简单查看消息的统计信息、标记的错误消息以及接收、排队、发送和过滤的消息。双击仪表板上的特定（已部署）信道可以进一步深入查看失败消息的溯源。它允许在其生命周期的每个阶段查看消息，从收到的原始消息到发送第三方JSP Web服务的转换消息以及从第三方JSP Web服务返回的响应消息。仪表板（主Mirth屏幕）是一个非常宝贵的信息来源。

在我最初开始Mirth Connect的学习和使用时，最明显的缺陷是文档资料的缺乏。Mirth Connect背后的组织nextgen的特色之一就是提供专业的技术支持和服务；虽然我不会指责他们故意忽略用户报告的问题，但很明显（并且受到尊重）他们的目标不是支持非付费用户群体，而是更多地促进用户群体在问题解决方面变得自给自足。官方论坛确实是我在测试和解决问题阶段的主要信息来源，这也是官方提供的一个很好的用户间交流讨论的平台。关于Mirth Connect的社群似乎正在快速成长，我从未等待很久就收到了关于我报告的问题的建议/解决方案。官方论坛是并且仍然是更复杂信息的唯一来源（包括在Javascript中结合Java创建过滤器和转换!!!）。最近创建了一个新的论坛（链接）很好地涵盖了基础知识，我建议新人关注一下

结论

Mirth是一个了不起的应用程序，非常成熟。无论您的公司是否是在进行医疗信息系统的研发，您都可以使用它来进行数据交换接口的开发。

[Mirth Connect集成交换引擎简介]

Mirth Connect官网:https://www.nextgen.com/

随着医疗信息化进程不断推进，越来越多的医疗信息系统在医院得到使用，各种系统之间的互联互通、信息共享变得更加迫切。然而不同厂商的系统提供的信息访问接口、协议各不相同，给医院信息的集成与应用带来挑战。为了应对医院信息碎片化、孤岛化的挑战，需要一种支持各种接口、协议且稳定、灵活的信息集成交换引擎来连接医院不同系统，对系统间的信息进行交换、处理，以实现各系统间信息的互联互通与共享，Mirth Connect作用在此。
Mirth Connect是一款基于ESB总线架构的开源、跨平台、专门针对医疗信息领域的系统集成和数据交换引擎。Mirth关注的核心还在于基于医疗领域特定标准的接口转换，而不是提供一个SOA集成平台，因此mc提供了各种不同类型的源连接器和目标连接器以匹配各种不同的系统。Mirth Connect还支持HL7、DICOM、JMS、SOAP等多种协议。支持对信息进行转换、映射、过滤和路由等多种处理；支持读写数据库、读写文件、生成PDF文档、发送电子邮件等多种操作。

参考资料：

Mirth Connect是一种接口引擎。
什么是接口引擎呢？
医疗系统之间要进行连接，普遍需要采用一种合适的接口方式。
最普遍采用的接口方式是HL7标准，规定了数据传输的协议、格式、数据结构和语义。
所以，尽管开发医疗信息系统的厂商各不相同，他们的系统普遍需要提供HL7接口。
但是呢，一方面HL7标准太复杂，另一方面人工成本高。知识门槛和人力成本导致需要有更为方便的为各种系统提供HL7接口的中间件软件。
所以，一种叫做接口引擎的中间件应运而生，一方面对外提供HL7接口的模板，另一方面提供一个转换能力，用来实现将各个系统自有的接口模式转换为对外的HL7接口的逻辑。
下面用一些简单的符号解释接口引擎在交互中的地位：
{系统自有接口->[接口引擎]->标准HL7接口} <---->另一个系统
ESB已经是一种成熟的集成中间件形式。
所以大多数医疗领域的接口引擎都是基于ESB来构建，在ESB基础上进一步提供医疗领域特定的接口封装方式，也叫适配器。
比如：Mirth connect就是基于早期的Mule ESB，而随着Mirth Connect本身的发展，他们的Donkey分支与Mule本身的分支相距越来越远。
但是，与ESB提供的功能相比，Mirth核心的关注点还在于基于医疗领域特定标准的接口转换，而不是提供一个SOA集成平台。

HL7是特定于医疗保健的标准组织(官网:http://www.hl7.org/)，其主要重点是创建一组与医疗保健相关的国际消息传递标准，以支持应用程序和设备之间的互操作性和通信。这些消息标准可以分为三个主要的HL7标准版本，HL7版本2（v2）、版本3（v3）和快速医疗保健互操作性资源（FHIR）。HL7 v2.x标准是当今医疗保健行业中最常见的数据标准。