go to post Jeffrey Drumm · Dec 13 Yes, adding that rule to your DTL will set MSH:6, assuming the schema you've selected for the target message in your DTL definition uses ReceivingFacility as the fieldname. You can use the numeric representation MSH:6 if you prefer. It will work just as well as MSH:ReceivingFacility, but is not as human-readable.
go to post Jeffrey Drumm · Dec 3 If you're using the HL7 File Service, the full filename can be found as a %String in the message object's Source property. You can extract the required characters from that and set MSH:6 in a DTL:
go to post Jeffrey Drumm · Nov 10 If you're using a custom business process to handle the message, you could perform the truncate in an OnRequest() callback. If you're using a BPL, you would add an action near the beginning of the process to perform the truncate. The request object will be a single batch object containing a collection of records; the next step would be to iterate over the collection and perform the inserts. You could do essentially the same thing in a DTL; use an SQL rule at the beginning to truncate, then add a foreach to iterate over the batch and populate the DB. The key is the fact that your BP is getting all of the records in a single object. So when that object arrives, it's time to truncate the table and repopulate it. You will have to skip the first record if it contains headers, of course.
go to post Jeffrey Drumm · Oct 31 With IRIS 2025.1.1 on Windows, I cannot reproduce your issue. Both sets of instructions execute normally. VS Code Version: 1.105.1 (user setup)Commit: 7d842fb85a0275a4a8e4d7e040d2625abbf7f084Date: 2025-10-14T22:33:36.618ZElectron: 37.6.0ElectronBuildId: 12502201Chromium: 138.0.7204.251Node.js: 22.19.0V8: 13.8.258.32-electron.0OS: Windows_NT x64 10.0.19045 ISC ObjectScript Extension 3.2.1-beta.1 ISC Server Manager 3.10.6-beta.3 ISC Language Server 2.8.0
go to post Jeffrey Drumm · Oct 27 You are correct in that ReplyCodeAction E* does not evaluate the contents of the ACK message MSA segment; it only looks at the IRIS error code and text. For your specific example, though, I'm wondering why you're not simply setting a condition to exclude invalid messages in the Routing Rule?
go to post Jeffrey Drumm · Oct 22 A foreach (possibly multiple foreaches) is what you need. Getting the iterators right is the issue. You're iterating over the AISgrp in the first RGSgrp of the source message and placing them in target RGSGroups with the same iteration count of the source AISgrp. Here's an example based on the 2.3.1:SIU_S12 schema structure that should do what you want, and also handles repetitions of the AIL, AIP and AIG groups:
go to post Jeffrey Drumm · Oct 21 And Firefox! Note that the author requests payment equivalent to US$9.99. As far as I can tell, payment doesn't unlock any special features, but it's probably the right thing to do 😁
go to post Jeffrey Drumm · Oct 15 If Cache isn't running under his account, it likely won't have access to that directory.
go to post Jeffrey Drumm · Oct 15 What account is Caché running under? You'll need to review Windows Services to find the Caché service controller (I don't remember the exact name). It's probably running under the Local System account; you'll need to change it to log on with your own credentials if you want it to use your account's environment.
go to post Jeffrey Drumm · Oct 14 Instead of ..Contains() as the outer method, use: ..RegexMatch(..ToUpper(source.{PIDgrpgrp(k1).ORCgrp(k2).OBXgrp(2).OBX:ObservationValue()}),"NOT DETECTED|NEGATIVE")
go to post Jeffrey Drumm · Oct 7 I just attempted the same sequence using a known valid network path on IRIS 2025.1.1 and it worked as expected. The result set contained the list of folders and files in the specified share.
go to post Jeffrey Drumm · Oct 7 I've never created an IPM module ... it seems like a fair amount of effort to set it up for a single small class and based on my current status it's unlikely that I'd do it more than this one time. That said, if some streamlined mechanism for building and publishing it exists, I'll give it a shot ...
go to post Jeffrey Drumm · Oct 6 ORCgrp is a member of PIDgrpgrp and PIDgrpgrp is missing from your "if" statement. The condition should read: ..Contains(..ToUpper(source.{PIDgrpgrp(k1).ORCgrp(k2).OBXgrp(k3).OBX:ObservationValue()}),"DETECTED") I don't know whether you're using the same doctype for the target, but if you are, the target path will need to be updated as well.
go to post Jeffrey Drumm · Oct 6 Use a combination of the ToUpper() and Contains() methods in the Function list with an if rule: The AI Bot offers another option, but it's probably a bit more involved than you really need 😁
go to post Jeffrey Drumm · Oct 3 The rule parser/compiler doesn't handle calls to methods/classmethods unless they extend Ens.Rule.FunctionSet, and it doesn't recognize the ##class() keyword. If your class does extend Ens.Rule.FunctionSet, you should be able to use just the Methodname as shown below: <assign property="PropertyName" value="SomeMethod(args)" />
go to post Jeffrey Drumm · Oct 3 Here's an example of the generated query, updated with calls to HICG.GetMsg(): SELECT TOP 100 head.ID As ID, {fn RIGHT(%EXTERNAL(head.TimeCreated),999 )} As TimeCreated, head.SessionId As Session, head.Status As Status, CASE head.IsError WHEN 1 THEN 'Error' ELSE 'OK' END As Error, head.SourceConfigName As Source, head.TargetConfigName As Target, head.SourceConfigName, head.TargetConfigName, head.MessageBodyClassName As BodyClassname, head.MessageBodyId As BodyId, EnsLib_HL7.Message.%ID As Body_ID, HICG.GetMsg(head.MessageBodyId,'PID:3') As Body_PID_PatientID, HICG.GetMsg(head.MessageBodyId,'PID:18') As Body_PID_PatientAccountNumber FROM %IGNOREINDEX Ens.MessageHeader.SessionId Ens.MessageHeader head, EnsLib_HL7.Message WHERE (((head.SourceConfigName = 'From_Some_Router' AND head.TargetConfigName = 'To_Some_Operation')) AND head.MessageBodyClassName='EnsLib.HL7.Message' AND head.MessageBodyId=EnsLib_HL7.Message.%ID) ORDER BY head.ID Desc I just replaced the null values with calls to HICG.GetMsg(). The 2nd argument is the schema-specific path to the values you're extracting, using the same syntax as found in EnsLib.HL7.Message's GetValueAt() method. You can download the class from the HL7 Spy website: https://hl7spy.ca/downloads/HICG_HL7.xml.
go to post Jeffrey Drumm · Oct 3 While @David.M's response will provide a query, it will likely not include the HL7 message-derived values. For example, a search that includes the HL7 field values you've listed will return null for their values when executed via the SQL menu or SQL shell. That said, I created a tool (originally for use with HL7 Spy to extract HL7 messages from Ensemble/Health Connect) that has some features that may help get you what you want. See this thread for an example of its use.
