Propose a Design Forum Topic

meetings
design-forum
Tags: #<Tag:0x00007f0a2efdd7e0> #<Tag:0x00007f0a2efd8678>

(Dominic Surrao) #43

Hi @jthomas,

I’d like to propose this design call:

  1. Title. How do we define an “active” order as a search parameter for the Order service?
  2. 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
  3. Required attendee(s). @mogoodrich, @darius, @burke
  4. Desired timing. September 12th or 17th

Thanks, Dominic


Design time for How do we define an “active” order as a search parameter for the Order service?
Design Form 2018-09-17: How to defined an "active" order as a search parameter for Order Service
(Gregory Schmidt) #44

Hi,

Title: EHR UX Re-Design. Concept Demo.

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?

cc: jthomas, jdick Thank you


Design Time for EHR UX Re-Design - Concept Demo
(Samuel Male) #45

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.

Required Attendees: @dkayiwa, @ssmusoke , @darius

Desired dates: I beg for a slot between Sept 17 - 26 !

cc: @jthomas


Design time for Improving on Memory Management in the mergepatientdata module
Design time for Improving on Memory Management in the mergepatientdata module
(Burke Mamlin) #46

A post was merged into an existing topic: Design Time for EHR UX Re-Design - Concept Demo


(Krzysztof Kaczmarczyk) #47
  1. Title. Review and discuss object mappings mentioned in Sync 2.0 FHIR Object Mapping.

  2. Description. Go through the draft proposals for FHIR object mappings for Sync available as child pages under: https://wiki.openmrs.org/display/projects/FHIR+Resource+List+for+Sync. Review mappings and gather technical feedback. Discuss usage of FHIR extensions.

  3. Required attendee(s). @darius @dkayiwa @wyclif @burke @mseaton @SolDevelo

  4. Desired timing. Next available slot. (The sooner the better)


Design time for Review and discuss object mappings mentioned in Sync 2.0 FHIR Object Mapping
Sync 2.0 FHIR Object Mapping
Tracking Sync 2.0 work
(Burke Mamlin) #48

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.

Required attendees: @mogoodrich, @burke, @wyclif and/or @dkayiwa, @darius. All others interested are welcome!

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.


Design time for Resolving design inconsistencies in Cohort Membership (TRUNK-5379)
(Burke Mamlin) #49

We need a design call to help @reubenv with the RefApp 2.9 release in order to help him with RefApp 2.9 issue tracking.

  1. Title: Helping unblock Reference Application 2.9 release

  2. 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 .

  3. Required attendee(s): @reubenv, @burke, @darius, @dkayiwa. Would like to have @mogoodrich and/or @mseaton, @ssmusoke, and any module owners or prospective module owners who can join.

  4. Desired timing: Next available time slot where we can get a quorum.


Design Time to Unblock Reference Application 2.9 Release
(Burke Mamlin) #50
  1. Title: Updating OpenMRS Radar data (https://om.rs/radar)

  2. 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.

  3. 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.

  4. Desired timing: In November 2018


Design Time for Updating OpenMRS Radar data