Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS »
Discussion: OpenMRS Talk »
Real-Time: IRC Chat

Resources

Skip to end of metadata
Go to start of metadata

How to Join

 Click here to expand...

In person

Courtesy, please

If you are joining remotely via telephone, Adobe Connect, or Skype, please use a headset-microphone, or at least earphones. Please use the mute feature when you are not speaking.

Interactive meeting - Adobe Connect

  • We routinely share a screen during the call. You can view the screen via our Adobe Connect meeting room at http://connect.iu.edu/omrsdf. For large meetings, the room has the ability to broadcast audio and connect to a telephone-based system as well, as controlled by the meeting hosts.

By telephone

  • US telephone number: +1-888-510-4073
  • Access code: 24222#

By Browser

Chat/IRC

  • Chat is available in the Adobe Connect meeting room (see above).
  • A backchannel meta-discussion during the meeting also occurs on IRC.

 

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

Loading

Outstanding TODOs (0 issues)

Summary Assignee Created Due

Create a TODO: http://go.openmrs.org/todo

Transcripts

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

 

 
{"cc_re__cc_re__cc_by_4_0": ["ody\">\n<p><a href=\"https://talk.openmrs.org/\" class=\"external-link\" rel=\"nofollow\">Visit OpenMRS Talk, our community discussion hub.</a></p></div>    </div>\n</div>\n<div class=\"columnMacro\" style=\"width:25%;min-width:25%;max-width:25%;\"></div></div></div></div>\n\n<p>Copyright \u00a9 2004-2016 OpenMRS Inc. By using this site, you agree to the <a href=\"http://openmrs.org/privacy\" class=\"external-link\" rel=\"nofollow\">OpenMRS Privacy Policy</a>.<br class=\"atl-forced-newline\" />\nText is available under the <a href=\"https://creativecommons.org/licenses/by/4.0/\" class=\"external-link\" rel=\"nofollow\">Creative Commons 4.0 International Attribution License (CC BY 4.0)</a>. <br class=\"atl-forced-newline\" />\nSoftware is available under the <a href=\"http://openmrs.org/license\" class=\"external-link\" rel=\"nofollow\">Mozilla Public License 2.0 with Healthcare Disclaimer (MPL 2.0 HD)</a>. <br class=\"atl-forced-newline\" />\n\"OpenMRS\" is a registered trademark and the OpenMRS graphic logo is a trademark of OpenMRS Inc.</p>\n        </div>\n    \n    </div>\n</div>\n\n\n        \n            \n\n<div id=\"footer\" ro"], "copyright__copyright__copyright": ["nated about technologies (think standalone of docker containers), this might be easier\n  \u2022 Need to focus more efforts on making the API (REST & Java) more robust\n  \u2022 UI technologies move too fast for the community to keep up.\nNext week dev forum: OpenMRS JS w/ Pascal (+1)\n\nTODOs\n\nLoading\n\nOutstanding TODOs\u00a0(0\u00a0issues)\n\nSummary Assignee Created Due\n\nCreate a TODO: http://go.openmrs.org/todo\n\nTranscripts\n\n  \u2022 Audio recording of the call: Listen online or download (available after the meeting)\n\n\u00a0\n\n\u00a0", "nated about technologies (think standalone of docker containers), this might be easier\n  \u2022 Need to focus more efforts on making the API (REST & Java) more robust\n  \u2022 UI technologies move too fast for the community to keep up.\nNext week dev forum: OpenMRS JS w/ Pascal (+1)\n\nTODOs\n\nLoading\n\nOutstanding TODOs\u00a0(0\u00a0issues)\n\nSummary Assignee Created Due\n\nCreate a TODO: http://go.openmrs.org/todo\n\nTranscripts\n\n  \u2022 Audio recording of the call: Listen online or download (available after the meeting)\n\n\u00a0\n\n\u00a0", "nated about technologies (think standalone of docker containers), this might be easier\n  \u2022 Need to focus more efforts on making the API (REST & Java) more robust\n  \u2022 UI technologies move too fast for the community to keep up.\nNext week dev forum: OpenMRS JS w/ Pascal (+1)\n\nTODOs\n\nLoading\n\nOutstanding TODOs\u00a0(0\u00a0issues)\n\nSummary Assignee Created Due\n\nCreate a TODO: http://go.openmrs.org/todo\n\nTranscripts\n\n  \u2022 Audio recording of the call: Listen online or download (available after the meeting)\n\n\u00a0\n\n\u00a0"]}