Picture Archiving and Communication System (PACS)

OpenEMR Development
#1

Goal

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.

How to connect

  • pid
  • port
  • ip
  • login info

(Thanks Alfonso!)

Notes

Testing

We may be able to bug @juggernautsei for PACS testing

Chatroom

#pacs

Team

None yet!

1 Like
Project - PACS Server Integration
Android and iOS Apps
#2

I support this count me in.

1 Like
#3

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!)

#4

yeah I know. Well done though.

1 Like
#5

I use DCM4CHEE as PACS backend. I am very satisfied with it and would love to see it integrated with openemr.
/Morten

#6

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:

  1. 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).

  2. Have you ever used an open source PACS solution that has an HTML/JS viewer?

#7

I certainly do not mind :slight_smile:
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.

#8

Cool, cool.

Looking forward to hearing more about the integration!

#9

Hi Everyone,

Please join #pacs chatroom : chat.open-emr.org

Victor will be joining the team! Am inviting him now!

-m

#10

@mborchorst

We’d love to hear more about your experiences with DCM4CHEE if you’ve got the time :grinning:

Open to hearing your thoughts either here or in the #pacs chatroom.

1 Like
#11

I expect to get some time the comming monday. I will try to condense my thoughts til then :slight_smile:

1 Like
#12

Inbox – matthewvita48@gmail-1
Inbox – matthewvita48@gmail-11700×2200 272 KB

1 Like
#13

I’m actully use DCM4CHEE as PACS too. It’s a nice software but need a RIS or EMR to make it a complete solution. I interesiting, count with me.

1 Like
#14

DCM4CHEE it’s powerfull! with many installations around the world.

1 Like
#15

Hi @esalosny, welcome.

We would love to have you help us with this exciting project. What is your background in PACS?

Thanks,
Matthew

#16

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.

1 Like
#17

Hi Eric,

It is very nice to meet you, by the way.

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 you have experience with either of those solutions? Should we revisit DCM4CHEE? Does it have a good web browser viewer?

I recognize that you stated that you are willing to volunteer your experience and understand if you can’t volunteer to write code/qa, but can you please do me a big favor? Would you be able to review the workflow I listed out in https://discourse-uploads-openemr.s3.amazonaws.com/original/2X/e/ee2ac7bd4fa9a371827de71f0328d33594215ee4.jpg and tell me if this is correct/close to reality? The more feedback, the better.

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) :slight_smile:

Thanks,

Matthew Vita
OpenEMR Project Administrator

#18

General: As DICOM relevant should the following material be considered (from at dental point of view):

  • 2D x-rays (intraoral tilms, headfilms, orthomopantomograms)
  • 3D x-ray datasets (CBCT, CT)
  • 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

#19

Hi Morten,

Thanks for that. I agree that x-rays are going to be the primary image type.

Some questions:

  • What is your local viewer program?
  • For your “clinical images in a one directory per patient” approach, is this done via the file system or in the EMR?
  • “Preferred image viewers do not speak DICOM” - what is their protocol?

Thanks,
Matthew

#20

Dear Matthew,

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.

Regards,
SĂ©bastien-