TW Code Jam 2011
What is OpenMRS
OpenMRS is an electronic medical record platform. Basically we provide an API and data model for storing and analyzing patient-level data, and a reference application that's used in 40+ mostly-developing countries. The system includes "core" code and pluggable "modules" that allow very powerful extensions of functionality, and UI-level customization.
Dates
4-5 June 2011
Participants in Code Jam
Preparation
To try OpenMRS on your laptop and play with web service calls, download the OpenMRS 1.9-SNAPSHOT Standalone. Unzip this file and run the included JAR file to start OpenMRS. The login username is "admin" and the password is "Admin123".
Adding demo data
https://openmrs.atlassian.net/wiki/display/RES/Demo+Data
Download Demo-1.7.1.sql.zip
Intro Tickets
Web Services Area of Focus
- Small application to test web services, using language-specific REST libraries where appropriate
- Proof of Concept in Ruby
- Proof of Concept in PHP
- Implement one of the User Stories
- Add new web service resources – see Adding a Web Service Step by Step Guide for Core Developers (REST 1.x)
- Unit Testing of web service calls
Automated Testing Area of Focus
OpenMRS is in the midst of a Sprint Schedule on automated testing.
See https://tickets.openmrs.org/browse/TRUNK-2137
Also see branch set up for this: TODO: create + link to branch here
- Write BDD script(s) for a module – see webapp-testing branch
- It would be AWESOME to get the rudimentary tests automated – see /wiki/spaces/docs/pages/25468482 section on rudimentary testing (login, find patient, create patient, etc.)
- HTML Form Entry
- Reporting Compatibility
- X/Forms
Multiple Providers Per Encounter Area of Focus
We have an ongoing Multiple providers per encounter project that is targeted for OpenMRS 1.9. Some India-based Thoughtworkers have done some initial tickets in this project.
From my quick analysis, the following tickets will provide a minimal coherent, demo-able version of this new feature (if we enter some data via sql inserts):
- Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
Time permitting, these would make the demo less "minimal" (and avoid the need for sql inserts in the demo):
Flowsheet Module Area of Focus
Thoughtworks has been helping to develop a module to view patient data within OpenMRS.
- Update flowsheet module to follow OpenMRS API conventions (DAO & service layers)
- Make flowsheet module persist the search concepts (e.g., in a cookie) between sessions
- UI improvements
UI 2.0 Area of Focus
We are redoing our UI from scratch in OpenMRS version 2.0 (see OpenMRS 2.0 User Interface Redesign). We're still in the early stages, and it's probably a bit early to do what I'm proposing here, but here are some potential code-jam ideas:
Analysis/Design of a "notification/task bar" element
We want a fixed element of the UI where we can inform/remind the user of ongoing tasks and processes. For example:
- you have 2 messages in your inbox (click to see your inbox)
- you have patient X's record open
- click to go back to the main page of this record
- maybe if you have multiple patients open, this is a "stack" and clicking slides open the stack
- you ran an analysis and its results are stored in your session (click to see them)
We've explored doing this as a "taskbar" panel at the center-top of each page through this mockup and this prototype implementation.
Is this a good approach in general? If not, what alternative approaches should we consider? If so, what are some points we should keep in mind while implementing this UI element? What standard interactions does it need?
Analysis/Design of a "popup preview" interaction
Often, the pages in our UI will display elements that have additional descriptive metadata we don't display by default, and sometimes their own "view/edit" page as well. We'd like the user to be able to get access to this additional descriptive metadata, without leaving the current page, to avoid breaking the flow of their actual task. Some possibilities:
- hover -> tool-tip
- click -> slide in a "preview pane" from the right side of the window
For example the page to view an encounter would display short forms of these items, with possible additional information
- location the encounter took place
- map showing hospital X relative to other locations
- the providers who participated in the encounter
- job titles of those providers
- the user who entered the data
- account username, last login
- hematocrit = 40%
- normal range = 32.3 - 51.9
Or a patient's page might list the patient's last 5 encounters. In this case you might want to preview the encounter, but you might also want to navigate to it.
What's a good common UI interaction that will unobtrusively allow people to get additional info about visible items? How do we avoid confusion if some of those same items may also be navigated to? Advantages/disadvantages/alternatives to in-place (e.g. tool-tip) vs fixed location (e.g. preview pane)?
Icon design
In the new UI we would like to use a coherent, attractive, set of icons to represent different OpenMRS verbs and objects.
Verbs:
- Add (e.g. Add a new Identifier to a patient)
- Edit (e.g. Edit an observation)
- Delete (e.g. Delete an encounter or remove an identifier from a patient)
- Retire (e.g. de-active a data collection form so it isn't used in the future)
- Mark as preferred (e.g. mark which of a patient's addresses is their primary one)
- ...
Objects:
- Patient
- Provider (e.g. doctor, nurse, community health worker)
- Concept (the basis of our data dictionary, representing a question, or a coded answer, e.g. "weight in kg", or "diabetes")
- Observation (atomic data element, like "weight = 70kg" or "family planning method = oral contraceptives")
- Location (e.g. a clinic or hospital)
- Visit (e.g. a 1-hour outpatient visit, or a 2-day hospitalization)
- Visit Type (e.g. Outpatient, or Hospitalization. Does this need its own icon?)
- Encounter (a single transaction where data is collected and
- Attribute (an "additional property" added by the sysadmin through customization: Person Attribute, Visit Attribute, Provider Attribute, ...)
We'd want to use these in:
- administrative pages (e.g. Manage Visit Types would be in a section with the Visit icon in the header)
- patient pages (e.g. the box in the header that says "currently in hospital X since date" would have the Visit icon)
- buttons (e.g. the patient demographics page would have buttons for "add a name" and "add an address")
- should we use the same add icon for both those examples? or would each have an icon that composes a common "Add" verb on top of the icon for the underlying object?
- timelines pulling together multiple types of data items
Known Issues
- Authentication may not work quite yet
- Module servlet mappings are absolute (not relative to context path)