Explanation of changes and strategy for OpenMRS 2.0 for press release

Hey everyone!

We’re finalizing a press release of OpenMRS 2.0 and we need to expand on a specific section to include more of a why and how. This press release will go global so we want to make sure we not only sound incredibly smart, but highly educational as well. Daniel has been helping me out a lot on this, but he has a lot on his plate already…

Can you please help me understand a section of text in our press release so we can better communicate it to the general public? Basically, if you can chip away at each one of the sentences and explain ‘what does this mean?’ and ‘why is this good?’ then that would be amazing! I’ll include each sentence in bulleted form below for convenience. If we can get this complete by this weekend that would be OUT-FREAKING-STANDING! Remember: what does this mean (layman’s terms) and why is this a good thing?

  • The release of Platform 2.0 solidifies the new technology stack of the OpenMRS Platform, including not only our custom Representational State Transfer API (REST), but also a Fast Healthcare Interoperable Resource (FHIR, pronounced ‘fire’) API and support for Open Web Apps (OWA).

  • FHIR support is critical to current and future work in interoperability. Our current FHIR work supports multiple DSTU2 (Draft Standard for Trial Use) resources and interactions.

  • OWA support allows developers to create and package new functionality using contemporary development tools like HTML5 and AngularJS. Support for allergies is now integrated into the Platform. The legacy user interface has been migrated to an optional Legacy User Interface module.

  • Platform 2.0 release includes significant upgrades to the tech stack, including Java 8, Hibernate 4.x, and Spring 4.x., as well as removing deprecated code from over the last ten years.

  • This ensures that we have a clean slate. OpenMRS Platform 2.0 ships with 201 bug fixes and 65 new features.

  • The OpenMRS Reference Application is a web application built upon the Platform and provides basic medical record system functionality.

Thank you for any time you can dedicate to this!

1 Like

@pascal if you think this would be appropriate to move in the Software or Development categories, can you help me move it there?

@jeffneiman who is the target audience for our press release? Other developers/technical folks? Participating orgs? Implementers? Funders? To drive new members to the community? This will change framing significantly for each of those… thanks!

Thanks for the post, @jeffneiman.

How does the optional Legacy UI Module work? How is it different from the current Legacy UI?

Which Rep App will come with it?

Hi Jan!

The primary publication will be Open Health News. I’m working with Roger Maduro on it and he specifically asked to elaborate on these sections. As for target demo, I’m not certain of that but after browsing their site, their articles are longer and more narrative style. And since he’s asking for expansion, I have to assume non-devs. If we use an abbreviation, we should spell it out and explain why it’s beneficial in lay-mans terms.

We should keep the current voice, but we just need to expand a little. Basically, we’re rattling off a bunch of cool features but we’re not explaining why they’re cool or how they help our platform. For me, this article should serve as a platform for OpenMRS to reach more non-devs, specifically funders and participating organizations. I would assume that implementers and developers can read between the lines already so they don’t need any explanation.

Sorry I can’t be of more help!


I’m sorry Ada, I can’t help you with your questions! You can read the full release here!

Are you able to help translate any of my original post?

I swear, in a few months time I’ll never need to ask these questions again!

Hi @jeffneiman,

Providing REST is a great step since it provides an interface that is “language agnostic”, meaning that any other system in a healthcare enterprise can talk to OpenMRS via this interface without having to write Java code and thus do not need to know much about the internals of OpenMRS code. REST interfaces are heavily used in all kinds of industries and gaining traction in healthcare as well (see FHIR and for example it has been added to DICOM webservices ; standard for storage & communication in imaging). It is very unlikely that OpenMRS will be the only software in a healthcare institution so it needs to ensure it has ways to talk to other systems (so it can for example be the single source of truth of patient demographic data and relay it to other systems). This is definitely the right way :slight_smile:

1 Like

Dude, you rule.

This is so helpful! This is exactly what I was hoping to get. Thank you so much!