go to post Jeffrey Drumm · Jul 18, 2024 The response from the Stored Procedure was not in the form of an object?
go to post Jeffrey Drumm · Jul 18, 2024 Also pointed out by others was not to have the Response object be anything other than Ens.Response. Any other type would cause an Orphaned message created even if you don't use it. Is this true even when the response object extends Ens.Response? That's a bit surprising ...
go to post Jeffrey Drumm · Jul 18, 2024 An option that can be performed without Studio, also nice! (You do need VS Code though) And @Robert.Cemper1003's solution can be performed exclusively via the Management Console, which is also a great alternative. I'm guessing that the WebSocket Terminal would also provide IRIS command shell access without an ssh session but I haven't played with that yet.
go to post Jeffrey Drumm · Jul 16, 2024 I wrote a quick classmethod in my custom FunctionSet class to test your observation and found that I can use the full mnemonic property path name, for example: ClassMethod GetControlID(pMsg As EnsLib.HL7.Message) As %String { // Also works with "MSH:10" Return pMsg.GetValueAt("MSH:MessageControlID") } Example from a rule (I used Document, but HL7 also works): And the resulting trace from the Visual Trace: I'm thinking that your inbound messages might not have the DocCategory (ex. "2.3.1") and DocName (ex. "ADT_A01") properties set ... ?
go to post Jeffrey Drumm · Jul 12, 2024 I'm pretty sure it's because a message header isn't created for an ACK, since (in most cases) it's not sent anywhere. They're tracked in Ens_Util.IOLogObj, and cleaned up from there if selected in the Message Purge task.
go to post Jeffrey Drumm · Jul 8, 2024 Yes, the process runs as the irisusr account, but does not have irisusr's environment, it has root's.
go to post Jeffrey Drumm · Jul 8, 2024 Great article, @Sylvain Guilbaud! One suggestion I would make is to configure the User value as irisusr (assuming that was the user specified at installation for stopping/starting IRIS). Otherwise IRIS obtains the root environment, which can have unexpected consequences.
go to post Jeffrey Drumm · Jul 4, 2024 Set From = "2024-07-04 13:21:16.477" Set To = $ZSTRIP($PIECE(From,".",1),"*P")
go to post Jeffrey Drumm · Jul 4, 2024 @Enrico.Parisi's observation is the most likely reason for the failure. You can obtain the credentials (assuming you've set them up in Interoperability | Configure | Credentials) with Set tCreds = ##class(Ens.Config.Credentials).%OpenId(..Adapter.Credentials,,.tSC) Return:$$$ISERR(tSC) tSC The tCreds.Username and tCreds.Password properties are available on success.
go to post Jeffrey Drumm · Jul 4, 2024 The Connect() method returns a %Boolean, not an %Status. You should check the ReturnCode and ReturnMessage properties to determine why it's failing.
go to post Jeffrey Drumm · Jul 3, 2024 The new editor doesn't support that, at least yet. If you'd prefer to have the original rule editor launch when editing a rule, you can disable the new editor's web application /ui/interop/rule-editor through the Management Console via System Administration | Security | Applications | Web Applications.
go to post Jeffrey Drumm · Jun 12, 2024 Odd. I just ran your exact query on IRIS for Health 2023.3 and it executed successfully. The error message suggests that a macro isn't defined, specifically $$$vaDataSegName, which is found in EnsHL7.inc (among others). Since you're working specifically with HL7 messages I suspect that include file is not available to the namespace in which you're running the query.
go to post Jeffrey Drumm · May 26, 2024 Looking through the HL7 2.5 OML_O21 structure as supplied by InterSystems, you'll find that there's a nested PIDgrpgrp() under ORCgrp().OBRgrp() that has a subordinate ORCgrp(). It looks like the parse is attempting to match on the required OBR segment in the nested PIDgrpgrp().ORCgrp(). You have a couple of options ... both of which require a custom schema to match your message. The first is to make the OBR segment in the PIDGrpgrp().ORCgrp() optional; the second is to remove the PIDgrpgrp() grouping entirely in the custom schema. EDIT: The first option doesn't work since the ORC matches on the optional ORC segment in the nested PIDgrpgrp.ORCgrp(), which makes it attempt to match on the required PIDgrpgrp.ORCgrp().OBXgrp().
go to post Jeffrey Drumm · May 20, 2024 This is what DTLs are for. The example below shows a scenario using HL7 2.5.1's ORU_R01 message structure, where each OBX segment may be followed by one or more NTE segments. The OBX Set ID, Value Type and Observation Value fields are populated; the first by the value of tObxCounter, the second by the string "TX" and the third by the contents of the Note field. The highlighted area demonstrates the updating of newly added OBX segments with the contents of corresponding NTE segments.
go to post Jeffrey Drumm · Apr 18, 2024 The ISCAgent is available through the online distribution link at the WRC site, in the "InterSystems Components" category. The oldest version available is 2018.1, but it may work for you.
go to post Jeffrey Drumm · Mar 12, 2024 OnGetConnections() should return an array in the first (Output) argument, indexed by the names of the target process(es) and/or operation(s). The second argument is the production item object passed by the invocation of the method from the web ui. Here's an example that scans the business process settings for any setting that ends with "ConfigName" or "ConfigNames" and sets the pArray argument appropriately: ClassMethod OnGetConnections(Output pArray As %String, pItem As Ens.Config.Item) { #dim tSetting As Ens.Config.Setting Do ##super(.pArray,pItem) For l=1:1:pItem.Settings.Count() { Set tSetting = pItem.Settings.GetAt(l) If ($LOCATE(tSetting.Name,"ConfigNames?$") && pItem.GetModifiedSetting(tSetting.Name,.tValue)) { For i=1:1:$L(tValue,",") { Set tOne=$ZStrip($P(tValue,",",i),"<>W") Continue:""=tOne Set pArray(tOne)="" } } } } Adjust the match string in the $LOCATE() function if you're using custom setting name(s) for the target(s).
go to post Jeffrey Drumm · Jan 30, 2024 I'd suggest using some other directory than /tmp as the root of the source path. And I would also recommend installing it as root rather than a user with some elevated privileges. You'll be specifying the account under which it will actually run later, during the install.