Some questions that provoke thinking from my mentor @heshan ;
How should the architecture look like is actually your decision to make. The logical model of the system is something we expect you to come up with. Consider these few options when you’re coming up with a solution.
qtns
- Does the current openmrs backend already have the features that supported the 2.0 version of this?
- Where exactly should this solution fit into the current O3 system.
- How should the implementation look like for the end user and what views, APIs, database structures do we need to facilitate them.
Go through the current O3 system and previous 2.0 drawing module throughly inorder to answer those questions.
Having read a bit of documentation I responded as follows;
qtn1
we already have the backend java attachments module and a miro frontend attachments app to handle images So yes some the features are existent only that there will need abit custom control using the AMPATH forms that will support annotating images (and save the annotated images as complex obs within encounters) for now without going into the whole complexity of measuring the coordinates of the annotation(s) which we can improve later.
qtn2
It should become a module or a component or a micro front end app within the o3 framework, specifically, 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? Just thinking that it can be within the esm-patient-chart app’s package directory just as the esm-attachment-app is Does this make sense or is there a more seamless way?
qtn3
For now; Views:
- ui for selecting predefined body diagrams
- drawing and annotating on the diagram(if there is not much research about ui/ux, can we use a powerful frontend drawing lib like reactannotate or OHIF viewer) ?
- Attaching images, reviewing/editing annotations.
APIs: I suppose we can leverage existing APIs and enhance along the way
Data Structure: I suppose we can consider the complex obs feature for management of the data model unless otherwise Though not familiar with all these nuances apparently. I hope to learn along the way
Looking at the implementation tools at Seeking Clarity and Guidance for Implementing the Unique o3-Draw-on-body-diagram app in OpenMRS 3.x - #10 by thembo42 especially thoughts shared by @mksd and @mozzy
Does this seems a possible solution strategy ?