Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »


Date: February 15-16, 2018

Location: Sea Cliff Hotel, Dar es Salaam

Moderator: Christian Pfleiderer


DAY 1 


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

FunctionalitiesObservationChallengesRecommendation
A. Members' Enrollment
  • QR codes linked to members
  • Still very much paper-based
  • No waiting period
  • No means of confirming the family size
  • Need to connect payment system
  • Clarify functionalities of openIMIS
  • Clarify that openIMIS is not an EMR
  • Incorporate GPS information with home enrolment (outbreak mapping)
  • Incorporate GPS information with the image of the applicant
  • Incorporate biometrics (e.g. Cameroon)
  • Define and operationalize a 'household' 
  • Link openIMIS with registries (e.g. social registry)
  • Link openIMIS with other systems
  • Broaden registration form to accommodate socio-economic data
B. Patient Identification and Service Utilization
  • Staff input data quickly on mobile
  • Easy to understand
  • Users felt comfortable
  • Shall allow multi-diagnosis (diagnose entry field should display not just the ICD code to prevent mistakes at entry)
  • Shall ensure data protection (staff shall not use their personal device for accessing data)
  • Diagnose code should be number + text (this has w positives and negatives - issues of data security)
  • Reference coding catalog in the backend
C. Claiming Process
  • Users were well-informed about the application and operate it effectively
  • Batch processing shall allow viewing of monthly summary by regions, by a person, by a health facility, or by a group of facilities 
  • Review the billing system
D. Other Remarks
  • Bringing the service closer to the people
  • Computer software is not bilingual
  • Develop a bilingual system for computers, not just the mobile app version


Group 2

FunctionalitiesObservationChallengesRecommendation
A. Members' Enrollment
  • Duplication of data entry/ similar data are entered in different systems (e.g. patient registry, claims, patient record)
  • Enrolment officer has no access to the membership database (no way to track)
  • Lack of trust in the technology
  • Data privacy concern about keeping data on the phone and the security issues related to this (theft, etc) → currently, only aggregated data are reported
  • Show summary information after enrollment (not aggregated count)
  • Send report/ overview of members to enrolment officer
B. Patient Identification and Service Utilization
  • No ID check/ household identification
  • Patient membership verification during powercut or offline mode is a challenge (lack of data and picture in the database if without internet)
  • Cards don’t have photos which make it difficult for illiterate people to know which card is theirs
  • Definition of household is loose (up to 6 people)
  • Household renewal and identification in the whole unit
  • Family number attached to the individual (Ex: In Ethiopia, facility health worker can see the household unit linked to card number)
C. Claiming Process
  • Code list of services is difficult to memorize (list is in the app)


D. Other Remarks
  • Capitation 
    • Diagnosis entry (reimbursement system calculated on a number of cases but the provider still needs to add diagnosis in openIMIS)
    • Prescription information needed but the burden of data entry is on the user and no incentive to enter full data (Should we be putting this level of effort on the provider when this data is not required for capitation payment?)

  • Potential to harmonize/integrate data entry


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, Swiss TPH, SolDevelo, Possible Health
    • Implementation Committee
      • Communication: FFW
      • Capacity: SwissTPH and EPOS
      • Community: AeHIN and Jembi
  • Clarifications
    • openIMIS as an avenue to create an environment for solving issues
    • Specific country customizations to be done by the responsible payer in the system
    • 2 versions at least in a year
    • Data ownership is locally managed
    • Plans for 2019: small releases, knowledge production, development of the 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, 
  • Country implementations 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 openIMIS
  • 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 an ESB as an interoperability 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:

  • 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? 
    • Unanswered due to time limit


E2. Parallel Session: Implementers Committee

  • Aim: UHC through health financing systems
  • 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 
  •  How do we use openIMIS? (the more fee for service-focused, the more information we need; always need data if we want to move away from a general budget)
    • Registration / enrollment (also collect money)
    • Verification of member
    • Claims submission
    • Claims review 
    • Client feedback
    • Reporting (what are you diagnosing, getting money for etc)
  • OpenIMIS is a flexible tool that can be used for many health financing schemes (NI, tax funded national health system, community-based health fund, vouchers scheme, strategic purchasing arrangements)
      • Next Steps for openIMIS (Global Level)
        • Position OpenIMIS globally as a 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 for openIMIS (Local Level)
        • Bringing new countries onboard
        • Current countries: RW, MW, CAM CH
        • Country assessments to gather requirements and software functionality requirements
        • Expansion of a network of developent and implementing partners (support possibilities for country-level implementation)
        • Implementation steps
          • Starter kit
          • Costing estimates
        • Demo on software
          • Online video
          • Wiki guide
        • Capacity-building: alliances and strategic partnerships

Q&A Session:

  • From the persepctive of operators already using a system, would you have to do this twice?
    • Different insurance providers have different systems. Can look at interoperability from single form for data import
    • Parallel systems currently running. It’s a policy level decision
  • 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 capacitated?
    • There shall be communication between local and global implementers.
    • Self-learning via wiki platform and via github for architecture.
  • 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 the redesign?
    • Two modules by end of 2019 but the size of the modules are not yet clear.
    • Roadmap and timeline by the end of Feb 2019. Until then, we will be sticking with the MS based system for implementation. It should also allow for a seamless transition to a modular approach
  • Would you know about the licensing agreement (when it will be offered for free)?
    • At the end of February, they would most probably know about the new architectures
  • Can this whole work be done offline?
    • Enquiry part is still online
  • 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 are that the database layer exchangeable that can be run on a Microsoft server and Linode server.
  • Recommendation: Big opportunity to involve developers from pioneer countries like Tanzania (re-architectural phases, etc)
    • Academic outreach with universities
    • Need to involve local institutions like academia as early as now (to include openIMIS in their curricular activities)
  • Recommendation: Local private software firms may be willing to participate in the developers' committee.
    • Universities can be entry points for capacity-building. 
  • Comment: Potential for openIMIS to interoperate with other systems or existing systems that are up and running (GOTOHOMIS, etc)
  • Comment: Claims management demo for rejection reports


F1. Parallel Session: Country System and Requirements in Tanzania

National Rollout
GovernanceHarmonization/Business ProcessesFeature RequestsChallenges
  • Adoption of SWAps (Sector-wide Approaches)
  • Proposed governance structure
    • Health Financing Technical Working Group
    • CHF Implementers Group
    • PORALG CHF-IMIS Technical Committee
  • Policy on installment of payments (a question right now)
  • CHF is a standard product (current rollout)
  • GIZ still at the beginning
  • Harmonize strategy for enrolment officera
  • Issues on mismatch of finances
  • Electronic payments/ mobile money
  • Inform clients of payments + renewals
  • Different programs give different hardware (progressive web app)
  • Integration with facility system
  • CHF-IMIS and NHIF integration
  • Data points need to be aligned - client
  • Diagnosis and other integration points between NHIF and CHF
  • Hardware needs 
    • MOH ICT - Sotto
    • PORALG ICT - Kitali
  • Unclear policy/ national direction
  • Contribution payment
  • Resource mapping
    • Hardware/infrastructure (mobile phones/tablets)
    • Coordination among DP+ national
  • Shouldering of costs
    • SMS costs 
    • Hardware costs
    • Administrative costs (Forms, cards, etc)
    • Training costs 
  • Hardware: Lack of phones for enrolment officers
  • Capacity-building: Large number of people to train and the high cost of training

Other Issues:

  • 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



F2. Parallel Session: Country System and Requirements in Cameroon

PayerBEPHA (Bamenda Ecclesiastical Province Health Assistance)FRPS (Fonds Régionaux pour la Promotion de la Santé)
Population GroupGeneral Population
  • Pregnant women
  • Newborn up to 42 days
Provider

Accredited Facilitiies:

  • Confessional
  • Public
  • Private

Accredited Facilities:

  • Confessional
  • Public
  • Private


Benefits Package (services and prices)

  • Services are defined for outpatient and inpatient
  • Different prices based on contract
  • Contract-based
  • Medical and non-medical services
  • Same prices for all providers
  • Contract-based in three regions
Enrollment/Registration
  • Manual + openIMIS (computer-based)
  • For 2019: Use of mobile phones
  • Paper-based entitlement for services (5 paper sheets - manual)
  • Registration for the voucher 
    • Pay when register
    • National ID/phone
  • Schemes
    • 10 % co-pay
    • 90 % subsidized
Claiming 
  • Manual + openIMIS (computer-based)
  • For 2019: Use of mobile phones
  • All bills sent on paper
  • Registry list
    • Voucher #
    • Date
    • Treatment
Claims Verification
  • Manual
  • For 2019: Use of mobile phones
  • Paper to excel
  • Longitudinal follow-up not possible
  • Claims rejection may be possible
  • Admin review 
    • Accountant secretary
    • Financial admin clerk checks excel (can ask bills)
    • Medical officer checks bills and examination (only 2nd category selected for check)
    • Regional office approves
    • The total budget to be divided by family
  • Medical review
    • Adherence to guidelines
    • Quality checks by medical supervisor
Digital Process (Which Parts?)
  • Enrolment
  • Claims
  • Specification is ongoing
  • Concept is under development (deadline end of March)
Support Needs for Next Steps
  • Capacity-building
  • Equipment
  • Material (QR code)


F3. Parallel Session: Country System and Requirements in Rwanda

PayerRSSB (Rwanda Social Security Board) MOHRSSB (Rwanda Social Security Board) Medical SchemeMilitary Medical SchemePrivate Insurance
Population GroupInformal SectorFormal SectorMilitary PersonnelPrivate Organizations and Others
Provider
  • Public 
  • FFs
  • PPCP (a few)


  • Private (mainly)
  • Public
  • FFs
  • Private (mainly)
  • Public
  • FFs
  • Private
  • FFs
Benefits Package (services and prices)

Defined Benefit Package

  • Uniform package
  • Different tariffs based on the plan of the health facility level
MOH-defined Benefit Package (with flexibility)MOH-defined Benefit Package (with flexibility)Health plan-defined benefit package
Enrollment/Registration

3Ms (Mutuelle Membership Management Software)

  • ePayment
  • Enrolment

Can the monolithic IMIS integrate with membership?




Claiming Manual 


Claims VerificationManual (except the payment process)ManualManual
Digital Process (Which Parts?)



Support Needs for Next Steps
  • Digitization of claims
  • Automation



F4. Parallel: Country System and Requirements in Chad

PayerMutuelles de SanteCNPS (Caisse Nationale de Privoyance Sociale)CNAS (Caisse Nationale d'Assurance Sante')
Population Group
  • Informal Sector
  • Communal
  • Professional
  • Formal Sector
  • Private and Public Workers
  • Universal 
Provider
  • Public Providers
  • Private Providers
  • Faith-based


Benefits Package (services and prices)
  • Primary care
  • Secondary care
  • Tertiary care
  • Primary care
  • Secondary care
  • Tertiary care

Enrollment/Registration
  • On paper
  • Excel
  • openIMIS (test)
  • Paper + excel

Claiming 
  • On paper
  • Excel
  • openIMIS (test)
  • Paper + excel

Claims Verification
  • Monthly verification FOSA
  • Punctual Medical Adviser Network 
  • Internal management information system

Digital Process (Which Parts?)NDN (openIMIS en test)NDN (openIMIS en test)
Support Needs for Next Steps
  • Capacity-building
  • Equipment (computers, phones)
  • Material/QR code
  • Institutional support
  • Information system



Q: Is there a sustainability plan for CBHI?

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. 



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. 


F5. Parallel Session: openIMIS Technical Discussion

  • Front (Material-ui, React & Redux, Javascript) in MS active source pages
  • Back (Django/Python <> Java)
  • 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


F6. Parallel Session: openIMIS in the 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 collaboration between IT and social protection
    • Short courses on health financing (with openIMIS as a tool)
    • IT specialist to support the local openIMIS developers' team


G. Communication Channels

-Data Confidentiality Onion

  • Confidentiality Access
    • Public Communication (website) - representative design
    • 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


H. 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







































































  • No labels