The proposed solution would include two different packages for each data source (caGrid DICOM and NBIA) but one configurable GUI. If query criteria are the same for caGrid and NBIA, host would have the same GUI for caGrid and NBIA. User would select the target data source from the drop down list.
Current implementation combines both sources DICOM Emory and NBIA into one XIP Host data source. Both share the same GUI but query and retrieve implementations internally are based on different clients.
Maintaining two different caGrid implementation under the same XIP Host data source proves to be a difficult task. Many conditions are created internally in the code to satisfy various query/retrieve scenarios. Separating these two data sources would lead to cleaner and more data source centered implementation. The question is how to reuse caGrid libraries and enhance them by Emory or NBIA specific libraries to minimize size of the modules?
Additional important consideration is caGrid Emory and NBIA compatibility with the TargetIteratorRunner. This construct depends on the Item level query, which Emory data source likely supports. I am told NBIA implementation has provisions for it but may never being turned on to allow for Item level queries. Series level queries were used to this point.
If NBIA does not allow for Item level query no TargetInetatorRunner will be applied. Hence two sources caGrid Emory and NBIA will be very different in they XIP Host implementation.