[Mike Grieger]

I will give an example based on what we have done for one partner who wanted/required mTLS config.  A couple additional notes is that (1) we both agreed we could work with self-signed certs for this, as there was also another layer of security (VPN) involved; and (2) I did not use trust/key stores, though may revisit in the future if this becomes more widespread – so far it was the only such one-off request done ~3 years ago.

1. Partner provided me their public certificate
2. I used openssl to generate a Private key / Public cert pair, and provided our public cert to client
3. note that the certs must be in PEM format… so if viewing the files, the should contain readable ‘–BEGIN CERTIFICATE–‘ …  ‘–END CERTIFICATE–‘
4. For configuration where we are the server, partner is the client:

Mode = ServerAuth
<p data-ccp-border-bottom=”1px solid #b3b3b3″ data-ccp-padding-bottom=”4px”>           CA Path – the directory path to where the partners public cert resides </p>
<p data-ccp-border-top=”0px none ” data-ccp-padding-top=”0px” data-ccp-border-bottom=”1px solid #b3b3b3″ data-ccp-padding-bottom=”4px”>           CA File – the file name of the partners public cert </p>
<p data-ccp-border-top=”0px none ” data-ccp-padding-top=”0px” data-ccp-border-bottom=”1px solid #b3b3b3″ data-ccp-padding-bottom=”4px”>           Certificate File: path/file name of our public cert </p>
<p data-ccp-border-top=”0px none ” data-ccp-padding-top=”0px” data-ccp-border-bottom=”1px solid #b3b3b3″ data-ccp-padding-bottom=”4px”>           Private Key: path/file name of our private key </p>
<p data-ccp-border-top=”0px none ” data-ccp-padding-top=”0px”>           Password: private key password </p>
       5. For configuration where partner is the server, we are the client:

Mode = ClientAuth

All other entries are the same as the above.

 

we have a 2-server test environment, so made it easy enough to set up a sandbox to trial-and-error test the configurations.

Hope this is of help.

[Mike Grieger]

fwiw, in tcl, we use the following to enable regexp within tcl proc:

DBCMD function regexp regexp

[Mike Grieger]

Walter – I’m wondering if you need to convert the Cert format so Cloverleaf can recognize it?  Is the .pfx in binary (not PEM/ASCII format)?  Thought it needed to be PEM format.

[Mike Grieger]

not an elegant solution, but it works: add a new Xlate action (just a @null to @null COPY or whatever), and put an echo statement in the xlt pre proc.  Use testing tool.  If your echo statement displays prior to the mis-match error, the tag error is farther down, else, it is above your echo.

Think binary sort… put the echo in the middle to find if the problem is in the top half or bottom half, then keep doing that to narrow it down.

[Mike Grieger]

It’s not too bad.  It’s been a few years, but once upon a time I dealt with GRV3 quite a bit.  Did most of the custom field mapping withing Xlates… via iteration and mapping the specific fields either directly to destination fields, or sometimes mapping them to variables, which could be used later in the Xlate (like when combining several custom fields into the same destination, like combining for Notes, etc.).

A very small snippet of Xlate actions where the custom fields were presented in ZOR segment:

{ { OP COMMENT }

   { COMMENT {Sets user defined data to variables} }

}

{ { OP ITERATE }

   { BASIS 2(0).ZOR.99111(0) }

   { VAR %f1 }

   { TYPE field }

   { BODY {

       { { OP IF }

           { ERR 0 }

           { COND { 2(0).ZOR.99111(%f1).[2]  eq =3INTCM01} }

           { THENBODY {

               { { OP COPY }

                   { ERR 0 }

                   { IN {{2(0).ZOR.99111(%f1).[4]}} }

                   { OUT {{2(0).ODS.00271(1).[0]}} }

               }

           }}

           { ELSEBODY {

           }}

       }

       { { OP IF }

           { ERR 0 }

           { COND { 2(0).ZOR.99111(%f1).[2]  eq =3INTCM02} }

           { THENBODY {

               { { OP COPY }

                   { ERR 0 }

                   { IN {{2(0).ZOR.99111(%f1).[4]}} }

                   { OUT {{2(0).ODS.00271(2).[0]}} }

               }

           }}

           { ELSEBODY {

           }}

       }

       { { OP IF }

           { ERR 0 }

           { COND { 2(0).ZOR.99111(%f1).[2]  eq =3INTCM03} }

           { THENBODY {

               { { OP COPY }

                   { ERR 0 }

                   { IN {{2(0).ZOR.99111(%f1).[4]}} }

                   { OUT {{2(0).ODS.00271(3).[0]}} }

               }

           }}

           { ELSEBODY {

           }}

       }

       { { OP IF }

           { ERR 0 }

           { COND { 2(0).ZOR.99111(%f1).[2]  eq =3INTCM04} }

           { THENBODY {

               { { OP COPY }

                   { ERR 0 }

                   { IN {{2(0).ZOR.99111(%f1).[4]}} }

                   { OUT {{2(0).ODS.00271(4).[0]}} }

               }

           }}

           { ELSEBODY {

           }}

       }

[Mike Grieger]

Wild card * means run at every interval, so you have it for every minute, every second…   put 0 in the minute and second fields, so that it runs at 02:00:00  instead of 02:*:*

[Mike Grieger]

Question – do you have to be concerned with any NTEs under your OBXs?  ie – OBX-2 has NTEs under it, so you need to make OBX-2 into NTE-1, but then keep the existing NTEs as well?

If not, it should be fairly easy to accomplish.  One method you could use is as follow: establish an iteration of the group/segment (whatever you are iterating on). In that iterate, do an IF, and evaluate your iteration variable to see if it is zero (first iteration).  (ex. IF $%s1 eq =0) – note the $ in front of variable.  under that IF, copy your fields to their OBX output.  under ELSE, copy your fields to NTE.  you can set up another variable to use, and have it equal to the math expression of your iteration value minus 1, so that your NTE copy basis starts with zero.  (ie, on OBX-2, the iteration variable is at 1 since it is zero based, so you want to subtract 1 from it so the NTE basis is one less than the current OBX you are on).  And if you want to use NTE-2 numbering, that should equal your current OBX iteration variable also.

Now, if you also have NTEs that can be present under your OBXs, that complicates things a bit.  Still doable, but more complex.  I won’t get into that at this point.

[Mike Grieger]

Russ – I don’t recall the specifics of the issue, but it could well have been on old 3.7 or 3.8 versions.  I did a quick test as well, and the field by field copying that you use does look like it handles things properly; however, with PATHCOPY, I see the carry-over (so initialization would be advised).  I’m pretty sure what I remember was with field by field and before PATHCOPY existed, so if I do recall correctly, I’d say that has been resolved in newer Cloverleaf versions.

So, I guess my caution may only be relevant any more if using PATHCOPY.

[Mike Grieger]

Gena – one word of caution when creating multiple messages through an Xlate iterate as has been suggested.  It’s been several years since I worked on such a thing, so my memory may be a bit fuzzy, but here’s what I recall:

Within the iterate, you should ‘initialize’ all the FT1 fields that you will be copying in your iteration.  Reason being, if a particular field is valued on one iteration, but not on the next, I believe that the first iteration’s data will carry over.  (I believe that on a subsequent iteration, an empty field will not overwrite a value on the outbound field buffer).

Something to be mindful of.

[Mike Grieger]

One possible thing… probably not quite what you wanted, but maybe better than having to modify the existing procs if you keep your existing structure…

If there is a way to identify the messages from your new thread from the others, you could write a new proc – to be placed first on the OB stack – that does a PROTO disp for those specific msgs and a CONTINUE for the rest.  I believe that would cause your identified messages to jump right to the protocol, effectively by-passing the rest of the tps stack.

I don’t think I like this suggestion, but I guess it may be a possibility?

[Mike Grieger]

You may want to take a look at the Xlate the message is going through… are there any ‘IF’ statements in the Xlate, and if there are, are any of the IF statements checking a field that either is a list of data, or a string that has any spaces in it…  IF statements don’t like that and throw the error you are seeing (if memory serves me).

[Mike Grieger]

ok.  Was just making sure.  When speaking in HL7 terms, PID-3.3 should mean the 3rd subfield.  (but by tcl index terms, that is an index of 2, since zero based).

So, you are talking about PID-3.4.

[Mike Grieger]

You state you are looking for PID-3.3, but in your code when you have PID-3 and you split it, you go for the index of 3…. the actual index of sub-field 3 should be 2, right?  (lindex 0, lindex 1, lindex 2)

[Mike Grieger]

I think your Test Tool output is showing you that OBX is iterating at the GROUP level, not segment level.

[Mike Grieger]

If I’m not mistaken, what you are describing is actually following the HL7 convention… that the field separators need only exist through the last valued field (and not needed to follow that last valued field).

However, I think one way to do what you are trying to do would be to edit your outbound variant, and make the last field that you do want to see the field separator in a ‘required’ field vs. optional.  Although, I don’t recall on which Cloverleaf versions this trick works with…

[Author]

Replies