How to Join
Click here to expand...
By Browser
By telephone
- US telephone number: +1 201.479.2627
Agenda
- Quickly review previous meeting minutes (5 min)
- "Crazy Ideas"
- Review next meeting agenda
Minutes
Attendees
Agenda
Notes
From last week...
- Quick clarification on our opinion of the main question (added to talk topic)
Crazy Ideas
- 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
- A db service, an API service, a "UI" service
- 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
- 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
- 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:
- 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)