Request a demo

Get one step closer to a better workflow.

Back to All

Radiology in the Cloud is Possible with these Four Components

Posted on 03/30/17

We have been seeing a lot of excitement around “Radiology in the Cloud“, and “Best of Breed” lately (I guess “Deconstructed PACS” is not hot any more), but none of these terms completely capture the real trend we are seeing.  What radiology groups want is a componentized single tenant ( client server application.  A key benefit gained by using an architecture of components (deconstructed) in a client/server environment is the ability to run those components on different systems (some in the cloud).  There are so many additional benefits to this design (including almost unlimited scale), that it is being used by almost every industry.  It is inevitable that radiology will follow.  So how do we get there?

On the server side, the architecture is very simple.  A VNA will ingest and store exams, and an application is needed to extract exams from the VNA and send them to the viewer.  For the worklist, a database is needed to store the state of the radiology enterprise and capture all the data associated with each order/exam.  Some services are necessary on the server side to receive and send orders as well as assign exams, compute statistics and monitor for conditions that cause alerts.  The system also needs to respond quickly to requests for data from the client systems.  All components need to send and receive data from each other, even if they are supplied by different vendors.

On the client side, all of the software will ultimately run in the browser.  This allows the client side application to use all the inherent functionality of the browser.  Software development goes faster, and communication between the client and the components on the server side is fast and secure (think about how your on-line banking works).  The three components that run on the client side are worklist, viewer and Voice Recognition.  Worklist: Don’t purchase a worklist that is not browser based.  Just don’t do it.  The only reason a worklist would be running in a thick client is because it was built years ago.  Viewer: The viewer is quite a bit harder to build in the browser, but vendors are getting very close to diagnostic viewer performance.  It will get there soon, if it is not already there.  If your rads are flexible, this is the type of viewer you want to buy, because they will only get better and the advantages of running in the browser will only increase over time

Voice recognition is the last component, but it is quickly heading toward the browser as well.  This is because browsers have become the platform of choice for building and deploying VR applications.  It started around 2014 when the W3C added voice functionality to the HTML5 standard.  Industry caught on quickly, and developers started building (  Now, you have the big players like Nuance ( ), Microsoft ( ), and Google (, all moving speech recognition technology to the cloud.  Vendors (including Clario) have built complete zero-footprint radiology speech recognition and reporting systems using this new technology.

Whether you call it “Radiology in the Cloud” or “Best of Breed” or something else, the best solution is the one that costs the least, performs the best, and is easiest to maintain.  Putting everything in the browser on the client side, and all server side components in a single tenant that you control is what radiology is moving toward.