Comments for York and stuff

Comment on Lossy Compression by Tom Warfel

Wed, 06 Aug 2008 22:10:55 +0000

About 15 years ago or so, two HP researchers named Natarajan and Konstantinides produced a few papers on something called “Occam Compression”, doing slightly lossy compression as an image enhancement technique. Because medical imaging is inherently noisy, at small amounts of lossy compression, you lose noise faster than signal. The resulting “lossy” images will actually have a better signal-to-noise characteristic than the original source images. Choosing the appropriate lossy compression algorithm is a function of the underlying imaging modality and the nature of the noise.

If we were a little smarter (and we could be) about choosing the lossy compression settings, one could make a good argument in favor of storing lossy images as a way of optimizing signal-to-noise, and gaining better transmission and storage characteristics to boot.

Comment on Who owns PACS — Radiology or IT? by Cynthia Keen

Thu, 17 Jul 2008 15:44:54 +0000

The article reflects the forum as it was presented at SIIM — edgy, irresolute, and humorous. We were reporting this event as we saw it.

Dr. David Channin came to the podium attired as a 1960’s Cuban revolutionary, replete with hat, beard (real) cigar and thick Spanish accent.

Comment on Open Source Participation by Peng

Sat, 28 Jun 2008 21:29:41 +0000

I was wondering about Open Source speech recognition the other day.

No I understand why it’s not out there yet.

Peng
www.midessexray.com

Comment on How can we be sure proprietary software is safe? by Martin P

Tue, 22 Apr 2008 19:04:21 +0000

Steve,,, I don’t think we’re singing from completely different hymn sheets. I do think that the additional transparency does create a situation where the case I quoted would be less likely to happen.
But your reminder that OSS can be just as dire (and in some instances more so) than proprietary software has set me thinking of under which circumstances OSS does improve the quality of software (if indeed there are any patterns involved - I’ll admit - I’d like there to be ).
As a first thought - for the vast majority of open source projects, there is clearly no guarantee or indeed likelihood that any kind of code review occurs. But as projects become successful and commoditised, the level of community code review increases.

But you are absolutely right - quality is about the engineering, not just the programming and code review only addresses the programming. The core of the software - whether proprietary or open - is the vision and structure imposed by the early leaders - usually no more than 2 or 3 individuals. If that is wrong, no amount of fancy coding techniques can make a silk purse out of a pig’s ear.

Comment on How can we be sure proprietary software is safe? by Steve Severance

Tue, 22 Apr 2008 15:42:31 +0000

I actually partly disagree. While open source does increase transparency I am not sure that simply open sourcing software would result in software that lead to better patient outcomes. I do not believe that open source software is inherently more secure than closed source software. There are many examples to back this up. Good software is the result of sound engineering practices that can exist in either an open source or closed source world.

Part of the problem is that for a variety of reasons customers keep coming back to the same wells. Part of that is because regulation limits options and partly because it is often easier to do so.

Now would I like more software to be open source? Yes. But as I think you allude to this isn’t likely to solve anything by itself.

Comment on Database Replication by Steve Severance

Thu, 28 Feb 2008 16:17:24 +0000

Yeah I know that lack of consistency is a foreign concept. It requires applications to handle inconsistent data. So it is possible to get back multiple versions of a row and the application must be able to disambiguate them. Check out http://www.allthingsdistributed.com/2007/12/eventually_consistent.html

Obviously a typical PACS has no need for this kind of scalability. However as we see larger and larger deployments the database will become a bottleneck and people may opt for some sort of amazon like model.

Companies would have to hire some better software engineers since the current crop seem unable to build stable software with robust, time tested tools.

Comment on Database Replication by Martin P

Thu, 28 Feb 2008 14:08:33 +0000

Steve.. Agree 100% re MySql. Any code out of this stable will be optimised for MySql but there are valid reasons for preferring other rdbs so choice is important too.

I think ‘eventual consistency’ is a feasible concept when there are no dependencies between endpoints that potentially can have inconsistent data (as in the oft-used example of DNS), but that rarely applies in the context of RIS/PACS - it is potentially a danger to patients to be otherwise. Radiology leads this concept with the commonly-available PACS feature that Rads are warned if they attempt to report on a study which another Rad is reviewing.

You’re dead right. Many PACS are not engineered to be fault tolerant. It isn’t simply about database replication - it must be a foundation stone of the software itself rather than a bolt-on to reclassify systems into the ‘enterprise’ space (as it too often is)

Comment on Database Replication by Steve Severance

Wed, 27 Feb 2008 04:16:15 +0000

Consistency is over rated. Modern distributed environments have ways of dealing with this. Amazon’s database is as they describe it, ‘eventually consistent’. Modern databases have good clustering technology as you allude to but many people do not implement it because of cost. IMHO MySQL should be the turned to database. Saves money too. It has proven its metal in the most demanding environments.

Eventually consistent databases do require a new way of thinking about things, but it does work. Most PACS are just not engineered to be fault tolerant.

Comment on What are the benefits of Open Source ? by Steve Severance

Sun, 17 Feb 2008 23:31:19 +0000

I want to point out that often users suggestions are met with the response of, “Thats a great idea. Why don’t you contribute a patch.” Certainly some of the projects that I am involved with are not like that but they tend to be in infrastructure category. The most successful open source projects are in this category, e.g. apache, JBoss, MySQL. Other common software like SugarCRM has a good model to clone.

Cloning in health care is hard. While there are lots of people with related experience to CRM health care is defiantly more sparse. Also with many of the developers that are in health care are not engaged in the community and their companies actively discourage it.

Good post.

Steve

Comment on Multi-frame loading by radix

Thu, 14 Feb 2008 22:45:50 +0000

Hi there. Some more things to consider…

Scripts need to be user editable in the GUI, as each user has a different idea of what is ‘relevant’. In addition, there is a clear distinction between plain old priors and relevant priors; a mechanism is needed to make that distinction.

Onto preloading considerations. I think a strategy could include a prioritisation based on the following factors:
- RAM availability
- compression/decompression overheads for web access
- single or multi-threaded downloading (high/low priorities)
- local multiframe DICOM caching

Thin-slice CT data is a little tricky in my opinion. Some administrators elect to store that data on demand, some always store it, and some never. I wonder if a percentage load of the series, based on the available RAM, would be a strategy.

Doctors invariably often load series they didn’t mean to. I think the beginning of each series takes priority over the end.