2016-05-26 Developers Forum

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)
  • Enhancing the Platform (Hamish FraserJan Flowers)
  • Review next meeting agenda

Minutes

Attendees
 - Pascal
 - Vinay
 - Daniel Kayiwa
 - Sushma Rao
 - Darius
 - Jamie Thomas
 - Srimaurya Kummamuru
 - ekruB
 - angshu
 - ada
 - Wyclif
 - Shekar Reddy
 - Jan Flowers
Agenda/Notes
What should we be doing?
How should we be working?
Want to create an architectural review board to get key stakeholders and technical advisors to provide a sounding board for the platform.
"Platform" background
  • "Core" started as just API on top of database
  • Added REST and called it a "Platform"
  • Added FHIR (other web services) and planning on adding other "infrastructure" modules
  • As of OMRS15 and in 2016, we plan to include OWA & module management
  • Per operational plan CY2016, we would like to take platform into covering "re-usable web components" (building blocks)
  • Need to cover more aspects of medical domain
  • For example: Episodes of care, Order Sets, Care Plan, ...
  • And broadly: decision support
  • TODO: road map or prioritized list for clinical domain components
  • Adopting standards/conventions
  • Make it easier for people to adopt & adapt
  • Integration efforts (labs, PACS, etc.) ... maybe not as part of the platform?
  • Is this supposed to be more about the standards/conventions being available for those integrations?
  • Bring more commong tooling into the platform
  • OCL Subscription, metadata management
  • Focus on finding things that are already being done and focus on bringing those into the community
  • The consumer of the platform is someone who...
  • wants to build a custom implementation of OpenMRS
  • needs an EMR backend for their project (supporting building apps in any technology)
  • ...
  • OpenMRS should become the de factor platform for EMR development ("the 'angular' of EMR development)
  • OpenMRS is too monolithic
  • Might benefit from a more microservice approach
  • Would benefit from being more Spring-like or JQuery UI-like (i.e., let people choose which pieces they want to bundle)
  • How can we consider alternate storage systems or other ways to scale
  • Amount of data
  • Reporting
  • Multitenancy
  • Don't discount server-side technologies (e.g., JSP and GSP pages have sustained OpenMRS)
  • Where is the boundary between the platform and the reference application begin?
  • When you're building a "web application" (an EMR), you're in the reference application
  • We don't want to squash innovation – there will always be implementations who want to do their own thing
  • Two implementations doing something cool is the place to start
  • From 1 to 2 is 3x effort, from 1 to n is 9x effort (ref: Mythical Man Month)
  • Community focuses on the "getting from two to three+"
  • Soften the barrier between "being OpenMRS" vs not – i.e., allow anyone to work on something and get more visibility ... things don't need to happen centrally
  • Innovation on the ground
  • Angular 1.x is the most common tool used, but not the long-term solution
  • Platform should only cover part of the stack
  • "When I think about the Platform, I think of an EMR API."
  • Platform should support more EMR things (more resources)
  • The Platform should not say "you need to use this technology"
  • Updates need to be easier!
  • Simple upgrade path
  • If the platform were more opinionated about technologies (think standalone of docker containers), this might be easier
  • Need to focus more efforts on making the API (REST & Java) more robust
  • UI technologies move too fast for the community to keep up.
Next week dev forum: OpenMRS JS w/ Pascal (+1)

TODOs

Transcripts

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