an idea

[Aaron Boxer]

I was thinking: wouldn't it be nice to have an FDA and CE approved open source DICOM viewer?

Kickstarter and Indiegogo have been pretty successful at raising funds for open projects:

Would it be practical to have a Kickstarter project for this?  I probably misunderstand how these regulatory approvals work, but I think the commercial viewers are way over-priced.

This would bring the price down for all othe commercial viewers,  as well as provide an economical diagnostic solution for all.

And the code would be "alive", free to be improved, and extended by the community.

Cheers,

Aaron

[Aaron Boxer]

Here are some relevant links:

http://www.qmed.com/news/can-open-source-medical-devices-win-fda-approval

http://science.slashdot.org/story/13/11/17/1427220/12-lead-clinical-ecg-design-open-sourced-supports-tablets-too?utm_source=slashdot&utm_medium=twitter

[Greg Silverman]

I would be willing to collaborate on this project in some wave, shape or form; but realistically, who would fund such an endeavor? 

Greg--

-- 

Greg M. Silverman

Senior Developer Analyst

Cardiovascular Informatics 

University of Minnesota

[Aaron Boxer]

Hi Greg,

I would be willing to collaborate on this project in some wave, shape or form; 

Great, I may take you up on your offer :) 

| but realistically, who would fund such an endeavor? 

Well, the way I understand crowdsourcing to work is that you make a pledge

and are promised something at the end of a certain time frame if the goal

is met; otherwise the money is returned.

So, rather than buying N licenses for a commercial viewer at  say $2500 per license,

(this is what Clear Canvas charges for their workstation, for example)

you would receive unlimited licenses for a donation of, say, $200. Assuming

enough others do the same.

So, assuming that the timeframe is reasonable, and the product is of sufficient quality

and scope, there is an incentive. Also, donors could have a say in the feature set.

We would not need to start from scratch, since there are a number of open source

viewers to build on.  

Cheers,

Aaron

 

On Friday, November 22, 2013 12:26:35 PM UTC-6, Aaron Boxer wrote:

Here are some relevant links:

http://www.qmed.com/news/can-open-source-medical-devices-win-fda-approval

http://science.slashdot.org/story/13/11/17/1427220/12-lead-clinical-ecg-design-open-sourced-supports-tablets-too?utm_source=slashdot&utm_medium=twitter

On Fri, Nov 22, 2013 at 1:10 PM, Aaron Boxer <box...@gmail.com> wrote:

I was thinking: wouldn't it be nice to have an FDA and CE approved open source DICOM viewer?

Kickstarter and Indiegogo have been pretty successful at raising funds for open projects:

Would it be practical to have a Kickstarter project for this?  I probably misunderstand how these regulatory approvals work, but I think the commercial viewers are way over-priced.

This would bring the price down for all othe commercial viewers,  as well as provide an economical diagnostic solution for all.

And the code would be "alive", free to be improved, and extended by the community.

Cheers,

Aaron

--
You received this message because you are subscribed to the Google Groups "dcm4che" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dcm4che+u...@googlegroups.com.
To post to this group, send email to dcm...@googlegroups.com.
Visit this group at http://groups.google.com/group/dcm4che.
For more options, visit https://groups.google.com/groups/opt_out.

[Hakan Gul]

Hi Aaron,

I already rebranded the opensource ClearCanvas workstation.   We rebranded all the asssemblies too.

So there is no name of ClearCanvas on the assemblies.   I also changed the splash screen and everything.
Getting the FDA approval is something else.  We most focused on the web side.  So I don't know the guidelines.

First you need to create a brand name and rename the assemblies accordingly and create splash screen too.

I can do something like that in 1-2 days.  But you need Login screen and few other stuff to make the app HIPAA compliant.

And on top of this the ClearCanvas desktop works only on microsoft windows.   But like I said I can provide the rebranded code with a setup.
Already did it.  The rest you guys can do it.

Thanks

[Aaron Boxer]

Hi Hakan,

FDA approval means that the FDA has approved a dicom viewer for diagnostic usage. 

Its different than branding. Without FDA approval, many US physicians cannot use a device

to diagnose illness.

I'm curious: which version of Clear Canvas are you using? The latest version from github?

Regards,

Aaron

[Hakan Gul]

Yes i use the latest version from githhub.

.Net 4.0

[Aaron Boxer]

Hi Hakan,

Interesting. The Github version is distributed under the GPL 3 License.

Under the license, if you modify the software and sell it, you need to 

provide the source code for these modifications to your customers.

Just a heads up.

Cheers,

Aaron

On Sat, Nov 23, 2013 at 3:26 AM, Hakan Gul <hakan...@gmail.com> wrote:

Yes i use the latest version from githhub.

.Net 4.0

[Hakan Gul]

Hi,

i don't sell it. We developed a cloud system. We open an account and give the workstation for free. We just charge monthly to Store and view dicom studies. That is why we redeveloped the oviyam viewer. The world is going to the cloud.

We plan on creating mpr and 3d for the html5 viewer in the near future. My advice Will be to focus on the cloud.

[Aaron Boxer]

Hi Hakan,

Thanks. Very interesting. Yes, GPL does not apply to Software As A Service products

such as yours. How do people feel about storing their data on a third party server?

Who owns the data once it is uploaded, and what kind of guarantee do you give

customers that they will not lose access to it? Just curious.

Cheers,

Aaron

[Ghetolay]

What kind of Viewer are we talking about ? A basic Viewer with windowing/zoom/annotations and maybe MPR/MIP or a full multi-modality Viewer with more advanced features ?

You talked about clearcanvas and I wouldn't work on a .Net project limited to windows.

Now Hakan is right, future seems to be about remote Viewer and multi-device. It may worth considering a web viewer and multi-device based Viewer.

Anyway the idea isn't bad but we need some detailled specification.

[Hakan Gul]

Hi Aaron,

Let me explain how things work.  The client uploads their studies with a web based  java applet uploader.
No VPN required.  The users drags and drops the study folders, or can select a whole CD and upload it.  The uploader scans the files and uploads the study(s) to their partition.

Once uploaded the client can assign the studies to specific authority groups.  So this keeps the studies secure.
And each client can only view their own partition and users.  The doctor views the study in the HTML5 viewer and creates a report.
We also have reporting system with ready templates.   The user can also download the study by clicking on it.  

The data is owned by the client and they are ok with it.  We do periodic backups and have high security.
The client loves it because they don't have to invest in expensive hardware and software.  On top if this there costs associated with IT support they don't have to pay.

If you want more info you can get in touch privately.

Thanks

[Hakan Gul]

Hi Ghetolay,

Your right the future is in remote viewing and cloud storage.

The telecom firms in Europe and Turkey are after this platform.   The web based HTML5 viewers are getting more advanced.

In the near future health institutions will not even install desktop workstations.  They will view everything web based of a cloud.

[Rady]

We also do a very similar work for our South Asian clients Cloudbased and Pay per use Model. Ours on Aws (workflow and Metadata on our instance) and S3 (Image Storage on customers instance). We let the client to purchase the S3 bucket and we push the images on the bucket on a very secured communication channel.  Later the S3 Data is also archived on Glacier for long term storage automatically. 

For viewing on Radiologist side we use Clearcanvas (No re-branding). We let the client know that we are using a opensource viewer. It adds credibility as this viewer is used by thousand of users.  

Glad to see many are moving towards the cloud, I agree that is the reality today for Small and Med size Diagnostic centers or Hospitals like people only have US, CR, etc..

with regards

Rady

[Hakan Gul]

Hi Rady,

Great to see you guys are getting the best out of the cloud. 

Do you guys use the ClearCanvas 2.0 with the setup or just created a setup from GithHub code.

I am looking for the old setup too.  As for viewing, we fixed the HTML5 viewer and they are mostly using that. 
But for more advance stuff like MPR, they use the desktop viewer.

If its possible can you send me the download links for the ClearCanvas workstation.  My email is iamh...@yahoo.com.

Thanks

[Rady]

Hi Hakan Gul , 

We have created our own Setup with Clearcanvas Viewer. I have send you both 32/64 bit viewers. 

regards

Rady

[Hakan Gul]

Thanks Rady !.   Your great !

[Alvaro G. [Andor]]

Hi,

Although I'm a bit late to this party, I'll offer my limited knowledge to this FDA and CE approval thing. Please correct my mistakes if I'm off, and sorry in advance for my crippled english.

AFAIK open source viewers can't be approved by FDA or CE 'as is'. Simplifying greatly: Open source viewers can be modified by the client (changing its behaviour) and there's nobody accountable of the distribution (as a legal corp or something similar must be the holder), so FDA doesn't like it.

But, you can make a distribution of that viewer and FDA can approve that binary distribution, where you (as a company) are responsible of maintaining the functionality of that distribution.

This is fairly common, and we can use OsiriX and a example:

• There is no difference between OsiriX OpenSource (which isn't really opensource, but that's another terror story I can tell you later) and OsiriX MD (FDA approved) but the nagscreens.
• There are a series of companies, included mine, which have made FDA and CE approved OsiriX distributions where binaries, although derived from that source, were distributed and controlled by those companies.

That's right on the FDA view, as there is somebody (a company) who's taking care of being legally responsible of that viewer, and controlling its distribution.

Because finally, FDA is mostly worried about liability.

:D

So, we can make a web viewer viable for FDA approval, but, some corp must in charge of FDA approval...

Hope I've helped a bit.


El 22/11/13 19:10, Aaron Boxer escribió:

[Aaron Boxer]

Thanks, Alvaro.  That helps clarify things for me . So, FDA approval is about having someone to sue if something goes wrong :)  

What I don't understand is this: the app runs on top of an operating system which could be open source,

but doesn't require FDA approval. So, who is liable if an OS bug causes patient safety issue?

I'm also curious about Osirix. Can you say more about it not being open source ? Do you mean the closed source plugins?

Cheers,

Aaron

[Alvaro G. [Andor]]

Hi there!

El 06/12/13 16:57, Aaron Boxer escribió:

Thanks, Alvaro.  That helps clarify things for me . So, FDA approval is about having someone to sue if something goes wrong :)  

What I don't understand is this: the app runs on top of an operating system which could be open source,

but doesn't require FDA approval. So, who is liable if an OS bug causes patient safety issue?

That might be a funny and complicated answer left to the lawyers and to be dealt case by case, but I don't think the nature of the OS behind might make much of a difference:

Imagine you're using some medical software under Windows, and you diagnose wrongly a cancer because the color profiling API is behaving in a funny way. I don't think you would have any big case against Microsoft but instead against the medical company which got the FDA certification for that software and didn't have proper ways of checking the integrity of the process. And anyway, they don't care. They have insurances for that.

I'm also curious about Osirix. Can you say more about it not being open source ? Do you mean the closed source plugins?

In certain moment, version 3.9.4 ( http://www.osirix-viewer.com/Roadmap.html ) , they included the Kakadu library for JP2K. As most of you probably know, that's not opensource, and it was included as a linked library, essential to running the software. The installer only showed the LGPL license on running it (and still does) with no mention to the Kakadu library.

I expressed my concerns about this in the mailing list: http://groups.yahoo.com/neo/groups/osirix/conversations/topics/22335 (you may need to be logged in and registered). At a certain point, when asking exactly what kind of distribution license do they have with Kakadu, my questions were moderated out of the mailing list and the debate was silently forbidden.

One of my main concerns, apart from the open source thing, is that most of the licenses for Kakadu say "... will not receive Commercial and/or financial benefit by developing, distributing or otherwise using Applications built from the software.". And Antoinne won't reveal which license do they have with them. This may mean that any kind of user earning any kind of direct or indirect money with OsiriX (say an investigator analyzing medical images, a veterinary who maybe doesn't need FDA approved software) is at risk of being sued.

Also, they are plugging foreign and closed source libraries without telling people into OsiriX.

Those days you got to choose on a preference menu, in OsiriX, if you wanted to use Kakadu or either OpenJPEG. That option doesn't exist anymore. That might make you thing Kakadu isn't there anymore, but my command line doesn't agree:

$ strings OsiriX.app/Contents/MacOS/OsiriX | grep -i kakadu
kakaduAvailable

$ strings OsiriX.app/Contents/Resources/Decompress | grep -i kakadu
Kakadu Error:
Kakadu Warning:
This attribute can be used to control the format used to record TLM
[... some dozens of lines redacted ...]
Kakadu-v7.1
[... some dozens of lines redacted ...]
**** Kakadu SDK failed to open this file:signal_EXC_ARITHMETIC
**** Kakadu SDK failed to open this file: C++ exception
Error in Kakadu Stripe Compressor:
Error in Kakadu Stripe Decompressor:

Not to say, also, that apparently now some libraries are only distributed on binary form on the repository, so we (and other people) cannot compile 64 bit versions, and are tied to 32 bit.

So, this is my rant. Does anybody else think that there are some reasons to be suspicious?

Thanks

Disclaimer: This are my own views and opinions and not necessarily supported by my company.

Cheers,

Aaron

[Aaron Boxer]

On Fri, Dec 6, 2013 at 3:13 PM, Alvaro G. [Andor] <an...@pierdelacabeza.com> wrote:

Hi there!

El 06/12/13 16:57, Aaron Boxer escribió:

Thanks, Alvaro.  That helps clarify things for me . So, FDA approval is about having someone to sue if something goes wrong :)  

What I don't understand is this: the app runs on top of an operating system which could be open source,

but doesn't require FDA approval. So, who is liable if an OS bug causes patient safety issue?

That might be a funny and complicated answer left to the lawyers and to be dealt case by case, but I don't think the nature of the OS behind might make much of a difference:

Imagine you're using some medical software under Windows, and you diagnose wrongly a cancer because the color profiling API is behaving in a funny way. I don't think you would have any big case against Microsoft but instead against the medical company which got the FDA certification for that software and didn't have proper ways of checking the integrity of the process. And anyway, they don't care. They have insurances for that.

makes sense. What we really need are FDA approved Radiologists.

 

I'm also curious about Osirix. Can you say more about it not being open source ? Do you mean the closed source plugins?

In certain moment, version 3.9.4 ( http://www.osirix-viewer.com/Roadmap.html ) , they included the Kakadu library for JP2K. As most of you probably know, that's not opensource, and it was included as a linked library, essential to running the software. The installer only showed the LGPL license on running it (and still does) with no mention to the Kakadu library.

I expressed my concerns about this in the mailing list: http://groups.yahoo.com/neo/groups/osirix/conversations/topics/22335 (you may need to be logged in and registered). At a certain point, when asking exactly what kind of distribution license do they have with Kakadu, my questions were moderated out of the mailing list and the debate was silently forbidden.

One of my main concerns, apart from the open source thing, is that most of the licenses for Kakadu say "... will not receive Commercial and/or financial benefit by developing, distributing or otherwise using Applications built from the software.". And Antoinne won't reveal which license do they have with them. This may mean that any kind of user earning any kind of direct or indirect money with OsiriX (say an investigator analyzing medical images, a veterinary who maybe doesn't need FDA approved software) is at risk of being sued.

Also, they are plugging foreign and closed source libraries without telling people into OsiriX.

Those days you got to choose on a preference menu, in OsiriX, if you wanted to use Kakadu or either OpenJPEG. That option doesn't exist anymore. That might make you thing Kakadu isn't there anymore, but my command line doesn't agree:

$ strings OsiriX.app/Contents/MacOS/OsiriX | grep -i kakadu
kakaduAvailable

$ strings OsiriX.app/Contents/Resources/Decompress | grep -i kakadu
Kakadu Error:
Kakadu Warning:
This attribute can be used to control the format used to record TLM
[... some dozens of lines redacted ...]
Kakadu-v7.1
[... some dozens of lines redacted ...]
**** Kakadu SDK failed to open this file:signal_EXC_ARITHMETIC
**** Kakadu SDK failed to open this file: C++ exception
Error in Kakadu Stripe Compressor:
Error in Kakadu Stripe Decompressor:

Not to say, also, that apparently now some libraries are only distributed on binary form on the repository, so we (and other people) cannot compile 64 bit versions, and are tied to 32 bit.

So, this is my rant. Does anybody else think that there are some reasons to be suspicious?

Well, we've seen this before. eFile was originally given away, lots of people started using

it, then they started to charge for it. Also ClearCanvas has closed most of their source.

The problem here seems to be deception.  

To my mind, FLOSS means both freely available source code, and an active developer community that works on and supports it.  I can't think of any medical open source projects that qualify; perhaps OpenMRS.

 

Thanks

Disclaimer: This are my own views and opinions and not necessarily supported by my company.

Cheers,

Aaron

[simonmd]

Wow. Thanks andor & Aaron for the context. OsiriX is fantastic software but when you start becoming more than the casual user and play with the code, you do begin to wonder about certain things. 

I fully believe Antoine should be able to derive some profit from his work. But the exact mechanism for doing so should be transparent and fully license compliant.

More on the original topic, I believe a truly, certifiably, honest-to-god FLOSS viewer with a wide community is a worthwhile purpose in itself, with or without FDA approval (much of the world is bound by other certificate authorities). Best practices and best evidence should be the guide. 

If the viewer was crafted in such a way that the only concern for certification was protection against code tampering, that is something that could be secured by whoever decides to pay for FDA or CE approval of their version.

[Aaron Boxer]

On Sun, Dec 8, 2013 at 10:29 AM, simonmd <sim...@gmail.com> wrote:

Wow. Thanks andor & Aaron for the context. OsiriX is fantastic software but when you start becoming more than the casual user and play with the code, you do begin to wonder about certain things. 

I fully believe Antoine should be able to derive some profit from his work. But the exact mechanism for doing so should be transparent and fully license compliant.

Yes.   

More on the original topic, I believe a truly, certifiably, honest-to-god FLOSS viewer with a wide community is a worthwhile purpose in itself, with or without FDA approval (much of the world is bound by other certificate authorities). Best practices and best evidence should be the guide. 

I agree.  Community is the key for me. But how can we build it?       

If the viewer was crafted in such a way that the only concern for certification was protection against code tampering, that is something that could be secured by whoever decides to pay for FDA or CE approval of their version.

Yes.  Good idea. 

I believe the problem in all of this is that:

"Love of money is the root of all evil"

[fleetwoodfc]

Unfortunately, if you are busy writing code, then you don't have time to grow your own food or go hunting so at that point loving some money is not so evil. :)

[Aaron Boxer]

On Tue, Dec 10, 2013 at 4:20 PM, fleetwoodfc <dda...@eesimed.com> wrote:

Unfortunately, if you are busy writing code, then you don't have time to grow your own food or go hunting so at that point loving some money is not so evil. :)

You're right. I guess I'm talking about greed.  

[Suresh Viswanathan]

I know I’m digging up a slightly old thread but I would like to invite those of you interested in an FLOSS viewer to have a look at Mayam 2.0. It’s from the same team who brought you Oviaym. With the 2.x release we’ve rewritten the code and have moved to the dcm4che 2.x tool kit and are also unifying the look and feel between both projects (work in progress)

Though our primary focus is Linux, it’s cross platform works quite well on Windows, Mac and Solaris. It is still work in progress, what it lacks is sufficient users to find bugs and give us feature requests. There are a lot of features on the drawing board like 3D (Beta), streaming, advanced navigation, etc. We would like to make it better with the community’s support.

It’s licensed under an MPL 1.1/GPL 2.0/LGPL 2.1 triple license and there are no plans to change the status anytime in the future. 

I would like to hear your thoughts.

Suresh

[Aaron Boxer]

Hi Suresh,

Thanks for all of your team's hard work. My feeling is that a good web based viewer will be what most people need for a DICOM viewer.

I would focus on Oviyam2: make it stable; make it an amazing viewer that is easy to use, and fast.  Focus on the standard 2D workflow.

Allow it to pull reports from a RIS. Once it is working like a charm, extend it with a plugin architecture to create a viewer ecosystem. And look into server side MPR/3D rendering. And streaming over web-sockets. And LDAP. And QUIDO..... 

My 2 cents.

Kind Regards,

Aaron

  

[Suresh Viswanathan]

Hi Aaron,

Thanks for your comments. While we would not be diluting our focus on Oviyam commercial considerations require us to have a good Linux viewer hence Mayam. Our business model does not depend on making money from the client software and since we’ve benefited greatly from the dmc4che project we’ve kept them both open source. 

The next version of Oviyam will be faster and have a new, unified look & feel. We’re removing little used features like off line support to make it more stable. MPR/3D support using WebGL is already available as a Beta feature. QUIDO has me really excited and will be supported once dcm4chee has support. LDAP is already available if you know hoe to configure it. Since we use dcm4chee’s own security back end which in turn is based on JAAS which can be linked to LDAP.

Since both our interests are aligned in wanting a good DICOM viewer for Linux I thought you should have a look at Mayam. We have the resources to develop it if the community can help us improve and fine-tune it.

Regards,

Suresh

[Aaron Boxer]

Thanks, Suresh. I will have a look. By the way, I am mirroring the source on github now:

https://github.com/boxerab/mayam

IMHO, one very powerful move you could make to encourage community involvement would be to move away from sourceforge

and put your projects on github. The fork/pull request workflow is really wonderful.

Cheers,

Aaron

[Suresh Viswanathan]

We will probably make the transition soon. Like I said, it’s work in progress but please do give your feedback.

Suresh

[Aaron Boxer]

On Tue, Feb 4, 2014 at 3:19 PM, Suresh Viswanathan <suresh...@gmail.com> wrote:

We will probably make the transition soon. Like I said, it’s work in progress but please do give your feedback.

Glad to hear. I took a quick look; does the viewer support jpeg 2000? It wasn't able to open some studies that were

jpeg2000 compressed.  I think the user experience could be improved. Have you studied Osirix? I would say it is the

finest open source viewer around, better than Clear Canvas.  Why not try to use a similar user interface and workflow.

Good artists copy, great artists steal - Picasso.

Add a similar plugin interface. Osirix packs many many features in, and yet it doesn't feel crowded or overwhelming; there is a nice

prioritizing of commonly used features vs. less frequently used. It uses large, easy to use icons, and menus and toolbars.  

Another thing I like is that everything stays in a single window, so it is easy to reach the UI controls while viewing an image.

 

I think if you forget about 3D rendering and just capture the Osirix 2D workflow, you would have a very popular and useful viewer that users would flock to.

my 2 cents

Aaron

[Suresh Viswanathan]

Thanks for your feedback. 

Since we’re using the dcm4che toolkit and Java it should support JPEG 2000 if JAI is supported on whatever platform it running on. I will double check if there’s an bug preventing this.

I’ve been using OsiriX since the initial 0.2 release a long long time ago. and am a big fan of it. If you have time to look at our initial release of Mayam (0.9) it was modelled on the OsiriX interface. However OsiriX takes advantage of the underlying Mac platform to be responsive.  The UI is also a function of the Mac's document centric interface. Trying to replicate that resulted in several compromises. Also I’ve always felt that viewers should have a dark theme to suit working in low light situations. The 2.0 Oviyam and Mayam releases were a complete rethink to see how best we could optimise workflow with a shared interface across the web and desktop. We’re still not there yet. Now that the basic code is in place the 2.1 release focuses on speed and UI /UX improvements.

Plugin’s will come in a future release. 3D rendering will, probably, also be an option plugin.

Keep it coming,

Suresh.

[Aaron Boxer]

Hi Suresh,

Since we’re using the dcm4che toolkit and Java it should support JPEG 2000 if JAI is supported on whatever platform it running on. I will double check if there’s an bug preventing this.

Ahhhh, that must be because I was running on windows 7 64.  Actually, most windows pcs these days are 64 bit, so you will have to find

another solution to support this platform. You can try my OpenJPEG JAI wrapper, if you like.

 

I’ve been using OsiriX since the initial 0.2 release a long long time ago. and am a big fan of it. If you have time to look at our initial release of Mayam (0.9) it was modelled on the OsiriX interface. However OsiriX takes advantage of the underlying Mac platform to be responsive.  The UI is also a function of the Mac's document centric interface. Trying to replicate that resulted in several compromises. Also I’ve always felt that viewers should have a dark theme to suit working in low light situations.

Good to know. I agree about the dark theme. One change you might consider is: rather than having a separate tab per PACS server, you have a single tab with multiple PACS servers, and you can query all of them. This is useful in a large hospital environment, where there may be a main PACS for new studies and an older PACS for prior studies. With a single tab, you can query both. And you would want to indicate

somehow what are the prior studies when the user opens a study.  This feature is present in Clear Canvas.

 

The 2.0 Oviyam and Mayam releases were a complete rethink to see how best we could optimise workflow with a shared interface across the web and desktop. We’re still not there yet. Now that the basic code is in place the 2.1 release focuses on speed and UI /UX improvements.

Plugin’s will come in a future release. 3D rendering will, probably, also be an option plugin.

Looking forward to seeing these changes.

Regards,

Aaron

[Wa]

Some things that would be nice with Mayam is the ability to add an extra icon in the image view window that can launch a program that you specify such as dictation software. Also in the image window can we make better use of the screen real estate in that the thumbnail navigation pane takes up too much room and it can not be adjusted. Ideally it would be prefered it be out of the way and navigate through the series using scrolling or arrow keys or the thumbnail be at the bottom of the page. When you are in portrait mode on the monitor the vertical thumbnails take too much room.

Also will the next release support a three monitor setup with one monitor containing the patient list while viewing images on two other monitors and support hanging protocols that use multiple monitors. Also if possible add support for a dicom SR that you can store back to pacs server.

While WADO speeds up the retrieval of images can the image viewer open immediatetly there are enough studies to fill the lay e.g in 1X1 layout open the image viewer as soon image 1 is lretrieved and have the images continue to load in the background. This will give a perception of faster image loading instead of waiting for all the images to be retrieved then launch the image viewer.

[Aaron Boxer]

On Sun, Feb 9, 2014 at 2:03 PM, Wa <mbugua...@gmail.com> wrote:

Some things that would be nice with Mayam is the ability to add an extra icon in the image view window that can launch a program that you specify such as dictation software. Also in the image window can we make better use of the screen real estate in that the thumbnail navigation pane takes up too much room and it can not be adjusted. Ideally it would be prefered it be out of the way and navigate through the series using scrolling or arrow keys or the thumbnail be at the bottom of the page. When you are in portrait mode on the monitor the vertical thumbnails take too much room.

Yes, I agree, screen real estate is precious. Also, thumbnails use network bandwidth and can slow down display of results (at least I saw this in Oviyam 2). They should be turned off by default, 

Also will the next release support a three monitor setup with one monitor containing the patient list while viewing images on two other monitors and support hanging protocols that use multiple monitors. Also if possible add support for a dicom SR that you can store back to pacs server.

I seem to recall that java multiple monitor support is buggy.

Also SR is a big topic which would probably require a lot of work, although you could probably borrow from David Clunie's PixelMed viewer, which has excellent SR support.

 

While WADO speeds up the retrieval of images can the image viewer open immediatetly there are enough studies to fill the lay e.g in 1X1 layout open the image viewer as soon image 1 is lretrieved and have the images continue to load in the background. This will give a perception of faster image loading instead of waiting for all the images to be retrieved then launch the image viewer.

I think you mean image streaming here, something present in Clear Canvas workstation. Except, with WADO, there is no extra server support needed, as long as it already uses WADO. I've used the Apache HTTP asynchronous client, and I'm sure you could

max out your network card with asynchronous calls and make streaming work very nicely. In fact, with WADO-RS, you could probably do

bulk data streaming and store the result at the end, and not need to do a C-MOVE. And you could stream the prior studies in the background. 

Aaron 

[Suresh Viswanathan]

Lots of good ideas bouncing around. I’ll add my 2¢ and reply to Aaron and Wa. Btw, please add feature requests / suggestions to the Mayam JIRA on dcm4che.org. 

On 10-Feb-2014, at 3:51 am, Aaron Boxer <box...@gmail.com> wrote:

On Sun, Feb 9, 2014 at 2:03 PM, Wa <mbugua...@gmail.com> wrote:

Some things that would be nice with Mayam is the ability to add an extra icon in the image view window that can launch a program that you specify such as dictation software. Also in the image window can we make better use of the screen real estate in that the thumbnail navigation pane takes up too much room and it can not be adjusted. Ideally it would be prefered it be out of the way and navigate through the series using scrolling or arrow keys or the thumbnail be at the bottom of the page. When you are in portrait mode on the monitor the vertical thumbnails take too much room.

Yes, I agree, screen real estate is precious. Also, thumbnails use network bandwidth and can slow down display of results (at least I saw this in Oviyam 2). They should be turned off by default, 

An extra icon that can be configured to launch an external program is a good idea and I’ll add it to the todo list.

You can collapse the side bar in the current version of Mayam (and Oviyam) if necessary. Having said that, one of the Ux improvements planned for the next release is an auto collapse option for the side bar to take up minimal space. We’re also adding the option for the sidebar to be displayed on the right too (for better RTL language support). I never thought about portrait arrangement and will see if this can be extended to a bottom positioning too. You can navigate through the series using the keyboard but the side bar is needed for switching series. If you have any further suggestions or screenshots of how other viewers (Other than OsiriX or ClearCanvas) handle this I’d appreciate it if you could share them.

Regarding speed, we use WADO generated JPEG 75 x 75 pixel images for the thumbnails (when the PACS supports WADO) so there shouldn’t be an issue with speed. When it comes to Oviyam, we load the entire series as JPEG images and show them as thumbnails in the sidebar. Although this might slow down the initial loading, it allows us to cache the images in the browser and display them instantaneously when clicked on (except on Chrome which seems to have a bug that prevents this).

Also will the next release support a three monitor setup with one monitor containing the patient list while viewing images on two other monitors and support hanging protocols that use multiple monitors. Also if possible add support for a dicom SR that you can store back to pacs server.

I seem to recall that java multiple monitor support is buggy.

Also SR is a big topic which would probably require a lot of work, although you could probably borrow from David Clunie's PixelMed viewer, which has excellent SR support.

We’re investigating into providing multi-monitor support in future releases. One of the challenges with Java is finding ways to bypass restrictions a native client wouldn’t face. SR is one of those things that would be nice to have but in reality requires a lot of work. With all the other features to be added, it’s not an immediate priority 

 

While WADO speeds up the retrieval of images can the image viewer open immediatetly there are enough studies to fill the lay e.g in 1X1 layout open the image viewer as soon image 1 is lretrieved and have the images continue to load in the background. This will give a perception of faster image loading instead of waiting for all the images to be retrieved then launch the image viewer.

I think you mean image streaming here, something present in Clear Canvas workstation. Except, with WADO, there is no extra server support needed, as long as it already uses WADO. I've used the Apache HTTP asynchronous client, and I'm sure you could

max out your network card with asynchronous calls and make streaming work very nicely. In fact, with WADO-RS, you could probably do

bulk data streaming and store the result at the end, and not need to do a C-MOVE. And you could stream the prior studies in the background. 

Displaying the first image in the main window while the other thumbnails are loaded is a good idea and is something we can do. Streaming would require extra work on the server and would be a proprietary solution. Apache HTTP asynchronous client seems like an interesting idea, it’s something I haven’t considered till now but will look into. When the time comes I probably would recruit your help if I hit any roadblocks. 

Regards,

Suresh.