gianni said But HL7 is a bi-directional protocol! What about receiving infos? A daemon or in general a program waiting on a port is needed and something outside Uniface is required... How have you solved this issue

  Here we have build 2 options in Uniface we can read HL7 filesOr a socket (created in .Net) that gets the HL7 messages and sends them to a Com exposed Uniface service (.dll) When we send out hl7 messages in files, there is no ACK / NACK. In socket mode we send and wait for a ACK / NACK message.

I don't think it exists, we have created it based on a HL7 definitions in records and takes the needed data and put it in a string variable (HL7 format). This string can be dumped in a file or send by socket

Thanks stcourth. I know HL7 is exchanging informations using XML streams. With current Uniface9 functionalities and a small integration sending via socket an XML properly structured is not a problem. But HL7 is a bi-directional protocol! What about receiving infos? A daemon or in general a program waiting on a port is needed and something outside Uniface is required... How have you solved this issue? Gianni

Hi Gianni, Wouldn't using a REST service via WAS do the job? Knut

Don't know that much about HL7 but I thought it only specified the format of the messages, not the method of delivery. There are several commercial HL7 interface engines for sale that can handle distribution and communication of the messages. To talk to them in Uniface you could use 3GL or Java call in/out, REST services that you build using DSP's, SOAP webservices or whatever. It al depends on the technical requirements of the interface engine. Or you could build your own specialized interface engine in Uniface, the requirements then depend on all the system that your engine needs to communicate with.