Child pages
  • 2015-05-07 Developers Forum
Skip to end of metadata
Go to start of metadata

How to Join

 Click here to expand...


In person

Courtesy, please

If you are joining remotely via telephone, Adobe Connect, or Skype, please use a headset-microphone, or at least earphones. Please use the mute feature when you are not speaking.

Interactive meeting - Adobe Connect

  • We routinely share a screen during the call. You can view the screen via our Adobe Connect meeting room at For large meetings, the room has the ability to broadcast audio and connect to a telephone-based system as well, as controlled by the meeting hosts.

By telephone

  • US telephone number: +1-888-510-4073
  • Access code: 24222#

By Browser


  • Chat is available in the Adobe Connect meeting room (see above).
  • A backchannel meta-discussion during the meeting also occurs on IRC.



  • Quickly review previous meeting minutes (5 min)
  • Google-MSF Ebola project w/ Nick Fortescue (Google)
  • Review next meeting agenda


View at


OpenMRS Developers Forum 2015-05-07
Recording: (Audio) (Adobe® Flash®)
  • Maurya
  • Nick Fortescue
  • Burke Mamlin
  • Michael Downey
  • Dallas Tx
  • shefali
  • Rafal Korytkowski
  • Willa Mhawila
  • Darius Jazayeri
  • Cosmin Ioan
  • Tomasz Mueller
  • Wireless Caller
  • Deluan
  • Daniel Kayiwa
  • Hamish
  • wintech
  • Jonathan Teich (silent)
Agenda & Notes
  • Review last week TODOs
  • TODO: Burke to notify presenters about their dev forum topics
  • TODO: Someone to Set up CI builds for MariaDB, PostgreSQL, and SQLServer, Oracle (We assume these will not be green lights)
  • TODO: Someone to Create tickets to address problems that occur for alternate DBs
  • TODO: Someone to Schedule sprint(s) to address DB tickets
  • TODO: Someone to push for mocks over integration tests
  • TODO: Someone to document how to test within IDE in dev pages in wiki
  • Google-MSF Ebola project w/ Nick Fortescue
  • Originally started by some open source volunteers
  • Google Tech Talk video was more helpful in quickly understanding the background compared to online documentation
  • It would help to have key points from the video on the website
  • OpenMRS Evaluation
  • Pros
  • Open
  • Domain knowledge of originators
  • Established user base in the field -- people actually using it in Africa.
  • Cons/Risks
  • Hibernate
  • magic is dangerous
  • efficiency/performance issues
  • Tomcat
  • performance
  • MySQL
  • can't run on a device (would have preferred to have had a SQLite option)
  • Bad rep
  • For large facilities only (more for hospitals than small clinics/efforts)
  • Bad UI
  • Not production grade
  • Getting Started
  • Painful.  Took several days to get started with OpenMRS
  • Outdated info about lightweight H2 database, only supported by some plugins
  • Standalone good for aquick try, hard to integrate with module development
  • Complexity almost made us ditch OpenMRS
  • Module development experience
  • Once you have things working it's fine, but hard to get there
  • Baded in assumptions (e.g., package name)
  • Maven archetype wizard hides critical details
  • Running doesn't stop if tests fail (runs old version)
  • Only one person could debug locally
  • One day to get developing
  • Resorted to print/log statements for debugging
  • Code
  • Mixed
  • No style guide enforced
  • Lots of large complicated methods
  • Javadoc thin
  • Undocumented assumptions about data
  • Above average for an open source project
  • Assumes single server with web based interface
  • Assumes time consistency
  • REST
  • Not good for transactionality, had to implement our own API on top
  • Made implementing our own API easy
  • Weird regex for package names
  • X/Forms
  • Significant thread safety issues (uses static variables)
  • Doesn't work out of the box with ODK
  • Led to forking
  • Performance
  • Worked amazingly good
  • Database schema
  • Diagram was super helpful
  • Design is excellent
  • Annotation based validation super annoying
  • e.g., hardcoded max age of 120!
  • bad failure mode (lack of transactionality means one validation could fail but transaction still go thru)
  • Too much business logic in low level code
  • "it has gone slightly too far towards too much validation"
  • Can lead to UX linked to data model (e.g., Order Model)
  • Concept db
  • CIEL amazing resource!
  • Need a few more consistency guidelines
  • Latin vs. common name
  • US vs UK spelling
  • Localization not quite orthogonal enough
  • UX tied to searching
  • Ended up using fake locale to work around limitations
  • Distinct local vs parent changes essential
  • Updates were hard and scary
  • updating CIEL was scary/fragile
  • Documentation
  • Some really excellent
  • Some might have once been good, but out of date
  • Most docs very hard to tell what version of code they were talking about (e.g., OrderService re-written around 1.9)
  • Version numbering inconstency doesn't help
  • Top priority features
  • Rock solid CIEL dictionary/local change management module
  • Revisit of UX localization for concepts in Schema
  • Rock solid backup/restore module
  • 30 minute process from 0 to debugging a module on Mac, Windows and Linux
  • Hard: refactor commonality from X/Forms and HTML
  • Questions
  • Can we get the transactional API that was made atop the REST API?
  • Eventually, all code will be open source
  • Note that work was rushed to address the Ebola epidemic
  • Was fork of X/Forms module submitted back (pull request or suggested improvement)?
  • Dates were formatted differently between ODK and XForms module
  • Daniel Kayiwa would be a good contact
  • Can you say more about UX localization for concepts issue?
  • Hard to add local modifications to the CIEL dictionary concepts
  • "You need to make local changes, and you have to find somewhere to put the string."
  • Did you look at the SDK? / Were you using the SDK? (Nick mentioned omrs-run)
  • yes
  • "a bit too magical" difficult to understand the difference between SDK and maven
  • Can you tell us about your experience with the offline/online synchronization of clinical data between the Android Apps and OpenMRS. This is a big challenge for OpenMRS in general use (i.e. separate instances synching to one master server)
  • Decide for every piece data if it's edit in place or additive
  • Observations are pretty easy, since changed can just be queued & aggregated
  • Orders are tougher
  • Fight with UX designers to keep the model clear to users.  For example, UX designers might want to be able to edit temperature, when this isn't actually editing a value, but adding a new value.
  • Do android apps work well vs a web based interface?
  • Big decision early on about tablet app vs web-based. (Web-based would require HTML5 offline storage, which would get tricky.) Went with native because we thought offline sync would be easier. Needed to do RFID reading, which wasn't feasible web-based
  • For UX reasons (wearing triple wet gloves, constantly washing hands) needed to prevent scrolling; you can do this in html, but it's tedious.
  • The RFID use case was the only deal-breaking reason that it had to be native.
  • It sounds like you didn't run using jetty in development. Was this intentional for some reason? (Or maybe this is a downside of the SDK?)
  • Documentation/SDK improvements would help a ton – any dev first encountering OpenMRS should be debugging
  • Couldn't get running from an IDE working
  • Did you write some "better" docs for "how to get your dev environment set up" that are worth sharing more broadly? (Or are they too project-specific.)
  • Nick will look back at his email
  • How did you interact with the community? Pros & cons?
  • Emailed dev list quite a lot, having devs in different timezones was fantastic!
  • Didn't use IRC much
  • Emailed Andy directly about dictionary issues
  • Emailed Darius directly about Ebola-specific issues
  • Emailed Daniel directly about XForms
  • After action review
  • What did you expect to happen?
  • What actually happened?
  • What can we do better?
  • Next week
  • 14 May: ThoughtWorks-SCI Ebola Module tech deep dive (Darius)
  • 21 May: GSoC Q&A/intro


Outstanding TODOs  (${entries.size()} issues)

Summary Assignee Created Due

Create a TODO:


  • Audio recording of the call: Listen online or download (available after the meeting)



  • No labels