Date: February 15, 2018
Location: Sea Cliff Hotel, Dar es Salaam
Moderator: Christian
A. Expectation Setting
-Mapping hospital workflows
-Use of data from openIMIS for research
-Use of data from openIMIS for decision-making and national policy making
-Integration with Health Curriculum
-Integration with SMART policy
-Digitizing claims
-Fit openIMIS with Enterprise Architecture in Tanzania
-Capacity-building on openIMIS
-How openIMIS can come in as a system for medical insurance
-Operationalizing the system (field level)
-Translation of field lessons to national level implementation
-Tanzanian perspective in technology/ digital health
-Learn more about openIMIS, knowledge and resource sharing
-Learn how openIMIS can fit with health financing schemes
-Coordination with other partners
-Linkages with health management systems
-Perspective on sustainability with evolving technologies
-Inclusion of indigents with openIMIS as a tool (Chad)
-Requirements gathering from countries
-Understanding country needs
-Sharing of lessons learned
-Governance structure of openIMIS
-Strengthening the management of openIMIS implementation
-Look forward into proposing it as a test tool in a local town in Cameroon
-Advance implementation with BEPHA in Cameroon
B. Field Trip Experiences
Group 1:
| Observation | Challenges | Recommendation |
|---|
- Members' enrolment: central them, a lot of data entry done and similar data is entered in different systems
- Members' enrolment: concern about keeping data on phone and the security issues related to this (theft etc)
- Client Identification: no patient verification without internet is a challenge
- Client Identification: Definitions of household is loose (up to 6 people).
- Cards don’t have photos which makes it difficult for illiterate people to know which card is there’s
- Capitation: reimbursement system calculated on number of cases but provider still needs to add diagnosis in OpenIMIS. Should we be putting this level of effort on the provider when this data is not required for capitation payment
Group 2:
Members' Enrolment
- obersvation - User familiar and efficient using system
- Obersvation - QR codes being used
- observation - lots of paper still around
- No means of confirming family/household size. Need a definition of household and how we implement it (Rwanda eg)
- Is it possible to do enrollment the household to get the GIS
- Linking with other systems is important
- Diagnosis code should be accompanied by text. This has positives and negatives - issues of data security.
- Data security is also an issue with people using personal phones at the health facilities.
- didn’t get to the reporting functionality which would have been valuable
- is the computer version also bilingual? App is yes don’t know about computer version
C. openIMIS Global Initiative
- Timeline: From IMIS to openIMIS
- Vision & Mission: Link health financing schemes into interoperable digital health systems by using open source software
- Components
- Open Source
- Sustainable Community
- Interoperability
- Customizable Architecture
- Open Source Sofware is free but needs to consider:
- Licensing Agreement
- Free to use as-is
- Costs for customization and implementation
- The community of practice (DHIS2, openLMIS, etc)
- Governance Structure
- Developers Committee
- Continuity: SwissTPH and SolDevelo
- Re-architecture: BlueSquare
- Interoperability: HISP India, etc
- Implementation Committee
- Communication: FFW
- Capacity: SwissTPH and EPOS
- Community: AeHIN and Jembi
- Developers Committee
- Clarifications
- openIMIS as an avenue to create an environment for solving issues
- Specific country customizations to be done by responsible payer in the system
- 2 versiosn at least in a year
- Data ownership is locally managed 2019: small releases, knowledge production, master version
D. openIMIS Regional Hub Africa: Jembi Health Systems
- NGO in Africa
- Started in 2009
- Technical development, business analysis, implementation
- Requirements definition, system architecture and design, development of software,
- Implementation in countries in Africa
- Managing and evaluation of projects
- International open software communities
- Role with openIMIS:
- Define requirements and provide technical assistance
- Technical specifications for interoperability
- Helping in implementation (matching with donors)
E1. Parallel Session: Developers Committee
- Alignment with digital development
- Alignment with digital investment
- Embedded in sustainable development goals
- From MS IMIS to openIMS
- Components
- Open Source: openIMIS in an open source environment
- Local Development: IMIS in TZ, NP, CM (adapt with unique requirements)
- Modulat Transformation: From a monolithic web structure to a mode modular structure
- Slow Transition: Prioritize modules depending on country needs
- Interoperability: Data exchange among different systems anchored on openHIE framework that would allow fire data to en ESB as an itneroperability layer
- Vision: Integrated Workflows (Examples: Eligibility, Claiming)
- openIMIS Outsourcing 2019
- Continuity: Software maintenance and support (Swiss TPH and SolDevelo)
- Re-architecture: Modular transformation (BlueSquare)
- Interoperability: HISP India (openIMIS and DHIS2), SwissTPH and SolDevelo (openMRS and openIMIS for claims management), Possible Health (openIMIS and Bahmni for claims management)
- Current Activities
- Routine support and release building
- Getting the teams on board
- Concise weekly coordination calls
- Need-oriented special topic calls
- Developers workshop (February 2019 in Bonn)
- Decide on technology options
- Learn new technologies
- Harmonize work plans
Q&A Session 1:
- How insurance will come into the new diagram of openHIE? The new version will include openIMIS.
- To have a lot of buy-in in Tanzania and other countries, there is a need for local developers for customization and development. How to ensure that they meaningfully come in (like they are paid on a regular basis)? This is where the regional and country hubs come in.
- Are there local developers in Tanzania? These are contracted by another implementing partner.
- To be part of openIMIS, what does it require?
E2. Parallel Session: Implementers Community
- UHC is the aim - through health financing sysems
- health financing processes
- resource collection
- taxes/payroll
- Insurance contributions
- user fees/co-pooling
- resource pooling
- purchasing of services (holds the funds for resource pooling, we need data to design a strategic purchase -match with services needed)
- capitation
- budget
- case based payment / fee for service
- more fee for service focus the more information we need. Always need data if we want to move away from a general budget
- how do we use openIMIS
- registration / enrollment (also collect money)
- verification of member
- claim submission
- Claims review
- client feedback
- reporting _ basic but growing (what are you diagnosing, getting money for etc)
- OpenIMIS is a flexible tool that can be used for main health financing schemes: NI, tax funded national health system, community-based health fund, vouchers scheme, strategic purchasing arrangements (P4P and RBF)
- What we do at the implementing committee? Next. Steps for OpenIMIS - globally
- position OpenIMIS globally as digital tool for health financing and UHC (so countries don't start from scratch)
- software development - collecting and defining new user requested features
- formal sector enrollment
- additional reporting and monitoring functionality
- dashboards for management and policy decision making
- interoperability with other systems
- marketing and communications: new website
- expanding the network of development and implementing partners (promote sustainability at the local level)
- Next steps: country-level
- bringing new countries onboard
- COuntries: RW, MW, CAM CH
- country assessments to gather requirements and software functionality requirements
- expansion of network of developent and implementing partners (support possibilities for country level implementation)
- implementation steps
- starter kit (including costing estimates)
- costing estimates
- Demo on software
-
- online video, wiki guide
- Capacity-building: alliances and strategic partnerships
- Q&A session 1:
- from persepctive of operators already using a system would you have to do this twice
- different insurance providers different systems. Can look at interoperability for single form for data import
- paralel systems currently running. It’s a policy level decision.
- from persepctive of operators already using a system would you have to do this twice
- resource collection
OpenForum Q&A:
- In Chad, how can this request for change (for co-payment) at the global level can be accommodated or we have it to develop it via local projects? We'll talk about the channels being used later in the afternoon. This shall be discussed among the implementers - it's something we need to find out based on your priorities. Local implementation structure and teams are needed for local development and features. Prioritization of requests is being assessed based on discussions with the technical advisory group.
- How can we be registered to openIMIS (as a local company)?
- How can we be capacitated? (Communication between local and global) Self-learning via wiki platform for architecture.. also via github
- For interoperability initiatives, how can we coordinate (so we don't end up doing the same thing)? Communicate with our developers.
- How high is the risk if I cannot fund local developers into the redesigned and modular system? Roadmap for communication among developers to be released by the end of the month.
- is there a timeline for redesign? 2 modules by end of 2019 but size of module not clear. There is a will. Will have roadmap and timeline at end of Feb 2019. Until then we will be sticking with the MS based system for implementation? Yes. It should also allow for seamless transition to modular approach
- Would you know about the licensing agreement (when it will be offered for free)? At the end of feb, they would most probably know about the new architectures
- Can this whole work be done offline? Enquiry part is still online.
- Recommendation: Big opportunity to involve developers from pioneer countries like Tanzania (re-architecure phases, etc) . Response: Academic outreach with universities
- Recommendation: Need to involve local institutions like academia as early as now. Include in their curricula activities
- Comment: Local private software firms may be willing to participate in the developers' committee. Response: Universities can be entry points for capacity-building.
- How can we benefit from the global initiative when the complete package is complete? We want to add open source development languages that are not dependent on Microsoft. Ideal scenarios is that the database layer exchangeable that can be run on a Microsoft server and Linode server.
- Comment: Potential for openIMIS to interoperate with other systems or existing systems that are up and running (GOTOHOMIS, etc)?
- Will there be a claims management demo? Rejection reports
COUNTRY GROUP WORK
Q: Is there a sustainability plan for CBHI?
A:
Q: In Cameroon and Rwanda, no enrolment features. Recommendation: Cameroon might want to customize it in their country as we are developing a master version.
A: Government want to use the aspect of this program for the future. We want to check if we can adopt openIMIS. Our problem is we have many bills and we want to extend this program in Cameroon. It's a strategic decision to make. We want to get ready on the rollout of openIMIS. To get the offline version installed and understand the functions so we can manage it on our level.
Country System and Requirements: Tanzania
- Unclear policy direction
- Governance: Sector-wide approach, health financing technical working group, CHF Implementers group, technical committee established on CHF IMIS, installment of payments (a question right now)
- Harmonization: Current rollout, harmonize strategy for enrolment officers, lot of issue on mismatch of money,
- Feature Requests: Payments have arrived, policies are active, app that runs on any hardware, integration with facility system, client registry might have overlapped with insurance system - integration needs to be aligned re data capture, standardization on NHIF and CHF
- Challenges: SMS cost, hardware needs, lack of phones, capacity building (large number of people), administrative costs, unclear policyQ&A:
Q: Microsoft training - we have done video tutorials, we can create training in each region via video
Q (Rwanda): Standards for claim management or wait for the openIMIS software to be ready?
Comment: There should be closer linkages between working groups on health client registry and openIMIS.
Technical
- Front (Material-ui, React & Redux, Javascript) in MS active source pages
- Back (Django/Python <> Java)
- University students come with Java and Python
- Database (SQL server)
- HL7-FHIR as data exchange standard (issue: question on database set-up or use an external one?)
- Airflow for monitoring of batch processes
- Migrating mobile application
Academia
- Assets
- Social protection and insurance (with courses on health financing)
- IT programming
- Research component
- Gaps
- Limited tools for practical learning
- Limited real-life scenarios
- Curriculum outdated
- Action Items
- Revisit curriculum to include openIMIS
- Research topics on digital health trends using openIMIS
- Ad hoc projects on openIMIS for collab between IT and social protection
- Short courses on health financing (with openIMIS as a tool)
- IT specialist to support the local openIMIS developers team
COMMUNICATIONS CHANNEL
-Data Confidentiality Onion
- Confidentiality Access
- Public Communication (website) - representative deign
- Team Communication (wiki) - transparent discussions
- Internal Team (forum) - restricted
- Peer to peer (eMail) - confidential
- GIZ Internal - GIZ internal systems
- Communication Platforms
- Issue Queue (Jira)
- Wiki (Confluence)
- Source Code Repository (Git)
- Documentation Repository (Git)
- Etc (Refer to Uwe's list)
-Public Communication
- Corporate Identity
- Brand Guidelines
- Templates (Powerpoint, Banner, Icons)
- Merchandise
- Technical Writing
- Website
- Newsletter and Social Media
- Demo Server
- Documentation
-Team Communications
- Wiki for IC
- Wiki for DC
- Events
- Calendars
- Google Groups
- Google Folders
Reflections:
- Encouraged to talk more about openIMIS and adopt it in the country
- Appreciate the clarification of governance structure
- Importance of communications
- Broaden our systems with openIMIS
- Difference between IMIS and openIMIS and the potential of timing in terms of starting implementation
- Sustainability via academia
- Strengthening the local capacity
DAY 2
Reflections:
-How do we approach the next steps (work plan-oriented)
-Requirements from different countries and find out how we can continue the conversation in Rwanda
-How we can collaborate from the requirements to the development (how the process can be easily managed)
-Communication channels are easily completed
-Some are skeptical about openIMIS
-Participants gained confidence on openIMIS
-Interaction between implementers and developers (communication channels)
-Harmonize and streamline processes
-Interaction, timelines, guidelines
-Connect the global, regional, and national levels
-Knowledge exchange and knowledge production
-Regional hubs roles (what are expected from them)
-Use of tools for knowledge sharing among different country contexts
-How do we make countries contribute to the global good
Implementing
*Private Sector
*Dr Mashaushi and Dr Faraja (Academe they dont have health - IFM), similar gaps with Asia
*Good branding
*KPIs - what are expected from CoPs and timelines
-Template for presentations, etc and documentation of country context stories
JEMBI HEALTH SYSTEMS
-African non-profit company
Jembi's core competencies include:
*needs assessment and requirements gathering
*system design and solution architecture
*software design and solution architecture
*software development
*implementation and capacity-building
Jembi's approach to health information systems
-acknowledging the interconnection between policy, practice, and technology
-focusing on building local capacity to use, manage and maintain the health information systems
-honest brokers of technology
-focus on interoperability
-Project Canvas
Country Engagement
AIM: Viable solution for health financing in low-resource setting
*Country Engagement
-represented in relevant African health information systems communities
*Products and Requirements
-country driven requirements are available to support openIMIS feature refinement and the ongoing development of the system
*Technical Product Requirements and Interoperability
-openimis interoperab
*Implementers
*Capitation
*Technical Architecture
Q&A:
Q: How do you conduct projects in countries?
A: TA, work with local capacity in the country and build that, work with ministries of health, work with openMRS in Cameroon, also do some of the dev work, build capacity with local moh to manage systems,
Q: Interesting to look deeper into, how do you reach out to people, how do you transfer and write messages and communicate to people?
A: System we designed we look at individual country requirements and make it universal and develop that functionality and follow standards from the blood transfusion society. We looked at how we do that product management or project management. A lot of engagement on the user side.
Q: It's important to have the translation part outlined at the beginning. That kind of highlights sustainability in the country.
Q: Interested in process steps. Based on the country assessment, how you went about it? In terms of prioritization and creating the global good? How do you list and select them and prioritize?
A: Slide deck later in the afternoon to check the processes
Q: Besides the blood project, we also have the CRVS project.
Q: What do you need to be onboard? So we can support you in the process?
A: We don't have the health financing knowledge but the more we know about the area. People don't state the point or tell a story that illustrates the point and is able to repeat the point and reiterate. A lot of discussion on how you go about gathering your requirements kind of capacitating in that way. We want to look at health financing and this is how you go about for these requirements. Health financing knowledge so we shape all those discussions. W have a lot of people we can start these discussions with.
Q: Use your networks. Interesting to know your network (later at lunch)
Q: Local capacity-building it may be where the networking part comes in (which may include private sector).
A: Anything for us to read. It's a bit complicated.
Q: Have a presentation on how Jembi is operating in Africa and how we leverage this collaboration. We face a lot of questions on success factors. Our colleagues will be interested in about it. If a possible joint session?
A: We can set up a webinar.
EPOS
-Group of companies in Germany (1985)
-Mainly active in Africa but also involved in hospital planning and supply
-Michael as a freelance consultant (hospital sector)
-Workflows in hospitals (focus on IT system implementation) and see how they can fit in the workflow
-openIMIS (open source approach is a good thing) and might go in the same direction with DHIS2 (university-based)
-To serve whole countries instead of having siloed pilot solutions
-From cap bldg perspective, we should focus on the political decision-makers, play with it, see the benefits
-Easier to have a menu on issues (as multiple choices) - small things that would make it easier to use
SWISS TPH
-Research and tropical diseases, training and cap bldg, health systems programs (education), insurance medicine courses, research activities happening within the institute,
-Department is on the implementation side, siddhart based on the technology side
-Implementation side - doing different health sector sides
-Dragos - health technology and telemedicine
WORK PLAN
Promotion
-Webinars
-Marketing
-Resources (demos, videos)
-Social Media
-Donor side
-Government side
Implementation
-Implementation Starter Kit (ongoing)
-Capacity-building (modules, content)
-Support to the implementation side (resources)
-Usability requirements (Flow of issue queue)
-Focus on rearchitecturing within the development teams
Infrastructure
-Generic training manual
-Generic powerpoint presentation
FAQs on data privacy issues and data analytics
-individual cant enrol themselves (which may translate to new requests)
WEBINAR (Channel it to the african hub)
Youtube channel for openIMIS (where you can upload openIMIS video) as go to channel
Newsletter with key themes (openIMIS central mailing list) link mailing list to central list
Alicia metacards
- Swiss TPH and EPOS support regional hubs (workflows)
- Jembi focus on country support (know who to involve)
- Link up among different groups
- Training courses and implementation starter kit (make sure no double work among hubs) -
- Process flow for requirement gathering
- Messaging and training package and implementer starter kit for Africa
Opportunity to implement openIMIS in Rwanda
-see how we can operationalize that
-immediate next steps: connect the right people to via Jembi
-we don't push any particular solutions
-work is promoting open source solutions specifically in Rwanda
-how the integration will take place
-how will the capacity-building take place
-how this local capacity-building can be done
-Assess based on those recommendations and figure out how we can fill the GPAS then talk to CHAI and ask if we can borrow technical resources
-Start from smaller scale pilot implementation (setting up the implementation and seeing it how it works locally)
-Start to secure some mid-term funding (talk to bluesquare who have linkages to Belgium)
-Ask IT team to send specifications about the platform (send screenshots of the database)
-Parallel approaches in capacity-building
-Mix an interview where you see a speaker and see the text - but these videos are difficult (i recommend to do this)
-Webinars, demo videos, and cap-bldg are important (addressing different audiences at different entry points)
-Comm materials for different target groups
-Training assets as we move along the implementation
-There needs to be a starting document on training assets and material development even though we have country-specific materials
-Audiences for training materials
- Policy-makers
- Technical training in Africa (digital square, jembi, digital health course), hackathons
- End-users (videos of country projects)
-Local office of GIZ in Cameroon
- Better understanding of GIZ
- Want to push through with the program (full round) to reach to the population in providing health insurance with BEPHA structure
- Government is reflecting on implementing a national system for health insurance (but expensive) so openIMIS is another alternative the government is looking at
- Interested in accompanying the implementers side when decisions or improvements are made and benefit from the improvements
- Better training of users/ demonstration (in government)
- Needs (use the full rollout of the openIMIS) otherwise we're working on a limited scope
- More comprehensive understanding of the openIMIS
- Political issues
- Focal point for f, africa
-Tanzania (what we can do for openIMIS Implementation)
- 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
- 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 monolithic 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
-download an application (self-extracting thing) and explore and play with this
-political side to be easily attracted
*workbook type per each phase - make it more participative - complement the manual
-resources needed (physical, cost)
stakeholder engagement
identification of stakeholders
-onboarding workshop
-use case scenario (examples)
-standard texts on the wiki
-Categories
-Ownership of countries
-registration why she is interested (data on persons)
-Demo use
-Demo script
-user stories in each country
REFLECTIONS:
-Instructional video in Africa
-FAQs by Michael
-Step-by-step concept for policymakers by Michael
-User journey for communications strategy
-Issue queue by Dragos
JEMBI
-Technical assistance (define what is TA)
-contribute where we can in assessment reviews
-more general webinar on implementation learnings (requested by CHAI)
-starter kit
-engagement with AeHIN (work with them for work with universities)
CAMEROON
-Cameroon as part of the IC
-demo for the government
-Capacity to better understand openIMIS
SWISS TPH
-release cycle
-transfer this to the issue queue
-IFM coordination with AeHIN
-How are we aligning the communication in the broader activities
GIZ
-open initiative (not a top down approach)
-tracking work packages via kanban
-open to new contributors and stakeholders
-looking forward for Tanzania to be more integrated