On Tuesday, April 1, 2014 3:01:56 PM UTC-4, Chris Hafey wrote:
> On Tuesday, April 1, 2014 1:18:13 PM UTC-5, Aaron Boxer wrote:
>
> > Folks,
>
> >
>
> >
>
> >
>
> > Inspired by Chris Hafey's recently launched HTML5 viewer and js DICOM parser,
>
> >
>
> > I am wondering out loud if a complete open source DICOM viewer solution is possible using just web tools? And, my feeling is that it *is* possible, given the recent advances in both DICOM and web technologies.
>
>
>
> Woot, I am happy to be inspiring :) I do think it is possible and am going to do what I can to make it a reality.
Cool!
>
>
>
> > So, here is my ideal stack:
>
> >
>
> > 1) cornerstone 2D viewer with all of the usual tools, CINE, etc.
>
>
>
> Yeah :)
>
>
>
> > 2) PACS search page using QIDO
>
>
>
> Possibly, but it might be better to have the client talk to an app server which then calls QIDO due to the following reasons:
>
> 1) Security - It seems unlikely that a QIDO server would have adequate authz/authc control to support the wide varieties of access control scenarios that exist
>
Well, if you have an app server to do queries, then I suppose you would just do good old Q/R, and not need QIDO at all. QIDO allows browsers to query PACS without an intermediary.
Regarding security, I don't know enough about ACL to comment, although you can certainly add basic auth to the search page itself.
> 2) An app server will likely be needed anyway, see below
>
>
>
> > 3) key image creation using STOW
>
>
>
> OK, but the app server should make the STOW call, not the client. Security is one big reason - I know I wouldn't want to give an end user browser the ability to add data to a clinical record without being sure that it is doing the right thing.
>
>
yes, I have to think through the security angle. Does the standard address security, I wonder?
>
> > 3) WADO streaming to local disk using web workers and IndexedDB local storage
>
>
>
> I think there is very low limit on local storage - something like 5MB so it may not be that helpful. WADO works for small images but I am skeptical about it working for large matrix sizes and multiframe.
You can increase the cap, but the user has to accept.
The trick here, and I have done this in other languages, is to stream data directly to disk, without parsing or decompressing, so memory requirements are low - assuming js cleans up memory properly after a stream is closed. If the cap can be made large, (and if the user is kind enough to install an [inexpensive] SSD, then it will work quite nicely. And a spinning disk will work fine too.
>
> > 4) real time decompression of encapsulated pixel data using asm.js and WebCL
>
>
>
> Yes this should be possible buy I would prefer to have the server do it and provide a more uniform interface to the client. In general I believe that servers should make life as simple for clients as possible, requiring the client to decompress every possible DICOM transfer syntax is not in line with this belief. There are some creative things you can do with using PNG as a container transmitting losslessly compressed pixel data....
>
Interesting, I am not familiar with the PNG trick.
>
>
> > 5) MPR using asm.js and WebGL
>
>
>
> I don't think this is something to pursue anytime soon because:
>
> 1) Loading all the slices to the client is time consuming
>
> 2) Requires a ton of memory
>
> 3) Will cause browser instability due to lack of memory management capabilities of the JS VM
>
>
>
> This should really be done on the server which a) should have a high bandwidth pipe to the archive and b) has ample memory. It should also be done in a higher level language than javascript which has deterministic memory management capabilities.
>
>
>
> > 6) Volume Rendering using asm.js, WebCL and WebGL
>
>
>
> Not yet - same reason as above.
>
>
Yes, perhaps advanced 3D features may not work.
So, stepping back, it looks like we need two different types of viewer:
1) basic 2D image review - pure DICOM solution - WADO/QIDO/STOW with basic
authentication on login page. JPEG images are pulled from PACS. Optional WADO streaming for large studies, if local storage tech is sufficiently mature. This should be fairly straightforward, and the nice thing is that this client will be able to connect to any WADO/QIDO enabled PACS. Or a proxy PACS can be used. But the client stays completely within the standard.
2) Power Viewer : add app server for security, advanced ACL, patient reconciliation and feeding RIS reports, and also a native browser plugin (NaCl for Chrome) to handle load: full DICOM image is used, full MPR/VR solution using VTK
#2 just builds on top of #1.
>
> > If enough people pitch in, we could be leaving the dark period of abandonware,
>
> >
>
> > hobbled "open source" and broken promises behind, and entering a golden age.
>
>
>
> Yup, I think its time we make this happen.
Yes!