DEVELOPMENT, TESTING AND DIFFUSION OF A COMMON SOFTWARE FOR QUALITY CONTROL ON HOME AND LEISURE ACCIDENT (HLA) DATA

DEVELOPMENT, TESTING AND DIFFUSION OF A COMMON SOFTWARE FOR QUALITY CONTROL ON HOME AND LEISURE ACCIDENT (HLA) DATA Activity Report (EHLASS/ISS Quality Management Manual provided as separart document) Kuratorium für Schutz und Sicherheit (Austrian Institute for Safety and Prevention) - Institut "Sicher Leben" Injury Prevention Programme SI2.298818 (2000CVG3-311)

Sicher Leben Authors Robert Bauer and Mathilde Sector - Institute "Sicher Leben", Vienna Institute "Sicher Leben" Austrian Institute for Home and Leisure Safety Ölzeltgasse 3, A-1031 Wien Tel. ++43 1 715 66 44-317 Fax ++43 1 715 66 44-30 E-mail: robert.bauer@sicherleben.at Internet: www.sicherleben.at Co-Authors (alphabetic order) Johansen, Anne Mette T. National Institute of Public Health, Kopenhagen Kiosse, Stellina - Hellenic Society for Social Pediatrics and Health Promotion, Athens Mulder, Saajke Consumer Safety Institute, Amsterdam Nectoux, Marc - SC PSYTEL, Paris Software Development Marc Nectoux - PSYTEL, Paris Funding European Commission, Directorate General for Health and Consumer Protection Austrian Ministry for Education, Science and Culture 2

IPP/2000/1070 Quality Control - Error! Style not defined. CONTENTS CONTENTS...3 SUMMARY...5 PROJECT MANAGEMENT...7 PROJECT PARTNERS...9 INTRODUCTION...10 Scientific Bases and Aims...10 METHODS...12 Task Force Work Packages...12 Purpose of Work Package 1...12 Purpose of Work Package 2...12 Tools Development...13 Software Testing...13 Recommendations for Next Steps...15 RESULTS...16 General...16 Installation...16 Input Data Format...17 Operation...18 Program Menus (v2.1)...19 The Output...21 APPENDICES...24 Appendix 1: Work Package 1 - Quality Management Manual...24 Austrian Work Package 1 as model (EHLASS Austria)...29 Appendix 2: Work Package 2: Review of Quality Management Software and Manual...32 3

Sicher Leben Appendix 3. Un programme commun de control de la qualité du codage des données recueillies dans le systeme EHLASS... 49 1- Contexte... 49 2- Principes de développement... 50 3- Contrôle de la conformité et de cohérence des données... 53 3.1- Les contrôles monovariables... 53 3.2- Les contrôles logiques... 53 3.3- Les contrôles de cohérence... 53 4- Contrôle de la richesse informative... 57 5- Le programme développé... 59 6- Application aux données françaises de 1997... 59 7- Utilisations du programme de contrôle commun... 62 Appendix 4: Réflexions sur le projet Common software for Quality control (QM)... 33 Appendix 5: Contrôles effectués dans le logiciel QC... 36 1- Le logiciel développé... 36 2- Principes des contrôles envisagés... 37 3- Détails des contrôles effectués... 38 3.1- CONTRÔLES DE CONFORMITÉ :... 38 3.2- DÉTAILS DES CONTRÔLES LOGIQUES :... 41 4- Description de l Etat Qualité... 41 5- Le listing des erreurs... 48 4

IPP/2000/1070 Quality Control - Error! Style not defined. SUMMARY I.- The purpose of the quality control software (QC-CONTROL) is to assist those performing injury data collection to have access to a software which performs the minimum quality controls in a standardized process. The summary of all assessment results and quality indicators are given in a Quality Statement. This Quality Statement should be produced regularly as a feedback to each data transmission on both national or EU level, in order to assist in quality control and improvement. The QC-Software itself is only one implementation of a recommended set of controls that should be applied to the EHLASS data. Currently, the controls comprise formal, logical and information indicators on record and data set level. Controls of plausibility and representativity are suggested. The recommended controls could also be implemented in existing programs other than this software. The quality control software has been developed to assist injury data centers (NDAs) in gathering and providing high quality injury data. This software would be applicable for any injury database; EHLASS is presented here as an example. Therefore, the quality control principles are based on the 20 EHLASS variables; one can expand the checks to control customized variables. II. As a related Documents a QUALITY MANAGEMENT MANUAL (QM-Manual) for Data Collection for the European Home and Leisure Accident Surveillance System (EHLASS/ISS) was developed. This manual is an integral part of this project and is provided as a separate document. The overall objectives of this Quality Management (QM) approach is to facilitate the improvement of quality, comparability and representativity of the EHLASS data. In general concept Quality Management this is achieved by the standardization of processes and the provision of feedback tools between providers (suppliers) and customers (demanders). The EHLASS/ISS QM Manual should assist those performing injury data collection with common guidelines and tools for all steps of data collection, from the point of contact with the patient or respondent to the upload of the data into the central database. 5

Sicher Leben For each of the steps, specific tools for documentation and feedback of quality aspects are recommended (in the final version). The QM-Manual describes a standard process for a minimum quality control of EHLASS data collection in the Member States, in particular for hospital based data collection. The EHLASS/ISS QM-Manual and the QM software tool for systematic quality control of EHLASS/ISS data will be available on the CIRCA website of DG SANCO (for Win95, 98, NT, 2000). http://forum.europa.eu.int/members/irc/sanco/ehlass/home Keywords: datat quality control, coding,, data collection, quality manual 6

IPP/2000/1070 Quality Control - Error! Style not defined. PROJECT MANAGEMENT Project co-ordination: Robert Bauer, Mathilde Sector Institute "Sicher Leben" - Austrian Institute for Home and Leisure Safety Ölzeltgasse 3, A-1031 Wien Tel. ++43 1 715 66 44 317 / Fax ++43 1 715 66 44-30 Email: robert.bauer@sicherleben.at / Internet: www.sicherleben.at Partners: DK, FR, GR, NL (see following chapter for details) Revised Timeline: Dec. 2000 to June 2002 Proposed total budget: 127.000 EUR Contracted funding: 70 % of total costs Partner Involvement: - Two workshops (all) - Two work packages (all) - Software: engineering and programming (FR) Coding expertise (DK) - Review of results and final reports (all) Proposed task list Step n 1: Existing tools analysis Aim: At first, the various control procedures or programs which are used by the teams in charge of the HLA data collection will be catalogued and reviewed in detail (this should be done on the basis of the national data collection plans provided to DG SANCO). As some teams (e.g. in Denmark, Sweden, Portugal, Greece and Austria) already use some specific control software we will try to extract the common features of these procedures and propose them as core elements of a common control software. Nevertheless, the experience from all EU countries, wherever similar codes and systems are in place, will be taken into account for the development of the proposed software. Thus, on-site trips will take place to assure the practicality and quality of the currently run systems. 7

Sicher Leben Step n 2: Wished controls analysis Aim: Establish a list of controls that the group of the actors wishes to be included in the program. In addition to the core elements of step.1, we propose two axes of development: - an axis "conformity to coding system" with regard to the tables of codes established in the coding version V2000. We shall add to it controls of inter-variable coherence and logical controls. A double checking mechanism for coding compatibility will be developed based on relevant current experience (e.g. in Greece). - an axis "information wealth" that takes into account the informative character of the record. This leads to create one "coding quality score" by attributing a score to each observation. When this quality score is lower than a chosen value, the complete observation might be rejected, otherwise the record is included into the database and errors are correcting automatically, if necessary. As a result, a quality report (diagnosis of errors) will be edited for every file that is submitted to the procedure, so as to be able to identify and correct the coding problems. Step n 3: Development of the control software Aim: Development of the control software and diffusable procedure by standard tools. Step n 4: Validation (testing) Aim: Test and validate the program with the project partners. Analyse test protocols, receive feed back from pilot sites and finally, include the necessary modifications into the program. 8

IPP/2000/1070 Quality Control - Error! Style not defined. PROJECT PARTNERS Denmark: National Institute of Public Health, Svanemollevej 25, 2100 Copenhagen Tel. (+45) 39.20.77.77, Fax (+45) 39.27.30.95 (Anne Mette T. Johansen) France: SC PSYTEL, 36, Rue Irene blanc, F-75020 Paris Tel. (+33.1) 43.79.71.92, Fax (331) 43.64.58.24 (Marc Nectoux) Greece: Hellenic Soc. f Social Pediatrics a. Health Promotion, 15, Oceanidon st., Athens 117 45, - Tel. (+301) 9354.179, Fax (301) 9324.300 (Stellina Kiosse) The Netherlands: Consumer Safety Institute, Technical Safety Unit, PO Box 75.169, 1070 AD Amsterdam, Netherlands, Tel. (+31) 20.511.4511, Fax (+31) 20.669.2831 (Saajke Mulder) Consulted for additional data acquisition and reports: Germany: Landesinstiut für den öffentliche Gesundheitsdiest (LOEGD), Westerfeldstrasse 35-37, DE-33611 Bielefeld - Tel.: + 49/521/8007-258, Fax: +49/521/8007-296 (Doris Bardehle, Claus Martin Heyer) European Commission: Directorate-General Health and Consumer Protection Unit G3, Euroforum building, 10 rue Stumper-Office EUFO 3188, L-2557 LUXEMBOURG (Helmut Friza) 9

Sicher Leben INTRODUCTION SCIENTIFIC BASES AND AIMS For the moment, each member state (MS) applies its own validation policy for the coding of Home and Leisure Accident (HLA) data collected within the "Injury Prevention Programme" (IPP). It follows that the level of controls is rather different from one MS to another, which in turn reduces the global quality of the common European HLA database. Further, MS controls are mainly monovariate controls of correspondence to codes. Thus, we propose to develop and implement a common software for data quality control. We suggest to distinguish two axes to assess the quality of the data already coded: - An axis "conformity to coding system" with controls of inter-variables coherence and logical controls. - An axis "information wealth" that takes into account e.g. the number of variables coded as "unknown" or with an empty free text field (description of the accident). So each record sent to the European database can be assigned with a quality indicator (QI) that informs about the degree of conformity, coherence and information of the record. Also, the QI gives a measure of overall quality of a specific data set. This instrument can strengthen the credibility of the system and enhance interpretation of results. A quality statement (diagnosis of errors) will be edited for every file so that the national teams can take measures to improve the quality of the data collection. General Objectives to enhance harmonisation of the data collection process for HLA data by providing tools for a standardised documentation and quality control summarised in a QM-Manual Technically, the study resulted: in an easy-to-use software for automatic quality control of EHLASS/ISS data 10

IPP/2000/1070 Quality Control - Error! Style not defined. Specific Aims - a manual (checklist) - for the total data collection process - specific tools (recommendations and programmes) - for assessing and reporting data quality (logic, plausibility, information controls, and standardised result tables Products Common QM-Manual for HLA data collection and data quality control, comprising Common software tools for data quality analysis, including a Quality Statement proposal (common quality indicators for each data set) 11

Sicher Leben METHODS TASK FORCE WORK PACKAGES PURPOSE OF WORK PACKAGE 1 The main purpose of the project was to develop minimum Quality Management Guidelines (QM-Manual) for injury data collection in order to implement a common software for data quality control. The first step towards this goal was to distinguish the different steps of the quality management process from the point of data collection to the upload of the data into the EUPHIN/HIEMS or EUPHIN /INJURY database. For each of the steps, specific tools for documentation and feedback of quality aspects were recommended. These recommendations and tools were to be integrated in a common software, resulting in a set of data Quality Indicators. The summary of all assessment results and quality indicators would be represented in a Quality Statement for each national data set. The Quality Statement should be an integrated part of each data set delivered to the EU. We provided the partners an example of a quality management (QM) manual that we employ for EHLASS Austria. We asked the partners to critically review the EHLASS QM Manual and to provide feedback regarding national differences in quality management techniques (see Appendix 1: Work Package 1). PURPOSE OF WORK PACKAGE 2 We asked the partners to provide feedback on the draft version of the IPP Quality Control Manual, as well as on the draft QM software which included Quality Statements for Member States. The Quality Statement was to be an integrated part of each data set delivered to the EU. Recommendations for improving areas of low quality (eg. free text structuring, standard training of coding, etc.) were also requested and documented. See Appendix 2: Work Package 2. 12

IPP/2000/1070 Quality Control - Error! Style not defined. TOOLS DEVELOPMENT QM Manual: guideline and checklist for the total data collection process For the manual should to offer concise documentation and guidelines a procedural approach according international QM standard (ISO) was taken, allowing for authorisation, feedback and flexible update (see separate EHLASS/ISS QM Manual) Quality Control Software: for assessing and reporting data quality such as logic, plausibility, information controls, and standardised result tables for representativity check. See Appendix 3: Reflexion sur le projet by Marc Nectoux. 27/07/2001 See Appendix 4: Un programme commun de control de la qualité du codage des données recueillies dans le systeme EHLASS. December 2000 for the historical development of the software in coordination with Marc Nectoux, France. SOFTWARE TESTING The software was developed using an artifically constructed data set in order account for all the possible error causes and variation. Four examples (Version V.2000): 1. 1402XXXXXXXXXXXXXX71915151520011011242001011505200102235110949A 2205006100F1298F4305F1998EN DESCENDANT DU LIT CHUTE SUR DE LA MOQUET- TE ET CHOC CONTRE UN PLACARD. 2. 1402020017195411980151519751012002001012114200102155196388 14007000G3110R0120Z9999 3. 02 020017195611937 XXX LA LESSIVEUSE S EST RENVERSEE. BRULURE AVEC DE L EAU CHAUDE. 4. 1402 020017195721924 2001012516200102145130549 05026219C0098C0098A1500CHUTE DANS LES ESCALIERS EN PIERRE DANS L ENTREE DE SA RESIDENCE CHOC/PORTE VITREE 13

Sicher Leben The pre-final QC-Software was tested on home and leisure data from the EHLASS hospital in Bordaex Bordeaux, France. The complete pre- and after-test datasets are availble from the aozhors. 14

IPP/2000/1070 Quality Control - Error! Style not defined. RECOMMENDATIONS FOR NEXT STEPS Presently, no common control procedure for actively supporting and maintaining minimum requirements in the Member States has been implemented so far. We propose the Manual and Software presented in this report be the basis of a training Session for the Member States on Common Quality and Coding Standards for HLA Data Collection. Provision and training for the Coding Manual and the QM-Manual would improve the consistency of data collection methodology and coding practice between Member States. Training in these measures would improve the quality of the European HLA databases. 15

Sicher Leben RESULTS GENERAL The purpose of the quality control software is to assist those performing injury data collection to have access to a software which performs the minimum quality controls in a standardized process. The summary of all assessment results and quality indicators are given in a Quality Statement. This Quality Statement should be produced regularly as a feedback to each data transmission on both national or EU level, in order to assist in quality control and improvement. Please address questions or comments to: Institute SICHER LEBEN Dr. Robert Bauer robert.bauer@sicherleben.at INSTALLATION Installation requirements : Access 1997 (full installation) 1. Open the Zip file 2. Extract the data files in the C: drive, keeping the option Use defined path (which automatically creates a folder «QCdef021112» in the C: drive. 3. Double click on HLA-QC.mdb to start the program 16

IPP/2000/1070 Quality Control - Error! Style not defined. INPUT DATA FORMAT The input file must be in HLA V2000 format (version October 2002), ASCII, fixed length and without delimitor records file (see the description format). No. of characters Positions COUNTRY CODE 2 1-2 HOSPITAL NUMBER 6 3-8 CASE NUMBER 10 9-18 SEX OF PATIENT 1 19-19 DATE OF BIRTH (YYYYMMDD) 8 20-27 DATE OF INJURY (YYYYMMDD) 8 28-35 TIME OF INJURY 2 36-37 DATE OF ATTENDANCE (YYYYMMDD) 8 38-45 TIME OF ATTENDANCE 2 46-47 DATE OF DISCHARGE (YYYYMMDD) 8 48-55 TREATMENT AND FOLLOW-UP 1 56-56 PLACE OF OCCURRENCE 2 57-58 MECHANISM OF INJURY 2 59-60 ACTIVITY 2 61-62 SPORTS 3 63-65 TYPE OF INJURY Type 1 2 66-67 Type 2 2 68-69 PART OF THE BODY INJURED Part 1 2 70-71 Part 2 2 72-73 PRODUCT INVOLVED IN THE ACCIDENT 5 74-78 PRODUCT CAUSING THE INJURY 5 79-83 OTHER PRODUCT 5 84-88 ACCIDENT DESCRIPTION 120 89-208 Bed-days are calculated as date of discharge minus date of admission. If the date of discharge is the same as date of admission the result is one bed-day Figure 1: HLA record format V2000 (version October 2002) Start the program by clicking on the arrow and under Path of file to be verified type in the file name of the file to be checked. Next, under Path where to put the corrected file specify how you would like the checked file to be named. For example: EHLASS_AT to be checked and call the new file EHLASS_Atchecked. 17

Sicher Leben OPERATION 1. Define path for data input file and corrected data ouput file (Figure 2) 2. Define the reporting year by giving the year of attendance (Figure 2) 3. Press Continue to start automatic data quality control (Figure 2) 4. Select an option the view the outputs and results (Figure 2): Summary error statistics (Figure 4 und Figure 5) Log files Corrected data file 5. Options (Figure 2) Review data format requirements Review data dictionary (EHLASS v.2000 codes; Figure 3) Online Documentation 18

IPP/2000/1070 Quality Control - Error! Style not defined. PROGRAM MENUS (V2.1) The following screen-shots show the menus currently impemented in the softwarwe v.2.1. Figure 2: QC-Software data input menu 19

Sicher Leben Figure 3: QC-Software data dictionary menu Figure 4: QC-Software Q-Statement page 1 Figure 5: QC-Software Q-Statement page 2 20

IPP/2000/1070 Quality Control - Error! Style not defined. THE OUTPUT Statistics for quality control (HLA v2000) by the Common Software for Quality Control (v2.1) Input file characteristics File name Oldest attendance Youngest attendance Number of date date records C:\ehlass20\ehlass97\bor0402.v2K 20020430 20020401 1277 Control on the entire file Number of concerned records % /Total Nb of records Duplicated records 0 00,00 Records with missing or non valid value 1277 100,00 Excluded records 0 00,00 Controls by variable Missing % Unknown % Other Non valid Variable specified range % Country 00,00 00,00 00,00 0 Sex 00,00 00,00 0 Date of birth 00,00 00,00 0 Date of injury 100,00 00,00 0 Time of injury 100,00 00,00 0 Date of attendance 00,00 00,00 0 Time of attendance 00,00 00,00 0 Date of discharge 00,31 00,00 0 Treatment 00,00 00,16 00,00 0 Place 00,00 00,00 00,00 0 Mechanism 00,00 00,00 00,08 0 21

Sicher Leben Activity 00,00 00,08 00,00 0 Sport 29,21 00,00 00,00 0 Type of injury 1 00,00 00,31 05,48 0 Type of injury 2 00,08 00,08 0 Part of body 1 00,00 00,16 00,00 0 Part of body 2 00,00 00,00 0 Product involved 00,00 16,44 04,62 0 Product causing 00,00 08,14 05,32 0 Other product 99,30 00,00 0 Description 00,00 Average % by variable 12,75 01,49 01,55 00,00 Control between variables Nb of concerned records % / Nb total of records Error of chronology if dates given 0 00,00 Date of discharge given and Trt not=hospitalise 0 00,00 Date of attendance > Date of discharge 0 00,00 Activity not = Sport and code sport given 0 00,00 Activity = Sport and code sport not given 373 29,21 % of records with a logical error at least 05,84 Corrected file characteristics File name Oldest attendance date Youngest attendance date Number of records C:\ehlass20\bor0402cor.txt 20020430 20020401 1277 Error file characteristics Entry file name Number of records in fatal error % of records in fata error 22

IPP/2000/1070 Quality Control - Error! Style not defined. C:\ehlass20\ehlass97\bor0402.v2K 0 00,00 Final Scores % Duplicate records 00,00 % Excluded records 00,00 % Records with missing or non valid value 100,00 % Records with logical error at least 05,84 Average % of missing by variable 12,75 Average % of non valid value by variable 00,00 23

Sicher Leben APPENDICES APPENDIX 1: WORK PACKAGE 1 - QUALITY MANAGEMENT MANUAL Table of Contents 1 GENERAL DESCRIPTION OF DATA COLLECTION... 23 1.1 General Information... 23 1.2 Project Staff... 24 1.3 Methodology... 24 1.4 Data... 25 1.5 Results (optional)... 25 2 DATA COLLECTION... 26 2.1 Data Collection Plan... 26 3 DATA COLLECTION... 27 3.1 Staff Training and Support... 27 3.2 Local Contact Point... 27 3.3 Data Aggregation National level... 28 4 NATIONAL DATA QUALITY ANALYSIS... 29 4.1 National Data Quality Analysis... 29 5 EU-LEVEL DATA QUALITY ANALYSIS... 30 5.1 Factory acceptance test... 30 5.2 Standard Test Analysis... 30 5.3 Upload of data... 30 5.4 Yearly Quality Analysis Statement per country in Data Dictionary... 30 24

IPP/2000/1070 Quality Control - Error! Style not defined. Purpose of Project The main purpose of this project is to develop minimum Quality Management Guidelines (QM-Manual) for injury data collection in order to implement a common software for data quality control. The first step towards this goal is to distinguish the different steps of the quality management process from the point of data collection to the upload of the data into the EUPHIN/HIEMS or EUPHIN /INJURY database (see flow chart below). For each of the steps, specific tools for documentation and feedback of quality aspects are recommended. These recommendations and tools will be provided in a common software, resulting in a set of data Quality Indicators. The summary of all assessment results and quality indicators will be given in a Quality Statement for each national data set. This Quality Statement should be an integrated part of each data set delivered to the EU. We provide an example of a quality management (QM) manual that we employ for EHLASS Austria. Data Collection (Local level) Data Aggregation (National level) Data Analysis (EU-level) Figure 6: Levels of Quality Management in Injury Data Collection 25

Sicher Leben Purpose of Work Package The purpose of this Work Package is to design a systematic quality management tool. Therefore we would ask you to Critically review the EHLASS QM Manual Provide feedback regarding national differences in quality management techniques by completing tables 1-4, and provide comments regarding the usefulness of a QM Manual for all Member States 26

IPP/2000/1070 Quality Control - Error! Style not defined. QM Manual (Country) Please complete the tables 1-4 as best you can;if unable to complete a portion, please state why. General Description of Data Collection General Information Description Comment Country Name of Datasource Year of Data Collection Responsible Organization Responsible Authority Contact Person Year data collection started Project Staff Description Comment Number of staff full-time Number of staff part-time Methodology Description Comment Setting (data collected in): general hospital accident hospital other (please list) Method (data collected by): face to face interviews mail survey telephone survey Subjects (data collected in-patient from): out-patient Topics (data collected on): home and leisure work school traffic Data Description Comment Data set Number of variables collected Coding EHLASS coding manual year Computing (software) SPSS, Access Excel, other Export File Formats SPSS, Access Excel, other 27

Sicher Leben Results (optional) Expected cases in 2000: By kind of treatment Special programs (by extension of questionnaire) Special studies (by extension of data collection) number of out-patients number of in-patients Comment Data Collection Procedure Steps Tool Data Collection Plan Staff Training and Support Local Contact Point Data Aggregation National level National Data Quality Analysis Procedure Steps Tool National Data Quality Analysis EU-level Data Quality Analysis Procedure Steps Tool Factory acceptance test Standard Test Analysis Upload of data Yearly Quality Analysis Statement per country in Data Dictionary Comments (regarding usefulness, format, etc.): 28

IPP/2000/1070 Quality Control - Error! Style not defined. AUSTRIAN WORK PACKAGE 1 AS MODEL (EHLASS AUSTRIA) QM Manual AUSTRIA (Country) Data Collection Description General Information Description Appendix Country Austria Name of Datasource EHLASS Austria Year of Data Collection 1999 Responsible Organization Institute Sicher Leben Responsible Authority Ministry of Health Contact Person Robert Bauer (robert.bauer@sicherleben.at) First year of data collection 1996 Project Staff Description Appendix 1 part-time project leader 1 parttime project administrator (1 full time, 4 part-time) Methodology Description Appendix Setting (data collected in): 3 general hospitals (mainly accident dept.): Feldkirch, Linz, Klagenfurt) 1 special accident hospital: Vienna See www.bmsg.gv.at for details on Austrian hospitals Method (data collected by): Subject (data collected from): Object (data collected on): face to face interviews with injury patients (or representative of patient in case of minors) in- and out patients home and leisure (HLA) accidents (nonlethal, non-intentional, non-occupational, non-traffic) DG SANCO Definition of HLA (see HLA Coding Manual) Data Description Appendix Data set 19 variables accord. to EHLASS data structure 1986 Data Set Description Coding accord. to EHLASS code table (coding manual V.86; modified to national needs Computing (software) SPSS, DB2/2, MS-Access Export File Formats SPSS (*.sav), Excel (*.xls), Access (*.mdb) Coding Manual EHLASS Austria 29

Sicher Leben Results (optional) Description Appendix Expected cases 1999 10.000 By kind of treatment 300 out-patients, 1x treated 7.000 out-patients in-patients >1x treated 2.700 in-patients (admitted) Special programs (by extension of questionnaire) Inline skating (150 cases) Cycling (600 cases) Ladders (200 cases) Special studies (by extension of data collection) Data Collection Plan Public tansport (40 cases) Burns and scalds Procedure Steps Tool Data Collection Plan Choice of data collection Publication.. method Sampling plan Publication Hospitals in Austria Hospital Discharge Registry Implementation of sampling Publication Hospitals in Austria Hospital Discharge Registry Hospital Contract Control of sampling Half-Year Quality Analysis Report (see 0) Data Collection Procedure Steps Tool Staff Training and Support Training Training Module Coding Manual Interviewer Manual Staff Feedback Interviewer Monthly Feedback Report Half-year Meeting (see 0) Sampling quotas Local Contact Point Hospital interview Interview coding form Manual Data Coding Interview coding form Aggregation and Transmission of data as a Monthly Package Coding Manual Data Entry Charge Sheet (unique id for each package) 30

IPP/2000/1070 Quality Control - Error! Style not defined. Data Aggregration National level Number coding forms with unique identifier Manual control of coding forms for completeness Manual correction when possible Data Entry - standardise to EU Database Format Data Storage Plan Completeness scoring Interviewer Monthly Feedback Report (inc. 0) Data Set and Data Type Definition (as part of Coding Manual) Data Storage Plan (data filed according to 0) National Data Quality Analysis Procedure Steps Tool National Data Quality Analysis EU-level Data Quality Analysis Data check for missing and for double counting of patient i.d. or unique id Data check for conformity and coherence Data check for information wealth and representativity Manual cross-check of activity at time of injury with free text Interviewer Comparison Analysis Yearly Aggregation of quality analysis Instructions and Checklist Software program to check and correct when possible Error / Correction Log Instructions and Checklist Software program to check and correct when possible Error / Correction Log Instructions and Checklist Software program to check and correct when possible Error / Correction Log Instructions and Checklist (e.g. on a 5% sample, twice a year) Half-Year Quality Analysis Report Yearly Quality Analysis Statement Procedure Steps Tool Factory acceptance test Acceptance report to national EHLASS centres Standard Test Analysis Instructions and Checklist Upload of data Yearly Quality Analysis Statement per country in Data Dictionary Data Set and Data Type Definition (as part of Coding Manual) Yearly Quality Analysis Statement 31

Sicher Leben APPENDIX 2: WORK PACKAGE 2: REVIEW OF QUALITY MANAGEMENT SOFTWARE AND MANUAL We would like to present you with the draft version of the QM Software, as well as the QM Draft Manual. This work is based on the feedback from the Work Package 1. Please do not hesitate to contact us if you have questions regarding this task. We appreciate your input and this will be instrumental in finalizing both of these project deliverables. 1. QM Software Comments (regarding usefulness, format, etc.): Suggested Edits: 2. QM Draft Manual Comments (regarding usefulness, format, etc.): Suggested Edits: 32

IPP/2000/1070 Quality Control - Error! Style not defined. APPENDIX 3: REFLEXIONS SUR LE PROJET COMMON SOFTWARE FOR QUALITY CONTROL (QM) nectoux/27/07/2001) 1. Avez-vous bien distingué dans vos documents les 3 niveaux de contrôle, ces 3 niveaux ayant des caractéristiques différentes? Niveau 1- Site de recueil Etape du contrôle (1) : Le fichier mensuel du site est en cours de constitution Action du Projet QM: donner des recommandations 2- Site national Etape du contrôle (2) : Le fichier national trimestriel est en cours de constitution Action du Projet QM: donner des recommandations 3 - Site européen Etape du contrôle (3) : Le fichier semestriel (?) européen est en cours de constitution Action du Projet QM : donner des recommandations + développer un logiciel de Caractéristiques Le retour à la source de l information est possible : contrôle d erreur pour chaque observation pour correction Le retour à la source de l information est difficile : contrôle d erreur au niveau du fichier du site pour redressement et calcul d indices de qualité interne et de représentativité analyse au niveau national : comparaisons inter-sites, comparaisons années N/N-1 Le retour à la source de l information est impossible : contrôle au niveau du fichier national pour redressement ou exclusion de certains cas et calcul d indices de qualité interne et de représentativité analyse au niveau transnational : comparaisons inter-etats, comparaisons années N/N-1 33

Sicher Leben contrôle et de validation + sortir des tableaux de bord Les étapes du contrôle d un cas : (1) Correction possible (2) Redressement (3) Redressement Recueil sur site Constitution de la base nationale Constitution de la Exclusion base européenne 2- Quelle procédure de contrôle voulons-nous développer? - A priori, nous voudrions développer la procédure de contrôle au niveau du site européen, avant versement dans la base européenne des données non agrégées (avec un codage des cas en V96). - Nous devrions prendre contact avec Cap Gemini pour développer, intégrer et implémenter les contrôles de la base de données non agrégées (nous proposons de gérer ces contacts). 3- Avez-vous des informations nouvelles et précises sur les types de contrôle mis en œuvre par les équipes nationales, en particulier pour le contrôle de cohérence logique entre variables et quels sont les souhaits et les besoins de ces différentes équipes? 4- Nous devons définir les conduites à tenir quand le codage est hors table de codes, quand le codage n est pas cohérent logiquement, quand le cas est en double, etc. 34

IPP/2000/1070 Quality Control - Error! Style not defined. 5- QAS (votre mail du 19.07.01) : Globalement, il faudrait préciser le niveau et l étape où s effectuent les contrôles proposés et définir les conduites à tenir. Plus particulièrement, il faut préciser : - Nombre de cas avec «missing» et de «unknow» pour chaque variable - Nombre de cas avec double complet : au niveau du fichier annuel d un site (?) - Nombre de cas en dehors des fourchettes ou des tables de code pour chaque variable - Nombre de cas avec le texte libre vide : OK - Nombre de cas ayant un problème de cohérence logique entre variables : OK, mais quels sont précisément les tests de cohérence logique? - Nombre de cas en Error Log :? il faudrait expliquer plus - Représentativité : sortir des tables du type Sexe x Age du fichier EHLID national, mais pour les comparer avec quelles autres tables? pour en déduire quel type de représentativité? 6- Voulons-nous développer des scores de qualité attribuables à chaque fichier (ou à chaque cas) soumis au versement dans la base européenne non agrégée? 7- Nous envisageons la publication des tableaux de bord, mais à quel niveau (national ou européen)?, selon quelle forme et quelle fréquence? Faut-il sortir le listing des cas en erreur pour envoi au chef de projet?. Il nous semble que le but du projet est plutôt d aider les équipes nationales dans le diagnostic des erreurs et des omissions que de juger le niveau de la qualité des données de chaque Etat. 35

Sicher Leben APPENDIX 4: CONTROLES EFFECTUES DANS LE LOGICIEL QC by Marc Nectoux, PSYTEL, November 2002. 1- LE LOGICIEL DEVELOPPE Nous avons développé un programme de contrôle des données HLA (Home and Leisure Accidents) V2000, avant leur versement dans la base européenne ISS (Injury Surveillance System) des données non agrégées. Ce programme : - édite les messages d erreur des enregistrements contenant au moins une erreur et l enregistrement lui-même - écrit le fichier corrigé après les actions de correction des erreurs - édite un Etat Qualité Fichier EHLASS V2000 à contrôler (format ASCII, de longueur fixe, sans délimiteur) Procédure Quality Control Edition d un listing Erreur Ecriture du fichier corrigé Edition d un Etat Qualité Liste des records en erreur Fichier V2000 après Tableaux caractérisant + messages d erreur correction des erreurs la qualité du fichier de données Ce programme effectue les contrôles conformément aux instructions du manuel de codage V2000 (october 2002), avant le passage des données dans le format ISS. Ce logiciel fonctionne dans un environnement matériel et logiciel standard de type Windows 95 et + en utilisant l outil de gestion de base de données Microsoft ACCESS 97. 36

IPP/2000/1070 Quality Control - Error! Style not defined. 2- PRINCIPES DES CONTRÔLES ENVISAGÉS - On contrôle un fichier en entrée (nom de fichier à passer en paramètre), constitué d enregistrements HLA au format V2000 (format ASCII, de longueur fixe, sans délimiteur), puis on réécrit un fichier corrigé (nom de fichier à passer en paramètre) en sortie (format ASCII, de longueur fixe, sans délimiteur), en éditant un listing des records en erreur et un Etat Qualité. - Au niveau européen, il n y a pas de contrôle sur les variables «Hospital Number» et «Case Number» de la V2000. - Les seules variables obligatoires au niveau européen sont : «Country» et «Date of attendance». Si cette information de base est absente ou non valide, il y a exclusion de l enregistrement. On présélectionne une année d admission (Year of attendance à passer en paramètre) au lancement de la procédure de contrôle. - Les contrôles de conformité : pour chaque variable de code, le logiciel contrôle que le code saisi fait bien partie de la table des codes valides. Sinon, il émet un message d erreur. De même pour les dates, le logiciel contrôle que les dates saisies sont sous une forme valide. - Les contrôles logiques : le logiciel contrôle par exemple que les dates saisies sont dans une chronologie logique (Date of birth < or = Date of injury < or = Date of attendance < or= Date of discharge). - Les contrôles de plausibilité : Nous avons recensé six contrôles possibles de ce type : Activity x Free text, Activity x Type of injury, Type of injury x Body part, Activity x Product code, Activity x Sport, Activity x Place of occurrence. En l absence d un consensus et d une définition précise sur ce type de contrôle, le logiciel actuel ne les prend pas en compte. - Les contrôles de représentativité : Ils sont à faire au niveau de chaque Etat sur des fichiers de données annuels et en tenant compte de données externes. Ils ne font pas partie du présent logiciel. 37

Sicher Leben 3- Détails des contrôles effectués 3.1- CONTRÔLES DE CONFORMITÉ : Dans le tableau suivant nous fournissons, pour chaque variable, le nombre de caractères de la variable, son format, la valeur explicite de la modalité de la variable (ex : le code Unknown de la variable Sexe = 9) et les actions à effectuer en cas d erreur. La signification des éléments du tableau est la suivante : - Num : format numérique, Date : format AAAAMMJJ, Alpha = alphanumérique - Exclusion : exclusion du record entier => non réécrit dans le fichier corrigé - List : référence à la liste des codes de la V2000 - Cpt : comptage de la modalité dans un compteur spécifique pour l Etat Qualité - Err : variable signalée en erreur dans le listing d erreur - Colonne Non valid range «99» : forçage de la modalité à 99 dans le fichier corrigé 38

IPP/2000/1070 Quality Control - Error! Style not defined. - Variable Nb car. -Format Missing Unknown Other specified Non valid range Country Action 2 - Num - Cpt21 Exclusion 99 - Cpt31 Exclusion 98 - Cpt41 List - Cpt51 Exclusion Hospital 6-Alpha Record 10- Alpha Sex Action 1 - Num - Cpt22 9 - Cpt32 List - Cpt52 Err - 9 Date of birth Action 8 - Date - Cpt23 99999999- Cpt33 Cpt53 Err - Date of injury Action 8 - Date - Cpt24 99999999 - Cpt34 Cpt54 Err - Time of injury Action 2- Num - Cpt25 99 - Cpt35 0-23 - Cpt55 Err - 99 Date attendance Action 8 - Date - Cpt26 Exclusion 99999999 - Cpt36 - Exclus Cpt56 Exclusion Time attendance Action Date discharge Action Treatment Action Place Action Mechanism Action Activity Action Sport Action Type of injury 1 Action Type of injury 2 Action Part of body 1 Action Part of body 2 Action Product involved Action Product causing Action Other product Action 2- Num - Cpt27 99 - Cpt37 0-23 - Cpt57 Err - 99 8 - Date - Cpt28 si Trt = 5,6,7 99999999 - Cpt38 si Trt = 5,6,7 39 Cpt58 - Err - 1 - Num - Cpt29 9 - Cpt39 8 - Cpt49 List -Cpt59 Err - 9 2 - Num - Cpt210 99 - Cpt310 98 - Cpt410 List -Cpt510 Err - 99 2 - Num - Cpt211 99 - Cpt311 98 - Cpt411 List - Cpt511 Err - 99 2 - Num - Cpt212 99 - Cpt312 88 - Cpt412 List - Cpt512 Err - 99 3 -Alpha - Cpt213 Z99 - Cpt313 Z98 - Cpt413 List - Cpt513 si Activ=Sp. si Activ=Sp. si Activ=Sp. Err - Z99 2 - Num - Cpt214 99 - Cpt314 98 - Cpt414 List - Cpt514 Err - 99 2 - Num 99 - CptD314 98 - CptD414 List- CptD514 Err - 99 2 - Num - Cpt215 99 - Cpt315 98 - Cpt415 List - Cpt515 Err - 99 2 - Num 99 - CptD315 98 - CptD415 List- CptD515 Err - 99 5- Alpha - Cpt216 5- Alpha - Cpt217 Z9999 - Cpt316 Z9999 - Cpt317 5- Alpha Z9999 - CptD317 Z9998 - Cpt416 Z9998 - Cpt417 Z9998 - CptD417 List - Cpt516 Err - Z9999 List - Cpt517 Err - Z9999 List - CptD517

Sicher Leben Description 120 Alpha Lecture du tableau : - Cpt218 Err - Z9999 - Prenons l exemple de la variable «TREATMENT». Cette variable est numérique (Num) sur 1 caractère. La liste des codes valides (List) comprend dans la V2000 les codes numériques de 1 à 9 (voir manuel de codage). - Si la modalité de cette variable est = (Missing), on ajoute 1 au compteur du nombre de modalités «Missing» pour cette variable (Cpt29). - Si la modalité de cette variable est = «9» (Unknown), on ajoute 1 au compteur du nombre de modalités «Unknown» pour cette variable (Cpt39). - Si la modalité de cette variable est = «8» (Other), on ajoute 1 au compteur du nombre de modalités «Other specified» pour cette variable (Cpt49). - Si la modalité de cette variable n est ni Missing (), ni comprise dans la liste des codes valides (par exemple, si cette valeur est = «M» ou «X», etc.), on ajoute 1 au compteur du nombre de modalités «Non valid range» de cette variable (Cpt59), on signale le record en erreur pour cette variable dans le listing des erreurs (Err) et on force sa valeur à «9» dans le fichier des enregistrements corrigés. Remarque : - Pour les variables «Type of injury 2» et «Part of body 2», on ne crée pas de compteurs de qualité pour la modalité «Missing», car ces variables ne sont complétées que s il y a une deuxième lésion (variables facultatives). Il en est de même pour la variable «Other product», on ne crée pas non plus de compteurs de qualité pour la modalité «Missing» (variable facultative). 40

IPP/2000/1070 Quality Control - Error! Style not defined. 3.2- DÉTAILS DES CONTRÔLES LOGIQUES : - Contrôles des dates : - Si (Date of birth renseignée > Date of injury renseignée) alors message d erreur L1 et Date of injury = missing - Si (Date of birth renseignée > Date of attendance) alors message d erreur L2 et Date of birth = missing - Si (Date of injury renseignée > Date of attendance) alors message d erreur L3 et Date of injury = missing - Contrôle Hospitalisation / Dates : - Si Date of attendance > Date of discharge renseignée alors message d erreur L4 et Date of discharge = missing - Si Date of discharge renseignée et Trt not = 5,6,7 alors message d erreur L5 et Trt = 5 - Contrôle Activity / Sport : - Si (Activity = Sport) et (Sport = Missing) alors message d erreur L6 et Sport = Unknown (Z99) - Si (Activity not = Sport) et (Sport = code sport valide) alors message d erreur L7 et Activity = Sport unspecified (59) 4- Description de l Etat Qualité On édite un Etat Qualité pour chaque fichier contrôlé. Cet état comprend plusieurs tableaux : 41

Sicher Leben - Caractéristiques du fichier en entrée : Nom du fichier La plus ancienne La plus récente Nombre de records date d accident date d accident du fichier en entrée - Contrôles sur le fichier entier : Nombre % / Nb de records en entrée Records en double (1) Records avec au moins une variable non remplie ou non valide (2) Records exclus (3) (1) à (6) : valeurs reprises dans le tableau donnant le score final de qualité du fichier. 42

IPP/2000/1070 Quality Control - Error! Style not defined. - Contrôles logiques (multivariables) : Nb des records % / Nb de records en entrée Erreur L1 (D. Birth > D. Injury) ou Erreur L2 (D. Birth > D. Attendance) ou Erreur L3 (D. Injury > D. Attendance) Erreur L4 (D. Attendance > D. Discharge) Erreur L5 (D. Discharge => Trt=5) Erreur L6 (Activity=Sport => Sport) Erreur L7 (Sport => Activity=Sport) % de records avec au moins (4) une erreur logique 43

Sicher Leben - Contrôles de conformité (monovariables) : Variable Missing % record Unknown % record Other specified. % record Non valid range % record Country x x x x Sex x x x Date of birth x x x Date of injury x x x Time of injury x x x Date of attendance x x x Time of attendance x x x Date of discharge x x x Treatment x x x x Place x x x x Mechanism x x x x Activity x x x x Sport x x x x Type of injury 1 x x x x Type of injury 2 Part of body 1 x x x x Part of body 2 Product involved x x x x Product causing x x x x Other product Description x Average % by var. (5) (6) Variables prises en compte pour le calcul des moyennes par variable (dernière ligne du tableau) : - Nous avons indiqué par des croix dans le tableau la liste des variables prises en compte dans le calcul des pourcentages moyens par variable. 44

IPP/2000/1070 Quality Control - Error! Style not defined. - Ainsi pour le calcul de «Average % of Missing value by variable», nous sommons les pourcentages de records «Missing» de 18 variables et nous divisons par 18 pour obtenir la moyenne. - Pour le calcul des moyennes des autres colonnes, nous ne prenons pas en compte les variables facultatives : Type of injury 2, Part of body 2, Other product pour ne faire porter cette moyenne que sur les variables les plus importantes. 45

Sicher Leben - Caractéristiques du fichier corrigé : Nom du fichier La plus ancienne La plus récente Nombre de records date d accident date d accident du fichier en sortie - Caractéristiques du fichier des erreurs : Nom du fichier en entrée Nb des records avec au moins une erreur % des records avec au moins une erreur 46

IPP/2000/1070 Quality Control - Error! Style not defined. - Score final de qualité du fichier : Ce tableau reprend des éléments d information les plus significatifs des tableaux précédents : Score final de qualité du fichier % de records en double (1) % de records exclus (3) % de records avec au moins une variable non remplie ou non valide (2) % de records avec au moins une erreur logique (4) % moyen de modalité non remplie (missing) par variable (5) % moyen de modalité non valide par variable (6) 47

Sicher Leben 5- Le listing des erreurs Il comprend : - l édition du tableau précédent : Caractéristiques du fichier des erreurs - l édition des records exclus avec la cause d exclusion (Country / Date of attendance manquant) - l édition de chaque record ayant au moins une erreur avec le ou les noms des variables en erreur 6- FICHIER TEST Nous fournissons le logiciel avec un fichier test de 100 enregistrements HLA au format V2000 où nous avons volontairement introduit de nombreuses erreurs. Le programme demande le nom du fichier en entrée (xxx\testv2k2.txt) et le nom du fichier corrigé en sortie. Il fournit après exécution : - le nom du fichier des erreurs (.log) avec les causes d erreur par enregistrements - la visualisation ou l impression du tableau de bord «Statistics for Quality Control» - le fichier corrigé en sortie. 48

IPP/2000/1070 Quality Control - Error! Style not defined. APPENDIX 5. UN PROGRAMME COMMUN DE CONTROL DE LA QUALITÉ DU CODAGE DES DONNÉES RECUEILLIES DANS LE SYSTEME EHLASS By Nectoux, Marc.Travaux EHLASS France. Un programme commun de control de la qualité du codage des données recueillies dans le systeme EHLASS. December 2000. Travaux EHLASS France Un programme commun de contrôle de la qualité du codage des données recueillies dans le système EHLASS Marc Nectoux et Dr Jean-Pierre Darlot 1- CONTEXTE L équipe française en charge du système EHLASS propose de développer un programme informatique commun de contrôle de la qualité du codage des données EHLASS. Un tel programme n existe pas en tant que tel au niveau européen : - chaque Etat membre applique sa propre politique de validation du codage des données EHLASS. Il s ensuit que le niveau des contrôles est assez différent d un Etat à l autre, ce qui est préjudiciable à la qualité globale des données européennes, au moment où des bases de données EHLASS communes vont être accessibles, via le réseau Internet. 49

Sicher Leben - à notre connaissance, les contrôles effectués par les Etats membres sont uniquement des contrôles de conformité monovariables (conformité à une liste de codes pour les variables qualitatives, appartenance à des fourchettes de valeurs pour les variables quantitatives). Il n y a pas ou très peu de contrôles de cohérence au sens de contrôles multivariables, comme par exemple celui pouvant porter sur les variables «Type de lésion» et «Partie du corps lésée». On peut avoir ainsi dans les données EHLASS actuelles une «fracture de l oeil» («fracture» : code 04 de la variable Type de lésion et «Oeil» : code 13 de la variable Partie du corps lésée), ce qui est manifestement impossible. Il n y a pas non plus de contrôle de la valeur informative globale de l observation. C est pour remédier à cet état de fait que nous décrivons dans ce document un programme commun de contrôle de la qualité du codage des données EHLASS que nous avons développé. * Texte ou résultats non utilisables sans l accord de Psytel 2- PRINCIPES DE DÉVELOPPEMENT - Les contrôles de validation sont applicables à deux moments différents de la vie des données, impliquant des logiques de correction différentes : - soit a priori : le contrôle s effectue au moment de la saisie et on signale alors les erreurs, les associations rares de modalités ou les informations manquantes pour examen et correction immédiate ou mise en attente de l enregistrement dans une optique de correction interactive par retour à la source de l information (patient, personnel soignant ou personnel administratif), - soit a posteriori : le contrôle s effectue après saisie des données, sans retour possible à la source de l information. On est amené alors, soit à rejeter l intégralité de l enregistrement, soit à forcer les valeurs erronées. - Le programme développé ici s inscrit dans cette seconde logique. Il conduit à créer un «score de qualité du codage» en attribuant un score à chaque observation. Quand ce score de qualité est inférieur à un seuil choisi, on rejette l observation entière, quand il est supérieur, on verse l enregistrement dans la base centrale, en corrigeant automatiquement, s il y a lieu, les erreurs. 50

IPP/2000/1070 Quality Control - Error! Style not defined. - Les différents scores et le seuil doivent être facilement paramétrables pour tester l adéquation du programme aux objectifs de qualité du codage et de rendement du système d information. - Pour programmer les contrôles de qualité du codage, nous nous appuierons sur deux éléments : la logique du recueil d information lui-même et l expérience acquise dans le recueil déjà effectué par le passé, dans une optique d auto-apprentissage des contrôles nécessaires. - Enfin, nous distinguerons deux axes dans la mesure de la qualité du codage des données déjà recueillies, indépendamment du processus même de recueil qui possède ses propres critères de qualité (qualité du recueil : respect des critères de sélection, exhaustivité des cas,...) : - un axe «conformité du codage», par rapport aux normes établies, c est ce que mesure un programme de contrôle classique, mais nous y ajouterons des contrôles de cohérence, - un axe «richesse de l information recueillie» qui tient compte du caractère informatif des données. En effet, on peut avoir des observations totalement conformes, mais avec un caractère informatif très faible, comme par exemple, une observation avec une majorité de variables avec des modalités «Inconnu» et un texte libre vide. Chaque observation recueillie peut ainsi être appréciée au regard de ces deux critères, seules les observations à la fois suffisamment conformes, cohérentes et informatives pouvant être qualifiées pour être versées dans la base de données : 51

Sicher Leben Nuage des observations Max. x Conformité ensemble des et cohérence x x observations des données x qualifiées x x xx Seuil paramétrable x x x x x Max. 0 Seuil paramétrable Richesse de l information 52

IPP/2000/1070 Quality Control - Error! Style not defined. 3- CONTRÔLE DE LA CONFORMITÉ ET DE COHÉRENCE DES DONNÉES 3.1- Les contrôles monovariables Ils sont indispensables. C est la première étape de la validation des données. Il faut au moins que : - les modalités des variables qualitatives (Mécanisme, Activité, Lieu, Lésion 1 et 2, Partie Lésée 1 et 2, Traitement, Produits) appartiennent à la liste officielle du codage, c est-à-dire pour le moment, à la version V86; - les valeurs des variables quantitatives (Age, Dates, Durée d hospitalisation) appartiennent à une fourchette de valeurs définies. Si l enregistrement est conforme à ces contrôles, c est un niveau de conformité 1 (score de conformité = 1, pour chaque modalité de variable dans la liste ou la fourchette prévue, sinon score = 0). 3.2- Les contrôles logiques Nous nommons ainsi tous les contrôles qui sont formalisables comme suit : si (Var 1 = xxx), alors (Var 2 = yyy ou liste) Si l enregistrement est conforme à ces contrôles, c est un niveau de cohérence 2 (score de cohérence = 3, sinon score = 0). Dans le système EHLASS, nous n avons qu un seul contrôle logique de cette forme : Si (Traitement = hospitalisation) alors il faut que (Durée d hospitalisation = 1-30 ou 39). 3.3- Les contrôles de cohérence Nous nommons ainsi tous les contrôles qui sont formalisables comme suit : Si (Var 1 = xxx et Var 2 = yyy) alors incohérence dans les données Si l enregistrement est conforme à ces contrôles, c est un niveau de cohérence 3 (score de cohérence = 2 ou 3, sinon score = 0). Quand on veut effectuer ce type de contrôle, deux difficultés apparaissent : 53

Sicher Leben - une difficulté d ordre quantitative : si l on considère l ensemble des variables EHLASS essentielles (Age, Sexe, Mécanisme, Activité, Lieu, Lésion 1 et 2, Partie Lésée 1 et 2, Traitement, Produits 1, 2), soit un total de 12 variables, il paraît difficile de programmer ne serait ce que tous les contrôles de cohérence de variables pris 2 à 2. Il y aurait en effet 66 combinaisons possibles (12 x 11 / 2). Il faudrait encore y ajouter les contrôles 3 à 3, etc. Il faut donc opérer un choix logique et judicieux pour ne programmer que les contrôles de cohérence réellement utiles. - une difficulté d ordre qualitative : comment décider qu une combinaison de modalités est «non cohérente»? C est parfois facile (cas précédent de la «fracture de l oeil»), c est parfois plus délicat (ex : un bébé de 6 mois ayant un accident dans une discothèque <=> Age < 1 an, Lieu = «discothèque»). Ce cas sera très rare. Il s agira le plus souvent d une erreur de codage, mais il peut aussi s agir d une circonstance réelle. Pour répondre à ces difficultés, et compte tenu que notre programme est un programme de contrôle du codage après saisie (et non d aide à la saisie), nous avons adopté la stratégie suivante : Résolution de la difficulté d ordre quantitatif : On peut dresser une matrice croisant les principales variables EHLASS avec elles-mêmes pour décider des contrôles de cohérence pertinents. Par exemple, dans une description d accident on peut avoir a priori toutes les combinaisons de sexe et d âge. Il n y aura donc pas de contrôle de cohérence a posteriori à ce niveau. Les seuls contrôles de cohérence que nous avons choisis d effectuer portent sur : Lésion 1 x Partie Lésée 1 Lésion 2 x Partie Lésée 2 pour éviter des associations du type «fracture de l oeil», «intoxication du doigt», etc. Mécanisme x Lésion 1 Mécanisme x Lésion 2 pour éviter des associations du type «Mécanisme = effort», «Lésion = intoxication», etc. Age x Activité pour éviter des associations du type «bricolage chez les moins de 1 an» ou «activité scolaire chez les plus de 75 ans». 54

IPP/2000/1070 Quality Control - Error! Style not defined. Résolution de la difficulté d ordre qualitatif : Notre choix a été d utiliser : le «bon sens», l histoire du système EHLASS (pour lequel des contrôles de ce type étaient prévus, mais qui n ont jamais été mis en pratique) et enfin l expérience acquise durant les années de codage précédentes pour nous en servir comme une sorte de base d apprentissage. Ainsi, nous avons analysé les données EHLASS France de 1987 à 1989, pour déterminer les fréquences des combinaisons des variables à contrôler. La règle d examen appliquée est la suivante : si la fréquence d une combinaison de modalités est inférieure à un certain seuil, le risque d incohérence sémantique est plus fort. Cela revient à faire l hypothèse, acceptable, que les erreurs sont rares par rapport aux données cohérentes. Ainsi, par exemple, pour le contrôle de cohérence des variables Lésion (18 codes) x Partie lésée (47 codes) la distribution des fréquences de combinaisons (18 x 47 = 846) par ordre décroissant montre que nous avons 570 combinaisons dont l effectif est inférieur ou égal à 10. Les 276 combinaisons les plus fréquentes (33 %) concentrent plus de 99,2% des effectifs. La description des accidents repose donc sur des grands types d association Lésion x Partie lésée, ce qui augure d une assez bonne cohérence globale des données. Sur les 95 814 observations françaises de 1987 à 1989, nous avons pris comme seuil d examen approfondi de la cohérence la fréquence 1/10 000. Si une observation appartient à une combinaison de modalités de fréquence inférieure à 1/10 000, elle est examinée sémantiquement attentivement pour la déclarer ou non incohérente. Les associations plus fréquentes sont aussi examinées sémantiquement, mais le risque d incohérence est a priori moins important. Nous avons ainsi établi trois listes d associations de modalités incohérentes. Dans le cadre d un programme européen, cette procédure devrait bien entendu faire l objet d un consensus d experts.- En définitive nous obtenons le tableau général des contrôles suivant : 55

Sicher Leben Contrôles de conformité Contrôles monovariables : Modalités conformes Score de conformité Age 200-223 2 002-149 Sexe 1,2 1 Date d entrée jj/mm/aa 1 Heure d entrée 00-23 0 Activité Liste V86 2 Mécanisme Liste V86 2 Lieu Liste V86 1 Lésion 1 Liste V86 2 Partie lésée 1 Liste V86 1 Traitement Liste V86 2 Durée d hospitalisation (si hospital.) 1-30, 39 2 Produit impliqué dans l accident Liste V86 2 Produit ayant causé la lésion Liste V86 2 Total maximal de ces contrôles 20 Contrôles de cohérence Modalités cohérentes Score de cohérence Contrôle logique : si Traitement = 5 (hospital.) alors Durée hospital. entre 1 et 30 ou 39 2 Contrôles de cohérence : Lésion 1 x Partie Lésée 1 ou Lésion 2 x Partie Lésée 2 Mécanisme x Lésion 1 ou Mécanisme x Lésion 2 Age x Activité Hors liste Incoher 1 Hors liste Incoher 2 Hors liste Incoher 3 3 3 2 Total maximal de ces contrôles 10 Total maximal de l ensemble 30 56

IPP/2000/1070 Quality Control - Error! Style not defined. A l issue de cette phase, nous construirons un score de contrôle : Score de contrôle = (score de conformité) + (score de cohérence) Le score de contrôle peut donc varier de 0 pour un enregistrement totalement non conforme et incohérent, jusqu à 30 pour un enregistrement totalement conforme, logique et cohérent. 4- CONTRÔLE DE LA RICHESSE INFORMATIVE Pour contrôler la richesse informative de chaque enregistrement, nous proposons de procéder de la façon suivante : si, avant correction automatique, la modalité de la variable est différente de «Inconnu», alors on attribue un score de spécification en fonction de l importance estimée de l information présente. Nous proposons la construction du tableau suivant : 57

Sicher Leben Variable Modalité non égale à Score de spécification Age Inconnu 2 Sexe Inconnu 1 Date d entrée Inconnu 1 Heure d entrée Inconnu 0 Activité Inconnu 1 Mécanisme Inconnu 1 Lieu Inconnu 1 Lésion 1 Inconnu 1 Partie lésée 1 Inconnu 1 Traitement Inconnu 2 Durée d hospitalisation (si hospital.) Inconnu 2 Produit impliqué dans l accident Inconnu 2 Produit ayant causé la lésion Inconnu 2 Texte libre (décomposé en mots non vides i.e. en séquences de plus de 2 caractères) 5 mots et + 1-4 mots 3 2 Total maximal 20 Score de richesse = (score de spécification de chaque variable) Le score de richesse informative peut donc varier de 0 pour un enregistrement où la totalité des variables est de modalité «Inconnu» et où le texte libre est vide, jusqu à 20 pour un enregistrement sans aucune variable de modalité «Inconnu» et avec un texte libre d au moins 5 mots non vides (séquences de plus de 2 caractères). - En définitive nous définissons le score de qualité du codage comme la somme des deux scores précédents : Score de qualité du codage = Score de contrôle + Score de richesse informative Il peut donc varier de 0 (qualité nulle) à 50 (qualité maximale). 58

IPP/2000/1070 Quality Control - Error! Style not defined. 5- LE PROGRAMME DÉVELOPPÉ C est un programme de contrôle automatique de la qualité du codage des données déjà saisies sur les sites de recueil, en conformité avec la version V86 (programme FORTRAN). On peut aisément extrapoler la logique de ces contrôles avec une nouvelle version de codage (par exemple, la V2000). A l issue du processus, chaque enregistrement se voit attribuer un score de contrôle et un score de richesse informative. Après avoir paramétré chacun de ces seuils, soit on rejette l enregistrement quand l un des seuils n est pas atteint, soit on force les valeurs erronées des variables au code «Inconnu» quand ces seuils sont dépassés et qu il y a lieu de corriger l enregistrement. L observation est alors réputée de «qualité», c est-à-dire suffisamment conforme, cohérente et riche pour être qualifiée pour la base nationale et/ou la base européenne. On peut aussi éditer pour l ensemble des données la distribution des scores, leurs moyennes et écarts-types et le pourcentage d observations qualifiées pour les seuils paramétrés. 6- APPLICATION AUX DONNÉES FRANÇAISES DE 1997 Nous avons appliqué le programme développé aux données en sortie des 8 sites de recueil français, avant le contrôle centralisé que nous effectuons. Les résultats sont les suivants sur les 51 025 observations de l année 1997 : Caractéristiques des scores : Type de score Moyenne Ecart-type Minimum Maximum Score de contrôle 29,410 1,2771 18 30 Score de richesse 17,831 2,0298 6 20 Score de qualité du codage 47,241 2,9228 28 50 Remarques : - La moyenne du score de qualité est élevée (47,2 pour un maximum de 50). La qualité globale des données recueillies est satisfaisante. 59

Sicher Leben - Cependant, la moyenne du score de richesse informative est relativement plus faible que celle du score de contrôle. Il y a des efforts à faire pour améliorer ce score : encore trop de texte libre vide ou peu utilisé et encore trop de modalités «Inconnu» dans les variables de codes. Distribution des effectifs du score de contrôle : Sc. de contrôle Effectif 18 1 19 0 20 1 21 2 22 89 23 0 24 107 25 12 26 4177 27 7 28 5949 29 3 30 40677 Total 51025 Remarques : - Les effectifs des scores impairs sont peu nombreux car les scores de conformité sont souvent pairs. - 91,38 % des observations ont un score de contrôle supérieur ou égal à 28, soit le plus souvent une erreur au maximum. 60

IPP/2000/1070 Quality Control - Error! Style not defined. Distribution des effectifs du score de richesse : Sc. de richesse Effectif 06 7 07 0 08 3 09 5 10 24 11 144 12 264 13 2981 14 776 15 3692 16 1901 17 8174 18 7954 19 14829 20 10271 Total 51025 Remarques : - Certaines observations ont un score de richesse faible. - 84,53% des observations ont un score de richesse informative supérieur ou égal à 16, soit deux variables importantes à «Inconnu», au maximum. Qualification des observations : - En fixant comme seuils de qualification : un minimum de 28 sur 30 pour le score de contrôle et un minimum de 16 sur 20 pour le score de richesse, nous qualifions 42 063 observations soit 82,44% des observations recueillies. Ces observations sont à la fois conformes, cohérentes et riches. Remarques : - Bien entendu, ces seuils peuvent être modifiés selon l exigence des utilisateurs. 61

Sicher Leben - Parmi les enregistrements ayant un score de richesse supérieur ou égal à 16, seulement 2,5% ont un score de contrôle inférieur à 28. La richesse informative est donc fortement corrélée à la conformité et la cohérence : la quasi-totalité (97,5%) des enregistrements riches sont conformes et cohérents, l inverse étant un peu moins vrai (90,2% des enregistrements conformes et cohérents étant riches). 7- UTILISATIONS DU PROGRAMME DE CONTRÔLE COMMUN Nous voyons deux types d utilisation à ce programme : Utilisation nationale : Le programme peut servir à mesurer la qualité du codage des données recueillies pour chaque site de recueil et donc être utilisé comme un indicateur de la qualité du codage. Ainsi, pour la France nous pouvons établir le tableau suivant, à partir des données 1997 : Sites de recueil Sc. de contrôle moyen Sc. de richesse moyen Hôpital A 29,873 17,858 Hôpital B 29,327 18,925 Hôpital C 29,542 19,711 Hôpital D 29,990 17,986 Hôpital E 29,533 18,798 Hôpital F 26,381 13,477 Hôpital G 29,975 16,084 Hôpital H 29,938 18,573 Moyenne générale 29,410 17,831 62

IPP/2000/1070 Quality Control - Error! Style not defined. Remarques : - Les scores de contrôle moyens sont proches les uns des autres, sauf pour l hôpital F. - Les scores de richesse moyens sont plus dispersés. Le plus faible est celui de l hôpital F qui semble donc poser un problème important de qualité de codage. Utilisation européenne : Pour le moment le cheminement des fichiers est majoritairement le suivant dans les Etats membres : Programme Site de recueil de contrôle local LA Site national Programme Programme Site de recueil de contrôle de contrôle Rapport annuel local LB national N1 national Programme Site de recueil de contrôle local LC Il y a donc une grande hétérogénéité des programmes de contrôle : les programmes de contrôle locaux (LA, LB, LC, etc.) peuvent être différents entre les sites d un même Etat (comme en France), les programmes de contrôle nationaux (N1, etc.) sont différents d un Etat à l autre. 63

Sicher Leben - Nous proposons le cheminement suivant, incluant notre programme de contrôle commun C : Programme Site de recueil de contrôle local LA Site national Programme Programme Site de recueil de contrôle de contrôle Base de données local LB commun C européenne Programme Site de recueil de contrôle local LC Notre programme de contrôle commun peut aussi être utilisé juste avant l entrée dans la base européenne et non au niveau de chaque site national, si cela pose un problème. 64

IPP/2000/1070 Quality Control - Error! Style not defined. 8- CONCLUSIONS Les avantages du programme commun de contrôle de qualité du codage que nous avons développé sont nombreux : - Notre programme assure un niveau homogène de contrôle de toutes les observations avant versement dans la base européenne. - Il améliore sensiblement les simples contrôles de conformité actuels. La base européenne ne contiendra donc que des observations suffisamment conformes, cohérentes et riches. - Le niveau d exigence de qualité du codage est paramétrable du fait de la création des scores de qualité de codage (score de contrôle, score de richesse informative). - On peut aisément extrapoler la programmation de ces contrôles avec une nouvelle version de codage (par exemple, la V2000). Nous proposons à la Commission de mener une discussion avec d autres experts nationaux pour construire un programme de ce type, validé par tous, afin d améliorer sensiblement la qualité du codage des données du futur système de recueil d informations sur les accidents domestiques et de loisirs, dans le cadre du programme «Prévention des blessures». 65

This report was produced by a contractor for Health & Consumer Protection Directorate General and represents the views of the contractor or author. These views have not been adopted or in any way approved by the Commission and do not necessarily represent the view of the Commission or the Directorate General for Health and Consumer Protection. The European Commission does not guarantee the accuracy of the data included in this study, nor does it accept responsibility for any use made thereof.