Webservices, DICOM and DICOMSR support

OpenEMR Development
#42

Hi @pcgarell

No, we are not setup for reading/parsing that file. That’s more for a PAC setup.
We are file based for just a folder/study of .dcm images. Each image has the tag information embedded in it’s header. For out viewer, the image header has to meet the dicom standard i.e specific metadata must be present for the viewers parser.
I have seen example dicom images that do not include certain meta like DICM included in meta header. This is my concern with your issues.

The folder upload will not show files in folder but merely chance to select a folder.

As for folder content on upload, I filter for only .dcm files and will skip all others. I also have made changes to the upload controller to be more forgiving in uploads and have attached a new patch that includes plus recent bug fixes.

This would go much faster(troubleshooting wise) if you sent me just one dicom image slice from a study you’re trying to get uploaded. I can open it and eval meta/header for our parser. If there is something I can do to support image then, i’ll do my best. Send to my email sjpadgett@gmail.com.
Regardless, I need to get this straighten out soon as this is holding up patch 4.
This patch has nothing to do with image parsing but some uploading changes you won’t necessarily see.

removed for new patch later in thread

#43

Very much appreciated for this really needs to be document. Viewer has many moving parts but the basics for things like folder and image uploading will be where most folks will likely have some trouble initially. Also, what our viewer requires for dicom images. This I will describe better for you once I get an okay from current testing.

Glad to hear you are healing and your pain is well managed(that’s the biggy) and look forward to this project as it’s a pet of mine…

1 Like
#44

I have been interested in this topic for a while. I have been thinking for a long time about possibly using Postgresql with OpenEMR. Is it possible that we could just use pgsql alone, for all of openemr needs including the imaging needs, and not require two different databases (mysql, couchdb)? I just thought I put that out there.

I would love a solution that would be simple and had a small footprint. ie. Took up small space. I would like independence from the big guys (amazon, google, microsoft, oracle). Is that asking too much?

I am familiar with PostgreSQL!

#45

Hi @pcgarell, So you know i’ve figured out the issue with your images. Well your images weren’t the issue but viewer jpeg-lossless decoder failing on decode. So i’ll have a new version up sometime tonight.

#46

I would want access to studies from the patient note. During the patient visit, is when I want to look at these. I am usually writing a note while I am talking to the patient about imaging results.

#47

Hi Sandra,
I’ll put this on the list for v6.0. For the patch I can only touch so much in regards to what is feasible for a patch. However, for v6.0 I plan much more for the viewer including a Orthanc plug in.

lol if you think about it, if I keep developing on v5.0.2 i’ll have nothing new for v6.0

1 Like
#48

@pcgarell and others following
This I hope will be final test patch.
I noted on the test files sent to me that the folder/directory of 17 images each have the same image sequence number and the same patient position.
A study should not have this and the viewer will let you know about it on load. Anytime you get a load error check browser console for clues to type of errors. Hopefully this was intentional for test purposes but, it kind of through me a curve.

Also, on folder loads app will do its best to drill down a directory tree to a folder containing the sought after dicom images as long as directories are empty till final directory.

The images sent to me do have the tags embedded and parse correctly.

#49

No curve ball. Those 17 files in the zip folder are 17 different saggital images through a lumbar spine using a MRI sequence (set of parameters on the MRI machine to obtain the images). Perhaps when it got anonymized those settings were reset. But I actually I think the sequence number will be the same for that part of the MRI study. There were in total 8 sequences (referring to 8 different MRI settings)
for this single study, which is standard to adequately image the lumbar spine. I only sent you the one sequence (saggital, T2) for testing purposes.

I tried the new dicom_patch with partial success. The individual file chooser sees both individual .dcm files and zip folders. The Zip Directory chooser sees neither. Trying to upload a folder with a zipped folder inside it (and nothing else) using the Zip Directory chooser returns:

Error number: occurred while uploading file named: DicomStudy.zip

The system does not permit uploading files of with size 0.

I am able to upload an individual .dcm file and all study parameters along with it!!! I am able to use all the functions/tools and it works great. But as you can imagine, 8 sequences, each with 10-20 files; we’re gonna need that Zip Directory upload function.

I wish I could help you more, let me know if there is anything I can do.

#50

First, you don’t need to use a pre zipped up file in folder because I ignore it any file that doesn’t have a .dcm or no extension. A .zip will be ignored and would be the reason for a size 0 upload.(I prob need to do better error reporting).
Just select the last folder in directory tree before the series of dicom files like:

image
image1920×1080 383 KB

image
image1918×691 96.3 KB

image
image1918×414 32.8 KB

Then:(v6.0 needs some styling work!)
image
image1853×890 199 KB

So try this procedure and let me know results. The sequencing, I just haven’t seen it to be the case of the same sequence number for all images even within a group. But, i’m not an expert on dicom by any means!!!

#51

@pcgarell
I just verified what you are saying concerning sequencing. I found a demo ct formatted in couple different ways from an export.
I don’t know if we’ll be able to support. I’ll have to look over if I can modify viewer loader to work around this.

I’m regretting the whole “It shouldn’t be too hard to do.” I made… :slight_smile:

1 Like
#52

Indeed, the Zip Directory chooser auto-zips the multiple .dcm files when you load the folder. Thank you. When trying to view it, it shows the first image and the rest are not loaded.

Interestingly, the OpenEMR Cloud Express version does not have trouble with this. I have not yet patched my Cloud Express version with prepatch 4, but I was able to load the same data set (pre-zipped the same 17 .dcm files) and it uploaded and displayed nicely in v5.0.2(3). I was also able to easily scroll through all 17 images.

#53

Yep, that’s what i’m seeing. I’ll have to take a look at difference in current version and what i’ve done since previous concerning loader. However should not be a difference. I’m befuddled!:slight_smile:

edit: @pcgarell I just tried the exact zip you sent me to test with on 502 patch 3 with same outcome i’ve been seeing.

Our loader is coded in such a way that if there is not different seq number or patient position(primary for loading. seq is fallback) we fail! 503(3) fails with this zip file.

Can you send me version that works for you?

#54

I don’t think it has anything to do with the new pre-patch because I am unable to load/view the zipped .dcm files on my localhost v5.0.2(3) version (ie, un-dicom patched), but I am able to do it on the v5.0.2(3) Cloud Express version. It loads and displays/scrolls all the images just fine. It may be a settings issue.

I did not change any of the settings for the Cloud Express version, simply launched it and viola. If you could somehow get those study tags from the .dcm files to load on the Cloud Express version, we’ll be in business.

#55

Okay, thanks for the clue. Is your local version Windows? I’ll test on Linux which I haven’t done.
I did go through the individual images where they each have the correct meta position data!! However, the loader from zip doesn’t seem to work on this set of images, again, befuddled!!!

@pcgarell yep looks like an OS issue. Even using the zipped by folder uploader, that zip works so, now I know where to look, I might be able to get it right finally!:slight_smile:

Thanks for your help, very useful…

#56

Yes, local version is Windows.

#57

re: “lol if you think about it, if I keep developing on v5.0.2 i’ll have nothing new for v6.0”
Oh yes, you will, you will just keep making it more perfecter and perfecter! (Yes, that is a new word, watch out Merriam Webster.)

There is a lot to do, trust me as soon as you put this stuff out there, there will be tons of feature requests. Believe me, health care lags the banking industry by millions of years in terms of technology. Open source is the only way we will catch up because we cannot afford to put the money into it that it costs!

1 Like
#58

@sjpadgett

Is it necessary to reinvent the wheel? Could you not copy and paste the code from the other DWV (forgive my non-programmer ignorance) and incorporate it with permission or with the similar license into OpenEMR?
Alternatively, can it be done with an API?
BTW, I created a wiki here:

https://www.open-emr.org/wiki/index.php/DICOM_Uploader,_Storage_Engine_and_Viewer

and created a message yesterday but for some reason it was blocked.
I know this wiki page is not fancy. I am just learning how to use media wiki with images. I do want to learn, fyi.
I believe this chat also blocked a message I wrote regarding filing, storage, rendering and archiving. Which is all part of the radiology needs, which then becomes part of the point of care of providers who use these images to make care decisions.

I work with workers compensation patients in NYS and there are claims that date back to 1990’s
Not that I would want to have these images available for 30 years, but there are times when they are needed in court. The movement is that courts are also moving toward making their systems electronic as well.

Now, it is not worth it to have all images available at all times. Hence, inactive patients/images need not be stored in full. These could be archived. Only active patients/images can be stored in full, then inactive images can be stored as zip/tar, then really old stuff can be supper dupper archived and moved to a separate slower database, let’s say. The latter would be the equivalent of the stuff people in the old days used to put in microfilm.

Next tell me how users would enable this feature, and what it is compatible with.

1 Like
#59

I’m not @gutiersa, i’m merely updating to latest core version of the library. The availability of the tools i’m integrating now have always been available since I helped integrate this back in v5.0.1.

There’s a bug in this version 0.27.0 where it shows up only for zipped files loading with the use of a decoder i.e jpeg-lossless. Appears to loop grabbing only first image each iteration.
Will have to either find the bug myself or submit an issue to library author.

Thanks for the wiki and i’ll get back to you once I sort out this bug. My next project is 2015 certification where I need to just go away and develop w/o other projects hanging.

We would want a PACS for your other issues which I eventually plan a compatible viewer.

1 Like
#60

@pcgarell @gutiersa
Good news, I’ve been able to fix the decoder issue w/o losing any of the newer features. I gotta tell you, this one had me going in circles! Tenacity can be a curse.

I’ll put up a new patch later today after I goto some appts.

1 Like
#61

Let us make it a blessing here!