In 2005 I partnered with a programmer/friend to start Jetrad. The company was in business to provide radiology services to underserved rural hospitals and imaging clinics who were unable to afford or justify their own radiologist. I have been out of that business for 11 years now.

I recently started learning about Amazon Web Services and as part of that learning curve, I started thinking about how we would deploy our Jetrad system using AWS vs the old way of doing it ourselves. AWS would have allowed us to scale MUCH faster with less up-front capital and manpower costs.

So I thought I would write a few posts about how I would spin up Jetrad now using AWS versus how we did it back in 2005-2008.

Overview of Jetrad

We set up a PACS image server in an Oklahoma City data center where we received DICOM medical images from rural facilities and routed those images to radiologists working for us under contract typically at their home. The radiologist would interpret the images and dictate a report. We would route the voice file to transcriptionists working for us under contract, typically at home. They would transcribe the reports into our system, the radiologist would sign the report, then the final report was available to the rural facility for patient care. We would then bill for the radiology interpretation and collect payments. We also built a Voice over IP phone system that would allow the clinicians to reach our doctors and help desk via voice calls over the Internet.

To build our system we had to install a PACS server in an OKC data center. This required us to purchase the hardware and storage, set up redundant firewalls and network switches, and eventually build a redundant server and firewalls in a Tulsa data center. The PACS software we purchased from a PACS vendor. The radiologist used commercial software to read the images. We wrote our own software connected to a SQL database pulled the metadata out of the DICOM server and then set up routing, reports, dictation, transcription, call routing and billing information. This data was housed on our own server in a SQL database and we wrote the HTML and PHP code to query and control the database and present the data to the rural clinicians, the radiologist, transcriptions and our billing and support staff.

Challenges

There were a number of challenges to our business, most of which we were able to overcome but a few that gave us significant headache. 

Capital for Expansion

To build our solution we had to purchase servers, firewalls, routers, switches, IP phones, and a host of other expensive IT products. We paid a monthly fee for our hosting in a data center, yet we had to manage our own servers at each facility. This required staff to install servers, install and configure switches and firewalls and redundant power supplies and backups and all the other items needed for the system. While much of the equipment we were able to purchase using our normal business proceeds, we still had to borrow for expansion. At the time I left in 2008 we had borrowed $300,000 in working capital and were needed to borrow another $1,000,000 to expand.

Redundancy

Building redundancy into our system was expensive, both in time, brainpower and capitol costs. When we first started we didn’t have redundant servers, either PACS or our database server. The best we could do was redundant firewalls and switches. As our client list grew (eventually 60 hospitals and growing) we added redundant servers and when I left in 2008 we had just started installing a fully redundant system in a Tulsa data center. All of this was very expensive and time consuming, costing hundreds of man-hours and a major investment in brain power.

Billing and Collections

Actually we were able to work through the billing issues. The biggest challenge, and the one that eventually lead to the failure of the company after I left, was the problem with collections. While it is easy to bill for radiology services, it is extremely difficult to actually collect for radiology services – or any medical services for that matter. Medicare and Medicaid only pay a fraction of the billed price. Same goes for insurance companies. And to get them to pay, everything has to be coded and filled out perfectly. Both the federal government and the insurance companies try to find every way possible to reject a claim. We would have 30% or more claims rejected for some type of minor technicality, which we would have to correct and then re-bill. This entire medical coding, billing and collection challenge added tremendous manpower demands, overhead and delayed payments.

The biggest challenge was in collecting for services to non-insurance clients. Those were exceedingly hard to collect. Billing individual patients and then trying to collect from those patients was extremely difficult. And in rural America, much of the population was not covered by insurance, which again made it difficult to collect.

Most radiologists told me at the time that if we were able to collect 25% of what we billed she would be happy. Collecting 30% was almost unheard of. So we could bill, bill, bill and our revenues looked fantastic, but our actually cash flow from collections was very problematic and eventually led to the downfall of the company.

Performance

Many of the rural facilities we dealt with had poor internet service. Most had T1 connections, but at 1.544 Mbs speed for the entire hospital, this meant it could take an hour to transmit one study. For a very small facility this was fine, but for a larger facility seeing a hundred patients per day this made data transmission very slow. We tried implementing technology that would allow us to cache the images locally and then transmit them in batch mode at night. This was just a patch until we could get facilities to upgrade to faster Internet connections. We didn’t have to deal with this cost, but it was an impediment to hospitals and clinics using our system. But then again, they often didn’t have a choice since they didn’t have a radiologist anyway.

For our costs, we had to connect our radiologists to our network. Many were working from home. Luckily most of them lived in a larger city and typically could get faster internet at cheaper prices than the rural clinics and hospitals. We did have reliability issues we had to deal with. Some tried to connect via satellite, but this was an unworkable solution for transmitting images and real-time voice communications.

How to Build Jetrad on Amazon Web Services

Up next – how I would architect Jetrad today using Amazon Web Services.

As I learn about AWS I can see HUGE improvements and benefits to how we were doing things 11+ years ago. I will detail these next.