Notifications
Clear all
Topic starter
Hello,
Below is a copy of how our address of an MD address prints out. As you can see the State and Zip Code go beneath the City (City is El Cajon).
How can I get the State & Zip Code to print next to the City?
Any help is appreciated.
Thank you,
Emma Parker
Corinne Ancona-Young D.O, MD
505 N. Mollison Ave Suite # 201
El Cajon,
CA, 92021
Posted : January 18, 2017 6:32 am
From what is this printing? Could be simply a report form layout.
Posted : January 18, 2017 7:12 am
Topic starter
It's printing on a letter we send to the referring doctor.
Thank you for your response!
Emma
Posted : January 18, 2017 7:55 am
Then I am guessing that the format of the letter has that extra carriage return embedded.
Can you copy/paste the letter here?
Posted : January 18, 2017 8:10 am
Topic starter
When I built the letter I used the "Insert Symbol" list and chose "PATIENT.REFMDADDRESS" and that is how it came out below. Which appears to be on one line, but as you saw it puts the State and Zip Code below the City.
{DATESTAMP()}
{PATIENT.REFMDFIRSTNAME} {PATIENT.REFMDLASTNAME}, MD
{PATIENT.REFMDADDRESS}
RE: {PATIENT.FIRSTNAME} {PATIENT.LASTNAME}
DOB: {PATIENT.DATEOFBIRTH}
Weeks gestation: {OBSANY("Gest age")} EDD: {OBSANY("EDC")}
Dear Dr. {PATIENT.REFMDLASTNAME},
Thank you for referring {PATIENT.FIRSTNAME} {PATIENT.LASTNAME} to the Sharp Diabetes Self-Management Education Center. Your patient has received an Initial Assessment and Comprehensive Diabetes Education in Pregnancy in accordance with the California Sweet Success Guidelines for Care and the American Diabetes Association Recognized Program National Standards. A complete education / assessment note is available upon request.
Assessment/Findings:
| Fasting<90mg/dl | 1hr pp Breakfast<130mg/dl | 1hr pp Lunch<130mg/dl | 1hr pp Dinner<130mg/dl | |
| # of values | {OBSNOW("OPV #1")} | {OBSNOW("OPV #1By")} | {OBSNOW("OPV #1Lot")} | {OBSNOW("OPV #1Rte")} |
| # of abnormal | {OBSNOW("OPV #1 dse")} | {OBSNOW("OPV #1EXP")} | {OBSNOW("OPV #1Mfr")} | {OBSNOW("OPV #1SITE")} |
| Range: | {OBSNOW("OPV #1 VIS")} | {OBSNOW("OPV #1Hx")} | {OBSNOW("OPV #1RNG")} | {OBSNOW("OPV #1VFC")} |
1. {OBSNOW("A&P#1")}
2. {OBSNOW("A&P#2")}
3. {OBSNOW("A&P#3")}
4. {OBSNOW("A&P#4")}
Recommendations/Plan:
1. {OBSNOW("A&P#5")}
2. {OBSNOW("A&P#6")}
3. {OBSNOW("A&P#7")}
4. {OBSNOW("A&P#8")}
{OBSNOW("dchrge date")}{OBSNOW("Disposition")}
{OBSNOW("dischdisp")} {OBSNOW("dchrge er dt")}
If you have any questions or concerns, please do not hesitate to contact the Sharp Diabetes Self-Management Education Center at (619) 502-5937 or (619) 502-5938.
Sincerely,
{USER.FIRSTNAME} {USER.LASTNAME}
Diabetes Specialist Educator
Posted : January 18, 2017 8:22 am
I would suspect that there is a 'hidden' hard return in the contacts data for that provider. The data symbol (PATIENT.REFMDADDRESS) only returns what has been input. Do you know if the individual who created the contact copied it from a digital source instead of typing it in manually?
Regardless of the answer, the solution would be to edit the contact and ensure that no trailing characters follow the city name (best to delete it all and re-enter). While state is coded by a list, I've seen instances where pasted items are used, which means that a leading hard return could be present as well. It's all about the data entry.
As a side note, it appears that you are possibly re-purposing obsterms in your letter (OPV for Blood Glucose values). If true, you may want to review your utilization of obsterms and align them properly. As we continue to move toward data driven reporting, using the proper obsterm becomes increasingly important.
Posted : January 18, 2017 9:52 am
Topic starter
Thank you for all of your help and for the heads up on the Observation terms. Unfortunately that was one of the things we weren't informed of when we began using C-EMR back in 2000 (that we could request customized Obs terms). You can imagine what our forms look like. It's going to be a huge change for us as we will have to have a cut off point with a lot of data on old terms and start with new/accurate ones.
In regards to the hard return issue I can confidently say there is no hard return issue on our end. To be sure I checked it.
Unfortunately I remember this issue came when we upgraded to the 9.8 version. There are still features in the letter that do not work i.e. bold, italic, and underline. That may just be the issue. Of course I just remembered that as I was playing with things.
Again thank you for all of your help.
Emma
Posted : January 18, 2017 11:16 am
It is possible to update OBS terms on all obs values in the system from one term to another with SQL, though GE does not recommend or support doing so.
First you would need to backup your database. You need to make sure you disable any outbound linklogic OBS interfaces before doing so. I also recommend performing a query of all of the data that ou are going to change and output the results to a CSV file. The query itself is fairly simple update obs set HDID=<NEW HDID> where HDID=<OLDHDID>.
You can find the HDID values for the above query with:
SELECT HDID from OBSHEAD where NAME = 'OBSNAME'
Posted : January 18, 2017 4:12 pm
I do not think it to be an issue with the letter functionality itself, rather the data symbol PATIENT.REFMDADDRESS. I've tested the symbol going back to 9.8.0 and it is indeed a defect in the data symbol. Suggest that a defect report be made to GE to have this fixed. Rumor has it that the more that report, the faster it is elevated and addressed.
Posted : January 19, 2017 3:27 am
Yes, there appears to be a GE defect in the REFMDADDRESS field.
I tested and got the following:
January 19, 2017
Leonard Spock, MD
address 1
Boston,
MA, 02134
RE: JOSEPH LOGICIAN
DOB: 01/01/1942
Thus, two errors:
1) it does not include address line 2 that I created for the Ref MD
2) it does a hard carriage return after the 'city," as you noted
Posted : January 19, 2017 4:01 am
Topic starter
I was hoping someone had figured out a way around this, but I guess not.
It's a bummer and a real big pain. Hopefully, with the newer versions it's been fixed.
We're supposed to upgrade, however, I don't know when exactly that will be.
Again, thank you for your time and assistance in the matter.
Much Appreciation,
Emma
Posted : January 19, 2017 4:36 am
Topic starter
Thank you Lee, I will report it!
Posted : January 19, 2017 4:42 am
Topic starter
Thank you "rwilliams" I may have some more questions for you, at a later time. Would you mind if I conversed with you on this?
I would very much appreciate this.
Thank you,
Emma Parker
Posted : January 19, 2017 4:47 am
We have this same issue, I wrote a function to fix it.
Instead of {PATIENT.REFMDADDRESS}, our letters call {fix_address_format(PATIENT.REFMDADDRESS)}. The function is defined in usrlib -custom.txt (we created our own usrlib file for custom functions), and the out-of-box usrlib.txt was modified to include usrlib-custom.txt in the load commands. Here is the function:
fn fix_address_format(a){
// "a" represents PATIENT.REFMDADDRESS or other address whose display is
// is incorrectly showing the State and Zip on a separate line
// 1-15-2013
local b, c, d, e
if a="" then return "" endif
e = array()
b = getfield(a,"\n","\r")
while match(b,"") > 0 do remove(b,match(b,""),1) endwhile
c = size(b)
for d=1, d<=c, d=d+1 do
if d=1 then e[d] = b[d] + "\r\n" else "" endif
if d=2 then e[d]= b[d] + " " else "" endif
if d=3 then e[d] = ReplaceStr(b[d],","," ") + "\r\n" else "" endif
endfor
return str(e,"")
}
Posted : January 19, 2017 5:21 am
Not a problem. Send me an email if you need specifics.
Posted : January 19, 2017 6:05 am
Page 1 / 2
Next
