ComplexOb Handler for Dicom(Radiology) files

[ryan97]

Hey Guys. I have been using openmrs software for a while now, but I’m kind of new to the concept of Complex Obs. I am creating of a functionality to upload radiology images so that a doctor who is accessing the same patient’s information from another module can easily view radiology images for that patient, if there are any. I think the only way to do this is using complex obs. So far I have followed the steps outlined in the Complex Obs Support page, and I also followed the discussion on this thread. Using this information I have been successfully able to create complex obs using imagehandler as its handler. It successfully accepts jpeg or png files, but when i upload a Dicom file, I get this error

Invalid image file

I wish to ask if there is a complex handler such as the image handler which would help me upload dicom files directly, or advice on any other alternative methods of doing this. Thanks

[dkayiwa]

Have you looked at the Visit Documents or Attachments module?

@mksd do you think this module is fit for this purpose?

[mksd]

100%, this is exactly where handling the case of DICOM images should land.

@ryan97 could you detail more precisely what use case you are willing to cover?

[ryan97]

@mksd I am woking on a version of openmrs’ radiology module, no entirely sure what version it is. The module came with a functionality to upload images already coded into it, but the files were not uploaded as complex obs, in a case of a patient having to undergo multiple scans which produce multiple images, it would be difficult to keep track of each of them. Also, the module already has a conerstone viewer integrated as a drag and drop area, such that i can successfully drag and drop dicom external images( i downloaded sample dicom images into my computer and used them to test the viewer) into it and they display successfully, but viewing an image which has been uploaded into the system via the existing file upload functionality was not possible.

So I changed the file upload mechanism such that it uses complex obs, but using image handler as my complex ob handler, i get the error i specified above.

That is an image from the radiology module I am using. The bordered rectangle is the drag and drop area for conerstone and that is where i was my eventual dicom file upload to be displayed.

All the above information was geared at providing better insight to what I’m trying to achieve as requested by @mksd. I will now look into the Visit Documents or Attachments module to see if that solves my problem

[ryan97]

@mksd I cloned the Attachments module from here and built it. I then uploaded its omod to a running instance of my openmrs server, but i got the following error

Any thoughts?

[mksd]

I have no idea of what environment you are on. Attachments work across a fairly wide range of version of Core (1.10.x to 2.1.x if I remember correctly).

You will have to provide a lot more information for us to be able to help you out:

• What Core version are you on.
• What other modules are around.
• What’s the log saying.

I would suggest to try out Attachments on a Ref App distro (say Ref App 2.8) to not waste any time.

[ryan97]

Hi @mksd, I found a way to successfully install and run the module. I had initially thought it possessed a mechanism to view dicom images once uploaded, but it turns out once i upload a dicom image and click on it inorder to view it, it downloads the file to my local machine instead. I am able to upload and view normal image formats such as jpeg and png. Here’s how the module looks like after i uploaded a dicom file and an image

Do i have to develop a mechanism for viewing the dicom images myself? And also I had thought i could access files saved as complex obs from this module, but I have a patient whose dicom file has been saved as a complex ob and added to its radiology encounter, but i can’t seem to access that file from here, i have to re-upload it, creating a whole new encounter. Any thoughts? I know its weekend but any advice would be appreciated.

[mksd]

Hi @ryan97,

1) Why DICOM images are handled generically

Only two ad-hoc viewers have been implemented so far: one for images and one for PDF files. Any other types of files will be handled generically. The generic handling consists in simply storing the file and providing the ability to download it again, which is what you have observed.
You will rightfully tell me that DICOM images are images. That’s true, but their MIME type is not specifically filtered by Attachments, see here why this happens. The very first thing that I think you should try doing on your fork of the module is to expand this method so that Attachments recognizes DICOM files as part of the so-called ‘image content family’.
Note that for this to work you will also have to add the DICOM MIME type to the global map (here):

mimeTypes.put("application/dicom", "dcm");

I don’t know if a DICOM image can just be viewed as any usual image (JPEG, PNG, … etc), I doubt so, and therefore I think that the above will not work. But please try it out and let me know your findings. If it doesn’t work it will mean that the DICOM MIME type case will have to be handled entirely specifically, which is what I suspect. But let’s try the above first and let me know how it goes.

2) Why other complex obs are not being seen through Attachments UI

For Attachments to incorporate in its UI complex obs that were saved elsewhere, you will have to tell it to do so through the following GP: attachments.conceptComplexUuidList (see here):

Adding the UUID of the concept complex that you wish being handled should work. Attachments should then start listing those files along the others (assuming they’re bound to a visit, but this can also be toggled off). I seem to remember that there might be a bug there and that this might not work as expected, I would be curious to hear your findings about it.

[ryan97]

Hi @mksd , Thanks a lot for your help. I found a work around to displaying the dicom files. What i did was i uploaded the file, converted it into a jpg using dmc4chee and saved the jpg as a complexOb using the imageHandler. This is just a quick fix, but I’ll still need to handle the files as dicom files and not jpg files if i were to use an image viewer such as conerstone. So if you keep me updated on any updates of this module regarding that. I would also do my best to contribute to this module as often as i can.

Thanks again.

[mksd]

But Attachments will never be an actual DICOM viewer. For this you can stick to dcm4chee, Oviyam, … etc. What I would wish for Attachments is to know that there are DICOM images recorded as complex obs, and have them handled -somehow- so that they nicely integrate OpenMRS’ workflow.

Is that what you would like to contribute to? I think there’s quite some work to be honest.

[ryan97]

Hi @mksd. Yes that is what I was referring to when I said I would like to contribute. I figured there would be a lot of work, but I guess a journey of a thousand miles begins with a single step:grin: . Quick suggestion, if OpenMRS is accepted for GSOC 2019, I would love to submit a proposal for this, if it is one of the available projects:grinning:

[mksd]

@ryan97 absolutely. I would be happy to mentor that one.

Could you read/follow the below thread and see if it’s already time to post about it in there?

GSoC 2019 : Project/Mentor Brainstorming

Hi all, Now the time for the community to get into the Google Summer of Code. Following on the success of more than a decade of involvement in Google’s Summer of Code initiative, OpenMRS once again planed to apply as a mentoring organization for Google Summer of Code™ 2019 , and we are looking forward to identifying potential project ideas and mentors for GSoC 2019 as part of the organization application process. The organization application is due on the 06th Feb , so we would like to get as …

[ryan97]

Hi @mksd, Can you please explain further what you meant by

What I would wish for Attachments is to know that there are DICOM images recorded as complex obs, and have them handled -somehow- so that they nicely integrate OpenMRS’ workflow.

I’ve got few ideas but I want to get what you think before I mention this in the gsoc project brainstorming thread.

[mksd]

What I would wish for Attachments is to know that there are DICOM images recorded as complex obs, and have them handled -somehow- so that they nicely integrate OpenMRS’ workflow.

Do you intend to upload the DICOM images using Attachments, or should Attachments assume that the DICOM images are already stored somewhere else? The latter case seems like the usual use case: DICOM images are generated by an X-ray machine and uploaded into and stored by a PACS. Then you would want OpenMRS to know that there is a PACS around and help access those files by providing links that will trigger the viewer.

Or did you have something else in mind?

[ryan97]

Yeah the latter case seems more plausible and I totally support your point of view. But I think the attachments module already does something similar to that. I think for each patient, you could view files that were uploaded during a previous visit or encounter and saved as a complex ob for that patient. Now for DICOM images, what we would have to do is implement a mechanism by which the radiology images uploaded can be stored in a PACS. That might involve doing some work on the radiology module too because if I can remember correctly, images in the radiology module are not stored as complex obs(I can’t remember well, been a while I worked on radiology, but I do remember encountering problems because of this), and there fore would not be accessible in the attachments module. Then once that is done, we could integrate the PACS

[mksd]

I don’t know the radiology module, but I would assume that it is the module that is integrating with the PACS. Whether it integrates with the PACS or not, the limitation that you have spotted is that it does not refer to radiology images that it knows of as complex obs, thereby moving them out of OpenMRS’ data model.

I guess you’re getting to a point that DICOM images are stored “somewhere” and that Attachments should know about them because they come up as complex obs. From that point it should know, out of the box, what to do with them, see my point 2 below.

I guess there are two possible situations:

1. A DICOM image was uploaded directly using Attachments, and we need to think through what is supposed to happen then.
2. A DICOM image exists as a complex obs because something else made sure to leave such trace of it. That’s the case where the DICOM image is stored somewhere else but is also referenced in OpenMRS as a complex obs. Again we need to think through what’s supposed to happen then based on the metadata that is provided by the complex obs.

It looks like in both cases the complex obs will point to a DICOM file location, it will be a local file in case 1 and a remote file in case 2.

[ryan97]

I guess the project would entail a lot of work with the processing of dicom files and I am fine with that. Given that you are the expert in the attachments module and probably use it more often, I guess there might be other minor tweaks you’d want included as well. This would probably be a continuation of this previous project

[mksd]

Yes correct. Feel free to share a draft proposal in regards to the scope to support DICOM files and I’ll be happy to review it.