Closed depryf closed 5 years ago
Here is my early design for this new feature.
A new class Algorithms will be responsible for caching the algorithm instances and for allowing a caller to register algorithms. By default it will register the algorithms supported by the library. It will have methods to get a specific algorithm, or get all algorithms.
A new class Algorithm will represent a single algorithm, it will have methods to define which fields it uses as input/output, description, version, etc...
AlgorithmInput and AlgorithmOutput will represent the input/output of a given algorithm.
I think the fields will be held in map of String/Object where the keys are NAACCR XML IDs and values are input value or computed values. The map will hold patient-level fields, but there will be a special "tumors" key that will be a list of maps. I think this part of the design might need more work, but we will see.
This works has been completed.
This library contains about 10 modules and most of them are "algorithms" (in the sense that they take some fields as input and return computed fields).
For those module, we would like to add the ability for the library to auto-register them so an application can provide standard NAACCR data items and ask the library to compute a given set of algorithms.
The idea is that the calling application won't be aware of the algorithms themselves (it won't call algorithm-specific static methods), instead the calling application will ask the library for all algorithms, then a user would select which one should run, and finally the application would call the library with the list of algorithm to execute. The advantage of this approach is that new algorithms won't require any (coding) work in the calling application.