OpenMRS Reference Application Getting started Design 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
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.)
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
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
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
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)
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
Big, friendly fields,optimized for repetitive,answer-every-questionflows In general, I think we should spend some time on cool extras, for the wow factor.
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
“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
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...
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
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
A particular slide catching your eye?
Clipping is a handy way to collect important slides you want to go back to later.