Title: Adding end-to-end test automation to OpenMRS applications
Description:
Several times a year we run a suite of front-end tests to validate core scenarios in the Esaude POC. We run these tests manually which requires a dedicated team and several months of work. During the spring of 2018 we developed an end-to-end automation tests framework–using CodeceptJS and puppeteer–to run tests automatically. Since then we’ve automated several tests in our suite to run in under 5 mins total, tests that previously took hours to run manually. We think this work is important because it will allow us to validate core scenarios much more frequently–on a daily basis before new code is checked in rather than on a quarterly basis–which should result in less regressions and more time for new features. We still have quite a bit of work to do, but would like to present what we have done so far in hopes it resonates with others in the community.
Goal: Present our end-to-end automation framework and discuss ways that it can be improved upon and used by others members of the OpenMRS commuity.
Hi, can we have a Design Call tomorrow June 25 for data model or other design questions for the Oncology module we are building as part of the 3 week IBM Health Corps engagement?
We are midway through the engagement and it’s important to get through some of these questions as soon as possible. We will post something for review tomorrow morning. Sorry for the short notice.
title: clinical decision support using (Snake disease model) and linking it
to the signs and symptoms and treatment and cure from the disease that the
patient has.
description: snake disease model has a template like the one in these
episodes: https://www.youtube.com/watch?v=tsWLoJeCU48
desired attendees: clinical informaticists
desired timing: whenever appropriate
Title: Google Summer of Code 2018 - After Action Review
Description: GSoC 2018 has come to an end, and it’s time to reflect on this year’s program and all the great contributions made by students and mentors alike, as well as looking forward to GSoC 2019 and how we can apply new learnings to making next year’s program a success.
Required attendee(s): @burke, @c.antwi, any #gsoc2018 mentors and students, and NB: anyone interested in administrating GSoC (or other OpenMRS internship programs) in future.
Title. How do we define an “active” order as a search parameter for the Order service?
Description. We propose adding a new service method to allow searching for orders across multiple criteria, like “includeInactive”. How do we define an active order and what is the best way to implement search based on it? Related ticket: https://issues.openmrs.org/browse/TRUNK-5424
Description: At AMPATH we are in the process of creating a concept re-design of our EHR user interface.
This will help provide a common framework and goal to move towards as we build new features.
The EHR is growing from the needs of outpatient HIV care, to serve multiple clinic types. An all purpose EHR design is needed.
Users have expressed the need for something that is very easy to use. It has to run on tablet, Chromebook, and phone. It has to be able to separate data and workflows by system (eg HIV, Diabetes), while at the same time be able to seamlessly provide care to patients with multiple issues at once. As an internist I am particularly interested in the ability to multitask and view high density patient data while concurrently writing orders & notes. The interface has to easily scale with minimal configuration as new clinic types and workflows are added.
Goal: We are looking for feedback from the community on the mockups, so that we can continue to improve them before building an interactive prototype.
Required attendee(s): All interested. if available: @burke@mseaton darius
Desired timing: Is there a time slot between Sept 26 - Oct 3rd?
Title : Improving on Memory Management in the mergepatientdata module.
Description : I feel we have a lot of memory leaks on how the mergepatientdata module manages data. I’m looking towards the best way we could implement streaming of data since this module handles lots of Patient and their metadata. Maybe we could also raise ideas of solving Overriding default multipart file size in Openmrs module dev. This could help to solve/prevent outOfMemory issues.
Resolving design inconsistencies in Cohort Membership (TRUNK-5379)
There are various design inconsistencies in the CohortMembership model that need resolution as described in TRUNK-5379. We will use time in the design forum to walk through these inconsistencies and aim, by the end of the call, to create or identify ready-for-work tickets to resolve them.
Desired timing: Within the next few weeks. Maybe favor a Wednesday forum, leaving Mondays available for topics w/ more required attendees in Africa/Asia timezones… but doesn’t really matter.
Description: The issue tracking page has been carried forward for several releases and has gotten outdated (e.g., module ownership). Reuban (release manager) does not have the information he needs to decide on which modules to prioritize for RefApp 2.9 or who the correct contact for getting modules released. Darius & Burke did an initial pass at cleaning up the ownership information. We need to gather a group of seasoned developers to help decide on what can be feasibly done to get RefApp 2.9 released soon. The goal of this meeting is to provide @reubenv with a clear path forward for module changes to include with RefApp 2.9 .
Description: We have not updated the OpenMRS Radar in 2018. We could use a design call to review & update the radar data. Any developers or technical implementers with experience & opinions about the message our community should be sending regarding the adoption or retirement of programming languages, modules/distributions, platforms, or standards/conventions are encouraged to join.
Required attendee(s): We need to have at least 4-5 devs present to be productive. The more, the merrier. I’d suggest we use the scheduling post first to determine interest and then can do a Doodle poll.
Title. Architecture proposal: Modules and Verticals
Description. I’ve drafted a proposal for OpenMRS architecture, about which there is an ongoing talk thread. I advocate defining a single, universal configuration mechanism. This will encourage better software practices, make OpenMRS easier to use, and strengthen the community’s ability to support it.I’m soliciting community feedback so that it can evolve to be something with enough force and buy-in behind it to make it happen.
on Febuary 18 2019 @najme will be presenting her work on "An OpenMRS Distribution focusing on Cystic Fibrosis, of which discussions have been going on here: An OpenMRS distribution
She will share more details on the presentation in the coming days.
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.