You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 7
Next »
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 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
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
- 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
- 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!
- 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)