Quality improvement of causes of death statistics by automated coding. Improvement of the automated coding system for causes of death IRIS

Transcription

1 Quality improvement of causes of death statistics by automated coding Improvement of the automated coding system for causes of death IRIS Final Report 2009 Eurostat grant Theme: 1.05 Health and Safety Lars Age Johansson National Board of Health and Welfare Sweden Gérard Pavillon Inserm-CépiDc France László Pelikán Central Statistical Office of Hungary Hungary Stefanie Weber DIMDI Germany Björn Witting Statistisches Bundesamt Germany

2 Table of contents 1. Background and summary Background Summary Task 1 - Project Management Meeting 1. Cologne - Germany Meeting 2. NCHS Raleigh (NC) - United States Meeting 3. Bonn - Germany Meeting 4. NCHS Raleigh (NC) - United States Meeting 5. Stockholm Meeting 6. Workshop Bonn Meeting 7. Budapest Meetings in Oslo*** Task 2: Dissemination towards ESSnet Task 3: Translating the international interface of Iris Task 4: Standardized test deck for quality, plausibility and validation checks for coding in Iris Task 5: Training deck for demonstration and training purposes Task 6: Develop a module equivalent to the MICAR module of the MMDS ICD codes and code modification Code modification: Technical principles Modifications dependent on non-medical data Code modification dependent on other medical conditions Tables specifying code modifications Algorithm Processing of surgery and other medical procedures in Iris a special case Recognize complications Flag conditions as cause of surgery/procedure Task 7: Workshop for implementation of Iris for interested Member States Aims and participants Feedback and suggestions Task 8: Improvement of manuals for dictionary development and language standardisation Annexes Annex 1 MMDS - Iris Meeting agenda...41 Annex 2 Iris Overview presentation...42 Annex 3 MMDS-Iris Meeting minutes...51 Annex 4 QUESTIONS ABOUT IRIS /11/ :03:28 Report 2

3 Annex 5 Bonn meeting agenda...57 Annex 6 NCHS meeting agenda...58 Annex 7 Stockholm meeting agenda...59 Annex 8 Bonn workshop agenda...60 Annex 9 Budapest meeting agenda...62 Annex 10 Budapest meeting minutes...63 Annex 11 Tech cod Iris presentation...68 Annex A01 Invitation to the Bonn workshop***...73 Annex A02 Notes on planned developments of the software and on noted software problems***...74 Annex A03 Agenda for the Users Group meeting in Oslo, 7-9 September 2011***.81 Annex A04 Participants in the Users Group meeting***...82 Annex A05 Notes on planned developments, revised according to requests and decisions made at the meetings in Oslo 5-7 September 2011***...83 Annex A06 Presentation at the Users Group meeting in Oslo of planned developments***...92 Annex A07 Presentation of the updated Iris interface***...97 Annex A08 Presentation of technical principles for multiple cause coding in Iris*** Annex A09 Presentation of technical principles for coding of adverse reactions to medical procedures in Iris*** Annex A10 Presentation of current status (implementation as per 2 November 2011)*** Annex A11 Main releases of the software September September Annex A12 List of problems encountered in MMDS (MICAR and ACME) application of rules and instructions in Volume 2 of ICD-10*** /11/ :03:28 Report 3

4 1. Background and summary 1.1 Background Causes of Death (CoD) statistics are of crucial importance both for health monitoring systems and in epidemiology. CoD data are collected routinely in all ESS member states, but differences in assignment of the underlying cause of death impair comparability and consistency at the European level. The introduction of a common automated coding system (ACS) could overcome that problem, since the same classification procedures and the same version of the ICD would then be followed by all ESS members. Further, the Eurostat norms for validation and quality assurance of mortality data would be implemented uniformly, since they would be integrated in the ACS. Some ESS countries are already using ACS, while others are planning or considering using ACS. In 2001 France (Inserm CépiDc) and Sweden (National Board of Health and Welfare SoS) decided to develop Iris, a languageadaptable system for computerized coding and classification of causes of death. Germany (Statistisches Bundesamt Destatis and Deutsches Institut für Medizinische Dokumentation und Information DIMDI) and Hungary (Hungarian Central Statistical Office - HSCO) joined that development in Together with Italy (Istituto nazionale di statistica ISTAT), which joined the effort in 2010, these five institutions now form the Iris Core Group. Since 2008 Iris is a complete international coding system with three existing national adaptations (Germany, Sweden and Turkey) and a basic international interface in English. All decisions about software development and improvement have been agreed by all partners and with the primary aim of creating an easyto-use coding environment conforming to all international standards. The partners are members of or are in close contact with all international organizations and authorities in the field of coding and classification of causes of death, such as the WHO Family of International Classifications network (WHO-FIC) and the International Collaborative Effort (ICE) on Automation of Mortality Statistics. 18/11/ :03:28 Report 4

5 1.2 Summary Through Grant Agreement to the Iris Core Group, through the main beneficiary DESTATIS, Eurostat has supported the development of Iris and the implementation of Iris in ESS countries. ***The agreement ran from 1 December 2009 and was originally planned to end on 31 May However, because of unforeseen changes to available staff, the end of the project was extended till 30 September 2011.*** The Group has completed the following tasks specified in the grant application form: Task 1: Project management, achievement of endeavours of project Task 2: Dissemination towards the ESS Task 3: The ability to translate the international interface of Iris Task 4: Standardised test deck for quality, plausibility and validation checks for coding in Iris Task 5: Training deck for demonstration and training purposes Task 6: Develop a module equivalent to the MICAR module of the MMDS Task 7: Workshop for implementation of Iris for interested Member States Task 8: Improvement of manuals for dictionary development and language standardisation The completion of the various tasks is described in the present report. Further deliverables referred to in the report are included in the Annexes, or are available on the Iris website: 18/11/ :03:28 Report 5

6 2. Task 1 - Project Management The objective of this task was to manage the project throughout its entire duration. The coordination between partners, the definition and control of the project schedule has been done during 7 meetings gathering together all the partners. Two meetings in Raleigh (US NC) allowed the Iris Group to work with all the people in charge of the US coding system at the National Centre for Health Statistics (NCHS). This report is the result of the work done during these meetings and in between. The specific deliverables of the meetings are mentioned below and put in the annexes. 2.1 Meeting 1. Cologne - Germany Date: 11 January 2010 This meeting aimed at: defining a global planning for the entire project evaluating the different tasks starting the discussion on technical solutions sharing the work defining the basis of a cooperation with the National Centre for Health Statistics (NCHS) It appears that there were enough specifications to begin with Iris version 4 development. We started to gather data to build training and test decks. The following meetings were planned: NCHS in February 2010 Stockholm in September 2010 Budapest April 2011 Bonn for the Workshop at the end of /11/ :03:28 Report 6

7 2.2 Meeting 2. NCHS Raleigh (NC) - United States Dates: 9 to 12 February 2010 The main goal of this meeting was to work with the nosologists and IT staff of the NCHS to set the bases of cooperation on joint updates of the US software (Mortality Medical Data System - MMDS) and of Iris. A first technical meeting with Donna Glenn, the historical designer of the MMDS, and nosologists clarified the complex role of Entity Reference Numbers (ERN) that are used in MMDS. On 10 February, a meeting was organized with MMDS new designers working in Raleigh and people from NCHS in Washington. This meeting was chaired by Sam Notzon from NCHS. Annex 1 gives the meeting agenda. The main discussions concerned the presentation of respective projects for MMDS and Iris and the possibilities to establish future cooperation. Annex 2 provides the Iris presentations and Annex 3 the Report of the meeting. The rest of our stay in Raleigh has been devoted to technical work with the US nosologists. Basic procedures were agreed for the exchange of data and knowhow between our two groups. A list of questions sent by Spain has been answered (Annex 4). Annex 1 - MMDS - Iris Meeting agenda Annex 2 Iris Overview presentation Annex 3 MMDS-Iris Meeting minutes Annex 4 QUESTIONS ABOUT IRIS 18/11/ :03:28 Report 7

8 2.3 Meeting 3. Bonn - Germany Date: 3 March 2010 This meeting aimed at evaluating the outcomes of the NCHS meeting and at discussing the ongoing developments of Iris (Annex 5). Technical advances have been made on the access to MMDS tables necessary for updating of Iris. It proved necessary to organise a second meeting with NCHS to clarify critical problems in the updates of Iris and MMDS tables and to make it possible for us in the Iris Group to make updates to the ACME decision tables ourselves. Annex 5 Bonn meeting agenda 2.4 Meeting 4. NCHS Raleigh (NC) - United States Dates: 17 to 20 August 2010 RTP This meeting has been devoted to discuss the work the Iris Group had already done on the MMDS tables with NCHS nosologists, and to solve technical problems linked to the MMDS system that appeared during the development of the new version. A detailed study of the MMDS module Micar was also done with help of NCHS ITs. An update of the NCHS-Iris group cooperation was reviewed. Annex 6 NCHS meeting agenda 18/11/ :03:28 Report 8

9 2.5 Meeting 5. Stockholm Date: 14 September 2010 This meeting allowed us to follow up the Eurostat grant project and to organize the workshop in January A complete examination of the development status was done. In connection with the Core Group meeting a Users Group meeting was also organized. Annex 7 Stockholm meeting agenda 2.6 Meeting 6. Workshop Bonn Dates: 31 January - 4 February 2011 The organisation of this workshop is part of the project (Task 7). The workshop was hosted by Germany (DESTATIS) in Bonn. After invitations, seventeen countries attended with 25 participants. The countries were: Belgium, Croatia, Cyprus, Czech Republic, England/Wales, Estonia, Italy, Lithuania, Luxembourg, Malta, Netherland, Norway, Poland, Portugal, Slovenia, Spain and Switzerland. This workshop focused on practical exercises in setting up and using Iris. Technical issues and setting up Iris Developing dictionary and standardization Using Iris Questions and discussion This meeting was a success because of the number of participating countries, the number of participants but also for the discussions. These exchanges resulted in many propositions on future Iris developments (see also Section 8 (Task 7). Annex 8 Bonn workshop agenda Annex A01 Invitation to the Bonn workshop*** 18/11/ :03:28 Report 9

10 2.7 Meeting 7. Budapest Dates: 6/4/2011 This meeting was held to finalize the project task and the report (Annex 9 and 10). The content of the presentation made at the Eurostat Tech Cod meeting in Luxembourg on 5 and 6 May was also defined (Annex 11). Annex 9 Budapest meeting agenda Annex 10 Budapest meeting minutes Annex 11 Tech cod Iris presentation 18/11/ :03:28 Report 10

11 2.8 Meetings in Oslo*** 5 6 September (Core Group), 7 9 September (Users Group) The two meetings in Oslo were not included in the original project plan and were not funded by the Eurostat grant 1. The Core Group discussed further developments of the software (see Annex A02), and the Users Group (see Annex A03-A04) provided valuable feedback on the current version of Iris. The Users Group meeting resulted in an updated version of the Iris Developments document, see Annex A05. Presentations given at the Oslo meeting are attached. Annex A02 Notes on planned developments of the software and on noted software problems*** Annex A03 Agenda for the Users Group meeting in Oslo, 7-9 September 2011*** Annex A04 Participants in the Users Group meeting*** Annex A05 Notes on planned developments, revised according to requests and decisions made at the meetings in Oslo 5-7 September 2011*** Annex A06 Presentation at the Users Group meeting in Oslo of planned developments*** Annex A07 Presentation of the updated Iris interface*** Annex A08 Presentation of technical principles for multiple cause coding in Iris*** Annex A09 Presentation of technical principles for coding of adverse reactions to medical procedures in Iris*** Annex A10 Presentation of current status (implementation as per 2 November 2011)*** 1 Some travel costs (e.g. Dona Glenn) were funded by the Eurostat grant. 18/11/ :03:28 Report 11

12 3. Task 2: Dissemination towards ESSnet The role of this task is to collect and to make available the documents and presentations produced during the time of this grant to inform and to train users on Iris. Most of the presentations were made during the Bonn Workshop. The following powerpoints are available: 1. Agenda 2. System overview 3. Standardization and Dictionary 4. Coding with Iris The documents describing Iris are the Iris manual, the Table manual and the tutorial on regular expressions. - The manual is an extensive description of Iris including installation, a quick start guide (How to use Iris section), a reference description of the interface (Menus and tools section), a database description and an introduction to standardization. ***The manual also includes a description on how to translate the Iris interface (screens and messages) to other languages (see Section 4, Task 3).*** - The Table manual gives a short description of the tables necessary for Iris processing and a detailed section on how to develop and maintain Iris dictionary. - The Tutorial on regular expression is a very detailed description on how to write regular expression in Iris for language standardization. All these documents have been written to help user with Iris implementation and use. They take advantage of users feed back and reported difficulties. 18/11/ :03:28 Report 12

13 All presentations and documents are available for download on Iris website. Follow the link: ***Iris version , released in May 2011, is the latest version made publicly available on the Iris website. At present, the software develops very quickly and several new versions have been distributed within the developers network since May. The most current version, , was released to the network on 10 October The developers have decided to release a public version through the website once a year only, since the project team does not have the capacity to produce a fully updated manual with each new intermediate version of the software. Also, limiting the number of releases to one per year gives the team a far better opportunity to thoroughly test the newly introduced features. The developers are reluctant to distribute a software to the general public that is not fully supported by a manual, although users with a previous experience of Iris can obtain the intermediate versions directly from the developers. A list of major new releases is given in Annex A11. The version numbering is non-consecutive, since the list does not include bug-fix releases that had no new features. Further, version , although released before the Eurostat project started (1 December 2009), is included as a point of reference. Annex A11 Main releases of the software September September 2011*** 18/11/ :03:28 Report 13

14 4. Task 3: Translating the international interface of Iris Iris uses hundreds of labels and messages. These texts are included in the controls such as button names, menus, tools etc. For instance the Iris main window in English displays numerous labels: The red ellipses shows the names "File" for the menu file, the label "Dictionary" for the dictionary tool and the label "Diagnosis text". It is important that all these texts can be translated in any language. It was also essential that this translation can be made by users without any need for programming expertise. This is why a mechanism was developed to allow an easy translation from a simple text file. How to do the translation is described in the Iris manual (section 3.6). 18/11/ :03:28 Report 14

15 At the moment, English, Czech, Swedish and French versions are available for download on the Iris website: ***When the Eurostat-funded project was planned the Core Group envisaged multiple versions of Iris. It was assumed that since death certificate contents and coding requirements differ several countries would need to develop their own national version. However, as the project moved on it became clear that maintenance would be less resource-intensive and international comparability better served if, as far as possible, countries would use the international version of Iris. The interface translation tool described in the manual greatly contributed to this development. Further, many features previously present only in some of the national versions have now been implemented in the international version. Accordingly, Norway and Sweden decided to discontinue the development of the Scandinavian version and to use the international version instead. For the time being only Germany maintains a national version, reflecting the broad differences in death certificate layout and contents among the German federal states. Note: A list of Iris versions, including new interface translation features, can be found in Annex A11. *** 18/11/ :03:28 Report 15

16 5. Task 4: Standardized test deck for quality, plausibility and validation checks for coding in Iris Because of the complexity of the Iris system, the effects of modifications to one or more components of the system may be difficult to predict. Also, changes to the two American modules currently used by Iris, MICAR and ACME, may produce unforeseen and unwanted effects. Therefore, it is important to test new Iris versions carefully, and also to test new versions of MICAR and ACME. When developing Iris V4 we used three data sets for testing. They contained actual cause-of-death data from Hungary, Italy and Sweden, ***coded and verified according to current statistics production practices in the three countries***. The Hungarian data set contained 130,193 records from 2009 and the Swedish 61,535 records, also from The Italian data set contained 625 records specifically selected because of their complexity, whereas the Hungarian and Swedish data sets represented a wider selection an entire data year from Hungary and the first two thirds of 2009 from Sweden. *** The records in the test decks retain their original data on sex, dates of birth, dates of death, and in relevant cases also dates of disease onset, date of surgery and date of injuries. Obviously these dates - and especially a combination of dates - make many of the records identifiable at the personal level. We still decided not to anonymize the data by changing the dates. The reason was that dates and durations all impact on ICD coding, and changing the dates would in many cases mean that the assigned ICD codes were not longer correct. Consequently, anonymized data sets would be less useful for testing how the code modification features in Iris and MMDS work. The decision not to anonymize the data sets raised sensitive issues of data protection. Finally, it was decided to limit access to the data to the three countries that had delivered them (Hungary, Italy and Sweden), but that the data would not be distributed further. As a consequence, the test data sets are not made available on the Iris website or attached to this report. *** 18/11/ :03:28 Report 16

17 We used the Italian and Swedish data sets to test the new decision tables for ACME that the Iris Group developed towards the end of The Hungarian data were used to test the entire Iris process, including selection of the underlying cause with the new ACME decision tables. So far we have limited the testing to a comparison of the underlying cause already assigned by the national cause-of-death statistics systems and the underlying cause assigned by the new versions of Iris and ACME respectively. However, we are now preparing further data sets that can be used for testing further aspects of automated coding, for example the impact of determinants such as age, sex, duration and details of external causes of injuries. ***During testing, a number of issues related to the interpretation of the numerous (and often far from self-explanatory) rules and instructions in Volume 2 of ICD-10 were encountered. When comparing the resulting underlying cause produced by the four coding systems involved the American MMDS, the Hungarian and Italian systems, and the Swedish Mikado system it became evident that coding practices differ between the countries. In some cases this was explained by the fact that one of the systems, and generally MMDS, had not implemented official WHO updates to the ICD according to the WHO schedule for updates. In other cases the ICD instructions themselves were ambiguous and could be interpreted in different ways. Such ambiguous cases have been referred to the international Mortality Reference Group for clarification. A summary of problems encountered so far is given in Annex A12. See also Section 10.4, Annex 4, Questions about Iris, where some issues related to data processing in MICAR and ACME are discussed. Annex A12 List of problems encountered in MMDS (MICAR and ACME) application of rules and instructions in Volume 2 of ICD-10*** 18/11/ :03:28 Report 17

18 6. Task 5: Training deck for demonstration and training purposes The Iris Group developed a set of certificates for demonstration and training purposes included as Workshop2011 in the Certificates database available for download on the Iris website at: (see Workshop material). This set of certificates was used for the first time in connection with the Iris workshop in Bonn (31 January 4 February 2011, see section 8). The set has 500 certificates and is composed of actual Swedish death certificates translated into English. We anonymized the records by changing all dates of birth and dates of death, however, and (with a few exceptions) setting the sex of the deceased to 1 (male). When translating the certificates we followed the originals as closely as possible and no cosmetics were applied, i.e., we tried to translate vague Swedish expressions into similarly vague English terms. Also, we kept different ways of expressing dates and durations, and we did not delete repetitions or superfluous words. Thus, we tried to compose a set of certificates that would give beginning users plenty of opportunities to practice language standardisation. The Workshop2011 set is designed for use with the 2011 Iris tables. If used in connection with the standard table set for 2011, about 70% of the terms are coded automatically in batch mode and the remaining 30% can be used for exercises in language standardisation and in adding further terms to the dictionary. The standardisation tables contain patterns for most common standardisation situations, which the coder can adapt to similar expressions and situations. 18/11/ :03:28 Report 18

19 The set contains some blocks of records that can be used for training in specific aspects of interactive coding, for example records number that deal with perinatal deaths, and records number that contain mentions of external causes or of surgery. 18/11/ :03:28 Report 19

20 7. Task 6: Develop a module equivalent to the MICAR module of the MMDS 7.1 ICD codes and code modification The Iris system uses the Dictionary table to map the diagnosis text to an ICD-10 code. In general, each diagnostic expression has only one entry in the Dictionary table. For example, the expression subdural hemorrhage has the ICD-10 code I62.0: Dictionary table: DiagnosisText SUBDURAL HEMORRHAGE I620 Icd1 IcdC Icd2 CodingFlag Likelihood Prompt YearStart 2005 YearEnd 2015 DateIn UserIn DateOut UserOut Comments OKForMultipleCodes FixForDT DesignedByDT NoStand1ByDT NoStand2ByDT However, according to ICD-10 many diagnostic expressions are coded differently depending on the circumstances. For example, the default code for the expression subdural hemorrhage is I62.0, as shown in the Dictionary table extract above. However, if the condition is the result of a birth injury the code is not I62.0 but P10.0, and if it is a traumatic subdural hemorrhage the code is S06.5. LAJ There are many further examples in ICD-10 of such code modifications. Even some very common conditions, such as myocardial infarction and pneumonia, are coded differently depending on other information on the death certificate. Therefore, it is crucial that an automated coding system is able to perform at least most of the code modifications automatically. 18/11/ :03:28 Report 20

21 In the current version of the Iris system most of the code modifications are handled by MICAR, which is one of the MMDS modules called by Iris. However, the MMDS is currently being redeveloped and the new version might not be callable by another software. Therefore, it will be necessary to replace MICAR by another module, and preferably by a module developed by the Iris Group. It would bring the further advantage that a black box in the Iris system (as MICAR now is) would be replaced by a module that is fully transparent to the Iris developers. 7.2 Code modification: Technical principles The code modification module will make use of code modification tables. The tables will specify first the default code, which is the input to the code modification process, and under which circumstances the default code would be replaced by another ICD code. Such reasons could be, for example, sex, age, other conditions mentioned on the certificate, the duration or status of the condition, whether the condition was traumatic or not, and whether the condition developed as a complication of surgery, medical treatment or a trauma. For processing reasons it seems appropriate to split the modifications in two tables, one dealing with modifications that are not dependent on other ICD codes on the certificate, and one dealing with modifications that do depend on other ICD codes. 7.3 Modifications dependent on non-medical data Code modifications could be dependent on, for example, the age of the decedent. In the following example the code I62.0 (subdural haemorrhage) is modified into the code P52.8, if the decedent is a child younger than one year: 18/11/ :03:28 Report 21

22 ModificationNotByIcdCodes table: Icd1 I620 IcdC Icd2 CodingFlag OrderNum Sex Age 0-12M Time NewIcd1 NewIcdC NewIcd2 IcdCodeAction LnkAction Likelihood P528 In this second example the default code for acute myocardial infarction, I21.9, is modified into I25.8 (Chronic ischaemic heart disease) if the infarction occurred more than 28 days before death: ModificationNotByIcdCodes table: Icd1 I219 IcdC Icd2 CodingFlag OrderNum Sex Age Time >28D NewIcd1 I258 NewIcdC NewIcd2 IcdCodeAction LnkAction Likelihood In some cases the modifications apply not to all conditions coded to a specific default code, but only to some of them. Such code modifications that do not affect all conditions in a specific ICD code could be handled by created codes (a fifth character that provides a subdivision of a four-character ICD code) or by connected codes (a general ICD code is specified further by a second code). For a closer description of the table items, please see section /11/ :03:28 Report 22

23 7.4 Code modification dependent on other medical conditions Modifications dependent on sex, age, duration and other such general information are fairly straightforward since it is comparably easy to link the default ICD code to a single value representing the modifying variable. It is more complex to evaluate a modification depending on other medical conditions reported on the death certificate, since the process needs to scan the entire certificate in order to capture all other conditions that might influence the modification, and also establish the type of relationship between the default code and the other condition(s) involved in the modification. Also, code modification may take place in several steps, where the outcome of one step influences what happens next. As regards the output of the modification process, there are two main types of code modification. First, the code modification may result in a change of code. For example, a cancer of lung can be coded as primary (C349) or secondary (C780). It is coded as primary if it is mentioned alone, but as secondary if it is mentioned together with another cancer that is not a common site of metastasis (ICD-10, Volume 2, section 4.2.7). In other cases the code modification may instead result in the addition of one or more other ICD codes to the default code. Multiple cause coding of surgery, for example, often means that codes are assigned not only for the surgery itself but also for the reason why the surgery was performed. Sometimes this reason is not clearly stated but only implied by the name of the procedure, for example appendectomy which implies appendicitis. In such a case the coding software should be able to determine if an additional code is needed, or if the reason for the surgery is already stated somewhere else on the death certificate. As mentioned above, the type of relationship between the codes may also impact on the code modification. For example, dementia (F03) reported as due to atherosclerosis (I70.9) is coded as vascular dementia (F01.9), but if the certificate does not imply a causal relationship between the atherosclerosis and the dementia then the code F03 should not be modified to F01. 18/11/ :03:28 Report 23

24 7.5 Tables specifying code modifications For the modification of ICD codes we intend to use two tables, one for specifying the modifications and the conditions under which they apply, and one that can be used to specify groups of ICD codes to which the same linkages apply, or that impact on a considerable number of other conditions. A possible layout of the ModificationByIcdCode table is outlined below: ModificationByIcdCodes table Icd1 Text (5) IcdC Text (5) Icd2 Text (5) OrderNum Integer CodingFlag Text IcdCodePos Text Lnk1Icd1 Text (100) Lnk1IcdC Text (5) Lnk1Icd2 Text (5) Lnk1CodingFlag Text (5) Lnk1Rel Text (2) Time text(100) Lnk1CodePos Lnk2Icd1 Text (100) Lnk2IcdC Lnk2Icd2 Lnk2CodingFlag Lnk2Rel Text (2) Lnk2CodePos NewIcd1 Text (5) NewIcdC Text (5) NewIcd2 Text (5) IcdCodeAction Text (1) LnkAction Text(1) Likelihood Text (1) DateTo Date - dd/mm/aaaa DateFrom Date - dd/mm/aaaa Comment Text (100) Icd1-Icd2 and OrderNum are the primary keys. Icd1-Icd2 contain ICD codes corresponding to entries in the Dictionary table, or to output ICD codes in other records in the modification tables. OrderNum is used to prioritize if there are several records for the same ICD code. 18/11/ :03:28 Report 24

25 CodingFlag is information carried over from the certificate, for example tick box values, that might have an impact on the modification of the default ICD code. IcdCodePos specifies whether the modification only applies to ICD codes in certain positions on the certificate, for example to conditions reported first on the lowest used line in Part 1. Lnk1Icd1-Lnk1Icd2 defines the set of ICD codes that would modify the code in the IcdCode field. As envisaged, the syntax would allow both single ICD codes and ranges of ICD codes in the Lnk1Icd1 field. For instance "C73, C760-C768" would indicate C73, C760, C761, C762, C763, C764, C765, C767 and C768. Further, a minus sign could be used to exclude a subset of codes. For example, "(C000-C969) ( C760-C789)" stands for all codes in the code range C000- C969 except C760-C789. In addition to ICD codes, code group names defined in the Code Groups table can be used to identify groups of ICD codes (see Code Group table below). If the modification applies to conditions defined by a value in Icd1 + IcdC and/or Icd2, code ranges cannot be used. Lnk1CodingFlag defines information carried over from the certificate, for example tick box values, that must be present for the modification to take place. Lnk1Rel defines the type of relationship that must exist between the Icd1-Icd2 codes and the Lnk1Icd1-Icd2 codes. Time specifies if a certain delay must exist between the condition in Icd1-Icd2 and the condition(s) in Lnk1Icd1-Icd2, and if so how long that delay should be. Lnk2Icd1-ICD2 and Lnk2Rel define a second set of link codes. If Lnk2Icd1- Lnk2Icd2, Lnk2CodingFlag and Lnk2Rel contain non-blank values, then the modification will not be carried out unless the certificate meets the conditions specified in all ten fields (Lnk1Icd1-LnkIcd2, LnkCodingFlag, Lnk1Rel, Lnk2Icd1-Lnk2Icd2 Lnk2CodingFlag and Lnk2Rel). NewIcd1-NewIcd2 contain the ICD code(s) the system will assign if the conditions are met. IcdCodeAction specifies if the modification consists in changing one ICD code into another, or if it means that an ICD code is added to the code(s) specified in the IcdC1-Icd2 fields. If it is an addition, it also specifies where to add the new code. 18/11/ :03:28 Report 25

26 The field LnkAction is used if several modifications apply to the same default ICD code, and specifies if all the modifications should be carried out or only one of them. That is, the field can be used to prevent a second modification from destroying the result of a first and prioritized modification. In the CodeGroups table the user can define sets of codes that are frequently used together and assign a name to them. He or she can then use these names rather than enumerating all ICD codes involved in the ICD code fields in the ModificationByIcdCode table. CodeGroups table: Name Text (20) Primary key Name of code set CodeGroup Text (5) First ICD-10 code included in the group CodeGroup Text (5) Second ICD-10 code included in the group CodeGroup Text (5) Third ICD-10 code included in the group... CodeGroup Final ICD-10 code included in the group DateFrom Date - dd/mm/aaaa Record valid from DateTo Date - dd/mm/aaaa Record valid to Comment Text (100) Free text Name is the name of the set of codes. For instance, "MPrTumour" could refer to Malignant tumours specified as primary. CodeGroup is the definition of the group defined by the ICD codes included in the group. For instance, the expression "C000-C769, C800-C969" defines a group consisting of all primary malignant tumours. 7.6 Algorithm Each default code on the certificate is examined for possible modifications and linkages. Modifications not involving other ICD codes (in the ModificationNotByIcdCode table) are evaluated first. Of the modifications specified in the ModificationByIcdCode table, those requiring a causal relationship are tested first. This implies that, in part I, codes are examined bottom-up from the last line up to line a. If a code is modified, the 18/11/ :03:28 Report 26

27 process tests if a modification applies to the new code. The process is followed until there are no further modifications. However, errors in the modification tables might lead to an infinite loop. The easiest way to prevent this is to limit the number of modifications and to keep track of the records for debugging. Examples Case 1 Default codes Final codes I a) Stomach cancer C169 C169 b) Lung cancer C349 C780 c) d) II Lung cancer reported together with a malignant neoplasm that is not on the so called list of common sites of metastases (ICD-10, Volume 2, section 4.2.7) is to be considered as secondary. Since stomach cancer is not on the list of common sites of metastases, lung cancer is considered secondary and the code is C780. The following record from the ModificationByIcdCode table applies: Icd1 C349 OrderNum 1 Lnk1Icd1 MprTumor NewIcd1 C780 IcdCodeAction R There modification is valid whether the stomach cancer is mentioned as the cause of the lung cancer or not, so there is no restriction in the LnkRel fields. The labels MprTumour and Csm are defined in the CodeGroups table, please see the following example. The expression MprTumourNotCsm means "all malignant tumours except common sites of metastases": 18/11/ :03:28 Report 27

28 CodeGroups table: Name MprTumor OrderNum 1 CodeGroupExp C000-C759, C810-C969, C97 Case 2 Default codes Final codes I a) CVA I64 I64 b) Thrombosis I829 I829 c) Atherosclerotic heart disease I251 I251 d) II Thrombosis (I82.9) is modified by both cerebrovascular accident (I64) and atherosclerotic heart disease (I25.1), but only when it is reported alone with one of these conditions. However, if it is reported with both conditions the code I82.9 should not be modified, since in that case it is not clear whether thrombosis refers to the cerebral or the cardiac condition. The following records from the ModificationByIcdCode table show how this situation can be managed. The first record identifies the situation where the thrombosis is reported with both atherosclerotic heart disease and CVA. If that is the case the resulting code the result of the modification is I829, which means that no modification is carried out. Further, the LnkAction is set to C (Completed), which means that no further code modifications are to be carried out for I /11/ :03:28 Report 28

29 ModificationByIcdCode table: Icd1 I829 OrderNum 1 Lnk1Icd1 I251 Lnk1Rel DueTo Lnk2Icd1 I64 Lnk2Rel Cause of NewIcd1 I829 LnkAction C Icd1 I829 OrderNum 2 Lnk1Icd1 I251 Lnk1Rel DueTo NewIcd1 I240 Icd1 I829 OrderNum 3 Lnk1Icd1 I64 Lnk1Rel CauseOf NewIcd1 I633 IcdCodeAction R Case 3 Default codes Final codes I a) Pulmonary embolism I269 T817 b) Open heart surgery ZZ1 Y839, I519 c) d) II There are several coding problems here: 1) There is no specific code in the ICD-10 for open heart surgery (the code tentative code ZZ1 is a dummy code assigned by Iris); 2) the pulmonary embolism is a complication of the surgery and the code I269 should change into T817; 3) open heart surgery with complications should be coded to Y839; and 4) according to ICD-10 (Volume 2, 4.2.6), a code for the disease that necessitated the surgery should be added. This disease will also be the underlying cause. The following records in the ModificationByIcdCode table achieve the correct result. First, the dummy code ZZ1 is converted into Y839 I519 since ZZ1 is 18/11/ :03:28 Report 29

30 mentioned on the lowest used line in Part 1. Second, the code I26.9 for pulmonary embolism is replaced by T81.7, vascular complications following a procedure. ModificationByIcdCode table: Icd1 ZZ1 OrderNum 1 IcdCodePos LowestUsedLine NewIcd1 Y839 NewIcd2 I519 Icd1 I269 OrderNum 1 Lnk1ICd1 Y830-Y849 Lnk1Rel DueTo NewIcd1 T817 Further, according to the suggested algorithm for coding of medical procedures, the term should be flagged as reason for surgery, please see the Surgery and procedures section. Case 4 Default codes Final codes I a) Gangrene, Diabetes R02, E149 I702, E149 b) Atherosclerosis I709 I709 c) d) II Both atherosclerosis and diabetes can modify the ICD code for gangrene. In this case gangrene is actually reported as due to atherosclerosis and not as due to diabetes. Therefore, the resulting code should be I70.2, atherosclerotic gangrene, and not E14.5, diabetic gangrene. Of the ModificationByIcdCode table records below, the first links atherosclerosis and gangrene with a resulting code of I70.2, atherosclerotic gangrene. The second record prevents diabetes from modifying gangrene in the presence of I /11/ :03:28 Report 30

31 ModificationByIcdCode table: Icd1 R02 OrderNum 1 Lnk1Icd1 I709 Lnk1Rel DueTo NewIcd1 I702 IcdCodeAction Y Icd1 R02 OrderNum 1 Lnk1Icd1 E149 Lnk1Rel MentionLine Lnk2Icd1 I709 Lnk2Rel DueTo NewIcd1 I702 LnkAction G Case 5 Default codes Final codes I a) Heart failure 2 weeks I509 I978 II Surgery for fracture of femur 3 weeks Z924, S729 Y839, S729 The default code for heart failure is I50.9. However, if surgery was performed before the heart failure occurred, and there were less than four weeks between the surgery and the death, then the heart failure should be considered a complication of surgery and coded to I97.8. This is expressed in the following ModificationByIcdCode table record. The time condition specified is the time elapsed between the ICD code I50.9 and the default code for surgery, Z92.4. Since the time elapsed is less than four weeks and the default code for heart failure (I50.9) is on the lowest used line in Part 1, I50.9 is replaced by I97.8, other postprocedural disorders of circulatory system. In the next step the default code for surgery, Z924, is replaced by Y839, since there is now an ICD code for complication of surgery on the record. 18/11/ :03:28 Report 31

32 ModificationByIcdCode table: Icd1 I509 OrderNum IcdCodePos LowestUsedLine Lnk1Icd1 Z924, Y830-Y849 Time 0-4W NewIcd1 I978 Icd1 Lnk1Icd1 NewIcd1 Z924 I978 Y839 Case 6 Default codes Final codes I a) Abdominal carcinosis C762 C798 b) Pancreatic tumour D377 C259 c) d) II The pancreatic tumour is not specified as malignant or benign and the default code is D37.7. Abdominal carcinosis is not specified as primary or secondary, and the default code is coded C76.2. However, since the pancreatic tumour is the cause of the abdominal carcinosis, the pancreatic tumour is malignant. The algorithm first checks if any modification in the ModificationByIcdCode table applies to D37.7, which is on the bottom line. It finds and applies the record by which D37.7 reported as the cause of C76.2 modifies D37.7 into C25.9. Next, the algorithm evaluates possible modifications for C76.2. The second table record below shows that C76.2 reported with C25.9 should be modified into C79.8, secondary malignant neoplasm. 18/11/ :03:28 Report 32

33 ModificationByIcdCode table: Icd1 D377 OrderNum 1 Lnk1Icd1 C762 Lnk1Rel DueTo NewIcd1 C259 IcdCodeAction Y Icd1 C762 OrderNum 1 Lnk1Icd1 C259 NewIcd1 C798 IcdCodeAction Y Note 1: The modification table records shown above are intended as illustrations only. In the actual tables the specifications would in all probability cover far wider ranges of ICD codes. Note 2: Developing modifications tables will take considerable time, and initially some modifications will either not get performed, because the appropriate record is still missing in the modification tables, or the modification might give the wrong result, because the modification table entry needs further refinement. Therefore, the Iris interface will provide a pop-up window which gives the code the opportunity to change multiple cause code modifications. 7.7 Processing of surgery and other medical procedures in Iris a special case Handling mentions of surgery and other medical procedures in an automated coding system offers some specific challenges, since the system has to 1) recognize certain expressions as possible complications of surgery or procedures, 2) flag them for continued processing, and 3) apply specific instructions for the selection of the underlying cause to these cases Recognize complications A coding system has to deal with two types of complications of surgery and other procedures: Type 1: Expressions clearly stating that the condition developed as a consequence of surgery or another medical procedure, for example 18/11/ :03:28 Report 33

34 postoperative renal failure, postsurgical wound infection. In the dictionary, such terms will have codes in the ICD categories for complications of medical procedures (E89, G97, H59, I97, J95, K91, M96, N99, T80-T88), and therefore Type 1 complications are easy to recognize. Type 2: General complications developing after surgery or another medical procedure. General complications are conditions that may develop as a consequence of surgery and medical procedures, but also of serious diseases and injuries, or in some cases without an obvious cause. Typical examples are heart failure, pulmonary embolism, urinary tract infection and pneumonia. The MRG has prepared a list of such general complications which is now incorporated in Volume 2 (section 7.2). Type 2 complications are more difficult to recognize, since they count as postprocedural complications only when they occur in a certain relationship to a recently performed operation or other medical procedure. The Swedish Mikado system uses the following algorithm: Recode a Type 2 complication to a code in E89, G97, H59, I97, J95, K91, M96, N99, T80-T88 if: - Reported first on the lowest line in Part 1, AND - There was surgery within four weeks before death, AND - The date of the surgery (if stated) is not later than the date of the complication (if stated), AND - The surgery is reported o further to the right on the lowest used line in Part 1, OR o in Part 2, OR o in the box for reason for surgery (corresponding to the Ident.ReasonSurgery field in Iris) 18/11/ :03:28 Report 34

35 A similar algorithm could be used in Iris. The recode could be specified in one of the modification tables, as described in the outline of the new multiple cause coding module Flag conditions as cause of surgery/procedure Once Iris has recognized the complications of surgery, it needs to find the reason why the surgery or procedure was performed. Once the reason has been found, a flag must be set that identifies the corresponding term and ICD code as the reason why surgery was performed. This flag corresponds to the & flag in ACME and would have a similar function. The following outline describes how this flag could be set. Add a field (A1) for SurgeryFlag to the MedCod database. Set SurgeryFlag to 1 if a) the text string contains a term indicating surgery or another medical procedure ( operated, surgery for, laparatomy, etc); or b) the text string is from the Ident.ReasonSurgery field. Text strings in the Ident.ReasonSurgery field are derived from the death certificate box where the certifier is supposed to state whether the deceased had surgery within the last four weeks before death, and if so the condition that induce the surgery. Iris should code text strings from this box automatically, and the ICD code(s) for the condition mentioned in the Ident.ReasonSurgery box should be placed last in Part 2. Text strings indicating surgery can be placed in a separate table, MedicalProcedures. In the line processing, such strings should be removed from the text string once both the surgery string and the string describing the medical condition have been recognized and coded (the surgery string with a flag in the CauseOfSurgery field and the medical condition with an ICD code). It is important that both the surgery expression and the condition expression have been recognized, since the surgery flag may end up connected to the wrong medical condition if the surgery flag is assigned before all parts of the text have been recognized, especially if the non-recognized part contains a phrase separator. 18/11/ :03:28 Report 35

36 The MedicalProcedures table should also provide ICD codes for the text strings indicating surgery. Note that codes in the range Y83-Y84 may be subject to modification, for example if the surgery was performed a long time ago, or if the complication was caused by a misadventure Processing Selecting the underlying cause When selecting the underlying cause, Iris should consider both Type 1 and Type 2 complications an obvious consequence of the first mentioned condition flagged as cause of surgery/procedure. Iris should make this link to the medical condition itself and not to the procedure code, as is now done in ACME. Once the medical condition causing the procedure has been found, Iris should apply further linkages from this condition in the usual way. If more than one term has been flagged as reason for surgery, Iris should reject the record for manual review even if an underlying cause has been assigned. Note: Initially, initially it might be convenient to code all complications to T889 and all procedures to Y839. Fully developed modification tables for complications of surgery and procedures will take long time to produce, since ICD coding of medical complications is rather intricate. However, if initially all Type 2 complications are recoded to T889 and all procedures are coded to Y839, the steps outlined above could be tested even if the modification tables are not fully developed. 18/11/ :03:28 Report 36

37 8. Task 7: Workshop for implementation of Iris for interested Member States 8.1 Aims and participants As stipulated in the grant agreement, the Iris Group arranged an Iris workshop. The workshop, which was hosted by Destatis (Germany) took place in Bonn on Monday 31 January - Friday 4 February, In addition to the members Iris Group (representing France, Germany, Hungary and Sweden), 25 participants from 17 EU and ESS countries were present. The countries represented were Belgium, Croatia, Cyprus, Czech Republic, England/Wales, Estonia, Italy, Lithuania, Luxembourg, Malta, Netherland, Norway, Poland, Portugal, Slovenia, Spain and Switzerland. This workshop focused on practical exercises in setting up and using Iris. The agenda covered Technical issues: - System overview - Installation and set up - Iris Manual - Setting Iris options - Databases: Paths and settings - Creating a new certificate data base - Preparing work lots - Passwords - Basic features of the Iris software Dictionary and language standardisation development: - Collecting dictionary terms - Using the dictionary tool - Generating a dictionary with standardized terms - Editing dictionary entries 18/11/ :03:28 Report 37

38 - Language standardisation in Iris: The main steps of the algorithm - Standardisation tables: What to put where - Building and testing Regular Expressions - Editing Regular Expressions Practical aspects of coding death certificates with Iris: - Updating the MMDS - Coding a work lot: - Batch processing - Reviewing rejected records - Interpreting the Explain messages - Adding terms from the work lot to the dictionary - Editing and correcting Regular Expressions - Reporting errors There was also room for general questions and discussions. Participants were encouraged to bring their own laptop, and we in the Iris Group helped them to install the most current version of both Iris and MMDS. All participants were given an installation CD with the most recent version of Iris and MMDS, including the updated decision tables for ACME that the Iris Group had produced towards the end of ***Originally, it was planned to include a session on national adaptations on Iris, referred to in the project plan as Basic and advanced possibilities of Iris adaptation. However, for the reasons explained in Section 4, Task 3, the Core Group had by now been convinced that making the international version as inclusive as possible, and thereby decreasing the need for special national adaptations, would be a better way to improve international comparability. It was decided, therefore, to delete this item from the agenda. Instead, the developers showed participants how to work with the interface translation file (the properties file), how to translate the Iris screens and messages into other languages, and how national requirements on, for example, data display and final validity checks, can be handled in the international version.*** 18/11/ :03:28 Report 38

39 8.2 Feedback and suggestions Feedback from the participants was very encouraging. Eight countries (Czech Republic, France, Germany, Luxembourg, Norway, Spain, Sweden, Switzerland) have already implemented Iris or plan to do so in Belgium will implement in Participants from several other countries (Cyprus, Netherlands, Slovenia, Italy, Poland, Croatia, Lithuania, Estonia, Malta) expressed their intention to recommend the introduction of Iris, at least once an electronic death certificate has been introduced. For England, however, the situation is less clear, since the Iris policy to update the software according to the time schedule for official WHO updates to the ICD causes some concern. Several countries were concerned that there is no formal structure guaranteeing the continued maintenance of Iris, and continued support to Iris users. Various models for maintenance, development and support were discussed, but no conclusions could be made. For the near future, participants asked for continued support when implementing Iris, especially reviews of best practice for implementation and advice on dictionary maintenance and how to develop Regular Expressions for the language standardisation process. The exercises in coding and Regular Exercises resulted in some very useful suggestions for improvements to the Iris interface and to Iris functions. These included further options for selecting death certificates for review, improvements to the export and import functions, better handling of scanned images of death certificates, further hotkeys for commonly used functions, improvements to the dictionary and standardisation tools, further options for data entry, and improved support for code validity checks. The workshop gave a unique opportunity to test Iris V4 on a wider group of users than had been possible so far. We did identify some ambiguous terms in the Iris interface and also discovered some minor bugs, which have now been taken care of. 18/11/ :03:28 Report 39

40 9. Task 8: Improvement of manuals for dictionary development and language standardisation Successful coding requires a good dictionary and efficient language standardisation procedures. Dictionary development and standardisation has also been a recurrent theme both in the various meetings with Iris users that the Iris Group has arranged, and in the numerous questions members of the group have received. Therefore, the Iris Group included a substantial section on language standardisation in the Iris manual (Section 7, Standardisation in Iris). An Iris manual on Regular Expressions has been available since We also developed a separate manual on development and maintenance of the dictionary. The dictionary manual includes instructions on both technical issues and issues related to the contents of the dictionary. There are sections on which tables that should be developed and maintained by the user, on dictionary development in general, and on specific dictionary issues such as the advantage of including single terms rather than compound terms, which ICD version to use, alternative ICD codes, created and connected codes, injuries and external causes, and how to use coding flags. These subjects cover most questions that newcomers to Iris might have on how to build and maintain a dictionary. All these manual are available for download on the Iris web site at: 18/11/ :03:28 Report 40

41 10. Annexes Annex 1 - MMDS - Iris Meeting agenda Room 2016 NCHS/RTP Research Triangle Park, NC February 10, :30 am 2:00 pm Chair: Sam Notzon 1. Re-engineering the MMDS: Aims and schedule Possibilities to coordinate the re-engineering of MMDS with Iris? For ICD-10 or ICD-11? 2. Presentation of the Iris project Demonstration of the current version of Iris The project s organization: Participating countries, core group, users group, Eurostat funding General aims of the Iris project Planned developments: Short term, medium term 3. Cooperation RTP-Iris core group: Possibilities and difficulties Pooling of resources (financial, medical knowledge, nosologists) Decision table maintenance as an international responsibility Resources required for future maintenance of the decision tables Links to the MRG and the WHO: The decision tables as international standard for selection and classification of underlying cause Replacing ERNs with ICD codes: Technically possible? Additional information required? Replacing Transax with full ICD code modification at the Micar stage? Further suggestions for changes to the MMDS MMDS documentation and metadata: Ownership and use of NCHS-produced material Future organization of the Iris project 4. RTP-Iris collaboration agreement Specific areas of Iris/RTP collaboration Iris access to MMDS source code Guidelines for Iris team access to RTP staff Future visits of Iris team to RTP. 18/11/ :03:28 Report 41

42 Annex 2 Iris Overview presentation 18/11/ :03:28 Report 42

43 18/11/ :03:28 Report 43

44 18/11/ :03:28 Report 44

45 18/11/ :03:28 Report 45

46 18/11/ :03:28 Report 46

47 18/11/ :03:28 Report 47

48 18/11/ :03:28 Report 48

49 18/11/ :03:28 Report 49

50 18/11/ :03:28 Report 50

51 Annex 3 MMDS-Iris Meeting minutes Raleigh, NC, February 10th 2010 Participants: Donna Glenn, Tyringa Crawford, Holly Lambert, Steve Rushing, Chuck Sirc (all NCHS/RTP), Sam Notzon, Charlie Rothwell (both NCHS/Washington, via phone due to weather conditions), Gerard Pavillon (Inserm, France), Lars Age Johansson (Socialstyrelsen, Sweden), Laszlo Pelikan (National Statistical Office, Hungary), Torsten Schelhase, Björn Witting (both Federal Statistical Office, Germany), Olivia Peikert, Stefanie Weber (both DIMDI, Germany) Aim of the meeting: To evaluate closer collaboration between the MMDS-team and the Iris Core group in order to share the available resources. As the weather conditions did not allow for Sam and Charlie to travel, the meeting was held as a telephone conference. Charlie Rothwell participated for the first hour, Sam Notzon for the full morning and then for an update of the afternoon discussions at the end of the meeting. After introductions of all participants Charlie explained NCHS status and plans for Vital statistics in a broad outline. A lot of big software projects are ongoing at NCHS these days as the needs of modern infrastructure for Vital statistics require these changes. Many of these changes will enable NCHS to have timely data available for surveillance purposes. MMDS itself has not been updated software wise and this project will have to be tackled over the next few years. As well changes to the ICD coming from the WHO Update cycle could not always be included in a timely way. Some of them are still outstanding and NCHS is not sure on how much of these changes can be implemented in the coming year due to the huge amount of resources this would require. The software changes as well include switching the system to a web application in order to have the data available in a short period of time and possibly to insource the reject coding from the states to NCHS in order to achieve more consistent coding of the data. For the long-term plans NCHS is facing the question of the transition from ICD-10 to ICD-11. This will require reasonable resources. Maybe this change can be handled as an international collaboration. Gerard Pavillon then introduced the work of the Iris group. Iris is used by many countries for testing purpose already. These countries meet regularly as a user group to exchange information and to be updated to the changes of the software. The Iris-software itself was developed as an international project by the members of the Iris core group (all present at this meeting), which do as well have full access to the sources of Iris and do decide on future changes to the software on the basis of MRG decisions, requests of the user group and experiences gathered by the use of Iris. A set of slides was distributed prior to the meeting of which the highlights were pointed out. The main objective of the Iris project is to have international agreed standards in mortality coding to increase the quality of the data. The shared approach was selected to share the burden of resources required. The software is language independent and only the burden of the development of a dictionary has to be undertaken by each country separately. The Iris Core Group works in close collaboration with WHO and the MRG. Recently the Iris Core group received a larger grand by EUROSTAT (the statistical agency of Europe) in order to make Iris more stable and independent and to promote the implantation of Iris. Stefanie Weber was asked by WHO to deliver a request for the revision process of the ICD. WHO is evaluating the idea of including a decision table like structure into the ICD-11 to 18/11/ :03:28 Report 51

52 enable internationally standardised mortality data coding. Therefore WHO would like to request NCHS if it would be possible to share the decision table content with WHO to be fed into the revision process. Charlie stated that this would not be a problem for NCHS as long as the implementation of all the updates doesn t have to be finalised before that. Action Item: Stefanie will give initial reply to WHO and ask for an official letter requesting the decision tables from NCHS for inclusion in the revision process of ICD. Chuck followed up on the topic of updates by posing the question of the possibility of shared workload for the updates of ICD-10. The Iris group showed great interest in this option and offered to participate in the updates of ICD-10 for As long as the international approach will not change the throughput of the MMDS system it was decided to go ahead and try to share the workload of the updates. The relevant software (for checking the changes) needs to be provided by NCHS as well as some training on how to technically handle the updates in a timely way so that this work can start right away. It was as well agreed that the final coordination will rest in the hands of NCHS for the time being as NCHS holds the greatest expertise on this matter and knows of all the possible pitfalls of the changes. Some of the changes will be implemented by NCHS anyways and are already underway. The other changes, that NCHS has given lower priority, can be implemented by the Iris group. NCHS can decide if the changes from the Iris group will be used in the US as well. If not, the possibility of having an international MMDS (with all update) and a US MMDS (with only the updates accepted by NCHS) can be evaluated. Action item: NCHS to share all needed tools to update decision tables (including modification tables) and provide some instructions on how to use this. Iris group evaluate how much time is needed for the changes and who in the Iris group will work on this. Charlie stated that NCHS will do whatever they can to support the activities of the Iris Core group. Stefanie explained the structure of the Iris Core Group and that the members of the Iris Core Group are having full access to the source code of Iris. Members of the users group will only get a compiled version of Iris. Countries that have membership in the Core Group are at present Sweden, France, Hungary and Germany. Italy is evaluating membership as well. Membership duties will include having an expert present at most of the Iris Core group meeting (twice a year) and taking up some responsibility on the further development of Iris. The Iris Core Group would like to invite the US to become a member of the Core Group as well. Sharing of the expertise of the MMDS development would be very valuable input for further development of Iris. Charlie answered with a possible yes. There needs to be further discussion within the NCHS before this can be decided officially but NCHS would be very interested in becoming a member of the Core Group. For the upcoming Iris meeting in Bonn Bob Anderson, Donna Hoyert and Sam will be representing NCHS. As well the Iris Core Group will try to pay regular visits to the NCHS in order to further facilitate discussions and interaction between the two groups Action item: NCHS to evaluate if permanent membership of NCHS in the Iris group will be possible. Iris Core Group try to facilitate further visits to NCHS Raleigh. The Iris system and its use of standardisation and dictionary were explained. Depending on the existence of a fairly good dictionary and a not too complicated language the resources of developing these parts for Iris can be estimated. Stefanie explained that for the NCHS use of Iris the existing dictionary for the MMDS system can be used and further refined. The standardisation will not be too complicated as the language English is not using much word compositions and flexions. An estimation of time needed for the development of sufficient dictionary and standardisation tables for NCHS would be 2-6 person-months. 18/11/ :03:28 Report 52

53 One of the key problems of the interaction of the two systems is the use of the ERNs. With every update of the dictionary of MMDS funny coding results can be obtained with Iris if ERNs have been changed without consideration of the necessary consecutive changes in the Iris system. As well, problems of the MMDS system will be a problem of Iris as well (eg. external causes and procedures) as the MICAR and ACME module of the MMDS system are used within the Iris system. Afternoon discussions started with further explanations on the reengineering of the MMDS suite provided by Chuck. The timeline of the whole project is two years. It will include reengineering of Super-MICAR, MICAR and ACME. One of the aims for NCHS is to develop a web-based coding environment to enable insourcing of the Reject-coding as mentioned above. The basis of the reengineering will be.net -tools with C# to be used as programming language. (Iris is based on.net and C# as well which could enable reuse of the sources for the two systems) A key goal is to have data for surveillance ready at hand within a short period of time, ideally within 24h. Gerard explained that the system, that is about to be moved from testing environment into real-time application in France, uses online certification as well. The data will be fed into Iris directly and could be coded after as few as ten minutes. The reengineering will start with the Super-MICAR part where software specifications are well underway and programming will begin somewhere this year. Afterwards the Software specifications for MICAR and ACME will follow. It was discussed to share the load of this reengineering. The Iris group offered to write the specifications for the MICAR part and, if both groups agree on the specifications, can even undertake some of the programming itself. This was well received by NCHS and necessary preparations outlined. The documentation of the MICAR-now-in-use needs to be given to the Iris group along with the source code of the program. The Iris Core group will then analyse the features and compare them to the other existing software in use (Swedish system, Hungarian system, etc.). As well tests need to be performed on large amounts of data to see which changes are really implemented in the existing MICAR. Action Item: All documentation on MICAR development and the Sources of MICAR need to be handed to the Iris Core Group. Sufficient amounts of test data of Super-MICAR output data (preferably one data year), arranged in lots of about certificates, will be given to the Iris Core Group for testing. The Iris Core Group will analyse the documentation and sources as well as the test results and write the MICAR specifications in draft version for further discussions. In order to test the possibility to eliminate the use of ERNs the test will be performed with ICD-10 codes as well as with ERN-codes. Wherever the test will reveal the need for further detail beyond the existing granularity of ICD-10 the results will be fed into the ICD-11 revision process to enable the possibility to use only existing ICD codes for the Iris and MMDS system in the future. Otherwise the possibility of created codes will be considered as well. Some members of the Iris Core group have tried to write a paper on the Formalisation of the Rules of Volume two of ICD-10 and the content model needed to enable maintenance of the decision tables in ICD-11. (The paper was further discussed on Friday, the latest version is attached to these minutes). As the exchange of large amounts of data is hard or impossible via the Iris group will look into the possibility to set up a restricted ftp-site for the Iris Core group and NCHS to access and exchange data. Action Item: Gerard to evaluate possibility of restricted ftp site at Inserm. If not possible, Stefanie to evaluate at DIMDI. 18/11/ :03:28 Report 53

54 NCHS as well has to print the ICD-10 to come with the MMDS system for the users. This is a huge burden for NCHS. Stefanie offered RTP the use of the CTK (Classification Tool Kit) developed by DIMDI for the use of printing the ICD-10 Volume 1 in different formats (HTML, pdf, ascii, etc.). The needed source data in ClaML format can be provided by WHO. Action Item: Stefanie to hand test copies of CTK to NCHS stuff (accomplished by giving a copy to Donna, Steve and Chuck along with documentation and a test chapter of ICD-10 in ClaML). NCHS to test CTK use for NCHS needs. Further cooperation on CTK is possible and can be followed up in later discussions. In order to keep discussions at a recent status and to be able to inform each other on a regular basis the possibility of fixed telephone conferences was discussed. It was agreed to investigate if a phone conference of the participants of today s meeting could be set up at a regular basis, eg. every other or every month. Action Item: Evaluate the possibility of regular phone conferences. The Iris Core Group thanked NCHS for the possibility of having such an open and fruitful discussion. The value of close collaboration is very high for the Iris Core Group and a continuation of the collaboration is seen as essential to the Iris Core Group. The meeting closed and was followed by two more days of technical discussions by a reduced number of participants. Results of discussions of the rest of the week: Discussions on update priorities: The Priority list for the updates to be implemented in the 2011 version was discussed. All neoplasms have been put on priority 2 due to the amount of work involved in the updates and in the retraining of the coders. To the Iris group the implementation of the leukaemia updates is very important as this an area of great interest for epidemiologists. In the cancer registries there will be inconsistencies between the morbidity and mortality data if these updates will not be implemented. It was discussed that the Iris group will do the updates to the decision table (causal tables) for this more or less independent section of the decision tables. These changes can then be compiled to be used as an international version of MMDS. The NCHS can decide if they would like to employ these changes as well or postpone the use until morbidity has been switched to ICD-10 as well. In order to estimate the amount of codes that are affected by these changes a crosswalk table was provided was provided by Stefanie. Software and Documentation that needs to be available to the IRIS Core Group in order to help MMDS-developers with the updates for 2011 and to develop the Software Specifications for MICAR reprogramming: MICAR Dictionary Browser (including Dictionary) ACME Table Updater (including most recent tables) Background program for ACME Table entries (including ACMEService and ACME_ErrorRpt program) ACME-Exporter program Hash-routines for the ACME Table PrintCausal program Documentation to above programs and tables MICAR and ACME Source code MICAR and ACME documentation Documentation for using all of the above programs 18/11/ :03:28 Report 54

55 Annex 4 QUESTIONS ABOUT IRIS A general remark: Both Micar and ACME are black boxes to us and we cannot change how they operate. We can (and do) forward errors to the US developers, however, and we also make suggestions for changes to them. 1. Why does IRIS ( Micar) convert the code A49.8- other bacterial infections of unspecified site- into the code A48.0 gas gangrene? 2. The code A49 with the digits is rejected by Micar 3. The code B49 causes problems in IRIS: Micar Reject :3 At present, Micar does not handle certain infectious and parasitic diseases, for example it does not decide whether an infectious organism should be coded as the cause of another condition or not. According to the ICD, pneumonia (pseudomonas) should go to J15.1, but to Micar this looks the same as pneumonia; pseudomonas also found which should go to J A49.8. Because of this ambiguity Micar rejects these records and they must be coded manually. 4. The code F13.0 Acute intoxication is rejected by Micar. Neither the code F13.0 nor the code I24.0 must be used as underlying cause, however the code F13.0 is not recognized by IRIS and the code I24.0 is converted by IRIS into the code I21.9 F13.0 works with the new Iris tables (2010 tables, will be published on the Iris website in March) and the MMDS I24.0 is converted to I21.9 since Volume 2 of the ICD-10 says that, for mortality, infarction should be assumed. We do this conversion in the multiple cause coding to avoid a contradiction in the output of multiple causes from Micar (otherwise the codes would say both no infarction and infarction on the same record). 5. The code I08.0 Disorders of both mitral and aortic valves is rejected by Micar. In Micar (and Iris) coding, codes for multiple valvular diseases cannot be used in the multiple cause coding. Instead, the components must be coded separately. Thus, disorder of mitral and aortic valve should be coded as I059, I359 in the multiple cause coding. 6. The code T Foreing body in respiratory tract causes problems in IRIS: Micar: 01 TENTATIVE ICD-10 CODES: U00 Micar rejects conditions related to aspiration and inhalation, because of difficulties in linking these conditions to other conditions on the certificate. Again, these records are rejected for manual coding. 7. IRIS converts automatically the code A419 into the code P36.9 when A419 is used for a younger than 7 days, by contrast IRIS doesn t do the same with the code A499 when it is used for a younger than 7 days. Instead of converting A499 into P369, the code A499 is rejected by Micar. Micar doesn t include code conversions for several conditions listed as congenital in the alphabetical index of ICD-10. A499 is one of them. We have pointed this out to the NCHS and hope it will be corrected in the future. 18/11/ :03:28 Report 55

56 8. One question about the malignant neoplasm of genital organ ( C63.9 for males and C57.9 for females) : in the option Code entry mode in order to check how IRIS treats the inconsistencies of sex, we have codified a woman with C63.9 and the code assigned by MMDS has been C51.9. We consider that MMDS should use as alternative code for C63.9 the code C57.9 due to the fact that it is its equivalent for females. We have introduced the code C63.9 ( it is a correct code for a man) but it appears an emergent window with the following text. Consistency Check. Code C51.9 cannot be used for males. If it is valid for man, it should be accepted, Shouldn t it? The substitution should go to C57.9, as you pointed out. We will change this is in the 2010 tables for Iris. There is a further problem: Iris substitutes all male codes into female codes because MMDS doesn t accept male codes in the multiple cause input. Instead, all codes dependent on the sex of deceased are entered as female codes. If the deceased is a man, Micar then changed the code to male. In Iris, the check for consistency between sex and code is now done before the Micar step, which is too early. We will correct this. 9. Double malignant neoplasm that have individual codes and other for contiguous site. For instance, malignant neoplasm of head of pancreas and malignant neoplasm of body of pancreas, on account of we don t know which of them was the origin, we should put in the dictionary Icd 1= C25.0, Icd 2= C25.1. The expected result given by ACME/IRIS is C25.8 ( overlapping lesion of pancreas), however ACME gives as a result C25.9 and we consider this result incorrect. In which cases should we put the code of overlapping lesion of pancreas Icd 1= C25.8? When developing the MMDS for ICD-10, the US decided not to use the.8 subcategories, mainly because most coders do not have anatomical knowledge enough to decide whether two sites are contiguous or not. Countries that want to use the.8 categories will have review records with several neoplasms in the same block and code them manually. 10. Does the field time interval interact with the selection of the underlying cause of death? In case of an affirmative answer, In which way does it interact? According to our test, it is an informative text field for the manual codifier that doesn t interact with the automatic codification. We are not sure about this statement and we might be using this field correctly. Could you give us further information about it? The time interval should influence the coding, but didn t always do so in previous versions of ACME because of a program logic problem. We are working on the problem and hope that it will be corrected in the next version of Iris. 18/11/ :03:28 Report 56

57 Annex 5 Bonn meeting agenda Agenda IRIS meeting Federal Statistical Office Germany Graurheindorfer Strasse Bonn, Germany Building 8, Room 144 March 3, :00 10:15 Welcome and Tour de Table 10:15 11:00 Outcome of meeting at RTP ICD major update 2010 in MMDS 2011 o Involvement of the Iris core group o Appropriation of decision tables and tools Further cooperation 11:00 11:30 Coffee 11:30 12:45 Reports from countries on Iris Status of implementation Test results Problems and questions Future plans 12:45 13:45 Lunch 13:45 15:00 Ongoing developments of Iris Eurostat grant Dictionary tool Update international interface Multiple cause coding only based on ICD codes Workshop 15:00 15:30 Coffee 15:30 16:15 Preparation for ICD-11 Mortality knowledge base 16:15 17:00 Future activities and any other business 19:00 Dinner 18/11/ :03:28 Report 57

58 Annex 6 NCHS meeting agenda RTP meeting on automated coding systems Tuesday 17 August - Friday 20 August Start on Tuesday 17 August at 9:30 1. ACME decision tables Table contents: - Review of tables submitted by Olivia and Lars Age (neoplasms, diabetes, infectious diseases, other) - Diabetes and infectious diseases tables: Outcome of Donna s test - Neoplasm tables: Outstanding issues - MRG decisions: Suggestions for corrections and revisions, new issues Planning and time schedule: - Release date for 2011 tables - Neoplasm updates implemented? - Next: Who will do what, and when? 2. MICAR functions and the Iris MCM (Multiple Cause Module) - Architecture and work flow of MICAR - MICAR decision tables: names, functions, updating (NB: Technical aspects on how to update the MICAR tables can be discussed at the end of the meeting) - Results of ACME direct test (what happens if we fully bypass MICAR?) - Multiple cause coding in the Hungarian and Swedish systems - ICD-based coding versus ERN-based coding - Future developments: Coordinating a future version of MICAR and the Iris MCM? 3. Policy and strategy issues - Project status and future organization of the Iris group (for the Iris group only) Eurostat project: Scenarios for Iris V4 Paper for Toronto 2010 tables for Iris Iris translation - Cooperation RTP-Iris: Next steps - Preliminary MMDS version available for testing? - Next Iris meeting (Stockholm, September) - Other issues on international implementation and support 18/11/ :03:28 Report 58

59 Annex 7 Stockholm meeting agenda Iris Core Group Meeting Location: Socialstyrelsen (National Board of Health and Welfare), Rålambsvägen 3, Sockholm Tuesday 14 September 13:00 17:00, meeting room 6214 Wednesday 15 September 9:30 17:00, meeting room Ugglan Welcome and tour de table - Participants activities new since the last Iris meeting Eurostat grant - Follow-up of work plan - Workshop Users group meeting - Plans for the meeting on Thursday 16 September Friday 17 September Iris development - ACME decision tables - MICAR equivalent - Translation tool - Manual - Test deck - Other Iris administration and organization - Future funding - Iris institute - Core group membership Future meetings 18/11/ :03:28 Report 59

60 Annex 8 Bonn workshop agenda Location: Room 138/144, Statistisches Bundesamt (Federal Statistical Office), Graurheindorfer Strasse 198, Bonn. Starting on Monday 31 January 2011 at 13:30 Ending on Friday 4 February 2011 at 12:30 Please note: The work shop will focus on practical exercises in setting up and using Iris. If possible, bring your own laptop! To install Iris, last-minute updates and other components that might be distributed at the work shop, you will need administrator s rights on your laptop. You will also need Microsoft Access 2003 or later, or another major data base manager. Welcome and tour de table Technical issues (Gérard Pavillon and László Pelikán) - System overview - Installation and set up - Iris Manual - Setting Iris options - Databases: Paths and settings - Creating a new certificate data base - Preparing work lots - Passwords - Basic features of the Iris software Dictionary and RegEx es (Stefanie Weber and Olivia Peikert) - Collecting dictionary terms - Using the dictionary tool - Generating a dictionary with standardized terms - Editing dictionary entries - Language standardization in Iris: The main steps of the algorithm - Standardization tables: What to put where - Building and testing Regular Expressions - Editing Regular Expressions 18/11/ :03:28 Report 60

61 Using Iris (Lars Age Johansson and Olivia Peikert) - Updating the MMDS - Coding a work lot: - Batch processing - Reviewing rejected records - Interpreting the Explain messages - Adding terms from the work lot to the dictionary - Editing RegEx es that didn t work - Reporting errors General questions 18/11/ :03:28 Report 61

62 Annex 9 Budapest meeting agenda April 6, 2011, Budapest starting April 6 th at 9am and extended to April 8 th at 12.15pm (Coffee breaks 10:30-10:50am, 3:15-3:35pm; Lunch 12:15-1:45pm) Welcome and Tour de Table Participant s activity on Iris Iris developments Work sharing Schedule Multiple Cause coding module Replacement module for ACME Iris RTP collaboration (Wednesday April 6 th, 3:00-4:30pm) Planned developments for MMDS Assessment of last year s cooperation Future collaboration Eurostat Presentation for TG Grant Experiences of countries from the workshop Administration and organization Iris funding Iris institute Iris for counties outside Europe Verbal autopsy Data entry module MMDS ACME decision tables Surgeries and traumatic cases ICD 11 Table maintenance Next meetings Paris 18/11/ :03:28 Report 62

63 Annex 10 Budapest meeting minutes Iris Core Group Meeting Lars Age Johansson and László Pelikán 6-8 April, 2011 Location: HCSO (Hungarian Central Statistical Office) Keleti Károly utca 5-7,1024 Budapest Participants: Mónika Bene (HCSO, Hungary), Olaf Eckert (DeStatis, Germany), Francesco Grippo (Istat, Italy), Lars Age Johansson (Socialstyrelsen, Sweden), Sam Notzon (NCHS, USA), Gérard Pavillon (Inserm, France), Olivia Peikert (DIMDI, Germany), László Pelikán (HCSO, Hungary) 1. Ongoing and planned Iris developments (For details please refer to separate document, IrisV4_Developments_ docx.) Schedule and work sharing The current version of Iris is sufficiently stable and could be made available when the Eurostat project ends (31 May 2011) with just some minor modifications. However, before we release it we should correct known bugs and fix the time interval issue. Further development will be shared between several programmers, so a version control system is necessary. László can start working on his items in early summer. Olaf will start by familiarizing himself with the source code. He will then get in touch with László and Gérard and they will decide together which items Olaf should work on. Multiple Cause coding module See item 3, Eurostat report, Task 6. Replacement module for ACME RTP is preparing a new version of ACME and it seems that this new version cannot be called by a line command. We can continue using the 2011 version of ACME for some time, but we should aim at replacing ACME with a UC selection module in Specifications are needed, and they can be built on the selection modules now used in Hungary and France. We need a substantial test deck for testing future changes to Iris. The test deck should contain records from as many of the Core Group countries as 18/11/ :03:28 Report 63

64 possible. See also item 3, Eurostat report Task 4, and item 6, ACME decision tables. 2. Iris RTP collaboration (Wednesday April 6 th, 2:00-3:30pm) Planned developments for MMDS SuperMicar and ACME will be replaced by web-based modules (developed in C# and with.net) this year. A new version of Micar200 will follow in The software will not be distributed to the states since all rejects will be handled at RTP. Source code will be distributed at request. The format of output and input files, and of ACME tables, will stay the same as now. Assessment of last year s cooperation The decision tables for 2011 were distributed very late, which didn t give us much time to test the new tables and evaluate the impact of the changes. However, now when SuperMicar has been replaced RTP will probably be able to send us Micar dictionary updates earlier this year. Currently there are no plans to change how Micar processes neoplasms. The Iris Group did some tests last year and we will send a summary of the results to Alaina. We will also send a list of ICD codes still missing in Micar to Alaina. She will add them and also tell us how to enter new codes into Micar. Future collaboration This year RTP will implement a protocol for assessing the feasibility of changes to the decision tables. The assessment will include clinical input, review by training team, data mining, what if -testing, assessment of the workload of ACME implementation and of workload of implementation in manuals, and an assessment of the statistical impact. The assessment will be logged. Test case: The MRG changes to embolism. 3. Eurostat Final report on the Eurostat-funded part of the Iris project The report is to be ready by 1 June. It will be a paper report with references to other sources, and it will also include a CD with all the referenced material. Task 1, Project management, achievement of endeavors of project Gérard will take care of this part. Task 2, Dissemination towards the ESSnet Gérard suggested putting the report on the Iris webpage together with the presentations and the manual. Also, the Iris manual should be made available on the website separately from installation of Iris, since installation requires administration rights. Task 3, The ability to translate the international interface of Iris An English property file for translation is included in the installation package. A description of how to use it is included in the manual, so there is no need for a further technical description in the report. The report should include a 18/11/ :03:28 Report 64

65 reference and a general description, however. Properties files in further languages should be published on the Iris web site, for example French, Swedish and Hungarian. We should also ask Magdalena Poppová for the Czech properties file. Task 4, Standardized test deck for quality, plausibility and validation checks for coding in IRIS We have got the data for a test deck, but the date of birth and date of death must be changed or anonymized before publication. We must keep the correct age, however, so if the date of death is set to the same day for all records in the test deck then the date of birth must be recalculated. The test deck should contain input codes and an underlying cause but no texts. There should be no information on the country of origin. Since corrected meta-tables are deliverables, the most up-to-date versions of the IcdErn, IcdSubstitution, ValidIcdCodes and NonConsistentIcdCodes tables should be made available from the Iris webpage. Lars Age will describe the test deck and the tables in the report. Note: Item 6, ACME decision tables, discusses a new test deck based on as recent records as possible. Task 5, Training deck for demonstration and training purposes The training deck developed for the Bonn workshop corresponds to this part of the Description of tasks and Deliverables. The total number of certificates should match the 500 records mentioned in the project plan. The training deck as well should be placed on the Iris website. Lars Age will write a short description to be included in the report. Task 6, Develop a module equivalent to the MICAR module of the MMDS The existing Swedish and Hungarian descriptions of the multiple code modification procedures (algorithm and technical implementation) could be merged. Lars Age and László agreed to combine the docs. Task 7, Workshop for implementation of IRIS for interested Member States We have the agenda of the workshop, a summary including participants assessment of the workshop (2-3 pages, Stefanie took notes), suggestions for improvements (included in the Developments document) and the presentations from Stefanie (Regex), Gérard (system architecture and Iris in general) and Lars Age (coding with Iris). Stefanie has collected the presentations and we will place them too on the website. Lars Age will write a short summary of reactions and suggestions for inclusions in the report. Task 8, Improvement of Manuals for dictionary development and language standardisation In the report we will refer to the standardisation part of the manual. We will also attach Stefanie s tutorial on Regular Expressions. Lars Age plans to produce a description of the connected codes and some other issues related to dictionary maintenance. Presentation at EUROSTAT TG 18/11/ :03:28 Report 65

66 Gérard undertook to hold the presentation. László said that he would perhaps attend the meeting. 4. Future administration and organization Iris funding and Iris institute On 24 February 2011 the Core Group sent a letter to Dr Dietrich Kaiser, director of the Iris institute, and asked him to investigate whether it would be possible to set up an Iris institute at DIMDI. We have now received a reply from DIMDI, and they will investigate the technical and legal issues. They estimate that resources corresponding to 140,000 over two years (70,000 a year) will be needed, probably this includes all Iris work. DIMDI will look for resources, but it is uncertain if DIMDI alone can cover all costs. Once the legal issues have been clarified, other countries in the Core Group will check if and how much they could contribute in the set-up phase. We could also get in touch with the people present at the Bonn workshop, since some of them offered to contribute to the costs of setting up an Iris institute. For the long-term funding of the institute we have to discuss which funding model to adopt. It is important that the model allows for long-term plans and maintenance. For a license fee model, we should again consider how much money the institute would need, how many countries that would be involved, which level(s) of service the institute should offer, for how long the license would last, etc. We might want to call the initial contribution initial license fee. We believe that Iris V4.1 will be well-functioning enough to warrant a license fee. 5. Iris for countries outside Europe, especially developing countries Data entry module Adding a data entry module would make Iris more attractive to countries setting up a vital registration system. It shouldn t be too difficult from the technical point of view, although some additional items might be needed and some checks. Which additional items would we need? Sam will keep us updated on the development of the registration tool he is involved in and we can borrow from it. Verbal autopsy We would need to connect Iris to a software that produces ICD codes from the replies to the questions. Iris would then process the codes according to the ICD rules. Verbal autopsy softwares use fields with free text entry, so it is important to arrive at a specific ICD code. There are different questionnaires depending on the age. We should use the WHO questionnaire. There are several softwares for verbal autopsy available already. Chris Murray has one, but that would probably be as a black box. We should also check with Debbie Bradshaw. 6. MMDS 18/11/ :03:28 Report 66

67 ACME decision tables As far as our resources permit, we will keep up with the WHO updates. Olivia, Francesco and Lars Age will edit the decision tables. It is important to test table update on a large set of actual death certificates. We should prepare a new test deck with as recent data as possible (2010, if possible, we can add more records as they become available). The RTP procedures for producing and checking new decision tables is very slow. For intermediate testing we could simply edit the squashed tables in the MMDS/Data folder. László will prepare a small Java application for the table team that unsquashes the tables (adds a line feed character) and then, after editing, squashes them again (removes the line feed character and adds a flag for the start of a new address code). It would be an advantage to have the tables in Excel, but plain text editing would work too. We could then run the full table editing procedure, including validity and consistency checks, once a year. Note that we will have to review the RTP house rules for table maintenance. The RTP software for editing and checking the decision tables is very slow. László will see if it could be made simpler and quicker. For example, maintenance would be easier if both addresses and subaddresses had individual records rather then code ranges. Surgeries and traumatic cases When we get to work on the multiple cause coding module we should consider if we would want to use the same basic approach as MMDS, or something different. For example, could we handle complications of surgery (according to the MRG list) simply as an extension to Rule 3? We need a substantial sample of death certificates mentioning surgery (including trauma with surgery) so that we can test various approaches. Francesco and Lars Age to work on specifications for surgery. Also ask Donna about alternatives to the processing in Micar. 7. Next meetings If we need to, we could have a meeting on the Eurostat report in early May, but let s try to manage without a face-to-face meeting ( and teleconferences should be sufficient). Next Core Group meeting will be in connection with the Users Group meeting in Oslo (in the week 5-9 September 2011, the exact dates to be decided later). Lars Age will check with Anne Gro Pedersen that there is a meeting room available, and with Donna Glenn that she could attend. 18/11/ :03:28 Report 67

68 Annex 11 Tech cod Iris presentation 18/11/ :03:28 Report 68

69 18/11/ :03:28 Report 69

70 18/11/ :03:28 Report 70

71 18/11/ :03:28 Report 71

72 18/11/ :03:28 Report 72

73 Annex A01 Invitation to the Bonn workshop*** 18/11/ :03:28 Report 73

74 Annex A02 Notes on planned developments of the software and on noted software problems*** Used as agenda for the Core Group meeting in Oslo, 5-6 September /11/ :03:28 Report 74

75 18/11/ :03:28 Report 75

76 18/11/ :03:28 Report 76

77 18/11/ :03:28 Report 77

78 18/11/ :03:28 Report 78

79 18/11/ :03:28 Report 79

80 18/11/ :03:28 Report 80

81 Annex A03 Agenda for the Users Group meeting in Oslo, 7-9 September 2011*** 18/11/ :03:28 Report 81

82 Annex A04 Participants in the Users Group meeting*** 18/11/ :03:28 Report 82

83 Annex A05 Notes on planned developments, revised according to requests and decisions made at the meetings in Oslo 5-7 September 2011*** 18/11/ :03:28 Report 83

84 18/11/ :03:28 Report 84

85 18/11/ :03:28 Report 85

86 18/11/ :03:28 Report 86

87 18/11/ :03:28 Report 87

88 18/11/ :03:28 Report 88

89 18/11/ :03:28 Report 89

90 18/11/ :03:28 Report 90

91 18/11/ :03:28 Report 91

92 Annex A06 Presentation at the Users Group meeting in Oslo of planned developments*** 18/11/ :03:28 Report 92

93 18/11/ :03:28 Report 93

94 18/11/ :03:28 Report 94

95 18/11/ :03:28 Report 95

96 18/11/ :03:28 Report 96

97 Annex A07 Presentation of the updated Iris interface*** 18/11/ :03:28 Report 97

98 18/11/ :03:28 Report 98

99 18/11/ :03:28 Report 99

100 18/11/ :03:28 Report 100

101 18/11/ :03:28 Report 101

102 18/11/ :03:28 Report 102

103 18/11/ :03:28 Report 103

104 18/11/ :03:28 Report 104

105 18/11/ :03:28 Report 105

106 18/11/ :03:28 Report 106

107 18/11/ :03:28 Report 107

108 Annex A08 Presentation of technical principles for multiple cause coding in Iris*** 18/11/ :03:28 Report 108

109 18/11/ :03:28 Report 109

110 18/11/ :03:28 Report 110

111 18/11/ :03:28 Report 111

112 18/11/ :03:28 Report 112

113 18/11/ :03:28 Report 113

114 18/11/ :03:28 Report 114

115 18/11/ :03:28 Report 115

116 Annex A09 Presentation of technical principles for coding of adverse reactions to medical procedures in Iris*** 18/11/ :03:28 Report 116

117 18/11/ :03:28 Report 117

118 18/11/ :03:28 Report 118

119 18/11/ :03:28 Report 119

120 Annex A10 Presentation of current status (implementation as per 2 November 2011)*** 18/11/ :03:28 Report 120

121 18/11/ :03:28 Report 121

122 18/11/ :03:28 Report 122

123 18/11/ :03:28 Report 123

124 18/11/ :03:28 Report 124

125 18/11/ :03:28 Report 125

126 18/11/ :03:28 Report 126

127 18/11/ :03:28 Report 127

128 18/11/ :03:28 Report 128

129 18/11/ :03:28 Report 129

130 18/11/ :03:28 Report 130

131 18/11/ :03:28 Report 131