How to Join

Click here to expand...

By Browser

https://www.uberconference.com/openmrs

By telephone

US telephone number: +1 201.479.2627

Agenda

Quickly review previous meeting minutes (5 min)
Enhancing the Platform (Hamish Fraser, Jan 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

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)

TODOs

Transcripts

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

Browser not supported