A simple example of how to count DocType's in the EnsLib_HL7.Message table is below:

SELECT Count(*) FROM EnsLib_HL7.Message
WHERE Name = 'ADT_A12'

If you need to compare Ens.MessageHeader properties too, you can do a join on the two tables:

select Count(*) from EnsLib_HL7.Message As Body
LEFT JOIN Ens.MessageHeader As Header
ON Body.ID = Header.MessageBodyId
WHERE Header.ID > 1 AND Body.Name = 'ADT_A12'

Hope this helps.

This behavior matches a known limitation with using Extended Criteria on Ensemble/HealthShare 2017.1.1.

Please contact InterSystems Support in order to continue investigating the behavior.

Clark is more or less correct.


In order for a Business Operation FTP Passthrough component to send a file downstream, the file has to have been saved somewhere local to Ensemble/HealthShare.  This can be one of two default locations.


1. The Caché database using GlobalCharacterStreams(initial default)

2. The local file system using FileCharacterStreams


This is controlled by the setting in the Business Service FTP Passthrough, "Use FileStream".  There is no default way of preventing the Business Service from saving the file. 


If space is your primary concern, then I would suggest an aggressive Message Purge strategy (using BodiesToo and KeepIntegrity set to true) as this can be a standard solution for keeping your persistent data  low even if you have large data flow in your Passthrough interface.


The #1 solution is to purge regularly so that you do not end up with a build up of so much data.

The #2 solution, if you do end up running into needing purge a lot of data, is to purge incrementally.  That is to run a purge for only a subset of your data.  Let your journal files get purged, and then purge another subset of data.  This procedure is tedious but the safest way to purge down large amounts of data.

Any other options would be custom solutions that InterSystems would want to be involved in assisting you with.


It appears though you have already resolved your issue by reinstalling the instance.

I encourage you to reach out to our Worldwide Response Center if you run into issues starting InterSystems applications in the future.  We can assist in identifying the root cause of what is preventing a normal startup.

You can find information about the WRC here:



You are setting a target property and then calling GetFieldStreamRaw on the source.  Any changes you make to the target message before you call GetFieldStreamRaw and then the subsequent StoreFieldStreamRaw will be overwritten by the StoreFieldStreamRaw method.

Essentially your DTL example is doing the following:

Set source = "OldValue"

Set target = "NewValue"

Set target = source

"NewValue" is overwritten.

Simply add your DTL actions to manipulate the target message AFTER the StoreFieldStreamRaw calls and you should be all set.


The order of which the different purge tasks are listed was not meant to indicate an order of which to run them in.  The order is up to the discretion of the Administrator.

The two tasks will be searching for different message sets to delete, so they will not overlap.  There would not be a noticeable performance benefit to running one before the other.


If your Mirror configuration requires special attention, you can use the ^ZMIRROR routine to run code at certain points in the Mirror Failover process.  It sounds as though you need to add code to start up the ISCAgent into $$CanNodeStartToBecomePrimary^ZMIRROR().   The latest Docs on ZMIRROR are below, but entry points such as this have existed in many versions of Caché.



I have successfully used the Parenthesis () Syntax with the Contains functions in a routing rule condition.  Your first example should be working as you expect it to.

I would like to work with you on this issue in a WRC case as I believe that it will take some investigation in order to identify what is causing the rule not to fire.

I will email you shortly with a WRC number and a couple questions.

Jeff Morgan

Ensemble Support