SEARCHING SNOMED CT FOR CODING INFORMATION IN ELECTRONIC HEALTH RECORDS FOR STROKE PATIENTS. - Final report for NICTIZ and CAP-

SEARCHING SNOMED CT FOR CODING INFORMATION IN ELECTRONIC HEALTH RECORDS FOR STROKE PATIENTS - Final report for NICTIZ and CAP- Judith van der Kooij, Anneke T.M. Goossen-Baremans and William T.F. Goossen Acquest, Koudekerk aan den Rijn, October 2006 postadres: Postbus 262, 2260 AG Leidschendam bezoekadres: Overgoo 11, 2266 JZ Leidschendam telefoon: (070) 317 34 50; fax: (070) 320 74 37; e-mail: info@nictiz.nl www.nictiz.nl

Nothing from this report can be duplicated, recorded in an automated data file, or made public in any form or in any way, either electronic, mechanic, by copies or recording or in any other way without preceding written consent of the owner of this report, being Acquest in Koudekerk aan den Rijn, the Netherlands, and NICTIZ, the client for this report. 2

PREFACE Under the authority of NICTIZ, the abbreviation of the Dutch name for the National IT Institute for Healthcare, a study has been conducted with the main goal to determine the usefulness of a broad introduction of a clinical terminology in The Netherlands. To make information technology work in health care one needs to accept standardisation of the data, as well as the vocabulary and the electronic messages, next to security of medical information. In the Netherlands, NICTIZ takes responsibility for this. In this study, the following persons participated Acquest: Lisanne van Beek William T.F. Goossen Anneke T.M. Goossen-Baremans Marinka de Jong-Fintelman Judith van der Kooij Nelleke Plaisier Portavita: Evert-Jan Hoijtink 3

SUMMARY For a project on development of an Electronic Health Record (EHR) for stroke patients, medical information was organised in care information models (templates). All (medical) concepts in these care information models need a unique code to make electronic information exchange between different EHR systems possible, with use of HL7 v3 messages. When no unique code could be found in an existing coding system, a code was made up. In the study presented in this article we describe our search for unique codes in SNOMED CT to replace the self made codes. This to enhance interoperability by using standardized codes. We wanted to know for how many of the (self made) codes we could find a SNOMED CT code. Next to that we were interested in a possible difference between care information models with individual concepts and concepts being part of (scientific) scales, i.e., aggregate concepts. Results of this study show that we could find a SNOMED CT code for 45,5% of the concepts. When we look at the concepts with a self made code, 43% of these codes could be replaced with a SNOMED CT code against 69,6% of codes coming from an existing coding system, like ICD10 or ICF. A difference could be detected between care information models with individual concepts and care information models that represent a scientific scale or measurement instrument. For 55% of the individual concepts a SNOMED CT could be found. However, for the scientific scales only 16% of the concepts could get a SNOMED CT code. However, we applied very strict limitations on acceptance of codes. Although the percentage of SNOMED CT codes found is somewhat lower than expected (roughly half was estimated), we still think SNOMED CT could be a useful coding system for the concepts necessary for the continuity of care for stroke patients, and the inclusion in Electronic Health Records. Partly this is due to the fact that SNOMED CT has the option to request unique codes for new concepts, and is currently working on scale representation. 4

Content Introduction 6 Literature study 8 Method 10 Results 12 Conclusion and discussion 15 Recommendations 17 References 19 Appendix 1: care information model barthel index 22 5

Introduction Health care is a domain for which information plays an important role. This goes not only for registration and billing, but even more for the direct care for patients. Especially for the documentation of patient records there is no univocal universal language. At this moment classifications that are meant for classifying diseases or treatments are used for various purposes, both administrative and clinical. Most of the time, these classifications are not developed for the registration of direct care for patients, but more for statistics and billing. For that reason, those classifications are not always suitable for the electronic registration of daily care observations and activities. Under the authority of NICTIZ, the abbreviation of the Dutch name for the National IT Institute for Healthcare, a study [1] has been conducted with the main goal to determine the usefulness of a broad introduction of a clinical terminology in The Netherlands. In the report of this study a clinical terminology has been described as: the collection of standard terms with their synonyms, which can be used in direct patient care to record all symptoms, circumstances, interventions, diagnosis, results and the decision making [1]. One recommendation of this report was to carry out some field tests with SNOMED CT. To make information technology work in health care one needs to accept standardisation of the data, as well as the vocabulary and the electronic messages, next to security of medical information. In the Netherlands, NICTIZ takes responsibility for this [2]. According to NICTIZ standardisation is necessary to realize clinical data exchange between different Electronic Health Record (EHR) systems, all with their own characteristics. NICTIZ chose Health Level Seven version 3 (HL7 v3) to be the standardisation methodology for messaging [3]. In several projects in which HL7 v3 was used, we identified the need for an additional coding system, next to existing coding systems, because unique codes were needed to correctly exchange information electronically. The focus in these projects is on the unique coding of each variable or activity of interest, i.e., the Act.code and Observation.code attributes in HL7 v3. To achieve this unique coding, we adapted several materials in which coding with ICD 10 and ICF had been carried out. However, this was not sufficient and especially in scale representation, semantically incorrect [4] Thus we choose different approaches to obtain unique coding. First we decided to invent new codes as a temporary solution to this problem to facilitate implementation of the stroke EHR and messaging. However, this is an undesirable situation in the long run, due to maintenance and interoperability issues. For this reason an explorative study was carried out for using SNOMED CT codes as standardized clinical terminology for one clinical domain: the care for stroke patients. SNOMED Clinical Terms (SNOMED CT) is a dynamic, scientifically validated clinical health care terminology and infrastructure [5]. By applying SNOMED CT coding, data can be captured, shared and aggregated in a consistent way across specialities and domains of care. Due to the SNOMED CT Core clinical terminology, SNOMED CT can be used for electronic medical records, ICU monitoring, clinical decision support, medical research studies, clinical trials, computerized physician order entry, disease surveillance, image indexing and consumer health information services [5]. In this study we tried to replace both the present codes, self made or from existing coding systems, like ICD10 and ICF, with SNOMED CT codes in the care information 6

models we created for an EHR for the continuity of care of stroke patients. A care information model is often also referred to as a template [3, 6]; an example can be found in Appendix 1. The care information models, or templates, that were developed for the EHR for stroke patients integrate knowledge, terminology and coding, and information models, with HL7 v3 as the underlying standardisation method [6, 7]. These models were derived from (paper) records given to us by the care professionals who were involved in the project for the EHR for stroke patients, are based on national guidelines for stroke care, and are based on evidence in the literature e.g., for scientific scales and instruments, or national study results [8]. After creating these care information models, they were shown to the care professionals for validation and feedback. If necessary they were corrected so they would correspond to the domain of stroke. The goal of this study was to explore the usefulness of SNOMED CT for uniquely coding the medical information in the care information models for the stroke domain. This is part of the ongoing development of standards, messages and the EHR for stroke patients [8]. The following research questions were formulated for this exploratory study of SNOMED CT: 1. for how many of the codes of the clinical concepts in the care information models can we find unique SNOMED CT codes?; 2. is there a difference between individual concepts and concepts representing scientific scales or measurement instruments with clinimetric characteristics? The results of the study were not only quantitative results but also qualitative results and recommendations. An important recommendation is to perform real life experiments with SNOMED CT in an EHR and in HL7 v3 messages, which is in planning phase. As a result of this, one can underpin decisions about the introduction of SNOMED CT as the national standard terminology for coding in EHR and HL7 v3 messages. After describing a literature study in chapter 2, the method of the study for the usefulness of SNOMED CT will be described in chapter 3. Next, the results of the study will be reported in chapter 4, after which the conclusions are given in chapter 5. The final chapter, chapter 6, describes recommendations. 7

Literature study The authors of this document were involved in a project on creating an Electronic Health Record (EHR) for the complete chain of care for stroke patients [8, 9]. All the information that is recorded for the stroke patients in the present situation was gathered. Then this information was organised. This organisation resulted in 84 care information models; see Appendix 1 for an example. In such care information models (validated) scales or instruments, observations or actions are described in detail. These 84 care information models contain altogether 1110 single elements that needed unique coding to be exchangeable in HL7 v3 messages. These care information models represent best practice, are Health Level 7 compliant, support the uptake of standardized terminologies and facilitate technical implementation in both electronic messages and clinical information systems. One of the paragraphs of the care information models describes the mapping table of the specified data and valueset in the domain to the HL7 Reference Information Model and message models. In this mapping table all items that are recorded in an EHR receive a unique code. A unique code is needed to exchange the information with other systems; this is called semantic interoperability [3]. The codes we were looking for where to correctly represent the concept for use in the code attribute of the HL7 class Act or Observation [2, 3]. Preferably these unique codes would be adopted from existing coding systems. However, most items could not get a unique code from these existing coding systems. This resulted in self made codes, which are unique but do not correspond to an existing coding system, are therefore difficult to maintain, and, due to lack of standardization, will only support partial interoperability. White and Hauan [10] discuss the way the LOINC coding system can adequately represent instruments and scales. They argue that a particular important aspect of coding is to maintain the psychometric or clinimetric properties of instruments and scales. Although this work was carried out with another coding system, their criterion refers to the domain content and therefore, we believe, is valid for any coding system applied: the meaning of the concept in the scale should precisely be represented in the wording and in the coding. A particular area of interest is that the quality of a scale is often represented in the binding of the variable or data item, with a very strict and narrow defined value set, the so called name-value pairs. The binding of data-item and the required answer categories represented in a value set, restricts to a large extent the possibilities to use a code from any coding system. If precision in coding is absent, the reliability and validity of a scale is at stake [10]. After creating the 84 care information models, NICTIZ wanted to test if SNOMED CT codes could replace the self made codes. There have been other studies carried out to test the breadth of SNOMED CT [11, 12, 13]. Without being inclusive of all materials, we list three that have a similar domain as focus as our study: coverage of clinical information. In the study of Campbell et al. [11] three potential sources of controlled clinical terminology were compared (READ codes version 3.1, SNOMED International, and Unified Medical Language System (UMLS) version 1.6) relative to attributes of completeness, clinical taxonomy, administrative mapping, term definitions and clarity (duplicate coding rate). The authors assembled 1929 source concept records from a variety of clinical information taken from four medical centres across the United States. The source data included medical as well as sample nursing terminology. The study showed that SNOMED was more complete in coding the 8

source material than the other schemes, because SNOMED covered 70% compared to READ covering 57% and UMLS 50%. From this study it could be concluded that SNOMED was more complete, had a compositional nature and a richer taxonomy. Chute et al. [12] reported a similar result when evaluating major classifications for their content coverage. For their study the clinical text from four medical centres was sampled from inpatient and outpatient settings. This resulted in 3061 distinct concepts. These concepts were grouped into Diagnoses, Modifiers, Findings, Treatments and Procedures, and Other. Each concept was coded into ICD-9-CM, ICD-10, CPT, SNOMED III, Read V2, UMLS 1.3, and NANDA. When coding the concept, the reviewers also scored the concepts: 0 = no match, 1 = fair match, 2 = complete match. Result of this study was that SNOMED had a broader coverage than any of the other coding systems used in this study. SNOMED received the highest score in every category, including Diagnoses (1.90), and had an overall score of 1.74. Wasserman and Wang [13] found a concept coverage of 88,4% when evaluating the breadth of SNOMED CT terms and concepts for the coding of diagnosis and problem lists within a computerized physician order entry (CPOE) system. When they took the relevance of the 145 terms that could not be coded with SNOMED CT into account, they could even conclude that the concept coverage of SNOMED CT was 98,5%. Although these three studies [11, 12, 13] showed that SNOMED CT has a rather high concept coverage, in this study it was expected to find SNOMED CT codes for about half (50%) of the self made codes. This 50% assumption was based on our experiences with looking at other existing coding systems used for these care information models and the vast amount of self made codes that where necessary for all clinical details for stroke patients during their full episode of care [8, 9]. Further, the restriction to only represent the Act.code and Observation.Code attribute in the HL7 class limited our search options. 9

Method From the American College of Pathologists a licence for the project, material on the structure, the contents of SNOMED CT and instructions on how to search for concepts, terms and their corresponding codes were received. After studying this material, all items from the mapping tables of the care information models have been systematically searched for in SNOMED CT. It was decided not only to search for codes for items that had a self made code, but also for items that had a code from another coding system, like ICD 10. This was done to find out how complete SNOMED CT is for the purposes of the care information models. To make sure SNOMED CT was used in the right way, the knowledge of experts was used. Like by means of a document on how to search in SNOMED CT, written by Casey [14]. Based on this document a search strategy was developed; this strategy was as follows: 1. translate the existing Dutch concepts in the mapping table in the care information models into English (this was done, as a requirement from NICTIZ, during the construction of the care information models); 2. start searching with the translated concept, as mentioned in the mapping table of the care information models; 3. when there is no perfect match, search for a concept on the SNOMED CT hierarchical levels above; 4. when there is no perfect concept, search with synonyms; 5. when still no perfect match can be found, search using the SNOMED hierarchy top down. When looking at the care information model for body temperature, for example, the following search strategy was reported. The model for body temperature consists of two concepts: body temperature and method of measuring. For the first concept the term body temperature was entered in SNOMED. This resulted in a hit: 386725007: body temperature. This resulting term fully represented the concept, so the SNOMED CT code was accepted. Then the second concept, method of measuring, was entered in SNOMED. This generated the following result: 371911009: measurement of blood pressure using cuff method. This was not the right concept. The hierarchical levels that lied above were also about blood pressure, so no result could be found via this strategy. Then a kind of synonym was entered: measurement of body temperature. This only generated a concept related to ovulation, which was not what one was looking for. The next step in the strategy was to search top down. For this the following terms were entered respectively: body temperature, measurement and method. All three remained without a result. So, no SNOMED CT code could be found for method of measuring of body temperature. For about the first 20 care information models that were coded, a short report on the search strategy was made. In this report, for every item, it was reported what the search looked like, what the varied results were, and what final result was chosen as the right one for the concept put in the search, together with a motivation for choosing this SNOMED CT concept. Next to that, other remarks on the search or the search results were reported. When in a search a synonym was needed, this synonym and its accompanying search results were also reported. An expert on medical terminology reviewed the complete search report and indicated which search results should be accepted and which should be rejected, with a 10

motivation or clarification. Next to this, the expert also corrected codes by advising to use another SNOMED CT code. The care information models for which the complete search strategy was not reported, only the SNOMED CT codes that could be found, were reviewed. Sometimes neurologists were approached to come up with synonyms for a certain item, which apparently was also not clearly formulated in the original Dutch wording. In some instances, the original Dutch term was replaced by a better one, given the explicit description in SNOMED CT covering the intended meaning more clearly. The final SNOMED CT codes were added to the mapping table in the care information models, so the original codes, self made or from another coding system and the SNOMED CT codes could be used next to each other. The adjusted care information models have been sent to Portavita, a company that works on the SNOMED CT implementation of the EHR for stroke patients for DWO in Delft, The Netherlands. This information system is an EHR for all health professionals involved in the care of a stroke patient. This means that all (medical) information that comes from the GP, the hospital, the rehabilitation centre, the nursing home, and home health care is put in one record. When this system is implemented, the messages, containing patient related information, will be sent from system to system, while using SNOMED CT codes next to the original codes. This way the applicability of SNOMED CT in the EHR and in HL7 v3 messages will be tested. 11

Results For this study 84 care information models were coded. These 84 care information models contained a total of 1110 single concepts or data items, that match the HL7 v3 Observation.code or in some instances the Act.co attribute in messages. For 505 concepts (45,5%) a SNOMED concept ID code has been found in SNOMED CT. Of these 1110 items 605 could not be coded with SNOMED CT (54,5%). For 990 (89%) items there was agreement either for the code that was found or for the fact that no code could be found. Not found could either be that the concept was not available in SNOMED CT, or that the binding of data-item and specific value set could not be represented correctly. When a distinction between self made codes and codes from an existing coding system was made, this showed the following result. For the 1008 self made codes 436 could be coded with SNOMED CT (43%). For the 102 codes from an existing coding system, liked ICD 10 or ICF, 71 could be coded with SNOMED CT (70%). Although SNOMED CT includes a wealth of scales and assessment instruments, most of these allow to code the total score, aggregate observation, or end result, but not the underlying variables or data items, necessary in the EHR. To answer the second research question the difference between SNOMED CT codes found for care information models with single items and care information models representing scientific scales or measurement instruments was studied as well. These results are presented in Table 1. table 1: Difference between SNOMED CT codes found for care information models with single items and care information models representing scientific scales. Amount of care information models Amount of concepts Amount of SNOMED CT codes Percentage of SNOMED CT codes 27 scientific scales 274 43 15,7 % 57 models with 836 462 55,3 % single concepts 84 in total 1110 505 45,5 % For these quantitative results a remark must be made. The items in the care information models are grouped in a HL7 v3 way: by using Organizers and Batteries. An Organizer allows to combine different single data items into a specific group. A Battery is considered a set of observations carried out at the same time, by the same professional, e.g. a lab panel of vital signs panel. For example: the nursing assessment contains 2 Organizers: nursing record and decubitus. The nursing record contains 7 care information models, each with its own items and Batteries to group these items. Although, SNOMED CT covers some relevant categories which could be used for the Organizer, SNOMED CT does not fully support this grouping principle. Therefore, we coded none of the Organizers and Batteries with SNOMED CT at this stage. And although these Organizers and Batteries all need a unique code it cannot be expect that SNOMED CT adds these codes because they do not represent medical information or concepts, but groupings of medical information. Moreover, the grouping can be different for every EHR that is made, depending on how an organisation wants to represent the information, or the clinical relevant organisation of information for specific patient categories. For this study it was thus 12

decided not to code Organizers and Batteries and to leave them out of the calculation for the results. Next to these quantitative results some relevant qualitative findings can be reported as well. First, items of the care information models which exist of two (or more) combined concepts do not always correspond with one concept ID within SNOMED CT. Our solution was to report all the separate codes. For example, when examining the family history of a stroke patient one wants to know if stroke at an early age runs in the family. For this concept three SNOMED CT codes were needed: one for stroke, one for age and one for young. So, sometimes concepts in the clinical domain correspond to two (or more) SNOMED CT concept ID s; the question is whether it is allowed to combine two (or more) separate ID s. In the terminology model and in HL7, this is known as pre-coordination of concepts. Second, the terminology used in the clinical area could not always be found in SNOMED CT. In this case it was tried to find a concept ID that represented the concept that lies behind the terminology used by the care professional. Third, the English translation of the Dutch items did not always result in a SNOMED CT code. Then synonyms were tried. Fourth, items with a left or right indication, like fingers extensors left, could not always be found in SNOMED CT. This problem was solved by using the attribute in an HL7 v3 class in which, for instance, location could be entered. However, this does not solve the terminological issue. On the other hand, this makes the addendum left and right superfluous in the terminology. For example, finger extensors left and finger extensors right could then be replaced by just one item, namely finger extensors, and the left and right are covered in the information model. Another solution to this problem is to combine two SNOMED CT codes: the code for finger extensors combined with the code for right, for example. We have applied pre-coordination with left and right only in those instances where it was absolutely clear, and superior to the expression in the information model. Fifth, as mentioned earlier, the Organizer and Battery concepts are not fully supported by SNOMED CT. It was decided not to search for SNOMED CT codes for the Organizer and Battery concepts anymore. Sixth, the degree of detail within SNOMED CT is very different. Some concepts are coded within detail and other concepts just have one code for the concept itself and no codes for the underlying details of the concept. For example, regularity and constancy of breathing are common observations for stroke patients, however no concept ID s and codes could be found in SNOMED CT. Yet, frequency and profound breathing could be found. Again, this could have been solved with pre-coordination of terms, but was not part of this initial approach. Seventh, the items in the care information models are mainly observations, in SNOMED these need to be observable entities. Though, most items can only be found as clinical findings instead of observable entities. Basically the observable entity should be the question, where the clinical finding should be the answer to the question. This again leads to the combination of name-value pairs. Eighth, in SNOMED CT the use of stimulants, like alcohol, marihuana, and cigarettes is defined as abuse of these stimulants although the use of stimulants is not always considered as abuse, if used with care. Using SNOMED CT here would imply a wrong meaning: use is intended to be documented, and abuse is implied by the terminology. For now it was decided not to use the SNOMED codes for these items. Ninth, SNOMED CT is sometimes inconsistent. For example the cranial nerves are not well represented. Some of these nerves are represented as a clinical finding, some as a function and some as an observable entity. It is to be expected that for 13

every cranial nerve it can be relevant to have an observable entity, a function and a clinical finding. Tenth, several issues arise from having to search for codes that meet the requirements of the messaging. It is obvious that the terminology model (i.e., SNOMED CT) and the information model (i.e., HL7 v3 messages) do match to a large degree, but especially in the area of pre-coordination and binding of namesvalues, there is still work necessary. Partly, such work is carried out in the HL7 Terminfo project [3]. 14

Conclusion and discussion In this study 45,5% of the items could be found in SNOMED CT. As can be seen in the result section the percentage of items found for scales or instruments was lower than the result for care information models containing individual concepts. For scales or instruments, the concepts need to be exactly the same as the scoring items of the tests or scale [9, 10], including the answering possibilities expressed in the value sets. Hardly any tests are included in SNOMED CT beyond the total score or end result. As was shown above only 15,7% of the concepts coming from scientific scales or instruments could be found in SNOMED CT against 55,3% of the individual concepts. The current 45,5% for the 84 care information models in total is lesser compared to similar studies [11, 12, 13], however, it is believed that one had to deal with difficult concepts in this study. These concepts were difficult in two ways: first is the very large granularity of the clinical concepts necessary for the care of stroke patients. These are usually very fine grained details of muscle functions, body position, thought processes etcetera, and in some instances expressed in quite awkward wording. Second, the care information models are often especially made to have an accurate representation in HL7 v3 messages of scales, which have specific clinimetric characteristics [6, 9, 10]. These clinimetric characteristics require an accurate equivalence between the concepts as used in practice and in the clinical terminology used for the unique coding [6, 9, 10]. Especially the strict rules for the binding of observation to value sets limits our findings. In addition, translation errors and or cultural differences might be a reason for this lower percentage. SNOMED CT has predominantly been built for the English language realm, and studies included English terms from clinical documentation. We worked with clinical concepts written up in Dutch terminology, as these were given to us by clinicians, often in their local wording, and derived from guidelines and literature in Dutch. They might use slightly different terms that could not be translated one to one from Dutch to English. For a more reliable result the care professionals, who gave us the (medical) information on which we based the concepts in the care information models, could be asked to review the results of this search in SNOMED CT. They are the best to check if the concepts they use in daily practice are well represented by the concepts that were found in SNOMED CT. Next to that they might also be able to formulate synonyms for concepts without a SNOMED CT code, although the translation from Dutch to English might still cause a bias. From this study it can be concluded that the question as to how many of the concepts from the care information models, that were initially developed for the EHR and HL7 v3 messages for stroke patients continuity of care, could receive a SNOMED CT code, was answered. Currently, with a quite difficult and restricted set of concepts in the area of stroke care, an overall coverage of 45,5% could be found. We believe this percentage can be higher when more pre-coordination of SNOMED CT terms is carried out, and when SNOMED CT continues with their scale representation project [15]. In this project, the observation value set binding will be taken into account. It is important to have standardized clinical terminology such as SNOMED CT applied in the EHR and HL7 v3 messages instead of reinventing the wheel by using self made codes. The motivation for this is to truly achieve semantic interoperability in the exchange of patient information [2, 3, 9]. Based on this study almost half (43%) of these self 15

made codes for clinical concepts could be replaced. We will submit the remaining concepts to SNOMED for future inclusion to meet our needs. 16

Recommendations When searching SNOMED CT we encountered some problems that result in recommendations, these are described below. Some care information models record items not only for the present situation but are also interested in the pre-morbid situation of the patient. The items for the premorbid situation need different codes than the items for the present situation. This because the time attribute in HL7 v3 classes can cause problems when the measure of the scale takes place today, but addresses the situation of a fortnight ago and compares it with the current situation. In SNOMED CT we could not find the items in both the present and the pre-morbid situation. A solution would be to have a SNOMED CT code for pre-morbid so all items that need a code for both the present and the pre-morbid situation can have a unique (combination of) code. The SNOMED CT code for the item itself can be used for the present situation and the same code can then be used in combination with the code for pre-morbid that create an unique combination of codes for the pre-morbid situation. Some terms in SNOMED CT make it clear to us that the source material should be changed because items needed a more precise definition or because the item needed to be split in two items. For example the item attention/concentration. These two words do not mean the same thing, so they need to be split and both need to be given their own SNOMED CT code. These results made us change the original material and adjust the care information models. Another problem were abbreviations in the source materials. It was not always clear what the abbreviation meant. Then no term could be inserted in the search engine for SNOMED CT. In the future it should be forbidden to work with abbreviation in the source material that is used for creating an EHR. For the Dutch situation we encountered a problem with the willingness to be a donor. If one has a donor card in the Netherlands this cards says if one wants or if one does not want to be a donor. The fact that one has a card does not say anything about wanting to be a donor. Nowadays these cards are no longer necessary. When a person dies a doctor is obliged to consult the donor registry to check if this persons wants to be a donor. Another issue with donor is that one has four choices, instead of just two (yes, I want to be a donor and no, I do not want to be a donor). One can also choose to leave the decision about being a donor to the relatives or even to a specific person. Further study of coding for this topic is necessary. As result of this study it can be conclude that SNOMED CT has several characteristics that make it useful to continue its application in stroke care, and after further testing, in the Dutch national infrastructure. We could find roughly half of the specific codes for granular terms. In addition, there are some reasons why we can get all codes needed in the near future. First, SNOMED CT has the possibility to request inclusion and coding of concepts that could not be found in SNOMED CT. This means that expansion is an option. Second, SNOMED CT has an ongoing project for scale representation that takes the clinimetric aspects of scales and concepts into account. Third, SNOMED CT is working on further internationalisation in order to meet European requirements. Fourth, Snomed and HL7 are working in the Terminfo project to sort out the 17

intricacies of the terminology model (e.g. pre-coordination) and the information model (e.g. using method or location attributes in classes) [3]. These guidelines are under development and will inform future projects like ours. Finally, the clinical use in the Electronic Health Record system, which is built at the moment, and in HL7 v3 messages will reveal additional information about the usability of SNOMED CT in the clinical care for stroke patients and is therefore recommended. Of course it is also recommended to have more clinical areas than just the area of stroke researched in such a way. A final recommendation would be to tackle the translation issue. 18

References [1] Nationaal ICT Instituut in de Zorg, NICTIZ (2003). Introduction of a clinical terminology in the Netherlands, Needs, Constraints, Opportunities. Leidschendam, NICTIZ. [2] Nationaal ICT Instituut in de Zorg. Web documents [Online]. [cited January 10, 2006]; Available from: URL: www.nictiz.nl. [3] Health Level Seven. Web documents [Online].[cited January 10, 2006]; Available from: URL: www.hl7.org. [4] Goossen WTF (2005). De problemen met de coderingen in de Nederlandse gezondheidszorg moeten maar eens aangepakt worden. Zorgadministratie en Informatie, jaargang 31, nr 122, december 2005. [5] SNOMED Clinical Terms. Web documents [Online]. [cited December 28, 2005]. Available from: URL: www.snomed.org. [6] Kooij van der J, Goossen WTF, Goossen-Baremans ATM, Plaisier N. Evaluation of documents that integrate knowledge, terminology and information models. In: Park HA, Murray P, Delaney C (Eds). Consumer-Centered Computer- Supported Care for Healthy People. Proceedings of NI2006. Amsterdam etc. IOS Press. Pp. 519-522. Studies in Health Technology and Informatics, volume 122. [7] Goossen WTF. Templates: an organizing framework to link evidence, terminology and information models in the nursing profession. In: de Fatima Marin H, Pereira Margues E, Hovenga E, Goossen W, editors. E-Health for all: designing a nursing agenda for the future. Proceedings 8th International Congress in Nursing Informatics NI 2003. Rio de Janeiro, Brazil, E-papers Serviços Editoriais Ltd, pp. 461-465. [8] Reuser L, Goossen WTF, Heijden, van der, H. Call for ICT within stroke service care. In: Runnenberg, J. et al, editors. Health Information Developments in the Netherlands by the year 2003. 6 th ed, pp. 52-56. [9] WTF Goossen. Intelligent semantic interoperability: integrating knowledge, terminology and information models to support stroke care. In: Park HA, Murray P, Delaney C (Eds). Consumer-Centered Computer-Supported Care for Healthy People. Proceedings of NI2006. Amsterdam etc. IOS Press. Pp. 435-439. Studies in Health Technology and Informatics, volume 122. [10] White TM, Hauan MJ. Extending the LOINC conceptual schema to support standardized assessment instruments. Journal of the American Medical Informatics Association 2002; 9 (6):586-599. [11] Campbell JR, Carpenter P, Sneiderman C, Cohn S, Chute CG, Warren J. Phase II evaluation of clinical coding schemes: completeness, taxonomy, mapping, definitions, and clarify. Journal of the American Medical Informatics Association 1997; 4:238-51. [12] Chute C, Cohn S, Campbell K, Oliver D, Campbell JR. The content coverage of clinical classifications. Journal of the American Medical Informatics Association 1996 May/June; 3:224-233. [13] Wasserman H, Wang J. An applied evaluation of SNOMED CT as a clinical vocabulary for the computerized diagnosis and problem list. AMIA 2003: Annual Symposium Procedure; 2003, pp. 699-703. [14] Casey A. Finding terms in SNOMED CT - supplement to browser guidance 2005 June. Internal report SNOMED CT. [15] Konicek D. Warren J, Casey A, Gabriel D, Spisla C. Using Snomed CT in standardized assessment scales. A proposal from the Snomed international 19

nursing working group. Workshop at Nursing Informatics 2006 conference, Seoul, Korea, June 13, 2006. 20

Appendices 21

Appendix 1: care information model barthel index BARTHEL INDEX Observation: Barthel_Index_R01E File: Translation_BarthelIndex_R01_v0.7E.doc Version 0.7 documentation: Status: Submitted Draft Request for Comments Final Standard: HL7 Version 3 (August 2004) Authors: Ir. A.M. Fleurke, Dr. W.T.F. Goossen, E. J. Hoijtink, Drs. J. van der Kooij & Drs M. Vlastuin. Source: Nictiz Specificaties CVA-keteninformatiesysteem versie 1.1 d.d. 29 september 2004 Dr William Goossen, Drs. Ron Meijer, Pamela van der Kruk, Drs. Lonneke Reuser 1. Version management Version Date Adjustments Authors 0.7 24-08- SNOMED CT coded were added. Dr William Goossen 2006 0.6 04-05- 2005 Model was adjusted and mistake in example was removed Judith van der Kooij, MA 0.5 03-05- 2005 Translation adjusted to Doc_Obs_Barthel_Index_R01_V1.2. Judith van der Kooij, MA 0.4 28-04- 2005 Mapping table: V is changed to M. Judith van der Kooij, MA 0.3 19-01- 2005 Translation adjusted to Doc_Obs_Barthel_Index_R01_V1.0. Dr William Goossen Judith van der Kooij, MA 0.2 18-05- 2005 Translation adjusted to Doc_Obs_Barthel_Index_R01_V0.99. Judith van der Kooij, MA 0.1 22-12- 2004 2. Aim of the Barthel Index Translation of the most recent document of the Barthel Index. Judith van der Kooij, MA The aim of the Barthel Index is to be able to capture and follow, in a valid and reliable way, the daily activities of the patient, especially the level of depending on help. Particularly for the CVA patients, the Barthel Index is frequently applied and is part of the CBO guidelines (guidelines of the Dutch Institute for Healthcare) for CVA patients. 3. Scientific foundations The Barthel Index has been developed to determine possibilities of patients to be able to handle the activities of daily life (Mahoney & Barthel, 1965). The scientific research for the Netherlands is done by De Haan, Limburg, Schuling, Broeshart, Jonkers & van Zuylen (1993). It appears that this scale is valid and reliable for 22

individual use and for use in populations (epidemiological research), as a measure of outcome, for example. The Barthel Index is a mandatory scale in the guidelines for stroke for physiotherapy, in the Netherlands (van Peppen, Kwakkel, Berns, Buurke, Halfens, Harmelingen van der Wel, Hobbelen, Kollen, Vogel & Wagenborg, 2004). For NICTIZ the Barthel Index was drawn up for the CVA ketenzorg (CVA Chain of Care) (Goossen, Meijer, van der Kruk & Reuser, 2004). The inconsistencies between literature, specifications and practice appeared to be a problem in some cases. That is why the Barthel Index as published in the Nederlands Tijdschrift voor Geneeskunde (the Dutch Journal of Medicine) by De Haan et al. (1993) was used for the Dutch specifications. This means that this document has been based on this Dutch version of the Bathel Index. It might differ from other versions that are available. The Barthel Index can be used to monitor the development of the daily activities and to show the results of treatment and rehabilitation. 4. Description of variables of the Barthel Index The proper variables and values are given in the table below. This table is based on the KNGF guideline for stroke, written by Van Peppen et al. (2004). Table 1 Variables, score items and conditions for the Barthel Index Function / organ Items Condition Continence of Bowels Controlling Bladder Personal Toilet 0 = incontinent 1 = occasional accident 2 = continent 0 = incontinent, or catheterized and unable to manage alone 1 = occasional accident (max. 1 time per 24 hours) 2 = continent (during more than 7 days) 0 = needs to help with personal care 1 = independent (face/hair/teeth/shaving) Previous week. When a urine catheter is necessary this is marked as incontinent. Occasional = once a week Previous week. Occasional = once a week A patient who can take care of his catheter himself is marked as continent. Previous 24-48 hour. Refers to personal hygiene like brushing teeth, shaving and washing. Needed attributes can be handed to the patient. Toilet use Eating 0 = dependent 1 = needs some help, but can do something alone 2 = independent (on and off, dressing, wiping) 0 = unable (dependent) 1 = needs help cutting, spreading butter, etc. 2 = independent Needs some help = can wipe himself and can perform any of the acts mentioned above. Independent = able to go to the toilet, get undressed, clean, dress and leave. Help = food is being cut to pieces; patient eats by himself. Able to eat normal food (even tough food). The food can be cooked and served by others, but can not be cut to pieces. 23

Transfer 0 = unable (dependent) 1 = major help (one or two people, physical) 2 = minor help (verbal or physical) 3 = independent Unable = not able to sit; a lifting device is used. Major help = a strong trained person or 2 people; patient can sit straight. Minor help = a person for supervision or some help. Mobility 0 = immobile 1 = independent but uses a wheelchair, including corners 2 = walks with help of one person (verbal or physical) 3 = independent Dressing/undressing 0 = dependent 1 = needs help but can do about half without help 2 = independent Stairs 0 = unable 1 = needs help (verbal, physical, carrying aid) 2 = independent Bathing 0 = dependent 1 = independent (or in shower) Help = an untrained person, including supervision and moral support. Independent = can move himself in the house or on the ward; aid can be used. A patient in a wheelchair should be able to handle corners and doors. Half = help is only needed with buttons, zippers, etc.; can put some clothes on by himself. Independent = being able to choose clothes and put them on. Independent = can carry an aid himself (if applicable). Independent = without supervision or help when getting in and out of the bath and when washing himself. 5. Working instructions The Bartel Index registers what the patient can do. It is not a registration of what the patient could do. The main aim is to record the level of dependency on help (physical or with words), how little this may be and irrespective of the cause. According to Goossen et al. (2004) the achievements of the patient are to be recorded by using the most appropriate source of information. According to Mahoney & Barthel (1965) the patient, friends, family members and nurses are the usual sources. Next to that direct observations and reasoning are also important. This shows that it is not necessary to really test the patient. Usually the achievements during the last 24 48 hours are important, but sometimes longer periods are relevant. It is important that the Barthel Index is measured both premorbid, as well as during hospitalization. It is often used during rehabilitation as well. Points of interest Unconscious patients score 0 on everything, even if there is no incontinence yet. The intermediate scoring categories presume that the patient is providing more than half of the achievements. When the patient feels the need for supervision, this means not independent. To be able to be independent, the patient is allowed to use aids. Variables and values: 24

The appropriate variables and values are given above, in Table 1. 6. Interpretation guidelines The Barthel Index uses the sum score. The scores on the separate variables are counted up. The interpretation of the total score is 0-9 for seriously limited, 10-19 for moderately limited and 20 for independent. This means that 20 is the maximum score. 7. Literature / acknowledgement Goossen, W. T. F., Meijer, R., Kruk, van der, P. & Reuser, L. (2004). Specificaties CVA keteninformatiesysteem. Versie 1.1. Leidschendam, NICTIZ. Haan, de, R., Limburg, M., Schuling, J., Broeshart, J., Jonkers, L., & Zuylen, van, P., (1993). Klinimetrische evaluatie van de Barthel-index, een maat voor beperkingen in het dagelijks functioneren, Nederlands Tijdschrift voor Geneeskunde, 37 (18), 917-921. Mahoney, F. I., & Barthel, D. (1965). Functional Evaluation: The Barthel Index. Maryland State Medical Journal, 14, 56-61. Peppen, van, R. P. S., Kwakkel, G, Berns, M, Buurke, J. H., Halfens, J., Harmeling - van der Wel, B. C., Hobbelen, J. S. M., Kollen, B. J., Vogel, M. J. & Wagenborg, L. (2004). Richtlijn Beroerte. Amersfoort: Koninklijk Nederlands Genootschap voor Fysiotherapie (KNGF). 8. An example of the instrument An example of the Barthel Index is given below. function / organ items condition score date Continence of Bowels Controlling Bladder Personal Toilet 0 = incontinent 1 = occasional accident 2 = continent 0 = incontinent, or catheterized and unable to manage alone 1 = occasional accident (max. 1 time per 24 hours) 2 = continent (during more than 7 days) 0 = needs to help with personal care 1 = independent (face/hair/teeth/shaving) Previous week. When a urine catheter is necessary this is marked as incontinent. Occasional = once a week Previous week. Occasional = once a week A patient who can take care of his catheter himself is marked as continent. Previous 24-48 hour. Refers to personal hygiene like brushing teeth, shaving and washing. Needed 25

Toilet use Eating Transfer Mobility 0 = dependent 1 = needs some help, but can do something alone 2 = independent (on and off, dressing, wiping) 0 = unable (dependent) 1 = needs help cutting, spreading butter, etc. 2 = independent 0 = unable (dependent) 1 = major help (one or two people, physical) 2 = minor help (verbal or physical) 3 = independent 0 = immobile 1 = independent but uses a wheelchair, including corners 2 = walks with help of one person (verbal or physical) 3 = independent attributes can be handed to the patient. Needs some help = can wipe himself and can perform any of the acts mentioned above. Independent = able to go to the toilet, get undressed, clean, dress and leave. Help = food is being cut to pieces; patient eats by himself. Able to eat normal food (even tough food). The food can be cooked and served by others, but can not be cut to pieces. Unable = not able to sit; a lifting device is used. Major help = a strong trained person or 2 people; patient can sit straight. Minor help = a person for supervision or some help. Help = an untrained person, including supervision and moral support. Independent = can move himself in the house or on the ward; aid can be used. A patient in a wheelchair should be able to handle corners and doors. 26

Dressing/undressing 0 = dependent 1 = needs help but can do about half without help 2 = independent Stairs 0 = unable 1 = needs help (verbal, physical, carrying aid) 2 = independent Half = help is only needed with buttons, zippers, etc.; can put some clothes on by himself. Independent = being able to choose clothes and put them on. Independent = can carry an aid himself (if applicable). Bathing Total 0 = dependent 1 = independent (or in shower) Independent = without supervision or help when getting in and out of the bath and when washing himself. 9. Model and description An important part of the clinical instruments for CVA ketenzorg (CVA Chain of Care) is drawn up by using an instruction, a HL7 v3 Domain model (D-MIM) and codes. At this stage, it can be foreseen that these models are not always necessary. However, the advantage of a model is that all requirements for the use of a clinical instrument are together in one model. On the other hand, other representation formats are available, like templates and archetypes, that could possibly lead to results in a quicker way. Where D-MIMs are available, they will be kept. For new instruments they are not being drawn up, but one will seek for a format which is easy to implement in a message and system. The D-MIM model for the Barthel Index starts with the naming on top (entry-point), with the name Barthel_Index. Beneath that is the act type Observation (OBS) with the name Barthel_Index. This is the central OBS for this model. In this act the total score of the Barthel Index is shown. The class Barthel Index has class code = OBS. Furthermore, the field for code system should be filled with the Barthel Index. In the derivation code the total score for the arthel Index is recorded. In other words: derivation method = add all values of the separate variables. Effective time is the point in time on which the Barthel Index is scored. The total score Sumscore for the Barthel Index is included in the derivation code. In other words, derivation method = add all the values of the individual variables. In value the value, that was created by adding the individual variables, is filled up. This is always an INT data type because it is mandatory to score and fill up all items to get a good sum score. That is why Mandatory (1..1). 27