SENCAS. Système Electronique de Notification des CAS de VIH/SIDA au Sénégal. (HIV/AIDS Case notification system in Senegal)

Transcription

1 SENCAS Système Electronique de Notification des CAS de VIH/SIDA au Sénégal (HIV/AIDS Case notification system in Senegal) Surveillance and Health Information Systems Technical Workshop West and Central Africa Dakar, July 26, 2017 Nicolas de Kerorguen, NG contractor U.S. Centers for Disease Control and Prevention / Division of Global HIV/AIDS and TB (DGHT) 1

2 Background: Project organization Role/responsibilities: The users (MOA) = National AIDS Control Committee and DLSI (Division de Lutte contre le SIDA et les IST, MoH), Dakar, Senegal The project manager (MOE) = IRESSEF (Institut de Recherche en Santé, de Surveillance Epidémiologique et de Formation, formerly LBV, University LeDantec/Laboratoire de Bacteriologie-Virologie, Dakar, Senegal The development team = University Gaston Berger, Saint-Louis, Senegal Other partners: There is one PEPFAR Cooperative Agreement between CDC and IRESSEF (through Westat) Technical Assistance (epidemiology and IT) provided by CDC-Atlanta 2

3 Background: Presentation of the system The SENCAS system : a paper-based form, was a four-page form, now reduced to a two-page form a web-based electronic database, matching the paper-based form A set of documents/procedures and human resource This is not name-based: there is a unique ID generated automatically by the electronic system, based on some patient information and sequential number 3

4 Adult case notification form 4

5 Background: Functionalities of the system Role base access: admin, stat, editor, viewer, etc. HIV/AIDS Case management (Add/View/Modify/Suppress) Case searches by criteria Automated standard reports and analysis Deduplication algorithms (1 automatic, 1 manual) Off-line mode Export database for analysis (MS-Excel or Csv) 5

6 Information flow Internet SENCAS IRESSEF, system administrator ADIE: Secure Government Hosting network Internet Data is collected on the patient chart and on the form at site level, Information is consolidated at site level on the form Data is entered electronically at site level or data is collected by LBV who enters the data into the electronic system There is no data validation step Patient chart ART Site SITE Case notification form 6

7 Unique ID The patient code is a 16 alpha-numeric characters code, generated as follow : RR D S PPP IJ KL SSSSS RR = 2 digits region of birth, D = 1 digit department of birth, S = 1 digit sex: 1 for male, 2 for female, PPP = 3 characters place of birth, IJ = 2 characters initial of first name and last name, KL = 2 characters initial of mother first name and last name, SSSSS = 5 digits sequential number, incremented for every new case => the code is unique => because it is based on patient information, it is treated as an identifying information 7

8 Matching algorithms 1/ Automatic algorithm : Happens when a new notification is entered into the electronic system Matches cases when many variables are equals (=> very few false positive) 2/ Semi-automatic algorithm Run manually by the administrator in order to find false negatives See appendix for details 8

9 Automated Reports A report at site level: A site user chooses the period of time (default=past month), and the system generates a standard report for the cases entered during this period of time, with disaggregation by sex, age category, risk factor, education. See example on next slide A report at central level : same as previous except that the user can select the sites/departments/regions. 9

10 10

11 11

12 Current situation Expansion phase: system already in place in 6 regions, ~25 sites. ~ 3,000 cases. Protocol updated. NACC, DLSI, IRESSEF and UGB are motivated and there is a very good synergy between these actors, as well as with CDC/HQ Existing methodology in place: for instance the team organizes validation workshops for every new version of the electronic system SOPs developed on Data cleaning, Deduplication, etc. Tracking monthly the number of cases per site Government network and support Computers given to all sites notifying (tablets were evaluated but desktop was a better solution) 12

13 Challenges Quality of data collection on paper-based forms (universal issue) Motivation (!) on sites (some are performing well, some are not) Lack of supervision Sensitivity around Suspected mode of contamination question Internet connection (=> USB key and pre-paid card) Lack of resources (small funding; small team in Senegal) Agreement on goals of the system and strategies: Describe which data/indicator/report the SENCAS system can generate and that we don t already have from other source (routine such as EMR or PMTCT or survey such as DHS+, IBBS) Shall we cover all sites or select sites? Do we have enough resource for achieving our goal? 13

14 Next steps More site supervisions, including : Training Data Quality Assessment and Data Confidentiality and Security assessment Expansion to additional sites and regions SOPs: Data Confidentiality and Security SOP, Site supervision, Data analysis and other SOPs being developed An Electronic Patient Monitoring System is being implemented in Senegal (LONAGEV) => Assess the possibility to extract data from this system in order to feed the case notification system in the future Comparing data with other systems: DHIS-2 (), Spectrum, etc. Produce quarterly report 14

15 Thanks Professor Souleymane Mboup Head of the Bacteriology-Virology Laboratory of CHU Le Dantec, now IRESSEF 15

16 Appendix1 : Matching algorithm (1/2) 1/ Automatic algorithm (Happens when a new notification is entered into the electronic system) When a case is entered and before its validation by the system, a 11 character-long code is generated : RRDSPPPIJKL, based on patient information ( RR=region of birth, D=department of birth, S=sex:, PPP=place of birth, IJ=initial of first name and last name, KL=initial of mother first name and last name) The system checks if this code already exists as first part of an existing patient code in the database. Normally a form can be entered only if RR, D, S, PPP, I, J, K and L are known; otherwise too many codes, filled with default values, may look alike. Case A: this code doesn t exist The system adds a 5-digit sequential number SSSSS to the first 11 character-long code, creating a new and unique patient code: RR D S PPP IJ KL SSSSS; the case can be entirely entered and validated. Case B: this code already exists The system will retrieve information related to the other case(s) having the same 11 alphanumeric code: date of birth, current citizenship, level of education and check if they all match or not. According to the result of the check, the system will declare if this is the same patient or not: Sub-case B1 : it is the same person The system send a message to the user telling him that the patient already exists in the database The system opens a modification window, displaying all patient information. The system will act as if it is a regular modification (usually adding an event or correcting information) Nota : if the patient was initially linked to another site, he will be linked to the site making the modification. Sub-case B2 : it is NOT the same person The system adds a 5-digit sequential number SSSSS to the first 11 character-long code, creating a new and unique patient code: RR D S PPP IJ KL SSSSS; the case can be entirely entered and validated. 16

17 Appendix1 : Matching algorithm (2/2) 2/ Semi-automatic algorithm (Run routinely or manually in order to find false negatives) User with sufficient privileges may launch the semi-automatic control The system will gather all patients having the same first 11 character-long code (and who haven t been checked by a previous semi-automatic routine) For each set of matching codes, the system displays all the values of the patient files, highlighting in yellow the values that differ The user has the possibility to associate, or not, two records Case A: the user chooses to associate two records The user will be able to choose, for each discordant field, which value to select (based for instance on paper-based forms, or by calling sites) If the user doesn t have enough information for choosing, the association will be postponed When all discordant values are solved by the user, the user can confirm the association The system will keep only one patient code: the most ancient. The system will flag this record as already checked for the association There will be only one case remaining active in the database Case B: the user chooses to NOT associate two records The system will keep track of the fact that these 2 records belongs to two different persons (there might be a table with association already tested ) The system goes to the next match 17

18 Appendix2: Case notification form 18

19 Appendix3: SENCAS Home page 19

20 Appendix3: SENCAS Data entry 20

21 Appendix3: SENCAS Manual deduplication 21

22 Appendix 4: Technical environment Web-based access: 1 central database SQL server 2005 and ASP.NET AjaxControl Toolkit for PDF generation Visual Studio s MS Chart plugin for graph generation Hosting: on a very secure Governmental WiMAX network (ADIE: Agence pour the Développement Informatique de l Etat) 22