An amazing future for OpenMRS

refapp
roadmap
openmrs-future
Tags: #<Tag:0x00007fbad14ad8a8> #<Tag:0x00007fbad14ad740> #<Tag:0x00007fbad14ad600>

(Andrew Kanter) #41

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!


(Andrew Kanter) #42

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!


(Gregory Schmidt) #43

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.


(Gregory Schmidt) #44

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


(Jonathan Teich) #45

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!


(Isaac Holeman) #46

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.


(Joel Denning) #47

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: