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!
A shared problem to which a separate web application could be applied
At least 1-2 developers who could be directed to work on a solution
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?
@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.
@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.
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?
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.”
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.
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.
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
