Meeting with Mentors to Understanding A large Code Base Like OpenMRS code base---More Requirements Gathering


A large code base can be overwhelming to wrap around the mind.

Wise people will disagree on whether one should do small bug fixes, code review, Read other peoples code, read the documentations. I want to say all these are ways and proven to help pick up the whole of new things(again its not knowing everything first to start off on contribution)…

But there is one proven and preferred technique of getting around a really large code-base. And modularity brings everything to reality. Its simple, pick up a module, in this case THE DRAWING MODULE, get to know all the technologies from the Back-end to the Service Layer then to the Front End. TEST and PLAY AROUND it out on the Developmet environments;

  1. Openmrs SDK,
  2. Docker

Report the bugs right here;

  1. Epic

After all this , you should be comfortable with picking on your flight path.

Not forgetting the wonderful Get Started as a Developer - Documentation - OpenMRS Wiki and other resources

But importantly I will kindly need feedback how you found the above module and how best we can improve it. and in addition to the communications that have revolved around this TOPIC;

  1. O3 Feature: Draw on a body diagram
  2. Refactoring O2 Drawing module Into O3 Draw On Body Diagram feature.
  3. No mapping for GET request after adding the Drawing module
  4. Ideas for GSOC 2023

If you time on yourself, test, play around the module then report the bugs and suggest requirements.

Thank you. nyc weekend!

@kdaud @jennifer @grace @heshan @dennis @jnsereko @dkayiwa @mozzy @jayasanka @ebons


Hi :raised_hands:

Its been nice Getting engaged in community calls and invents is a great way to get the best out of a project idea because i realised OpenMRS has all stakeholders from end users to subject matter experts to developers. Have had a chance to interact with wonderful people around the community to gather requirements for the prospective GSOC project On Body Draw Diagram App UI


  1. Have attended several 03 , TAC calls and others

  2. 19th Feb, 2023(Meetup with mentor) @heshan

We introduced each other and had a wonderful time to dive in on how to get started on the gsoc project success tips.

The main take aways from that meeting were;

  • Getting an all round understanding of the MFEs or 03 artchitecture.

  • Understanding the Back end configuration(How the client talks to single or several servers)

  • Getting used to the REST API used to provide end points

  • Well laid out requirements analysis especially sharing the same with stake holders(openmrs, providers and patients).

  1. 1st March, 2023(Meetup With Mentor) @heshan


Getting the most out of a proposal

Main take aways:(my own notes)

  • A project proposal needs to be chronological with a hierachy laying out the software engineering best practices(From an analyst point of view) i.e problem statement, Requirements(User point of view/ User oriented)- what you need a user to do with the system, Design and the Implementation

  • When collecting requiremnts look also at the existing solution and explain why you need improvements of the new system

  • Involve the stakeholders i.e




  4. 1st March , 2023 (Slack conversation with) @cduffy


Getting up the wireframes evaluated and going foward to do mockups

Main take aways;

  • What questions do you have about the concept/project idea right now?

  • Understanding what users need, trying out design prototypes (no code) and then creating mock-ups to test again—best practices of coming up with best ui design

  • Be sure of what the timeline for your project is, and what the deliverables are

  • How to engage stakeholders like DOCTORS

Ask questions like ;

  • in what situation do they need to draw something on the body in an EMR?

  • what problems do they face when doing that?

  • when they look at your designs, what questions do they have

When you understand those things, you’ll make a better contribution in @cduffy 's voice :smile:

so our doctors on the community @grace @burke @reagan you can now kindly provide feedback such that we design the best solution.

Thanks @heshan @cduffy @ibacher @dkayiwa @mksd @jnsereko @jwnasambu


2nd March call facilitated by @kdaud @jayasanka MEETING NOTES

Successful GSoC Proposals

Technical Skill building

@kdaud (Facilitator)

  • Get community feedback from our public channels(tag those that you would love to get feedback from); Talk, Slack, etc.

  • The community has different teams/squads or flight paths that you can join and take it upon yourself to join the weekly calls posted by @christine or @jennifer or any other admin(always pinned globally on Talk).

  • You must do/work on tickets. Especially those labelled intro and it needs to be ready for work

  • Work on issues or the ticket that are related to your project idea(gives you a hand ahead to get a succesful proposal) review

@jayasanka (Facilitator)


  1. Find a suitable project

  2. Prepare a proposal

  3. Submit



  • Start early

  • Read the organisation guidelines carefully.

  • Research the project thoroughly

  • Showcase your relevant skills and experience

  • Demonstrate your passion for the project

  • Show enthusiasm and commitment

  • Make sure your proposal is well-written

  • Choose a project with a responsive mentor

  • Proofread your application

  • Get feedback


  • Mandatory questions

  • Requirements

  • Design

  • Implementation

Thanks @kdaud @jayasanka @heshan @grace


@thembo42 I wanted to take a moment to compliment you on your dedication to the OpenMRS community and your commitment to applying for GSoC. Your notes on your meetings related to the project have been incredibly informative and valuable to the community. And your willingness to share your findings with others is truly commendable. :clap:

It is clear that you have put a great deal of effort into your preparation for GSoC, and your enthusiasm and passion for this project are evident in all that you do, I have no doubt that you will make a great addition to the OpenMRS community and that you will achieve great success in the program. :hugs:

Thank you for all that you do, and Best of luck with your GSoC application! :raised_hands:

1 Like

This is very well organised @thembo42, Well done. This is exactly the level of trasprency we expect from a good open source contributor.

Keep up the good work!!


wow @jayasanka this is humbling.

Thanks for the commendation.I am really thrilled and thanks too for the mentorship and I am ready to offer help in the software engineering industry and particularly Openmrs and ready to learn and grow from the amazing folks.

1 Like

Thanks so much @heshan, cant thank you enough for the mentorship. Looking forward to working with you.

1 Like


In addition to the OpenMRS REST WEB service API, is the complex obs management api sufficient to extend new functionality?

Where else can look at especially for material request on image form submission?

am working on proposal for 03; Draw on body diagram app ui

@mksd @jayasanka @heshan @ibacher @dkayiwa @jnsereko @reagan @mozzy


Going forward to developing new features for OpenMRS 03

on 6th March 2023, I had an engagement with the UX lead @cduffy to brainstorm about the new features we want to develop and eventually add design components to the style guide that will support the design system

We collaborated on figma and he pointed out insights that would be helpful for the gsoc students that want to develop new features for OpenMRS

  1. The problem description needs to be well put across to see that a new solution unique to the existing solution is realised
  2. The work of coming up with new designs can take quite some time, so scope your solution to the feasible time frame and time line giving the required deliverables
  3. Show your wireframes to a doctor/nurse/EMR user and ask them what they think of it before going any further. What is the number 1 thing they would want to do on this screen/design? @cduffy i left comments about this.

@grace @kdaud who are the practioners or doctors/nurses/ EMRS users we have here?

Going foward: 8th March I had a meet up with a mentor @heshan

Pointed out very important insights of how to furnish a project proposal. Important things to note:

  1. The project proposal provides proof of concept that going on with the project will provide value to the users, so the system will be implemented with a clear thought out problem specification and a feasible solution.

  2. The design phase mainly provides a conceptual & logical understanding of the whole project, which involves modelling specifically using the standard Modellling language UML

  3. The implementation phase also needs solid thought out steps given your requirements and how the solution idea will leverage the requirement specification.

@heshan @jayasanka @suubi7 @joshua @reagan @ebons


welldone @thembo42

1 Like

Really great work @thembo42


Finallising requirement Gathering

Going forward to provide solid Requirements for the 03; Draw on Body Diagram feature

I know this can scope beyond but this form mapping is very vital in addition to @heshan 's scope.

faciitator: @jesplana Questions: I assisted by @cduffy

  • in what situation do they need to draw something on the body in an EMR? During the admission or assessment process, doctors will indicate which part of the body was wounded or need a specific operation.

  • what problems do you face when doing that? The images on the drawing modules are quite small. So having a larger image to draw on could help.

  • when you look at the designs, what questions do you have I’m not sure how I would use the ““1. default view””. Because any diagrams have to be attached to a specific form to be able to ask questions related to the causes of injury, the findings, diagnosis, interventions and/or treatment. As drawings are saved as complexObs, they should also be part of the attachment. Being able to find the drawings coming from the form in the attachment page.

  • what number one thing do you want to do on the screen especially editing/anoatating screen

  1. First, the user needs to be able to fill in a form related to the admission or the assessment being conducted,
  2. then when necessary, choose a template to document the injury or body parts involved for the intervention.
  3. draw on the image
  4. image is saved as part of the form
  5. Be able to view all of the images/attachments for the patient
  6. Do a side-by-side comparison (but this can be done by viewing in a new window)

Here’s an example of the ICRC war surgery manual with lots of photos on how images are documented: image

Here’s also a link to the Istanbul protocol to document torture/ill treatment. The diagrams start on page 193. Here, the doctor will look at the detainee and document his/her findings. s/he may use multiple diagrams to properly document. So a form may contain multiple diagrams and they have to be saved individually but still attached to the same form.

I’m available for a call if needed and i can also have one of our doctors attend the call to give the UX designer live feedback. @cduffy kindly will need your help when we schedule a call.



@kdaud @heshan @jayasanka @grace @dennis @vasharma05 @ibacher @mksd

hi @ibacher @achachiez


Having known that the AMPATH form engine has support for custom control of annotating images, and looking at the above insights about form inputs and outputs, how will be able to wrap my app that i will be creating from GitHub - jona42-ui/openmrs-esm-drawing (react based )in an Angular app such that i take advantage of the form engine’s features for managing form data, validation, and submission.

are there configurations i need to do before hand?

and given the custom component i will create will be used as an input in a form, does it mean for every concept or diagnosis / findings will need creation of a new form, is it possible to use the form builder or there is a specific way to create new forms in the form engine?

It looks as though i will have lots of dependencies.


cc/ @ibacher @dkayiwa @heshan @mozzy @dennis @samuel34

Hi Jonathan,

Assuming that your module defines a widget specifically designed for Forms, you can encase it within an Extension to make it accessible globally. Afterwards, we can integrate this extension into Forms using controls that utilize the Extension framework. This feature is already supported in OHRI Forms/React form-engine, which will soon become the Standard O3 Engine.

1 Like

Thanks @samuel34 makes perfect sense. The extension system had skipped my mind and since my implementation may not be from scratch, I was AMPATH form-engine inclined for reasons of compatibility. cant wait to see the full functionality of the OHRI form engine-react based to explore the modern designs.

hi @jesplana @cduffy want to know if you can make it for a call tommorrow as i am planning a meet up to finalize the the ui/ux clarity of the 03: on body diagram feature before we move into code. Will be presenting the designs for feedback from doctors/nurses/EMR users.

I want all interested folks to attend.

@grace @jennifer @christine

1 Like

@thembo42 Have you thought about presenting these designs at the weekly Product Design call? These are on Mondays at 6pm EAT. That might be easier than trying to schedule a separate meeting.

1 Like

Thanks @jennifer for that insight. Let me consider that this Monday.

Hope to be put on the agenda.

@jayasanka @kdaud

1 Like