I understand that this is an effort primarily lead by a team working with Bahmni and that the primary concern is therefore to end up with an adequate solution for Bahmni. Of which will be keen to benefit.
However as I attempted to say over the last PAT call, let’s not close the door to having this being used with OpenMRS in general. Let’s hear from the senior devs and OpenMRS architects what they have to say about the database ‘flattening’ that will be undertaken here. It will cost an hour of developers forum to hear their thoughts about it.
Let me give you one real world experience that we don’t want to endure twice as implementers. We have one non-Bahmni implementation that aims at transitioning to Bahmni… when the appropriate resources will be available to do so, if ever. In the meantime they would like to use appointment scheduling, which is available outside of Bahmni. However we are reluctant to enable this feature as it would not be compatible if/when they transition to Bahmni, leading to a data migration headache bigger than what it already is. This is a “low-resource deadlock” that arises, because when it came down to it, the developers behind the appointment scheduling feature of Bahmni did not really consider recycling/expanding the existing appointment scheduling module.
I want at least to raise the alarm when it comes to important and impactful features, people involved on this thread will converge to whatever decision they deem fit.