go to post Jeffrey Drumm · Apr 3, 2020 The documentation is available both in the DTL editor when you use the Exists() method in the Expression Editor for a rule: And in the Class Reference for Ens.Rule.FunctionSet -- the Exists() Method: The Class reference is clearer about the table argument being a quoted string.
go to post Jeffrey Drumm · Mar 4, 2020 Hi Brendan, Well, I just tested it with WinSQL and the queries that never returned results previously are now working. They're also working in the application I had originally tested with, so ... not sure what the cause was. I was previously using IRIS for Health CE 2019.1 as the target environment but am now using a "commercial" IRIS 2019.1 license.
go to post Jeffrey Drumm · Feb 25, 2020 Did you get an actual compilation error, or just an error indicator in the expression editor? In my case, the dialog box shows the expression indicated an error, but it doesn't cause a compilation problem. I don't have any sample messages to test with at the moment, so I'm not sure it will actually work ...
go to post Jeffrey Drumm · Feb 25, 2020 It appears as though the answer is no. I would think that the Private property keyword would be the most intuitive way to do this, but it does not appear to have any effect in the DTL editor.
go to post Jeffrey Drumm · Feb 25, 2020 Hi Barry, your syntax is close but not quite right: I don't have a message class handy that has an Observation property defined as %ListOfDataTypes, so I get an error indicator in the rule editor (which I've tried, poorly, to edit out).
go to post Jeffrey Drumm · Feb 25, 2020 The functionality described here is pretty specific to Ensemble/HealthConnect. While I can't answer definitively, I'm fairly certain that Epic does not store queued/processed HL7 messages using the same object format and class names (i.e. SQL table names) as Ensemble.
go to post Jeffrey Drumm · Feb 20, 2020 What version of Caché or IRIS are you using? on IRIS 2019.1, the menu returns immediately after the "No matching records found" message.
go to post Jeffrey Drumm · Feb 19, 2020 I set up a test scenario based on your criteria. I created a service, HL7 router process and 3 operations: Service: HL7 MLLP, target HL7 Router, AckMode=Application Process: HL7 Router, ForceSyncSend: True, ReplyCodeActions: E=F Target Operation 1: HL7 File Out Target Operation 2: Custom Operation that returns an HL7 NAK, sets IsError to 1, logs an error code of 5001 with text "Forced NAK", ReplyCodeActions: E=F Target Operation 3: HL7 File Out Observations: Message arrives in router process Routes to Operation 1, completes successfully Routes to Operation 2, receives error Router responds to Service with Error; shuts down ... no message delivered to Operation 3 Service returns NAK to sending application Message remains queued for Router Isn't this what you would want to happen?
go to post Jeffrey Drumm · Feb 12, 2020 While I haven't tried it, I'm fairly confident that this would be handled via ReplyCodeActions in the router.
go to post Jeffrey Drumm · Feb 12, 2020 Once the ACK is received by the Router, it's forwarded as a Request object to the ResponseTargetConfigName list, so at that point it's just like any other message. No need for BPLs in this specific instance.
go to post Jeffrey Drumm · Feb 12, 2020 Yes Neerav, that will avoid it, but at the possible expense of both performance and robustness. If one process called from the routing rule doesn't complete, nothing else does either. In a BPL you have more granular control over sync/async works.
go to post Jeffrey Drumm · Feb 12, 2020 If the order of the A02s is not important, you can simply create a routing rule with two Send actions for the same target; the first Send is configured with a DTL that creates an A02 for the first transfer, and the second a DTL for the second transfer. Many receiving systems will have an issue with this, though, as both patients temporarily end up in the same bed. While it might be fun for the patient, the transfers may be rejected. In some cases you may need to perform 3 transfers: Transfer patient 1 to a dummy bed, transfer patient 2 to patient 1's prior location, transfer patient 1 to patient 2's prior location. In this scenario, it would probably be prudent to use a BPL to enforce synchronous behavior, guaranteeing that the transfers happen in a specific order.
go to post Jeffrey Drumm · Feb 11, 2020 ^%SYS is mapped from IRISSYS, so it should only need to be modified int he %SYS namespace, right? Does IRIS need to be restarted after this change? It doesn't seem to be having an effect. I'll be trying the ^EnsPortal change shortly and will report back.
go to post Jeffrey Drumm · Feb 11, 2020 I'll assume that I'm not the first person to complain about this Thanks!
go to post Jeffrey Drumm · Feb 11, 2020 Seems to work fine if you route the ACK to another Business Process. For the router handling messages from an inbound service: Response comes in from TestTCPOut; the received ACK is sent to the original service and forwarded to a BP called AckWrangler. That BP runs a routing rule that optionally transforms the ACK and passes it off to another operation called AckTarget:
go to post Jeffrey Drumm · Feb 10, 2020 What do you have set for the Response From and Response Target Config Names fields in the router's configuration? I'm thinking the former should be the operation from which you're receiving the response, and the latter should be the router itself.
go to post Jeffrey Drumm · Feb 7, 2020 As a general rule, I'd suggest using the StartsWith() function in the DTL wizard when comparing date fields. In your case, the Birthdate field very likely does not include a Time component at a resolution of seconds. If it did, though, you could run into many combinations where the date value from CurrentDateTIme() would match. For example, Contains() would return true on the 19th or 20th of February 2020 against "20200220200219" ... February 20th 2020 at 8:02:19pm. This would certainly be a rare occurrence, but not impossible.
go to post Jeffrey Drumm · Feb 6, 2020 A few of questions: Can we assume that the tracking information will be received asynchronously, after the PO? Will there be only one tracking file per PO, or will there be a distinct file per line item in the PO? Can the tracking file name be somehow derived from data found in the PO, or must the file(s) be scanned/parsed to determine its related PO?
go to post Jeffrey Drumm · Jan 29, 2020 I get the same result using your suggested method, Brendan. I'm not technically a customer; I work for a Services Partner of ISC. I am a DC Moderator though (if that carries any weight) so it would be nice to keep abreast of the new stuff
