1. HIV CASE BASED SURVEILLANCE IN KENYA
By: Wanjiru Waruiru
University of California San Francisco
December 13, 2017

2. What is HIV Case Reporting?
HIV Case Reporting refers to the method used to capture individual-level information on persons infected with HIV
Each person with HIV infection is reported as a single case (adult or paediatric) containing information that pertains only to that person
Data is collected in a longitudinal manner allowing the MOH to follow the individual over time (from diagnosis to death)
Presenter: There are various mechanisms of HIV surveillance, case reporting will capture individual-level data, allowing for de-duplication of data and tracking of an individual over time.

3. Why Implement HIV Case Reporting?
To strengthen HIV surveillance systems by developing a nationwide reporting system that covers the spectrum of the epidemic (HIV infection, disease progression, and care and treatment outcomes)
To characterize important factors in the epidemic
HIV prevalence (how many people living with HIV)
How many are currently on care or treatment
How long it takes to get individuals from diagnosis into care
How many initiate ART
How many are virally suppressed
How many HIV infected people have died
The characteristics of all these individuals (age, sex, where they live, where they obtain care)
Presenter: A national reporting system will enhance surveillance of HIV epidemic and the cascade of care.

4. Key HIV Surveillance Data
Death
HIV Infection
Primary prevention
Secondary and tertiary prevention
Information on uninfected persons
Number at risk
Characteristics
Risk behaviors
Use of prevention interventions
Location
Accessibility
Information among HIV+ persons
Number infected
Characteristics of infected population
Mode of transmission
Disease stage at diagnosis
Disease progression
Exposed partners and children
Linkage to care
Retention in care
Receipt of recommended services
Mortality among HIV+ persons
Vital statistics for HIV and non-HIV causes
Incidence
Number new infections
Mode of transmission
Characteristics
Location
Linkage to care
Use of prevention interventions

5. Benefits of HIV Case Reporting
Ability to match care and treatment events for an individual over time
Ability to have de-duplicated cases in a database
More timely data on the epidemic
More accurate calculation of the cascade of care
# diagnosed  # linked to care  # retained in care  # prescribed ART  # virally suppressed
Improved monitoring of mortality
Allows flexibility in types of analysis that may be required
Presenter: There are many benefits of case reporting nationally, as well as to the county and programs.
Read the slide.

6. How HIV data are currently collected in Kenya
Aggregate
Monthly and quarterly reports
Unable to de-duplicate (person can be reported multiple times)
This is good, but can be improved….
Presenter: Currently aggregate data are collected from facilities each month, this is an example table. Since data are aggregate, you can’t tell if someone is in the data more than one, for example when they transfer to another facility, they would show up as a new case or new to care.
Number in County Started on ART by month, 2013

7. How case reporting can enhance the current data collection system
Reported AIDS cases in [insert year] by age and sex
Presenter: Describe the two figures 1) shows individual cases by total HIV cases, AIDS cases, and deaths over time, and 2) number of cases virally suppresse by sex and year. These data are un-duplicated.
Annual trends of new reported HIV cases, new AIDS cases and deaths of people with HIV, 2003– 2013
HIV viral load suppression rates by gender and year of HIV diagnosis,

8. CBS Process Assessment
Objectives
Gauge staffing needs, person-time required, training and equipment needs for implementation of HIV case reporting
Determine the most efficient and accurate methods of data collection
Assess the availability and quality (accuracy and completeness) of data for case reporting
Review sources of data (standardization, uniformity, availability)

9. CBS Process Assessment
Summary
Data collection from December 2014 to January 2015
27 facilities in Kisumu and Siaya counties
A total of 1,575 cases collected; 138 paediatric (<15 years)
90% of MOH forms contained the data elements required for CBS
Data completeness and accuracy can be problematic specifically for: date of diagnosis, clinical numbers, lab-related variables

10. CBS Process Assessment
Recommendations
Implement case reporting in a phased approach
Collect new cases and sentinel events for routine surveillance
Integrate CBS into routine county-level surveillance activities
MOH to reinforce following standard format for data collection, especially the assigned clinic number to allow for de-duplication
The use of a national unique identifier needs exploration
Evaluate the completeness and accuracy of EMRs for inclusion
Encourage the facilities to keep original date of diagnosis, even if retested to confirm diagnosis

11. Piloting HIV Case Reporting in Kenya

12. Objectives
Determine if the existing data sources capture what is needed for case reporting
Test the database and the system
Review the quality of the data the system generates
Determine the best method and costs to scale it up
Presenter: The pilot is an expansion of the process assessment and allows us to test the tools and database system which are newly developed.

13. Where data was collected

14. What data were collected
All new HIV diagnoses
All previously diagnosed HIV cases
In summary: All HIV cases
Presenter: read slide

15. What type of variables were collected
Information about where the case was identified (name of facility, sub-county, county etc.)
Demographic information (name, dob, sex, place of residence, etc.)
HIV treatment and care history (date started, ART regimen, etc.)
Laboratory test results (CD4, VL)
Opportunistic infections (TB)
WHO staging (III or IV)
Vital statistics (death, date of death)
Presenter: read slide

16. Mandatory variables What makes a case:
Reporting facility
Date of diagnosis
Name (first and last)
Sex
Date of birth or age
Without these, a case could not be reported
Presenter: read slide

17. Sentinel events
A sentinel event: These are critical events in the lifetime of an HIV positive person that are important in surveillance of the epidemic. For Kenya these are:
Entry into care
HIV Disease Sentinel Events
HIV
diagnosis
First and all CD4 results
Advanced HIV disease
ART initiation
First and all viral load results
Death/
Lost to follow-up

18. Sources of data HTC register ANC register Pre-ART register
HEI Register
CCC card “Blue Card”
Lab slips
HEI Follow-up Card for Paediatric cases
Presenter: read slide

19. HIV/AIDS Case Surveillance System Architecture
Presenter: The KeHARS system architecture consists of three parts: 1) the Mobile platform, 2) The Data Transmission Module, and 3) the Cloud Platform.

20. HIV/AIDS Case Surveillance System
Mobile application
The mobile platform will be comprised of an application that will allow:
Entry, Searching. Viewing, and Updating of adult and paediatric HIV/AIDS cases
Generating reports to assist in data management
Data will synchronized between the mobile application and the cloud database automatically and in real time.
HIV/AIDS Case Surveillance System
Ver 2.01
Presenter: The mobile platform will consist of a mobile application that will allow the user to enter HIV/AIDS cases for the first time, search on the database of cases, view case information, and edit or modify cases as necessary. Moreover, the application will allow the user to generate reports that will assist in data management and correct validation errors.
Finally, the

21. Cloud platform Data stored on a cloud server
Data will synchronized between the tablet to the cloud automatically and in real time
User manager enables creation and management of credentials for each user
Presenter: read slide

22. Pilot summary
Data collection from 13 July 2015 through 20 January 2016
A total of 124 facilities across six sub-counties in Siaya and Kisumu counties
The pilot was conducted by surveillance officers
Facilities purposively selected for CBS reporting to ensure variation in size, services offered, supporting implementing partners, ownership, and to include sites with EMR and paper-based systems

23. Pilot summary
Computer matching algorithms were used to identify multiple case reports that belonged to a single person.
To ensure that all records in the CBS database represented unique cases and that data from multiple sources that concerned the same person were linked into a single record.
Variables for matching algorithm: 1) Soundex code, an alphanumeric phonetic code that accounts for misspellings of names based on English pronunciation of first and last names, 2) sex, 3) date of birth  , and 4) master facility list (MFL) code of the reporting facility.  

24. Pilot summary A total of 12,260 cases collected
11,722 cases after data cleaning and de-duplication
10,674 adults (15+ years) and 1,048 children (<15 years)
Record-matching and de-duplication was performed without the benefit of a national unique identifier
De-duplication/matching process would be more difficult on a larger scale unless a national identifier is implemented.

25. Pilot summary
Unlike program monitoring, CBS allowed for monitoring time from diagnosis to care, and care to treatment
The CBS data allows the ability to monitor progress toward targets
Systematic and integrated collection of clinical and demographic characteristics in a longitudinal manner can be achieved
If implemented nationwide, Kenya would be able to leverage a timely understanding of its HIV epidemic to evaluate impact and allocate resources where needed most.

26. Beyond the Pilot: Establishing HIV Case-Based Surveillance in Kenya

27. Goals and Objectives for Case-Based Surveillance in Kenya
To establish and maintain a case-based HIV surveillance system.
Objective 1: To describe HIV infected persons
Objective 2: To provide information effectively, plan for HIV prevention and treatment and care programming
Objective 3: To evaluate HIV programming

28. HIV Case-Based Surveillance Infrastructure Needs and Tools
Public Health Infrastructure
Laboratory testing and reporting
Vital records reporting and tracking
Existing notifiable case reporting systems
Capacity of existing disease reporting infrastructure for HIV case surveillance
Case report forms (electronic and/or paper)
Data elements needed for case identification

29. HIV Case-Based Surveillance Infrastructure Needs and Tools
Existing or new information systems
Information system to be used for case reporting, etc.
Computers, servers, and hardware housing/storage
Appropriate facilities and backup systems
Guidelines and policy documents
HIV surveillance strategy
CBS guideline documents
Business requirement document for HIS solution for CBS

30. Storing and Managing Surveillance Data
Case Surveillance can only occur if data are transferred from the point of patient interaction to a central point for data management
Three criteria should be considered:
Format(s) of the data
Method(s) of data transfer
Pathway(s) of data transfer

31. Establishing Case Based Reporting: Factors to Consider
Current needs of surveillance data
To understand the distribution of the disease
To target and evaluate prevention interventions
To plan for an implement care and treatment
Future needs to adapt to
New testing strategies
Changes in ART recommendations
New interventions
Resources needed
System development, maintenance, and evaluation

32. HIS Solutions

33. Considerations for a CBS information system
The volume of cases and sentinel events necessitates the use of electronic systems to support case-based surveillance
Electronic Medical Records at facilities can provide the bulk of sentinel events
Contains HTS data and C&T data
Some additional data may come from other sources, such as laboratories and vital registries

34. Considerations for a CBS information system
Due to the volume of sentinel events at facility level, an active reporting system is not feasible
Health workers don’t have time to report these events
Reporting events may also require training at what sentinel events constitute
We will use passive reporting, whereby EMRs will automagically detect, extract and forward sentinel events to a central database

35. Schematic of the CBS database
EMR
De-identified Analysis Database for CBS
Sentinel event database
sentinel events
EMR
EMR
De-identification is an important element of the CBS database. This is handled by the Master Patient Index.
There will be an MPI at each facility to foster integration between pharmacy, lab and EMR. And there will be a national MPI, that focuses on identification between EMRs across facilities, and link records that belong to the same person.
The sentinel event database is a repository for all sentinel events, that needs to be linked with the national MPI, to come to a de-identified analysis database for CBS. This is where analysis and reporting happens. All sentinel events will have been merged against a single patient.
Patient IDs
Reports
Datasets
Master Patient Index (MPI)

36. Analysis
Analysis will be conducted on a line-listed analysis database, that has all the sentinel events for a particular individual, de-identified

37. Analysis
We expect that there will be missing data, especially in the beginning
We will not censure data within the analysis database, instead, we will record the missing data using NULL-values
Each individual analysis scenario will determine which records will need to be censored
Data will be continuously improved and updated over time

38. Operational and coordination considerations
The role of informatics should not be underestimated, and ideally should be conceptualised right from the onset of the project due to the volume of data sources
The data will never be perfect, but has the potential to improve over time to reasonable to good quality especially once data gets being used
Technologically wise it is a complex solution that requires ample planning and time for implementation

39. Operational and coordination considerations
Stakeholder engagement is important, right from the beginning
Determine early enough what the system should do, and also define what it should not be doing
Define the stakeholders involved, and what their role is going to be
Use existing systems as much as possible

40. Thank you