# Vision for the OpenMRS Platform (as of 2017) **URL:** \ **Category:** Development\ **Tags:** platform-strategy, platform\ **Created:** [July 24, 2017, 4:04pm UTC](https://talk.openmrs.org/t/vision-for-the-openmrs-platform-as-of-2017/12540 "2017-07-24T16:04:26Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![burke](https://talk.openmrs.org/user_avatar/talk.openmrs.org/burke/32/17_2.png) [@burke](https://talk.openmrs.org/u/burke)\ **Post date:** [July 24, 2017, 4:04pm UTC](https://talk.openmrs.org/t/vision-for-the-openmrs-platform-as-of-2017/12540/1 "2017-07-24T16:04:26Z")
The OpenMRS Platform underlies every implementation of OpenMRS. We, as a community, have committed to releasing new versions of the platform _at least_ once per year. So, where should we go with the OpenMRS Platform? Here is a vision for the Platform. In summary: #### 1. Maintain one Platform for all needs Implementations & distributions may build completely different solutions using the platform, but we continue to all share the same platform. - If something is not used by the vast majority of implementations/distributions, it probably doesn’t belong in the platform. - Limiting the Platform to widely shared components decreases the chance of organizations needing to run a custom version of the platform and, thereby, maximizes the opportunities for collaboration. - The Platform should expand to include widely used services that are not currently part of the Platform. #### 2. The Platform is the back-end. Other than basic admin functions (e.g., module & OWA management), the Platform should focus on back-end services and not trying to provide a user interface. - While we are creating OWA versions for most admin functions, the majority of these would be bundled in the Reference Application or easy additions to the Platform and not bundled with the Platform. #### Next steps Given this vision, the goals for 2017 would be to incorporate a couple key services that most everyone is using into the Platform (e.g., ID generation and selected features from the EMR API module to start). > **[Platform Vision (2017)](https://docs.google.com/document/d/1klnOwwku_eux42xXFVCTpSiQSWkBZkJC3Ui6fLd93ZY/edit)** > > We believe health informatics technology has a critical role in improving health in low and middle income countries and, instead of a “once size fits all” approach, meaningful solutions require systems that can be adapted to meet local needs. We... We’d love to hear your thoughts & feedback on this vision for the Platform. ---
**Author:** ![burke](https://talk.openmrs.org/user_avatar/talk.openmrs.org/burke/32/17_2.png) [@burke](https://talk.openmrs.org/u/burke)\ **Post date:** [August 14, 2017, 3:19pm UTC](https://talk.openmrs.org/t/vision-for-the-openmrs-platform-as-of-2017/12540/2 "2017-08-14T15:19:47Z")
This was discussed and action items created during our [2017-08-07 Design Forum](https://notes.openmrs.org/2017-08-07-Design-Forum). ---
**Author:** ![mseaton](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mseaton/32/8088_2.png) [@mseaton](https://talk.openmrs.org/u/mseaton)\ **Post date:** [August 14, 2017, 3:45pm UTC](https://talk.openmrs.org/t/vision-for-the-openmrs-platform-as-of-2017/12540/3 "2017-08-14T15:45:33Z")
Sorry I missed this meeting - would have been good to be there for it. Regarding incorporating idgen into the platform, I’m all for it and agree the easiest path for compatibility would be to simply bundle the module. There are 2 primary issues that need to be taken on before this is something we can consider: 1. [IDGEN-33](https://issues.openmrs.org/browse/IDGEN-33): Replace use of sqldiff with liquibase 2. [IDGEN-42](https://issues.openmrs.org/browse/IDGEN-42): Add web services for all API functions Both of these have some history of having been worked on, but not finished, due to design discussions or technical issues that came up and were never resolved while the original developers were still around or interested in continuing. My recollection of the Bahmni module is that is was too tied to the specifics of how Bahmni uses IDGen and not general-purpose enough, but a lot of time has passed since that initial attempt, so things may well have changed. I’m happy to be involved in these tickets, if we can prioritize them for community development. Thanks, Mike ---
**Author:** ![burke](https://talk.openmrs.org/user_avatar/talk.openmrs.org/burke/32/17_2.png) [@burke](https://talk.openmrs.org/u/burke)\ **Post date:** [August 16, 2017, 1:56pm UTC](https://talk.openmrs.org/t/vision-for-the-openmrs-platform-as-of-2017/12540/4 "2017-08-16T13:56:48Z")
Thanks @mseaton. What do you think would be the most effective way to move this forward? Perhaps a design forum discussion after which we could assign tasks? If so, then do you think we should have separate calls for each of these tickets or have one call for both? ---
**Author:** ![mksd](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mksd/32/11729_2.png) [@mksd](https://talk.openmrs.org/u/mksd)\ **Post date:** [August 16, 2017, 2:45pm UTC](https://talk.openmrs.org/t/vision-for-the-openmrs-platform-as-of-2017/12540/5 "2017-08-16T14:45:39Z")
Does [this](https://talk.openmrs.org/t/openmrs-plans-ideas-3-0-0/12868/3) belong here too? > [@](#): > > Enable I18N support for metadata names and descriptions (on the model of what’s done with the `Concept` class). ---
**Author:** ![mseaton](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mseaton/32/8088_2.png) [@mseaton](https://talk.openmrs.org/u/mseaton)\ **Post date:** [August 16, 2017, 4:10pm UTC](https://talk.openmrs.org/t/vision-for-the-openmrs-platform-as-of-2017/12540/6 "2017-08-16T16:10:02Z")
@burke, sounds fine to try to bang this out during a design forum. I say we try to accomplish both in the same call - we can always re-visit later if need be. Mike ---
**Author:** ![burke](https://talk.openmrs.org/user_avatar/talk.openmrs.org/burke/32/17_2.png) [@burke](https://talk.openmrs.org/u/burke)\ **Post date:** [August 16, 2017, 4:18pm UTC](https://talk.openmrs.org/t/vision-for-the-openmrs-platform-as-of-2017/12540/7 "2017-08-16T16:18:31Z")
> [@mseaton](#): > > @burke, sounds fine to try to bang this out during a design forum. I say we try to accomplish both in the same call - we can always re-visit later if need be. Awesome. I will propose the topic via [om.rs/designtime](http://om.rs/designtime). I’m assuming we need – at a minimum – Darius, you, and myself for the discussion. Please let me know if there is anyone else who is required to be available for scheduling the discussion.