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?
Platform module:
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.
This will be an AMPATH Forms feature primarily, correct?
How does the following high level flow sound?
1) A diagram is embedded in a form.
Most likely a new custom control will be needed to handle diagrams to be annotated.
2) Users are able to annotate the diagram.
This is where a good UX is required. If no UX research has been made, then we should just find good frontend libs out there that do that well.
For instance React Image Annotate is Google result #1 (for React.) A basic POC would just take the users into that tool upon clicking an ‘annotate’ icon close to the diagram to be annotated?
3) The annotated diagram is submitted by the form.
Submitted… as a complex obs, nothing special.
Here I wouldn’t go, at least at first, into the whole complexity of measuring the coordinates of the annotation(s). I would just assume that what matters is the annotated diagram, visually.
In the end it would all be about putting together a custom control to manage complex obs through the diagram annotation workflow.
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
There is also OHIF viewer a powerful complete image viewing and annotation Library.
it could be run as a standalone service or an embedded React library .
I have done work in the past to integrate it into the Radiology module for Librehealth and added more custom annotation tools
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?
yes that’s what i had in mind initially though comparing the cost, its quite expensive so am looking at now the option you shared and @mksd of using the o3 form for custom control.
So what’s the high level architecture looking like?
I suppose having an openmrs-esm-drawing-app fresh app using openmrs-esm-template and then add it to the openmrs-esm-patient-chart as dependency? Does this make sense or there is a more seamless way?
wow, great resource google #result1 indeed. sure i suppose the UI/UX research did not get due attention, lets utilize the libraries probably we can iterate.
so am looking at now the option you shared and 