Encounter Diagnoses Sprint 1

Owned by Arthur Thungu
Last updated: Feb 27, 2018
2 min read

General Information

Team Lead: Daniel Kayiwa

Sprint Lead: Arthur Thungu

Timeline

Start Date:  

End Date:  

Participants

  • Cecilia Nalubega 
  • Patrick Luwum
  • Kelechi Iheanyichukwu
  • Arthur Thungu
  • Isaiah King'ori

Sprint Goals

The main goal is to design and implement Conditions and Encounter Diagnoses in the OpenMRS core platform.

The goal has been sub divided into several tasks:

  1. Introduce a new convenience class CodedOrFreeText
  2. Introduce an Enum for "diagnosis certainty"
  3. Introduce an Enum for "condition status"
  4. Introduce new Condition domain object, backed by a new `condition` table
  5. Introduce a new Diagnosis domain object, backed by a new `encounter_diagnosis` table
  6. Introduce new REST APIs for these domain objects
  7. Refactor emrapi module's DiagnosisService and ConditionService to use new functionality
  8. Create a ticket for migrating existing data captured via the emrapi module
  9. Create a ticket for updating the UIs in the reference application to use new tables


Sprint Dashboard

key summary type created updated due assignee reporter priority status resolution

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

How to Participate 

Add your name to the list on this wiki page (with any comments about your availability). If you want to join after the sprint has started just join the IRC channel mentioned above and say hello.

The general process:

  1. New to OpenMRS sprints? Want help getting started? Join IRC and say "???": I'd like to participate in the sprint!". If you get no response, just ping any of the above sprint participants as per the IRC tips at http://en.flossmanuals.net/openmrs-developers-guide/support/
  2. Pick a ticket from the available tickets in the top-left of the sprint dashboard page at:
    • Make sure it does not depend on a ticket that is incomplete.
  3. If you have any questions about the ticket, ask on the group chat
  4. Do the ticket. See our HOWTO for git. Sprint specific git HOWTO for devs with push rights: whatever works for you :-) If you don't like pull requests, don't send them. Commit and push directly to the main repo. If you do like pull requests, fork the main repo and send pull requests, but merge them right after. My favorite way is to work on the main repo, but create local branches (without pushing them to the main repo). Merge branches locally to the master and push to the main repo.
  5. Join the daily scrum to share your updates

Tasks To Be Completed Prior To Design

None

During Project Notes for the sprint

To be added while the project progresses 

Sprint Retrospective:

What went well in the Sprint

  • Consistent delivery of tasks
  • Effective communication
  • Good, actionable and timely feedback
  • Teamwork

What could be improved

  • Communication frequency - regular team syncs aside from the daily scrum
  • Mixture of stacks (Java and React)
  • More peer code reviews
  • More detailed stand-ups
  • Communication on blockers (At most 2 days for progress report)

What will we commit to improve in the next Sprint

  • More peer code reviews
  • Communicate on blockers (At most 2 days for progress report)
  • Communication frequency

Resources

JIRA board: https://issues.openmrs.org/secure/RapidBoard.jspa?rapidView=136

Github repo: https://github.com/openmrs/openmrs-core