HL7 servers in Python?
rbsharp at gmx.de
Tue Jun 17 17:49:30 CEST 2003
I'll keep this general since not everyone is interested.
1. Whilst receiving the messages I don't do any parseing at all. Breaking
down HL7 is really for all practical purposes trivial. It is a collection
of separators, one for fields and one for components and so on. So you can
get the data out of a HL7-Message basically using split. I don't parse the
data until I can process it and that is done in a separate process. This
has always proved to be a good thing, because I can stop the processing
and correct something without worrying about data loss.
What does vary is the packaging of the data, but the basic pattern is some
start character (usually chr(11)), data consisting of records separated
usually with chr(13) and then an end character (chr(28)) and a stop
character (chr(13)). But this can vary from system to system. What
constitutes an ACK or a NAK is also quite different at times
2. I am (was) stuck with Python 1.5.2 because I have to link Python
against a static unify database library and bind in some external
C-Routines. This was not quite trivial and I had to play about with SWIG
for a while, but now its routine. I mostly confused my self with Python
2.2 and had to understand the build process. At the end my interpreter
still crashed, and I despaired, but the reason was a bug relating to
shared memory segments in the database library. But it is still an issue
updating ca 25 to 30 Installations with 2 MB of Python, many of which
still only have a modem.
By the way, an earlier version of Twisted blocked SCO Machines. After a
while nobody could log in any more. I installed the newer version and the
problem went away.
3. I use Twisted to serve a variety of transport needs. Basically the
Information I send or receive is Ascii data, only I and the receiver
really know what is in there. What we do have to agree on how the data is
to be transported. Whether over sockets, per FTP or a mounted
NFS-directory. If the means of transport is not available, then I need to
be able to keep retrying until I succeed. I need to be able to serve
several sources and several destinations, each of which can be
individually configured. I could be receiving data over NFS and sending
For Sockets I "hang" them in to the select loop. I differentiate according
to direction. Incoming data is handled by calling the TCPListen method of
the application und outgoing data by creating an instance of tcp.Client.
With tcp.Client I had some difficulties handling connections that come and
go. If the connection was dropped I had to delete the Client and recreate
it and then reestablish the connection
FTP and NFS are dealt with by quite simply creating a Job Manager that is
repeatedly called using reactor.callLater(5,<JobManager>). The Job Manager
maintains a queue of objects where it repeatedly calls generic methods,
like put and get.
There may be better ways of doing things, but it worked and has been
working for some time now.
On Mon, 16 Jun 2003 17:05:46 +0000, Moshe Zadka wrote:
> On Mon, 16 Jun 2003, "Richard Sharp" <rbsharp at gmx.de> wrote:
>> I have one Pathology Unit that does work for two hospitals and
>> communicates with two hospital systems. With Twisted I basically
>> subclass protocol.Factory and implement the necessary submethods.
> You probably also needed to subclass protocol.Protocol to actually parse
> HL7, right?
>> It is a little daunting at first and there was at the time (about 2
>> years ago) when no usable documentation worth speaking of was
>> available. I am also stuck at the moment with Twisted 0.18.0, because
>> it runs with Python 1.5.2, and I had trouble getting Python >= 2.0
>> running on the all the Unixes I had to get it running on. In the
>> meantime, I think I've got that under control.
> Ugh. Current Twisted (1.0.5) needs Python 2.2. Python is pretty
> portable, I've managed to build it (back when I needed to) on pretty
> wierd unices. Sometimes you want to install gcc because the compiler
> that comes with the system is damaged :(
> If you are having serious problems building Python, you're better off
> asking here (giving all the details about your platform) than using
> Twisted 0.18 (which was not a horribly good version, IIRC -- I kinda
> liked 0.15.5 I think).
>> If you're interested in looking at the programms I will have to ask the
>> company I developed the software for, but the complete program is only
>> ca. 800 Lines and covers 4 Low Level Protocols.
> If you get permission to put them up, that would be even better :) As a
> Twisted developer, I keep hoping that people will implement Protocols
> for Twisted as the standard way of having Python support a network
> protocol (rather than, say, asyncore) but except for ldaptor, I don't
> think there have been many 3rd party protocols.
More information about the Python-list