Homepage › Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Pathcopy Populating A Blank Field
- This topic has 24 replies, 11 voices, and was last updated 16 years, 1 month ago by
John Mercogliano.
-
CreatorTopic
-
May 5, 2008 at 4:30 pm #50010
Darren Tomlinson
Participanti 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
-
CreatorTopic
-
AuthorReplies
-
-
May 5, 2008 at 9:03 pm #64487
Daniel Chibaya
ParticipantIs the field actually blank or does it have some “hidden” text in there? Control characters? -
May 6, 2008 at 3:44 pm #64488
Darren Tomlinson
Participanti’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. -
May 13, 2008 at 12:38 pm #64489
Darren Tomlinson
Participanti 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.
-
May 13, 2008 at 12:55 pm #64490
Tom Rioux
ParticipantDarren, 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
-
May 15, 2008 at 2:31 pm #64491
Robert Milfajt
ParticipantI 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 -
May 16, 2008 at 8:23 pm #64492
John Mercogliano
ParticipantAll, 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 -
May 19, 2008 at 11:37 am #64493
Darren Tomlinson
Participanti ran the hex dump on my file. there is no hidden character. 7c 467c7c 577c 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.
-
May 19, 2008 at 12:05 pm #64494
John Mercogliano
ParticipantDarren, 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 -
May 19, 2008 at 12:55 pm #64495
Darren Tomlinson
Participantthere 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
-
May 19, 2008 at 2:27 pm #64496
John Hamilton
ParticipantI 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.
-
May 20, 2008 at 1:21 am #64497
John Mercogliano
ParticipantDarren, 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 -
May 20, 2008 at 1:14 pm #64498
Darren Tomlinson
ParticipantJohn, 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…
-
May 21, 2008 at 3:52 pm #64499
Alice Kazin
ParticipantI have had this issue before. Generally I check if a required field in the segment is not null before doing the Pathcopy. -
May 21, 2008 at 4:28 pm #64500
Alice Kazin
ParticipantIn my case I was pulling ^M ( d) from the end of the segment. -
May 21, 2008 at 7:16 pm #64501
Kevan Riley
ParticipantWe 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
-
May 21, 2008 at 7:22 pm #64502
Alice Kazin
ParticipantIt was happening on 5.4.1 rev1. -
May 27, 2008 at 12:45 pm #64503
Darren Tomlinson
Participanti 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 ||
-
May 27, 2008 at 2:24 pm #64504
John Mercogliano
ParticipantI 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 xlateOutValsset xlateOutVals [list]
foreach InVal $xlateInVals {
lappend xlateOutVals {}
}return $xlateOutVals
}
John Mercogliano
Sentara Healthcare
Hampton Roads, VA -
June 13, 2008 at 12:20 pm #64505
Darren Tomlinson
Participanti 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.
-
June 13, 2008 at 12:32 pm #64506
Jim Kosloskey
ParticipantDarren, 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.
-
July 21, 2008 at 7:09 pm #64507
Jim Gibson
ParticipantWe 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. -
July 29, 2008 at 7:21 pm #64508
John Mercogliano
ParticipantDarren, 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 -
August 6, 2008 at 1:56 pm #64509
Kevin Crist
Participanti 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]
-
August 6, 2008 at 7:35 pm #64510
John Mercogliano
ParticipantKevin, 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
-
-
AuthorReplies
- The forum ‘Cloverleaf’ is closed to new topics and replies.