What Exactly IS PACS in a cloud?

Posted by Martin Peacock in Blog      No comments

Dec
22

AuntMinnieEurope has an interesting article predicting some trends for 2012.  Amongst others, it suggests the buzz around ‘Cloud PACS’ will remain just that – buzz with little substance (small degree of irony there perhaps?).

I agree, but I do disagree with their definition of what ‘cloud’ actually means.

Indeed what some vendors are referring to as cloud PACS is simply a virtualization of locally hosted systems, further hindering market adoption of “true” cloud PACS. True cloud PACS is defined as having both application and storage provisioning and hosting by a third-party server offsite from the end user (i.e., public cloud).

Well – having app and storage hosted by a third party off-site is today – and always has been – call co-location (or co-lo for geeks).  That isn’t the same as ‘cloud’.  Wikipedia defines cloud as computing-as-a-service, which is, I think, closer, but I would go even further.  I would tend more towards computing-as-an-amorphous-and-opaque-service.

Lets take GMail as an example. I use GMail as my primary service provider and its a classic example of what most people would think of as ‘cloud’.  From which of Google’s many datacentres is GMail served?

Credit: Techcrunch

I’ll be honest.  I haven’t a clue.  It could be any.  In fact as a service, different elements could be served from different locations – mail from Europe, contacts from US and search from South America.  I don’t know and importantly I don’t care.

Another example is the Amazon Elastic Computing Cloud (EC2).  Within EC2, it is possible to rent servers in units of compute cycles, memory and storage, and point roughly to where they should be located – as in ‘somewhere in Europe’ or ‘somewhere in the US’ – but the Amazon infrastructure could move those around for a number of reasons.  You may not be aware they are being moved, but moved they are.

In Amazon’s case it is able to do this by virtual of virtualisation – the technology that the article in AuntMinnie specifically says is not ‘cloud’.  Virtualisation also offers a concept that is quite opposite to AM’s definition – that of the ‘private cloud’.

A private cloud is one which is dedicated to the use of a particular organisation. It can be externally hosted, an internal implementation or indeed a hybrid.  But the properties of amorphous and opaque still apply.  A private cloud architecture often implementation might be 2 or 3 datacentres in different locations – say 2 within the grounds of a hospital, and one off-site.  This can be organised in a way to maximise disaster tolerance, for example.  Individual servers/services can be moved between datacentres without the user being aware.   The user just knows the service/data is coming from ‘somewhere’ *.

So the distinction is not between ‘cloud’ and virtualisation – or even between public and private.  It is between local and remote.  Services hosted remotely suffer from two handicaps:

1. Trust.  Both from a security and privacy point of view, remote cloud services are still looked at with a slightly leery eye.
2. Infrastructure.  Remote cloud services will almost inevitably end up going through public infrastructure.  Even in the ‘developed’ world, the high specifications required for bandwidth, latency and reliability are not available everywhere.

Both of those are improving – but I think for data-intensive applications like PACS, ‘the cloud’ is still to come over the horizon.

Paring the idea of private cloud to the bone, we could end up with another of AM’s predictions – that PACS as a ‘Managed Service’ will grow in popularity over the next couple of years.  I personally think such a solution is a seriously retrograde step in PACS as an industry – although it may have benefits in a minority of (small) organisations.  Why?  Another of AM’s articles that landed in the mail this morning  points to ESR guidelines for the communication of urgent and unexpected findings.  It is interested reading in itself, but the bottom line is that while technology can provide part of the solution, it can’t do everything.  That is because the delivery of healthcare in any organisation of meaningful size is a complex thing that will always be at least as much to do with people as technology.

That is the reason integration between the many silos of information that have evolved in a typical healthcare organisation has progressed so slowly.  Any to keep the wheels moving smoothly, I would argue that what is needed is more knowledge within the organisation that know the systems, the data, and how they interact, and not less.  Managed Services in any but the simplest of organisations is the wrong direction to go.

But that’s my opinion.

Martin Peacock

* It should be noted that virtualisation isn’t the only way to achieve this – but virtualisation makes the job of ‘clouding’ an existing service much easier.  Services can be engineered such that they can be implemented as a cloud service – software engineering techniques such as MVC help. And infrastructure measures such as clustering and load balancing go a long way to achieving similar objectives.  Whatever mechanism and architecture is used – this aspiration should be high on the list for any any mission-critical system.