As long as you can count on the message spec never changing, this works fine.

If the originating system ever adds an NTE segment after the OBX, you'll have an issue. The message would still be valid from an HL7 standards perspective, though.

Thanks, Leon. Good to hear that you're still active in healthcare integration, and I hope we'll see more of  you here at the Developer's Community!

Are the DTLs referenced in routing rules or are they being called from custom Business Processes (or BPLs)? I verified the first option using a production at my current client and the DTLs are all there in the export list.

Ah, now it makes sense. The Document type you'd specified for the inbound message did not match the structure of the message itself, so the RemoveSegmentAt() method didn't know how to "find" the EVN segment ... it didn't exist in that schema.

The recommended approach would be to use a schema/document type (custom if necessary) that matches the structure of your inbound message, making the segment to be removed optional in the definition. With that in place, the RemoveSegmentAt() method would have worked as expected.

I would expect to see that error on the original message (before the EVN segment was deleted) but not on the cloned/modified version. Are you sure you're looking at the right message?

You were close with you original code ...

Set newreq = request.%ConstructClone()

Set sc = newreq.RemoveSegmentAt("EVN")

Set request = newreq

the variable sc is the status of the remove segment operation; the EVN segment is actually removed from newreq.

I've cobbled together a little TamperMonkey/GreaseMonkey script that diddles with the style sheet without having to make unsupported changes to your installation's configuration. Adust the devattr, qaattr and prdattr variables to suit your color tastes, and the match arguments for the hostnames to identify your servers.

// ==UserScript==

// @name         Management Console Banner

// @namespace    http://tampermonkey.net/

// @version      0.2

// @description  Seems to work for both Chrome and Firefox

// @author       Jeff Drumm, HICG LLC

// @include      *://*/csp/sys*

// @include      *://*/csp/healthshare*

// @grant        none

// ==/UserScript==

function addGlobalStyle(css) {

    var head, style;

  head = document.getElementsByTagName('head')[0];

    if (!head) { return; }

  style = document.createElement('style');

  style.type = 'text/css';

  style.innerHTML = css;

  head.appendChild(style);

}

var devattr = 'color-stop(0.0,rgb(95, 246, 18)), color-stop(0.5,rgb(20, 204, 51)), color-stop(1.0,rgb(232, 227, 226))'

var qaattr = 'color-stop(0.0,rgb(248, 252, 10)), color-stop(0.5,rgb(204, 199, 20)), color-stop(1.0,rgb(232, 227, 226))'

var prdattr = 'color-stop(0.0,rgb(255, 2, 49)), color-stop(0.5,rgb(204, 18, 18)), color-stop(1.0,rgb(232, 227, 226))'

var curattr = ''

if (window.location.hostname.match('^ensprod.*')) {

    curattr = prdattr;

} else if (window.location.hostname.match('^ensqa.*')) {

    curattr = qaattr;

} else {

    curattr = devattr;

}

addGlobalStyle('.portalTitle { background: -webkit-gradient(linear, left top, left bottom, ' + curattr + ') !important; } ');

Mmmyyyeaaaaaah, You're going to want to do that in a DTL:

Create a rule that appends the text to the target.AlertText property:

You can add conditionals to provide different alert explanation values based on the SourceConfigName or by parsing the source.AlertText text to find something interesting.

Finally, stick the DTL in the Send rule for whatever operation you're sending alerts to.