Page Comparison

...

Quick overview Notes

3 basic user roles

Admin: Setting schedules for (Dr., volunteers, etc), configuring basic options (example room assignments)

Receptionist: Making appointments, Accepting patients (registration)

Clinicians: See the list of patients, and see patient dashboard

Admin

1. Configure Spaces

setup room 1,2,3

2. Configure Appointment Types (gyno, family, Radiology)

type of appointment and length of appt (helps figure out how much time a room is busy for)

3. Resource scheduling

Receptionist

1. List of appointments with a status of "scheduled"

a. ability to check them in, and announces to clinician that they are here.  Starts and Encounter 

2. Creating appointments 

a. Selecting a clinician for your need, and then it will automatically show times available

b. AI algorithmic way to make efficient (min max rooms and doctors)

Clinican

1. Time tracking starts (how long were they waiting, how long (insert variable metric)

General Info

...

There should be multiple design meetings.  The first starts off with a small group working with the leader to determine the high level scope of the project and then to break down into smaller pieces to eventually place as tickets.  Once those meetings havehappened have happened use of the community design meeting time should be used to refine the tickets and if possible assign them to who will be doing the work.

Looking at creating 3 parts (Possibly 2/3 different sprints)

1.  Structure issues w/OpenMRS and Pair program

1 Core Dev in a complementary timezone

2.  Get more people involved with core features

This is where the community gets involved

3. Once in place some feedback from users to make changes.

Looking to see if we an build this incrementally

1.  A separation of API and UI

Design Call 11/7 Proposal

1. Start small (example Create and appointment)  Layout the design for that.  Concern is that if it's too basic will it get used?  Discussion on this is needed.
   1. Creating a table in DB
   2. basic UI
2. Get the developers on some specialize bugs to fix
3. Happy with the design for the 1st feature
   1. Possibly Daniel could schedule an hour a day to work with them setting up the project with their first feature.
      1. Talk to Daniel about scheduling  (Sunday through Thursday is the workweek)
4. How do we guide tomorrow call correctly?
   1. Goal What's the data model needed?
      1. what are the items that needed in the DB (start, finish, date, time, location, what needs to be recorded)
   2. Some basic introductions
   3. When we get an idea of the smaller pieces figured out then how to create tickets
      1. We need to frame tickets as user stories and then have the developers build the actual tickets for code
5. Look at existing modules to see if we can reuse (module ID: appointment) need to look at this source code to see if it has potential

   Info

   Risks (these should be resolved prior to or during the design meetings): Enter anything that is still questionable or worrisome that has not been answered: (open issues, potential concerns) Once a decision is made make sure that a summarized answer is included. Example: Q. How will we handle issues with conflicting userID’s?  A. All ID’s will have an added identifier that is unique. Developers need more experience with the OpenMRS framework/models   Effort Accounted For: (At the end of the design call all tickets should have an estimated effort and that total should be balanced against the known available effort of the developers assigned) (Yes/No)  If not in balance in favor of success why and the action plan for remaining items

   via IRC on the #openmrs channel on freenode.

Use this channel for ALL debugging and random questions having to do with the sprint. Please avoid direct messaging to personal contacts. If you have a question, someone else most likely does too, and our geographically distributed community benefitsfrom public group discussion.

...