Few years ago we had explored orthanc-server as an alternative to current couchdb / documents folder. At that time extra effort in installing and managing additional server was a big issue. Since then advent of docker has simplified the installation and maintenance of these servers. For installations that are heavy users of documents deploying the dicom server will be a robust alternative.
I’m reengineering this now. I’m adding two viewers depending on use case. One will be orthanc compatible and the other file/database compatible. Either on the fly import to zip on directory based.
Hi All,
I’m close to having this ready for v5.0.2(4). I upgraded our existing DWV viewer to 0.27.0 and cleaned up some integration issues from initial implementation 3-4 years ago.
I added several new tools, DWV help, image tag overlay, popup of most all tags, file loader by folder, zip, url or single image. Implement viewer from patient documents where one can pop out to full screen window or view in documents UI or select from main menu to load images from any file/url source.
Here is pop out:
Tags popup:
File Loader:
In documents(still needs work)
So I should have a patch version for testing in next day or two.
3 Likes
So I can’t seem to decide if we should auto zip a folder import then store zip to documents folder or store the individual files from the folder import! Maybe in v6 i’ll give an option but for v502 I just want anything new as default behaviors.
Maybe some have an opinion or other workflow concerns.
1 Like
hi @sjpadgett ,
Will it all be tracked as one document? If so, then would go with the zip. Note that issue with individual files could be name clashes (OpenEMR deals with this automatically, but could maybe be a pain).
Hi @brady.miller,
I was thinking i’d zip the selected folder, use directory name as new zip name then store zip as if user imported a zip file.
I think user can opt to download studies as zips from radiology labs but i’m unsure what that structure looks like and hope I can find an example of one as i’m sure it will come up.
I have also considered storing a file directory pointer/url to images that may reside in cloud or on server but will opt to put a stand alone viewer in a tab started from menu somewhere.
Viewer has ability to edit/enhance/draw on images and store the the new state where state can be imported back onto the original image. I’m not sure i’ll deal with that now as it is better suited to v6 as i’d need to touch a bunch of core.
So for now I guess i’ll zip up directory as a zip(only one level of that directory). At least that’ll save some file management by user.
Thanks.
1 Like
Here is a video to show some of what is in viewer rework.
Viewer access can be from several places
-
Patient Documents where it may be opened in dialog(for quick access), the view panel or poped out in new fullscreen window.
-
Menu Miscellaneous->Dicom Viewer where images file or folder from any location can be selected.
Any feedback or suggestions should happen soon so if I need to address any of community concerns, I can address them before I merge PR for patch 4 release. All that is left to do on my list is adding an auto zip of images folder upload to document category.
I think this will be a nice feature upgrade for everybody.
2 Likes
Just put PR up: DICOM Viewer Rework by sjpadgett · Pull Request #3730 · openemr/openemr · GitHub
A video is here: Webservices, DICOM and DICOMSR support
Will update if we put a temp demo up or I just bring into codebase for normal demo resets tonight.
Update: have a demo for my branch here: https://www.open-emr.org/wiki/index.php/Development_Demo#Alpha_-_Up_For_Grabs_Demo
I uploaded some demo mri images w/slices. I plan to merge tomorrow then work to get patch 4 out by Monday.
@pcgarell note the demo that Brady and I put up last night for testing this. So if ya want to play with, go there. admin pass : https://two.openemr.io/openemr/index.php
1 Like
@gutiersa
Would you be willing to put up a wiki for this project using the info i’ve provided in threads(or I can give more)?
Hope your foot is healing and hopefully they gave you plenty happy pills for relief.
Hi all following this thread.
I’ve finishing with improved DICOM viewer and have integrated with v5.0.2 via upcoming patch 4 and with v6.0.0. Attached is a pre patch for your use so just follow normal patch procedures. Version status will be indicated in About.
@pcgarell Let me know if i’ve missed anything.
I was able to install the pre-patch, but I can’t get it to load any images. I tried uploading a folder with several .dcm files (not zipped) using the Zip Directory of image slices file chooser (hoping OEMR would zip them for me) and got this:
Error number: occurred while uploading file named: DicomStudy.zip
The system does not permit uploading files of with size 0.
I then tried zipping the .dcm files together, and used the same Zip chooser button, but the file chooser doesn’t see the zip folder.
I put the zipped files in a new parent folder (so the chooser would see the new folder) and no other files or folders in it, but got the same error as above when I tried to upload.
Loading individual .dcm files (or multiple with CTRL+click) does load the files, but when I try to open them I get:
“A load error has occured. See log for details.”
Try unloading a pre zipped file of .dcm using normal upload. ie old method
@brady.miller
The demos patient document uploads have .dcm amd zip files blacklisted!
hi @sjpadgett ,
I’ll look into that. Guessing it’s the demos with demo data. Will be able to fix that in the demos by simply turning that feature off when using demo data (I’ll add it to the stuff I’m doing for the utf8mb4 changes).
Using the individual file chooser I am able to upload a set of zipped .dcm files, but when I try to open it in OEMR no images are displayed. The viewer starts up, but no images (and no error message).
@pcgarell oh, there jpgs? Haven’t tested these(it’s why zip fails as I don’t allow any extensions but .dcm). Are they the only image type you receive? Check out this web page: Error Messages · ivmartel/dwv Wiki · GitHub
Still, i’m tenacious and don’t give up so, hang in there. Especially since I had another eye surgery this morning and seeing is a chanledge.
Can you send me a test image?
1 Like
I may have a local settings issue. Let me test a few things, while you rest your eyes. I’ll let you know once I have ruled out local issues.
@sjpadgett , demos that are using demo data now have the correct document upload permission setting. Just restarted the main 5.0.2 demos. And the rest of the demos will be working correctly after the next demo farm restart (in 20 or so hours)
1 Like
Yes I would, of course.
Thanks, my foot is healing well. Some of hardware should be coming out soon. Pain is well controlled with NSAIDs (thankgoodness)
I will review this thread this weekend and get started on the wiki.
I had an anonymous MRI data set made and just tried to upload on the 5.0.2 demos and got the same errors as when I tried on my local instance. These are .dcm files. Loading them individually results in the error mentioned above, zipping a single study together (17 files in this example) makes the zipped folder invisible to the Zip Directory file chooser.
I white listed everything that had DICOM or zip in its name.
In my data set the .dcm files are in a folder called DICOM. There does not appear to be anything other than .dcm files in that folder. My understanding is that the data we are trying to import (in addition to the images) is stored in the DICOMDIR file (patient name, DOB, DOS, etc.). Should I move that file to the DICOM folder?