...
- As we go along, we may want to pull Orthanc into its own server, as the disk usage would be huge. We will also need a backup server.
- Currently we map order type - modality. This works fine for us in current setups where there is one modality. When we find implementations that have more than one modality, we will learn more about the setup, and perhaps modify the order type - modality solution. Some scenarios,
- Radiology orders (order type) fulfilled by multiple modalities. Do we map each leaf test (chest 1 view xray instead of Radiology) to a modality?
- We support devices that support HL7 order message and can auto forward DICOM images to a DICOM server.
- We may want to pull Orthanc into its own server, as the disk usage would be huge. We will also need a backup server.
TODO
- One issue with Orthanc is for Cent OS < 7.0, the only way we have it working is having to build Orthanc for that environment. This is not a feasible option for production server at an implementation, we do not want dev tools to be installed in production boxes. To get away from this problem, we are exploring options like dcm4chee.
- Can we search for an image by a custom dicom field like Bahmni Order Id (which a user cannot change from the carestream ui)
- document on wiki to configure Carestream device
- how do I do procedure code mapping
- how do I add a new HL7 client
...