@aaron-kaufman-moore
Forum Replies Created
-
AuthorReplies
-
October 19, 2016 at 1:01 pm in reply to: Cloverleaf Process Unresponsive – read returned error 0 #84658
Shane,
Your experience mirrors ours for our MDM interface from Epic’s EPS outbound documentation. We had the process go down every ~4-6 weeks when running on 6.0.2 but haven’t been up on 6.1.2 long enough to see if the pattern will repeat itself.
It isn’t a persistent connection since it comes from Interconnect/EPS and not Bridges making the connection, so what you see is normal.
We have our inbound setup as multi-server since we can have multiple sources (the source is clustered and multiple hosts can connect to send messages)
We utilized the error settings in Bridges to immediately notify us when we receive an error 56, so the on-call person usually gets into Cloverleaf quickly and restarts the process so that there isn’t too much that needs to be retriggered from Epic
Unless something has changed, the certificate creation process for moving to basic security requires you creating certificate request and Infor generating certificate files to place on your system. I’d recommend starting by opening a ticket on InforXtreme, since they would have the latest documentation for that process.
We do attach our system that utilizes basic security to the enterprise microsoft active directory (I believe that feature first came with 6.0, but we are on 6.1.2). The users are setup as part of the normal creation process by whoever manages your domain. We had an AD group created which all people who need to access Cloverleaf were placed into. Within the LDAP configuration in Cloverleaf, you choose which AD group(s) are allowed access to cloverleaf.
We are starting to get the same thing at my organization, so I’m also in search of a solution.
For those who might be more familiar, what about the use of IPSEC rules in windows firewall for securing the communication between Cloverleaf and 3rd party systems. If I were to utilize a certificate generated from our own CA, would Cloverleaf be able to use it to negotiate with a Windows server firewall rule that requires a Computer Certificate as the authentication method?
I’m not an expert on Epic ADT but I believe some of the merge transactions will spit out an update for every encounter a patient has ever had in the system. What got us more was the activities done by some batch jobs, we look closely at transactions with specific users in EVN-5 when they first come into Clovlerleaf and handle those accordingly.
We have a strategy for connecting with our Epic system’s multiple test/staging environments where we have dedicated port ranges for each environment that no other thread may use. When we need to test against a different Epic environment, we run a script that will stop each process on a site then run a sed command on the NetConfig to change just those port numbers and restart the sites against the different Epic test environment.
Mike Klemens wrote:Thanks for posting that!
I was able to track down some large base-64 PDFs this morning and confirmed with my OnBase admin that they filed despite them being 4.04 & 4.07 MB. She did mention that the size limit is configurable in the Windows Service setup – we currently have ours set at 20MB. 4MB is apparently the system default, not a hard limit. This information pertains to v14 of the application.
I didn’t reach quite that much growth, I recently installed 6.1.1 in a test server and I experienced a 3 to 1 ratio:
Size comparison – took /scrhist/1wkago (1/12/16-1/19/16) and the compressed flat files took: 9.39 GB, when converted to SMATDB (all uncompressed) it took 28.10 GB in space
The source files were compressed using AIX’s built in compress command (not sure which protocol it uses)
I think you’re spot on with the trxid proc; We’ve used a trxid proc before that looked at the first two characters of PV1-3.1 since our sending system had the device identifier begin with a campus identifier. Hope this helps so you wouldn’t need to maintain a large table.
We experience some of that same strange SMAT behavior in our production system that is running 6.0.2 with the classic SMAT files.
I’d use a regsub in a pre-proc command would be:
regsub -all {|} $ {\F\}
I don’t recall having to download any java from outside sources for our installations. We just use whatever comes with the Cloverleaf Installation for our AIX server.
David Barr wrote:Rob Lindsey wrote:We have everyone login to the *nix server as their own account and then use:
su – hci
that forces the *nix system to use the .profile of the hci user and not reference anything from the originating user.
Do they have to type in the hci password? What prevents them from logging in as hci directly?
Also the “-i” option on sudo clears out the environment from the original user.
In our setup (AIX 6.1), the users do need to enter the hci password when they su up to the hci username. We prevent them from logging in as hci directly by adding the following lines to /etc/ssh/sshd_config:
Match User hci
PasswordAuthentication no
That will not allow hci to login with a password, but still allow scripts which can handle key-file authentication (think sftp) to still work as an hci user. That has satisfied our security team…so far
Yes, I sent it attached in an e-mail to the address that your e-mail button is linked to.
We went from GE to Epic and we noticed not only the amount of A31s but also the way that Epic creates encounters every time an inpatient has a procedure (eg. radiology) and sends out A04 and multiple A08s while that happens even though the patient is still an inpatient. We also had to setup a function for some of our systems that generates A08s out of Bridges when it sends out A31s, so we really increased our volume, sorry I don’t know where the numbers went, but I think it was close to a double.
We also got bit a couple of times by the same backload issue, so we do two things to help alleviate the problem. The first is that we create a temporary copy of our outgoing ADT interface in Bridges and have them run the load command with that AIP record as the target interface (so if they forget to set the suppress flag, it doesn’t affect other interfaces). The second thing we do is that we still place a TPS proc at the top level where ADT hits Cloverleaf to block any messages with the EVN-5.1 of the username of the person running the job to keep anything out of the engine should we know about the load but the the other two checks were missed.
-
AuthorReplies
