The Drawing Module latest vesion does not appear there in any publicly published repositories for distributions using the Drawing module from the early 2000s.
Physicians/providers have been using hand drawn sketches to document their physical exam findings and link it to their patient’s medical record. Drawing Module provides physicians the means to upload or draw patients anatomical outlines/pictures and annotate their comments directly on the picture. This module provides a way to draw and annotate on images and save them as complex observation.
O3 On Body Drawing App UI:
While the O2 Drawing module provided quite a number of functionality, the community has moved places for collaboration, sharability(hard to analyze data or send it to another system in 02), lavereging modern intuitive technology to bridge the technical debt and provide efficient health care across the globe easily through MFEs.
The community is still discussing about the scope as it can go out of hand.
we need to look at the pressing needs(objectives) of Clinics and Hospital programs that need this feature.
Objectives
Visual representation of medical conditions: Physician can use the On Body Diagram tool to document their physical exam findings by drawing sketches of the patient’s anatomy and annotating their observations directly on the picture.
FYI: a single image speaks a million words(Obs ).
This can span to using a gallery of template images(saved on a concept-basis or label the attachment and have multiple attachments) , select, load and then draw/annotate.
or taking custom pictures(esp for analysis using the pool of saved Obs with clinical exam for reasearch) that can even be analysed by model of datasets( e.g AI & ML) to provide prescription and accurate medical exam(but i think this is out of scope).
using forms
I want to be corrected here; I suppose we will make use of AMPATH forms for customisation and annotation. meaning that the UX for different use cases(Inform of widgets) like Burns, cervical cancer screening form, PRP,Pain, Injury and other concepts/observations and we just plug widgets into it (which i thing can be done via config) and associate those widgets with privileges (which can also be done via config) as the attachments coming from this particular encounter is limited to the users with a specific role/privileges. For highly sensitive pictures, only specific users can see Everything attached here is also shown in the attachment widget. ;
Images here are edited and saved or the data coming from the HTML form are sent to Odoo for material request.
Designing widgets looking at observation/condition may not scale(am just thinking). how can we categorise all the use cases of the app?
cc: @dennis@vasharma05@jnsereko
Collaborative care(it was hard in 02): The On Body Draw UI can be used to facilitate collaboration between different healthcare providers. For example, a specialist can use the module to annotate a picture of a patient’s X-ray to provide their opinion on a particular medical condition, which can be shared with the primary care physician for review.
moving towards refactoring the Drawing module, have tested it and discovered a number of bugs some then have linked theme below and the ui is quite buggy;
Determine if particular observation corresponds to particular drawing
Determine the author of a drawing whether new or old
save the SVG data for new drawing
These apis actaually do the work though apart from the above issues i obeserved above. AFter some of these arrors are rectified, i think we can move the project into the dev3 to continue the work on the APIs and the UI it self.
Though could not get this out of the box, but realised exposure of rest end points for retrieving the annotated or saved template drawings.
My question here is that are we still using the html form entry module to interact with the openMRS REST APIs(especially in 03)?
Moving forward: to give a little suggestion/improvement about the current work is;
from the ui/ux perspective;
handling the editing of the diagram on the frontend
handling the upload and storage as Heshan Andrews suggested in the
search for images based on their metadata, such as name, description, or associated annotations
Role-based access control for highly sensitive images
Automatic concept-label detection based on the area drawn on an image
handling forms for the anotations and drawing.
allowing collaboration between providers on the same drawing.
I am also seeking your advice on this;
Implement REST APIs for storing diagram metadata and images on AWS S3 mainly for scalability and security.
Kindly weigh in and give a chance to improve on this.
have UI wireframes of this, is it allowed to share them here publictly.
Running mvn clean install with a single module fails on TESTS with this log;
which was unable to make the .omod file
Though when i run mvn org.openmrs.maven.plugins:openmrs-sdk-maven-plugin:setup-sdk, in the module directory its detected and build and intstalled.
On testing out the module, alot of logs with the following openmrs.log;
Can i get a technical advice on how i move forward towards refactoring this module into a simple 03 MVP easily(best practices) as its seemingly quite painful. Though i want this to be compatible with the latest platform and then using OpenMRS 3.x API to allow for support, then doing E2E automated tests.
its quite alot of work but am here to make this a success by your guidance.
Rather than worrying about the module first, I’d probably start with an O3 frontend module that can draw something that can be serialised to a SVG. It may also be worth taking a look at the attachments module, which also uses ComplexObs to store files…
Hello there , Myself Pavan
Iam intrested in contributing to this project for GSOC 2023. I have observed that this feature of drawing shapes & drawing annotations already looks to be implemented in the drawing module documentation.
https://wiki.openmrs.org/display/docs/Drawing+Module
).
