An amazing future for OpenMRS

thanks @dkayiwa this is encouraging #java

Thanks @burke for your leadership in getting this started. This has spurred a great conversation and our team at PIH is fully on board with this vision.

At PIH, we have long invested in building shared, configurable modules and applications. This is core to what we need to do, as we support many different implementations in a number of countries. Sharing as much in common, while leaving room for necessary customization, is essential. Today, we are experiencing the same major shift as many others - towards a need for more point-of-care utilization and for our applications to work seamlessly and efficiently across devices (i.e. laptops, touchscreen computers, tablets, etc), so this is a very relevant and timely discussion.

We have done our best to hack in this direction over the past year or so already. Taking a cue from the community, which had started adopting React as a new standard front-end technology for OpenMRS (Andela, Bahmni, etc), the PIH team re-tooled in an effort to collaborate in this way and to build features that are “distribution-agnostic” and which meet two of PIH’s roadmap priorities - 1. lab test ordering, basic lab tracking, and lab results entry, and 2. point-of-care screening application for a combined HIV/NCD clinic. Our approach for this has been to lead the development on a shared library of UI components built in React, and to model how these can be leveraged to quickly develop new applications, putting as much functionality as possible into the common library, fittingly called openmrs-react-components.

This has been modestly successful, but I’d say that it has not yet met our full ambitions. This is due to a host of factors, but chief among them is lack of deep expertise in React and in responsive CSS design with Bootstrap or a similar framework. This is where I believe we really need that “expert coder” that you describe to “bootstrap development”, primarily in these new technologies. It is essential that we invest in a resource that we confidently feel will get us established in the right direction and make it easier for teams to collaborate using existing code than to go their own way.

PIH will continue to invest strategically in these initiatives and the more traction and collaboration ensures, the more investment is possible. It would be great to hear more about plans to

and what we need to do to get this underway.

Best, Mke

4 Likes

Maybe I’m being a little overdramatic, but this thread feels like a very important moment in our community’s history to make our collaboration deeper and more powerful. This of course strengthens our public goods.

It’s very exciting!

I believe a few things are being said here:

  1. While there is always room for improvement, the focus of Burke’s vision here is less on the core platform and more on the user experience: the web application itself.
  2. Multiple organizations are interested in being a part of this activity and have weighed in here, but there’s consensus around starting small and working our way towards larger and more sophisticated.
  3. There’s a need to discuss how this effort is resourced: but the consensus seems to be around a hybrid model of combining in-kind engineering/management effort from large implementations alongside new resources working alongside those “close the the ground”.

I think there are more than enough organizations that have “raised their hands” here to get things started. Let’s not waste any time: @burke, @jennifer, @terry… how should we proceed, and how can we all help? :slight_smile:

4 Likes

Hi - can a design call be arranged? I’ve been working on new mockups specifically focused on a very simple and highly composable EHR application. It fits Paul’s description of something small that could grow into something larger later.

The mockups could be presented as a strawman, and act as a starting point for conversation to see how much/and how little they solve real world needs for the implementors in this thread.

In a little less than a week, this discussion underscores how much rich experience and knowledge we already have within our own community to draw from. Another reason the future holds so much promise!

Based on this discussion, I suggest that we begin by convening a small group with representatives from each interested organization. This small group that can continue this exploration and lay out what we’d like to see in a MVP that will help us achieve our goal: an extensible, customizable web application framework that supports future development by existing and new implementations. Part of this will mean:

  • identifying specific needs and priorities across countries/implementations
  • deciding what components we can and want to re-use
  • determining what components we may need to add

@gschmidt, I like your suggestion of using your new mockups as a strawman to see what most resonates with today’s implementations. Our Design Forums are currently underutilized and we can easily dedicate one of them as a space for these ongoing discussions. Can you please propose this as an initial topic in the Propose a Design Forum Topic thread and we’ll poll everyone to determine the best day/time?

Much of this will help us work out an estimate of the level of effort/resources needed and put together a strong, well-rounded team who can help get this off of the ground. From a fundraising perspective, it would be ideal to have a pipeline of "projects" ready to go that could be used to inform proposals and ongoing discussions with donors and emerging countries - perhaps helping to re-think "the global approach to sustainability and maintenance of these global goods and support from implementations," as @chris so very nicely put it.

Over the next two weeks, let’s plan on laying out an initial action plan that also includes time and space to tackle other questions that have been raised around roles and responsibilities, resource allocation, processes, and migration paths. Please feel free to chime in with any additional considerations and actions. @burke @terry

3 Likes

Burke:

Thanks for starting this great conversation that marks another extremely important milestones in the life of OpenMRS - and its truly amazing and humbling to be part of this history making experience.

As we continue discussing details and next steps as you have suggested, I would like to offer ourselves, IntelliSOFT, as one of those 203 groups ready to participate and contribute actively on making this process work. We have and continue to invest in both Bahmni and RefApp and therefore have lots to contribute in this collaborative effort.

Very excited to be part of this, thank you and let us do this!

1 Like

The most important first step

Identify at least three organizations with:

  1. A shared problem to which a separate web application could be applied
  2. At least 1-2 developers who could be directed to work on a solution
  3. A commitment to work collaboratively toward the solution (i.e., put in the extra effort approach the solution generically instead of cutting corners)

I would guess a progressive point of care solution (i.e., works well on mobile or desktop) that could be applied to NCDs or HIV would be the most likely candidate; however, it’s more important to have 3+ organizations with a shared problem than to pre-select the problem to solve.

As an example, imagine if PIH, Jembi, AMPATH, and one or more ministries (e.g., Nigeria, Kenya, Mozambique, Uganda, etc.) decided to commit 1-2 developer(s) toward collaboratively building a point of care solution that would meet their needs. In turn, the community would commit its energy (bringing leadership, a react guru, project management, additional development, etc.) toward making the effort amazingly successful. In the end, we would have a frontend to serve us for the next 4-5+ years that could not only run alongside RefApp or Bahmni, but, with a clear migration path, serve as a point of convergence for those efforts.

Additional initial steps (could be done in parallel)

  • Identify a React guru (i.e., experience in building best practice enterprise-quality frontends and expertise in ) who can help us decide on the best option(s) for modularity †, build the skeleton + some initial functionality, and run a bootcamp to get community developers productive quickly.

  • Design discussions to flesh our requirements and build a common vocabulary (as @gschmidt has proposed); however, it’s hard to proceed too far before we know what problem we are trying to solve – i.e., step #1 is having 3+ organizations committed to solving a particular problem collaboratively and this problem needs to be an actual problem they need to solve (not necessarily the problem we want to solve). That said, in meantime, the vision Greg & Jonathan are creating can both (1) drive us toward convergent design & vocabulary and (2) provide a shared “north star” for the community (i.e., where we want to be eventually).


† For example regarding modularity, is there a way to leverage HMR for production use without adding too much complexity for the developer or overhead/risk for the implementer? Or are we better off using the SDK or other tooling to automate redeployment of the frontend when modules are added/removed?

3 Likes

@burke, though I agree with the process of you’ve outlined (though would suggest not being so dev-centric), you’ve mentioned in your additional steps the need to find a React guru. I recognize our bias given we have invested a lot in Angular, but it’s not clear to me why React is the de facto framework of choice.

I think a bigger question to consider is the “glue” that the webapps will be using. We specifically chose angular because it’s a comprehensive framework. We have a single web application that widgets (written in angular) are imported into. I think this is an advantageous approach for reasons we can discuss on another forum. If we proceed using a model similar to OWA’s, which are essentially embedded within the java servlet/tomcat application, then it may make it either easier to be framework agnostic or perhaps react is more appropriate. I worry though that this firs step is not drawing the attention it deserves when considering the framework of choice.

It may seem like this is getting too much into the weeds but I believe this question of “glue” (I can’t think of a better term) needs to be addressed first before other work proceeds on building any applications. There are a lot of implications in terms of routing, state management, low level libraries to interact with the rest api, offline support, and many others which I believe need to be considered before embarking down a particular pathway. Migrating from an existing way of doing things to a new model will not be a straightforward process for any implementation.

I suppose that this group of key stake holders could meet first to decide these questions and then once a framework is settled upon and approach to design, we then look for an expert in that domain to help guide us along.

JJ

4 Likes

@jdick that makes sense… I do think that whatever path is chosen a key goal is that it needs to be able to “play nicely” with other components… ie, integrate the new functionality into their existing app, whether that be Ref App, PIH EMR, or AMPATH…

Great to see these ideas continue to evolve. I agree that at this point we need to start building out a framework in a few dimensions:

  • UX and higher-level workflow (keying off much of what @gschmidt has been doing)

  • core technologies (discussed a lot by @burke and within this thread),

  • in the middle, clinical/functional business components (some of what I have been trying to contribute, as well as ongoing projects from PIH and others).

  • Also, community roles and resources (discussed in Nairobi, and at some recent OpenMRS ops&strat meetings).

As several have said here, we should have a starter project that lets us explore the real needs and possibilities in these areas, and use that as a point for branching out to the greater plan. NCD/HIV has been suggested many times and has people from several groups working on it, so that ought to be one. The other could be another application like the results viewer, or a lower-level piece such as FHIR services, or otherwise.

I’m looking forward to working with a team to get this moving. One thing we need to do is have a base for discussion and action. I’d be glad to see a weekend face-to-face retreat if that were feasible. Other than that (and certainly easier to schedule), perhaps we could use the often-underused Monday design meetings as a regular home for this?

Again, a lot of great ideas on a number of critical points. I’m taking note of them so that they don’t get lost in the shuffle - and to make sure we take action in good time. Keep an eye out for a post later this week on our action item/plan - and

We have a good lead on a meeting time: Monday, April 1 at 7pm Nairobi, 6pm Cape Town, 4pm Accra, 12pm Boston, 9am Seattle. We’ll update the OpenMRS calendar and include our key stakeholders (and/or representatives) on the invite list.

During that meeting, @gschmidt will present his strawman/mockups and we’ll see what shared problems a web application framework can address. In order to use our time efficiently, come with your top 3 problems/needs in mind.

@burke @jdick @mseaton @mogoodrich @chris @jteich @dkayiwa @bistenes @k.joseph @c.antwi

1 Like

hi, we can get this recorded, i will review afterwards having another meeting within the same hour. thanks

3 Likes

Hi everyone,

I haven’t been posting actively on this forum but I’ve really enjoyed following the recent ‘future of OpenMRS’ discussions—the way this community dreams together is inspiring. A few of you probably remember that my co-workers at Medic Mobile and I developed an OpenMRS messaging module back in our early days. Since then we’ve been building and implementing the Community Health Toolkit with a focus on mobile and using couchdb/pouchdb to address connectivity issues, but I always hoped there’d be a way someday for us to re-engage with the OpenMRS community. CHT-OpenMRS interoperability is a super high priority for us because we need to be able to integrate care experiences from the community to hospitals (especially in the places where we’re already working with PIH and other OpenMRS implementers). We were hacking this at the last OpenMRS meet up and Patrick’s suggestion of OpenMRS as FHIR server is appealing. More than that though, it would be a dream for me if we could share technical components with the wider OpenMRS community.

The Community Health Toolkit is a collection of open source tools and resources, including a highly configurable application framework for building responsive, offline-first community health apps. The framework has support for implementing longitudinal health records, workflow-based decision support, interactive messaging, task and schedule management, and analytics. It was originally written in Angular.js and we’re in the process of upgrading to the latest Angular (and we seriously considered React). We’ve made the process of building and maintaining custom apps dramatically simpler by enabling app developers to write (testable, version controlled) JavaScript, XForms, and JSON to configure the framework’s core features to run in a specified manner. You can read more about that here: https://github.com/medic/medic-docs/blob/master/configuration/developing-community-health-applications.md

We have a dozen developers on the core framework team, in addition to the larger number of tech leads who use the framework to build custom apps with specific implementing partners. Other organizations like D-Tree, Living Goods, and Partners in Health are doing their own implementations and hiring developers to support them. Medic Mobile also has fourteen people (including me) on our design team, and I wonder if UI/UX/Service design is a particular area where our team could contribute. How much we could contribute to shared OpenMRS needs depends heavily on whether we could identify a viable technical architecture with enough overlap in our community’s existing roadmap and what the folks on this thread need.

Identifying that opportunity for overlap is beyond my technical imagination/skill. Maybe we could help solve some of these problems, maybe we just participate enough on architecture discussions so that interoperability is way easier and the CHT provides another front-end option for OpenMRS implementers, or maybe we just contribute some designer cycles as a gesture of solidarity. Regardless I wanted to say that I have immense respect for what you all are undertaking here. What might we be able to do to help?

5 Likes

Welcome to the conversation - and you are already helping by sharing what you have been working on and these initial ideas about where you think your team may be able to pitch in. Keep doing this! And part of the beauty of our community is that we all bring different strengths to the table, so I trust that someone will speak up when they see “that opportunity for overlap.” :slight_smile:

1 Like

Update: We were able to confirm availability of a few additional people over the past couple of days. As a result, @gschmidt’s strawman UI/UX presentation and discussion will take place on Tuesday, April 2 at 9:30pm IST/7pm Nairobi/6pm Cape Town/4pm Accra/12pm Boston/9am Seattle.

Following the forum, we’ll post the recording.

1 Like

Jen, is this instead of the Monday scheduled time as noted above, or is the Monday discussion taking place as well? (Hoping for the latter, as I currently have a conflict with the Tuesday time, but majority should rule)

Yes, this is instead of the Monday time. The Monday and Tuesday 12pm EDT time slots were both popular, with a few key people either only available on or preferring Tuesday. It would be great if you (and anyone else) can share questions or specific points you would like to make ahead of the call. And we’ll make the recording and notes available.

Moving forward, I think we can keep both slots “in reserve” and choose from them depending on the topic that needs to be discussed and who is essential to the discussion.

I moved some things around – this is important! Going forward, I’m hoping we can set a regular weekly time (and a regular active team) to keep this moving.

1 Like

Hi - attached is a short concept paper (5 min read) to help with today’s Design Call.

1 Like

thanks a lot everyone who joined the call, about the next steps, i have 3 technical design suggestions;

  • Architecture of community toolkit (cross platform sharable UI components)
    • Shared form builder
  • Configurable workflow between those components
    • Vs building X number of known workflows for supported programs and implementations such as HIV or NCDs etc and availing a switch for a choice of the default