Welcome to the NEW CHUG— your ultimate destination for cutting-edge insights and discussions at the intersection of healthcare and technology.

Our platform is dedicated to exploring the dynamic landscape of healthcare technology, empowering professionals, enthusiasts, and innovators alike with the knowledge and resources to navigate the rapidly evolving field.

From telemedicine revolutionizing patient care to the transformative potential of artificial intelligence in diagnostics, we delve into a myriad of topics shaping the future of healthcare delivery. Whether you’re a seasoned healthcare IT professional, an aspiring entrepreneur in the digital health space, or simply curious about the latest innovations, our curated content, expert interviews, and thought-provoking articles provide a comprehensive exploration of healthcare technology’s most pressing issues.

Join us as we navigate the forefront of innovation, driving forward the transformation of healthcare for a healthier, more connected world.

Have questions or suggestions? Please use the contact button below.

Notifications

Clear all

MEL Trace question

MEL, SQL, Oracle

Last Post by Anonymous 1 second ago

6 Posts

3 Users

0 Reactions

67 Views

RSS

rtardif

(@rtardif)

Posts: 55

Trusted Member

Topic starter

Hello. I have this line of code that is giving me weird results in the MEL trace file, and thus, a problem in the form. I have a line of code that attaches four 0000s to the end of the patient's PID #. Since the patient can have more than one Participant ID #, I have the form looking at the last value and adding 1 to get the next sequential #.

TMPVAL = replacestr(str(val(OBSPREV("PARTICPNT ID")) + 1),".00","")

Below, is the portion of the trace file where this line is executed. As you can see, the value in the last Participant ID # is 20080101278260002 (PID portion changed to protect the innocent). However, when it goes to add the 1, it converts the number to 20080101278260000.00. It's like the 2 is being converted to a 0 for some reason. This is the only patient where I'm having this problem. This code has been working for all other patients. Any clues why this is happening?

07/01/2019 Process Id #3968 ML Thread [MelTrace] execute> call OBSPREV("PARTICPNT ID")
07/01/2019 Process Id #3968 ML Thread [MelTrace] results> "20080101278260002"
07/01/2019 Process Id #3968 ML Thread [MelTrace] execute> call VAL("20080101278260002")
07/01/2019 Process Id #3968 ML Thread [MelTrace] results> 20080101278260000.00
07/01/2019 Process Id #3968 ML Thread [MelTrace] execute> 20080101278260000.00 + 1
07/01/2019 Process Id #3968 ML Thread [MelTrace] results> 20080101278260000.00
07/01/2019 Process Id #3968 ML Thread [MelTrace] execute> call STR(20080101278260000.00)
07/01/2019 Process Id #3968 ML Thread [MelTrace] results> "20080101278260000.00"
07/01/2019 Process Id #3968 ML Thread [MelTrace] execute> call REPLACESTR("20080101278260000.00", ".00", "")

As always, your help is greatly appreciated.
Robin Tardif

Posted : July 9, 2019 12:17 pm

rtardif

(@rtardif)

Posts: 55

Trusted Member

Topic starter

I found another instance where a similar thing is happening to several different patients. I have a display field that has the following code: LAST_SIGNED_OBS_VALUE("PARTICPNT ID")

It reports the correct value of 5446930001. When I change the code to val(LAST_SIGNED_OBS_VALUE("PARTICPNT ID")) the result is a completely different value of 1151962705.

How is that possible? Since the first value is a number, the value shouldn't change just by putting the val() around it. Is this a memory address? A faulty computer processor? Me going crazy?

Has anyone else seen this? This is occurring in CPS 12.3.2, by the way.

Thanks again.
Robin

Posted : July 9, 2019 4:06 pm

mhogg

(@mhogg)

Posts: 12

Active Member

It appears that val returns a numeric value as a float data type that has to round the value because it is so large. I did a little testing. 20080101278260001 and 20080101278260002 both round down to 20080101278260000, whereas 20080101278260003 rounds up to 20080101278260004.

If you want to use this logic, you're going to have to use a smaller number to make it work.

Posted : July 11, 2019 8:50 am

rtardif

(@rtardif)

Posts: 55

Trusted Member

Topic starter

Thank you for your help. Because I can't change the length of the existing PID, I decided to use a different method to create a unique application number. That way I don't have to deal with these long PIDs.

Thank you for explaining what was going on. I thought I was going crazy.

Robin

Posted : July 11, 2019 9:27 am

dcarpenter

(@dcarpenter)

Posts: 323

Reputable Member

So this is the PID + 4 digits? If the only thing that should change is the last 4 digits, then we can separate the PID from the last 4 digits, modify the smaller number, and then recombine them. Does that work for your scenario? This Patient ID in your example seems very long, but as long as the last 4 digits is always the ones that change, this can work.

Here is an example of what I mean.

{//This is the Obsterm value you provided

PartID = "20080101278260002"

//get the length of the Participant ID

len = size(PartID)

//Grab the last 4 digits

tempNum = sub(PartID,len-3,4)

//get the ID without the last 4 digits
tempPartID = remove(PartID, len-3,4)

//basic math. This turns the "0002" to "3"

TempNum = val(TempNum) + 1
ZeroStr = ""
//check for how many 0's need to be added before re-attaching
cond
case TempNum <10
ZeroStr ="000"
case TempNum <100
ZeroStr ="00"
case TempNum <1000
ZeroStr ="0"
else
ZeroStr =""
endcond

//Reconnect the pieces into a Participant ID that is 1 more than the last one.

TMPVAL = str(TempPartID,ZeroStr,TempNum)}

Let me know if you have any questions

Posted : July 11, 2019 11:44 am

rtardif

(@rtardif)

Posts: 55

Trusted Member

Topic starter

Thank you for your help. I ended up using a different method to create a unique application number. I'm using a date/time stamp with other info. I should have done that in the first place, but I was trying to give the person creating the reports an easy way to sort and group the data.

Again, thank you. I do appreciate the help.

Robin

Posted : July 12, 2019 4:01 am

24 Forums
9,940 Topics
39.9 K Posts
0 Online
6,470 Members

Forum Icons: Forum contains no unread posts Forum contains unread posts

Topic Icons: Not Replied Replied Active Hot Sticky Unapproved Solved Private Closed