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

Dealing with pipes (|) or carrots (^) in data returned in a delimited data symbol

MEL, SQL, Oracle

Last Post by Anonymous 1 second ago

5 Posts

3 Users

0 Reactions

54 Views

RSS

mkherman

(@mkherman)

Posts: 53

Trusted Member

Topic starter

MEL gurus-

I have a form that uses multiple delimited data symbols, specifically prob_after, prob_list_changes and list_assessments.

The issue I am having is when a user enters a pipe or a carrot as part of a problem comment, problems assessment, or other field that is returned in the data symbol.

This causes errors in the form because when you parse the array, there are less than the number of expected elements in the elements of the array.

I hope I am missing something simple, but am struggling with how to deal with the 'bad' data.

Any suggestions?

I have thought of using the none delimited symbol and match on a carrot or pipe. Then try to replace it in the delimited symbol, but am concerned that I will overwrite a pipe or carrot that is suppose to be there.

(I have submitted an enhancement to GE that it would be great if the delimited symbols did not return data with characters used to parse, but that could take awhile).

Thanks for any idea or suggestions!

Mary Kay Herman

Posted : September 22, 2015 12:39 pm

aaltotsky

(@aaltotsky)

Posts: 129

Estimable Member

SQL update may help you if you have a few cases with delimited symbols.

You can have a trigger that will filter pipes and carrots out of input field.

I recommend to replace them with other similar symbols:

For example: for carrots you may use "Modifier Letter Up Arrowhead" (U+02C4 or ˄)

and for pipes "Latin Letter Dental Click" (U+01C0 or ǀ ). Also 'divides' : U+2223 ( Alt+8739 or ∣).

See all 3 (pipe,Dental Click and divides): [|ǀ∣]

Here is for more info: https://en.wikipedia.org/wiki/Vertical_bar

Posted : September 22, 2015 5:15 pm

ronmoses

(@ronmoses)

Posts: 158

Estimable Member

While there is merit in aaltotsky's suggestion, I would have to advise against implementing a trigger unless it's absolutely necessary. Even in expert hands, they can have unexpected consequences, and it can be difficult to identify them as the cause of any resulting problem. Over the past three years we've implemented a total of four triggers for various reasons, and have ultimately removed three of them due to unforeseen problems. The only remaining trigger prevents any deletes from a specific table in order to counter a very destructive bug in the application, but it's a table only IS would ever be touching. So it's a very low visibility item, and everyone in the department is aware of its existence.

In addition to the technical concerns, you're altering data entered and signed by a provider, which could raise eyebrows during an audit. That doesn't mean you can't do it, it just means you want to get a sign-off from your compliance department before you do anything like this.

The simplest solution, if not the most realistic or thorough, would be to train users not to use those symbols. But I think we can agree that's not always going to work out.

If you must sanitize this data, the proper place to do it would be in the originating form. The character replacements can be handled there before they get anywhere near the database. Of course that may be problematic if you don't have the ability to modify that form, or if there are many potential forms in question.

So all that being said, the absolutely ideal place to handle this is in your form, prior to parsing it out. But if that string comes in with delimiters already in place, and you can't distinguish them from the erroneous characters, then that's not an option either. I don't know what you're working with, so I can't answer that for certain.

I realize I haven't given you an answer, but I thought it might be helpful to have an idea of your broader options.

Posted : September 24, 2015 5:05 am

mkherman

(@mkherman)

Posts: 53

Trusted Member

Topic starter

Thanks for the feedback, cleaning up the data at the database level is not really an option.

We have tried to train users to not use these characters- but occasionally they still do. Sometimes I think it is even by accident. As I mentioned in my original post- it would be best if GE could solve this by either not allowing those characters to be used, or clean it up when a delimited symbol is used.

The main issue I am having is with a | in the problem comment.

If this has been done- then even a simple function pulling in the problem name, icd9 and icd10 code causes problems.

Simplified version of my issue but with this function- if there is a | in the problem comments, I get an error Bad Value or Bad Index because there is no element 8 (ICD10 code).

Just was curious if anyone had dealt with this before.

{fn fmtprblist(){

local results=""

local strprb=prob_after('delim')

local prbarr=getfield(prob_after('delim'),"|","")

numprb=size(prbarr)

For count=1, count<=numprb, count=count +1

indivprb= getfield(prbarr[count],"^","")

results = results + if results<>"" then HRET else "" endif + indivprb[2] + " ICD9: " + indivprb[3] + " ICD10: " + indivprb[8]

endfor

return results}}

Thanks for the suggestions.

Posted : September 24, 2015 5:50 am

aaltotsky

(@aaltotsky)

Posts: 129

Estimable Member

Here is the regex expression that you may use to spit the string:

\"(?:[^\"])*\"|[^|]+

The following string will be spitted on 4 parts:

"My bad pipe(|) string"|"regular string with inside double quotes"|456|somthing

Try http://regexpal.com/ to test your regex.

Posted : September 24, 2015 6:49 am

24 Forums
9,940 Topics
39.9 K Posts
1 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