Two primary uses of CCOW
Posted by Martin P in 
There are two primary uses of CCOW:
- As a Single-Sign-On (SSO) mechanism. This makes user’s lives easier.
- As a means to synchronise patient (and other) context. This can make user’s lives a little easier, but more importantly, mitigates against cross-identification errors.
The first is the most common motivation for many (if not most) CCOW implementations. Which is (IMHO) opinion , a little unfortunate, because I believe the second to be more important. Having said that, once a CCOW implementation is into a site simply as SSO, there is always the possibility that context management is added later.
I see from a number of news sources that one implementation at least plans to use both aspects from get-go.
It can be done. More should be trying. After all, EPR applications are approaching their 50th birthday.
Why New PACS Fail
In many ways, RIS and PACS are unique in the world of ‘enterprise’ systems. But in many ways, including many of the reasons that new procurements go awry, they’re very much like other enterprise systems.
/. has a book review for a new book on Why New Systems Fail. Does this bit sound familiar?
Throughout the book, Simon puts a significant focus on human factors in project success and failure. He identifies issues such as internal politics, kingdom-building, reluctance to learn new systems, internal project sabotage, end-user resistance, and staff allocation. Simon divides firm personnel assigned to work on the COTS project into four groups — willing and able (WAA); willing but not able (WBNA); not willing but able (NWBA); and neither willing nor able (NWNA) — and talks about how each groups helps or hurts. Similarly, he identified four dangerous type of project managers: the Yes Man, the Micromanager, the Procrastinator, and the Know-It-All.
Mine is on order. I’ll report back here.
14-Aug EDIT: Report here.
Augmented Reality: Data Visualisation in Radiology
With computing power continuing to follow Moore’s Law, and new forms of Human Interaction Devices becoming mainstream (read: cheaper), different ways to present Radiographic imagery and diagnostic ‘experience’ are being developed by both academia and vendors. I’ve been a little sceptical about the benefits that may be achieved with multi-touch screens like iPhone and Microsoft Surface, although there’s a nice Radiology-specific proof-of-concept here.
In a previous life (like, 20 years ago), I had the good fortune to be involved in a really cool (albeit slightly politically incorrect) project involved in overlaying a Digital Terrain Model (DTM) onto a heads-up display for fighter arcraft pilots. This was one of the first applications for what we now call “Augmented Reality”, for which The Guardian has an article. A number of major vendors are taking this quite seriously, including Siemens.
In a couple of videos available on YouTube, we have overlay of a brain scan onto a phantom head, and even more impressive, visualisation in situ. The head and leg were likely chosen as subjects for good reason – as relatively rigid parts of the body. As pointed out in the Siemens paper above,
This first prototype does not account for patient movement, such as respiratory excursion with displacement of the lungs and upper abdominal organs.
.. but that was 3 years ago and is certainly not an insurmountable problem. This surely is the stuff of science fiction.
The end of OpenSolaris? A boon to ZFS?
Via /., Steven J. Vaughan-Nichols considers the likelyhood that Oracle, should the acquisition of Sun go ahead, will despatch OpenSolaris to the trash can. Other open-source projects currently sponsored by Sun, but unwanted by Oracle, will have a good chance of survival because they have enough community behind them to keep either the original project going, or a fork.
OpenSolaris, however, very likely does not have enough of a community to do so. That would be a real tragedy. Many years ago I cut my unix-y teeth on Solaris (back in the days when vi and VMS EDT were the only word processors worth knowing) so I’ll certainly look back with fond memories. Even now, OpenSolaris is seen by many as a rock solid OS.
However, there may be some silver lining to this cloud. read more
10TB array for less than a thousand bucks
The guys at Tom’s Hardware went through an experiment to construct a 10TB internal array for less than $1000. While technically a success, the conclusions:
These are our findings: The 12 hard drives…
- require careful system configuration (staggered spin-up)
- require a powerful RAID controller with sufficient ports
- aren’t convenient for desktop users
- are still subject to issues when using 2+ TB partitions
- deliver 6 to 8 times more throughput than an individual drive: almost 1,000 MB/s
- deliver 3 to 7 times better I/O performance than an individual drive
- result in 11 GB net capacity in RAID 5 or 10 GB in RAID 6
- deliver excellent cost per gigabyte, especially with the 1 TB Samsung drives we used (2 TB drives are still too expensive)
- still beat a flash SSD array in terms of throughput even if you keep two or three hard disks as spares
Now I’m an advocate of not paying too much for storage, but even Tom’s crew agree this may be going a little too far:
Most people probably don’t want to install more than a few hard drives into their PC, as it requires a massive case with sufficient ventilation as well as a solid power supply. We don’t consider this project to be something enthusiasts should necessarily reproduce…
… but it does suggest that more conventional storage need not be the major investment it used to be. A good NAS offerring iSCSi or FCoIP should be way less than 1TB/$1000.
Google Trends says IHE XDS is FUN
In my day job as well as in a research thread I have on at the moment I have increasingly come across IHE XDS – a subset of IHE which provides for the transfer of clinical documents across the enterprise. This is particularly important for systems with otherwise undefined integration profiles who can then (for example) exchange such items as discharge summaries into the clinical record.
Wondering idly if the rest of the world shared my increasing awareness, I turned to Google Trends and noticed something strange.
News of Google OS takes top rank in global media coverage….
Well, maybe not. But certainly when I opened up my news reader this morning, There was plenty of coverage of the news that Google are developing a browser-centric operating system. Comment came from Javascript site Ajaxian, from The Guardian, BuilderAU, and coming in slightly late (unusually), El Reg. Primarily focussed as a netbook platform, to mix it up in that market segment, Google nevertheless says:
Site Visits, Reference Sites, String and Stickytape.
In Mike Cannavo’s recent Part III to his excellent series on ‘ Building a better PACS’, he admits to not being a fan of site visits:
Most of the visits I’ve been on were more like congressional junkets than real learning experiences — a reason to wine and dine a client who pretty much has made the decision to go with them already. Done properly, however, a site visit can be beneficial. Unfortunately, most people just don’t do them properly.
One way to do a site visit improperly is to talk to the wrong people. In my experience, systems that can be considered to be any kind of success rarely do so as the vendor delivers them. Generally, a liberal helping of string-and-stickytape is required to match vendor’s vision of a healthcare enterprise with the reality on the ground. The right people to talk to – before, during and after a site visit, includes the people the aplied the string and stickytape.
One very wrong way to conduct a site visit is to listen to the folk who made the decision to buy a system. Ask yourself – you made a decision to spend $M and somebody asks you if the decision was a good one. What would you say? As this article on the London Stock Exchange’s decision to change its trading system queries:
I can only wonder how many other Windows enterprise software failures are kept hidden away within IT departments by companies unwilling to reveal just how foolish their decisions to rely on archaic, cranky Windows software solutions have proven to be.
Now in fact the decision seems to be to change the application rather than the operating system but the point remains the same.
Supercomputing comes to PC/Mac 3D workstation near you.
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.
Mike’s Building better PACS Part III
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?
Latest from the Blog:
Categories
- DCM4CHEE
- Development
- High Availability
- IHE
- Infrastructure
- Lessons learned
- News
- Open Source
- PACS General
- Project matters
Recent Comments:
- Martin P on Window/Levelling in a browser – CANVAS or server-trips?
- Martin P on 3D can be a dangerous game
- Juan Jose Cermeno on 3D can be a dangerous game
- A.J on Window/Levelling in a browser – CANVAS or server-trips?
- Suresh on Window/Levelling in a browser – CANVAS or server-trips?