One of the biggest limitations until recently for our medical imaging facilities was access to bandwidth.  Our facilities are based in geographies with burdened infrastructure.  Recently we negotiated an incredible deal with Cogent, a multinational Tier 1 ISP, for 100mbps fiber termination at each of our four facilities.  The expanded bandwidth (10x our current capacity) means resources for new IP applications including voice.  Asterisk, the open source PBX, is an outstanding option for small and medium business hoping to take the leap into VoIP, affordably, while avoiding black-box and heavily licenses solutions.

In the next several series of posts I will explore the front-end (telephones), the back-end (Asterisk) and the glue that holds the newly created IP telephony platform together.  I’m confident this solution will move out of lab sometime in Q2 2010 and into production based on our extensive testing and research.

Telephones (Part I)

Ultimately the success of the solution will be based on two things: the user-friendliness of the phones and technology and the quality and reliability of the telephone service.  Never has purchasing phones been so much fun (well, aside from getting my first iPhone).  In bringing this solution to lab, I needed some hardware.  I purchased four Polycom Soundpoint 601′s, four Cisco 7945g’s and an ATA-186 for testing.  The Polycom phones are certainly more capable than the Cisco phones, at very similar price points.  The 601 supports up to 32 “lines” with an additional module.  The 7965g is limited to two.  The 7945g has the “cool – I saw it on 24″ factor.

Configuring the Polycom 601 is incredibly easy and can be done directly from the telephone itself.  (Default username is “Polycom” and password is “456″)  It took less than 10 minutes to configure the phone, reboot the software, and have a functional device.  I won’t go into any more detail here because frankly, there isn’t any.  It’s worth mentioning that the phone’s interface only exposes a small percentage of the settings available – use the web browser if you’re feeling dangerous (http://<ip of phone>/).

Configuring the 7945g was anything but easy.  First, Cisco requires a SmartNet contract to obtain the SIP firmware that did not ship on the phone (Cisco ships their phones with their SCCP/MGCP firmware.)  Once you get the firmware, it’s not a relatively straightforward “upload and install”.  From past experience with the Cisco 7960 phone I knew a functional TFTP server was required to deploy the config files and upgrade the firmware – I used TFTP32 (I’m a mac user so I tried using it’s native tftp capabilities; I wasn’t successful).  It took hours online to find the right combination of config files and firmware to get these phones to work (follow this link for a zip archive of my config files).  There is very little Cisco documentation regarding the actual XML syntax used for the config files; I cobbled mine together after reviewing many samples.

Regarding the firmware, I ended up using the SIP45.8-5-4S firmware – the config files reference this.  When you have the configuration files manipulated, firmware loaded and TFTP server functional, reboot your phone and cross your fingers.  It’s like a game of Russian roulette.  While my Cisco phones are behind a firewall, I’ve disabled the NAT setting alltogether in the phone.  I enabled consistent NAT and SIP transformations on my firewall.  I configured the phones to register every 60 seconds.  With these settings, I’ve been able to maintain registrations.

I used the ATA-186 at my house.  The ATA-186 is a FXS – it provides IP dial-tone to the copper in your home or office.  Calls placed through any of the telephone lines at our home get routed via the ATA-186 to the Asterisk server and ultimately to the recipient.  This device also required a SmartNet contract to obtain the appropriate firmware.  I was able to do some crafty Google’ing and found it.

Conclusion

Both the Cisco 7945g and Polycom Soundpoint 601 are great phones.  The Polycom phones are going to be great for our actual technology implementation.  The Cisco phones look great at home, though they (Cisco) make it very difficult to integrate their phones into non-CallManager solutions.

In the Apple PACS world Osirix was upgraded to 3.6 which is a rather sizeable upgrade. Some of our SecureRAD customers are using it and we’ve had very little pushback. It’s solid.

Two new customers came online with SecureRAD this quarter including University of South Florida and a small but busy radilology shop in NC. Were having a lot of fun helping them solve some interesting problems.

A solution we are now implementing to intelligently archive the medical imaging data produced during a given day is to package it and distribute it to the remote sites using SFTP at the end of business.  Efficiency is increased by a immeasureable magnitude by transporting a single data stream vs. many thousand streams (each individual image).  Once the package arrives at the destination a script extracts that data, parses it and uses DICOM’s c-store method to submit it to the local archive.  As well, an E-mail is sent to the PACS administrator notifying him/her of the success or failure of the transmission.

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/
Contents/Resources/kickstart -activate -configure -access -on -users
admin -privs -all -restart -agent -menu

This command saved my butt when it came time to install two Xserve’s (headless) as I had no access to a Mini Display Port adapter and Server Assistant “shit the bed.”

It’s worth mentioning you should be ssh’d in as Admin/Administrator.  I speculate this won’t work as root, but I don’t know.

The birth of our son meant changing how business is done so I could be home to help.  Change is a good thing and in retrospect, has made SecureRAD a more succesful company.  Much of SecureRAD’s business is now direct-ship to the customer.  We’ve built and shipped a number of PACS systems from February 4th – June 13th.  Two of those “installations” are in Trinidad (I wanted to jump in the box and go, myself) and others are around the continental US.  Whether this is the right answer or not, I’m on the road again.  This time in Cleveland, Ohio installing at St. Vincent’s Charity Hospital.

(A note to Apple: Why not include the Mini Display Port adapter in the Xserve box?)  Seriously, this was a more frustrating moment of the installation which otherwise went off without hitch.  To get the headless servers setup with IP’s and ARD-available, I used Server Assistant.  This worked well until it came time to “Apply” the settings and the button remained greyed out.  I ended up SSH’ing into the boxes, used ‘networksetup’ to configure the “Ethernet 1″ interface and used Kickstart (ARD) to start the ARD processes.

People are friendly in the midwest but man, there is nothing to do here.

nano /etc/crontab
crontab /etc/crontab
crontab -l
/etc/init.d/crond restart

Link

UPDATE: We’ll need to turn the lights on!