Prospective Contributor team from universities in Sweden

Development
#1

Who are we?

We are master’s students of software engineering in University of Gothenburg and Chalmers University of Technology in Sweden and as we speak right now, this is our final year of the program. This is part of a Software Evolution Project course and we chose openMRS as the open-source project that we want to contribute to. This project will take place from September to December 2015.

We will spend a total of around 120 hours per person, a maximum of 10 hours in a week in brainstorming and share ideas in our team on how we can achieve our goals based on qualities that each one of us will be working on. Hopefully, many of the team members find this interesting enough to continue expanding the project even after completing the course.

What we want to do? We want to contribute positively to the openMRS system and of course this is our path of learning experience and so it is also beneficial to us in a sense that we learn by doing and getting feedback from you.

We have been going through the developer guide that has quite helped us to understand the system and we are hoping to get support (ideas, advices) from you since we believe you understand very well the system.

We want to focus on the listed quality criterias (below), and find ways on how openMRS can be improved based on these criterias and implement them so that the system fits these qualities. We will have a public repository on github and we will share with you what we do and asks for help whenever we need it and hoping we can count on you.

Here are some of the issues combined with the affected quality attributes that we are interested to start working on; we are open for suggestions from you for any other functionality that will affect these qualities (functionality, reliability, usability, efficiency and maintainability):

Quality attribute - security

Quality attribute - reliability

Quality attribute - testability / usability

Quality attribute - Operability

Quality attribute - Operability

Quality attribute - Operability

Quality attribute - Operability

Quality attribute - Efficiency

6 Likes
AngularJS Form Entry project features
#2

Hi Florence,

Welcome! We are glad to have you guys assisting in making OpenMRS better and thank you for choosing OpenMRS. From my understanding, the order entry related tickets i.e TRUNK-4221, TRUNK-4220, TRUNK-4218 and TRUNK-4219 were wrongly marked as ready for work, @darius put together an order entry ui module for an ebola treatment center where i think he already implemented those features, i recall we were contemplating making the module the out the box general purpose one to provider the order entry user interface but we never came to a conclusion. But regardless of the route we take, we need to close those tickets since either way it will be done in a module, possibly we might move the tickets to another jira project for the new module.

I see that you are picking tickets based on the fact that help you address specific quality attributes, I’m not sure if we can assign you a single task/feature since it might give you the platform to address all the quality attributes, so i guess we need to get you specific tickets, is there other tickets you had identified that were a good fit?

1 Like
#3

@darius, we would be interested to push this forward (lab test and medication orders), what’s the status of this exactly, and where can the work be picked up from?

2 Likes
#4

@florencemayo89,

First of all, let me say how much we appreciate you & your group reaching out to the community. Very awesome!

Several of the tickets reference our legacy UI and the order entry UI tickets were written from the perspective of the original 2.x UI framework (i.e., building GSP pages). We are trying to migrate toward building apps that use Angular+REST.

As @wyclif mentions, we do have basic order entry for meds & tests on our road map, though it got bumped from 2.3 to 2.4+ for lack of anyone available to work on it.

There are also some near-term targets – e.g. removing legacy features and deprecated methods from the platform as we prepare for releasing Platform 2.0 in a few months; getting a dev tool to exercise & learn the REST API runnning inside OpenMRS (work started during GSoC); finish moving the legacy UI out of the platform and into a module (work started during GSoC); and, metadata mapping (i.e., creating a mechanism for modules to be shared across systems without having to hardcode references to encounter types, locations, etc.) that @raff is leading. You may or may not be interested in any of those.

Cheers,

-Burke

1 Like
#5

I have closed those order entry tickets, there was work that was started on condition lists (EA-40) by the Bahmni team and also to remove problem lists (TRUNK-4749), i think these would be possible tasks to work on.

1 Like
#6

@burke That’s great news, definitely the way to go. We are very interested in that type of development, where can we find more about this? Would that mean that HFE would also be “angularised” eventually?

We are very interested in this because we are looking in ways to make OpenMRS more “offline friendly”, and using an HTML5 client-side MVC framework is an important step in that direction.

1 Like
#7

Hi @wyclif ,

Thank you for your quick replies:

We are definitely ok with a single feature if it covers a number of qualities; it doesn’t need to cover all of them. Please suggest any if available.

#8

Hi @burke,

Thank you for your quick replies:

The activities you suggested sound interesting and we would be interested in working on them. However, we would like to know what the deadlines would be since you stated that they are “near-end term targets” and also considering the fact that we are new to the project. Kindly give us more information (brief descriptions) on what may be required for each task so that we may make a better judgement.

#9

@florencemayo89 are you looking to work on these qualities (functionality, reliability, usability, efficiency and maintainability) to improve Openmrs overall?

I would propose you pick one big project with small tasks - that way the students can learn and teach other and you can provide a complete end to end function for OpenMRS -

@burke and @wyclif have posted some potential projects you can get started on

Judy

2 Likes
#10

Hi @judy,

Thank you for the reply,

Where can we find the project you’re referring to? Can you provide a ticket number if any ?

#11

[EA-40][1] is the ticket for condition lists, there are some design details [here][2], @burke is this design page up to date? [1]: https://issues.openmrs.org/browse/EA-40 [2]: https://wiki.openmrs.org/pages/viewpage.action?pageId=76677952

1 Like
#12

Hi @wyclif ,

thank you for the links you shared with us, we have been going through the details of the project and we would like to start working on the project from tomorrow if possible, what would be the fastest/suitable way to reach you in case we need help, what is the deadline to deliver this project?

#13

Um, hold up a second. Looking at EA-40, the last comment is:

(Rafal says) The basic Java API can be considered as done for condition-lists. The remaining work is to expose REST resources and implement https://issues.openmrs.org/browse/EA-51

…and code for that is already written. I’m not sure this is a good project for you all…

1 Like
#14

Hi @darius,

Yes, that is true ! what would be your suggestion of the project then ! what can we pick from the technical road map?

#15

We recently had AdminUI sprints to angularize much of our admin user interface for the imminent release of 2.4. Last week, we had a dev forum discussing AMPATH’s Point of Care system:

In building that system, the AMPATH team have started creating an Angular Form Entry tool using angular-formly that they hope to see adopted by the community. @jdick (tech lead at AMPATH) designed it and @willa & @werick have been doing much of its development. The AMPATH team has a lot on their plate and may be very interested in having help to pull out the “Angular Forms” as a module/library that would be more easily adopted by others and even incorporated into the Reference Application.

We agree!

FYI – There are also native apps for iOS and Android along with mobile data entry tools like mUzima.

1 Like
#16

Much as i would like certain projects like angular forms go forward, i would imagine working on something on the technical road map of the next platform release is of higher priority.

2 Likes
#17

@mksd

There are several medication order entry UIs, each of which would take some work to get them into the reference application.

The first one that I worked on lives here: https://github.com/openmrs/openmrs-module-orderentryui It is mostly-feature-complete (for the simple use case, e.g. no order sets or shortcuts) but definitely needs some bugfixes (e.g. the concept-select autocomplete widget is broken when you click edit–it fails to populate correctly with an initial value). Adding this module will add a widget to the patient summary, which links to a screen that lets you write orders for drugs.

What I was doing most recently (but didn’t finish this before leaving PIH) was refactoring some of this code into the new visit note functionality that PIH was working on. This is on hold, but still has active interest. The idea is that we add a new screen for “visit note for the current visit” which lets you write drug and lab orders (among other things) and save it all when you’re done. @mogoodrich can say where this code lives now.

In between I worked with a ThoughtWorks team to build an order entry UI for an Ebola project. I think it’s really really nice UI-wise (big friendly buttons, and highly-optimized workflows), but it’s the farthest from being ready to plug into the reference application. (It uses different CSS, and it’s part of an angular application, and would need to be refactored out.) The code is in http://github.com/openmrs/openmrs-module-ebolaexample and you can see it running if you log in here: http://devtest03.openmrs.org:8080/openmrs/ms/uiframework/resource/ebolaexample/html/tabletapp/index.html

If you’re looking for the quickest path to get drug order entry into the reference application, look at the orderentryui module. The better solution would be to pick up work on the new visit note UI. Is this something you’d be interested in?

#18

This is something that we would like to work on, is there a project description you can provide us with, where we can find additional information. @mogoodrich

#19

@florencemayo89, sorry, I was responding to @mksd in that message. This specific piece of work doesn’t have any project description besides “the reference application needs a UI for drug order entry, that will work for a real life implementation”. So I don’t think this is a good one for you all. It really needs to be taken up by someone with a direct link to an implementation.

Unfortunately I don’t have a good project idea available right now, though I would point to:

  • “metadata mapping” which I think was mentioned earlier in this thread
  • do a UI in the reference application for Condition Lists. I don’t think that this is well-described in JIRA issues, but should hopefully be straightforward to describe.
  • more “Admin UI” screens that didn’t make it into the recent sprint. E.g. for example we need to have a UI for searching for, viewing, and editing Concepts in the reference application UI. (This might take some UX work to design right, but hopefully it’s easy to draw something at least incrementally better than what’s in the legacy UI.)
1 Like
#20

@florencemayo89 & @mksd do you think you can work with us (AMPATH) to come up with angular formly module than can be used by the general openmrs community?

We will be more than happy to collaborate and walk you through what we have done.

1 Like