Implementation of the Order Entry UI application in ReactJs

Hello,
We are redesigning the order entry ui application using ReactJs.This application is currently implemented using Angular Framework. Attached are the screenshots of the current and the mockups of the proposed design. Any suggestions towards this feature are highly welcome. thank u.

Proposed

Before the drug is selected

After the drug is selected

Current


Screenshots of the application workflow can be found here


Contributors:

@zeze @betty @larrystone @flavia @fred @dkayiwa

1 Like

@geofrocker Just a watchful sightseer is the foundation of the screens and HTML layout TwitterBootstrap?

1 Like

@ssmusoke These are just mockups.

Hi @geofrocker

Seems good improvements for the Order Entry UI applications. I would like to add few comments about this :smiley:

  1. Is it possible to hight light the Patient Information from the grey background? Because the bottom part (Even Outpatient or inpatient) is common for the Patient. If possible, you can use some different background color to highlight that part like the current design.
  2. Here you have simply mentioned the Male or Female below the Patient Name. Can you think about using the image to illustrate this one :slight_smile: . Let’s add a Square Image on the left side to patient information and add the Male or Female image to that one based on the patient sexual information.
  3. The taps (Outpatient and Inpatient) are not visible like an actual tap. Is there any way to improve the UI/UX for the tap content?
  4. Can you use the tap view to show the Active Prescriptions and Past Prescriptions? Then somehow, we can reduce the total height of the Order Entry UI applications :smiley:
  5. New mockup also contains only texts for the action menus like Edit and Stop. Can you use some icons with the name to indicate the Edit and Stop actions.
  6. Some labels(Dosage, unit, …) are located on top of the text field input sections and some other labels(Needed for) are located left to the text field input sections. Can you work to make this consistency? It will be good if we use one styling format over there.
  7. Alignments should be considered while working on the UI/UX. Can you please fix the alignments of the input fields, New Order for, and the white color big box?

The suggestions mentioned above are just from my view :slight_smile:. Feel free to discuss if you have any concerns.

CC : @dkayiwa

1 Like

@suthagar23 Thank you for the feedback. We are still digesting it as a team

@geofrocker I’m excited to see this project getting worked on!

You should know that the current orderentryui design was done by two people (me and @jteich) with almost no input from anybody else. So you should not assume that it has the perfect workflow. And further, most people on Talk will not really be familiar with how it works, since it never made it to a 1.0 release.

Therefore I suggest that before you start making small tweaks to the screen layouts, you should begin by pasting screenshots of the entire workflow of the existing application that you’re using as a starting point, so that people can give feedback on the overall flow as well.

1 Like

Also glad to see this moving forward! Here are a few things I noticed – happy to help more as you continue.

  1. I like your display of Active Prescriptions shown on the first screen, because it gives you the option either to deal with existing/old prescriptions or to start a new prescription on the same screen. You do not need to have the Active or Past Prescriptions shown once the drug is selected, though; at that point they will no longer be relevant to the workflow.

  2. You will find that, for outpatient prescriptions, it is necessary to select not only the drug (“Penicillin”) but also the drug form (“tablets” – as opposed to “liquid”, etc.) and possibly the strength (“250 mg tablets”) BEFORE you can get to the “after the drug is selected” screen – the prescription isn’t fully specified without them. For inpatient, you don’t have to do that because the nurse and the pharmacy usually make that choice for you.

  3. Field controls:

  • Dosage (“Dose” is more correct) – either an free number entry field, or a selector. If a selector, your system needs to be smart enough to know all the common doses for all the drugs.
  • Frequency – should be a selector; there are few enough choices
  • Route – same
  • Duration – almost always a free number entry field
  • Dosage (after “Dispense”) – should be just “Number” rather than “Dosage”. This also would be a free number entry field.
1 Like

I should mention that we designed a really nice set of screens for doing this on a tablet, as part of the OpenMRE Ebola project. See Figure 1 in the article we wrote about it. I would particularly like to steal the idea of screens B (shows the most-commonly-used drugs) and C (shows available drug formulations for the generic drug you select).

1 Like

I’d like to an order entry UI that:

  • Can be used (eventually) to support any type of order. While we may start with drugs ± tests for now, we want to eventually expand to referrals, procedures, radiology orders, supplies, diet, activity, nursing instructions, etc. At this point, I’d avoid hardcoding in labels like “Active Prescriptions” or the assumption that all orders will neatly fall into the same table structure. Let the order type dictate the order form details and the rendering and, if we use a table (though tables work better on desktops than phones), then limit columns to those that work for all orders (i.e., “order” and “action(s)”).

  • Responsive UI. The design should be able to scale from desktop to tablet to phone without having to be re-written.

1 Like

Thank you all for the feedback. It is really helpful. We are going to work on it.

@darius We have added the screenshots of the entire workflow of the existing application at the bottom of our post.

1 Like

Remember Agile!

image

I highly recommend that the Andela team focus only on the specific use case of Drug Order Entry for now, and we keep the UI specific to this (e.g. “Active Prescriptions” is fine). Once that is built and released, we can add Lab Orders, and this may require changing some text labels, or even the whole screen layout. (Full order entry is a huge project, and its size and complexity have the potential to distract…)

That said I agree with Burke’s that you should not use a table with many columns for this, but just write out the whole order text in a single column. This is probably more familiar to doctors, who are used to doing this on paper.

In the existing UI it looks like this: image

Bahmni does it similarly:

This will allow both structured and free-text drug orders to be recorded, and it will also pave the way for other types of orders to be listed inline as Burke points out will happen in the future.

FYI the API has a mechanism for different types of dosing instructions to be defined (the main one is SimpleDosingInstructions) and the thing they have in common is that they can all be represented as a string.

1 Like

Fair point. My point was more along the lines of (if you’ll allow my variation of Henrik’s cartoon)…

So, they can focus on drugs only, but at least do it knowing what direction we’re heading – i.e., hack in the right direction.

We have two implementation ideas concerning how to approach the new Order Entry UI OWA; these are listed below:

  1. Would require installing the existing Order Entry UI omod and the new OWA.
  2. Would require installing only the new OWA without the existing Order Entry UI omod.

With option no. 1, after installation, the admin navigates to the clinicianfacing page containing the patient details. From this page, the admin can proceed to the new Order Entry UI OWA by clicking on the PRESCRIBED MEDICATION link.

With option no. 2, the Order Entry UI OWA is available as a shortcut card on the admin homepage. Clicking this card takes the admin first to the Find Patient Record module to search for or select a patient, after which the admin is taken to the Order Entry UI OWA.

My challenge is how to handle linking the Find Patient Record module to the Order Entry UI OWA.

cc: @zeze @betty @larrystone @flavia @geofrocker @dkayiwa

1 Like

@fred are you asking for how to link to this page https://demo.openmrs.org/openmrs/coreapps/findpatient/findPatient.page?app=coreapps.findPatient from the OWA?

Yes, how to link to that page from the OWA.

Can you ask your team mates for how to link to another page from HTML/JavaScript?

No, this new OWA should be free-standing, when used against the OpenMRS Platform (which includes the REST API).

If there is any required business logic in the OMOD then please ask for advice on whether we can move it out to the core platform in some way.

At least this is true for the standalone screens for ordering meds. Listing current orders on the patient dashboard can’t be done purely in an OWA, though I think that could be moved to the coreapps module.

In order to set up a link from the main OpenMRS UI into the Order Entry OWA, you would do this using with extension, which for now you have to manually set up, but I hope eventually can be automatically done via the OWA manifest file.

Alright. Will do so

Thank you very much for the detailed feedback. This is really valuable to the team. Please if there is a documentation we could use for the manual setup, we would appreciate if you could spare a few minutes to share it with us.