Refactoring O2 Drawing module Into O3 Draw On Body Diagram feature.

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.

According to the community discussions;

we need to bring this to reality.


cc: @grace @jesplana @dennis @dkayiwa @herbert24 @ball @johnblack @mksd @burke

1 Like

about the scope i have a few thoughts;

  1. we need to look at the pressing needs(objectives) of Clinics and Hospital programs that need this feature.


  1. 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 :grinning:).

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.

search from gallery

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. ;

Screenshot from 2023-02-07 15-39-31

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

  1. 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.

so personally i think the scope can revolve around;

  1. Drawing and annotation(click and draw)
  2. Concept-label-detection(e.g. clicking right arm → system also encodes “right arm” etc )
  3. Form entry

Because lavereging AI/ML for prediction from patient images may be another GSOC project :grinning:

Any thoughts here??

@jennifer @kdaud @jnsereko @grace @dkayiwa



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;

I will request folks to look at them Daniel Kayiwa Ian Bacher Nsereko Joshua

A number of use cases of API s i observed;

  1. retrieve obs correspoding to drawings
  2. retrieving SVG(binary) data saved for new drawing
  3. Determine if particular observation corresponds to particular drawing
  4. Determine the author of a drawing whether new or old
  5. 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;

  1. handling the editing of the diagram on the frontend
  2. handling the upload and storage as Heshan Andrews suggested in the
  3. search for images based on their metadata, such as name, description, or associated annotations
  4. Role-based access control for highly sensitive images
  5. Automatic concept-label detection based on the area drawn on an image
  6. handling forms for the anotations and drawing.
  7. 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.

thank you.

@kdaud Heshan Andrews Jayasanka Weerasinghe Vineet Sharma Dennis Kigen Moses Mutesasira Sharif Magembe Grace Potma Dimitri R John Mark Esplana Burke Mamlin

It’s great @thembo42 to see you interested in the project and gathering ideas around it. @heshan @jayasanka could you have some comments for Jonathan?

hi @dkayiwa @ibacher


Apache Maven 3.6.3

Maven home: /usr/share/maven

Java version: 11.0.18, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64

Default locale: en_US, platform encoding: UTF-8

OS name: “linux”, version: “5.19.0-32-generic”, arch: “amd64”, family: “unix”

have tried testing out the GitHub - openmrs/openmrs-module-drawing: This module provides a way to draw and annotate on images and save them as complex observation. and have found lots of blockers;

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.

Thanks for the guidance

@dkayiwa @ibacher @mksd

Is there any reason why you are not compiling with Java 1.8?

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…


thanks @ibacher @dkayiwa have created an MF module with a little project setup and mainly the draw functionality and serialisation to svg.

Though have gotten abit of blockers on configurations;

mainly the app is esm-drawing-app(not sure of the convention consideration)

when i run yarn start

Then looking through the GitHub - openmrs/openmrs-module-attachments: UI components and backend web services to upload, view and manage attachments within OpenMRS.

looks not to be present on

Lastly i will need to get the magic of esm-moodule and the api end points


@jnsereko @dennis @heshan @jayasanka

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.

Are there any features Iam missing out on…

Please clarify

hi @pavan thanks for your interest in the project, kindly find the need for the project here;

Thanks @ibacher

So firstly i need to fork the esm-template and setup an angular workspace with o3 since i will be using ampath forms for custom control and a front end drawing react library? right?