OpenMRS Reference Application, Getting Started
Upcoming SlideShare
Loading in...5
×
 

OpenMRS Reference Application, Getting Started

on

  • 909 views

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

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

Statistics

Views

Total Views
909
Views on SlideShare
909
Embed Views
0

Actions

Likes
0
Downloads
17
Comments
1

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Dear Darius, this set of slides is providing me a great deal of stimulation as a clinician.

    Slide 8 - this format would seem to address soem of the 'overload/selection' problems associated with specific clinical environments where a choice has to be made re data entry formats and displays and therefore it is relevant to Slide 15 where you list the forms available for a specific location (?clinician).

    I am interested in your comments realting to Slides 16 & 17 and 'dense data' and how you feel clinicians seem to like this. I am not sure they do so I am interested in the logic behind this.

    I am listening to the auditory commentary so this may give me more ideas. I hope this feedback helps. Terry
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

OpenMRS Reference Application, Getting Started OpenMRS Reference Application, Getting Started Presentation Transcript

  • 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)
  • Home Screen: Your Apps “Widgets” too!
  • 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...
  • Clinician
  • 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
  • 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