Dev-focused discussion points for the Dec 5, 2012 OpenMRS Design Forum.

1. OpenMRS Reference Application
Getting started
Design Forum, Dec 5, 2012

2. Why “Reference Application”?
• There is no such thing as the OpenMRS
application.
• There should be many applications built on
the OpenMRS API.
• As OpenMRS, we will build one “reference
application”
– an example for others (and a reusable one)
– not a solution to all problems

3. Guidelines
• Satisfy the 80% use case. Custom needs will
require custom development.
• Consistent design and user experience
• Prefer less functionality, released faster, with
good and consistent UX
• Borrow the best modules from implementations
• Build configurable functionality, via modules
– Can build other applications by reconfiguring the
building blocks of the Reference Application
• Separate versioning and releases from the API

4. Build on the UI Framework
Specific Goals module, for rapid development
and reusable widgets
• First release in the first half of 2013
– Can run alongside the OpenMRS webapp
– No requirement to support all existing functionality
– Existing implementations don’t need to switch yet
• Built for real-time use, also supporting retrospective entry
• Role-based workflows, with specific real-world roles pre-configured.
– Possible initial target:
Registration clerk, Clinician, Data clerk, Analyst, System Administrator
• Support for multiple locations, and hierarchies
• Good global navigation and application framework
• A few really good widgets. (So we can copy these patterns for
years.)

5. How do we make it happen?
• Create a “Reference Application” module,
patterned after PIH’sMirebalais module
– (Do this now)
– Contain no functionality of its own
– Configures other modules, provides CSS, etc
• Set up CI/CD, also patterned after PIH-Mirebalais
– (Do this with our first line of code)
– Builds and tests after every commit
– Always have a latest live demo

6. How do we make it happen? (2)
• Decide what workflows to include in release 1
• Start doing BA and UX analysis on the 80% use
cases for those workflows
– (Need UX expertise)
• Some initial low-FTE sprints to set up the
framework and get good examples in place
– (Do this soon)
• High-FTE sprints to implement lots of
functionality following the good examples

7. What might this look like?
• Following are mockups, screens, and ideas
from various sources, showing the direction I
want to go in our first release.
• We should have lots of healthy debate about
this going forwards, and this should including
implementers, users, and UX advisors

8. Already implemented in
Multiple Locations the EMR module.
• When you log in, choose
a location
– Assuming more than one
configured
• Pages aware of “session
location”
• Lets us support:
– facilities with sub-locations
– multiple facilities sharing a
medical record
• Out of scope: a new
security model

9. Already implemented in the
Apps App Framework module.
• No monolithic application
• Instead: targeted Apps, each with limited
workflow-specific functionality
• Roles only see certain Apps (via privileges)
– New homepage will be “your available apps”
• Build some key Apps as part of a core process;
expect the community to write (many) more
• Example: “Vitals Station” with a locked-down
workflow to:
– 1. Find checked-in patient; 2. Record vitals; (repeat)

10. Home Screen: Your Apps
“Widgets” too!

11. Hopefully we can borrow
Registration Clerk Mirebalais registration UI and
AMPATH-led registration API
• Support for a “Front Desk Clerk” role that can:
– Create patients
– Check in patients for visits
– (bonus) Schedule appointments
• If the sprints on this module go well. :-)
• Use this to implement a key UI paradigm
– Repetitive, high-volume tasks; work fast, don’t think
much; follow a strict workflow
– Optimized all-keyboard UI
• Reuse this paradigm for other workflows

12. Big, friendly fields,
optimized for repetitive,
answer-every-question
flows
In general, I think we should
spend some time on cool extras,
for the wow factor.

13. Hopefully we borrow some
Data Clerk of this from Mirebalais
• Support for the historic “Retrospective Data
Entry” workflows
– Find a patient
– Fill out forms
– Edit demographics, relationships
• An “administrative” patient screen, focused on
data entry, not clinical details
• Use this to implement a “friendly”, not-too-
dense UI paradigm

14. “Administrative” patient screen
Ignore the specifics of this mockup, but note
that it tries to be sparse and non-confusing

15. We’ll need reusable widgets like “recently-viewed patients” and specific ones like “my stats”
Support something very much
like our current form entry tab

16. Have to implement this
Clinician completely from scratch
• Information-rich displays of clinical data.
• Details configurable per-implementation
– Someday, per-user
• Another UI paradigm:
– dashboard-of-widgets
– dense data
• I don’t personally like this, but clinicians seem to...

17. Clinician

18. Hopefully we’re sprinting
Analyst on this irrespective of the
Reference Application
• We have powerful-but-complex underlying
technologies, e.g. Reporting, Calculation, Data
Integrity modules
• Paradigm: new UIs that expose partial
functionality, with better UX
• For example:
– Cohort Search (i.e. Cohort Builder replacement)
– Data Set Builder (i.e. Data Export replacement)
– Run reports
– Out of scope: user-friendly UI for building reports

19. Global Navigation Ideas

20. Actions
• On a patient page (and perhaps others),
there may be tens or hundreds of “actions”
you can take.
– An action is basically a label and a URL
– Includes things like filling out forms, opening
the order-entry tool, etc.
• We should actually build these into the UI
• Have a reusable widget that lists them, with
searching
– With keyboard navigation for advanced users