So Dell gets into the PACS Archive market. Who next?

Posted by Martin P in PACS General      No comments

Mar
25

Dell has announced their entry into the medical imaging archive market.  As if we didn’t have enough vendors.

I’m going to pick some holes in this.

Because, Coffin points out, “IT budgets are not increasing at the rate of storage needs for the industry.”

… nope.  But they don’t need to.  The cost of storage is plumetting at an increasing rate.  What organisations paid for 1TB 2 years ago will get them 10TB (or indeed a great deal more) if they are smart and not go for the ‘easy’ option.

Moreover, he says, with “these vendor-neutral archives, it doesn’t matter who the PACs vendor is.

Look.  There is no such thing as a vendor-neutral archive.  There is only vendor-different archives.  Storage is still storage.  Database schemas are still schemas.  So-called ‘vendor neutral archives’ are simply open transparent instances of those technologies (if you’re lucky).  The fact that a distinction needs to be made is a disgrace.  Vendors should NEVER have been allowed to hide those behind opaque barriers (as, indeed some vendors get way with to this day).

The article doesn’t go into any detail on the level to which this new product will support the necessary IHE profiles to make this truely safe and usable.  Then again, my experience of ‘horizontal’ vendors trying to make inroads into ‘vertical’ markets, suggests that IHE, HL7 and the like are at best afterthoughts.  I recall Digital (then still a thriving company) trying to dig into the GIS market (then, my field of expertise) and making a dog’s dinner of the whole thing.

Still.  I may be pleasantly surprised.

Is Computing and Data Visualisation on the verge of a revolution?

Posted by Martin P in Development, IHE, PACS General      No comments

Mar
25

I’m a fan of the notion of punctuated equilibrium in evolutionary theory.  From Wikipedia:

When evolution occurs, it is localized in rare, rapid events of branching speciation…

… most of the time, things just truck along doing what needs to be done, and then over a short (relatively, in the case of evolution) period of time, some ‘big stuff’ happens.  That kind of feels where the computing and technology world is sitting right now.

In the course of innovation within the computing and data visualisation fields – particularly as applied within medical imaging, there has for many years been steady but linear progress pretty much corresponding to Moore’s Law.  Lets take a look at a few technology sectors:

• Smartphones.  Clearly, these were languishing in the doldrums until Apple gave the industry a smart kick up the rear.  It took a little while for competitors to figure out how to follow, but follow they have and the next year or so will see some intense competition and major advances as a result.
• Browsers.  There is at last widespread adoption (at least in product roadmaps) for HTML 5, even by Microsoft.  This is important.  Two elements in particular – Web Sockets will enable the development of server ‘push’ for CCOW implementations (an issue till now).  The Canvas element allows for in-place editing of images and image properties ‘in the browser’ with Javascript.  Watch this space for a little experimental implementation of Window/Leveling using the Canvas element.  As well as HTML5, many browsers are working on WebGL – a means to allow browsers to take advantage of hardware acceleration when rendering 3D.  3D was not too long ago a luxury item in Radiology but nowadays its a necessity.
• Speaking of 3D.  Developments are arriving thick and fast.  From Avatar in a cinematic context, augmented reality, 3D on every conceivable device, and while this 3D print of a vein is intended for ‘replacement body parts’, 3D printing of objects is mainstream and may well turn out to be a valuable surgical preparation tool.

There is a common thread to many of these – the involvement of Google.  While the big G is by no means responsible for all advances, I think maybe it’s energy has a beneficial effect on innovation generally.  Google’s blunderbuss approach to innovation sometimes leaves me lukewarm.  As an example, consider Google’s many patents (for one and another) for scanning the pages of bound books.  innovative, perhaps, but it leaves me thinking – why not just guillotine to binding?  For 99% of books – thats ok surely?  But in general, Google is setting the pace – and many of the other big players in technology have woken up and contributing.

The rest of us can only benefit.

New release for DCM4CHEE: 2.14.8

Posted by Martin P in DCM4CHEE      No comments

Mar
22

So we now see the release of DCM4CHEE 2.14.8.  While in terms of version number it is a minor update from 2.14.7, in many ways it contains some major feature additions.  As one might expect, there are a number of bug fixes and background changes, but there are a good handful of changes that may well have positive impact on installations:

• DCMEE-1343   Improvement of tolerance of illegally/inappropriately encoded DICOM datasets (yes, even today, it still happens!).
• DCMEE-1292   Improved timer handling for periodic taks.
• DCMEE-1340   Sync the filesystem before sending C-STORE-RSP.  A success response is not sent until the filesystem actually writes to disk to mitigate against a server crash while data is in filesystem cache.
• DCMEE-1373   Improved performancee in XSLT processing.

But along with these are two very significant elements:

• DCMEE-1356   Storage of lossy compressed images on a different FS group to the original image.  This is significant in two ways – firstly, while DCM4CHEE has to date supported lossy compression on previously compressed images, it has not actually compressed images itself.  Secondly, and more importantly, is how this could potentially be used.  I haven’t played with this myself just yet (I will), but for the moment I read this as follows.  Browser-based delivery of images has proved to be tough in one important respect – Window/Levelling.  Just about any scheme for getting a browser based application to window/level images requires some aspect of server-side processing – and image resizing is an important element of that.  It is of course possible for images to be resized from the full quality image each time, but for browser delivery – that is a massive waste of server resources, and makes performance a real issue.  Having a lossy compressed version of the image available makes this scenarion so much more viable.  More on this after I have had a chance to work through the new feature.
• DCMEE-1358   Migrate from JBOSS MQ to JBOSS Messaging.  This is an important upgrade.  JBOSS MQ was deprecated in favour of Messaging some years ago, and ongoing development discontinued not long after, as a result of which, MQ is severly limited in many ways – including message instance management.  The DCM4CHEE forums have a number of threads around monitoring and management of (for instance) the Forwarding Message Queue.  MQ has never had the capability to do this with any great effectiveness and the move the Messging can only improve the situation.  Again, more of this later.

The role of people in PACS purchases. Courting and Marriage

Posted by Martin P in PACS General      No comments

Mar
17

So the AMICAS and Merge deal is going ahead. I have no great experience of either (other than Merge doing open source software a disservice with the free-but-proprietary-and-eventually-not-free-and-not-even-particularly-good eFilm. Not that they did anything actually wrong – but a disservice all the same), so I’m not going to even try to make any analysis.

But I will point to someone who does have sufficient experience, and who picks the most important element that any vendor brings to the table – people:

But AMICAS is far more than a collection of software.  AMICAS is nothing less than the sum of its people.  I know them well,  I have worked with these people for years, and they are the finest in the business.

Mike Cannavo (it seems, the one and only PACSMan) misses it on his article on 2nd-time PACS-ers, but the reality is no matter what technology you have, people are the key, if people are pushing in the wrong direction, you’re going to have problems.

It’s taken me a long time to fully grok this, but I’m as sure now as I have been about pretty much anything that the choice of technology actually isn’t as important as many people think it is. I have certainly been on projects where the technology choice was largely driven by a massive, detailed matrix of what the solution MUST have, what the solution SHOULD have, and what it MAY or MAY NOT have. This matrix is then used to differentiate between a shortlist of 3 or 4 possible solutions. In fact, when one reduces the process to delivering specific benefits, actually ALL of those solutions could have done the job.  I may have liked some more than others, but they would all have provided adequate return on investment at least from a technology point of view. The biggest differentiator is ALWAYS the people the vendor(s) bring to the project not just now – but along the entire system lifecycle.

Automating a process with information technology – or changing the technology behind an already automated process will always involve change, and people notoriously do not like change.  I suspect what much of the massive detailed selection matrix is there to do (perhaps unconsciously) is try to minimise change rather than accepting it. This is why IT projects (including PACS) traditionally have such a high failure rate – the technology is expected (almost always unrealistically) to fill in the gaps where stakeholders have been unwilling to make necessary changes.

So how to ensure that the selected solution carries with it the people most likely to deliver the targeted benefits? Clearly, reputation helps. But a vendor getting a good reference from a site with a completely different culture to one’s own is quite irrelevant.  It is clear to me that many organisations generally and certainly in Healthcare have no idea what their culture is – or even that they have one.  Understanding where one is coming from is the first piece of the jigsaw.

And then both sides of the fence should court.  Yup, it’s an old fashioned word but the alternatives don’t quite seem appropriate.  Open Source solutions make this ritual a little easier but it can be done with proprietary vendors also.  Start small (the first date) with a small, perhaps peripheral or standalone purchase. Don’t put all your eggs into one basket at first – you may not know who you’re going to end up with in the long term so keep an open mind.

If the first date works, go that little bit further (you know what I mean!). Go steady and get involved in a little interfacing.  If that works out, bring your vendor into your core operations.

It may turn out to be a whirlwind romance.  Or not.  Either way, transition to engagement and marriage is through a process that suits all parties and maximises the chances of compatibility.

And what of those vendors that insist on talking about the big picture?  Who won’t even get out of bed if you’re not about to spend in seven figures?  Well that’s a bit like proposing on a first date.  It happens, and sometimes it works, but not often.

Maybe you don’t have time to go through this process.  Maybe you need to ‘get on with it’.  Well, due diligence takes time whichever way it is done.  Understanding who you’re getting into bed with should be part of that process.