一、IHE简介

IHE(Integration Healthcare Enterprise)中文常翻译为集成企业医疗。IHE概念是由美国的医学专家和相关政府部门、信息技术专家和企业共同发起的，目的是提供一种更好的方法让医学信息系统之间更好地进行集成。1998年，RSNA和HIMSS两个组织牵头，组织有关学会和设备厂商共同建立了IHE。

IHE不是一个组织，是一个用户、厂商、以及顾问机构共同定义基于标准的医疗保健工作流程的国际合作。至今，IHE没有成立自己的组织，而是通过其发起单位HIMSS和RSNA开展活动，这就是为什么大家经常可以看到在RSNA期间举Connectathon测试或者在HIMSS期间会举办IHE Interoperability Showcase的活动。

以下都是IHE活动的一部分。

1.动员用户要求厂商寻求IHE方案(IHE教育);

2.通过Technical Framework定义和促进每年的增长目标;

3.IHE 通过RSNA IHE 网站促使厂商应用IHE方案(集成声明和成功故事);

4.提供标准测试工具使得厂商易于评估其一致性;

5.IHE在各种全球性的贸易展览中提供教育报告，如RSNA、HIMSS、ACR、ECR、SCAR、SPIE等;

6.通过与不同的国际卫生保健社团(如美国RSNA/HIMSS/ACC，欧洲COCIR，日本JIRA)合作，实现全球化的技术框架(Technical Framework)。

IHE的技术框架是一种详细的、严格组织的文档，这些文档提供了一种容易理解的指导，以便完成特定的系统整合。技术框架从系统交互的观点出发，把所有的医疗过程抽象成一个个子框架，每个子框架由一些医疗事务以及参与事务的多个独立功能单元组成。这些功能单元在子框架中被称为角色(Actors)。事务(Transactions)则定义了角色间交换的信息。IHE通过在角色间进行基于DICOM或HL7标准的数据交换，保证了系统的开放性和工作流程的自动化。IHE的技术框架的最终目的是企业间的集成。

IHE定义了放射、基础设施、实验室等技术领域，涉及几十个集成模式。

IHE强调系统或者角色时间的协同工作互动性。IHE的目标在于为医疗部门、企业、跨企业以及国家级的卫生保健体系提供卫生保健的协同工作方案，提高临床应用的效率(Efficiency)和效力(Effectiveness)，改善系统协同工作能力(Interoperability，互动性)，改善临床工作流程，改善图像质量和一致性，改善数据的准确性和可用性，降低运作成本(可复用电子数据输入)，通过IHE Technical Framework定义集成解决方案。用标准的解决方案替代私有的方案。IHE所提倡的是基于卫生保健标准(DICOM，HL7等)的集成。为了达成这样的目标，IHE确定了行动策略。而IHE的组织构架以及每年活动安排都与其策略是一致的。

二、IHE Connectathon

作为从事医疗信息行业的人，我们都知道IHE Connectathon的概念。IHE Connectathon是IHE举办的众多活动中的一种;它的目的在于通过实际测试加强厂商之间的互动交流，使厂商的产品能够最大意义上规范化，进而推动医疗信息的进一步发展。

这里简单地从以下几点来说明IHE Connectathon。

1.测试医疗设备互通性;

2.1999年始于北美;

3.每年在亚洲、北美和欧洲各举行一次;

4.促进医疗企业集成;

5.到今天，IHE Connectathon已经是一套非常完备的测试流程，每年都吸引众多厂商参与进来。

三、IHE-C

IHE-C是IHE中国的简称，意即中国版的IHE Connectathon，由中国医学装备协会等单位联合发起。IHE-C 2007年从上海开始，此后一直在北京举行，地点设在天坛医院报告厅。IHE-C每年举行两次，分别在三月份和八月份举行(个别年份会有所变化)。

1.IHE-C测试模式与角色

由于多方面原因，IHE测试的涵盖项目不能囊括所有的测试需求。截止到2012年，IHE-C所包含的项目包括以下几个方面：放射科工作系统专项测试(PACS系统IHE标准测试)，放射线(Radiology)领域，IT基础设施(IT Infrastructure)领域和实验学领域(Laboratory)。常见的模式和角色如下：

测试模式：

SWF，PIR，RWF，CPI，PDI，KIN，ED，PGP，ARI，SINR，CHG，PWF,XDS-I，PIX,PDQ，RID,ATNA等;

测试角色：

Order Filler

Image manager

Report manager

Report creator

PPSM

PIX consumer，manager，source

PDQ supplier，consumer

Evidence creator

Image display

Print Composer

Portable Media Creator

Portable Media Importer

Report Reader

Print Server

Modality等。

测试的说明中会对需要测试的角色作出说明，每个角色会有R/O/Z等几种选择。

测试的角色及流程是对具体业务逻辑的抽象，每个公司或者单位应该根据IHE的要求进行相应业务实现的调整以通过最后的测试。

2.测试软件—mesa

IHE为测试准备了预测试软件mesa，旨在帮助厂商进行前期开发以及后期调试并以此为基础参加IHE测试。IHE测试要求必须通过mesa测试才能参加现场互联，实际上mesa测试很水，糊弄过关很轻松。参加过IHE测试后，发现真正的收获在于对mesa的钻研以及进行实际产品的开发的帮助。

说实话，刚开始钻研mesa的时候一个头两个大。就自己一个人在钻研mesa的测试工作，其他人都在等着自己进行产品的开发，压力挺大。但最终依靠大家的鼓励和帮助熬过了艰难的准备过程，回头想想这个过程对自己的帮助很大。甚至心理有个想法，每个有意从事HIT的人员或者学生都应有这么一次从整体了解这个行业的机会，通过IHE这么一个平台，我们可以更好地了解业界，了解医疗信息的基础知识，了解具体项目的运作，了解未来的发展方向。

个人觉得与其说mesa是一个测试软件，不如说是强大的开发包，而且是集成了HL7、dicom以及ATNA等验证机制的全面的开发包。研究mesa的代码对我来讲是一个很大的提升，好多HIT底层的设计都可以从中得以验证。说实话大多数公司去参加测试时不过是为了测试而测试，毕竟IHE测试是设备之间的互联，是死的标准，真正的医疗信息化进程还要靠人的意识转变和推广。公司的开发一般会专门为IHE准备相应产品，实际在医院或者平台上应用的较少。所以IHE在中国的推广还有很长一段路要走。这种结果是多方面决定的，有技术层面的，也有人为方面的因素，毕竟这个东西是从老美那里开始的，他们的医疗业务流程跟国内有很多出入。举个简单例子，人家老美的写报告医生能配专门的记录护士，我们有么?呵呵!

Mesa的安装和配置是一个让人头疼的事情，IHE显然意识到了这个问题，而且在逐步改进。老版本的mesa有windows版本、unix版本，安装起来极其复杂。现在的mesa安装较为方便，将所有mesa测试相关的软件打包到一个虚拟机中，这想法挺好，最起码使用者省事了，不用对着一堆文档和软件发呆。目前提供的mesa打包只有linux版，自己制作过一个windows下的虚拟机，有兴趣的朋友也可以试一下。

Mesa中有bug，这是软件不可避免的问题，曾有幸和一帮国外的同行在谷歌SIG中交流，感谢研究IHE初期一个名为yaron的朋友的帮助。

3.mesa的使用

打开mesa测试软件，里面会有mesa的配置信息和使用时要用到的文件夹。关于mesa的具体使用文档可以去mesa的官方网站上下载：

http://ihedoc.wustl.edu/mesasoftware/15.x/dist/index.htm

这里也给出一个网页使用说明：

http://ihewiki.wustl.edu/wiki/index.php/Pre-Connectathon/MESA_Software#Index_to_all_domains.27_pre-connectathon_software

Mesa的使用是和perl脚本分不开的，这对mesa的使用来说既有好处又有坏处，总是觉得没有界面是mesa使用不方便的一个方面。而且测试中，你会发现由于一个小步骤的问题你不得不从头做一个测试N遍，然后不断的上下键，郁闷到吐血。

对大多数的测试者而言，我们常用的文件夹就是图中的mesa_tests，脚本、perl源代码，角色的配置等都在这里面了，storage也是我们常用的文件夹，这里会有测试中的中间文件产生，对我们后面的测试会有帮助。具体使用可以参考mesa的使用文档，看着网页版的测试指导，还是挺方便的。测试中遇到问题时，我们可以通过VS/VC对mesa代码进行调试，找到问题然后解决，这对自己的代码能力也是个提高。

顺便说一句，按照官方文档对mesa进行nmake时会有错误产生，但是在libsrc中会有相应的lib生成，加上库就可以对mesa代码进行调试了。mesa软件中自带的ctn库无法打开，研究了好久也没有结果。这个库貌似是3.1.0版本的。

Mesa的测试是一个郁闷的过程，不断的改，不断地调，测试的角色越多，越让人头疼，不过熬过一段时间会发现收获挺大。时至今日，IHE-C在中国的普及度越来越高，同时IHE-C颁发的证书已经成为医院采购设备和软件时的一项参考指标。

四、IHE测试体验

事实上，IHE测试的更大的作用不是实现了厂商之间的互相通信，而是开发过程中对业务对信息标准化有了更为深刻的认识。IHE测试的结果是厂商有两套软件，一套用来忽悠，一套用来实施。但是不得不说IHE测试是一件好事，信息化在进步，医疗软件开发在进步，这就足够了。

IHE测试现场是忙碌的，五天的时间紧张而充实。测试之前要有心里准备，最好可以咨询一下参加过测试的厂商。熟悉测试环境之后，就要开始搭建自己的测试平台，最好把自己家的配置信息写好，以便接下来和其他厂商沟通，测试现场的纸条是漫天飞。

测试伊始，最好有一个较为清晰的规划，有的放矢。如果任务实在多的话，还要想清楚保什么，舍弃什么。测试过程中也要积极主动地去和可以配合的厂家沟通，方便地情况下要尽量配合其他厂商的要求，因为它很可能就是你潜在的测试伙伴。与人方便，与己方便。

仔细保留每一次测试成功的日志，可以给每一个测试用例建一个文件夹，方便自己快速找到即可。有可能双方现场测试过程中出现了问题，而且现场无法解决，那么晚上酒店的联调不可避免，也要有所准备。

测试过程中关注现场发生的一些事情，那很可能给你接下来的测试带来帮助。别的厂商某个case的测试是否成功可以为你做这个case的测试提供经验，少走弯路就是节省时间，而在测试现场，时间就是效率，时间就是最后的成功。

五、IHE测试的明天

IHE测试目前集中在医疗系统、软件的互相通信，应该属于功能性测试范畴;以后的测试除了在横向上发展外，是不是纵向上也会有所拓展?比如，图像显示工作站阅片是不是能够满足医生诊断的需求，医疗软件的可用性测试等等。