2016-09-22 Developers Forum

How to Join

 Click here to expand...

By Browser

By telephone

  • US telephone number: +1 201.479.2627



  • Quickly review previous meeting minutes (5 min)
  • "Crazy Ideas"
  • Review next meeting agenda


  • Darius
  • Daniel
  • Deepak
  • Wyclif
  • Bharat
  • Burke
  • "Crazy ideas"
From last week...
  • Quick clarification on our opinion of the main question (added to talk topic)
Crazy Ideas
  • Using No-SQL
  • Postgres JSONB?, Lucene, MongoDB...
  • Make "encounter document" the center of the model + index the properties and obs of this
  • Does encounter become the center of the model?
  • Currently, observation & orders are the "key" pieces of information.
  • An encounter-centered model would center around "documents" about events that happen to the patient.
  • Bharat: If encounter were at the center, and was a document, you could index things like chief complaint, diagnoses, drugs. This could make queries across multiple of these a lot easier. (Today it's hard because of lots of nested joins.)
  • Burke: "documents are fine as long as we maintain the reusability and codification/discoverability of discrete data elements"
  • i.e. Concept Dictionary should still be the foundation
  • Darius: imagine doing this approach in parallel to the current view (i.e. implement it via strangler pattern)
  • Instead of xyz_attribute, have xyz.extraJsonData
  • (though, you probably still need XyzAttributeType, and handlers, etc)
  • Bharat: Postgres native support for json datatypes has improved a ton. We can use some of it in the current model
  • Darius: e.g. when we implement Notes, which will have lots of text, this could be nice
  • Bharat: or for attributes (as Burke mentioned above)
  • Microservices in OpenMRS?
  • apt-get install -y openmrs-patient openmrs-encounter
  • Separating by tiers
  • A db service, an API service, a "UI" service
  • Separating API services
  • Patient, concept, obs, encounter, etc. each become separate services responsible for their own resources.
  • Darius: seems hard to actually split things up... seems like encounter, obs, order, note (+/- visit) are all one bounded context
  • Bharat: can improve the contracts by which another system (e.g. lab) could leverage these more effectively
  • Burke: (mapping this to 1970's era Med Informatics terminology)
  • Patient Service as a microservice == Master Patient Index
  • Darius: instead of a having a "Simple Lab Entry" OpenMRS module, have a "Simple LIMS" microservice
  • Cons
  • More logistical challenges
  • Is each microservice independently versioned? Could this lead to microservice hell? :-)
  • Increased system/upgrade challenges
  • If each microservice has its own datastore/apps, installation & upgrade could become complicated
  • Getting to "scale out" beyond 1 JVM (and how to do this)
  • De-hibernating OpenMRS (e.g., if we use hibernate, restrict its use to DB layer and prevent it from leaking into API)
  • Becoming FHIR-modeled – i.e., FHIR resources from the ground up
  • If FHIR lives up to its potential to become the standard definition of resources
  • Is this still "OpenMRS"?
  • It's "OpenMRS" if we bring the community along – i.e., we incrementally get there and provide upgrade paths for implementations
  • Burke: if FHIR becomes the de-facto standard of how EMRs are defined, we could:
  • 1) have a FHIR interface
  • 2, more revolutionary) refactor the data model to be defined by FHIR
  • since we're OpenMRS, do this incrementally with a migration path
  • OpenMRS Standalone becoming preferred for production
  • We commit to various technologies and assume responsibility for maintaing them, but, in turn, have clearer path for upgrades and leveraging NoSQL, etc.
Next week's Dev Forum topic: Uganda Hackathon Prep (led by @ssmusoke)


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