Vision for the OpenMRS Platform (as of 2017)

platform
platform-strategy
Tags: #<Tag:0x00007f23d9f443f0> #<Tag:0x00007f23d9f442b0>

(Burke Mamlin) #1

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).

We’d love to hear your thoughts & feedback on this vision for the Platform.


Platform 2.2 Planning
(Burke Mamlin) #2

This was discussed and action items created during our 2017-08-07 Design Forum.


(Mike Seaton) #3

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: Replace use of sqldiff with liquibase
  2. 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


Propose a Design Forum Topic
(Burke Mamlin) #4

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?


(Dimitri R) #5

Does this belong here too?


(Mike Seaton) #6

@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


(Burke Mamlin) #7

Awesome. I will propose the topic via 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.