On the server and middleware side we have some wonderful open projects like dcm4che, dcmtk and gdcm. Don't underestimate the importance of a good UI - radiologists have very high expectations for viewer UI's and there is quite a bit of variance between them on what a good UI is. So that leaves you with people that are missing at least one of those three things (good developer, know domain, can build good ui) and that makes it very hard to build a product that a radiologist would actually use. They would likely be blocked from working on open source projects due to conflict of interest / IP concerns with their employer. This is really the main problem - those that are able to do it (good developers, know the domain, can build good user interfaces) are all gainfully employed and actually high in demand. > 2) You need developers that are able and willing to do the work. Mind you, most of the world is not bound by FDA requirements, so there should be quite a large audience for a non-certified approach. You can resolve this by forming a commercial entity that gets the FDA510k for the product and sells it - this has been done for both ClearCanvas and Osirix. > 1) If the target is a radiologist workstation used to interpret images, you will have adoption problems in the US due to FDA concerns. > There are several issues related to viewers: > We really do need a stable, cross-platform, fully featured open source viewer.
Rather, you get nag screens encouraging you to purchase the 64 bit version.
And it is not possible to build a 64 bit version, because these closed source libraries are only made available as 32 bit builds.
A good chunk of the core image reading and 3D rendering code is sitting in closed source libraries. > Regarding Osirix, I would not characterize this as GPL software, although much of it is distributed under the LGPL license. There really is no fully featured open source DICOM viewer available today, which is realy sad, given the size of this field. > This is quite an interesting discussion. > substitution, it can do so just fine, using the syntax that I posted. > When run under a Cygwin window fed with the files from a "find" shell > Btw: the storescu.exe from OFFIS can not recursively scan for images in > plus commercial closed source fully functional software). > hence the not uncommon "dual license" business model of GPL crippleware > holders specifically agree to license it under different conditions, of > the source of something derived from a GPL application (unless the > have its source made available by definition, since one cannot later > Indeed, an independently created certified version of Osirix would have > or sold it only requires that the source be available.
> cannot be identical the GPL does not preclude software from being > There is no reason why the open source version and the certified > uncoupled from GPL because of certification reasons. > approved open source software? As far as I know, even Osirix CE is now > medical software business? Are there actually examples for FDA/ISO > - What about the always imminent FDA and ISO certification issue in the > paucity of offerings, which is why it would be so much better if you > choose from, like Osirix on the Mac, but still there is a distinct > Fortunate users of other platforms have open source workstations to
> which is implied by the availability of the source. > continuing support, possibly by someone other than the original > I agree most users don't care about the source per se, but only about > and as you point out, are screwed when buggy implementations are no > to keep their source closed, and as a consequence users have no choice, > Actually, I conclude that Windows freeware or shareware developers tend > usability, a "dead end" looks different in my eyes. > of users do not really care for open source but for functionality and > 1.5 and DicomWorks, both of them not open source (and of course sort of > - the currently most widely used free (gratis) dicom viewers are E-Film > On Monday, Janu8:38:46 PM UTC-5, David Clunie wrote: > On Saturday, Ma9:29:19 PM UTC-6, Aaron Boxer wrote: On Monday, Ma9:08:50 AM UTC-5, Chris Hafey wrote: