Wiki Spaces


Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack


Page tree
Skip to end of metadata
Go to start of metadata

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.


4-5 June 2011

Participants in Code Jam


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


Intro Tickets

key summary

Data cannot be retrieved due to an unexpected error.

View these issues in Jira

Web Services Area of Focus

  • Unit Testing of web service calls

Automated Testing Area of Focus

OpenMRS is in the midst of a Sprint Schedule on automated testing.

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 Testing Releases 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.

  • Unable to locate Jira server for this macro. It may be due to Application Link configuration.
  • Unable to locate Jira server for this macro. It may be due to Application Link configuration.
  • 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):

  • Unable to locate Jira server for this macro. It may be due to Application Link configuration.
  • Unable to locate Jira server for this macro. It may be due to Application Link configuration.
  • Unable to locate Jira server for this macro. It may be due to Application Link configuration.
  • Unable to locate Jira server for this macro. It may be due to Application Link configuration.

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.


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


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

1 Comment

  1. From Paul Ellarby...

    Just to level-set expectations for the Code Jam on Saturday 4 June, I thought I would start a thread to explain how it will work, and what needs to be done prior to arriving at the code jam. This is not a definitive “how to”, so if you have suggestions on improving this experience, don’t hold back!

    When I have organized code jams and hackathons in the past, I follow a pretty simple “agile light” approach, and I propose we do this at the Away Day. Essentially, this means lots of conversations, planning, and feedback, so the day will look something like the approach below. I am assuming we will start the code jam on Saturday morning, but we could move the introductions and initial planning to Friday night, and start Saturday with a 30-minute planning session for each focus team.

    1 hour – opening, introductions, areas of focus
    1 hour – break into focus teams, plan what is going to get done
    2 hours – create!
    30 minutes – showcase
    30 minutes – planning
    2 hours – create
    30 minutes showcase
    30 minutes – planning

    Rinse and repeat as long as people want to keep going.
    During the 30 minute showcase, I like to do a mini-retrospective, just to ensure we are working well, and nothing is getting in our way.

    You will notice that I mention “areas of focus” (and like any good TW’er, I have shortend this to a 3-letter acronym – AoF). Right now, we have three of these – web services ; building functional tests ; and new feature development. I expect each of these to attract a different set of TW’ers, but I would like to encourage cross-team movement following the showcase at the end of each iteration.

    To prepare for the code jam, I would like to ask the OpenMRS contributors to think about the AoF, and define to a broad extent what we mean by each area. Also, are these the right three, should there be four, or two, or some other number?

    Once we have defined these AoF’s, we can then start to prepare the infrastructure to make sure we are “off and running” at the code jam, and not spending time setting up environments, etc.

    OpenMRS folks, can you talk about the AoF’s amongst yourselves, then shoot an email to the entire team with some definition around these by Friday? This will be instead of the conference call.