OpenMRS Reference Application

Getting startedDesign Forum, Dec 5, 2012

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

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

Specific Goals• 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.)

Build on the UI Framework module, for rapid development and reusable widgets

How do we make it happen?

• Create a “Reference Application” module, patterned after PIH’s Mirebalais 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

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

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

Multiple Locations

• 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

Already implemented in the EMR module.

Apps

• 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)

Already implemented in the App Framework module.

Home Screen: Your Apps

“Widgets” too!

Registration Clerk

• 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

Hopefully we can borrow Mirebalais registration UI and AMPATH-led registration API

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.

Data Clerk

• 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

Hopefully we borrow some of this from Mirebalais

“Administrative” patient screen

Ignore the specifics of this mockup, but note that it tries to be sparse and non-confusing

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

Clinician

• 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...

Have to implement this completely from scratch

Clinician

Analyst

• 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

Hopefully we’re sprinting on this irrespective of the Reference Application

Global Navigation Ideas

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