Before proceeding with the development, I would greatly appreciate your insights and guidance on the following schools of thought to ensure a solid foundation for future implementations:
Refactoring the legacy O2 drawing module into OpenMRS 3.x:
Is it advisable to refactor the existing O2 drawing module to align it with OpenMRS 3.x?
What considerations should be taken into account when refactoring and migrating the module?
Standalone module for use by hospitals, clinics, etc.:
Should I develop a fresh standalone module that can be utilized by various healthcare organizations?
What are the technical implications and benefits of creating a standalone module instead of integrating it with the OpenMRS platform?
If it is determined that a platform module is more suitable, should I create a completely new module?
How can the transition from the legacy module to the new one be managed effectively?
Working with the data model to add new functionality:
What are the recommended approaches for incorporating new functionality, such as annotation features and wound regionalization, into the data model?
Are there any best practices or considerations for extending the existing data model?
Considering the critical nature of this feature and its potential impact on numerous organizations, I aim to establish a foundation that is technically solid and enables future scalability. Therefore, any insights, recommendations, and expertise you can provide would be immensely valuable.
NOTE: proposed solution aligns seamlessly with the OpenMRS 3.x architecture, APIs, and data model.
03 micro-front end modules are completely different from the OpenMRS Java modules
By Refactoring, did you mean adding any necessary Rest API to the existing legacy 02 java module and removing out any existing 02 UI stuff ??
Iam not sure about the specific workflows for this feature but we already have the backend java attachments module and a miro frontend attachments app to handle images , we could probably incorporate an annotation library into it.
That is In addition to @mksd idea of embedding it in the o3 form
So that means even for having multiple forms especially admission forms like wound score or cervical cancer forms, etc can be configured to have a variety dynamically created and stored other than hard coding them?