Forum Replies Created
-
AuthorReplies
-
Peter Heggie wrote:
I believe that the license is checked at process startup. If you don’t recycle the process every day, then it should still run.. I may be wrong..
But threads will not run on process startup.
Support can give you a temporary key/keys to get you going while you submit a new key request. So this could take 30 to 120 minutes, end to end time before you have keys that will work.
Submitting a new license key request generally (in our experience) has a turn around time of less than two days.
We went through this a few months ago. After upgrading to 6.2, we discovered that we had requested the ‘temporary’ keys instead of the permanent keys, and everything stopped at the midnight recycle. We called Infor Support and got the temporary keys.
Thanks, hopefully this never happens 🙂
Albert Sinha wrote:Expired Thread count license makes the threads to fail.
Thanks!
Ramachandran,
Are you taking about just sending email alerts to the exchange?
If so, that can be done pretty easily using the email alert tool.
This can also be done from within an xlate, and you can grab data from the message like, MRN, Control #, Name, etc and send that in your email.
May 22, 2015 at 1:15 pm in reply to: Immunization Registry for Missouri with Allscripts Sunrise #79112Hi Diana,
We are finally done with this project. We get the messages from eLink to Cloverleaf and setup a raw route using the PROTOCOL:fileset-local to write to file. Afterwords we use a product called “MoveIT” which grabs the file and sends it via FTP to the state. It runs once every 24 hrs and sends whatever has appended on that file.
I tried playing around with Cloverleafs feature to FTP, but’s its too clunky to get it to work.
April 27, 2015 at 3:10 pm in reply to: Question: FRONT-END TPS TCL PROC PERFORMS 99% OF THE WORK #82182Perhaps if you did away with the Bulkcopy it may be easier to route only specific messages. Are you also doing “_HCI_static_route_” for your routes?
If so, I would try changing that to something like this example below.
For example, to send ORU’s, setup as follows:
Quote:Route: ORU_R01
Destination: to_cerner_oru
PreProcs: If you need an initial filter
xlate: Mostly Copy or Pathcopies (No bulkcopies at all)
Post Proc: If you really need one
Doing everything in TCL kinda takes away the magic of Cloverleaf to me because you don’t see the arrows showing the flow.
What kind of messages are you receiving on that particular inbound thread?
Now, what if you have the same MAC address but a different IP?
Does that affect the hcihostid?
Well, I know it’s not the MAC address nor the Hostname. That give’s me a different value.
I think Infor needs to understand more from their clients how we are using the SMAT files. Without understanding this, they can’t really know if forcing us to use a DB option is better for us, the client.
I haven’t used the SMAT tools in years, because it’s pretty bad. I use HL7Spy, which does an amazing job of helping me analyse the data.
If I’m forced to using their DB option, I’d have to write lots of specific SQL code to reproduce the same type of queries. I don’t really care to do this, but if they can provide the same queries in a “pre-canned” option, I might lean more towards this change.
Steve Williams wrote:There are several ways to accomplish the task building tiered routes, each has their virtues. This is what deploying this methodology (tpsRedirect) looks like in the engine.
Hey Steve, nice screenshot 😀
David Coffey wrote:Suppose I have three threads.
Brandon Grudt wrote:PM as in Private Message.
Brandon Grudt wrote:In the past, I’ve been able to send PMs to other users without issue.
Jim Kosloskey wrote:Is this a report type format like RTF or PDF?
If so AllScripts should be sending this as base64 encoded.
If you are getting the inbound protocol to read it, maybe you can base64 encode it in a Tcl proc (of course anything following on would also need to be able to decode it, etc.).
Personally I would be concerned I would get by this and then find other nasty stuff in future messages since the vendor seems to be incompetent.
If it were me I think I would try to get together with my management and try to apply a little wall-to-wall counseling with AllScripts
Robert Milfajt wrote:I’m out of ideas, because it would seem to get this to work you either need to create your own custom PDL and figure out how to define this, or to have the vendor stop sending x1c in the data.
Bob
I was playing around with the protocol: tcpip
and I got it to accept the message and continue to flow downstream, but I then run into two more problems.
1) The message cuts off/truncates at the 1C mark. So you only get part of the message.
2) Now you have the same problem but on your outbound message. The receiving side won’t process the message because it’s not properly encapsulated. But even if you do tweak it to encapsulate, you only have half the message due to the truncation.
The ideal would be for Allscripts to fix it at the point where the physician does the copy/paste, but I seriously doubt Allscripts will put in a fix for that.
Robert Milfajt wrote:Sorry, ID10T error, try this:
define phrase basic-msg;
[code]define phrase basic-msg; -
AuthorReplies