2014-11-06 Developers Forum

Owned by Jamie Thomas
Last updated: Nov 06, 2014 by Burke MamlinVersion comment
6 min read

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)
  • OpenMRS 2.2 planning
  • Review next meeting agenda

Minutes

View at notes.openmrs.org

OpenMRS Developers Forum 2014-11-06
Attendees
  • Burke Mamlin
  • Michael Downey
  • Karl Wurst
  • Mike Davisson
  • Wyclif Luyima
  • Ada Yeung
  • James Arbaugh
  • Mujir
  • Angshu
  • Darius Jazayeri
  • Ryan Yates
  • Nyoman Ribeka
  • Mike Seaton
  • Sara Armson
  • Mihir Khatwani
  • Badeia Jawhari
  • Steven Wanyee
  • Willa
  • Paul Biondich
  • Mark Goodrich
  • Daniel Kayiwa
Agenda/Notes
Review last week TODOs (OpenMRS 2.1 Retrospective)
  • None listed last week
  • Someone to Identify which module(s) are demonstrating best practice
  • Burke to Get updates to Modulus on OpenMRS Technical Road Map – specifically, ability for implementer to enter comment on module and ability to rate module.
  • Sara to email implementers@ regarding OpenMRS University
OpenMRS 2.2 Planning
Our vision: Implementations (especially, PIH, I-TECH Kenya, and Bahmni) use OpenMRS 2.x as the basis for their distributions, because it provides a good & reliable foundation to meet their needs.
Our goal: PIH, I-TECH Kenya, and Bahmni see OpenMRS 2.2 as a potential destination in their road maps – i.e., each sees OpenMRS 2.2 as having one or more desired improvements/features and no deal-breakers.
OpenMRS Road Map
  • Determine how much UI Convergence is possible (between Refapp, Mirebalais, KenyaEMR, and Bahmni)
  • Program-based workflow
  • Condition lists
  • MD: agree
  • Basic Order Entry functionality for meds and tests
  • JA - would be very helpful for HHF
  • Integrated Multiple servers (e.g., sharing data, patient transfers, remote management, supporting external MPI)
  • Go into this with low expectations: something that tries to solve everyone's problems out of the box will fail. At least we should share some effort or design/approach
  • Mihir - Sorry did not get this one <- I rephrased it.
  • DJ: PIH wants to support having local servers at facilities, and consolidate their data in a central place, but lighter weight than a full HIE-level EMPI+SHR (like we discussed over lunch Mihir)
  • Yeah I did not get your comment on the same. "at least minimal coordination and sharing of effort or design/approach"?
  • OpenMRS Platform 1.9 → OpenMRS Platform 1.11 (or Platform 1.12, whatever is under OpenMRS 2.2)
  • OpenMRS 1.x → 2.2 migration strategy (i.e., help implementations get to 2.2, ok to be combination of SQL scripts ± upgrade module)
  • Registration
  • Appointment scheduling
  • (?) Specific REST enhancements (driven by Bahmni needs)
  • (?) Ad-Hoc Analysis
  • (?) Specific reporting improvements
  • Concept management: OCL-CIEL Subscription Module
  • Permission management
  • AY: Samson Gejibo from University of Bergen has expressed interests in this, from the security point of view.
  • Retrospective data entry
  • Account management
  • Improved cohort building
Areas for collaboration
  • Bahmni & I-TECH Kenya on OpenERP integration
PIH
  • Program-driven content and workflow
  • AY: would be very helpful for AMPATH
  • Improved registration (e.g., support address hierarchy)
  • JA - would be very helpful for HHF (RA-75, RA-451)
  • AY: would be very helpful for AMPATH
  • Distributed OpenMRS servers (sync, external MPI, strategies for centralized reporting, patient transfers & referrals, orders & results)
  • Test orders
  • JA - would be very helpful for HHF
  • Lab result entry
  • JA - would be very helpful for HHF
  • Episodes of care (pregnancies)
  • MD: Kenya very interested in this, if this means providing a dx history for a person.
I-TECH Kenya:
  • Test orders and results (supporting HL7)
  • Drug orders and results (supporting HL7)
  • DJ: Does this mostly mean integrating with a pharmacy system via HL7, where dispensing will be handled? 
  • SW: Yes it does.
  • Automated replication to a central site
  • MDavisson : THis would be sending encounter updates to a central server and permit patient transfer
 
  • Patient Transfers between OpenMRS servers
  • Concept management: change or merge concepts
  • DJ: does this mean doing this centrally and propagating it to many servers? Or just being able to do it at all, combine observations, etc?
  • angshu: if the answer to the above question is yes, then as part of bangladesh project, where we use OpenMRS as TerminologyServer, we have done feed based sync to client OpenMRS server.
  • MD: Hmm...  this does not particularily mean progagating to remote instances,  more along the line of improved concept management.  
  • SW: Initially just being able to do it and over time central server propagating to n servers
  • BJ: Better management of concepts is vital for KMRI/ICChange, we find it very difficult to integrate new concept releases to our current system. We've tried using the meta data sharing module but it hasn't really worked for us.
  • Improved reporting
  • AY: would be very helpful for AMPATH
  • JA - would be very helpful for HHF
  • MD: 
  • BJ: This would be helpful for KMRI/ICChange as well 
  • Steven's exact quote was "more robust reporting / extract engine"
  • Improved cohort building
  • AY: would be very helpful for AMPATH
  • JA - would be very helpful for HHF
  • OpenERP integration
  • SW: High on our list is "billing" functionality (we'll explore available work from the community) but integration with a financial info system useful as priority leading to integration with an ERP. Bottom line here is facilities in Kenya want a Hospital Wide Info Management System.
  • DJ: Bahmni has already done OpenMRS-OpenERP integration, specifically supporting billing
  • PB:  Is this in a module?  What would it take to "mainline" this?  Thanks awesome TW people... what would it take to get you on a call to demonstrate / present this?  Thanks for the github link, I think the conversation is more around how/whether strategically we'd want to integrate that code with a release at some point
  • Mihir - We have a module in MRS to publish events of certain categories, and another module in OpenERP which consumes the same. This is done over atomfeed. @PB you can email us on bahmni@thoughtworks.com
  • angshu: @PB, you can find more information about AtomFeed at <http://github.com/ict4h/simplefeed>, where it explains the protocol built over atom spec. There are reference openmrs module libraries as well
  • Monitoring tools (system performance and utilization)
Bahmni
  • Improved REST API, including better metadata support (easier to set up new system, migrate data) and also letting external apps build patient dashboards
  • Simpler, domain-specific, version-controlled app configuration
  • DJ: PIH is possibly now doing something like this, but I don't understand exactly what it means. (@Mark, what's the ticket?)
  • DHIS2 integration
  • Condition lists
  • Bed assignments
  • Appointment scheduler 
  • MD: Kenya is interested in this
  • DJ: Mirebalais is using/extending the Appointment Scheduling module originally built by Tobin et al for Tel Aviv Refugee Clinic. Can this work for others?
  • Mujir - We may need to extend emr api/rest services for appointments (assuming appointment module suffices)
  • DJ: We added REST web services to the appointmentscheduling module, but there is no integration with encounter transaction
  • DJ: It's the same module, but we created "Appointment Scheduling UI" for the 2.x UI (using the underlying API from that linked module)
  • Observation status (marking abnormals)
  • (?) Drug dispensing
  • (?) Drug order templates
  • (?) Oncology support
  • BJ: ICChange/KMRI has talked about better implementing oncology support, we are still conceptualizing our ideas. Open for feedback in this area if others are working on this as well.
  • (?) Observations on images of body parts
  • (?) PACS & DICOM
  • (?) OpenERP integration
ThoughtWorks
  • Better concept browsing (source → reference term → concept, without losing context)
  • Multiple classes per concept
  • Concept attributes
The interstitium (the "stuff inbetween", the "glue") needed
  • Skinning conventions
  • Reference Application style guid +/- touch-friendly UI. Can we converge at least a bit?
  • Clearly defined list of shared dependencies (modules & features)
  • angshu: some tech aspects?
  • supporting other db. e.g postgres
  • integrating or opening up authentication to other auth server?
  • spring framework update? :)
  • 1.9.x → 2.2 migration strategy
  • MD: agree,  this is very important for Kenya.  We have many sites and have to do upgrades manually at each site,  so I am not sure I fully understand why this is not an issue?
  • Kenya is getting ready to invest time in this upgrade and my understanding is this is not trivial
  • Are we missing a simple strategy that we need to know?
  • SW: Extremely important to us
TODOs
  • TODO Burke will summarize & share with community
  • Invite Bahmni team to present their OpenERP integration as a form of billing support OOB for OpenMRS RA
  • Invite PIH to present "2.0-ified" appointment module for potential RA integration
  • Be explicit with an upfront process that will allow participants in this call know how their input will help determine what actually makes a release
  • After action review
  • Cancelled due to lack of interest in reviewing ourselves
  • What did you expect to happen?
  •  
  • What actually happened?
  •  
  • What can we do better?
  •  
  • Preview next week
  • WIP from Bahmni update on work their doing on top of the new order entry API in 1.10
  • WIP from Sara and ThoughtWorks on Concept Management Module
  • Showcase for Allergies

TODOs

Transcripts

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