2016-05-26 Developers Forum

• Quickly review previous meeting minutes (5 min)

• Enhancing the Platform (@Hamish Fraser, @Jan Flowers)

• Review next meeting agenda

Attendees

 - Pascal

 - Vinay

 - Daniel Kayiwa

 - Sushma Rao

 - Darius

 - Jamie Thomas

 - Srimaurya Kummamuru

 - ekruB

 - angshu

 - ada

 - Wyclif

 - Shekar Reddy

 - Jan Flowers

Agenda/Notes

Enhancing the Platform <https://talk.openmrs.org/t/how-do-you-think-the-platform-should-evolve/6403>

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)

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