Thanks.

 We are kind of the opposite. All "photos" (fundus, slit, external, specular microscopy, FA, etc) are seemlessly sent to our radiology PACS system. We've been doing that for the last 6 years and it works really well. Radiology approached us when we last upgraded our digital imaging system and offered to integrate the imaging. I was skeptical but it worked from day one. Our docs love it. They can view our images alongside CT's, MRI etc from anywhere. One downside is that it's radiology-centric, so you don't have some of the same viewing/measurement tools you may be used to (stereo, PDT rings, calipers, etc). We also lose the FA timer when viewing in the PACS. But, we are also setup to view locally (in the eye center) through ImageNet, so the docs have a choice. Most use the PACS for everything.

We send all photos through DICOM export in ImageNet using the visible light standard. We created custom captures in ImageNet for all photo procedures and use that as our conduit to the PACS. We've integrated Canon non-myds, RetCam, Kowa Genesis, anything that produces an image file format (JPG, PNG, TIF, BMP)

Our bigger challenge is sending "reports" (OCT, HRT, VF, etc). Most newer ophthalmic instruments use the OP DICOM standard for export. Our problem here is that our PACS system doesn't accept OP yet. We have work-arounds for OCT reports etc. using a print-to-PACS utility, but it's an extra step or two. It sounds like your PACS either has a print-to-PACS setup or is accepting the OP standard. If that's the case, the holdup may be accepting the photos sent through the visible light standard. I would check the VL/OP acceptance for your PACS & see if its something as simple as that.

In a big medical center, this model makes sense to integrate all the subspecialty imaging through one PACS system.

My co-worker Jim Strong is better versed in DICOM than I am and he may chime in to fill in any blanks in my description.

I hope this helps.

Although we've been working with ImageNet 2000. Most of the other camera vendors have jumped on the "DICOM compliance" bandwagon.  This means that their software should be able to convert an image into a DICOM object and export it to a PACS system.  The question is whether or not it's wrapped in a manner that your PACS can accept.

We have been very lucky in that our RIS/PACS (Centricity/Stentor) is very promiscuous in that it will accept just about any type of "image" file.  The downside is that it will only accept Visible Light or VL SOP-Class DICOM objects.  This was an older generic catch-all for non-x-ray imaging.  Most of the Oph vendors have adopted the OP or OT (OCT) SOPs which are newer and more specific while abandoning the backward compatible VL.

The SOP equates to the 'flavor" of the DICOM used and defines the types of tags and other metadata included with the image.  If a PACS is looking for a certain tag, in a certain place, as defined by "VL" but the image was wrapped as "OP" then FAIL.

Another type of output that Oph vendors seem to like is an ePDF, which i think is an encapsulated PDF.  Unfortunately our system will not accept those, so we haven't had much luck investigating  them and our PACS admins always get a funny look when the term ePDF is used.

What i have learned is that there is only 1 way to find out if systems work together and that is a live test.  You can review Conformance statements cover to cover and pass them on to the PACS people to read, but ultimately there can still be issues.  Ideally then vendor is willing to work through these v. playing the blame game.  You have to assess this as you deal with the vendor and weigh it heavily in your decision. 

:)

j-

(1) Does the PACS take the images from you or do you send them?

(2) If they must be sent to the PACS, did you have to download twice? -- Once to the PACS and again to the server where images are kept.

(2) Is there hardware and software involved?

(3) Must you dedicate a person on your staff to do any of the tasks associated with getting these images to the PACS?

(4) Does the hospital handle all the details and costs?

(5) Are the images in the PACS system of sufficient quality?

(6) Are you sending Heidelberg movies?

(7) Why do you send "all" of the images rather than pulling out a select group of images to send?

(8) Do you send images that are for clinical studies rathe than clinical care?

Thanks.

Denise Cunningham

National Eye Institute

 Thanks for resurrecting this topic. That's one of the cool things about the forum, in that you can go back months later if you have new info or questions. Here are my attempts to answer your questions based on the 2 systems I'm familiar with. (Penn State Hershey & the VA both use different PACS systems). I've put my answers in Bold.

The NIH Clinical Center wants our images added to their picture archiving and communication system (PACS). From Tim Bennet's post, it sounds easy to do. Here are a few questions:

(1) Does the PACS take the images from you or do you send them? Both ways work, but normally they’re handed off seamlessly by your imaging system.

(2) If they must be sent to the PACS, did you have to download twice? -- Once to the PACS and again to the server where images are kept. This is all done in the background. Typically you save the images to your local system & then they are automatically transferred to the PACS. Depending on the number of images captured, it could take a minute or two for them to land in the PACS. Some systems are setup so that you don’t even bother saving to the native software (OIS, Imagenet, Escalon, etc) The local VA hospital we cover is setup that some instruments only save to the PACS. We do both here (Local machine/system & PACS)

(2) Is there hardware and software involved? Your dept will probably only need to load the PACS software interface on your capture stations.

(3) Must you dedicate a person on your staff to do any of the tasks associated with getting these images to the PACS? We don’t, but our situation is different than yours. The most time consuming part of the process is to "schedule” the patient in the system so they will show up on the modality worklist. In Radiology that happens at the reception desk when patients show up for their appt. In ophthalmology, we do almost all imaging on demand. They have already been checked in at the desk. So the imagers "schedule” the patient before imaging. This takes 2-3 minutes and another minute to close the session later. That becomes a bit of busy work, especially when that’s as much time as most patients physically spend in the imaging suite. Our average patient spends under 5 minutes getting their imaging done. Chair time is often 2-3 minutes. It takes longer to schedule than to image. I’m guessing your clinic would be different and that patients could be put in the system when they check in. We’ll eventually need to add staff or have someone else do the data entry as we continue to get busier. We'll probably designate someone at the reception desk to do this task. Some PACS & image management systems would make this task easier than what we have here.

(4)Does the hospital handle all the details and costs? Ours does

(5) Are the images in the PACS system of sufficient quality? They look good. We store locally as .PNG, but send .JPG to the PACS

(6) Are you sending Heidelberg movies? We haven’t done that since we rarely shoot video, but other departments here do. You might need a secondary plug-in piece of software to do that.

(7) Why do you send "all" of the images rather thanpulling out a select group of images to send? Sending them all as a group is seemless and is done automatically. Pulling a select group is too much unnecessary work.

(8) Do you sendimages that are for clinical studies rathe than clinical care? Depends on the clinical trial. We do a separate manual "push” of clinical trial images if the patient is also receiving care here. They are de-identified for study purposes but put into the PACS under their clinical ID.

There are a lot of things to consider. Jim summarized things real well up above. Some of this depends on your specific PACS system & whether it accepts the OP DICOM standard. Without that, you are left with transferring via the VL standard. Then you might need an add-on utility called a print-to-pacs to manually push reports (like OCTs) to the PACS. It also depends on how committed & motivated your institution and PACS team is for integrating ophthalmology. Our was very motivated. They approached us and did all the heavy lifting to set things up.