Hey Doug,

It's been a very long time :)

So ... no, you don't need a complex record map to do this, but the mechanism takes just a little more work using a "simple" record map. The record map feature doesn't let you set a Composite field as repeating, which is why we need to deal with those "grouped" OBX segments/fields using a different method.

What I've done is define the RecordMap with individual fields for everything before the first OBX field, and then define the rest of the record as a single, repeating field. You can then iterate over that last field and parse out the individual HL7 field values with $PIECE, or turn them into a $LIST and  reference the elements by numeric index. The only delimiters you'll need to set for the record map are a "|" as the field delimiter and a "~" for the repetition delimiter.

Here's a sample record map layout:

Along with setting OBXSegs as repeating, I set the MAXLEN DataType parameter to something large enough to accommodate all of the fields. Also note the Discard field; the sample data in your post included a leading "|," so that needs to be treated as though there's an initial empty field in each record. Including a dummy field to consume it makes things a bit more understandable when addressing the subsequent fields.

Here's one way you might iterate over the repeating record map field:

As you surmised in a follow-up to Nora's earlier posts, the Complex Record Map functionality is really only required when the record structure varies from line to line in the input data.

Have you looked at the Default Char Encoding setting of the various HL7 operations? 

It's not normally a property of the message header or body objects. You can often find the port number in the Source property of the Body, but not the IP address. To get that, you'll need to look at the Event Log for the service. It will look something like this:

As for what you're doing wrong ... hard to say at this point; not much to go on. Does the connection complete successfully without restricting the allowed IP addresses?

There are two steps to this ... the first is to open the file as a stream of type %Stream.FileBinary, the second is to use the EnsLib.HL7.Message method StoreFieldStreamBase64() to insert the stream into the desired field.

EDIT: The links point to earlier versions of Ensemble's class methods but they're still valid.

Put them in a separate production and namespace that is restricted to only users with the proper role/resource assignments. There is no built-in mechanism to restrict visibility below the production/namespace level.

If you don't care about any unsent/completed/suspended messages, try calling the CleanProduction() method in class Ens.Director:

Do ##class(Ens.Director).CleanProduction()

This is strongly discouraged for PROD environments ... be forewarned. Would recommend you contact the WRC if you're getting this error in a PROD environment.

Giving them only the %EnsRole_Operator role will prevent them from making configuration changes to the production. And if they aren't assigned the database resource (%DB_<databasename>), they won't be able to start or stop the production either.

In the %SYS namespace:

%SYS>Set ^%SYS("Portal","EnableAutoRefresh")=1

That will reveal the radio buttons that allow you to turn on/off Auto Refresh. Setting that global to 0 actually has the same effect as clicking the Off button, but eliminates the ability to turn it back on via the management console.

There's the Activity Monitor, but I don't know whether it was available for 2017.x. It requires configuration, as it is not enabled by default. It starts gathering activity after configuration, so you won't be able to use it to obtain activity/volume history for messages processed through the production prior to setup.

Are these messages all compliant with the doctype structure they're associated with?

If yes, why not use the symbolic path that the structure supplies ... i.e. something like MsgOut.GetValueAt("PIDgrpgrp.ORCgrp(n).OBXgrp(n).NTE(n)")?

@Robert C. Cemper has you on the right track, but I'm curious as to whether the vendor of the foreign (i.e. non-HealthShare/HealthConnect) system has provided a specification. Do you need to accommodate Acknowledgement messages for both sending/receiving? Is there some sort of handshake protocol that is used to indicate when it's safe to send, a sort of RTS/CTS-type mechanism? Or is this being designed "on the fly?"

If I were designing something like this, I'd go with a web service ... always over the same port, and when you want to send something you'd POST it. When there's nothing to POST, you'd periodically GET to see if anything is waiting.

Anything else would most likely be a one-off in healthcare integration.

The maximum string length for HL7 fields in Health Connect/IRIS for Health is something like 3.6MB; larger than that, the field itself is represented as a stream. You may want to look into the stream methods for accessing fields for your use case.