Title: Unvoiding/Unretiring via REST Description: Standardize on a REST API for undeleting (unvoiding data, or unretiring metadata) Timing: next available
We’d like to schedule a call for
Title: “Module to collect data from user-related forms”
Description: The discussion will focus on developing a module, or enhancing an existing one in order to capture data that is not directly linked with patients, but part of the implementation. For example, recurring data related to facility performance or feedback from community health workers, etc.
Desired timing: Next open slot on Wednesday when attendees are able to join.
Description. During OMRS17, we had a session specifically discussing ways we could create greater collaboration beyond the platform (notes). One of the action items from that discuss was to refactor the main UI components of the Reference Application (specifically, login page & landing page, then maybe dashboard ±visit page) to use contemporary development techniques that we want to promote –i.e., React or Angular against REST, npm, maybe webpack or similar technologies. As Darius put it (paraphrasing): “I don’t want to devs to have to learn extra OpenMRS-specific steps in order to add an app to the RefApp.”
Goal: Determine strategy for refactoring login page and landing page, including technologies/approach to be used and draft action plan. Our intent to complete this refactoring before GSoC starts in May.
Desired timing. Next available slot (I’m covering inpatient service 9-26 Feb, so would like to fit in this call and, if we need it, a follow-up call before 9 Feb).
for what it’s worth, I will be unavailable Jan 25th to Jan 30th, but feel free to have the call without me… I am interested in following this, though.
I’d like to schedule a design session focused on improving concept dictionary management for OpenMRS using OCL. We had a preliminary discussion in January where we outlined 3 milestones that we hope to hit in 2018 so that OCL can be a more valuable tool for the OMRS community. This topic corresponds to milestone 2 in these notes: https://docs.google.com/document/d/1UjgF1GYuuI7tFsK3qGMT2efdmLeNaKpfbptajgw0Vxc/edit?usp=sharing
Title. Implementing LDAP support in Atlas 3.1 project,
Description. During GSoC 2016, a new version of the Atlas server code was written in nodejs as the Atlas 3.0 Project, but this new, node-based server code was never fully deployed.Since in 2017 the authentication is switched to LDAP, it is needed to implement the same in atlas 3.1 project.
Goal: Determine strategy for designing the authentication module with LDAP and discussing other security related issues.
Desired timing. 28 Feb (Since GSoc applications would start from 12th March).
On Monday March 19 I would like to discuss this on an OpenMRS design call:
Specifically, this is work that a team is about to start doing for a Bahmni implementation project, and they’re asking for design feedback up front, when it’s easier to incorporate. And so that the output can be more generally useful for Bahmni (and presumably for OpenMRS too).
(Also FYI @paynejd since this will preemput our scheduled OCL discussion. But I promise to send some mockups soon.)
We would like to discuss the work on the Condition Lists for Ref App work done in the OMRS17 hackathon for inclusion in RefApp 2.8 on the next (Wed, 11 April) design forum.
Super. PIH will join the discussion. We appreciate the emphasis on the work.
Based on yesterday’s quarterly Scrum of Scrums I would like to propose several design topics:
Data Warehousing and Analytics
- Description: The eSaude team wants to work on data warehousing and analytics in the upcoming quarter. They are interested to learn about existing work by Bahmni and PIH, to understand if they can leverage one of these approaches.
- Required attendee(s): @ningosi, @valvijo, @pramidat, @mseaton
- Desired Timing: eSaude should comment on this
UI Dev Conventions
- Description: A lot of JS development is happening these days, it feels very scattered, and many people don’t know what the current best practices are or what code/libraries they should be starting from. Let’s have a call to see if we can identify good practices and reusable components being used in recent development, and document them in an obvious place.
- Required attendee(s): @dkayiwa, @darius, (@raff), @darius, @burke, @mogoodrich
- Desired Timing: no preference
OCL for OpenMRS
- Description: Continuation of previous design calls, continue to get feedback on design and mockups at https://docs.google.com/document/d/1R_Fgr5SBl4xFNJgj6yMJNVY63b5H_OUqM55o1GFqFKs/edit#heading=h.rc908wooykzg and hopefully get the beginning of this project to be ready-for-work.
- Required attendee(s): @paynejd, @darius, @ball, (@pramidat), (@madhubalam), (@akanter)
- Desired Timing: ASAP; on a Monday
A post was merged into an existing topic: Design Time for UI Dev Conventions
A design call to discuss approaches for simpler appointments scheduling, whether this can be based on the current appointment scheduling or a new module based on Patient Appointment Scheduling - Integration with other forms
So there are already two appointment scheduling OpenMRS modules out there, there should be a way to not create a third one…
Otherwise, on the principle, I support moving forward enhancements of the appointment scheduling feature and achieving a better integration with other tools/screens/APIs in OpenMRS and its distributions.
Adding Order Status for Orders
Description: The PIH team is looking to build functionality for “Order Tracking”, and adding a “status” to Orders would help to facilitate this.
Desired Timing: ASAP (just not the one starting in 15 minutes)
Following up with the discussion here(Order Entry UI Sprint 7 Progress), we would like to schedule a design forum.
Title: Discuss/finalize the Consolidated Order Entry UI design/flow.
Description: Consolidated Order Entry UI is a proposal from @ddesimone, more details about it can be found in this Talk post.
A team of developers from Andela(which I am a part of) has started working on the initial design provided in the Talk post and here is a link to the sprint announcement Order Entry UI Sprint 7 Announcement.
However, there have been a lot of feedback given on the initial design(here and here) which has to be integrated into what is already existing. This call is meant to help facilitate the discussion on how to integrate the feedback provided into what is already existing.
Desired timing: Next Available Slot(16th July 2018).
2 posts were merged into an existing topic: Design forum to discuss/finalize the Consolidated Order Entry UI design/flow
A post was merged into an existing topic: Design forum to discuss/finalize the Consolidated Order Entry UI design/flow
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.
Desired time: Early Aug