The time has come to attempt to implement a better PACS experience for our users. Should be able to hook up to a handful of tested PACS systems as well as easily access the DICOM images in the system.
I’m just doing the project management for this at the moment, so it’s a team of one! I’m sure others will join later on (there are MANY projects going on right now!)
Very cool @mborchorst, I am familiar with DCM4CHE at a high level. Two questions for you, if you don’t mind me being a little bit forward with you:
Would you like to lead this PACS project? It appears as though are already working with an open source PACS solution in a production setting and would know how to best envision a native OpenEMR PACS experience. If this is something that interested you, perhaps @Elijah_Wisdom has some cycles to contribute as a teammate (just taking a guess because he expressed a lot of interest here).
Have you ever used an open source PACS solution that has an HTML/JS viewer?
I certainly do not mind
I am very busy the coming months, so project leading would probably more likely lead to project grounding. I will definitely chime in with all I think to know, and my wishes to the openemr integration with a PACS. If no one has taken the task as we come to October, I may be able to do something, but till then anybody can do more than me.
I use the Aesculap viewer on my workstations, as I have not been able to find a Linux capable diagnostic viewer. This is in many ways not ideal; not the least when it comes to 3D datasets, but I have not found the “right” solution or rather, a better solution.
I am working with an implementation of DCM4CHEE 2.8 that receives 500 daily studies, also scanners with 1500 images in each study. We already did some some custom modifications to apply automatic advices, reports and audits systems to optimice this implementation. I am a developer, we are testing some ehr like openemr too. I am new in clinical solutions but i’be happy to share my expirience with you.
Our volunteer team has spent some time looking at DCM4CHEE. We actually found the following solutions to be a little bit easier to set up and see in the web browser:
Do let me know if I am wrong in assuming you are not able to volunteer development time. The other admins and our global user base always benefits by working together to supply robust features such as these (big impact)
2D imagining (Clinical photos, jpeg, png, tiff or bmp)
2D film
Digital dental casts (STL or proprietary formats)
3D film
Probably mainly the x-ray part is relevant as main feature.
A PACS server runs parallel to the openemr, so only minor direct connection between the two would happen.
I have a workstation with connection to my 2 x-ray machines, so I would need a menu item to call locally installed programs with the patient information. The locally installed programs would then connect to the PACS for the actual DICOM communication. On my clinical workstations I then use a viewer (locally installed, but a different program) to view the x-rays. Ideally the set up should therefore be different per workstation.
For optimal flexibility I store my clinical images in a directory structure (one directory per patient). As my preferred image viewers do not speak DICOM, this is probably the best solution for the time being.
Does this make any sense to you?
/Morten
I write this message as the main author of the Orthanc DICOM server. Please be sure the Orthanc community would be happy to see an integration with OpenEMR.
Several users have reported using Orthanc with its associated PostgreSQL plugin to store around 10 TB of data. So it should not be a problem to use Orthanc to store a database of x-rays images, which looks as your primary goal, given that a typical single RX DICOM image weights roughly about 10MB.
Regarding your answer to Morten, DICOM is conceived as an universal standard to store and exchange medical images, including for dental applications. Currently, the problem with dental applications is the wide variety of incompatible file formats, for which no single neutral storage exists, and for which physicians must use many different viewers: DICOM should be the solution to break these proprietary, closed, non-competitive ecosystems.
Any 2D x-rays and 3D x-rays imaging device can already be configured to generate DICOM files. 2D visible-light images and 2D films can be encapsulated as DICOM images (a process known as “DICOM-ization”, for which free and open-source tools do exist, such as Orthanc through its REST API, or GDCM and DCMTK through their command-line tools). DICOM primitives to encode digital dental casts do exist, but the FOSS community should unite to work on a reference implementation to convert from STL to DICOM (in particular, the Orthanc community would be happy to contribute to this effort). Finally, as far as 3D films are concerned, DICOM supports stereoscopic movies.
If you have any question regarding Orthanc, feel free to get in touch with me.
