UX Design Updates for OpenMRS Flow / Micro Frontends

Tags: #<Tag:0x00007f29999c5d00>

This thread syndicates content that is also being posted on OpenMRS Slack, under the #ux-design-advisory channel.

This is to help ensure everyone is in the conversation on the latest UX developments on this project.

Please reply here, or join us in the project’s Slack Channel.

Signup for OpenMRS Slack at: https://burkeware.com/openmrs/slack/ and add the channels #ux-design-advisory, and #microfrontends

5 Likes

Feedback sought : do these UX regions make sense.

Figma File with UX regions of the patient file: https://www.figma.com/file/XcyrlmDjMn2rkehroDXSvE/Patient-File-general-layout?node-id=0%3A1


Background on the patient file regions : http://www.gregoryschmidt.ca/writing/patient-file-ux-regions

Background on the multi-tasking layout http://www.gregoryschmidt.ca/writing/ehr-design-multi-screen-multi-tasking

Feedback sought: EHR Convention for UX Date Display - Short Date

The proposed short date format in English is: DD-MMM-YYYY

This is to be used whenever there is clinician facing content.

This short date format closely follows the NHS CUI.

For detailed explanation on this short date convention see:


Background research if interested

I agree DD-MMM-YYYY is probably the most universal, non-ambiguous format and a good choice for a default convention.

I’m assuming this is the general convention for date display and not a universal rule. There are contexts where information last for days or weeks at most. For example, if I’m signing an order or reviewing a lab that was done two days ago. In those cases, it’s unnecessary (add valueless noise) to show the year.

1 Like

Ah yes, good point, the year may be truncated at times

Feedback sought: EHR Convention for Patient Name Display

The proposed patient name format is:

FAMILY NAME(s), Given Name(s)

e.g. SUMGONG, Jemima Jelagat

This closely follows, but diverges slightly (title excluded), from the NHS CUI.


For detailed explanation see:

Background research, if interested:

I’ve seen this convention used in some countries. Does it work well in all countries? Are there any countries that wouldn’t work well with capitalization of family names? For example, I would think it could do fine with long or hyphenated names (like those commonly seen in Latin America), but would it work okay in countries that often have multi-case names (e.g., Irish) or accented characters?

Hi, good question, I just checked the ICAO guidelines (for passports),

They said that in the case of the Family Name prefix (e.g. “von” "Mc” or “de la”) lower case or mixed cased is acceptable there. Otherwise ICAO promotes full uppercase for names.

Accented characters should work in uppercase.

Feedback sought: OpenMRS User Personas

Based on your experience as an OpenMRS implementor

  • Are these the right categories of personas to collect at first?
  • Is this the right information on each persona to collect?

Having a clear user user personas in mind, is an essential step in designing things that actually work.

This slide deck is designed to make it easier for groups to participate in collecting user personas based on their real world data. This will contribute to the design of OpenMRS Flow.

Please suggest updates to it before we circulate it among implementations.


2 Likes

Feedback sought: Patient ID Number Display

Whenever a patient identifier number is displayed, we must always display in close proximity the label for this data value.

Example: Do not only display in the patient banner a patient ID number without a label: 254 932 3022

Instead display: NHS No. 254 932 3022. or Clinic No. 392 932 3022. or. Tel. +254 932 3022

Feedback sought: Patient Age Display

Example of patient age display

Born 04-Jul-2014 (5y 2m)

Born 16-Jun-1983 (36y)

The age is shown in parenthesis after the date born. In English the label ‘Born’ is used (as per NHS CUI guidelines).

I’m usually interested in the patient’s age and DOB is only needed when verifying the patient’s identity. Putting age in parentheses (as secondary info) feels backwards to me.

FYI - we also have many cases where ages are estimated (e.g., we only have a year of birth): “~42y (born 1977)”

In theory, this makes sense. In practice, when institutions have a single medical record number used throughout the care process, the label has less value and just adds noise to the UI. In my practice, the medical record number is always presented unlabeled next to the name and I’ve never seen anyone confused by it.

In implementations using multiple identifiers, I’d agree labels are important, though we might have to be creative, since our identifier types have names that can be long and I don’t think they have abbreviations or short names out of the box. Even in those cases, if there’s a preferred identifier, the label may be more clutter than benefit.

Feedback Sought: App navigation flow - Interactive Prototype

Hi, its likely easier to see how the navigation flows via this screen capture than on the static images posted earlier above (UX Design Updates for OpenMRS Flow / Micro Frontends)

App flow on Tablet

App flow on Mobile

Desktop

I don’t have an interactive prototype yet. But its the general idea with the screen split in two. Left side is Chart. Right side is Workspace. And either half can be made full screen.

1 Like

Hi - I agree. Perhaps a better way to display this is:

in one line

Age 36 yr, 16-Jun-1983

or stacked (but with less line spacing than Talk uses)

Age 36 yr

16-Jun-1983

This also is shorter than the initial example with the label Born, and parenthesis.

Oh, very good point - the labels would need “short names”. Perhaps a work around could be to use the existing ID label field, but encourage groups to enter the ID label as a short form, rather than a long form?

National ID No.

instead of: Kenyan National ID Number

AMRS No.

instead of: AMPATH Medical Record Number

Stacked is fine. If on one line, I’d favor parentheses over a comma when on one line – e.g., 36yr (16-Jun-1983).

We will need to get these patient identifier names from the API (database). Since we have name and description, we could use name for the label. Implementations could shorten their patient identifier type names and clear up ambiguity (e.g., spell out any abbreviations) in the description. But be prepared for long names for identifier types. If long names “break” the UI, the UI will be broken for most implementations.

1 Like

These demos are awesome @gschmidt! The experience for going from patient chart to workflow and back makes a lot more sense to me when I see it in motion like this. Looking forward to talking further about getting some of these screens in front of users and getting their input.

1 Like

Much of the above information has been summarized onto a single Wiki Page, regarding the proposed Major Regions of the application.

https://wiki.openmrs.org/pages/viewpage.action?pageId=224527794

As well as new Flow Chart of the navigational flow. The full-screen view of this chart is on the Wiki page.