Hi, in “order_type_class_map” we have a unique constraint on “concept_class_id”.
The intention of this table, I am assuming is to keep a mapping between what sorts of orders are applicable over what “class” of concept. What if multiple types of orders can be applied over the same “class/type” of ‘orderable’ concept. This again probably leads us to the multiple-class-for-concept conversation.
For our specific needs, this is the scenario that we have.
- In our systems, many order-able concepts have same class. example: “Plain Radiography of Chest”, “Cataract surgey” have been classified as ‘procedure’ (icd10 pcs).
- Hospitals however want to organize the investigations into 2 different types of orders - Radiography as “radiology” order and “cataract surgery” as “surgical”.
- The constraint on “order_type_class_map” concept_class_id (unique) however restricts us to map the “procedure” concept class to both “radiology” and “surgical”.
thoughts? any reason for such constraint?
Looking at the github commit where this was added the commit message gives no insight into why this was added:
Generally, I think the idea is that you should have more granular concept classes (e.g. different classes for Radiology Procedure vs Surgical Procedure). And I guess the thought is that multiple concept classes might map to a single Order Type, but not the other way round. Also, I think @burke has a long-term vision of making concept classes hierarchical.
There’s also code in OrderService.saveOrder that will infer the order type based on order.concept.class, which only works if a concept class can point to just a single order type. (I personally think that’s a low-value feature.)
A primary purpose of the order type is to define the behavior for an orderable – i.e., which form should be used, where should the order be routed, etc. The API needs to unambiguously determine the type from the orderable. For example, when someone orders “Plain Radiography of Chest,” the API needs to know this is a radiology order type. During the design, we assumed that concept classes would be more discriminating (that radiology tests and surgeries wouldn’t be in the same class). If “procedure” could be mapped to both “radiology” & “surgical” order types, then the API wouldn’t know which to choose for the “Plain Radiography of Chest” orderable.
There are a couple ways of addressing this…
Multiple Concept Classes
My preference would be to improve the usability of concept classes by allowing concepts to have more than one class:
Given TRUNK-4540, you would be able to classify “Plain Radiography of Chest” as a radiology test and “Cataract Surgery” as a surgery and map these to different order types if you liked. It would also help to work with concept managers (like @akanter) to create a bit more granularity in classes (e.g., distinguishing between surgical procedures, radiology tests, GI procedures, etc. in concept class).
Concept-specific Order Type Mapping
Another option would be to allow for concept-specific mapping of order types and then have the API use the most specific mapping (i.e., concept mapping to order type overrides a class level mapping). I’m not as fond of this approach, since it seems like a maintenance nightmare.
@burke, I like multiple concept classes approach. However, I am wondering if 4540 would take sometime to develop and whether it would have effect on older builds and upgrades. How fast can we move with this?
The standard answer is that if you were to work on this now, and commit it to the master branch of openmrs-core it would be included in OpenMRS Platform 2.1, which would be released in Q1 of 2017.
The optimistic answer is that after Platform 2.0 is released (this quarter, in theory), we want to move to a significantly faster release cadence (still doing LTS releases yearly). This would be much more likely to happen if someone like you added a nice feature like this and pushed to get it released quickly.
I am assuming that code for “multiple-class-for-concept” feature, can be done pretty quickly, which is a pre-requisite for the orderType<=>ConceptClass mapping. I am more worried about consequences/impact on older and even current distributions of OpenMRS. e.g Ref App, Bahmni etc. I can do a quick analysis of needed work and run with you all.