...

1. At which geographic level should we assign teams?
   1. Currently we assign them at the operational area level in locations
   2. We assign teams at the village level in the team management module
   3. What's the difference here?
      SG: The Difference is because we can only assign teams to OpenMRS Locations in OpenMRS. However on Reveal Jurisdictions(Spatial Locations) are used. We have to find a way of matching these two since we are using OpenMRS locations to control access to Reveal. We decided to use Operational Area tags since those would be easier to match to Reveal jurisdictions. The other levels of Locations on OpenMRS may not be necessarily mapped to Jurisdictions which are administrative locations. However this can be amended if its guaranteed that location Hierarchy in OpenMRS matches the jurisdictions, then its possible to tag `team_id`  at Higher levels than Operational Area
2. Are there plan-type specific requirements for assigning teams (FI vs IRS vs ?)
   1. AM: IRS will be more dynamic than FI, however, requirements don't differ. Right now, the build seems to be that team assignment to plans happens automatically with FI, thought with IRS these assignments will be done by an end-user. We
3. Can we assign multiple Teams to a single Jurisdiction? (OA, FA, Spray Area)
   1. AM: We need to be able to do this.

IRS Team Assignment Workflow/Considerations

1. 1) Teams should be assigned either at operational area level OR a higher level in the hierarchy above that gives access to all below. Workflow expectation is that there is daily/weekly internet connectivity and teams will be reassigned
   1. Team assignment Workflow:
      1. All areas that are to be visited in next day/week are assigned by a manager. This frequency of assignment is determined based on connectivity as well as the IRS Manager bandwidth to be doing these assignments. Some managers may do this daily. Some may do it only weekly.
      2. Users log in, sync any data from previous day or week's work. Then re-sync the full list of operational areas assigned. 
         1. Requirement: we need to have a way to know if syncing (uploading data and downloading data) is complete (not specific to team assignment dev but necessary for functional workflow)
      3. Users on the client, select the OAs in the hamburger menu that they plan to work in in the next day/week (network dependent, if network every day, can do this daily. When they know they are going out of area for x amount of time, they need to sync enough areas for x amount of time). Sync the plans for each OA (sync all plans if multiple for one OA), sync imagery, sync the tasks.
         
         1. Question: Apart form the user burden of selecting from a long list (we think this won't be huge since they will only have to do this 2 - 3 times per day), does syncing a long list of operational areas take a lot of data/space (if we are not syncing their plans or data). Need to balance the frequency of syncing/internet access with the # of areas whose data is synced to the tablet (limited by connectivity)
   2. Team creation - near-term/immediate, we will create one large team for all IRS teams within a district. This means all users will have access to all operational areas that are assigned.
   1. Requirement: creating multiple teams and being able to change which users are on which team at any time
      1. This necessitates having a view in the web UI to see which teams are assigned where.
   3. 1. Question: Can team assignment be done at other levels of Jurisdiction higher than OA/village that would then allow access to all OAs within that jurisdiction?
      2. Requirement: users should have a permission hierarchy for submitting data on the client and a separate permission for viewing data on the WebUI

FI Team Assignment Workflow/Considerations

Teams should be assigned to the district level, which gives them access to all operational areas//villages within a district or province.

These assignments will be mostly static (won't change daily or weekly).

Notes

• Summary: Need to assign users/teams to geographic hierarchies, define user addition/deletion, and define permissions as appropriate.

User Type Table - permissions need to be coming from OpenMRS

Requirements

1. Location/administrative hierarchy units must be defined.
2. Users and user names / passwords must be defined.
3. A team hierarchy structure must be defined (i.e. team leader, team member) if appropriate
   1. QUESTION: Does Thailand want a flat team/user structure or something more hierarchical?
      1. AM: Christina Riley Pedro Pagalday Olivares please fill out the table above
      2. AM: Derek PollardSameen Babur please fill out table above for Namibia
      3. AM: Derek Pollard please fill out table above for Zambia
4. User permissions must be defined if appropriate
   1. QUESTION: Do all team members have access to all parts of the FI planning module, web dashboards, and mobile client?
      1. Craig Answered 7 Aug: Currently, the answer is no. We separate the web users access controls from the mobile client.
      2. AM: Added Requirement: We need to differentiate access to creating/editing plans piece and access to viewing plans in progress and viewing reporting
   2. QUESTION: Can all users access all geographic administrative units? Or are they restricted to a specific OU and below?
      1. Craig Answered 7 Aug: They are restricted to the location of the team where they are assigned
      2. AM: Added Requirement: We need to differentiate access to locations for viewing versus editing data. For example, as a district I need to edit data only in my district but see data for the whole country.
5. User loading into Reveal must be defined - currently this comes from the BIOPHICS holding tables (Pierre Dane looking into this)

6. Users must be mapped into teams and assigned operational areas/operational areas assigned to teams - see Thailand Team/User Mapping

7. Users and teams must be added to OpenMRS and then linked to their locations

   1. QUESTION: Is this the ideal way to do this?
      1. Craig Answered 7 Aug: No, but it's what we currently have in place
   2. QUESTION: How are users/teams deleted?
      1. Craig Answered 7 Aug:
         1. Users can be archived in the OpenMRS UI
         2. User Team Association can be voided in the OpenMRS UI
         3. Teams can be voided in the OpenMRS UI 

...

System terminology crosswalk:

Domain objects

Organization

FHIR Links:

• organization-type code system
• codeableConcept data model

{
  "identifier": "",
  "active": 1,
  "type": {
    "coding": [
      {
        "system": "http://terminology.hl7.org/CodeSystem/organization-type",
        "code": "team",
        "display": "Team"
      }
    ]
  },
  "name": ""
}

Practitioner

{
  "identifier": "",
  "active": 1,
  "name": "",
  "userUuid": ""
}

PractitionerRole

{
  "identifier": "",
  "active": 1,
  "organization": "Organization:identifier",
  "practitioner": "Practitioner:identifier",
  "code": {
    "text": "Community Health Worker"
  },
  "location": "Location:identifier"
}

...

OpenSRP already has a location domain object, but we need to add a reference to the managingOrganization, which is how we can make the link to a particular organization and the locations that are managed by that organization

{
  "type": "Feature",
  "id": "ac7ba751-35e8-4b46-9e53-3cbaad193697",
  "geometry": {
    "type": "MultiPolygon",
    "coordinates": [
      [
        [
          [
            101.16691589355469,
            15.071501959533219
          ],
          [
            101.16562843322754,
            15.069429992157021
          ],
          [
            101.16485595703125,
            15.064913033351885
          ],
          [
            101.16489887237549,
            15.06147344997797
          ],
          [
            101.16584300994873,
            15.058531111669833
          ],
          [
            101.1687183380127,
            15.057702276638427
          ],
          [
            101.17352485656738,
            15.057743718466615
          ],
          [
            101.17944717407227,
            15.058365344921617
          ],
          [
            101.18399620056152,
            15.058945527975887
          ],
          [
            101.18910312652588,
            15.05977435816855
          ],
          [
            101.19189262390137,
            15.062923883477925
          ],
          [
            101.19154930114746,
            15.067109364744775
          ],
          [
            101.19086265563965,
            15.072703691366488
          ],
          [
            101.19060516357422,
            15.07481706536609
          ],
          [
            101.18863105773926,
            15.076806104068151
          ],
          [
            101.18541240692137,
            15.07693041836944
          ],
          [
            101.18215084075926,
            15.077261922817648
          ],
          [
            101.17717266082762,
            15.078090681677569
          ],
          [
            101.17421150207518,
            15.077759178521134
          ],
          [
            101.17215156555176,
            15.07659891340453
          ],
          [
            101.1685037612915,
            15.075355765184456
          ],
          [
            101.16691589355469,
            15.071501959533219
          ]
        ]
      ]
    ]
  },
  "properties": {
    "status": "Active",
    "parentId": "07b09ec1-0589-4a98-9480-4c403ac24d59",
    "externalId": "",
    "name": "TwoTwoTwo_03",
    "managingOrganization": [
      {
        "reference": "Organization:identifier"
      }
    ],
    "geographicLevel": 4,
    "version": 0
  },
  "serverVersion": 1563491965499
}

...