关于构筑一个HL7的网关系统以及HIS组件的构想。（请提意

arbol

GOOD ,但是，有几个方面我不清楚。
1。用WEB方式的话，在医院之间的连接事实上很难城里。
2。我想问一下HL7定义了DTDS，有没有定义XSL的东西。我对这个是初学者，还望告知。
在UNIX/LINUX下，对XML的解析，有什么好的对C/C++，我刚DOWN了一个ORACLE 的解析器，但是是对SCHEMA做的，那么他能解析HL7的DTDS文档吗？
望大家帮忙

sbf2000

1.医院间通讯一般都有一个前置服务器，可用来做Web服务。
2.HL7 V3用的是schema， 一般来说，旧版软件支持DTD，新版软件同时都支持DTD和schema的。
3.XML解析最多的是JAVA，网上很容易找到的。

arbol

1.WEB有它自身的弱点，慢，HTTP协议与XML结合应当是很好的，但是还是很慢，而底层中间件的长连接是很快的，大型企业（银行，石油，石化，电信等）都用中间件来做，对于医院来说，前置机是必要的，就相当于一个网关的作用，互相访问也不可能直接就到数据库上，这样安全性很低的。
2.我有了DTD的东西，到哪里才能得到HL7 V3的schema.
3.我对JAVA不熟悉，下的ORACLE的XDK有FOR标准C的，并且，如果做中间件，在UNIX下也可能采用C/C++来实现。
4.是不是对于XML解析开发包一般都有对XML数据流读取，分析，和输出内在数据的API接口函数，以及和把从数据库查到的东西打包成XML结构？
望告知？

sbf2000

1.HL7 V3 schema可以到http://www.hl7.org/v3ballot/html/index.htm中找到。
2.底层中间件速度可能很快，但可能不够灵活，适应性较差，Web服务还是有优势的。
3.XML解析有很多通用软件，没有必要重做，网上找找，肯定有的。可以在一些开源软件网站上找找。

ironstone

我想最主要的问题并不是在于通讯，而在于标准应用，虽然 arbol 说并不在乎理论上的东西，而希望具体的实现，但实际上考虑一下在国内银行系统实现互联之前，每个银行系统的银行卡并不是可以相互结算的，在商场的终端需要摆上数台pos机才能实现和不同银行卡和商场的结算。那个时候相信银行系统就已经实现全国联网了，但为什么不能实现相互之间的电子结算，我想这并不关系到底层的通讯到底是试用长链接还是其他的链接方式，而在于不同银行之间所采用不同的数据结构和系统架构。
而同样的对于HL7来说，更多的是在于实际应用，至于通讯消息方面， arbol 所说的通讯平台，在windows系统下，有微软的biztalk server可以作为一个典型的应用示范。HL7中间件是可以架设在biztalk server建立的消息平台之上，而不用去管理底层的通讯。美国有一家公司的HL7产品就是基于biztalk来开发的。
对于简单的HL7应用，诸如目前国内阶段需要解决的HIS与PACS，医嘱处理系统与HIS计费系统之间的消息传递都是相对比较简单的消息传递，这些消息的处理可以直接利用字符消息进行处理，的确不需要这么复杂。
同时我认为开发unix下的HL7中间件的在国内是没有什么实用意义，当然要是作为毕业论文当另当别论。同时，考虑在全国范围内实现医院，甚至是说一个城市内医院与医院之间进行信息交换的实际意义。这并不如同银行一样需要实时处理的，因此医院与医院建立一个长链接的目的是干什么？他们需要传递什么样的消息？
技术研究是应该的，但去研究没有实际应用价值的技术，则只是浪费精力而已。不能简单的套用其他行业的经验，毕竟每个行业都有自己的特点，不了解这些特点而单纯的研究技术，很可能事半功倍

arbol

就上述问题做回答。
1。关于UNIX下开发的问题。事实上，微软的东西就是不尽人意。随着规模的扩大，服务器和小型机使用的时间一定会提上日程，而这些稍微高端的东西都是UNIX平台的。而且，在保证7*24服务上，WINDOWS很难做到，而UNIX是不允许频繁关机，设计之初就是长时间运行。对于医院来说，在紧急时刻，找不到患者的历史资料（有可能在其他医院）会耽误诊断机会，造成严重事故。
2。对于RIS/PACS的开发，以及医嘱的消息传输是不是很难，但是，如果现在只想到这些东西，而忽视系统平台的搭建对产品来说是很没有远见的。以后卫生部如果突然要求HL7全国医院推广（当然，肯定先做试点），我们其不是有要开发，那么现在开发的东西感觉有点浪费，如果现在早想的到。
3。医院建立长连接是为了患者着想，快速的传递患者的资料。
4。技术的研究是本着应用，现在想银行，石化等也是用了八年才联网运行，但随着计算机技术的应用。医院联网的时间可能会很短就实现。现在不考虑以后的价值，等到到时匆忙去考虑，还不如现在考虑清楚（当然不可能完全清楚），以后有了部分的产品，再优化岂不更好。
其实，UNIX/LINUX下的研究以及思想快速称为产品，然后使用，再反馈，再修改这些东西是需要马上提上议程了。

ironstone

1、对于unix下的开发，从技术上考虑也许是这样的，但是在全国看来是否有从事unix系统下的医院软件开发的厂商，此外医院内部能够雇佣或者能否留住足够的unix系统管理人员？
2、对于医院来说，在紧急时刻，找不到患者的历史资料（有可能在其他医院）会耽误诊断机会，造成严重事故。这一点，其实不用担心，在紧急时刻的医疗处理成功与否取决于医生的临床经验和判断，医生当时的处理判断是依据当前的患者资料，而不是患者的历史资料，在医院内只有紧急处理的情况发生，而不会有根据历史资料进行紧急诊断的事情，所谓的造成严重事故的说法不成立
3、医院之间会在什么样的情况下进行资料的传输呢？一般是在转院、转诊的情况下需要进行资料的传输，而这样的传输都是一过性的，比如pos机刷卡时传输给中心一下数据，然后接收回来的数据。所谓的快速传递患者资料的意义是为了什么？
4、我的意思并不是说忽视系统平台的作用，当一个医院内存在多个需要相互传递消息的系统，而不是象RIS与HIS之间这么简单的传递的时候，就已经需要考虑通讯平台的处理，单目前来说最实用，对医院来说最简单最经济最方便的解决方式是什么?另外说一句：卫生部是很难干出突然要求用HL7来进行全国医院联网的事情的，医疗行业的行政复杂程度远比其他行业要复杂，而且卫生部门也正在由办医院向行政管理的管理医院的角色转变，当然几个医院之间的链接要求也是可能的，比如医疗集团就可能有这种要求
5、我并不反对快速形成产品，但是考虑一下你形成了unix下的产品，和现在那个系统去使用？如何和这些都在运行windows的开发的his进行链接？你这样的中间件让windows系统如何操作呢？如果没有使用，那会有什么再反馈和再修改？更谈不上提上议程了
我希望我们的讨论能够足够深入，也算是让各自的想法思路更加明确和清晰

arbol

1。是这样的，我的开发可能在SCO、SOLARIS、LINUX上进行，因为PC上只能跑这些，以前都是在小机上做的。随着医院的规模和信息量扩大，WINDOWS可能有负担不起的能力，所以，以后就像国外一样，大部分都在UNIX下跑，当然，这需要一个过程，但现在做也是为以后考虑，在UNIX开发的这个通讯平台，同时，在WINDODS下也需要开发同类产品，基于X/OPEN的标准，这样大家的联通就不成问题。
2。看了台湾的很多解决方案。例如电子病例中心以及区域医院互联等等，他们的网状结构基本上需要一个开放的通讯平台来解决，相信他们也是这样做的。其实看了他们的解决方案和现在内地的银联解决方案的网络架构很相似，都有区域中心的概念存在。如果以后内地建成区域电子病例中心等，相信他们考虑的肯定是小机下的UNIX。
3。医院之间的联系现在可能很少，但确实如你所说，医院的内部可能单独跑了很多的系统例如PACS/RIS.LIS等等。这些系统之间的联系在通讯上各自独立，他们的联系的结合不能以紧密来做，开放的X/OPEN标准中，可以找出通讯中间件来联系处理信息的交互，其实，收到信息怎么做，就看各个系统的模块的设计和实现了。

arbol

1。确实相对于windows，unix的管理人员比较欠缺。这是一个问题。但要找的话也可以找到吧。人力这方面的投入是必须的。
2。对于目前所说的这些一次性的传输，通讯中间件体构FTP的函数调用，只要调用这个函数，就可以从目标主机和源主机之间用FTP来传输文件。但对于通讯应用应尽可能支持。这是个平台的问题。
3。就我所知，国内现在有一些UNIX/LINUX下的医疗PACS/RIS/HIS/CIS/LIS的软件，而且实际也早在应用。
4。我们应该更多的讨论，这样大家的思路会更清晰。

tong

在医疗行业的计算机系统里，Unix应该有它的一席之地的。虽然现在的Pentium或者Xeon系统已经相当powerful，但是还是不能和UltraSparcIII相提并论的。再说Unix系统还是比Windows稳定。在像中国这样的人口大国里，系统一旦运行起来，其负荷是会很重的。当然，这取决于“系统”的定义，以及它的功能。系统可大可小，功能可繁可简。在受财力条件限制的情况下，系统设计时硬件配置的性能是个很重要的考虑因素。Ironstone的看法就有医院财力不够的意思。至于Unix开发商，只要有市场需求，他们就会出现。
在Unix上，SUN和IBM都把网络应用的开发技术和工具的重点放到了JAVA上。虽然C/C++运行的更快，但是如果没有好的技术支持，开发是比较费时的。另外，开发了但没能广泛使用，没成为标准，就有被淘汰的可能。
医院之间的信息交流量现在看来不大，这是因为现在的系统的局限性。也因为现在医院的经营模式。HL7的开发就是为了要使系统间信息交流更容易。至于这种交流是否应该具有实时性，则取决于功能设计。理想情况下应该是实时的，或接近实时的。
说起系统硬件配置，我对于国内的情况了解甚少。大家是否能介绍一下大概的情况？没有高性能的硬件和网络支持，系统的开发是会很困难的。功能也会因此大打折扣。

arbol

对，我也认为小机（大机估计不行，IBM的那种大机估计医院不会采购）对于医院来说，还是可以接受的，这时，基本来说，应该是双机热备加磁盘阵列加磁带库。实时性和存储安全性都要考虑。国内的大医院应该有这些配置吧。
关于语言的问题。首先JAVA是很火，但是C/C++在UNIX本身还是有它的特点的。和系统结合比较紧密，可以看看UNIX网络编程（stenve的经典）。但不可能要求所有厂商都用什么开发语言来开发。所以，这里比如建区域电子病例中心，那么通讯就可以选择了中间件了。IBM.HP.ORACLE.BEA大家的产品都可以互联。至于语言用什么，就看各自喜好了。
虽然医院现在信息交流量不大。但是，集成实时性网络还是必要的，至少以后医院肯定需要有前置机，那么和保险，金融，上级主观的通讯都由前置机出去，不可能直接跟主机连。以后还可以开展医院分支机构开到社区，开展社区医疗，网上医疗等等。
至于硬件的配置和采购。可以祈祷医院有一些开明和有远见的院长。还希望卫生部能有高效的效率和远见的规划。
我们向天空祈祷，或者对着RMB也行。

alexluo

HL7中说如果某医院只用一家公司的产品，其用处不大。我想HL7是大家设计实施系统时的参考，但完全按HL7标准实现一套产品，我也觉得需求不大。

乖乖兔

其实hl7并不只是在一家医院中使用,它也用于医院与医院间的数据交换.例如台湾的转诊标准.在一个医院中间使用一个厂商的产品也是不可能的,没有一个厂商可以提供医院中使用的所有软件产品.现在国内的情况和国外的情况是一个样的.国内的许多厂商号称拥有多个产品,但真正做好的没有一家.

arbol

这几天看了HL7的一些细节问题，遇到阻力比较大。计划设计事件触发，例如I12.REF/RRI的关键字判断。但是，还有，对于解析XML也出现阻力。我的解析器不能合适的解析DTD文档。正在郁闷中。
并且，由于没有合适的国内标准，参考了台湾的转诊标准。感觉现在还不能在HL7中做的太多，只能在外围的通信中间件和事件出发路由上做做，并且，对于HL7中DTD的描述还不清楚，相关变量的定义不知所措，大家多讨论了。

乖乖兔

你使用的那家公司的xml解析器呀?可以多找几家公司的试试!