@michael-heldt
Forum Replies Created
-
AuthorReplies
-
…and usual it boiled down to a network + /etc/resolv.conf issue.
Apparently nslookup gets executed somewhere on on the hcimsiutil. Our host names in netconfig that were simply aliases via /etc/hosts were “hanging”.
A DNS entry in resolv.conf was removed off the network (not just the dns service stop) and the nslookup would hang waiting for a response. This completely explained why some sites experienced issues vs others across multiple env’s.
Thanks gotham for the help!
1 – In on terminal session, issuing the following command (date is included to see how long it takes to return to a command prompt)
$ date;hcienginestop -p phar_oshkosh;date
Wed Jul 3 11:58:11 CDT 2013
Trying hcicmd…
Response:
Process shutdown initiated
Process ‘phar_oshkosh’ is not running
Wed Jul 3 12:06:06 CDT 2013
2 – In a seperate terminal, you can see the process phar_oshkosh has stopped with a normal exit. But the original terminal session that issued the command has NOT returned. The original terminal does state the “Process ‘phar_oshkosh’ is not running” withing ~12 seconds of issuing the command, but it still has not returned to the command prompt!
$ date;hciprocstatus;date
Wed Jul 3 11:58:40 CDT 2013
Process State Message
phar_hartford running Started at Wed Jul 3 11:56:48 2013
phar_oshkosh dead Normal exit at Wed Jul 3 11:58:23 2013
phar_lakeland running Started at Wed Jul 3 08:48:49 2013
phar_burlington running Started at Wed Jul 3 08:48:39 2013
phar_grafton running Started at Wed Jul 3 08:48:33 2013
phar_aph running Started at Wed Jul 3 08:49:19 2013
phar_manitowoc running Started at Wed Jul 3 08:48:29 2013
phar_kenosha running Started at Wed Jul 3 08:48:20 2013
Wed Jul 3 11:58:40 CDT 2013
sorry…enter it in the JVM Arguments field
Options->Client Options->Advanced tab->JVM Arguments
We are using 5.4.1 and since my math is ?able
In the 5.4.1 GUI…Options->Client Options->Advanced tab…enter -Duser.timezone=
Example i’m in Central Standard Time:
-Duser.timezone=CST
You need to enter the hyphen first on the parameter.
Thank teammate of mine …..Jason L for the fyi
We currently have HACMP on AIX 5.3 with 2 physical servers (2 prod lpars, 2 test lpars) in a active-passive running qdx5.4.1. We are looking at upgrading both hardware, os and cloverleaf version in a big bang effort.
When upgrading os or adding hardware to a physical server, we currently initiate an hacmp failover (planned outage) to passive server which takes a good 20+ minutes to bring back our cloverleaf process. Literally stopping all cloverleaf processes (on the active) and restarting cloverleaf processes (on the passive). After which cloverleaf processes are not always stable. This is getting annoying and I’m looking for some better solutions.
We have the MT’s place a “T” into the visit account # in Escription. “T” values are allow through the rules in Escription to go out the MDM interface. In cloverleaf I remove any visit id’s that are not numeric. The trans/gen tables in epic are setup (for particular worktypes) to create an encounter. Letters would be an example.
For a short period of time during testing we too had the same provider id being sent in txa 9 and txa 10..which as you note epic does not like. I asked escription to take care of that and they did. It started when we were trying to get the “resident/non authorizing” tested.
We don’t do partilar dictations necessarily. If the same job crosses and the document is not signed, it gets updated. The chart review is setup in epic display a hyperlink to that “version” of that document. We aren’t doing “parent/child” (TXA 12.3 TXA 13) for escription since I was told from escription that they have no way of tell if the document has been updated vs created.
If you have multiple contributor systems that send in MDM messages (example: multiple transcription systems) the TXA 12.3 value is handled globally in Epic. So we have to make it “unique” in cloverleaf for each system.
-
AuthorReplies
