hi…thanks for the pic and the reply…
when I save a form, it shows scanned documents…but the thing is…there is no small versions showing up in the encounter page as shown in the screenshot…I guess you are using 3.2.0 of openemr…but, this thing doesnt work in openemr 4.0…in the encounter screen it is shown just blank…if ou want to see the document, then one must click edit and see the document scanned…
OH,
Well I don’t have 4.0.Alpha/Beta at all.
I didn’t even know that I could actually get the code for it, just see the demo. I guess I should get into the repository hunh?
I guess that you are only getting the output from print.php when you hit edit, and not at any other time. Maybe it’s a difference in that controller file. Basically we are nesting href’s/iframes like russian dolls, and that may be an issue. The code only uses print.php, and not view.php, cause all “view” does is call “print”.
I’ll try to find out.
Just click the download button the page and it will download the zipped file. Extract the zipped file in your htdocs forlder of xampp…and rename it to “openemr”. please remove the previous openemr directory to somewhere else. Now open the newly copied openemr directory and go to sites/default…here you will see a sqlconf file…its a php file…open the file in notepad/wordpad/notepad ++ and edit the following:
Thank you for the links. I had downloaded that, but the “3.0” in the file name kept me from ever doing anything with it.
I see what you get in 4.0…. an index page. Yuk. I guess it is useful sort of…but YUK. Looks like this whole chunk of the EMR is different now.
Is this what you are seeing???
Ya i get this thing…now when you click on “done” on the bottom of this page…it takes you back to the encounter page and there you see nothing execpt a grey band…i was just thinking of atleast a link with the name of the image or uploaded document. when you press on that link, it opens in a modal window to show you the file…like the ID card view in the present version…4.0
Looks like it really needs to be totally re-written.
I believe there are depreciated functions etc… in the code as is anyway. I sent a message to the original authors about permission to update it using their same sql update script and all that, but it looks like it is just worth totally re-doing. It really would be a nice feature. I know that other folks are planning to do an embedded drawing program for injury locations and surgery planning. I personally am working on an external drawing program that just produces the image for upload.
Well, this forum is about OEMR and not peripherals., but I will respond a bit.
The program is in a dephi based engine that can use DirectDraw.
The idea is a professional looking diagramming interface that creates a simple overlay drawing surface on a view of a 3d image, then renders it.
I am not right up to the point of posting a demo or screenshots, but imagine a dolly image where you select a body part, rotate it to the desired angle, then select standard sprite marks or tooltips to write on the image.
The final step is to hit the integrate function that does renderings of the 3d object you are drawing textures on, and export them as a animated gif, png strip, pdf, collage, or single image. It saves the image to a file, as well as copying it to the clipboard. It then opens up your default browser to your pre-selected openemr installation.
I wouldn’t know how to get you further into the emr than that at this point, but after that point you just have to navigate to the patient, use the scanned image form and post it. I think running an app on the machine would be a lot faster and more precise than something with the performance of a Java game. I like the idea of being able to draw ablation spots on a 3d atrium, or even import models or images from a cat scan. I imagine that some folks would like a running record of EKG’s and all that right in an encounter, and be able to have an interface that looks as slick as what they are used to seeing straight from Medtronic. The same program will be good for client presentations if I get enough 3d models into it (“Here is where I am gonna burn holes through the wall of your aorta!”).
That reminds me. I may want to add audio/visual MIME types to the list… I am sure the regular documents interface must be able to do this already.
More I think about it, the more I think that using the regular imported documents index rather than a secondary one is really the way to go for encounter-specific stuff. It’s a duplicate system, y’know?
Yeah, I better check the version I have posted. That late-night stuff isn’t very smart.
I’m gonna do a clean 3.2 install and see what package should be uploaded. I did a lot a stuff at the office, and some here at the house, and some via RDP. I better get that straight first. I will then get rid of the depreciated code and post a (hopefully good) version.
So first I understand that yourPHP version (which must not be the same as the one I got with the xampp install for 3.2.0) would not work with the depreciated function at all, right?
You then saw code that looked like this:
// we give the file a unique identifier
$file_new_name=date ("Y-m-d-H-i-s-");
$file_new_name.=$_SESSION['pid'] ; //add patient id
//save the file extension
$file_ext=$HTTP_POST_FILES['document_image']['name'];
$extension=substr ( $file_ext , -4);
$file_new_name.=$extension;
// we check for a valid type of file.
if (($HTTP_POST_FILES['document_image']['type'] == 'image/gif') ||
($HTTP_POST_FILES['document_image']['type'] == 'image/jpg') ||
($HTTP_POST_FILES['document_image']['type'] == 'application/pdf') ||
($HTTP_POST_FILES['document_image']['type'] == 'image/pjpeg') ||
($HTTP_POST_FILES['document_image']['type'] == 'image/jpeg') ||
($HTTP_POST_FILES['document_image']['type'] == 'image/bmp')){
$checktype='ok';
}
if ($checktype!='ok') {
echo ("<br><span class=text>Only .jpg, .gif or .bmp images can be uploaded.<br></span>");
die ();
}
…and your version has the lines for mime type .pdf right?
…then you changed $HTTP_POST_FILES to $_FILES in a total of eight(8) locations in the file including waaaay down near the bottom. Next, you are reporting that after those changes, you are getting the (erroneously worded) message about file types when you attempt to upload a .pdf. Correct?
BTW, I did a clean xampp install, and then added the pack from the download. It worked.
I noticed that in php admin, I have this notice about my php version:
“Your PHP MySQL library version 5.0.51a differs from your MySQL server version 5.1.33. This may cause unpredictable behavior.”
That means with the depreciated code, 5.051a still runs the code. Perhaps the compatability issue is with OEMR 3.1.x, though for the life of me I can’t see why that would be so. The change I made to this old form seems so minor…Just adding mime types and a frame to display pdf’s
…and your version has the lines for mime type .pdf right? …then you changed $HTTP_POST_FILES to $_FILES in a total of eight(8) locations in the file including waaaay down near the bottom. Next, you are reporting that after those changes, you are getting the (erroneously worded) message about file types when you attempt to upload a .pdf. Correct?
Yes the lines for mime pdf are there and I did a find and replace all that had $HTTP_POST_FILES to $_FILES
I am NOTgetting any errors after I make the change and the pdf is embedded in the encounter and shows fine in both encounter and scanned document form.
>Oh<
Posting the problem after the solution made me think there was still a problem! Doh! So everything is fine and I should upgrade the code and re-post.
Excellent.
Thanks JimmyFoo
The code that is there works, but i don’t think I have corrected the warning message. I also need to allow other mime types. Give me an hour after this post, and it shall be so.
OK, December 14 version posted. It is tested with 3.2.0 only. Code that I know to be depreciated I have snuffed, and a big load of mime types are allowed and filtered.
The subject here is nearly 4 years old but it has become a new issue to me. Was glad to have found it but I noticed that the contributed ‘documents’ form is still very old and does not support pdf files - and the updated form from Art is not at the URL up there any more.
Has there possibly been a better solution to “attach document to encounter” during the last three and a half years?