I have started to put together a list of projects on this page that you might like to get stuck into... the list is far from complete, and in no particular order. Let me know what you think via twitter or the Google group (links above) or via Bitbucket.
OpenREM currently relies on having a third party DICOM store service class provider in order to receive DICOM objects from modalities. This project is to incorporate the service into OpenREM, probably by using using pynetdicom.
The second phase would be to incorporate query of a PACS or any other store of DICOM dose related objects to retrieve the objects to import into OpenREM. This should be able to work automatically as well as allowing ad-hoc queries via a web interface. Logging should also be available through the web interface.
This project is pretty much stand alone in the first instance, so start by familiarising yourself with the pynetdicom code to establish how to setup a Store SCP.
OpenREM currently uses the Django-filter application to filter the exams in the interface, and then the same arguments are used to filter the exams for export.
This is quite limited at the moment, as only fields that I have chosen can be filtered on, and only in the way that I have decided, ie generally 'contains'. It would be great if one could filter on more arbitary fields, and use AND, NOT, OR etc.
Fork the latest version of develop on bitbucket and then research alternative ways of adding filters, remembering that what ever happens in the interface has to also work for the export code.
The current filters are defined in remapp/interface/mod_filters.py which are then imported to the view (in views.py) and used to create the queryset. This is then passed to the template to be found in remapp/templates/remapp/ctfiltered.html (using the CT template as an example). The code in remapp/exports/ uses the same mod_filters.py definitions to filter the database again before writing the export files.
Radiation dose structured reports (RDSR) from fluoroscopy contain a wealth of information about the exam, right down to the parameters for each time the exposure pedal is pressed. One of these values is the dose in air at a reference point, and it is this dose – or the associated DAP – that is normally accumulated and used as a marker for likelihood of skin erythema.
However, this dose might be deposited all at one position on the patient, or it might be spread over two positions or over a large area. This can make a massive difference to the skin dose in any one location. The challenge is to be able to quantify this using the information available information about the position of the C-arm and the position of the table, then to display this in a useful visual way.
Take a look at the information that is available in an RDSR from a fluoroscopy system to work out what is possible. For example, is there only enough information for plotting the doses on a sphere, or does the table position add more information. There are some things that are in some manufacturers RDSR that aren't in the DICOM standard (at least last time I checked!), for example the magnification / field size. This information is retained by OpenREM when captured from a Siemens comment field.
The second element is establishing how to visualise the dose distribution. There are a number of ways to do this, but you'll need to work out which way is best and which you can tackle! For example, a simple version would be to plot a 2D dose distribution on a canvas element; an advanced version would be to create a 3D object that can be manipulated by the user, depicting the table, the dose reference plane, and potentially a nominal human shape or maybe a cylinder.
The current version of the DICOM CT Radiation Dose Structured Reports templates do not store any mA modulation information. This is really useful data to have when establishing the behaviour of your CT scanners, so it would be great to store it in OpenREM. Future versions of the structured report templates are expected to incorporate this sort of information.
Fork the latest version of develop on bitbucket. The first thing to do is probably to modify the models.py file to work out how and where to store the data in the database. The next thing to do would be to create an extraction routine that somehow makes a connection between the CT series in question and the series described in the RDSR.
Visualising modulating mA information over an image of the anatomy at that point can be very useful for assessing how a scanner/protocol is performing and for optimisation. This task would be to store in an appropriate fashion the scan projection radiograph images (ie the Scout, or Topogram), and then to display them with the mA or CTDIvol overlay that will become available if issue 121 is completed.
Work out how to store the images. They could be stored in the database, but should probably be stored on disk with a link to the file in the database. The original DICOM images will have patient data in, whcich we don't want to store, along with image location and size information that we do. It might be an idea to save the pixel data as a compressed format - JPEG for example, and save the pixel size and location data in the database. It might also be useful to downsize the images and adjust the pixel size information accordingly.
Fork the latest version of develop on bitbucket and develop a new extractor routine. The database schema will need extending to reference the new images
It should be possible to filter a dataset, then plot any available metric against any other in that dataset. Ideally this should be dynamic and interactive, to change scales, filtering options, adding extra variables etc. It should also be possible to see which exams individual markers on the plot refer to, and be able to link
Work out how to store the images. They could be stored in the database, but should probably be stored on disk with a link to the file in the database. The original DICOM images will have patient data in, whcich we don't want to store, along with image location and size information that we do. It might be an idea to save the pixel data as a compressed format - JPEG for example, and save the pixel size and location data in the database. It might also be useful to downsize the images and adjust the pixel size information accordingly.
Fork the latest version of develop on bitbucket and develop a new extractor routine. The database schema will need extending to reference the new images
The website needs a dynamic twitter feed, certainly to contain any tweets from @_OpenREM, maybe to contain tweets containing either #OpenREM or @_OpenREM.
Find an elegant way to incorporate this into the homepage, probably using javascript. Alternatives would be php or perl (it's hosted on a cPanel controlled server, no root access). Fork the repository, add the new code, send me a pull request :-)
The page will need some rearrangement to make this work, ideas welcome. It might be the we can drop the 'what OpenREM is not' section, particularly if we can get the DICOM Store SCP and QR SCU working.
OpenREM needs your ideas and priorities. If what you want to see isn't here, or you want to let the developers know that you think a particular feature is important to you, then get in touch.
If the feature that you want to see isn't listed here, then check to see if it is listed on the issues list at Bitbucket. If it isn't there either, log in (you can use an existing username from another site if you wish), and add the issue. Alternatively you can use the Google group, link at the top of the page.
If you want to let the developers know that a particular feature is important to you, go to the Bitbucket issues list and use the vote function on the issue you are keen on.
OpenREM currently has dose information extractors and web interface views and exports for CT, fluoroscopy and mammography. Radiography, in particular Digital Radiography, or DX needs to be added to this.
Fork the latest version of develop on bitbucket, copy the code in the remapp/extractors/mam.py as a basis. The fields you need should all be in the database - reference rdsr.py in the same directory for pointers, or look at models.py in the remapp folder.
Task has been tackled by David Platten and the merged fork has become OpenREM 0.5.0.
In linux, the shell takes care of wildcard expansion, so using the command openrem_rdsr.py *.dcm will pass a list of dcm files to openrem_rdsr.py.
In Windows, the default shell does not do this, instead it passes the literal '*.dcm' that then can't be found. This project would be to add the required code to the OpenREM import scripts to make using wildcards work on either platform.
The solution lies in the python glob module, for example see this Stack Overflow question. Fork the latest version of develop on bitbucket, make the necessary changes, test them on Windows and linux if possible, and send me a pull request.
Task has been tackled and included in OpenREM 0.5.0.
Radiation dose structured reports (RDSR) from fluoroscopy contain a wealth of information about the exam, right down to the parameters for each time the exposure pedal is pressed. For some studies, there might be a few hundred exposures. In contrast, the current export function in OpenREM for fluoroscopy studies is at a very high level, listing just the summary information for each study.
The challenge is to work out how this information can be usefully rendered in a spreadsheet (single csv or multi-sheet xlsx) in such a way that lends itself to useful analysis for population dose surveys. It might be that unlike the other modalities, a separate export might be required for the use of individual dose estimates that contains more detail than is possible to usefully contain in a multi-study export.
Take a look at the information that is available in an RDSR from a fluoroscopy system to work out what is possible. You can get an idea by looking at the individual fluoro exam page in the OpenREM interface, but even that is just a summary.
Once you have some ideas about how it might be done, fork the latest version of develop on bitbucket, copy the code in the remapp/exports/xlsx.py as a basis for your code, assuming you have gone with an xlsx solution. You will also want to consult the existing exportFL2excel function in remapp/exports/exportcsv.py. Other files that will need editing to get your new code executable from the interface are:
Task has been tackled and included in OpenREM 0.5.0.
