web stats
ASTM Client Receiver - Page 2 - Mirth Community

Go Back   Mirth Community > Mirth Connect > Support

Reply
 
Thread Tools Display Modes
  #11  
Old 11-27-2012, 08:37 AM
narupley's Avatar
narupley narupley is offline
Mirth Employee
 
Join Date: Oct 2010
Posts: 7,126
narupley is on a distinguished road
Default

Quote:
Originally Posted by vognstang View Post
Thanks for the update on your roadmap intensions.

I am working on 2.2.1.

In regards to connector development, i got a couple "questions" related to 3.0:

I have encapsulated the protocol code in the a protocol class where input output interface are streams, i guess your not changing the receiver/dispatcher concept in the connectors?.. wheter it is backed by mule or not shouldn't make much of a difference, atleast i think.

UI is completely like the existing connectors, so there shouldn't much problem, unless your changing away from netbeans UI?

regards
Niels
Here are a couple "answers":

Yep, abstracting the logic using an interface gnostic only of input/output streams is definitely a good way to go. The tricky part is making that work with streamed batch messages and the vastly different messaging engine that 3.0 will use. In any case, your work with 2.2.1 certainly would not be lost on the community even after 3.0 is released, as many people will still be using 2.2.1 until they're ready to migrate.

The NetBeans UI builder is still being used, at least for the time being. However, the underlying structure of the connector settings panels will change significantly (and for the better) in 3.0.
__________________
Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

Nicholas Rupley
Work: 949-237-6069
Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


- How do I foo?
- You just bar.
Reply With Quote
  #12  
Old 11-28-2012, 08:09 AM
vognstang vognstang is offline
What's HL7?
 
Join Date: May 2012
Posts: 4
vognstang is on a distinguished road
Default

okidoki sounds good i am not to concerned then, removing the beans stuff (as it sounds like you are doing) would definetly help on a multitude of things (ex. automated testing)

I attached a very very very preliminary version of the connector (plus source), any feed back is appreciated, though i can not promise to adhere to any comments and i will ofcause not be liable for it to work(that was the disclaimer)
Attached Files
File Type: zip astm-${version}.zip (100.7 KB, 194 views)
File Type: zip astm src.zip (71.4 KB, 208 views)
Reply With Quote
  #13  
Old 12-13-2012, 05:46 AM
vognstang vognstang is offline
What's HL7?
 
Join Date: May 2012
Posts: 4
vognstang is on a distinguished road
Default

this post does not seem to generate much interest, but anywho, i added some stuff and done some testing of the connector... so here goes...
Attached Files
File Type: zip astm.zip (112.2 KB, 325 views)
Reply With Quote
  #14  
Old 12-13-2012, 07:06 AM
narupley's Avatar
narupley narupley is offline
Mirth Employee
 
Join Date: Oct 2010
Posts: 7,126
narupley is on a distinguished road
Default

Quote:
Originally Posted by vognstang View Post
this post does not seem to generate much interest, but anywho, i added some stuff and done some testing of the connector... so here goes...
Don't count yourself out; there have already been several hundred views of this thread, so I'm sure people are interested even if there aren't any new posts.

I took a look at the connector; awesome stuff! I'm sure it'll be very useful for people who are still on 2.2.1. As far as 3.0 goes, we've completely resigned the "transmission mode" framework so that you can easily develop plugins for ASTM, or literally any other custom lower-layer protocol, like MLLPv2 or HLLP. That new framework won't be included in the first beta release next week, but it will be in the next beta coming out sometime early next year. So look forward to it!
__________________
Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

Nicholas Rupley
Work: 949-237-6069
Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


- How do I foo?
- You just bar.
Reply With Quote
  #15  
Old 12-13-2012, 11:13 PM
asulis asulis is offline
Mirth Guru
 
Join Date: Dec 2006
Location: Cagliari, Sardinia, Italy
Posts: 210
asulis is an unknown quantity at this point
Default

I think it will be very useful for me in the future, thank you very much for your contribute.

Best regards,
Alessandro
Reply With Quote
  #16  
Old 03-30-2013, 01:41 PM
gurun gurun is offline
Mirth Newb
 
Join Date: Jun 2012
Posts: 13
gurun is on a distinguished road
Default

I have a new (much simplified) version of an ASTM adapter. It implements LIS-1, 1381 as well as well as "Radiometer classic" which is the usual 1-4 low level framing (but choose whatever). It is developed on the 2.2.1 branch.

Question, is there any reason why this should be submitted back to Mirth if you are not going to release another version of that branch? I could just as well put it up on my own blog, right?
Reply With Quote
  #17  
Old 04-01-2013, 07:40 AM
narupley's Avatar
narupley narupley is offline
Mirth Employee
 
Join Date: Oct 2010
Posts: 7,126
narupley is on a distinguished road
Default

Quote:
Originally Posted by gurun View Post
I have a new (much simplified) version of an ASTM adapter. It implements LIS-1, 1381 as well as well as "Radiometer classic" which is the usual 1-4 low level framing (but choose whatever). It is developed on the 2.2.1 branch.

Question, is there any reason why this should be submitted back to Mirth if you are not going to release another version of that branch? I could just as well put it up on my own blog, right?
The short answer is that even after 3.0 is released, there will (unfortunately) be many people who will still use 2.2.1 for quite some time. Also, we may release a 2.2.2 version as well, which would include a plethora of bug fixes that would cater to those 2.x stragglers.

In any case we have developed an ASTM E1381 (which is the same as LIS-1) transmission mode plugin for 3.0, but not for 2.x. I'm curious as to what "radiometer classic" means though. Is that another ASTM standard, or a custom variation on LIS-1?
__________________
Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

Nicholas Rupley
Work: 949-237-6069
Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


- How do I foo?
- You just bar.
Reply With Quote
  #18  
Old 04-01-2013, 08:01 AM
gurun gurun is offline
Mirth Newb
 
Join Date: Jun 2012
Posts: 13
gurun is on a distinguished road
Default

So, in answer of my question, you would recommend that I submit it back then?

1381 and LIS-1 is _almost_ the same, with an emphasis on almost. For systems expecting 1381, they would not cope with LIS-1. In reality, most implementations seem to ignore the 247 length constraint on 1381 which in reality turn them into LIS-1 60k+ length).

"Radiometer classic" was introduced something like 20 years ago, and because of the wide spread usage, and because blood gas analyzers where very early on connectivity direct to LIS, and becasue the 0x04 and 0x04 delimiters where introduced as a simplified low level protocol for LIS system-to-system integration over TCP/IP - because.. it was adopted as industry standard. It is a simplified version of MLLP basically. I would guess that it is the one most used in integration of ASTM over TCP/IP.

We could never get the response on LLP working with the responses on this, otherwise we would have used that. And we never managed to figure out how to do it using the TCP adapter either.

If you implement ASTM support, I think you should also consider LIS in client mode on the sender side of Mirth. I need to implement this, but fitst have to figure out if this is consistent with the connector life cycle.

Finally, to have it complete, it also needs to be able to handle delimiters that are themselves part of the message. I noticed that you can specify multiple delimiters in the 3.0 TCP adapter, but no choice of including them in the actual message. This is typical for some Roche devices but also some other vendors use it.

ASTM in comparison to HL7 is a world of hurt. It is not so much implementing a standard, but rather to cover for all the deviations from it on lower level.
Reply With Quote
  #19  
Old 04-01-2013, 08:41 AM
narupley's Avatar
narupley narupley is offline
Mirth Employee
 
Join Date: Oct 2010
Posts: 7,126
narupley is on a distinguished road
Default

Quote:
Originally Posted by gurun View Post
So, in answer of my question, you would recommend that I submit it back then?
If by "submit it back" you mean post it here on the forums for all to see, sure why not!

Quote:
Originally Posted by gurun View Post
1381 and LIS-1 is _almost_ the same, with an emphasis on almost. For systems expecting 1381, they would not cope with LIS-1. In reality, most implementations seem to ignore the 247 length constraint on 1381 which in reality turn them into LIS-1 60k+ length).
Wow thanks for the info there, I didn't know that was the case. In our implementation, just about everything is configurable, from the 240-character content limit down to the specific checksum algorithm used (defaulting to addition modulo 256), to the lengths of the various timeout conditions.

Quote:
Originally Posted by gurun View Post
"Radiometer classic" was introduced something like 20 years ago, and because of the wide spread usage, and because blood gas analyzers where very early on connectivity direct to LIS, and becasue the 0x04 and 0x04 delimiters where introduced as a simplified low level protocol for LIS system-to-system integration over TCP/IP - because.. it was adopted as industry standard. It is a simplified version of MLLP basically. I would guess that it is the one most used in integration of ASTM over TCP/IP.

We could never get the response on LLP working with the responses on this, otherwise we would have used that. And we never managed to figure out how to do it using the TCP adapter either.
If it's a simplified version of MLLPv1 (which is already ridiculously simple), then I'm sure it can easily be emulated with the 3.0 TCP connector, in which you can specify the starting/ending bytes. If it's a simplified version of MLLPv2, then it's still rather simple though. We've added MLLPv2 support in 3.0 in addition to the standard MLLPv1 that most people know and use. So assuming that it's similar in nature, I would guess that it could be emulated by changing the MLLPv2 properties (which are also all configurable, down to the timeouts). Do you know where I might find a copy of the standard? I tried googling it to no avail.

Quote:
Originally Posted by gurun View Post
If you implement ASTM support, I think you should also consider LIS in client mode on the sender side of Mirth. I need to implement this, but fitst have to figure out if this is consistent with the connector life cycle.

Finally, to have it complete, it also needs to be able to handle delimiters that are themselves part of the message. I noticed that you can specify multiple delimiters in the 3.0 TCP adapter, but no choice of including them in the actual message. This is typical for some Roche devices but also some other vendors use it.
We have implemented E1381 as both a Listener connector and a Sender connector. Actually to be more precise, there is only the TCP Listener/Sender and ASTM E1381 is a transmission mode plugin that can be added in addition to vanilla TCP / MLLP. Regarding the delimiters (as mentioned before), every single one is configurable. Some Roche devices use 1381, but others use a completely proprietary protocol, which we're planning on developing as well. Also if you're wondering "what about devices that can still only connect via serial?", well, don't worry.....

Quote:
Originally Posted by gurun View Post
ASTM in comparison to HL7 is a world of hurt. It is not so much implementing a standard, but rather to cover for all the deviations from it on lower level.
True, though I would make the distinction between LIS-1/E1381 (the lower-layer protocol) and ASTM E1394 (the application-layer protocol). E1394 is the "HL7-like" content, which incidentally we've also developed for 3.0. Be sure to watch the next few developer Q&A webinars, as we'll probably be showing off much of this soon...
__________________
Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

Nicholas Rupley
Work: 949-237-6069
Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


- How do I foo?
- You just bar.

Last edited by narupley; 04-01-2013 at 08:44 AM.
Reply With Quote
  #20  
Old 04-01-2013, 09:35 AM
gurun gurun is offline
Mirth Newb
 
Join Date: Jun 2012
Posts: 13
gurun is on a distinguished road
Default

Sounds very cool. Looking forward to 3.0 release, and I do believe we will start using it within the first 6 months.

Server-mode of the listener is not what you think (I believe). It acts exactly like a TCP sender, but with the only difference that the socket is a listener, and the receiving system (LIS) connects the socket, and then goes into wait state (looking for ENQ in the case of 1381/LIS1). The message exchange is still driven from Mirth.
It would be kind of like having a listener (Mirth) and only send responses, over and over and over again.

I could send you the spec for the 1/4 thing, but it is really just that. It is not a "standard".

And the only thing you need in order to get the "delimiters part of the message" is to make an if in the code you already have on 3.0 and you are done. "Two lines" of code...

Now just waiting for the release.. Has been looking interesting so far, but much of the code seem to be elsewhere right now, so can't judge. I'm most exited to see if you did anything about response transformations, but not that it really matters other than for pedagogic reasons for the specialists we train.

Serial? It is a server software right. The DMS we have didn't implement that part, because it is already taken care of with cheap hardware converters.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 08:18 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2020, vBulletin Solutions, Inc.
Mirth Corporation