Re: Bika OpenMRS interface

[lemoene]

Hi Burke. I hope you don't mind me posting your reply to the Bika Health list. Bests, lemoene

-------- Original Message --------

We would prefer ORU^R01 for lab results. 

-Burke

On Mar 18, 2009, at 4:26 AM, Ryan <rg.cr...@gmail.com> wrote:

Hi all,

Sorry for waking the dead, but I've now coded an OpenMRS module that allows for some basic LIS connectivity. I have been using the bluebird XML spec for receiving results but I would now want to move onto HL7.

I've been looking at the HL7 2.6 spec and so far the messages I've picked out for communication between the system could be a OML^O21 message for the lab orders and one of the OUL's for receiving results.

I remember from this conversation the following was mentioned:

Orders - use HL7 2.6 orders (most likely)

Results - use ELINCS 3 (HL7 2.5.1) for results

Why for the results would a 2.5.1 message be used?

I want to support messages that would be most useful. What messages would be best to use?

Regards,
Ryan

[Bill Lober]

Burke - this corresponds to ELINCS 3 MT-ORU-1, MT-ORU-2, MT-ORU-3 messages, right?

Or, is it the case that ELINCS further constrains the ORU^R01 to match the MT-ORU-* specs starting on pg. 30 of the Elincs doc?

I guess the underlying question is whether OpenELIS can send MT-ORU-1 messages to the ORU^R01 handler in OpenMRS?

Thanks,

Bill

Lemoene - hope this is OK for this forum - I thought it might be of general interest (or a misunderstanding of mine best corrected 9 time zones away, where the sun is up..!)

At 10:21 PM 3/27/2009, lemoene wrote:

Hi Burke. I hope you don't mind me posting your reply to the Bika Health list. Bests, lemoene

-------- Original Message --------

We would prefer ORU^R01 for lab results.Â

[Bill Lober]

Excellent -

I noticed the MSH-9 part in 6.2.9 also - That's what prompted me to wonder if MT-ORU-2 was the same as a ORU^R01, or whether it was a subset/further constraint of an "R01".  My conclusion:  I don't think it matters, for my purposes.

We'll continue to work towards Elincs, then...

Thanks,

Bill

At 10:07 AM 3/28/2009, Burke Mamlin wrote:

Bill,

I'm not an ELINCS expert, but from what I can see from ELINCS 1.1, the MT-ORU-1, MT-ORU-2, and MT-ORU-3 message types all conform to the R01 event of the ORU message type in HL7.

So, yes, I would expect that any of the MT-ORU messages of ELINCS should be able to be passed to the ORU^R01 handler in OpenMRS.  In fact, ELINCS 1.1 section 6.2.9 addresses the message type (MSH-9) field and ends with "In the MT-ORU-1, MT-ORU-2, and MT-ORU-3 message types, this field must be
hard coded to the following value: ORU^R01^ORU_R01."  :-)

Essentially, OpenMRS uses ORU^R01 to receive results.  Again, I'm not an ELINCS expert, but I'm guessing this means that the OpenMRS handler would work with available results (MT-ORU-2) messages with little to no modification, but it's not currently set up to manage status updates (MT-ORU-1) for observations or corrections to observations (MT-ORU-3).  It would probably accept all three, but just blindly create observations in OpenMRS from any OBX segments it found in the message.

Cheers,

-Burke