The document management facilities are pretty good due to the fact that they exist and work. I am doing more scanning these days, but I have a few problems with the way things seem to work.
I don’t see any way to delete a scanned document. I know that if I scan for the wrong patient, I can move it to the right one. What if I scan a pdf with a single wrong page mixed in? I guess I could have a dummy account and move it over there. What if I scan to the wrong category or if I later add a new, more appropriate category?
I don’t know if I am wrong and there is already a way to move from one category to another and a way to delete or hide documents.
If not and if there are other needed features in this section, would it be best to work with what is already there? I think it is written in the more difficult to follow OO style.
It would also be possible to write a form with an improved interface that could work with the current document storage system.
I agree that this is a needed feature. I think this should a “HIPPA compliant editor”. These types of changes need to be logged with the reason that the change is being made.
Another way to do it would be to leave the old system to support documents already scanned and to add an optional form that stores binary files in the database instead of the filesystem. The new.php of the form would have the upload interface and a textbox to enter a description of the file being uploaded and the view.php could allow for deleting or transferring to another patient with a textbox to request the reason for change. It would log the change as well.
I am going to look into getting started on this in the near future.
I dont thing the speed will suffer since they will be confined to a table that is used only when accessing documents
The overall database size. For a regular, 2-3 doctor practice I am seeing db dumps weight about 100 MB per year,
While the documents scanned weight about 600 MB year
So you can talk about a total of 500MB per year per doctor as a raw, safe calc,
For out of premises backup I dump the db and then sync the files under a ssh tunnel,
Overloading the db will force to set a mirrored database as an out of premises backup alternative estrategy.
Are you using rsync? That’s what I’m using and it’s great.
My documents directory right now is at 23MB which is since January this year. We are just a 1 doctor practice and not that busy yet. Also, I am just now getting to the point of scanning everything. I scan almost everything at 200x200, which is legible, but not great.
I guess moving the documents into the database might not be a great idea at this point.
Of course, the good thing about doing this as a form is that it makes it optional.
In terms of back-up I use the MySQL master-slave replication. I replicate to the slave every 60 seconds to give me real time back up.
I also have a slower frequecy replication using rsync. The rsync executes every 24 hours. This helps protect against malicious SQL commands that damage the database.
A malicious SQL query is quickly replicates to the slave (frequency 60 sdeconds).
I store all scanned documents as PDFs. I use Paperport for scanning and manipulating scanned images. You can just feed a bunch of pages into the scanner and they go straight to PDF. You can also read PDFs within a web page. The usual medical records I get from a hospital might be 20-30 pages and scans into about a 1.6MB PDF. In Paperport, you can also take other formats, like JPEG, and put them into the PDF. I use the free version that came with my scanner. I am using a Brother all-in-one machine. It never chokes on many-paged documents and it’s pretty fast.
I am a new user. I am considering scanning my documents into OpenEMR.
My questions are: 1. Is it still recommended to store scanned documents within the OpenEMR database or should they be scanned elsewhere as suggested by Dr. Bowen. 2. Has anything changed since this older posting, perhaps in the newer versions of OpenEMR there are better ways to manage scanned documents.