Child pages
  • 2016-09-22 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 http://connect.iu.edu/omrsdf. 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/IRC

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

 

Agenda

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

Minutes

Attendees
  • Darius
  • Daniel
  • Deepak
  • Wyclif
  • Bharat
  • Burke
Agenda
  • "Crazy ideas"
Notes
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)

Transcripts

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

 

 

  • No labels