penguin8r wrote on Tuesday, November 09, 2010:
If you open an encounter generated within CAMOS, then click Print this Encounter -> Print (PDF),
the output is basically just all the CAMOS text smashed together, unformatted, with no paragraph breaks.
What might need to be done to correct this?
The print to HTML option seems to give proper output, but PDF is more useful for printing to paper, to fax, etc.
visolveemr wrote on Wednesday, November 10, 2010:
Hi,
We had generated the CAMOS encounter and print the same in both PDF and HTML format. We didn’t face any formatting issues in print(PDF) with OpenEMR-3.2.0 and development tip.
It would be more helpful if you mention the OpenEMR version and OS used.
Thanks
ViCarePlus Team,
www.vicareplus.com
services@vicareplus.com
penguin8r wrote on Wednesday, November 10, 2010:
sorry, should have mentioned that earlier. It’s version 4.0.0-dev, copied from CVS a couple weeks ago.
It’s running on Ubuntu 10.04 LTS, 32-bit.
I’ve been trying to figure out what’s wrong in the rx_print.php in /interface/forms/CAMOS , since that seems to be where the problem is coming from.
penguin8r wrote on Thursday, November 11, 2010:
FYI to anyone else who might be using this, there’s an error in rx_print.php that causes the printouts to have the phone number listed as both the Voice & Fax number on the printed version.
It’s an easy fix, just something to watch out for if you print data from CAMOS or use it to create & save or fax PDF versions
markleeds wrote on Thursday, November 11, 2010:
I have continued developing CAMOS and have a few new interesting features which have been working well for me. I bring this up because I recently implemented PDF prescription printing. The way I have it set up is that if a single encounter note is generated, the prescriptions are appended as additional pages. I did this as a necessary convenience that I have “needed” for a while. As I order more things on prescriptions, like blood tests, MRIs, X-rays, DME, etc… I find myself jumping around a lot to print my notes and prescriptions. This way, I print a single PDF and get everything. Also, some other cool features. I am going to share soon so others can test.
arnabnaha wrote on Thursday, November 11, 2010:
Hi Markleeds…
It will be great if you share that pretty soon, within a few days to say…I was looking for that feature…You can put the new code on github, so that it gets tested and incorporated in the official openemr repository codebase…Please do it as early as possible…
Thanks…
Arnab Naha
markleeds wrote on Thursday, November 11, 2010:
Arnab,
I am a little out of sync with what is in the repository. The fastest way to get it to you might be email. I can talk you through it if you need help. For the pdf prescription printing, you probably only need to drop in to files into the CAMOS directory. notegen.php and a new file, rxpdf.php. If you have modified your notegen.php, then you can just see the few changes that call on rxpdf.php and incorporate them.
Mark
sunsetsystems wrote on Thursday, November 11, 2010:
Obviously it would be nice if someone will port this to current code. Not good to have updates floating around by email. 
arnabnaha wrote on Thursday, November 11, 2010:
hi markleeds…
Please send allt he files necessary via email to me and i will update that to my fork in the repository as a seperate branch. From that Brady/Rod/tony can upload that to the official openemr codebase…Please send all the files to- superarnab@gmail.com
Thanks
markleeds wrote on Thursday, November 11, 2010:
Rod,
Sorry about that. I am using a pre-3.0 version of OpenEMR. There are some changes to how forms interact with the system since then. I don’t want to accidentally undo anything that Brady has done, so I think I need to go through line by line, at least in the new.php file.
Mark
bradymiller wrote on Thursday, November 11, 2010:
Mark,
Always good to hear from you. As arnabnaha suggest, first step is to get it into a github repo. Then you can get some help (at least direction) porting your changes in. The OpenEMR repo is now in git, and it’s very straighforward (and well documented) to start a public github repository to get your code published there (and begin to port it back):
http://openmedsoftware.org/wiki/Git_for_dummies
-brady
arnabnaha wrote on Friday, November 12, 2010:
hi mark…
I received your mail with the camos file…As per your instructions, i replaced my notegen and added rxpdf.php into my camos directory. i didnt find any button which allows me to print Rx in pdf format.
markleeds wrote on Friday, November 12, 2010:
Arnab,
You are right that there should be a PDF button for consistency of the interface. I did it differently because my primary goal in writing code is to make my job easier. When you click on the link, either from within CAMOS or in the encounter that says “Print This Encounter”, it will print the current encounter note and the prescriptions will be appended to that note.
If you were using CAMOS to print prescriptions entered in the built-in OpenEMR prescription module, PDF printing won’t work that way yet. It will only work the way I described above. It is working great for me because my note and prescriptions all print out at the same time. The only issue is deciding if I should waste prescription paper for my note or throw in a piece of blank white paper before printing.
markleeds wrote on Friday, November 12, 2010:
Brady,
Thanks for the link. I’ll be working on Git for dummies this weekend.
penguin8r wrote on Tuesday, November 16, 2010:
Good to hear CAMOS is still under development!
Another question, when printing from CAMOS, the keywords are printing instead of the data.
That is, if you have the 'patientname" , ‘patientage’ , ‘patientgender’ , ‘doctorname’ variables in the CAMOS form, it displays the correct data in OpenEMR, but when you print (PDF or HTML) , those words show up, instead of the actual patient data or doctor’s name.
Anybody know a fix for this?
markleeds wrote on Tuesday, November 16, 2010:
penguin8r,
That should not be able to happen because the replacement is supposed to happen when the data is saved. This means that ‘patientname’ is not inserted into the database, the actual patient name is substituted prior to database insertion. There is a function in content_parser.php named replace_placeholders() which handles this. It is called twice in ajax_save.php.
penguin8r wrote on Tuesday, November 16, 2010:
Mark,
Thanks for the input, I agree it shouldn’t be able to happen, but it does, over & over, on every system I’ve tested.
I will look into the replace_placeholders function.
Can you email me your newer CAMOS php files so I can try them out? I have production systems where docs would like to use this if we can get it working correctly.
Thanks!
cgenandt_at_gmail.com
penguin8r wrote on Wednesday, November 24, 2010:
For anyone who may be interested in this ongoing issue, I just went looking into the actual DB table entries for the saved CAMOS forms.
The saved data is ‘patientname’ , ‘patientage’ , ‘patientgender’ , ‘doctorname’ , ‘date’
instead of being the actual data.
I will try next with the new CAMOS code & see what happens.
Has anyone else experienced this problem before?
penguin8r wrote on Wednesday, November 24, 2010:
Edit to add: the new version of the CAMOS code fixes the form saving/printing problem. However, it’s not compatible with OpenEMR version 4.0, so back to the drawing board…
Will experiment more with the new CAMOS code & try to see what the problem is.
bradymiller wrote on Saturday, November 27, 2010:
penguin8r,
Can you distribute the most recent CAMOS (basically forked at this point). Mark probably added the replace_placeholders() (which is actually the replace() funciton in the official codebase) into ajax_save.php after he stopped maintaining code in the official codebase. In the current code, it appears the placeholders get put into the database (agree not a good idea since age and date should be a constant (ie. shouldn’t change in the original note evertytime you print it)). Oddly, though, the placeholders are getting converted when i show reports via html/pdf since the replace() function is called in these scripts. Should be simple to get correct behavior (and also continue to support previous notes that contain placeholders) with Mark’s most recent CAMOS files. Awaiting those files to either be emailed top me or posted on github.
-brady