Pathcopy Populating A Blank Field

Homepage Clovertech Forums Read Only Archives Cloverleaf Cloverleaf Pathcopy Populating A Blank Field

  • Creator
    Topic
  • #50010
    Darren Tomlinson
    Participant

    i have this copy defined in a translation…

    PATHCOPY   0(0).PID.00114(0)   ->   0(0).PID.00114(0)

    whenever the field comes in blank, Cloverleaf would populate this field with an M.  Does anyone have any idea why?

    i later realized that the use of a PATHCOPY on a subfield was poor syntax, so i changed it to a COPY and it works correctly now.  The reason i tend to use PATHCOPYs is because if a field has subfields, a COPY with only copy the first subfield…i just got in the habit of always using PATHCOPYs.

    Also note, i am on 5.3 rev3

Viewing 23 reply threads
  • Author
    Replies
    • #64487
      Daniel Chibaya
      Participant

      Is the field actually blank or does it have some “hidden” text in there?  Control characters?

    • #64488
      Darren Tomlinson
      Participant

      i’m not sure exactly what you are asking, but that field comes blank into Cloverleaf in the PID, and an M gets put into it.

    • #64489
      Darren Tomlinson
      Participant

      i have it doing it again, in a new context…

      I have PATHCOPYs on fields in the OBX segment.  the fields that can repeat, but i denote instance 0, also get “M”s put in the fields that are blank.  i am completely perplexed.  

      example: PATHCOPY of blank field(s) 0(0).OBX(%s1).00576(0) will get populated with an M but 0(0).OBX(%s1).00577 will not.

      i’m guess not many people have ran across this due to the lack of responses.

    • #64490
      Tom Rioux
      Participant

      Darren,

      The “hidden” characters may be control characters (such as a tab or a carriage return) that may be showing up in the message being sent.  One quick way to check this is to do a hex dump on the file:

      hcihd filename.bin

      When you do a hex dump you will see the Hl7 message on the right and the hex equivalent on the left.  Any control characters will show up as dots in the hex part of the dump.  See example:

      56547c5e 33373739 3735320d 4754317c   VT|^3779752.GT1|

      The first four columns are the hex equivalent of the last column.  If you notice at the tail end of the 3rd column, there is a “0d” that represents the end of the segment.  

      Check your message to see if anything like this is happening in your message.

      Hope this helps…

      Tom Rioux

    • #64491
      Robert Milfajt
      Participant

      I agree with Thomas that you probably have an ASCII 13 character imbedded in the field.

      Cloverleaf represents this as ^M in textual displays, and the ^ is also the sub-field delimiter, so you think you are getting an M when in actuality you are getting x0d.

      Bob

      Robert Milfajt
      Northwestern Medicine
      Chicago, IL

    • #64492
      John Mercogliano
      Participant

      All,

        I just ran across this same problem today doing a pathcopy of 1(0).1(%g1).0(0).NTE(%s1) with the NTE segment getting populated with a single M in the first field when the NTE segment did not exist.  It turned out that my iterate was set to list instead of segment.  

       Don’t know if this applies but something to look at.  

       I would have thought that I would have received some type of error because everything else in the dialog box was defined for a segment iterate including the %s1 instead of the %l1.

      John Mercogliano
      Sentara Healthcare
      Hampton Roads, VA

    • #64493
      Darren Tomlinson
      Participant

      i ran the hex dump on my file.  there is no hidden character.  7c467c7c577c represents |F||W|.  as you can see, there is no hidden character between the F and W.

      i double checked the bad iterate variable, but that was not it.  there isnt an iterate at all anywhere in the translation.

    • #64494
      John Mercogliano
      Participant

      Darren,

        That could be your problem as it appears pathcopy returns M when you use an undefined iterate value.  If you are not using an iterate then you should be able to use a direct reference as in

      0(0).OBX(0).00576(0) instead of 0(0).OBX(%s1).00576(0)

      But if this is a repeating segment, how are you looping through the segments without an iterate?

      John Mercogliano
      Sentara Healthcare
      Hampton Roads, VA

    • #64495
      Darren Tomlinson
      Participant

      there are two instance above where i have this problem…

      1) is in the PID that has no iterate

      2) is in the OBX with a properly defined iteration variable

    • #64496
      John Hamilton
      Participant

      I use pathcopy on a regular basis. I have never seen this issue where the source data was not a fault.  

      What I would suggest is posting both your translation and the source data.  Or call support.   I would be more the willing to go over your xlate and use your example data to find the issue.  But trying to recreate your problem for me has been problematic.

    • #64497
      John Mercogliano
      Participant

      Darren,

       First, I am using 5.2 rev 2, so this might be fixed in a future release as they did a lot of work after 5.3 with pathcopy.

       I’ve been able to duplicate your PID pathcopy problem and it does appear to be related to pathcopy not working with a completely null input on a repeating field.  Pathcopy should work down to the field level.

       Being my problem also produced the same result and I would have also been sending a null value to pathcopy at the segment level because of my uninitialized iterate variable(oops), there is a good chance that pathcopy has an overall problem working with a completely null data stream in a repetition.

       Being your second problem also dealt with copying a blank repeating field but the non repeating field worked this appears to hold true.

       I don’t know about everyone else, but at the field level I have always used the copy command.

       Your statement that copy will only copy the first subfield is incorrect.  As long as you define the source and destination the same as pathcopy, at the field level it works the same, minus the null copy problem.

      Hope this helps,

      John Mercogliano
      Sentara Healthcare
      Hampton Roads, VA

    • #64498
      Darren Tomlinson
      Participant

      John, you are right about the copy command.  i just retested it, and it appears to work.

      I know at one point the copy command would not copy subfields for us…and thats when we found using pathcopy as a solution to that problem.

      The thing that might have been the problem back then is that we were running 5.3 rev3 on the server, but didnt install the patches on our PCs.  That has since been rectified.  I guess that could have been the issue.  i dont know…

    • #64499
      Alice Kazin
      Participant

      I have had this issue before.  Generally I check if a required field in the segment is not null before doing the Pathcopy.

    • #64500
      Alice Kazin
      Participant

      In my case I was pulling ^M (d) from the end of the segment.

    • #64501
      Kevan Riley
      Participant

      We noticed this problem while we were comparing output from 5.3 against 5.6.  This has been happening to us quite a bit in 5.3 and we never noticed it.  The behavior goes away (is fixed) in 5.6.  I can’t speak to any intermediate versions.

      Kevan Riley

    • #64502
      Alice Kazin
      Participant

      It was happening on 5.4.1 rev1.

    • #64503
      Darren Tomlinson
      Participant

      i figured out why i thought i needed to us a PATHCOPY to copy all subfields.

      For instance, if you were to copy the PID with a PATHCOPY but wanted to null out PID2, if you COPY @null -> 0(0).PID.00105, it will leave the subfields alone and only blank out the first subfield.  Result will be |^subfield2^subfield3|.

      whereas if you use a PATHCOPY of @null you will blank out all subfields and be left with ||

    • #64504
      John Mercogliano
      Participant

      I wrote this xlt proc to null a field because of the purge cache problem with copying a null value with pathcopy in versions I believe earlier then 5.5.  You call this with the field name in the source and destination(i.e. 0(0).PID.00105).  

      Pathcopy would be the logical choice if it was not for these two problems.  But luckily with tcl you can code around most of the inconvenient problems 😉

      Code:


      proc shs_xltNullField {} {
         upvar xlateId       xlateId        
      xlateInList   xlateInList    
      xlateInTypes  xlateInTypes    
      xlateInVals   xlateInVals    
      xlateOutList  xlateOutList    
      xlateOutTypes xlateOutTypes    
      xlateOutVals  xlateOutVals

      set xlateOutVals [list]
      foreach InVal $xlateInVals {
      lappend xlateOutVals {}
      }

         return $xlateOutVals
      }

      John Mercogliano
      Sentara Healthcare
      Hampton Roads, VA

    • #64505
      Darren Tomlinson
      Participant

      i ran into two more problems previously discussed within this thread.

      1) i am now getting an a segment of “NTE|M” copied across when there was no NTE segment present.  i did not have an iteration value as John has described earlier in this post because i want to only copy the 0 instance.  when i changed the PATHCOPY of the NTE to separate copies of each individual field, the problem went away.

      2) i ran across the COPY not coping all subfields again.  in the one instance i saw today, a copy of a field defined as STRING will not copy subfields if present.  however, if i change that field to COMPOSITE, it gets all subfields.

    • #64506
      Jim Kosloskey
      Participant

      Darren,

      In the second instance (ST Data Type) that Data Type is mal used. Separators of any kind are not to be placed raw in a ST field – period!!

      They either need to be escaped or the field used properly or (as you have done) change the Data Type to CM or some other componetized Data Type as a work around.

      I see this violation all the time and mostly I try to get the vendor or system owner to stop being so damn lazy and follow the standard. I am not always successful at getting the sending system to change but I am almost always successful in adapting due to the power of Cloverleaf(R).

      The second instance you observed is not a fault of PATHCOPY – IMHO it is doing what I would expect.

      email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

    • #64507
      Jim Gibson
      Participant

      We are in the process of testing for our upgrade from ver 5.3 to 5.6.  We had seen this problem with PATHCOPY.  In 5.6 it has been fixed and you do not get the mystery M segments.  We are just hoping our apps that have been getting these for years won’t mind not getting them.

    • #64508
      John Mercogliano
      Participant

      Darren,

       Your first problem you described is still a variant of the same problem.  Even though you are hardcoding the repetition value, pathcopy is still working on a a segment defined as repeating. So when it receives a command to copy a null segment you get the M.  I have gotten around this problem by using an if statement on the set id or some other value that is guaranteed to never be null and only calling pathcopy when there is data.

      John Mercogliano
      Sentara Healthcare
      Hampton Roads, VA

    • #64509
      Kevin Crist
      Participant

      i am having somewhat of a similiar problem. i am trying to copy fields from a vrl to hl7. This is a first for me as i am new to interfacing. when i run the testing tool i get m’s where there should be the | field separator. i am using only a copy statement in the xlate, so far. any advice would be thankful. thanks.

      [/img]

    • #64510
      John Mercogliano
      Participant

      Kevin,

       I have a similar setup and I have no problem with the pipe disappearing.  Are you attempting to copy a constant or a vrl field to 0(0).MSH.00001.[0] when you build the MSH segment?  Unless the downstream system expects something else, you should not need to do anything to field 1 or 2 as cloverleaf will always send the default, at least in 5.2.  I’ve also attempted to copy @null and the testing tool still shows the pipe.  It only changes if I gave it a valid ascii character.  Not sure where else to look but hope this helps.

      John Mercogliano
      Sentara Healthcare
      Hampton Roads, VA

Viewing 23 reply threads
  • The forum ‘Cloverleaf’ is closed to new topics and replies.

Forum Statistics

Registered Users
5,092
Forums
28
Topics
9,274
Replies
34,365
Topic Tags
281