What's your vision for the OpenMRS Reference Application?

Community Leadership
21

As @mseaton suggests, I don’t think this needs to be an “all or nothing” choice. I do believe we need to be forward-thinking with technologies and I see a lot of promise in the REST + popular (non-OpenMRS-specific) front end technology (whether Angular, OWA, or whatever).

I don’t think this point can be overstated. One of the only reason OpenMRS exists is because of the modular architecture. Creating an application that is not modular would be a disservice to the community, IMHO. Whatever approaches we take, implementations need to be able to add or remove components to meet their needs.

22

@darius @lober @burke I have a question about the modern JS driven stack from the perspective of the end users, clinicians, and data entry people in the field who are comfortable with Facebook. How the modern stack hold up with field implementations that are in a low resource settings, with probably old computers running Windows XP and old versions of Firefox and IE 8,9 with little promise of upgrades and updates.

Will the new stack provide a seamless user experience within these constraints?

23

@darius we should continuously improve the end user experience! So going back to the old kings would not be forward thinking. But if we use the new technologies to build something that does not do what the old kings used to, then we are saving less lives instead of more! :smile:

1 Like
24

@dkayiwa @darius However the new kings today (2016) will be the old kings in 3-5 years to come (2020), so what comes around goes around.

What improvements can be made on the old kings to keep them relevant and adaptable in the new age, as they are not going anywhere.

25

I agree with Mike and Burke that it doesn’t need to be an “all or nothing” approach (with supporting HTML Forms) but we clearly need to define what the target requirements are. Does the “Ref App 3.0” need to support all (or at least the vast majority) existing HTML Forms out of the box? If not, then as @pascal and @arbaughj mentioned, this would be effectively end-of-life-ing existing implementations that rely on Html Forms, and I would suspect that 90% of those implementations would not upgrade to “3.0”. Whether this is a necessary trade-off to build a “modern” architecture can be debated–but I think we are kidding ourselves if we think we can make an “upgrade path” from Html Form Entry to another technology that would be good/reliable/easy enough for the average “!.0” user to be willing to attempt the upgrade.

Mark

1 Like
26

Good question. Using a REST API† + popular (non-OpenMRS-specific) front end technologies has several advantages, including allowing the front-end technologies to vary based on need (including supporting thick mobile apps), change as UI technologies evolve, and leverage popular frameworks (including Facebook’s React) that are far more likely to address browser compatibility & performance issues.

I am a big proponent of the Unix philosophy of DOTADIW. IMHO, the best way to “future proof” our tools is to focus them on doing one thing and doing it well. The extent to which those tools can “age well” will vary depending on the extent to which their “one thing” is abstracted from its dependencies.

We definitely need to provide a migration path. One relatively easy approach in a web-based world is to start out with supporting a “mashup” where HFE can run side-by-side. If we end up with an Angular Form Entry or similar replacement for HFE, then we’d need to find a way to make the translation as easy & painless as possible.

† By “REST API”, I’m assuming a REST API that represents an application API that encapsulates application business logic – i.e., not just reflecting database CRUD operations as REST resources – so any user interfaces built atop the REST API do not need to implement business logic.

27

I interpret you two as both saying “Upgrade Path for existing 1.x and 2.x reference appliation OVER modern tech stack.” Is that right?

1 Like
28

I think it is fine to have new forms technologies that may not do the majority of what the old kings used to, as long as there still remains a way of running them from within the new Ref App 3.0. This will strike the balance between having something new and better, but also with legacy support. When end users hear of new technology, they expect life to be easier and more exciting, instead of harder. :smile:

29

Addressing Paul’s questions…

I think we all want this to be implementer-driven; however, I’m not sure the same voices would design and prioritize. There are several factors at play:

  • What do implementations need?
  • What does the Reference Application need? (sometimes implementations will not prioritize something that is desperately needed – e.g., a modular infrastructure or a style guide)
  • Who has time/resources to do the work?
  • etc.

No such thing. If we re-visit our past discussions & lists of “complete EMR functionality” or grep these from existing standards/specifications, there’s certainly a base set of functions that everyone could agree on, but the definition of “complete” changes over time. Perhaps we could define completion by a metric like “>50% of implementations using OpenMRS are using the Community Distribution for patient care with minimal changes (e.g., adding an extra app here or there).”

Based on need. Just as is true for concept modeling, I’d assume these decisions would best be driven by a healthy compromise of pragmatism (what’s actually needed) and strategic planning (conventions over configuration, flexibility with good return on investment).

30

@janflowers, any chance you could bring some implementation/clinical opinions into this thread? What do implementations (beyond what we’ve heard from @mseaton, @mogoodrich, and @arbaughj) want from the OpenMRS Reference Application?

31

@darius and I ran into each other in the University district yesterday, had lunch and talked about… Guess what?!

One question he asked: If I want the reference app to be simple and accessible (and complete) - what prevents it from accreting so much functionality that it soon becomes both valuable, and too complex to serve as a “gateway” for new users. Good question.

My answer is that the RA should always be simple, the minimum set of functional example features needed to be what people think of as a simple EMR - keeping track of patients, keeping information about visits for those patients, and reporting (thanks @pascal - Darius and I did talk about that also). Those functions should be packed in an RA that is also secure, documented, and deployable by someone not familiar with a great deal of OpenMRS context. Taking advantage of the modular structure of OpenMRS, the RA should include instructions to… Replace the simple reporting features in the RA with a more complex and difficult to understand/use module, Modify patient demographics to reflect localizations. Modify visit data to reflect more structuring and complexity. Add features like decision support and order entry - presumably from a list of several choices - or develop their own modules.

The RA should not reflect a lot of assumptions about target facilities (mid-size district hospitals, for instance, are more complex than outpatient clinics), nor should it “grow” to add the complexity that many of the implementations need. So, the RA should not grow - but the ways to add functionality to the RA should multiply (and be clearly documented) as implementations develop these features.

My thought is that the RA should focus on the goals defined in this strategic objective

  1. a foundation on which platform features and architecture can be demonstrated.
  2. an entry level system to encourage adoption by NEW users looking for a functional, modifiable, minimal system to see a) that OpenMRS works, and b) that they can extend it both independently and (more important) by drawing on the community.

I’m not crazy about the RA 3.0 term, as part of our culture now is that we have to explain the “sync” in RA and platform version numbers. But, we need to call it something.

I used to think there were no resources at all for the RA - that it had to be agreement on a simple, common foundation, but now I see there’s a potential budget. That might change things.

Complete: see list above - complete to me means start to end minimal functionality (3 components of an EMR - patients, visits, reports), secure, reliable, documented, usable. It does not mean “a complete set of functions” - especially if that means those demonstration functions are not secure, not documented, …

New technology. An important thing to demonstrate is the client-side, JS, responsive design UI. I have no objection if old modules continue to run along side this, but I would think the minimalist “complete” UI would be angular JS or similar. And the entire minimalist UI should be responsive/small screen ready…

Out of time, and I’d rather keep this readable.

32

I’ll try for some more targeted responses.

@dkayiwa - I’d prefer an easy on-ramp for new users OVER legacy support (though I’m not opposed to legacy support, if it doesn’t get in the way).

@mogoodrich - as above - I think OpenMRS’s growth depends more on lowering barriers to adoption than on supporting existing implementations - not because I don’t think those implementations are critical, but because I think they are already motivated to move forward with more complex distributions based on specific organizational requirements.

@burke DOTADIW - agreed. I think the disagreement is on what that thing is. For me it’s expansion, growth, adoption by new implementers. But, by building simple, not by offering a toy (eg., toy hammer: a tool that looks like a hammer but can’t really be used to build a house)

@ssmusoke - re JS stack - Good question. Agree w/ Burke (who knows more than I do) and also would point out that responsive design to include more modern devices let’s us sidestep old systems. Not good to build to XP and IE 8, even if for now they remain common. We have the existing RA for that…?

@mogoodrich - I think I already expressed my rather cold-hearted preference of lowering adoption barriers for the (minimalist) RA OVER legacy support. That might not play well with the legacy implementations (but they are adults, and understand the value of building OpenMRS’s base).

@ssmusoke - old kings in 3-5 years. I agree. I’d look for the RA 3.0 to be the RA as long as JS-driven responsive design remains king, and I’d suggest abandoning that king when something new comes along (and not worrying about legacy support for it, either)

@burke @mseaton - @darius and I disagree on details but both would discard the Legacy UI and RA 2.x, I think, and have RA 3 be something with modern technologies. Darius favors Bahmni (I think), while I think it may already have enough assumptions built in that it is complex to assimilate. For me it’s an open question how complex it is, and how close to my version of complete deployability/usefulness (vs complete functionality)

@pascal - sorry I left out reporting!

That’s all for now - offline for travel the rest of the day.

33

To be clear, I do not think that Bahmni should be the Reference Application (and neither does the Bahmni team). Both should exist, as different products with different goals.

OpenMRS is a sprawling, loosely-coordinated, community, whose primary focus is openness. It has access to massive intellectual resources, but it cannot deploy them on a reliable timeline. Its comparative advantages are demonstration, starting point, exploration of the platform, and ability to focus on extensibility of building blocks.

Bahmni (a subset of the OpenMRS community) is a highly-coordinated team whose primary focus is building an easy-to-implement product. Its comparative advantage is building a polished product on a timeline via a professional software development lifecycle. (And other service providers and distributions will be similar to Bahmni in these ways.)

So my vision of the Reference Application is a combination of Burke’s and Mike’s, with the added point that we should not measure success based on the number of RefApp installations, but rather by how it makes the platform and other distros better by demonstrating best practices and driving the conversation. (So, to Paul’s question, the key stakeholder group is participating implementations + OpenMRS advisory team.)

We should let distributions and service providers choose different tradeoffs between extensibility/configurability vs packaging/polish for a particular use case. And the OpenMRS community should empower them to target the (much bigger) potential install base of people who want to use OpenMRS without being true open-source participants.

1 Like
34

Lots of very strong positives in Bahmni - the UI technology, the resources put into the effort, and the easy-to-implement emphasis.

Turns out that (to my surprise) our meetings start with transportation at 7AM tomorrow, so I’ll be on a bus getting oriented to federally qualified community health centers during the OpenMRS Leadership call tomorrow AM. I’m sorry about that - this is not a call I wanted to miss.

To summarize: I see the RA as a “gateway” RATHER than a tool primarily to demonstrate best practices and drive conversation among participating implementation and the OpenMRS advisory team. It’s not that I don’t think those later functions are necessary, just that I think we ALSO need an easier way to engage interested parties and help them become implementers. We’re not at the scale we could be. The best practices and conversation part will happen without the emphasis on the RA as an outward facing, accessible, gateway system. The outward facing, accessible gateway won’t happen as easily if the attention is focussed primarily on the existing implementations and advisory team.

But, I’m not the one to code a new RA, so in the end, it will really depend on who is willing or able to wrote a new RA, and what direction they choose to go.

35

I think I lean slightly toward upgrade path vs modern tech stack, but my main point is that if we as a community feel that an upgrade path is important, this needs to figure into the design early on, and not just “and, of course, we will need to give people and upgrade path”, because I don’t think it’s an easy thing to do.

Mark

36

@paul - I think you achieved your wish - some brisk discussion to highlight why it was difficult to claim clear consensus and move Strategic Goal #2 forward…!

To me it seems like the greatest difference is the vision of RA as (1) a path for upgrades/migration - aimed at supporting the existing community VS the RA as (2) something new - to demonstrate new approaches, to show new features, and to entice new implementers to the ecosystem. I think many of the other points are either points of agreement, or tactical approaches that derive from favoring either (1) or (2).

I think both are valuable outcomes - but as the loudest proponent of (2), I feel obliged to keep stating that argument until I’m sure that it is well understood, so if (1) prevails, at least it’s not without considering the implications of (2).

37

Hi everyone.

We had a nice conversation last Thursday about the goals of the reference application. I took a fair bit of notes during the conversation, and in an attempt to move us forward, I’d like to take a crack at defining some new conventions that attempt to summarize the various viewpoints expressed.

What I heard from the group was the following:

  1. There is a contingent that expressed the need for a flexible, modular, modern, extensible application framework that allows for important local customization.

  2. There is a contingent that expressed the need for a feature-rich, out of the box clinical application that “just works” and services the primary end-user audience of OpenMRS today.

  3. There is a desire by some to show the value of the OpenMRS platform through an example.

From my vantage point as project lead, the summation of the conversation described our Reference Application as an amorphous collection of goals that aren’t necessarily complementary. We seemingly have gotten our brains in a place where we believe we have to decide which of these goals we want to remove from a list. I’m not so sure that this strategy is the right one. Some of our bundling/debate around goals relates to the name “reference application”. I would strongly encourage you all to consider dropping that name altogether. So here’s what I propose:

OpenMRS Platform: The OpenMRS platform includes everything that we intend to release in our 2.0 release, but includes an additional presentation / user interface layer out of the box.

  • Target audience: developers and implementers who want to develop distributions or fit-for-purpose applications.
  • Descriptive characteristics: extensible, starting point for an implementation, pluripotent,

OpenMRS Community Distribution: The OpenMRS Community Distribution is a community developed, pre-configured application (complete with clinical concepts, forms, reports, etc) that fully leverages the OpenMRS Platform. It sacrifices customizability and end-user customization for quick, ready end-user consumption.

  • Target audience: end-users who simply want easy access to a functional medical record system and aren’t interested in deep customization or flexibility (i.e., those who care less about the value of a platform)
  • Descriptive characteristics: feature rich, polished, ready-to-use, great example of the power of the OpenMRS platform

This attempts to try to break apart the current notions of the Reference Application into perhaps more logical pieces. It essentially adds code and function into the platform, and allows the application that many have stressed has strategic value to simply be an application. :slightly_smiling:

Questions that this model raises for me:

  1. We’ve talked about componentization of application functionality. For example, Terry, Jonathan, and others have pushed for modular EMR functions. Part of that push is to stimulate the re-use of best practices by making these pre-configured modules readily available to implementers and developers, part of it was simple economies of scale. Where do these modules get released? I could see those being bundled/available in either my above new “platform” or “community distro”

  2. If we go down the pathway of making a real, pre-configured community distribution, how do we arrive at the target audience and how do we oversee requirement/user story work in a way that truly meets the needs of that target audience?

Thoughts/rocks are welcome. :slightly_smiling:

38

I’m the one most strongly pushing this viewpoint, and I stand by it. And I actually think you agree with me, Paul. Trying to build one product that has all the characteristics we want cannot work without exploding our resource requirements by 10x, so we should have an ecosystem of different products that target different goals. (Which is what you’re suggesting.)

I have one specific quibble that doesn’t invalidate your broader point:

There is value in having something that is truly the minimal back-end version of OpenMRS. This is what we’ve been calling OpenMRS Platform, and we shouldn’t change that. (We’ve shot ourselves in the foot enough times by repurposing names; let’s not do it again.) OpenMRS Platform 2.0 should be what we’ve been saying it’s going to be for the last year: Core + REST + FHIR.

We could then have another layer on top of this, which is what you’re calling OpenMRS Platform in your post, and we need to call this something new, e.g. OpenMRS Web Framework.

To summarize: I agree with the idea of splitting “Reference Application” into two different things, but one of those things should not be called OpenMRS Platform because that name means something else.

Now, a few more rocks… :slightly_smiling:

  • Building two products instead of one RA will require more resources, not fewer. Since our resources are limited, we still need to think about tradeoffs. Nobody should be under the pretense that “we’ll build a web framework and a community distribution” means that they’ll both move quickly/far in 2016.
  • This split doesn’t actually address the backwards-compatibility vs technically forward-thinking issue. (Providing a REST+OWA-driven starting point, while also prioritizing backwards-compatibility with OpenMRS 1.x and Reference Application 2.x is going to cost a lot of effort. )
  • “pluripotent” platform is easier said than done, especially when it comes to supporting people who don’t want to use CIEL-compatible concepts, or “can’t” because they’re locked into legacy concept dictionaries. I think that pushing for CIEL-compatible concept dictionaries in an opinionated way is one of the best things we’ve done in the 2.x reference application.

(I should make this shorter, but…well I’m the only response today, and it’s still <500 words.)

39

@paul,

I appreciate the direction your pushing, but I’m not sure it’s a naming problem.

Platform

Question:

What do AMPATH’s AMRS, PIH’s Mirebalais, Bahmni’s distribution, Haggstrom’s Cancer Patient Portal, CHICA, Regenstrief’s NCD, OpenMRS in Rwanda, OpenMRS in Philippines, Google and MSF’s Ebola solutions, someone downloading & running OpenMRS Reference Application 2.3, and every site that is or has been on the OpenMRS Atlas have in common?

Answer:

They all use the OpenMRS Platform. They may be using different versions of the platform, but they are all using a version of the same, shared platform.

The Platform is what we are all sharing – i.e., every implementation is running the Platform.

The platform can and should grow by incorporating more shared functionality (e.g., idgen), but I think the platform needs to remain what is actually shared. While this may include some UI elements, I think this is more likely to be module & OWA administration ± optional admin functions. I would love to find a way for everyone to share some basic UI (e.g., login screen, framework, style guide), the variation in UI technologies makes this trickier.

Reference Application

As far as the Reference Platform goes, I agree with @mseaton’s key insight:

The Reference Application needs to be modular.

Modularity (e.g. extension points in the UI, built to allow extensibility) was just as critical for adoption of 1.x reference application as modularity was for the platform.

Community Distribution

From my standpoint, a Community Distribution (the “complete” EMR) can be built on the reference application. Regardless, as @darius suggests, it’s going to take a large investment to make a complete EMR. If it’s not modular, then it will just be one more distribution alongside the others. If it’s modular (building on the reference application’s architecture), then there’s a chance other distributions can be created from it.

The Fundamental Issue

OpenMRS is a community of implementations.

We’ve been very successful by sharing a platform, but it’s not a surprise that we’ve hit limits on how much can be shared across all of our implementations. It’s also not a surprise, that a community of implementations has not prioritized nor had the luxury of spare resources to create a distribution that none of them are using in the hopes that it will get widely adopted.

If the community believes the best strategy for the community is to build a “complete” solution that many/most in the community will be able to migrate into, then we need to find the significant resources to make that happen (e.g., a development team of at least 8-10 people dedicated for 2 years toward this task). If that’s the case, perhaps this defines the operational plan for the Objective #2.

40

I really like a lot of what has been said here. A few comments:

  • We have historically tried to share more than the platform. The collection of uiframework, appframework, and uicommons modules represent our “2.0” effort towards an Openmrs Web Framework. I think most would agree that our custom GSP layer is not the strategic way forward for a 3.0 effort. But hopefully we can all agree on the value of this shared Web Framework. The level of backwards-compatibility / future support for the 2.0 framework can be debated, but I think this is independent of saying that this shared layer should be strategic for OpenMRS to move forward.

  • Perhaps we need to make a distinction between the “OpenMRS platform” as a discrete code artifact, and the “OpenMRS platform” as a strategic goal. Or perhaps we need another strategic goal. It would seem to me that, per the point @paul made, that the “OpenMRS Web Framework” might be a component that falls under the direction of strategic goal number 1. But to the point that @burke and @darius make, there is value in having this as something that is intentionally a separate artifact that runs on top of the OpenMRS platform of core+web services+fhir.

  • There may also be value in having us move the notion of the “OpenMRS Community Distribution” into Strategic Goal 3. So this strategic goal would be focused on supporting an ecosystem of distributions, one (or more) of which it was directly responsible for developing and releasing.

  • If we do the above, this would free up Strategic Goal 2 to focus on the ecosystem of reusable components, built upon the OpenMRS platform and OpenMRS Web Framework, where we would direct our collective domain and implementation expertise. This is the ecosystem within which all manner of components would exist, from GSoC projects to our community-built best practices for Order Entry and Allergies. The Community Distribution effort (under goal 3) would be focused on choosing a subset of these components and wiring them together into a coherent product, and would ideally enable customers to install other components within the “reference application component ecosystem” on top as desired.

If ultimately the community distribution isn’t able to be resourced sufficiently, that would be disappointing, but by decoupling it from the “reference application components” and the “Web application framework”, my hope is that we could make meaningful efforts on the building blocks that would go into it, and better support the ecosystem of distributions that others may create and support.

Mike