Thoughts on objective 1 presented last week by Burke

Community Advisory Council
1

(I am hoping that @burke is in this list)

We had a busy call. I wanted to talk about a few things related to what should OpenMRS as a platform focus on next.

While I do understand that moving up the technical stack and providing more above the layer of REST API seems one possible thing platform could do. e.g. Providing reusable web components which can be used by different front end applications developed by different products. I do not like this idea for couple of reasons:

  1. It starts to bleed into objective 2 (reference application). I know the distinction between platform providing reusable components and reference application being a complete application; but it does feel like duplicating work. Even if we go this route objective 2 team would be more suited to develop reusable web components rather than objective 1.
  2. While reusable web components in theory sounds like a good idea, lets look around, has this been done successfully by many people? UI and reusability has not gone well together in general in the industry.

Instead I believe that we have unfinished business below the API layer, on the server side in OpenMRS. I strongly feel we should focus on that and improve our offering there. Concretely I have following in my mind. (I am keeping in mind our goal of “being a individual’s medical record system” - paraphrasing what I think Burke mentioned in the call too)

  1. Scalability - I feel OpenMRS should cater to much bigger volumes of data that just for a single hospital. It should almost be horizontally scaleable by adding more hardware. Even for the volumes that it manages, the reporting runs much slower than we would expect in 2016. This would help create new kinds of work done on top of OpenMRS. (Technical I think we have a small :slight_smile: problem in this area. This boils down to Obs table. While this was the appropriate way of solving the schema less problem, today we have better options, even in traditional databases like Postgres with JSONB support. Don’t want to do in much detail here.)

  2. Support multi-tenancy (hope this is obvious)

  3. Allow more than one application server in front of the database at a time in production.

  4. We should perhaps provide more types in the core domain than we do today. e.g. We should have diagnosis as an entity in the system; we should support referrals better; lab results, etc. To me it feels like FHIR has more types than OpenMRS. Without these types we are dependent on different implementations layering their own schema on top of Obs table. Obs has become a platform.

  5. We perhaps should also provide good user interface for managing the master data in OpenMRS as part of the platform as a product.

  6. We can perhaps look at some of the backend contrib modules which are used quite frequently and should include them in platform add-on distribution.

  7. We should provide better support for infrastructure tools that is showing up in the industry like docker.

Best

5 Likes
2

This can be done using docker :slight_smile:

@pascal did a lot of work on dockerizing OpenMRS. We should work on getting those repos under the OpenMRS GitHub org.

3

Seems to be in line with this from wikipedia:

The costs of redesigning applications for multitenancy can be significant, especially for software vendors who continue to offer an on-premises single tenant version of their product. They end up being forced to support 2 distinct products with all the resulting costs.

An increasingly viable alternative route to multitenancy that eliminates the need for significant architectural change is to use virtualization technology to host multiple isolated instances of an application on one or more servers. Indeed, when applications are repackaged as virtual appliances the same appliance image can be deployed in ISV hosted, on-premises or trusted-third party locations and even migrated from one deployment site to another over time.

1 Like
4

That’d be my thinking exactly. Docker is a type of virtualization which uses the same kernel as the host. My thinking is that each instance of OpenMRS runs in a docker container and is completely separate. You are really just spinning up a docker image when somebody requests an instance. Easy peasy. We’d need to think about scaling issues. Docker has that baked into 1.12(not yet released)!

1 Like
5

@r0bby, @dkayiwa, without expressing an opinion either way on multi-tenancy +/- docker, I would ask us all to keep this thread focused on high level strategic vision appropriate to the high-expertise-but-lower-engagement “Advisory Council” audience, and not go too far into specific technical points.

@petmongrels, this is very interesting and helpful.

Maybe another angle on what you’re saying here is that:

  • There are certain core issues that can only really be solved centrally (e.g. scalability, modern reporting/BI approaches, and the core domain model), and OpenMRS’s strategic objective should be to solve these things.
  • If we focus “platform” strategic energy on reusable web components, this distracts from what can only be solved via central coordination around the platform.
2 Likes
6

+1000 @petmongrels! Thank you so much for sharing these thoughts.

Agreed. We started with Objective 1 focused on a Platform that was largely UI-agnostic. This is my preference as well. Others wanted to consolidate the efforts of creating shareable components into the Platform. Like you, I see a lot of challenges in sharing in the UI layer. That said, when we have shared parts of the UI, there have been enormous benefits (e.g., sharing modules, promoting best practices, making it easier for folks to build from the same base). In my opinion, there might be a middle-ground, where the Platform enables some level of collaboration in a UI space – e.g., generic JS libraries, OWA+module mgmt+admin features done in a way that is extensible & demonstrates best practice.

+1000. I’ve been voicing concern over this for a few years. The good news (or bad news, depending on your perspective) is that we haven’t had implementations hitting this issue enough to move this forward. I would love to work with others to design a strategy for clustering.

This has been on the wish list for a long time. We have the tiniest of beginnings of this with the introduction of care settings within the order service. This is a big job, since nearly every aspect of the API will need to be able to filter/combine data appropriately.

I think this is closely related to the first item – i.e., being able run multiple instances against the same data is a path to scalability (being able to grow as needed via more hardware).

Couldn’t agree more. We’ve had efforts toward these over time, including Conditions. But they fell short when implementation priorities changed. One of the fundamental goals in Objective 1 is to position the OpenMRS development community such that implementations can add to, influence, and enhance an ongoing development process & road map.

Agreed. As I mentioned up front, I think this can not only provide basic administrative functions out of the box, but also serve as an example of how to build UI components against the platform.

Agreed. This is one of the primary intents of Objective 1.4.

Amen! I watched Atlassian’s standalone grow from a toy to their primary approach to production. In that process, they were able to be more proscriptive & flexible with the internal structure, since there were fewer expectations placed on clients. I also wonder if we could migrate toward a microservice artchitecture, where each service has explicitly declared responsibilities in terms of delivering results in a scalable way (i.e., respond to batch requests against large datasets with sub-second response time, conventions across services for paging, linking, extending, authentication, etc.).

2 Likes
7

Interesting to read this again, after 6 years, and compare with where we are now. :slight_smile:

cc @burke @ibacher @grace @dkigen @raff

3 Likes
8

Not that everything is where I would like it to be and—leaving aside multitenancy, which is complex—it does seem like we’ve made some real strides towards these goals over the past few years. One thing I’m hoping from this year’s in-person conference is to see if we can make some concrete steps towards articulating what the vision of OpenMRS should be—and what we should prioritise for the next 12 months or 5 years…

2 Likes