Clovertech

TCL Proc filter on subfield

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › TCL Proc filter on subfield

  • Creator
    Topic
  • February 3, 2009 at 3:54 pm #50602
    Gena Gill
    Participant

      I’m trying to filter messages based on what is in PID 3.3.  I’m having issues extracting the data in that field in my TCL Proc.  Here’s the relevant section:

      set pidloc [lsearch -regexp $segments “^PID”]

      set pid [lindex $segments $pidloc]

      set pid_fields [split $pid $fldsep]

      set pid_3_fields [lindex $pid_fields 3]

      set pid_3_sub [split $pid_3_fields $subsep]

      set pid_3 [lindex $pid_3_sub 3]

      echo “PID 3.3 equals $pid_3”

      The echo returns a blank, even though I know there is data in that field.  If I set the subfield from 3 to 0, then I get a return, but not when I set any other subfield.

      Any suggestions?

    • Creator
      Topic
    Viewing 10 reply threads
    • Author
      Replies
      • February 3, 2009 at 4:03 pm #66747
        Max Drown (Infor)
        Keymaster

          Could you please post a sample message?

          -- Max Drown (Infor)

        • February 3, 2009 at 4:16 pm #66748
          Gena Gill
          Participant

            Here’s the message for a test patient.  I need to filter based on whether MS4ADT or LA01 shows up in PID3.3.

            MSH|^~&|LA01|MS4ADT||MS4ADT|200902021143|RESULTOUTASCII|ORU^R01|090330198268|P|2.2|||AL|NE||||||2.2b

            PID|1|124899511|36-07-11^^^MS4ADT^MR||SKTEST^BLAIR||199909090000|F||||||||||17417007^^^MS4ADT

            PV1|1|I|SDU^SDUC504A^A^100^OCCPD|1|||^ACCOUNT IN ERROR^ERRORS|||SDI||||||||I||||||||||||||||||||||||||200901200846

            ORC|RE|09033005137^LA01|09033005137^LA01|R0903301153^LA01|I||1^^^200902021140^^ROUTIN||200902021143|CCROSBY||^ACCOUNT IN ERROR^ERRORS|SKAGGS||200902021143||SDU^^SF

            OBR|1|09033005137^LA01|09033005137^LA01|SPCUL^CULTURE, SPUTUM T GRAM STAIN^LAB^SPCUL^^LA01|ROUTIN||200902021140|||CCROSBY||||200902021140|SPU&SPUTUM^^^SPU&SPUTUM^^**&Default Container|^ACCOUNT IN ERROR^ERRORS||||||200902021143||MICRO|P||1^^^200902021140^^ROUTIN||||^^I9||||||||^^^^0

            OBX|1|TX|REPORT^Clinical Report^LA01|1|Specimen/Source: SPUTUM/SPUTUM||||||V|||200902021143|SKAGGS^SKAGGS REGIONAL HEALTH CENTER

            OBX|2|TX|REPORT^Clinical Report^LA01|2|Collected: 02/02/2009 11:40||||||V

            OBX|3|TX|REPORT^Clinical Report^LA01|3| ||||||V

            OBX|4|TX|REPORT^Clinical Report^LA01|4|Status: Preliminary      Last Updated: 02/02/2009 11:43      ||||||V

            OBX|5|TX|REPORT^Clinical Report^LA01|5| ||||||V

            OBX|6|TX|REPORT^Clinical Report^LA01|6| ||||||V

            OBX|7|TX|REPORT^Clinical Report^LA01|7|  GRAM (Final)||||||V

            OBX|8|TX|REPORT^Clinical Report^LA01|8|    Many Gram Positive Cocci||||||V

            OBX|9|TX|REPORT^Clinical Report^LA01|9|    Few Gram Negative Diplococci||||||V

            OBX|10|TX|REPORT^Clinical Report^LA01|10| ||||||V

            OBX|11|TX|REPORT^Clinical Report^LA01|11| ||||||V

            ZOM|1||||M090330079||||||MICRO||||||M090330079|3|H|||200902021140|||||||||||||||||S||||||09033005137^LA01|||||IP1||||||CULTROUTINE|A|V|||CULTURE, SPUTUM T GRAM STAIN||||||||||^^MRO|I|N||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||N|||||||||N

            ZCA|||SDU|||||||||||||||||||||||||||||||||||||124899511|||PROD|$ReleaseId: 12.2.0.0$|$Id: pwic.pad,v 1.180.1.23.1.5, 2008-12-22 17:28:29Z$;$ReleaseId: 12.2.0.0$;$St|$Date: 12/22/08 11:28:29 AM CST$||||199909090600+0000|CST6CDT||||SDU^STEP DOWN UNIT|||||SDUC504A^SDUC504A|SDU^^SF

          • February 3, 2009 at 4:29 pm #66749
            Max Drown (Infor)
            Keymaster

              test.tcl (run by doing tcl test.tcl at the command line)

              Code:

              set fldsep “|”
              set subsep “^”
              set segments “PID|1|124899511|36-07-11^^^MS4ADT^MR||SKTEST^BLAIR||199909090000|F||||||||||17417007^^^MS4ADT”

              set pidloc [lsearch -regexp $segments “^PID”]
              set pid [lindex $segments $pidloc]
              set pid_fields [split $pid $fldsep]
              set pid_3_fields [lindex $pid_fields 3]
              set pid_3_sub [split $pid_3_fields $subsep]
              set pid_3 [lindex $pid_3_sub 3]
              echo “PID 3.3 equals $pid_3”

              Returns:

              Code:

              PID 3.3 equals MS4ADT

              It looks like your code works?

              -- Max Drown (Infor)

            • February 3, 2009 at 6:38 pm #66750
              Gena Gill
              Participant

                Weird, because when I run it through the testing tool and this is what I get…

                PID 3.3 equals

                It doesn’t give me a return.  Since I’m sending to a test system, I think I’ll go ahead and put the proc on the thread and see what happens.  If it doesn’t filter, then there’s no harm done, and I can move on from there.

                If it does filter, then I’ll consider this a bug in the testing tool.

              • February 3, 2009 at 7:42 pm #66751
                Rob Abbott
                Keymaster

                  Are you sure your test data is not corrupted with linefeeds?

                  Rob Abbott
                  Cloverleaf Emeritus

                • February 3, 2009 at 9:28 pm #66752
                  Mike Grieger
                  Participant

                    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)

                  • February 3, 2009 at 9:45 pm #66753
                    Gena Gill
                    Participant

                      No, not two…  It’s the 4th sub-field, which eternally confuses me, as you start counting the first field as zero which maked the sub-field label as 3.

                      I even parsed the original message to be sure.

                    • February 3, 2009 at 10:00 pm #66754
                      Mike Grieger
                      Participant

                        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.

                      • February 4, 2009 at 2:50 pm #66755
                        Gena Gill
                        Participant

                          Problem Solved!  Thanks everyone, for your help.

                          The problem DOES seem to be in the TPS testing tool.  I do get a return in the production environment, and am able to successfully filter messages based on that value.

                        • February 4, 2009 at 3:45 pm #66756
                          Alan James
                          Participant

                            I’m attaching a great little proc that’s pretty versatile for just this sort of use.  Depending on what Gena wants to filter, the arguments for this proc would be

                            {PASSCOND ~REGEXLA01|MS4ADT} {SEGNAME PID} {FIELDNUM 3} {SUBFIELDNUM 3}    to filter both of these messages

                            {PASSCOND ~LA01} {SEGNAME PID} {FIELDNUM 3} {SUBFIELDNUM 3}  to filter only those messages with LA01 in PID.3.4

                            {PASSCOND ~MS4ADT} {SEGNAME PID} {FIELDNUM 3} {SUBFIELDNUM 3}  to filter only those messages with MS4ADT in PID.3.4

                          • February 4, 2009 at 8:51 pm #66757
                            Rob Abbott
                            Keymaster

                              Gena Gill wrote:

                              Problem Solved!

                              Rob Abbott
                              Cloverleaf Emeritus

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