Title: An OpenMRS Distribution focusing on Cystic Fibrosis
Description : We are a team (the Representative of Iran Cystic Fibrosis (CF) Association) with high creative performance, working on clinical data of patients with cystic fibrosis (CF) professionally. Our focus is on design a platform (CF package) for patients and providers to help them and improve the quality of life of this group of patients. CF package includes some main parts such as professional registry; monitor and follow-up of patients; correlative analysis on image, sequencing (NGS), transcriptomics, proteomics, and fluxomics; predictive analysis based on correlative analysis via machine learning, expert systems, and intelligence artificial algorithms. Any developers or technical implementers with experience and opinions regarding the adoption or retirement of programming languages, modules/distributions, platforms, or standards/conventions are encouraged to join.
Goal: We are looking for feedback from the community on our project, so that we can continue to improve it before building an interactive prototype.
Description: Building on the conversation started by Burke, this Design Forum will review a set of UX mockups with the purpose of using them as a strawman to start a discussion in understanding how they do / and do not fit the needs of implementors who are interested in working together on a first version of a shared OpenMRS UX application.
These mockups build on the work @jteich and @tgreensweig have collaborated with in understanding modularity and how to design a flexible EHR system. The mockups present a lightweight flexible application paired with a powerful and highly customizable workflow builder that drives much of the UX.
I’d like to propose a topic for Wednesday next week.
Topic: Improve performance of Platform
Description: The release process of Platform 2.3.0 is already under way and there is a desire to improve platform performance as it grows. There are no tasks yet to address this as can be seen on Platform 2.3.0 Roadmap, feature number 8. This design forum will help create tasks for improving platform performance so that work by the devs towards achieving this can commence.
Description. What if we had a lightweight modular web framework allowing components or even full apps to run as a single page application? What if you could combine your implementation’s bespoke or Bahmni front end with a module from another organization or country? At OMRS18, we dreamed of many How might we…? scenarios including finding a path to a common application framework. An amazing future for OpenMRS proposed a pragmatic approach of having multiple organizations collaborate on a shared frontend to solve a real world need. Exploration of that proposal led us to micro frontends and to single-spa. @joeldenning, founder of single-spa and an expert on frontend technologies, will present a set of proposals for technical features of a modular frontend architecture.
Attendee(s).@joeldenning, @dkayiwa, technical leaders of implementations/organizations eager for greater collaboration on web applications – e.g., AMPATH technical leadership (fyi @jdick), PIH technical leadership (fyi @mseaton), Jembi technical leadership (fyi @chris) – fyi: we plan to record and post to YouTube for anyone who cannot join
Desired timing. We plan to hold this on Monday, 29 April (4-5p UTC design forum)
@marslan8530 has been working in the community to review our existing information architecture in the wiki and identify pain points and areas where the architecture could be improved.
@marslan8530 will be presenting and discussing his work thus far with the community during the Design Forum today 4 November 2019 on Uberconference at 5pm UTC
Title. GSoC 2020 | Improvement to OpenMRS DHIS2 Integration
Description. We need to discuss the community’s requirements for the OpenMRS DHIS2 Integration
This module is followed by the great work done in the previous GSOC project .
The OpenMRS DHIS Integration Module gives a good overview of the module. Since this could be part of the CoVid-19 response I think this is quite urgent as well as an important project.
Title: How to: organize an OpenMRS Outreach Guide
This design call is to explore the best way to organize an outreach to sensitize the targeted community about OpenMRS. An Outreach is a predetermined visit executed by a member or members of OpenMRS focused on interesting the intended audience into contributing in different ways to OpenMRS .
We will explore:
Who should organize or get involved in an outreach.
What components ( e.g. information, other material) should be shared in an outreach.
How should an outreach be conducted?
When or how often should these outreaches be organized?
We need to find a time to continue the discussion about OCL interoperability that @ball kicked off a few days ago.
Title: OCL Interoperability with OpenMRS Production Deployments
Description: We need a common understanding and high level approach for OCL and OpenMRS interoperability beyond the subscription module. There’s good progress toward MVP of OCL for OpenMRS, but for PIH and deploying/updating production systems, this must include this full “happy path” from OCL -> Code -> OpenMRS Implementations. Is it possible to support Initializer (‘Iniz’) compatible csv format? Is this a good approach?
@mksd that was original suggestionl, but I think the feeling of others was that they didn’t want to try to cram too much into the OCL call. I still think it would make sense to discuss as part of the OCL call, but I’m happy either way, as long as the right people are in attendance.
The Condition List UI in core apps has been 90% ready-to-go for awhile now, and we’d like to get it over the finish line. However, that 10% that isn’t complete could potentially lead to a rabbit hole and lead to a lot of rework.
Can we have a design call to resolve these issues?
@mksd thanks… @burke had a very helpful post here Condition List Implementation that I think clarifies things a lot for me… still worth a design discussion though…