| Gliffy | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Background
We need a way for concepts to be classified into different types of orderables (e.g., some will be drugs, some will be tests, etc.). We realize that it's unlikely that one classification scheme will satisfy everyone's needs. In addition, we'd like a design that supports the notion of someone being able to come along and add new types of orders through a module. The most straightforward approach would be to use concept classes (similar to how we have already been doing) to classify concepts (via their Concept Class) into the appropriate order type – i.e., drug for drug orders, test for test orders, etc. The downside of this approach is that it requires that we align all implementations one a single classification scheme and does not allow for further granularity of classes (e.g., splitting tests into lab tests, radiology tests, procedures, etc.). So, we're looking for a design with the following requirements.
...
Basically, we create a mapping of concept classes to order types within the order service. Within the application, this would appear as a screen amongst the order administration screens like "Concept Class Mappings." Using this table, you map any existing concept classes that represent orderables to the appropriate order type. The types of orders are supplied by the system – e.g., starting with DRUG and TEST, but allowing a module to register a FOOBAR order type if it wanted. So, we have table like this:
| Gliffy |
|---|
...
|
- order_type_class_map_id – autonumber primary key
- concept_class_id – a reference to a concept class
- order_type – a reference to a Java class of type
? extends Order
...