An amazing future for OpenMRS

Tags: #<Tag:0x00007f0789b65958> #<Tag:0x00007f0789b6b830> #<Tag:0x00007f0789b6a728>

Isaac, so great to have your contribution here. Now that you are out of Cambridge, it would be great for us to figure out a closer way to work together. You know, I was at Cambridge when we first added OpenMRS to the Millennium Villages Project HIS :). Anyway, it sounds like you have a great team and adding mobile for formally to the design process hasn’t really be grappled with since OpenROSA and some other work around the same time. Looks like folks have already scheduled a technical evaluation so we are on our way!

2 Likes

Great meeting on Tuesday, and I am sorry that I missed it. The recording was very helpful! FYI, I am more likely to be able to attend Mondays than Tuesday mornings.

A couple of thoughts came up while listening to the conversation:

  1. The overarching vision is certainly one that we have had for a long time, but have not been successful in capturing. There was a lot of similar work done in MVP and Xforms where thought to be the way to make the interactions cross-platform to mobile. Synch versus offline databases never really caught on, so Integration Option #2 is not really applicable for a truly offline-capable framework.
  2. On Workflows… I think we should not only consider the application workflow, but also the patient workflow. Aligning these two together is required for success. Patients are not linear. We would need to think about state-dependent logic that allows the patient to be updated at any point, by any application, which would then modify the resultant workflows. Getting the basic components out, and an engine that can render them with some sort of instruction set is the first step. We can then add on conditional logic.
  3. Households versus patients. This was also another key issue that was not fully baked into OpenMRS. This is not a simple aggregation of patients, but involves a supporting data model. We might think of households as something more than just people who reside in the same place. This would allow us to capture communities, families, and other forms of relationships… but we’d need to nail the household model at least for CHT.
  4. We need to think of the functional not only technical stack. Allowing for logic to perform across implementations, forms to act across languages and such, means that we need semantic operability, conceptual aggregation and a common information model. We did not go down the OpenEHR approach of using archetypes etc, since we didn’t want to inhibit the implementation of OpenMRS. However, we are going to need to include some sort of common information model and some sort of enhanced patient-resources which contain a minimum data set if this is going to work. This is actually a big deal and might make the true interoperability across legacy systems difficult… unless we invest in doing some migration work with our partners.

All in all, a very exciting conversation and I would like us to see how we can describe this whole project in a way that we can properly resource it!

1 Like

Thanks for this post - it highlights the challenges, but also what is possible with such a tool in the areas of advanced workflows based on state dependent logic. Arriving at shared concepts and further semantic operability will tough, but you’re the right person to help lead us through it.

Hi, Tuesday’s Design Call conversation is continue over the following threads:


Next Call: Monday, April 8, 2019 (16:00 UTC)

Discussion & updates on:

  • UI Design: first-draft list of UI Component Library

  • Technical Architecture: assessment to date of Community Health Toolkit

  • Workflows: further discussion around what ‘workflows’ mean

All are welcome: link to UberConference call

Regarding the Workflows and Logic area, Similar to some comments from @akanter and @isaacholeman, I’d like to make sure we have a workstream that continues down the “modular clinical functionality” path that has been part of the discussion [really, all application functionality]. I’m hoping we can survey our application needs and collect a reasonably wide set of functional components – reports, data displays, pathway flow over time, orders, person search, etc. – and map those to our developing general website workflow and UI paradigms, further unifying the more comp sci and more application aspects of this project. What’s needed for a generic reusable functional component? How do they need to interact with each other in real workflow? This will also allow us to define a practical starter project that is well aligned with the big picture.

Along with this, we should take a look at the concept and data types used in these applications and how they inform the site and UI design.

Moving forward!

2 Likes

Sorry for my slow reply @akanter, I’ve been in Dakar for work and I’m catching up on emails/forums. I didn’t realize you were at Cambridge back then–that’s cool! I’m really excited about working more closely with the OpenMRS community in general, and one of the specific areas where we’re hoping to get your input is around terminology and indicator management. It sounds like figuring out how we can use OCL may be in some ways distinct and in some ways possibly very related to our ability to deploy OpenMRS in a deeply integrated way with Community Health Toolkit apps. I’m looking forward to continuing these conversations in upcoming OMRS calls.

Hi everyone, I’m a new member of the OpenMRS team and have been working with @burke, @dkayiwa, and @jdick to get up-to-speed on the current system and to discuss options and a proposal for a modular frontend.

I shared a few slides a few days ago with them that has some frontend topics to discuss and early proposal of the direction that a modular frontend could go. I will be presenting these topics on 29 April in the Design Forum called Modular Frontend Architecture for OpenMRS.

RFC Additionally, I’ve talked with Burke about potentially creating an RFC github repo for a modular frontend. RFC is an acronym for Request For Comments (see https://github.com/vuejs/rfcs and https://github.com/reactjs/rfcs/ for examples), and it is a mechanism the open source world sometimes employs for far-reaching technical decisions.

Question for the group - What does everyone think of using an RFC as a mechanism for driving collaboration and decisions for a modular frontend? If so, I would transfer the information in the slides below to a github repo and pull requests, for everyone to see and comment on. I’m new here, though, and don’t want to start out trying to change things in my first couple weeks, so if sticking to discussions here on Talk would be better, let’s do that.

Link to some slides - https://docs.google.com/presentation/d/1sv0n_15Zp9HNusdSagOXnBO7Kbh2qURMQj3a8OR8ndo/edit#slide=id.p – these slides are meant to set to the stage for discussions, not to represent decisions that are made. I am an experienced frontend web dev and have implemented large software systems before, but do not yet have the context of OpenMRS, nor the relationships with everyone here. I do not want this to feel like an outsider coming in and making decisions without collaborating with everyone – so feel free to comment, disagree, reach out to me directly, or anything else. The purpose of the slides is to drive collaboration :slight_smile:

5 Likes

@joeldenning . Thanks! While I won’t be able to make your design call, I really like what I see implied in the slide deck. Specifically:

  1. javascript library agnostic framework
  2. consistent OpenMRS-driven style guide as a way of ensuring consistent look and feel
  3. core services (such as authentication, etc) provided out of the box

Do you remember iGoogle, the old Google home page that allowed for end-user-configurable page widgets inside a generic page structure?

http://www.igoogleportal.com

I keep wondering if we can get to a place, where… given the high-level use case (I want to care for a patient, I want to build a patient cohort, I want to build a report, etc), whether we can have a standard set of page structures (ie, 3 boxes by 3 boxes with a top gutter for patient context), and then allow community developers to build the widgets for the boxes? :slight_smile:

This would be exceptionally powerful. Glad that you’ve taken the interest in helping us evolve the user experience within the OpenMRS community. Welcome!!

One more quick question: in your slides, you refer to the smaller UI compositions as “single-spa applications”. Do those multiple applications which might comprise an end user page view all share the same data context?

Update: we have created an openmrs-rfc-frontend github repo where we’ll be tracking and documenting decisions about the future of OpenMRS frontend. Please jump in and comment on things, propose things, etc.

To address your questions, @paul:

I keep wondering if we can get to a place, where… given the high-level use case (I want to care for a patient, I want to build a patient cohort, I want to build a report, etc), whether we can have a standard set of page structures (ie, 3 boxes by 3 boxes with a top gutter for patient context), and then allow community developers to build the widgets for the boxes?

A good question and a tough one. Here’s a link to some related discussion and ideas. Layout components can be pretty tricky to manage, but also very valuable. I think the big question is how similar/dissimilar/flexible the UI is for different distributions. A component that tries to be flexible enough for anything but opinionated enough to be useful is really hard to do well.

One more quick question: in your slides, you refer to the smaller UI compositions as “single-spa applications”. Do those multiple applications which might comprise an end user page view all share the same data context?

Could you explain how you’re using the term data context? The applications all share the same javascript runtime environment, which includes the DOM, event loop, global variables, and global events. They are not isolated from each other via iframe. However, each can have its own variables in memory that are encapsulated and not accessible to any other application. API data is usually stored inside of encapsulated variables such as those, but can be shared if needed with other applications.

Question on the rfc-frontend repo, I was thinking that maybe it makes sense to have a dedicated repo for RFCs, so that it is possible to have the thinking done in the same place across various initiatives.

Front end is the current hot topic, OCL, the different operations areas, service providers, education, training etc.

Currently these are scattered across various documents, spreadsheets. There can be an RFC for the RFC process (I think I just went recursive on myself), but I hope this paints a good picture

2 Likes

Hello, I built a slide deck to help myself understand:

  1. Different ways micro frontends can be used in OpenMRS
  2. What micro frontends are

Feel free to add / comment / edit / and fix mistakes in the document.

It includes a lot of slides from blog posts and lectures on micro frontends.

1 Like

I’m a fan of RFC’s for collaborative decision making :+1: Right now I’m only involved in the frontend side of things, so wouldn’t try to talk about whether RFC would be desireable for backend or not. In general, though, I’m in favor of it.

I have created a video that shows microfrontends visually. In the design review meeting on Monday I will be going over the content in the video in more detail. Here’s the link:

Video

Exceptional video. Very slick custom microfrontend inspector.

Could someone share the details for today’s call?

I got this. Thanks

For those who weren’t able to join the design forum on a modular frontend framework for OpenMRS, the call has been uploaded to YouTube:

1 Like

Dear Friends,

The OpenMRS Kenya Community in conjunction with the Kenya Health Informatics Association (KeHIA) is very happy to inform you that the “OpenMRS Camp Cradle” kicks off tomorrow in Eldoret, Kenya. This area in Kenya has a sentimental meaning to the history of OpenMRS.

This hackathon is in lockstep with this vision of “An amazing future for OpenMRS” and ongoing work by the global “Micro front-ends” Squad and this. There is already great appetite for a series of follow-on “UI/UX safari hackathon” leading up to our annual implementers meeting later in the year.

Please see attached additional details about the hackathon including the guidance schedule.

We hope to have provision for remote participation and we will provide that information early tomorrow morning.

Invitation_OpenMRS Hackathon_June 2019_GENERIC.pdf (219.1 KB) OpenMRS Camp Cradle Hackathon Schedule 17th - 21st June 2019, Eldoret, Kenya.pdf (169.9 KB)

2 Likes

Follow the action here #OpenMRShackathon