4 ms·

A curated list of open source healthcare software, tools and resources

74 points by okokok___ 6y ago

ksaj 6y ago
This is great. Back when I had a tympanomastoidectomy (how's that for a medical mouthful?) they gave me the images of the before/after CT scans on CD. I used OsiriX to view them and it totally blew my mind. While the "lite" (free) version wasn't exactly like the medical-grade imagery, it was close enough to make me very familiar with every nook and cranium. (sorry for the pun, the CT scans were of my skull!) When you look at the images individually, it makes it more obvious and simultaneously more fascinating how the software maps everything into a 3D image. It's actually not that complicated as long as each layer of the scan is consistent. Basically they are a greyscale version of http://thescienceexplorer.com/brain-and-body/dead-body-sliced-5000-times-create-virtual-human http://thescienceexplorer.com/brain-and-body/dead-body-slice... that the software interprets and colours. I assume DICON viewers could easily interpret the sliced dead-body images because of that. I'm very happy to see that DICOM viewers have since appeared in open source. I look forward to re-imaging my scans to see what shows up. More on topic -- I always wanted to write a DICOM-diff to make before/after comparisons, which can also be useful in seeing progressions over time, but don't have the knowledge for the graphical interpretation of each pixel on a 3D plane. But with an open-source solution, that part is already done and I just have to think about a plugin or new menu item for alignment and highlighting in an already-existing package.
- brnt 6y ago
  Should anyone ever encounter a medical image of type xdr, I've written a small library that reads them [1], also a simple viewer [2]. I've since changed careers, but please use it if you wish. Medimage also reads dicom imagery, and represents the data internally as a numpy array, which might help you write that diff tool. 1. github.com/brenthuisman/medimage 2. github.com/brenthuisman/dosia
  - okokok___ 6y ago
    awesome! I think these might be good candidates for Console! :)
  - ksaj 6y ago
    Make sure OP is aware of this. These look like they belong on the Awesome list.
- ska 6y ago
  There have been good open source projects in this area for ages now. DICOM itself is baroque but at least some of the complexity can be managed by easily available libraries. If you want to play with this stuff 3DSlicer (see the fine article) is a good starting place - access to a lot of ITK filters etc. without direct programming. For example, you can fairly easily do your "diff" idea there (usually called a subtraction image) directly. It turns out this is not as useful as you might first think, although CT images are much less problematic than, say MRI. Still it's mostly used for contrast pairs (i.e. images taken in the same session, one baseline and one with a contrast agent). With much time between scans you often need to do more work.
  - ksaj 6y ago
    Thanks. I see your point when it comes to soft tissues - organs and whatnot won't always be in the same place when scanned a second time down the road. I was thinking specifically about my case, which is all bone. It should work for that, but you're right about the rest. So my idea is probably of limited interest.
    - ska 6y ago
      Yes that should work ok for your case - as noted it’s a pretty standard approach but just had limited application, at least without significant preprocessing.
- neandrake 6y ago
  I can't speak to the clinical aspect of medical imaging but I've done some development with medical images. If you end up pursuing your diff concept here are a few things which might help point you in the right area or give you some additional keywords when searching: 1. CT images measure densities of tissue (in Hounsfield units). 2. The images will first need to be aligned/registered/fused. There are different ways to do this but it can be difficult if the two scans were done with different protocols/hardware as the image resolutions and dimensions can differ but also anatomy regularly changes (not as much in the head area). 3. Fusions are often described as having a primary (unchanged) and a secondary (the image that's modified to align to the primary). 4. Fusions can be very basic rigid alignments (like moving one photo on top of another) or be fancy by moving voxels independently (often called deformable registration, like cutting a photo into squares and moving them) however these are difficult to evaluate for correctness. 5. Fusions are often viewed as a transparency overlay of one image on top of another (in the case of deformable it's the deformed image over top the primary). 6. After doing a fusion a subtraction can be performed to find the difference in image values (the densities). Best of luck and enjoy the field.
  - ska 6y ago
    Adding a couple of hopefully helpful comments here. 1. There is a lot of terminological abuse in this area, but fusion is properly a display (or production of new images) technique, (co-) registration is the mapping of one image to another. 2. You almost certainly do not want deformative or even affine transforms in the registration of same patient bony anatomy in CT (because it is stereo-tactically accurate). You want a rigid transform here. Also because of CT you can rely on the units are meaningful so you don't need to normalize. 3. Because you are doing rigid transform only , you should not resample the moving image here (could be both images move, more often as you describe). Most package will get this wrong. Save the resampling for the end and do it once. 4. You will have to resample one or both images, as their underlying lattices will not be aligned. There is a bit of subtlety here, but in the OPs case probably best to sample both to a similar isotropic grid (e.g. 1mmx1mmx1mm) and subtract. 5. You can do the resampling explicitly or implicitly (i.e. as part of computing the subtraction) but either way use a proper smoothing filter not tri-linear interpolation. 6. Oh, a note - your original images are probably 12 bit encoded in 16 bit ints, make sure your loader isn't truncating or rescaling to 8 bit.
okokok___ 6y ago
This will be in the next Console email, which you can subscribe to if you'd like to keep up to date on new open source projects :) https://console.substack.com/ https://console.substack.com/ I also put an interview with one of the developers in each email.

74 points by okokok___ 6y ago

ksaj 6y ago

This is great. Back when I had a tympanomastoidectomy (how's that for a medical mouthful?) they gave me the images of the before/after CT scans on CD. I used OsiriX to view them and it totally blew my mind. While the "lite" (free) version wasn't exactly like the medical-grade imagery, it was close enough to make me very familiar with every nook and cranium. (sorry for the pun, the CT scans were of my skull!) When you look at the images individually, it makes it more obvious and simultaneously more fascinating how the software maps everything into a 3D image. It's actually not that complicated as long as each layer of the scan is consistent. Basically they are a greyscale version of http://thescienceexplorer.com/brain-and-body/dead-body-sliced-5000-times-create-virtual-human http://thescienceexplorer.com/brain-and-body/dead-body-slice... that the software interprets and colours. I assume DICON viewers could easily interpret the sliced dead-body images because of that. I'm very happy to see that DICOM viewers have since appeared in open source. I look forward to re-imaging my scans to see what shows up. More on topic -- I always wanted to write a DICOM-diff to make before/after comparisons, which can also be useful in seeing progressions over time, but don't have the knowledge for the graphical interpretation of each pixel on a 3D plane. But with an open-source solution, that part is already done and I just have to think about a plugin or new menu item for alignment and highlighting in an already-existing package.

brnt 6y ago
Should anyone ever encounter a medical image of type xdr, I've written a small library that reads them [1], also a simple viewer [2]. I've since changed careers, but please use it if you wish. Medimage also reads dicom imagery, and represents the data internally as a numpy array, which might help you write that diff tool. 1. github.com/brenthuisman/medimage 2. github.com/brenthuisman/dosia
- okokok___ 6y ago
  awesome! I think these might be good candidates for Console! :)
- ksaj 6y ago
  Make sure OP is aware of this. These look like they belong on the Awesome list.
ska 6y ago
There have been good open source projects in this area for ages now. DICOM itself is baroque but at least some of the complexity can be managed by easily available libraries. If you want to play with this stuff 3DSlicer (see the fine article) is a good starting place - access to a lot of ITK filters etc. without direct programming. For example, you can fairly easily do your "diff" idea there (usually called a subtraction image) directly. It turns out this is not as useful as you might first think, although CT images are much less problematic than, say MRI. Still it's mostly used for contrast pairs (i.e. images taken in the same session, one baseline and one with a contrast agent). With much time between scans you often need to do more work.
- ksaj 6y ago
  Thanks. I see your point when it comes to soft tissues - organs and whatnot won't always be in the same place when scanned a second time down the road. I was thinking specifically about my case, which is all bone. It should work for that, but you're right about the rest. So my idea is probably of limited interest.
  - ska 6y ago
    Yes that should work ok for your case - as noted it’s a pretty standard approach but just had limited application, at least without significant preprocessing.
neandrake 6y ago
I can't speak to the clinical aspect of medical imaging but I've done some development with medical images. If you end up pursuing your diff concept here are a few things which might help point you in the right area or give you some additional keywords when searching: 1. CT images measure densities of tissue (in Hounsfield units). 2. The images will first need to be aligned/registered/fused. There are different ways to do this but it can be difficult if the two scans were done with different protocols/hardware as the image resolutions and dimensions can differ but also anatomy regularly changes (not as much in the head area). 3. Fusions are often described as having a primary (unchanged) and a secondary (the image that's modified to align to the primary). 4. Fusions can be very basic rigid alignments (like moving one photo on top of another) or be fancy by moving voxels independently (often called deformable registration, like cutting a photo into squares and moving them) however these are difficult to evaluate for correctness. 5. Fusions are often viewed as a transparency overlay of one image on top of another (in the case of deformable it's the deformed image over top the primary). 6. After doing a fusion a subtraction can be performed to find the difference in image values (the densities). Best of luck and enjoy the field.
- ska 6y ago
  Adding a couple of hopefully helpful comments here. 1. There is a lot of terminological abuse in this area, but fusion is properly a display (or production of new images) technique, (co-) registration is the mapping of one image to another. 2. You almost certainly do not want deformative or even affine transforms in the registration of same patient bony anatomy in CT (because it is stereo-tactically accurate). You want a rigid transform here. Also because of CT you can rely on the units are meaningful so you don't need to normalize. 3. Because you are doing rigid transform only , you should not resample the moving image here (could be both images move, more often as you describe). Most package will get this wrong. Save the resampling for the end and do it once. 4. You will have to resample one or both images, as their underlying lattices will not be aligned. There is a bit of subtlety here, but in the OPs case probably best to sample both to a similar isotropic grid (e.g. 1mmx1mmx1mm) and subtract. 5. You can do the resampling explicitly or implicitly (i.e. as part of computing the subtraction) but either way use a proper smoothing filter not tri-linear interpolation. 6. Oh, a note - your original images are probably 12 bit encoded in 16 bit ints, make sure your loader isn't truncating or rescaling to 8 bit.

okokok___ 6y ago

This will be in the next Console email, which you can subscribe to if you'd like to keep up to date on new open source projects :) https://console.substack.com/ https://console.substack.com/ I also put an interview with one of the developers in each email.