...
- Minister of Health (roll out to 26 regions)
- Working and reaching the communities
- Tanzania (we ant other nations to learn from it)
- Creating stories in Swahili to be transmitted to the global level
- This is our vision based on the symposium from the government point of view
- Need: Have a good communication channel as a country and know the timeframe of requirements (how long will it take to be delivered)
- Need: Local developers who can develop the own requirement that may benefit the global level to help other countries
- Need: Develop local modules (normally have a training of trainers) when a new feature is developed, need to make sure that the trainers are trained
- Need training courses via local academia (field workers can get knowledge from the institution)
- We are happy the initiative is moving forward
- Challenges on the health insurance system (we should walk with other countries)
- Create new innovators that may help the product grow
...
- grow
- 60% of the young generation is under 25 (train young people and people come up with new product and innovations
-Look at generic country requests at the global level
-Small and specific requests need to be created at the country level
-Experiences from the field, communication materials, reflection feedback into the community
-Possible national extension - EMRs need to interface or communicate with other countries
SNOMED Presentation
ISSUE TRACKING (Jira)
-Issue
- Question about openIMIS
- Raise a bug
- Request new feature
-Refer to diagram
-Waiting for support, waiting for customer, pre-testing, in-progress, resolved
-To-do (who's accountable) -
Issues:
-do we use only one tracking system? (tanzania is using a different one)
-prioritization of issues: level of technical advisory group, release cycle involves different committees and product group which gives input on which is requested (technical advisory group)
-Suggestion: high priority, medium priority, low priority in country requests
-Any user has access to the service request
-Define differences in priority (who will decide?)
-Suggestion: As long as the response will be fast regardless of priorities
-Average how long the reaction time is? 24 hours according to the SLA
-It could be a development or implementing issue (you can assign a person)
-Challenge: functional requests have overlap with the development side
-Some things needed to be redefined (issues on the service desk needed to be channeled either to the developer or implementers committee)
-We need feedback between the two committees (for the implications of each)
-Suggestion: Only the team can make an assignee
-Screen requests
first level
-questions
-report bugs (try to replicate and refer to that) when you raise a bug
-new feature request: filter if health financing side
second level: detailing out what exactly is needed
-decision-making (what resources are needed) before going to the developers queue
-do we have some substeps (IC & DC)
-Response form (automatic response comes with link to the request) - indicate what the steps are in that email so they know the steps and know how to go about it
-Suggestion: Radio button selection in the beginning (to narrow down issues) to limit the request -make it easy from the users
-Open source (openLMIS)
- issues are logged (local implemenation partners do the first round of filtering) and submit the ticket
- consensus-based priority (look if specific country or affecting a lot of people) and make sure it follows the priority
- End user → local implementing person → global committee
-Jira can also accommodate other requests apart from the country specific implementaion side
-Hubs as part of the process (part of the issue queue)
-Send email to the system then goes to the email of a group of people then a ticket gets assigned to somebdoy (logged through a focail point in a country)
-Local queue system per country? Clarify with openLMIS
-Are there enough resources to deal with applications on a country level? do cap bldg with local partners for issue escalation probably
-Transfer knowledge and open up and have people qualified to roll out and provide training
-Costs
explained generic steps
timeline
cap blg
scale
-Step-by-step proposal for Rwanda (tailor it to the size of the implementation)
*Rollout is mostly training of users (depends on location as well)
*Rough estimation only because it depends on the country cost
*National rollout in tanzania (sample) - now just the concrete application in the new districts
-Information to think through on what they need to do (getting the steps done so they own the process, get them an idea of the quantity, the cost should be researched upon)
-Same applies with the timeline of the application
-Cameroon experience (outsourced maintenance support)
-request from cameroon: open source advantage and disadvantages, if cameroon can engage local developers (but you are not assured of their competency), who responds with health-related?, maintenance and
-Build a capacity for the local teams (developers in each country)
-If we document and escalate all to the global level, maybe local team can resolve, but we can still inform/update the global so it can be replicated in the global level
-country representatives who can be logged in to the Jira (if we leave it open to users, global will be overwhelmed) – we should leave some issues to be taken care of the local team
-Whenever there is a new requirement, at the mpment you are working with epayment application, so other countries may not need to do the same and use the same
-1. implementers - we can use that channel for countries who havent started yet
-2. Developers -
-Follow the same process for quality control (question to george) for cameroon's maintenance support
-Before we accept any contrbution, they need to follow the policies or test, before it goes to the master version
-Establish communication/contact when you bring in a new developer so they are aware of the global intiative
-There might be functionality reasons why it wont to the core code, it may be because it doesn't meet the standards (Quality control)
-you might be maintaining a piece of code specific only to you
-Before hiring an external developer, inform first the developers committee
-should we integrate external develoeprs in the Jira issue queue?
-best way to learn is through an academic group (assignment for group of students) - look at this issue queue
-should we maintain the local solutions from countries to the global github? - its up to the country if they want it to be available on github
-Bluesuare is proposing to have a plug-in feature so local developers can hook in to the platform without the rest of the world kowing about it
-Tanzania: they should have a helpdesk where they can log in (for countries who haven't started)
-a focal point in each country to have a linkage into the global issue qeueu
RELEASE CYCLE
*Refer to diagram (bottom-up approach)
-Development life cycle
-Maintenance and support project planning
6 months release cyce (4 months development then 2 months to support/ specification or requirements gathering)
Next release cycle:
April 2019
October 2019
April 2020
-Make sure enough time for developers
-Time between requirements gathering, process where implementers committee contribute to the process of release cycle, depends on a matter of how many releases come out..
-Have time before the release,
-Collection of requirements will go the issue queue
-How to modify to bring in the implementers committee (hubs)
-When do we start or put process into the diagram
-Who will be the coordinator (go back and forth)
-Define another step to generalize solution on the business side and developer side (go straight into queue)
-Prioritizaton mechanisms and who will decide
-Who is resonsible at each part, who will comunicate
-Testing not present in the planning (usually 2 months for testing) - take it into account (effectively)
-whether the software works for what they have in place
Answer: set up another test server (end user acceptance test will be placed mid year)
-Testing is important because of many scenarios in health insurance
-To make sure it all complies with the requirements before the release
-1) test server,
2) deploy it in the user demo server (online or offline) then give them time to test, then put it in the live sytsem
-not data from the organization
-master version release then tested
-if someone can have a look at the user perspective then wait for contries to give you feedback or you can have a sub-release
-Beta-release (not tested in the field yet)
-Reuirement gathering and user support (2 months)
-Suggestion:Period for collecting requirements (categorize development stuff), ONCE THE NEW RELEASE IS COMING OUT, DEVELOPERS CAN STILL CONTINUE WITH THE DEVELOPMENt (we should not have a partiular period)
-How many business analysts? 2 that are not also full time
-New developments will be on the modularization part, at the maintenance component - it will focus on maintaining or holding system together
-Tanzania: no specific release schedules/cycles as of the moment
-big change: modular transformation and integrations
-naming of openimis versions, imis - monolithic, open source package - then openimis (one with modularization transformation).. in tanzania not yet using open source so it's still IMIS
-Change the system architecture and developer platform, database (from monolitihic to modular architecture)
-Re-architecture will change the back-end
-User functionality will still remain
-Fixed release dates? Yes
Implementation Starter Kit
Ex: iHRIS (for implementation starter kit reference), openLMIS,
-Business processes mapping to demonstrate a user journey
-test database where i can populate and experiment
-donwload an application (self-extracting thing) and explore and play with this
-political side to be esasily attracted
*workbook type per each phase - make it more particiapteive - complement the manual
-resources needed (physical, cost)
stakeholder engeagement
identification of stakeholders
-onboarding workshop
-use case scenario (examples)
-standard texts on the wiki