OpenMRS Reference Application, Getting Started

OpenMRS Reference Application, Getting Started

• 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 the80% 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 theUI 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 wemake 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 wemake 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 thislook 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 inthe 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: YourApps “Widgets” too!
• 11.
  Hopefully we canborrow 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, optimizedfor repetitive, answer-every-question flows In general, I think we should spend some time on cool extras, for the wow factor.
• 13.
  Hopefully we borrowsome 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 reusablewidgets like “recently-viewed patients” and specific ones like “my stats” Support something very much like our current form entry tab
• 16.
  Have to implementthis 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 apatient 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