Saturday, July 4, 2009
Posted in Hardware, PACS General at 1:50 pm by Martin P
Various forms of 3D representation of radiology data are becoming routine within the diagnostic world. But although the increase in performance of multi-core CPUs has rocketed in the last few years, it is raw processing power that remains the bottleneck to better and more useful 3D applications. But in the last couple of years in particular, the world of supercomputing has entered the commodity hardware market by utilising GPUs (Graphics Processing Units). These were designed to accomodate the home gaming industry with fantastically realistic rendering of 3D scenes, but can be used for any processing task which can be parallelised. So while a ‘good’ PC of today’s standards might sport 4 or 8 CPU cores, GPUs come with hundreds or even thousands of cores, for just a few hundred dollars.
I initially missed the AuntMinnie article, but even at this point, the idea is mature enough for modalities to be shipping already using GPU HPC. It can’t be long before GPUs are used this way in regular PCs and workstations. Of course, 3d reconstruction isn’t the only application that may take advantage. As a result of GPU-based HPC, apparently passwords just aren’t secure anymore, Bruce agrees. back in the world of Radiology, voice recognition has long been dogged with reports of excessive error rates (referential pun intended! 
). It seems that a VR system parallelising several hundred cores may well be able to improve that situation. Work has already started on using GPUs for decision support - perhaps that may be a new beginning for the potnetial-not-yet-fulfilled CAD.
Nvidia has a nice one-page primer, HP go into a little more depth.
Edit: just to drive home the difference - CPUs have FLOPS metrics in tens-GFLOPS. Even now, GPUs are measured in Tera-FLOPS. Although I don’t think they really run as warm as some suggest.
Permalink
Thursday, July 2, 2009
Posted in PACS General at 9:46 am by Martin P
Mike Cannavo speaks a lot of sense in the third part of his series on building a better PACS. Comparing the relationship between vendor and customer with that of Mariage (as he has done on a couple of occasions before), he has an important point. The reality is the technology differentiaters between vendors are fairly easy to tease out in the context of an organisation’s requirements (as long as they themselves are properly understood). The BIG differentiator is about people and cultures - both that of the customer organisation and the vendor. Even if the chosen vendor’s product turns out to be not-quite-perfect, it is the reaction of people on either side of the contract that will determine the level of success or failure.
It is crucial for a prospective customer to understand it’s own cultural biases and be able to match those with the vendor. A simple example of this is in how dirty a customer wants her hands to get. Some may want to understand what is happening in the guts of the system so they themselves can participate in the formulation of solutions - enter Vendor A who is happy to be open about their technology and internal processes. A second prospective customer (organisationally) may want nothing of the sort. Many want a fully turn-key solution that simply does what is says on the tin. Enter Vendor B who is happy to flood the customer with engineers for a week (oh, and charge for it!) while the customer carries on as normal. Swap those combinations around and however well selected the technology, the probability of success is drastically reduced.
Mike also expands on his notes from Part II on The Contract. There is one element of the contract I feel strongly about in the contract and that is the definition of ‘downtime’.
Downtime begins with the receipt of a call to (the vendor) by the PACS system administrator (PSA) that the system is inoperable and a determination is made that the problem can not be repaired remotely. Downtime shall continue until such time as the system is fully operational.
The word ‘inoperable’ is important. Does this mean when all elements of the system are unavailable (the likeliest interpretation from the vendor), or does it mean “Ok, DICOM SCPs are up, delivery to the reporting stations are ok, but DICOM QR and Web distribution are down”. Hmm I guess that means the system is partially up, therefore operable.
There is one good way to fix this and set it in stone. A good implementation process will have a pre-defined set of tests loosely defined as System Acceptance and User Acceptance. A subset of these test sets should be marked as critical, and ‘downtime’ defined as any scenario which would cause any one of the critical tests to fail. Is that being a little hard on the vendor? Maybe, but who is the one stumping up millions of bucks for a system?
Permalink
Tuesday, June 23, 2009
Posted in Development at 1:06 pm by Martin P
Living and working (as I occasionally do) outside the US, the workings of the FDA, and the CCHIT are of limited relevance. Limited, but by no means negligable. Many individuals as well as institutions outside the US consider FDA 510(k) an important indicator of fitfulness-for-use. Never mind the fact that the US - being the world’s largest market for Healthcare IT - is the primary driving force for the products that are subsequently shipped elsewhere. I suspect, should CCHIT follow the path that the US administration expects it to, then CCHIT will fulfill a similar role as the FDA does in PACS.
Indeeed, I’ve speculated before that CCHIT might take on some of the role the FDA has fulfilled to date in certifying the quality of potentially patient-threatening (as well, of course, as patient-benefiting) and I still believe that is a credible path forward. CCHIT has had critics in recent times over its positioning of the certification process at large corporate vendors, although progress seems to have been made - Fred Trotter being amongst the legions putting the pressure on.
But this is my problem: The certification requirements as far as I can see read like a functional specification. There is no consideration that the functionality as implemented might, quite simply, be crap.
The FDA process does include a loosely defined concept of software engineering best practice which at least ensures the vendor has put some thought into design, engineering and defect prevention. CCHIT seems to have none.
So as much as I turn green & roar a lot when I see Access databases (written by a couple of just-grads with little or no experience of real development) being wheeled into hospitals to manage departmental workflow or EVEN WORSE live clinical information, it seems if the current formulation from CCHIT is followed, I’ll have to put up with it.
Permalink
Sunday, June 21, 2009
Posted in Browser matters at 4:20 pm by Martin P
Way back last August I predicted we may see the upgrade from Firefox 3.0 to 3.1 appear potentially by late September 2008. So much for my skills of prediction. In the meantime, we’ve seem Firefox 3.1 being rebranded as 3.5 (justifiably, because the leap is substantially more than a 0.1 point release!) and go through an extended period of alpha- and beta - testing. Over the last week or so, we’ve seen the release of Release Candidate (RC) 1 and RC2 - possibly the final pre-release version.
The main benefits (from my perspective) are:
More details in the release notes.
FF was beginning to remind me of the Debian Linux project’s problems in release strategy of years past but I’m glad they didn’t succumb to the temptation of competing with the Google Chromium release and IE 8 but instead took the time to make this a serious contender for (again) best browser.
Check it out. It’s good.
Permalink
Monday, June 8, 2009
Posted in Development at 3:52 pm by Martin P
The key to a ‘good’ user interface (UI) is that the UI distills what is often a complex morass of information into a simple representation. Ben Galbraith likens the process to craftmanship. Quoting Joel, describing the fitting of trim around a door:
You can’t tell this from the picture, but the screws in the middle strips are almost but not exactly lined up. They are, maybe, 2 millimeters off. The carpenter working on this measured carefully, but he was installing the trim while the doors were on the ground, not mounted in place, and when the doors were mounted, “oops,” it became clear that the screws were not exactly lined up.
Avoiding that 2mm error before it becomes too costly to fix is where the craft is.
But more. Galbraith cites the popularity of the Nintendo Wii despite it being technically inferior in many respects to its competitors. The craft is knowing which expectations to exceed - to the folk that love the Wii (including myself), the expectations have nothing to do with the fastest, most realistic 3D rendering, but in the way I interact with the experience. The craft is knowing where those expectations lie. It has traditonally been called “requirements analysis” but in my mind, craftmanship beats requirements analysis every time.
Permalink
Posted in Hardware, Infrastructure at 12:35 pm by Martin P
I note from HealthTech Wire that Fuji are
the first PACS vendor to officially validate its virtualization solution at VMware corporate headquarters in Palo Alto, Calif.
… Which may be true, but I’m glad to say that the number of PACS vendors which are qualified on virtual infrastructure continues to build. For the last 3 or 4 years in particular, server virtualisation is the only way to deliver servers in any medium- to large- sized organisation.
the benefits of virtualisation are well proven at this point:
- Hardware consolidation means:
- Reduced power consumption. The typical non-virtual server room eats power (and the money it costs) at an obscene rate.
- Increased reliability. Each and every server can take advantage of the highly redundant hardware configuration traditionally reserved for only a handful of the most important servers.
- Hardware abstraction, or the control of the environment which each instance of operating system sees as its hardware base. This gives benefits:
- Performance management. Need extra processing power? Just move the virtual server over to a different corner of the environment which has lower overall utilisation. Simple as that.
- Business continuity. Especially when combined with good storage-level replication, the catastrophic loss of one of a pair of datacentres just means the servers need to be re-expressed in the other.
It is understandable perhaps that PACS vendors have been a little slow to qualify products in a virtual environment - there are two types of application in particular that perform less than optimally under virtualisation:
- Applications with dependence on parallel processing.
- Those with high IO demands - in terms of either volume or latency.
The latter of these clearly could be said to include PACS, but the evidence is now clear that PACS (at least good ones) does not have IO requirements that a virtual environment cannot deliver.
Which of the various flavours to invest in? There are three main threads:
- VMWare is free to download and use (even if they have some archaic licensing hooks) and is widely recognised as being the industry leader - although this is primarily down to the technologies to do the ‘enterprise’ stuff like move VMs across hardware without downtime which itself comes at a price).
- Microsoft’s Hyper-V is also free with Server 2008. I can’t speak too much to this but I suspect like VMWare, to do any heavy lifting with require additional product which costs.
- The Xen family of vendors, including Oracle and Citrix leverage the Open Source (i.e. truly free) Xen Project.
Which is best for you is dependent on a number of factors - including your own appetite for risk. The biggest consideration though is the same as with selecting a PACS - be sure to chose a vendor (or in most cases, a reseller) that you can work with.
Permalink
« Previous entries