(Migrated) HL7 on Zato?

(This message has been automatically imported from the retired mailing list)

Anyone out there trying this?

Any ideas, resources, pointers, general or specific, most welcome.

Thanks!

Trying what?

On Sep 22, 2014, at 5:18 PM, Samuel Rose samuel.rose@gmail.com wrote:

Anyone out there trying this?

Any ideas, resources, pointers, general or specific, most welcome.

Thanks!

Is anyone trying to implement HL7 v2 or v3 standard connections from
Zato to external systems http://en.wikipedia.org/wiki/Health_Level_7

On Mon, Sep 22, 2014 at 8:45 PM, Ivan Villareal ivaano@gmail.com wrote:

Trying what?

On Sep 22, 2014, at 5:18 PM, Samuel Rose samuel.rose@gmail.com wrote:

Anyone out there trying this?

Any ideas, resources, pointers, general or specific, most welcome.

Thanks!

FWIW in my case I resolved it was a best fit to just use either an
existing HL7 interface engine like
http://www.mirthcorp.com/products/mirth-connect or to use
http://hl7api.sourceforge.net/ or some readily available python HL7
parsers. These all act as stand-alone services, and Zato services
simply talk with these services.

On Mon, Sep 22, 2014 at 8:47 PM, Samuel Rose samuel.rose@gmail.com wrote:

Is anyone trying to implement HL7 v2 or v3 standard connections from
Zato to external systems http://en.wikipedia.org/wiki/Health_Level_7

On Mon, Sep 22, 2014 at 8:45 PM, Ivan Villareal ivaano@gmail.com wrote:

Trying what?

On Sep 22, 2014, at 5:18 PM, Samuel Rose samuel.rose@gmail.com wrote:

Anyone out there trying this?

Any ideas, resources, pointers, general or specific, most welcome.

Thanks!

On 23/09/14 02:18, Samuel Rose wrote:

Anyone out there trying this?

Any ideas, resources, pointers, general or specific, most welcome.

Hi Samuel,

I’m sorry but I couldn’t reply earlier.

I spent quite some time on an HL7-based project built on top of Zato and
I can share a few remarks. This was my first HL7 project.

The project’s original scope was to build an HL7 <-> Zato <-> SOAP <->
Zato <-> JSON interface.

Purely of business reasons this got greatly reduced but I did complete
the HL7 part - it was HL7 v2 (no XML) and the patient-related structures
I dealt with were to do with general symptoms as expressed through HL7’s
PID, PV1, ORC and OBX. Included were embedded RTF and plain text
attachments.

There are two major HL7 libraries for Python:

The former is way more object-oriented and allows you to navigate
through an HL7 document using dot notation, i.e. msg.msh.cm.

The drawback of hl7apy was that I couldn’t make it parse all of the HL7
documents I received prior to development - so even though it is much
more convenient, I could not really use it. And the project’s schedule
did not really allow for my taking it up with hl7apy’s maintainers so it
could be properly sorted out.

python-hl7 on the other hand requires one to index elements in HL7,
think ‘birth_place = msg.pid[0][22]’ for instance - this naturally
requires one to read HL7 spec a bit more closer but I’d say it’s not a
base big deal after a day or two. The advantage of python-hl7 is that I
had no problems with parsing and processing any of HL7 documents at all.

Given that I dealt with only a handful of structures, I ended up writing
a few utility methods in a base service other services inherited from,
i.e. I had methods like ‘get_attachment’, ‘get_patient’ and so on that
returned all the business data as Python dicts/bunches. It took a couple
of days but then the actual services were a piece of cake to develop.

I considered adding HL7 to Zato’s SimpleIO as a first-class citizen on
the same level as JSON or XML but then again - HL7 is a huge spec and
like I said, the project’s scope was capped. I don’t rule out that in
the future it might be added.

If you can, try to convince your HL7 vendor to use HL7 v3 - this will be
simply XML and will be an order of magnitude easier to read and deal
with than v2.

If it can’t be done, try to convince them not to use the default v2
separators - have them use ‘;’ or ‘,’ - this can be configured in MSH
and will make any sort of debugging much, much easier. That allowed me
to read HL7 directly with no GUI browser.

I’d say there is not much Zato-specific to working with HL7. You simply
need a library to parse it, turn into convenient Python structures as
soon as possible, and then it is regular Python development. There are
plenty of resources online regarding HL7 - this is a well worked out spec.

If you have with time any suggestions on how to have Zato ease the task
of working with HL7, please let me know, I’d be very interested in your
opinion :slight_smile:

On 23/09/14 02:18, Samuel Rose wrote:

Anyone out there trying this?

Any ideas, resources, pointers, general or specific, most welcome.

Hi Samuel,

I’m sorry but I couldn’t reply earlier.

I spent quite some time on an HL7-based project built on top of Zato and
I can share a few remarks. This was my first HL7 project.

The project’s original scope was to build an HL7 <-> Zato <-> SOAP <->
Zato <-> JSON interface.

Purely of business reasons this got greatly reduced but I did complete
the HL7 part - it was HL7 v2 (no XML) and the patient-related structures
I dealt with were to do with general symptoms as expressed through HL7’s
PID, PV1, ORC and OBX. Included were embedded RTF and plain text
attachments.

There are two major HL7 libraries for Python:

The former is way more object-oriented and allows you to navigate
through an HL7 document using dot notation, i.e. msg.msh.cm.

The drawback of hl7apy was that I couldn’t make it parse all of the HL7
documents I received prior to development - so even though it is much
more convenient, I could not really use it. And the project’s schedule
did not really allow for my taking it up with hl7apy’s maintainers so it
could be properly sorted out.

python-hl7 on the other hand requires one to index elements in HL7,
think ‘birth_place = msg.pid[0][22]’ for instance - this naturally
requires one to read HL7 spec a bit more closer but I’d say it’s not a
base big deal after a day or two. The advantage of python-hl7 is that I
had no problems with parsing and processing any of HL7 documents at all.

Given that I dealt with only a handful of structures, I ended up writing
a few utility methods in a base service other services inherited from,
i.e. I had methods like ‘get_attachment’, ‘get_patient’ and so on that
returned all the business data as Python dicts/bunches. It took a couple
of days but then the actual services were a piece of cake to develop.

I considered adding HL7 to Zato’s SimpleIO as a first-class citizen on
the same level as JSON or XML but then again - HL7 is a huge spec and
like I said, the project’s scope was capped. I don’t rule out that in
the future it might be added.

If you can, try to convince your HL7 vendor to use HL7 v3 - this will be
simply XML and will be an order of magnitude easier to read and deal
with than v2.

If it can’t be done, try to convince them not to use the default v2
separators - have them use ‘;’ or ‘,’ - this can be configured in MSH
and will make any sort of debugging much, much easier. That allowed me
to read HL7 directly with no GUI browser.

I’d say there is not much Zato-specific to working with HL7. You simply
need a library to parse it, turn into convenient Python structures as
soon as possible, and then it is regular Python development. There are
plenty of resources online regarding HL7 - this is a well worked out spec.

If you have with time any suggestions on how to have Zato ease the task
of working with HL7, please let me know, I’d be very interested in your
opinion :slight_smile: