No mapping for GET request after adding the Drawing module

Am running the Reference Application 2.13.0-SNAPSHOT local instance using SDK Wanted to test out and play around the Drawing module 2.2.0-SNAPSHOT. cloned and built the module, Added the .omod to the modules and started it after creating a new concept class following this doc openmrs-drawing-module

am getting this error. pastebin.com

1 Like

@dkayiwa @burke @sharif kindly give me pointers here. want to see if this an be good candidate for 03

1 Like

Add .form to this url: openmrs-module-drawing/DrawingManageController.java at 2.1.0 · openmrs/openmrs-module-drawing · GitHub

1 Like

has not been recognized as standard part of the url therefore it has brought 404 status code error, can not be found

1 Like

Can you raise a pull request that has the changes you have made?

1 Like

PR-here though changing the url seemingly means changing file names as the endpoint is a java file.

The link that i posted above points to the exact line where you should change manage to manage.form

PR-here, kindly review this

Did you test it out?

am getting this-thread’s error exactly. have followed step by step though quite different is running RefApp 2.13.x-snapshot.

using ....openmrs/index.htm , does not work it gives this log pastebin

I have deployed the new build of the module after adding .form using RefApp 2.12.x and openmrs core 2.4.x; it works. Put server down and re sets it up, logs pastebin appear, ...openmrs/index.htm does not work

it seems [LUI-190] Core on Tomcat 9.x and RA 2.6.x not starting up - OpenMRS Issues still poses risks in the deployment/ dev environments .

yes, it works well thanks @dkayiwa

1 Like

Generally speaking it would be great for AMPATH forms to support annotating images (and save the annotated images as complex obs within encounters).

You asked me this question in private:

Does it mean i will need to start on 03 tickets and then try re writing the modules with react and micro front end technologies.

I don’t know that for sure yet since AMPATH forms is basically written in Angular. I’m definitely not the right person to ask about such details.

Hopefully there is a way to embed in an AMPATH form a custom control for annotating an image, and that custom control may hopefully be in any preferred frontend technology, @achachiez @ibacher?

1 Like

We have support in the form engine for custom components. The component themselves need to be wrapped in an Angular component (the form engine basically uses Angular’s template-driven forms), but the actual library to implement the drawing doesn’t need to be Angular-specific…

2 Likes

Ok so that’s good. However we would need to properly think the UX of annotating images. This would be the first step, and I don’t think we have anything yet there that has been designed.

1 Like

cool, given the plight of the tech trend in the community, it suffices, unless otherwise that React with MFEs provides 03 feel of the user experience and interface and collaboration. My doubt is an open source library for drawing to provide the variety of the community priority objectives and use cases because I know openmrs has standards and processes and depending on the goals of the project, to pick on a drawing library ,considerations to the cost benefit and programmer effort etc, are key.

Can some one point me to such a library. ? the first requirements got from the previuos implementation documents of drawing modules have no address for 03.

Great, that’s true . It’s not uncommon for project ideas to evolve and change as they are being developed, and it’s important to be flexible and willing to adjust the scope of the project as needed.

forexample, for the case to drawing app ui to support concept-label detection, but that the scope of the project may have become too broad. though still the change of requirements can happen as this is very important for both patients and healthcare professionals, as it can provide a quick and easy way to communicate and understand complex clinical information.

And i think 03 will help us to , capture patient data with an intuitive user interface and experience,analyse the data and share it with other systems seamlessly(MFEs technology) as this should have been hard in 02.

This iss very important forexample; we can have a UI/UX that shows a form that allows users to input information about the place of injury, including the location, date, and time of the injury. It also includes a map and a list of injuries, which can help users to understand the context and severity of the injury. or UI/UX that shows a dashboard with various widgets that display information about burns, painful body parts, and cervical cancer screening. It also includes a menu that allows users to navigate to different sections of the app.

I thinkI will need to roll up these designs here in the famious carborn system such that we get a feel of this :grinning: But i need a mentor to work along with(towards success of this) for good measure and pointing me to right resources @grace @dkayiwa @dennis @jwnasambu @jnsereko @sharif @mozzy

Question: when i design a dashboard forexample; The dashboard including a menu bar(carbon component :grinning:) along the top of the screen/ desktop,.the menu bar may include buttons or links that allow users to navigate to different sections of the app. For example, there might be a button for accessing patient records/summarry, or a link for viewing reports or statistics, will this laverage the openmrs reporting module(i know it will), but am curious to know wether the Micro front end module will not have its own inbuilt statics for example if the stats about the diffrenet use cases eg, physiotherapy, Palliative care, burns etc in comparison to the number of patients that have reported such on different ecounters.

sorry for the mount of words!!

@dkayiwa @dennis @grace @ibacher

@thembo42 I always recommend quick, hand-drawn sketches as a helpful way to share ideas. Could you draw out what you’re imagining and share a picture of your hand drawing? Doesn’t need to be pretty or perfect, just a helpful starting point.

Re. useage reporting - see Examples of "Clinic Dashboards" in OpenMRS EMRs for some relevant info.

1 Like

sure, @grace thanks för the resource , will work in this over by Monday

1 Like

came up with sample ui/ux for the drawing feature, sorry if I miss used components :pray:, it was quick and I ask for comments. I want to suggest my thoughts in a number of use cases(more can be implemented);

  1. Burns
  2. Pain recording
  3. Digitalizing Cervical Cancer forms
  4. Physiotherapy…

The mechanism involves both drawing and clicking different anatomical drawings and saving them as complex Obs. These are editable, deleteable…

Given the workflow stage, forexample the Visit note, a ui component to add a diagram/image provides a means to laverage the drawing feature.

The patient dashboard, forexample under the HIV summary stores the annotated diagram showing the specific area affected, and other clinical exam findings (create visual representations of the location of rashes or other skin findings, or to document the location and size of tumors or other abnormalities found during an exam) intuitively with a nice user experience like below, easily shareable, edited and understood by everyone;

Data received in the form is mapped to images or drawings with a ui and ux coming from an editor, which are stored as complex Obs. eg an example given by @mksd concerning digitizing the cervical cancer screening form like this

cervical This finds its way in either drawing or whipping up standard anatomical cards/ templates to help illustrate the examination by the provider as below;

  1. usinga pool of pre defined illustrative anatomical diagrams aka Anatomy Desk from an open tab with search funcuanality to filter any concept(more on this later) anatomy;

  2. In this case the screening nurse/doctor is supposed to draw areas within the cervix’s oval, which can be quite tricky to do with old mouses and touchpads. the modern drawing libraries or even touch screen functionality in case of tablets will provide a better user experience;

    This still can apply in palliative care as its important to know the use cases of such also;

  3. Providing a way for palliative care patients to express themselves and communicate with their care team and loved ones, even when they are no longer able to speak or write.

  4. Allowing physical therapy patients to practice fine motor skills and hand-eye coordination by drawing and coloring

  5. Offering a form of creative expression and relaxation for both palliative care and physical therapy patients

  6. Providing a way for patients to document their progress and share their artwork with their care team and loved ones. 5…

It really provides a better user interface to express or document patient info with audio and other attachements

Its important also to consider documenting Body maps and concept-label-detection as suggested by @grace . forexample pain/ injury measurement and reaserch by the providers. FYI; Two categories of pain assessment

  1. Pain scale: Pain scales can be numerical, visual analogue, or categorical, to evaluate the intensity and category of pain
  2. Body map: Body maps provide added value in that they evaluate the location of pain. clinics that carry out surgery, this enables them to investigate factors that impact long-term opioid use with the ultimate goal of understanding when to pursue alternative pain management strategies for patients undergoing surgery.

Similarly physiotherapy provides options to document findings and provides foms to store patient data;

form data;

@grace @dennis @dkayiwa @ibacher