Easy: Getting IB HL7 data: Separate threads vs Interprocess communication

This topic has 7 replies, 2 voices, and was last updated 4 years, 8 months ago by Jim Kosloskey.

Creator

Topic
April 24, 2020 at 10:33 am #116534
Bobby Harris
Participant
Can a single IB HL7 server source (think HL7-ADT from the EHR) be used across multiple CL sites and process WITHOUT inter process threads? We currently make use of inter process/site threads to distribute HL7 (raw) data. In Site GetData – We get the HL7 (raw) data inbound from the EHR, then setup multiple OB threads to be used in OTHER CL Sites with their own processes.

My belief is each process in different CL sites should be able to establish their own connection to an external IB (HL7) data source and not have to make use of inter process threads.
Creator

Topic

Viewing 2 reply threads

Author

Replies
- April 24, 2020 at 10:39 am #116535
  Jim Kosloskey
  Participant
  Will the EHR allow multiple connections from the same Client IP Address (different ports)? I suspect most (maybe all) do not.
  
  If they did you can try it but each connection may not get the same message or there could be some other anomalies.
  
  What is your perceived issue wit the way you are doing it now?
  
  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
- April 24, 2020 at 10:43 am #116536
  Bobby Harris
  Participant
  Hi Jim,
  
  Thank you for your response.
  
  Your Question: What is your perceived issue wit the way you are doing it now?
  
  The CL documentation states to avoid using inter process threads to aid in resource management. Our server is “stressed” at times and as a newbie and am looking for ways to reduce the stress.
  - April 24, 2020 at 11:15 am #116538
    Jim Kosloskey
    Participant
    What I would suggest is to think about something like this:
    
    Site 1:
    
    Process A
    
    IB thread (from EHR ADT) —> tcp/ip thread local host port 20001 (port is just a suggestion) this is the client to Site 2
    
    Site 2:
    
    Process A
    
    tcp/ip thread local host port 20001 (matching the OB thread in Site 1 —> Final Destination
    
    Using intersite routing can be problematic for higher volumes.
    
    In the above architecture Site 2 would deliver to as many downstream systems as is practical. If more are needed, add Site 3 and a new OB tcp/ip thread in Site 1.
    
    If you would like to discuss in more detail, email me.
    
    email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
  - April 24, 2020 at 1:28 pm #116540
    Bobby Harris
    Participant
    Thank you for your insight!
    
    Your recommendation is currently how it is setup. The process is high volume (ADTs) and sometimes goes into Panic – very early before business hours. We will have to come up with a solution, because we will have the need to leverage this IB source for more projects.
    
    Thanks
  - April 24, 2020 at 3:38 pm #116543
    Jim Kosloskey
    Participant
    Oh I thought from the initial post you were using intersite routing.
    
    If all that is in the site receiving the ADT is IB thread and raw routes to destination threads which are localhost tcp/ip and there are panics happening overnight then you need to look deeper into what is occurring during those panics.
    
    Could it be the EHR is blasting unnecessary ADT messages (I know some do)?
    
    email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
- April 24, 2020 at 10:47 am #116537
  Bobby Harris
  Participant
  Follow up for Jim,
  
  You mentioned (same Client IP address different ports). I was thinking using the same port. So, each CL process would use the exact same port to retrieve the server data.
  - April 24, 2020 at 11:19 am #116539
    Jim Kosloskey
    Participant
    The EHR still needs to be able to allow multiple clients to connect on the single host connection.
    
    Under the covers a unique port will be assigned at the IP level but I believe you will need to specify separate ports in Cloverleaf.
    
    In my opinion, this is not even worth pursuing.
    
    If the architectural change I proposed in an earlier reply does not relieve the strain, then more detective work needs to be done. But I think the architectural change should improve things. You may just be approaching the limit of what your Server can provide in its current configuration.
    
    email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
Author

Replies

Viewing 2 reply threads

You must be logged in to reply to this topic.