I have activated Couch DB and it works very well. Its just a query…can you clarify, where the documents go after uploading? I mean after activating couch db in the administration and uploading a document to a patient from the patient summary screen, the document can be viewed in openemr but previously I used to find the document under sites->default->documents with a unique patient ID, Now its not there…but where it is?
Another thing is…after I upload a document via the newly added “NEW DOCUMENT” in the miscellaneous section, I get the document under a newly created directory 00 in sites->default->documents (when the default storage location is hard disk) but after activating couch Db again I dont find the document in 00 either.
Third, when I am using hard disk as default storage method, and uploading document nia miscellaneous->New Documents, it goes to 00 directory created under sites->default->documents. But, when I move that document to a certain patient, no new directory is created under sites->default->documents with the patient unique ID.
Hope you can understand my so many complex queries…
When using couchdb you cannot see the individual files, its storing in the couchdb database . You cannot retrieve the files like you storing in the hard disk. CocuchDb database files is located at cochchDBInstallationDir\var\lib\couchdb. The file has an extension of “.couch”.
The Miscellaneous->New Documents script is meant for uploading documents where the patient it belongs to is not yet known. So, it then allows, as you did, moving of the document to the patient once you figure out which document the patient is meant for. In theory, you could load all the patient’s documents in the New Documents screen, but I recommend against it, because then all of the uploaded documents will end up in the 00 directory, which could get a bit annoying with thousands of documents in one directory. As you have noted, once a document is uploaded into OpenEMR (either to a specific patient folder or to 00) it never physically moves even when assigning it to another patient; the thing that tracks the actual patient of the document is in the documents sql table entry (the foreign_id entry). To further explain, the specific reason this New Documents script/method was created, was to allow assigning of patients after automated importing (via the Direct service, that was just added in the codebase yesterday) of patient documents.
Note that the 00 entries also go to the couchdb table, which is why you don’t see them on the hard drive when couchdb is enabled. To better visualize what couchdb is doing, on your browser play with the following:
localhost:5984/_utils/
(When you click on a document, note the pid value, which will be the pid of the patient or will be 00 in the case that no patient has been mapped to it yet)
The point Arnab is making is a problem for Hard Disk storage. Even if you assign patientId’s to the unassigned it will not move from the 00 directory and on a period of time it will increase in number.
I don’t think Arnab is making that point. I think he is just trying to figure out how it works. I think it does make sense to begin considering the question of how many files can go into a directory (I think with NTFS and modern linux formats this number approaches the millions). At this point the ‘00’ directory will store all the documents uploaded into the Miscellaneous->New Documents screen (note I placed a warning at the top of it not to use it when the patient is known) and all the documents uploaded via the direct service will be in the ‘direct’ directory (note the directory is arbitrary since it’s the foreign_id of 0 that is important for the files in ‘00’ and ‘direct’ that allow them to be assigned to patients in the Miscellaneous->New Documents screen).
If there was a concern of getting to many files in one directory, then could consider creating randomly creating a directory(if not existent yet) in documents/00/ or documents/direct/ (0-10000) and placing the file in it. Note for this to work then need to deal with the fact that the Documents class does not work for second-level directories in the documents folder(this fact is what plagues the scanning form); so would make sense to have a path_depth sql_column in documents (default to 1) in documents that simply gives the directory depth of the sql_column ‘url’ entry in documents table to find the file. For example, the depth is 1 currently (only the first item is popped off the path), but in the case of adding another level to the directory (direct/1010), then the depth would be 2. Note that some may say, well why not just take the directory to right of ‘documents’ in the ‘url’ field, but we can not rely on that (the documents directory may be configured to something else, which would then break). The nice thing about a depth descriptor is that even higher level document directory structure would then be supported.
