Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

B. Field Trip Experiences


Group 1

Functionalities

Observation

Challenges

Recommendation

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

Functionalities

Observation

Challenges

Recommendation

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: openIMIS Country System and Requirements in Tanzania

National Rollout

Governance

Harmonization/Business Processes

Feature Requests

Challenges

  • 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

  • Active policies

  • Application that runs on any hardware

  • Different programs give different hardware (progressive web app)

  • Integration with facility system

  • CHF-IMIS and NHIF integration (client registry might have overlapped with insurance system - integration needs to be aligned re data capture, standardization on NHIF and CHF)

  • 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


F2. Parallel Session: openIMIS Country System and Requirements in Cameroon

Payer

BEPHA (Bamenda Ecclesiastical Province Health Assistance)

FRPS (Fonds Régionaux pour la Promotion de la Santé)

Population Group

General 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: openIMIS Country System and Requirements in Rwanda

Payer

RSSB (Rwanda Social Security Board) MOH

RSSB (Rwanda Social Security Board) Medical Scheme

Military Medical Scheme

Private Insurance

Population Group

Informal Sector

Formal Sector

Military Personnel

Private 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 Verification

Manual (except the payment process)

Manual

Manual


Digital Process (Which Parts?)





Support Needs for Next Steps


  • Digitization of claims

  • Automation




F4. Parallel: openIMIS Country System and Requirements in Chad

Payer

Mutuelles de Sante

CNPS (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



Country Q&A:

  • Recommendation: In Cameroon and Rwanda, there are no enrolment features. Cameroon might want to customize it in their country as we are developing a master version.

    • Government wants 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.

  • Recommendation: Microsoft training - we have done video tutorials. We can create training in each region via video.

  • Question: Standards for claim management or wait for the openIMIS software to be ready?

    • 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


A. Expectation Setting

...

-Sustaining openIMIS through the academia (both in Asia and Africa)


B. Community: Regional  Regional Hub in Asia (Asia eHealth Information Network)


  • Overview: pool of professionals from South and Southeast Asia committed to promoting better use of ICTs to achieve better health

  • Membership: over 1000+ professionals in eHealth, HIS, and CRVS in 25 countries

  • Strategic Areas

    • Enhance leadership and governance for digital health

    • Achieve interoperability through appropriate use of standards

    • Create opportunities for knowledge exchange and resource sharing

    • Offer capacity-building for digital health (Mind the GAPS)

      • Governance

      • Architecture

      • Program Management

      • Standards and Interoperability

  • Community of Practice on openIMIS

    • Overview: openIMIS Community of Practice in Asia is a regional hub of health education institutions, medical student associations, in-country interoperability labs, and other related networks that actively review, implement, and evaluate openIMIS in various use cases, particularly in the academic setting, to support the application of ICT solutions for social health protection. 

    • Goal: Management of social health insurance and other health protection schemes to achieve universal health coverage(UHC) through openIMIS

    • Vision: Position openIMIS as a global good that can support the application of concepts and skills on social health protection and health informatics

    • Mission: Strengthen the openIMIS community in Asia by contextualizing capacity-building strategies and supplementary knowledge materials with the reality of concrete country cases

    • Partners: University of the Philippines Manila, University of Gadjah Mada, University of Colombo

    • Domain: ICT Solutions for Social Health Protection

    • Community:

      • Health Education Institutions

      • Asian Medical Student Associations

      • Network of Health Informatics Faculty

      • Network of Medical/Nursing Students,

      • Country Interoperability Labs in AeHIN Member Countries

    • Practice/Strategy:

      • Establishment of Country Hubs

        • Advocate for the establishment and strengthening of the openIMIS Asia Regional Hub, with a particular focus on the Asian Medical Student Associations and Health Education Institutions

        • Form a network of faculty members who will advocate the use of openIMIS (for teaching)

        • Form a network of medical/nursing students who will advocate the use of openIMIS (for learning)

        • Create further use cases to support countries with little experience in health financing

      • Development of IEC (Information, Education, and Communication) Materials

        • Conduct needs assessment on how Health Education Institutions can integrate openIMIS into their curricula

        • Develop short courses on setting-up and using openIMIS in Health Education Institutions

        • Prepare training materials on setting-up and using openIMIS in Health Education Institutions

      • Capacity-building and Technology Transfer

        • Conduct training of trainers workshop/s among country hubs (inception, capacity-building, and completion workshop)

        • Provide an online meeting and online training platform to demonstrate the application of openIMIS in Asia

        • Provide an enterprise architecture tool to manage architectural artifacts of openIMIS in Asia

        • Create separate cloud instances for openIMIS in each country

      • Interoperability Testing

        • Test the interoperability of openIMIS with health information systems being used in a country

        • Integrate the country’s preferred health information system with openIMIS

      • Regional Knowledge Sharing and Networking

        • Conduct knowledge sharing activities to document experiences of openIMIS Asia Regional Hub (best practices, lessons learned, and technical recommendations)

        • Conduct webinars on the progress of openIMIS Asia Regional Hub

        • Conduct face-to-face meetings to gather the country hubs of the openIMIS Asia Regional Hub

        • Promote openIMIS through digital marketing and public relations initiatives in Asia

      • Strengthening of Public Goods

        • Support the openIMIS community in its implementation and capacity development strategy with focus on experiences from Asia

        • Coordinate with openIMIS Africa Regional Hub to develop global goods

        • Connect with Health Education Institutions in Europe and Africa on incorporating openIMIS in the academic setting

        • Document the activities conducted in the openIMIS wiki (wiki.openimis.org)

    • Country Plans (Philippines)

      • Identify participating medical and nursing schools

      • Customize openIMIS Manual for use in the clinical skills lab

      • Provide openIMIS-on-the-cloud to participating schools

      • Train faculty and selected students on how to use openIMIS in the clinical skills lab setting

    • Country Plans (Indonesia)

      • Identifying the learning objectives of the relevant courses

      • Develop specific learning and instructional courses based on the openIMIS features

      • Develop scenarios for learning and assignment

      • Collect students experiences on using openIMIS

      • Feedback from users during the exercise

      • Disseminate the results to AeHIN and BPJS Kesehatan

    • Next Events:

      • International Smart Hospital Forum (March 2019 in Taiwan)

      • Telemedicine Conference (July 2019 in Kuala Lumpur)

      • Laos and/or Siem Reap (July 2019)

      • Big Data, Machine Learning, and Artificial Intelligence (partnership with MIT Critical Data) in October 2019


C. Community: Regional Hub in Africa (Jembi Health Systems)

  • Overview: African non-profit company

  • Core Competencies:

    • needs assessment and requirements gathering

    • system design and solution architecture

    • software design and solution architecture

    • software development

    • implementation and capacity-building

  • 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 (openIMIS)

    • Aim: OpenIMIS is the reference tool for the OpenHIE UHC component and viable solution for health financing in low resource settings

    • Country Engagement

      • Output: OpenIMIS is represented in relevant African health information sytems communities

      • Activities:

        • Represent OpenIMIS on relevant HIS communities calls

        • Represent OpenIMIS at relevant workshops and conferences (funding permitting)

        • Provide TA to countries looking at implementing OpenIMIS as a health financing system

    • Product and Requirements

      • Output: Country driven requirements are available to support OpenIMIS feature refinment and the ongoing development of the system

      • Activities:

        • Facilitate discussions with countries to validate requirements and gather new requirements for OpenIMIS

        • Develop OpenIMIS presentation and training materials

    • Technical Product Requirements and Interoperability

      • Output: OpenIMIS interoperability workflow and technical specifications are documented

      • Activities: 

        • Define and document OpenHIE workflows for UHC

        • Define and document interoperability workflows relevant to OpenIMIS

        • Reference standards and APIs for OpenIMIS interoperability with OpenHIE stack

    • Implementers

      • Output: More implementation and funding partners involved in OpenIMIS implementation in Africa 

      • Activities:

        • Work with existing networks of implementing organizations to identify partners with the capacity to implement OpenIMIS in Africa

        • Work with existing networks of donor organizations to identify partners with interest in supporting OpenIMIS implementations

        • Expand network of potential partners to support OpenIMIS implementations

    • Capitation

      • Output: Contribution to the requirements for capitation within OpenIMIS are definition and documentation

      • Activities:

        • Consultation with capitation experts

        • Work with countries within the relevant HIS communities to define the use cases and requirements for capitation in low resource settings

        • Document requirements for capitation in low resource-settings

    • Technical Architecture

      • Output: Contribution to the renewed OpenIMIS architectural design

      • Activities:

        • Define and document FHIR interoperability workflows for OpenIMIS

        • Provide appropriate tech design TA from Jembi experience


Q&A Session:

  • How do you conduct projects in countries?

    • Work with local capacity in the country and build on that (build capacity with local moh to manage systems)

    • Work with ministries of health

    • Work with openMRS in Cameroon

    • Also do some of the dev work

  • How do you reach out to people? How do you transfer knowledge and communicate with people?

    • In the recent system we designed, we look at individual country requirements and make it universal and develop that functionality, also following the standards from the blood transfusion society.  A lot of engagement on the user side (project management).

    • Besides the blood project, we also have the CRVS project.

    • It's important to have the translation part outlined at the beginning. That kind of highlights sustainability in the country. 

  • Based on the country assessment, how did you go about it? In terms of prioritization and creating the global good? How do you list and select them and prioritize? What are the processes?

    • Slide deck later in the afternoon to check the processes

  • What do you need to be onboard? So we can support you in the process?

    • We don't have the health financing knowledge. We want to look at health financing and to guide them how you go about for these requirements. Health financing knowledge so we shape all those discussions. We have a lot of people we can start these discussions with. 

    • Anything for us to read on health financing.

  • Interesting to know your network (later at lunch)

    • Local capacity-building it may be where the networking part comes in (which may include private sector).

  • 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 it. If a possible joint session?

    • We can set up a webinar.


D. Capacity-building: EPOS Health Management

  • 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


D. Capacity-building: Swiss Tropical and Public Health Institute

  • Research and tropical diseases, training and capacity building, health systems programs (education), insurance medicine courses, research activities happening within the institute,

  • Department is on the implementation side (Siddhart: technology side; Dragos: health technology and telemedicine)

  • Implementation side in the health sector

  • 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

General Recommendations/Comments:

  • Develop FAQs on data privacy issues and data analytics

  • Use of the AeHIN webinars to share updates from the African hub

  • Create Youtube channel for openIMIS (where you can upload openIMIS videos) 

  • Create central mailing list for openIMIS (with key themes); link mailing list to central list

  • Create workflows to enable Swiss TPH and EPOS in supporting regional hubs 

  • Identify stakeholders from the network of Jembi to involve in the country support 

  • Link up different groups in the implementation committee

  • Ensure no double work among hubs in developing training courses and implementation starter kit 

  • Develop a process flow for requirements gathering

  • Prepare a training package and implementer starter kit for Africa 

  • Take parallel approaches in capacity-building to address different audiences at different entry points

    • Webinars

    • Demo videos

    • Training 

  • Develop communication materials for different target groups

  • Develop 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)


E. National Implementation: Rwanda

  • Operationalization

    • Explore how will the local capacity-building take place

    • Explore how will the integration be done

  • Stakeholder Engagement

    • Coordinate with Jembi to connect the right people in the initiative 

    • Coordinate with CHAI to request/borrow technical resources based on the identified gaps and recommendations

  • Approaches

    • Promote open source solutions

    • Start from smaller scale pilot implementation (setting up the implementation and seeing it how it works locally)

    • Secure some mid-term funding (talk to blue square who have linkages to Belgium)

    • Ask IT team to send specifications about the platform (send screenshots of the database)


F. National Implementation: Cameroon

  • Plans: 

    • Government is reflecting on implementing a national system for health insurance (but expensive) so openIMIS is another alternative the government is looking at

    • Want to push through with the program (full round) to reach to other populations in providing health insurance with BEPHA structure

    • Interested in accompanying the implementers' side when decisions or improvements are made 

    • Coordinate with the local office of GIZ in Cameroon

  • Needs:

    • Use the full rollout of the openIMIS otherwise we're working on a limited scope

    • Improve training of users

    • Prepare demos for the government

  • Issues:

    • Political issues

    • Focal point for Africa


G. National Implementation: Tanzania

  • Scenario: Roll out to 26 regions (Ministry of Health)

  • Plans:

    • Reaching other communities in Tanzania

    • Translating user stories in Swahili to be transmitted to the global level (we want other nations to learn from it as well) - this is our vision based on the symposium from the government point of view

  • Needs:

    • Have a good communication channel as a country

    • Know the timeframe of requirements (how long will it take to be delivered)

    • Create a pool of local developers who can develop our requirements (small and specific requests need to be created at the country level) which may also benefit the global level

    • Develop local modules and undergo training of trainers when a new feature is developed

    • Develop training courses via local academia (field workers can get knowledge from the institution)

  • Issues

    • Challenges on the health insurance system (we should walk with other countries)

    • Possible national extension - EMRs need to interface or communicate with other countries

  • Suggestions:

    • 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)

    • Document experiences from the field through communication materials and feedback into the community


H. Issue Tracking (Jira) 

  • Issue (Refer to Dragos' diagram)

    • Ask question 

    • Raise a bug

    • Request new feature

  • Waiting for support

  • Waiting for customer

  • Pre-testing

  • In-progress

  • Resolved


Open Forum:

  • Prioritization of issues

    • Prioritization is decided at the level of technical advisory group

    • Release cycle involves different committees 

  • Suggestions:

    • Segment priorities into high priority, medium priority, low priority for country requests

    • Redefine the development and implementation aspects of issues

    • Only the committee can identify an assignee to an issue 

    • Automatic email response for requests should come with a link indicating the next steps on how to go about the request

    • Include radio button selection from the get-go to narrow down issues and make it easier for the users

    • Before hiring an external developer, inform first the developers' committee

    • Appoint a focal point in each country to have a linkage into the global issue queue

    • Assign some issue to an academic group (a group of students to a look at an issue queue) 

    • Conduct capacity-building with local partners for issue escalation (Learn from the openLMIS experience)

      • Ticket submission by a local partner (local implementation partners do the first round of filtering) 

      • Consensus-based priority by the global committee (look if a specific country request will affect a lot of people) 

      • End-user → local implementing partner → global committee

      • Question: Local queue system per country (send email to the system then goes to the email of a group of people then a ticket gets assigned to somebody logged through a focal point in a country)?

        • Clarify with openLMIS

    • Screenshot must be attached to requests for faster correspondence

    • Proposed process:

      • 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

        • Create substeps for IC & DC

  • Issues:

    • Define differences in priority (who will decide?)

    • Functional requests have overlap with the development side (issues on the service desk needed to be channeled either to the developer or implementers committee)

    • Do we use a single tracking system? (Tanzania uses a different one)

    • Should we integrate external developers in the Jira issue queue?

    • Should we maintain the local solutions from countries to the global github?

      • It's 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 into the platform without the rest of the world knowing about it

  • Others

    • Jira can also accommodate other requests apart from the country-specific implementation side

    • Average reaction time for response is 24 hours according to the SLA

    • Hubs as part of the process (part of the issue queue)

  • Rwanda 

    • Step-by-step proposal for Rwanda (tailor it to the size of the implementation)

    • The rollout is mostly training of users (depends on location as well)

    • Rough estimation only because it depends on the country cost

  • Tanzania

    • 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: Build capacity for the local teams (developers in each country) 

      • If we document and escalate all to the global level, maybe the 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 moment you are working with the epayment application, so other countries may not need to do the same and use the same

    • Issues:

      • Open source advantage and disadvantage

      • Maintenance and support

        • Global team: Before we accept any contribution, they need to follow the policies or tests, before it goes to the master version

        • Establish communication/contact when you bring in a new developer so they are aware of the global initiative

      • If Cameroon can engage local developers (but you are not assured of their competency), who responds with health-related?


I. Release Cycle

  • Inter-project Collaboration

    • Maintenance and Support Project

      • Legacy system support

      • New functionalities update

      • Technical support

      • Demo server update

    • Capacity-building Project

      • User needs

      • Issues

      • Functional Specifications

    • Modular Transformation Project

      • Architectural changes

      • Packaging mechanism

  • Development Life Cycle

    • Analysis and Requirements (input: capacity-building)

    • Architecture, R&D, Prototyping (input: modular transformation and Digital Square HL7/openHIE interoperability)

    • Design and Development

    • Testing and Quality Assurance

    • Release Management (input: modular transformation)

    • Training and Product Support (output: capacity-building, modular transformation, Digital Square HL7/openHIE interoperability)

    • Maintenance

  • Maintenance and support project planning

    • 6 months release cycle

      • 4 months of development 

      • 2 months of support/ specification or requirements gathering

    • Next release cycle

      • April 2019

      • October 2019

      • April 2020


Open Forum:

  • Make sure there is enough time for developers

  • Time between requirements gathering and process where implementers committee contribute to the process of the release cycle depends on a matter of how many releases come out

  • Collection of requirements will go the issue queue

  • How to modify to bring in the implementers committee (hubs)

  • When do we start or put the process into the diagram

  • Who will be the coordinator (go back and forth), who will be responsible in each part, who will communicate

  • Define another step to generalize solution on the business side and developer side (go straight into the queue)

  • Prioritization mechanisms and who will decide

  • Take into account the process of testing to make sure it all complies with the requirements before the release (Testing is important because of many scenarios in health insurance_

    • Set up a test server (end user acceptance test will be placed mid-year)

    • Deploy it in the user demo server (online or offline) then give them time to test; usually two months

    • Put it in the live system

  • Master version release then testing

  • If someone can have a look at the user perspective then wait for countries to give you feedback or you can have a sub-release

  • Beta-release (not tested in the field yet)

  • Categorize development stuff during requirements gathering

  • Once the new release is coming out, developers can still continue with the development (we should not have a particular period)

  • New developments will be on the modularization component

    • Modular transformation and integrations

    • Change the system architecture and developer platform, database (from monolithic to modular architecture)

    • Re-architecture will change the back-end but user functionality will remain the same

  • For the maintenance component, it will focus on maintaining or holding the system together

  • Two business analysts (not full time) in the team as of the moment

  • Consider the naming of openIMIS versions


J. Implementation Starter Kit

  • Examples for reference

    • iHRIS 

    • openLMIS

  • Business processes mapping to demonstrate a user journey

  • Test database where we can populate and experiment

  • Enable download of an application (self-extracting thing) and explore and play with this

  • Make the starter kit more participatory by including scenarios/examples and worksheets in each phase

  • Starter kit should complement the training manual

  • Upload standard texts/content on the wiki

  • Promote ownership of countries 

  • Prepare demo use cases and scripts

  • Prepare user stories in each country

  • Action Items

    • Jembi (Rhonwyn), AeHIN (Kristin), and Swiss TPH (Siddhart) to jointly work on the implementation starter kit

    • EPOS (Michael) to work on FAQs

    • EPOS (Michael) to work on a step-by-step concept for policy-makers

    • Swiss TPH (Dragos) to work on the issue queue

    • Others

      • Instructional videos for Africa

      • User journey for communications strategy


K. Reflections


JEMBI

  • Technical assistance (define what is TA)

  • Contribute where we can in assessment reviews

  • More general webinar on implementation learnings (requested by CHAI)

  • Implementation starter kit 

  • Engagement with AeHIN for engaging universities


AEHIN

  • Capacity-building for our CoP (inception, training, and completion workshops) with the help of the global team

  • Focus on openIMIS in the sphere of the academe

    • Sustain openIMIS by strengthening user base in universities

    • Collate user feedback from country hubs

    • Produce research paper on openIMIS

    • Develop capacity-building program on openIMIS for health education institutions in Asia

  • Leverage the use of webinars as a platform for knowledge sharing

    • Schedule internal meetings on openIMIS (with CoP Asia)

    • Schedule public webinars on openIMIS (also invite Jembi)

  • Leverage digital health-related events to promote openIMIS

    • Present openIMIS

    • Scope user requirements/situational analysis with potential users

  • Contribute to the implementation starter kit 

    • Pre-implementation (suggestion): requirements definition and resources mapping (physical, human, and financial)

    • Live (suggestion): onboarding workshops

    • Post-implementation (suggestion): m&e mechanisms


CAMEROON

-Cameroon as part of the IC

...