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
go to post Jeffrey Drumm · Jan 28, 2020 Will native install kits be available for the Community Editions as well?
go to post Jeffrey Drumm · Jan 16, 2020 Thanks for the response, fellow Jeffrey! The tables I'm currently working with are tiny, literally no more than a couple dozen message header and body records. The query in the IRIS SQL shell (and management portal SQL facility) returns results immediately. I think we have some sort of obscure bug here. This is with IRIS for Health CE 2019.1 running on Ubuntu (not a docker image), and the client is Windows 10 using IRIS ADO.NET support. Same result when using the ODBC drivers, though. I think you're right on reaching out to WRC ... thanks again.
go to post Jeffrey Drumm · Jan 14, 2020 I should also point out (after doing some additional experimentation) that this method works for individual fields as well: Again, I should mention that what you see in the DTL Test facility does not represent what will happen in the transformation. I believe this is an artifact of the way the Windows clipboard handles EOL characters in a cut/paste operation.
go to post Jeffrey Drumm · Jan 14, 2020 I'm pretty sure you don't want a newline character anywhere in the target OBX segments, so this should do the trick: Unfortunately, this does not appear to do the right thing in the DTL Test tool. You can verify it works at the Caché/IRIS prompt, though: You can, of course, also verify that it works by calling it from a routing rule
go to post Jeffrey Drumm · Jan 11, 2020 The fact that the DB1 and OBX segments are shown in the color black is an indicator that your HL7 schema does not match the message's actual structure. Unless you correct that in the schema (which may require creating a custom schema) you won't be able to reference the OBX (or DB1) segments in your routing rule using the standard conventions.
