HL7的应用理解

乖乖兔

同意tianma的观点，hl7并没有对通讯做具体的要求！只注重系统的数据交换的格式（当然也有其他方面）

arbol

大家理解错了我的思路，即使医院不是全国联网，那么医院之间总要联网的啊！无论同城，异城。那么，设计通讯的方式必不可少，楼上谈到的HL7中间件，我认为只是我思想中的一个HL7解析组件而已，而非整个系统架构，我的思路是建立底层的通讯，这个通讯可以是协议无关的。
希望支持同步和异步方式。同步方式是指用connect连过去，服务器端用fork一个进程来处理。异步是收到后放倒队列里，然后在做处理。
底层的思路想清楚了，比如提供几个系统接口，发送字符串，收到字符串等。
这时我们在来讨论对于HL7的解析和数据库方面的处理，即使一个医院内部，各个系统的整合利用中间件也是可以实现的，这样，通讯问题就解决了，剩余的精力可以放倒数据的处理方面。

tianma

    确实，设计通讯的方式必不可少。但它和HL7的应用没有关系，应该将通讯方式和HL7的应用分开处理。以避免丧失软件灵活性。
    HL7是开放式应用，对象并不限于同一类系统，应用双方的系统平台，甚至应用目的都可以不同，如医院和社会保险机构之间的数据交换。这一点和电信、银行的交易系统这类封闭的、统一的应用不同，搞专用的通信设计在这里是没有意义的。

乖乖兔

既然是通讯中间件就应该是和具体的平台以及应用环境无关，它只负责在各个系统之间的通讯。也就是负责将HL7消息打包并安全而准确的发送到目的应用。所以通讯中间件与HL7协议毫无关系！其实，abort已经注意到这一点了

jackie

各位讨论挺专业的，HL7中间件产品国内（含台湾）国外都已有现成产品，印象当中美国的一些HL7 solution provider的网站上还有试用版，希望想自己开发的人能少走弯路。如果想直接购买也成啊。
其实，做HL7中间件只是最简单、最易实现的方法，真正要做到全院系统整合，还需要有一个HL7的平台（姑且这么叫吧）。

乖乖兔

是的，的确还需要一个HL7产品的开发平台，不过平台是在各个中间件的基础上开发的。是各个相关中间件相互整合的结果。（当然，有的模块叫做中间件可能是不合适的，但姑且这样叫吧：））

arbol

现在回过头来想。其实利用底层的通讯中间件（协议无关，可单独采购，也可开发）来做通讯机制，在医院内部或者医院之间搭载一个传输字符串的大网。
在利用XML解析树来解析传到的XML字符串。这个解析模块可以放在各部门的数据库主机上，相互规范传递的消息触发，剩下的就是应用了。
其实，现在我们医院内部有很多数据库主机在跑，以后要是归到一台小型机了，那么解析机制就在这个主机内部实现并出发。通讯连接就只放到主机和这个医院的前置机上去和其他医院交换数据。
这样做基本可以规范流程和交换数据。形成一个HL7的开发平台构思。

乖乖兔

就我个人的观点来看,当前的所说的hl7平台的概念有点太大.现在的当务之急是实现hl7的核心模块(hl7消息的解析和构建).因为真正的建立一个hl7平台的话需要的知识太多,对于个人是很难完成的.开发好核心模块后,其他的各模块是在核心模块的基础上实现的.

arbol

是很有道理，但是我一着手就碰到了问题。我无法确定国内到底自己定义了那些DTD的格式。不能我们总是参考台湾的标准。国内有没有定义好的事件消息的XML格式。只有DTD肯定是不行的啊。

乖乖兔

对于hl7的核心模块来说,根本就不需要具体的消息的格式.因为只要给出的消息符合hl7标准,我们的hl7核心模块就应该能够正确的解析,我不知道你需要具体事件消息的XML格式做什么?只要找及格进行测试用就可以!!

arbol

不知道怎么来形成解析树，我来读取一个XML数据流，我采用什么办法把她解析出来。对于你们的核心模块是把所有的可能的数据结构都规划好了，一次读取事件消息就可以了，我现在困难是怎么利用解析器建立一个核心读取模块。
你们是怎么分析的。大体思路能不能介绍一下。

乖乖兔

现在不是有很多个XML的解析器吗?为什么不找几个测试一下.数据结构的定义是在开发数据交换系统的时候定义才定义好的,在开发的HL7工具中只要提供hl7消息定义的工具就可以了.然后通过hl7的核心模块来解析定义好的消息树就可以了.

乖乖兔

如果确实需要通过QQ或者e_mail联系我,我给你一个UNIX下的xml解析软件的原代码.不过支持xml不是太好,不过你自己可以添加其中没有的解析功能!

arbol

你给我发一份吧。我的e-mail你知道吧！
真是太感谢你了.

arbol

近来关注UNIX的通讯编写。来的少了。：）