New post
AllAccepted answers
Jeffrey Drumm · Apr 6, 2018

The cursor is hovering over the 2nd sub-component of the first component of the field. 3 is the field, 3.1 is the first component of the field, 3.1.1 is the first sub-component of the first component of the field, and 3.1.2 is the second sub-component of the first component of the field. If the field has repetitions (delimited by a ~), the first repetition would be referenced as 3(1), with its components and sub-components referenced as 3(1).1, 3(1).1.1, 3(1).1.2, etc.

Jeffrey Drumm · Apr 6, 2018

You may already understand this, but it bears repeating: If your intent is to include a literal ampersand symbol, you should also change the sub-component separator in MSH-2 in keeping with the formal HL7 spec.

Unfortunately, many vendors don't understand (or bother to handle) HL7 escaped characters, and some of them don't even pay attention to the values in MSH-2 ... leaving us forced to generate what is essentially badly-formed HL7.

Jeffrey Drumm · Apr 4, 2018

If you're unable to purge Message Headers that are beyond the retention period with KeepIntegrity turned off, you may need to clean up your indices.  In a Cache terminal, execute the method below in the namespace where your Ensemble production is defined:

> Do ##class(Ens.MessageHeader).%ValidateIndices("",1)

Depending on the number of message headers, this may take a while to run ... on one system I've worked with it took more than a month.

You may want to also check for orphaned message bodies. You can determine if you have any by issuing the following SQL query from the SQL shell:

> Do $system.SQL.Shell()

>> SELECT COUNT(*) FROM EnsLib_HL7.Message HL7 LEFT JOIN Ens.MessageHeader hdr ON HL7.Id=hdr.MessageBodyId WHERE hdr.MessageBodyId IS NULL

Cleaning up the orphaned message bodies is yet another task, but let's see if you have any first ...

Jeffrey Drumm · Mar 26, 2018

I know this is sort of making an end-run around the issue, but my needs are such that it works well for me.

I run all of my development environments in virtual machines on my laptop. Spinning up a new (or cloning an existing) VM to support a distinct environment gives me the flexibility you appear to need without jeopardizing other software installations.

Jeffrey Drumm · Feb 6, 2018

Looks like changing the framing would require a modified Parser anyway. So ...

I think you'll have to create a copy of EnsLib.HL7.Service.Standard (something like OSU.HL7.Service.CrappyFraming) that changes the  %Parser property to be your custom parser:

Property %Parser As OSU.Custom.HL7.CrappyFramingParser [ Internal ];

Then modify the custom service that was developed long, long ago to subclass it:

Class OSU.HL7.Service.TCPService Extends OSU.HL7.Service.CrappyFraming[ ClassType = "", ProcedureBlock, System = 4 ]
Jeffrey Drumm · Feb 2, 2018

Hi Richard,

The issue in this case was that there could be a variable number of repetitions in the PID:3 and MRG:1 fields, and that there was no guarantee that the MRNs for each facility would appear in the same order. So the actual need was to be able to compare each iteration of the MRN in PID:3 with each iteration of the MRN in MRG:1. This is cumbersome/difficult without a loop construct in the Rules editor, and would require at least as many sequential comparisons as there are repetitions in PID:3.

The example you provided compares only the first iteration of PID:3 with the first iteration of MRG:1, so if the desired match appeared in any subsequent iteration of either of those fields the desired outcome would not be achieved. This is one of those cases where some ObjectScript is a more streamlined solution.

Jeffrey Drumm · Jan 30, 2018

Yes, and just recently too.

You very likely need to run an index validation against Ens.MessageHeader.

NAMESPACE>Set sc = $System.OBJ.ValidateIndices("Ens.MessageHeader",,1,1)

Depending on the size of your database, it could take a while ... possibly weeks if you're in the multi-terabyte range. It has very little impact on performance, though. If you think it might take a while, you can create a task class and have it run non-interactively in Task Manager (that's what I did).

Once it's complete, your message purge should remove the old cruft automatically.

Jeffrey Drumm · Jan 30, 2018

Scott, there's a utility called %GSIZE that does just this; it analyzes global storage and reports allocated vs. actual use.

namespace> d ^%GSIZE

It will prompt you for the database directory (defaulted to your current namespace's), whether you want to include all globals (Yes), globals that contain no data (No), and whether it should show details (Yes). Hit Enter for Device: or specify a path/filename if you want the report written to disk, and Enter again for the Right margin.

If your environment is mirrored, you can run it against the mirror. It could take a while to run; an Ensemble database I've worked with recently is 10TB in size and it took a month to complete.

EDIT: Should've paid attention to your qualification, too ... that's something that will take a bit of query development, thinking in terms of message volume between specific source and target config items along with an analysis of message content size. You'd be working with Ens.MessageHeader for that ...

Jeffrey Drumm · Jan 29, 2018

I think the intent is to limit configuration control of business hosts in an Ensemble production based on user role. Effectively, prevent a Cache/Ensemble user from changing the IP address or port number of a TCP/IP Business Operation through the Management Console without restricting the ability to view the settings.