2016-09-22 Developers Forum

How to Join

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

https://talk.openmrs.org/t/should-editing-the-child-obs-make-its-parent-dirty/8049

• Quick clarification on our opinion of the main question (added to talk topic)

Crazy Ideas

https://talk.openmrs.org/t/we-need-your-crazy-new-technology-ideas/3637/4

• 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

• http://dotadiw.com "Do one thing and do it well"

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