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
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 : PATIENT FILE: Major UX Regions — Gregory Schmidt
Background on the multi-tasking layout A Multi-Screen & Multi-Tasking EHR UI from First Principles — Gregory Schmidt
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.
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
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.
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.
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.
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.
Much of the above information has been summarized onto a single Wiki Page, regarding the proposed Major Regions of the application.
App's Major Spaces | OpenMRS Flow - Projects - OpenMRS Wiki
As well as new Flow Chart of the navigational flow. The full-screen view of this chart is on the Wiki page.
Hi, please find for your review an example of the navigation bars across mobile & tablet. Desktop still pending.
https://wiki.openmrs.org/display/projects/Navigation+Bars++|++OpenMRS+Flow
