Monday, June 16, 2008
Posted in Open Source at 8:58 pm by Martin P
One of the key benefits in Open Source Software is in its community. Outside of the warm, fuzzy feeling, there are very real, tangible benefits like support and diversity, amongst others. Smarter people than me have waxed lyrical on those benefits so I won’t here. But I will comment on a common misconception around Open Source - and that is that the ‘community’ is about developers.
It is true that successful OSS projects have a large proportion of developers at the core - lets face it - it’s about producing software after all, but there is much that gets done which isn’t ‘developing’ (even though it often gets ‘done’ by developers). The REALLY successful projects boast a variety of skills in their community - from web design professionals to marketing professionals to legal professionals and a rake of other skills that all make the project what it is.
But if you’re not one of those - what if you’d like to feed back into ‘the community’ but all you can offer is an occassional bug report - only to be told it’s been reported, fixed, and ready for the next stable release?
Well, there may be a way you can contribute a little time to make the world a freer place. This blog is about open source PACS and RIS - although it hasn’t considered the challenges in RIS very much (so far). Well here is one. One of the features virtually anybody would expect to see in a RIS is some level of integration with a dictation/speech recognition (SR) system. The problem is, Open Source SR is still in very much a developmental stage. That’s OK, the SR vendors will cooperate with anyone who may bring in sales, surely. Yes, but then is it really Open Source - especially when OSS SR is beginning to bubble.
Open Source SR has no lack of recognition engine - in fact there are 2 or 3 pretty good engines. What it is lacking is language acoustic models . That is a large collection on speech samples for the engines to match patterns against. This is where virtually anybody can offer value to a worthy OSS project.
Voxforge is an Open Source project to collect vox samples to fill exactly that gap. They’ve gone out of their way to make it really, really easy to submit even a few seconds of sample. Your community needs you.
Permalink
Wednesday, June 4, 2008
Posted in PACS General, Posting on-the-fly at 11:50 am by Martin P
Now this question annoys me, particularly in the form it is raised in Aunt Minnie, which as far as I can see, is just about the most effective way of stirring up so-called ‘turf wars’ that have resulted in so many failed PACS implementations in the past. Lets re-form the question a little: Who owns the Finance system? Finance of course. Who owns the HR system? HR Doh! So why does a hospital have an IT department at all? Simple, because there folks in IT who understand different things than folks in Finance, HR, and yes, (Gasp) Radiology, and can (generally, and to varying degrees, admittedly) apply that understanding to domain solutions that give value to the department as a whole, and to the wider organisation.
“If you don’t have budgetary control of your bucket of allocated capital dollars, you have lost control”
Is that it? Is it really about who holds the money? I have seen, in a major hospital, a clinical department ‘with the money’ base their clinical workflow on a system built on an Access database. I’ll repeat that. An ACCESS database. Any IT professional would offer good reasons why that isn’t a good idea - for the department or for the hospital, but the ‘in control’ department went ahead anyway, and then replaced the system 2 years later. If being ‘in control’ means locking out other perspectives to one’s own detriment, then ‘in control’ is paranoia (I think, I’m not a psych).
“Your critically needed PACS upgrade will be competing with acquisition of a new laser doodad for OR”
That may indeed be true. But lets face reality - IT doesn’t make that decision - the prioritisation of PACS upgrade vs laser doodad is one for hospital management, usually in the form of a ‘medical council’ of some form. It that perfect? No. Does that make it political? Yes. But its the way the rest of the world works, and in the context of the impact of informatics technology, the rest of the world works better than most healthcare systems.
To answer the question - who owns PACS - Radiology or IT? The hospital does.
Permalink
Saturday, May 24, 2008
Posted in OffTopic at 10:29 pm by Martin P
… As Sarah Lacy might say. But technology is one thing. This is real life.
Permalink
Posted in PACS General at 2:49 pm by Martin P
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 the rest of this entry »
Permalink
Posted in Development, CCOW at 2:08 pm by Martin P
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.
Permalink
Saturday, May 17, 2008
Posted in PACS General at 12:48 pm by Martin P
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.
Permalink
« Previous entries ·
