Googling your PACS

Posted by Martin P in PACS General      No comments

May
24

I recently read an article pointing out how ubiquitous Google is nowadays, I realised that I had started to follow the pattern of using the big ‘G’ as an entry point to all things interweb. Lets say I have a few moments to check on what Dave Clunie has been up to. Now – is it daveclunie.com or dclunie.com? Sod it. Google Dave Clunie and there he is!

Most people presume Microsoft wanted to ‘merge’ with Yahoo to compete with Google, which indicates that getting to the point of competing is a challenge indeed. And indeed it is – because the Google search algorithms are quite extraordinary. Let’s face it, if what you are looking for doesn’t appear on page 1 of a Google search – you probably messed up your search terms.

Wouldn’t it be great if the same algorithms could be applied to searching in PACS? Not possible, alas, as Google keeps the algorithms closely guarded. Until now.

read more

Polling from a web browser (or not)

Posted by Martin P in Development, IHE      2 comments

May
24

I recently wrote a few notes on the major challenge towards CCOW adoption in browser-based applications – avoiding the necessity for polling for context updates. There is a technology ‘umbrella’ going by the name of Comet which wraps quirks and tricks in a browser to achieve server side ‘push’ communication, but there may be a new kid on the block.

Cisco – who do have some pedigree in delivering useful technology, are launching an open source messaging protocol they’ve dubbed ‘Etch’, which is specifically designed for high volume traffic (the example given being 50,000 transactions/second) – not a limiting factor when dealing with RIS/PACS or CCOW, although round-trip latency is clearly an issue to consider.

But according to the CIO article (which appears to be the only publicly available knowledge at present)…

Another Etch feature that differentiates it from SOAP is the ability for the server to initiate message traffic to the client once a connection is established.

… now that sounds interesting. And, of course as CIO notes…

Cisco also is examining the possibility of establishing Etch as a standard. Marascio pointed out that Cisco is well represented in the IETF, the main standards body for Internet protocols.

… which might make a difference.

Lossy Compression

Posted by Martin P in PACS General      1 comment

May
17

AM reports on a SIIM presentation on the effects of lossy compression.

The mean percentage of “different” ratings was 2.3% for the lossless studies, 78% for the 8:1 ratio, 95% for the 12:1 ratio, and 99% for the 16:1-compressed studies, Krupinski said.

At the same time noting that differences in presented image do not necessarily translate into reduction in diagnostic quality, I ask the question why take the risk?

There are two reasons why lossy compression has ever been entertained in an industry which otherwise goes to great lengths to ensure maximum image fidelity – storage and bandwidth. In both cases, the argument for compromise is radically reduced in recent years.

The cost of storage is a fraction of its level even a few years ago. It is commonplace to find RAID 5 at €1000 per TB and that reduction is showing no signs of slowing. I have a post on storage in the pipe – watch this space.
Availability of bandwidth – both LAN and WAN has improved also, although not perhaps to the same extent. It is certainly trivial nowadays to feed a Gigabyte/s to a single desktop on the LAN, and availability of broadband has improved in orders of magnitude (at least in the developed world). It could be argued that even broadband-based WAN does not compensate for the increased data volume generated by recent generations of CT and MR, but it is a rare situation that the circumstances collude:

• A study of significant volume..
• ..of which all frames are required..
• ..to be reported over WAN..
• ..with no opportunity to utilize a local cache.

So where there is availability of multi-MB/s broadband, even the bloated data volumes increasingly seen today should not present a problem where quality compromise is appropriate. Of course, that is not the case where broadband has not penetrated, and perhaps the argument takes a different flavour for developing countries. where the balance between quality and compromise may tip in a different way.

For those of us lucky enough to have the infrastructure that can be available today, we should not even consider compromising quality because, quite simply, there is no good reason to do so.

CCOW Implementation in a web browser

Posted by Martin P in Development, IHE      2 comments

May
2

I’ve written before that I’m a fan of CCOW (given that it’s probably a little bloated for what it does). It still dismays me that so few vendors support it – obviously not enough buyers ask for it and I don’t know why. But there is an issue with the implementation of CCOW in applications written to run in web browsers – which an increasing number are, and it won’t be long before the majority of clinical application do so.

There are two defined interfaces to CCOW – ActiveX and Web (meaning http, but I’ll ignore the distinction just this once). I’ll immediately discount ActiveX from this discussion, since it is limited to IE and I believe browser-based software should be browser independent (in as much as possible/reasonable). Others may have a different position (and do!) but there you go. That’s me.

The CCOW web interface involves the following (massively simplified, of course) :
1. Application registers with a context broker to enter a given context.
2. Application listens on a port for http messages indicating a change in status within that context
3. http message arrives, application processes accordingly.

So where does the issue lay? There are no standards based mechanisms for browsers to listen on a socket, even though there are a small handful of mechanisms for effecting some kind of ‘push communication’ from the server (but only by using browser features in ways that they weren’t really designed to be, and then, browser independence is largely compromised again. There are good reasons – certainly with respect to security – why browsers are thus shackled. But in this case, there is also a good reason to unshackle.

read more