Terminology system-based data encoding for intensive care: Deriving the APACHE-IV reasons for ICU admission classification through SNOMED CT and optimizing the user interface for diagnostic data entry

(1)

1

Terminology system-based data encoding

for intensive care

Deriving the APACHE-IV reasons for ICU admission classification through SNOMED CT and optimizing the user interface for diagnostic data entry

(2)

2

Terminology system-based data encoding

for intensive care

Deriving the APACHE-IV reasons for ICU admission classi fication through SNOMED CT and optimizing the user interface for diagnostic data entry

Student

Hugo Johan Theodoor van Mens Faculty of Medicine

Department of Medical Informatics

Academic Medical Center, University of Amsterdam Meibergdreef 9

1105 AZ Amsterdam Student ID: 0582115

E-mail: h.j.vanmens@amc.uva.nl Location of Scientific Research Project Faculty of Medicine

Department of Medical Informatics

Academic Medical Center, University of Amsterdam Meibergdreef 9

1105 AZ Amsterdam Practice training period May 2015 – January 2016 Supervisors

Dr. ir. Ronald Cornet Faculty of Medicine

Department of Medical Informatics, J1B-114 Academic Medical Center, University of Amsterdam Meibergdreef 9

1105 AZ Amsterdam +31 (0) 20 56 65205

E-mail: r.cornet@amc.uva.nl Prof. dr. Nicolette F. de Keizer Faculty of Medicine

Department of Medical Informatics, J1B-114 Academic Medical Center, University of Amsterdam Meibergdreef 9

1105 AZ Amsterdam +31 (0) 20 56 65188

(3)

3

Summary

INTRODUCTION Patients are sent to the intensive care unit (ICU) for several reasons, such as life-threatening medical problems or monitoring after an extensive surgery. The reason for ICU admission is registered in the electronic medical record (EMR) for direct patient care. Additionally, it is

registered for the Acute Physiology and Chronic Health Evaluation IV (APACHE-IV) model to assess the severity of illness of patients at the intensive care, e.g. for quality improvement. This double registration creates an unnecessary administrative burden for ICU clinicians and may lead to suboptimal data quality. Another problem is that encoding diagnoses in a usable manner is

challenging, and evidence to support guidelines for optimal user interface (UI) design to support this encoding is limited. PURPOSE The purpose of this scientific research project was to investigate how the APACHE-IV reason for ICU admission can be derived directly from data in the EMR and to gather evidence for guidelines to optimize the UI for medical data encoding.

APACHE-IV DERIVATION METHOD We applied an existing four-step framework to update an existing SNOMED-APACHE mapping from the January 2011 version of SNOMED CT to the July 2015 version. We performed three additional steps to enable the derivation of the APACHE-IV classes from data in the EMR: (1) a migration and revision of the database, (2) the definition of classification rules; particularly for other, unknown and trauma classes, and (3) the design of the derivation process. RESULTS The update was carried out partially: we updated or removed 4 concepts and 7

relationships and revised the database to a new representation in line with SNOMED CT technical documentation. We developed classification rules which could replace the partially mapped other classes (n=49) and unknown classes (n=4) to fully mapped classes and allow the derivation of trauma classes based on traumatized body parts. DISCUSSION With these results we are one step closer to the APACHE-IV derivation from data in the EMR, but the mapping still needs to be revised and updated further. The derivation is hampered by the fact that the APACHE-IV classes are not defined explicitly. CONCLUSION The derivation of APACHE-IV classes requires an up to date SNOMED-APACHE mapping with classification rules, the encoding of admission diagnoses with SNOMED CT or SNOMED CT-based interface terminology and explicitly defined APACHE-IV classes.

UI CONFIGURATION FOR DIAGNOSTIC DATA ENCODING METHOD We compared a guideline-compliant UI configuration for encoding diagnoses to one that resembles the configuration of an existing system, but is not guideline-compliant. Time, correctness, task completion, ease of use, user preference and motivations were the outcomes measures. We used a cross-over design in which we switched a randomly assigned initial configuration after half of the (n=20) cases. SETTING Residents, fellows and assistants (n=27) of the ICU of the Academic Medical Center Amsterdam completed the experiment. RESULTS We did not find a significant difference in correctness, task completion or ease of use, but participants were 19.3% (95% confidence interval: 6.38-33.7%, p-value<0.01) faster with the guideline-compliant UI configuration and had a clear preference for this configuration. Their motivations were in line with the guidelines. DISCUSSION Possibly, the sample size was too low to obtain significant differences in correctness, task completion and ease of use. CONCLUSION The time difference and clear user preference indicate the importance of UI design guidelines for encoding medical data. In order to find the influence on correctness, task completion and ease of use, and to evaluate more types of configurations, more research is required.

CONCLUSION Deriving the APACHE-IV classification from the EMR is still hampered by an incomplete mapping between the interface terminology and SNOMED CT. We indicated that

guideline-compliance of a UI to support medical data encoding can increase the speed of encoding and that participants prefer the UI that is compliant. The updated SNOMED-APACHE mapping needs to be implemented and evaluated in future research.

(6)

6

Dutch Summary: Samenvatting

INTRODUCTIE Patiënten worden voor uiteenlopende redenen naar de intensive care (IC) gestuurd, zoals levensbedreigende medische problemen of monitoring na een uitgebreide operatie. De reden voor IC opname wordt in het elektronisch patiëntendossier (EPD) geregistreerd voor de directe patiëntenzorg. Daarbovenop wordt het geregistreerd voor het Acute Physiology and Chronic Health Evaluation IV (APACHE-IV) model, om de ernst van ziekte van IC patiënten in te schatten, voor onder andere kwaliteitsverbetering van de zorg. Deze dubbelregistratie zorg voor een onnodige

registratielast voor clinici op de IC en kan leiden tot suboptimale datakwaliteit. Een ander probleem is dat het vastleggen van diagnosen op een gebruiksvriendelijke manier lastig is; en dat evidence om richtlijnen voor het optimale ontwerp van de user interface (UI) om dit te ondersteunen beperkt is. DOEL Het doel van dit wetenschappelijk onderzoeksproject was om te onderzoeken hoe de APACHE-IV reden voor IC opname direct kan worden afgeleid uit data in het EPD en evidence te verzamelen voor richtlijnen om de UI voor het vastleggen van medische data te optimaliseren.

APACHE-IV AFLEIDING METHODE We hebben een bestaand raamwerk van vier stappen toegepast om een bestaande SNOMED-APACHE koppeling te vernieuwen van de versie van SNOMED CT van januari 2011 naar die van januari 2015. We hebben drie extra stappen uitgevoerd om de afleiding van de APACHE-IV klassen uit data in het EPD mogelijk te maken: (1) de migratie en revisie van de database, (2) de definitie van klasseerregels, en (3) het ontwerp van het afleidingsproces.

RESULTATEN De update was deels uitgevoerd: we hebben 4 concepten en 7 relaties vervangen of verwijderd en de database herzien voor een nieuwe representatie in overeenstemming met de technische documentatie van SNOMED CT. We hebben klasseerregels gemaakt om ten dele gekoppelde klassen met “overige” (n=49) en “onbekend” (n=4) volledig te koppelen en om de afleiding van traumaklassen mogelijk te maken op basis van de getraumatiseerde lichaamsdelen. DISCUSSIE Met deze resultaten zijn we een stap verder gekomen in de richting van de automatische afleiding van de APACHE-IV klassen uit data in het EPD. De koppeling moet wel nog verder

geëvalueerd en geactualiseerd worden. De afleiding wordt belemmerd door het feit dat de APACHE-IV klassen überhaupt niet expliciet gedefinieerd zijn. CONCLUSIE De afleiding van APACHE-APACHE-IV klassen benodigt een actuele SNOMED-APACHE koppeling met klasseerregels, het vastleggen van diagnosen met SNOMED CT of een interface terminologie die op SNOMED CT gebaseerd is en expliciet

gedefinieerde APACHE-IV klassen.

UI CONFIGURATIE VOOR HET ENCODEREN VAN DIAGNOSEN METHODE We hebben een UI configuratie die overeenstemde met de richtlijnen vergeleken met een UI configuratie die leek op een bestaand systeem, maar niet overeenstemde met de richtlijnen. Tijd, correctheid, taakvoltooiing, gebruiksgemak, gebruikersvoorkeur en motivaties waren de uitkomstmaten. We hebben een cross-over design gebruik waarbij we een willekeurig toegewezen beginconfiguratie wisselden na de helft van de (n=20) casussen. RESULTATEN Stafartsen, fellows en artsen in opleiding (n=27) van het Academisch Medisch Centrum Amsterdam hebben het experiment voltooid. We hebben geen significant verschil gevonden in de correctheid, taakvoltooiing of het gebruiksgemak, maar

deelnemers waren 19.3% (95% betrouwbaarheidsinterval: 6.38-33.7%, p-waarde<0.01) sneller met de UI configuratie die met de richtlijnen overeenstemde, en ze hadden ook een duidelijke voorkeur voor deze configuratie. DISCUSSIE Mogelijk was de steekproefgrootte te klein om significante verschillen in de correctheid, taakvoltooiing en het gebruiksgemak te meten. CONCLUSIE Het tijdsverschil en de duidelijke gebruikersvoorkeur duiden op het belang van het volgen van de richtlijnen voor het ontwerp van de UI voor de registratie van medische data. Om de invloed op de correctheid, taakvoltooiing en het gebruiksgemak te vinden, en om meer verschillende instellingen te vergelijken, is er meer onderzoek nodig.

(7)

7

CONCLUSIE De afleiding van de APACHE-IV klassen wordt nog belemmerd door een incomplete koppeling tussen de interface terminologie en SNOMED CT. We hebben aangeduid dat het volgen van de richtlijnen voor het ontwerp van de UI voor de registratie van diagnosen kan leiden tot snellere registratie en dat deelnemers een duidelijke voorkeur hebben voor de UI die aan de richtlijnen voldoet. De geactualiseerde SNOMED-APACHE koppeling moet geïmplementeerd en geëvalueerd worden in vervolgonderzoek.

Keywords

(8)

8

1. Introduction

1.1 Medical domain context: intensive care

Critically-ill patients with severe and life-threatening conditions are treated at the intensive care (IC).1_{The patient population is very heterogeneous, although they generally are characterized by a}

dysfunction of one or more organ systems. The patients might suffer from disorders such as organ failure, respiratory insufficiency, cardiac arrest, coma or sepsis for example. Patients might have been admitted to the IC unit (ICU) for several reasons, such as complications after cardiovascular surgery or after severe trauma due to a traffic accident.2_{Because of this variety in the patient}

population, multiple medical disciplines are involved. The instability and high mortality risk of IC patients requires intensive monitoring, among other things with monitoring devices, for instance with electrocardiograms to monitor the heart rate. Often, patients also require pharmacological or mechanical support, such as medication to control their blood pressure or mechanical ventilation to support their breathing. Large amounts of data about the patients are recorded from the devices and by the staff for direct patient care and often additionally for secondary purposes as well, such as quality improvement and research. Automation therefore already happened relatively early in this medical domain, in order to keep an overview of the patient’s condition.

1.2 Problem definition

1.2.1 Redundant diagnostic data entry

The reason for ICU admission is registered in the Patient Data Management System (PDMS) to keep a record of the patient for direct patient care. Additionally, this reason for admission is used for other purposes, particularly for the Acute Physiology and Chronic Health Evaluation IV (APACHE-IV) model.3

This model is used internationally in IC to quantify the severity of illness of IC patients and to predict the risk of mortality. APACHE-IV mortality predictions are used for several purposes, including to stratify patients in research and to correct for case-mix in quality assessment of ICUs. The model uses demographic, physiological and diagnostic data available in the first 24 hours of ICU admission. In the Netherlands the APACHE-IV is used by the National Intensive Care Evaluation (NICE) medical registry4

with the aim to monitor and improve the quality of ICU care. By comparing the actual in-hospital mortality with the predicted mortality, ICUs can evaluate their performance and identify areas or patient populations for improvement. The ICU of the Academic Medical Center in Amsterdam (AMC)5

is one of the 85 participating ICUs in the NICE registry.

The APACHE-IV score and mortality prediction are currently obtained by automatically extracting physiologic and demographic data from the PDMS. In spite of this, the APACHE-IV reason for ICU admission classes cannot be taken automatically from the PDMS yet, as the reasons for IC admission are recorded as free text in the PDMS. Consequently, the reasons for admission are entered a second time, by picking one category from a specific APACHE-IV reasons for ICU admission list. This is thus a form of redundant data entry, because the same diagnoses have to be registered twice in different formats. Other ICUs are confronted with similar situations. In order to prevent this redundant data entry, it should be possible to derive the APACHE-IV classes in a fully automated way from the medical record. This will be relevant to all ICUs that participate in the NICE registry and we expect it to increase the data quality of the NICE registry and decrease the administrative burden for

clinicians.

1.2.2 Incomplete SNOMED-APACHE mapping

In order to automatically obtain the APACHE-IV classes from the PDMS, the reasons for admission have to be encoded with medical terminology systems. As of November 2015, within the PDMS of the new electronic medical record (EMR) of the AMC, reasons for ICU admission will be registered

(9)

9

based on the Dutch interface terminology Diagnosethesaurus (DT)6_{. The DT is, albeit in part, mapped}

to the reference terminology SNOMED CT to enable the reuse of diagnostic data, for purposes such as reimbursement, auditing and research. SNOMED CT is a medical terminology system that can be used to register medical data, among which diagnoses, in EMRs in a fine-granular and formalized way7_.

In previous research a mapping between SNOMED CT and the APACHE-IV reasons for ICU admission classification has been developed at the AMC8,9_{, in order to realise the automatic derivation of the}

APACHE-IV reason for ICU admission from the PDMS. Up till now this mapping could not be used in practice as SNOMED CT had not been implemented. Now that the AMC will use the DT, and by this SNOMED CT, to enter reasons for ICU admission, finally the established SNOMED-APACHE mapping can be utilized in order to derive the APACHE-IV classes from the DT concepts. Figure 1 illustrates the relationships between the interface terminology DT, reference terminology SNOMED CT and

aggregate terminology APACHE-IV. Aggregate terminology is another word for a classification system. DT, SNOMED CT and possibly other terms (illustrated with “term n”) refer to DT concepts. These are linked to SNOMED CT concepts. The APACHE-IV classification, but also other aggregate terminologies (illustrated with “aggregation n”), can be derived from the DT and SNOMED CT (see the next chapter for background information).

Figure 1: Interface terminology Diagnosethesaurus (DT) relationship to reference terminology SNOMED CT, and aggregate terminologies ICD, DBC and APACHE (adapted from DHD, 2014)6

The DT was developed based on the input of over 25 Dutch scientific medical societies, but

unfortunately but the IC specialty had not been involved so far.6_{Hence, it is not clear if the DT fits the}

requirements of this medical domain. Furthermore, the latest version of the SNOMED-APACHE mapping is from January 2011 and is not up to date anymore and needs to be adapted to the July 2015 SNOMED CT version. Additionally, this mapping did not address classification rules that are necessary to complete the derivation of the APACHE-IV classes. For example, a patient with a head and chest trauma would be classified as having ‘Head trauma’ and as a ‘Chest trauma’, but together this should become a ‘Head/chest trauma’. This type of aggregation cannot and should not be modelled in SNOMED CT, but has to be formalised separately. These issues need to be resolved first before the mapping can be realised in practice.

1.2.3 Encoding medical data by clinicians

Encoding medical data, e.g. based on the DT or SNOMED CT, is being experienced to restrict the expressiveness of clinicians compared to traditional free-text documentation methods. Encoding medical data was conventionally carried out by financial administrators and specialized medical

(10)

10

coders, based on notes doctors had written in free text in their medical records, often after the patient had been discharged. By shifting the encoding task to clinicians themselves, it is thought to increase the administrative burden at cost of the time doctors have available for patient care. Therefore, another challenge to be tackled before the APACHE-IV reasons for ICU admission can be derived is to make the encoding of medical data efficient and effective. Several guidelines10-12_exist

on implementing medical coding systems in the user interface (UI) of an EMR, however, evidence for these guidelines is limited.

1.3 Purpose and research questions

The purpose of this scientific research project is to investigate how APACHE-IV reasons for admission can be derived from routinely collected data in the PDMS. On the one hand, the aim is to update the existing mapping between SNOMED CT and APACHE-IV and to design classification rules. On the other hand, the aim is to improve the user interface for encoding diagnostic data in the EMR. Research questions:

 How can reasons for ICU admission from the APACHE-IV model be derived from DT-based data in the EMR?

 What is the significance of guidelines for the user interface that supports medical data encoding for the registration of diagnoses with the DT?

1.4 Approach and expected results

In order to answer these research questions, two subprojects have been carried out. The first project consisted of the update of the SNOMED-APACHE mapping and the development of classification rules to derive the APACHE-IV reason for ICU admission class from SNOMED CT concepts. The second project consisted of a controlled experiment with IC staff to test different UI configurations to enter diagnoses with the DT. A compliant UI was compared to a UI that is not

guideline-compliant but resembles the configuration of an existing system. The research project delivers the following expected results:

 Assessment of the applicability of a previously defined method to update the mappings between medical terminology systems, particularly the SNOMED-APACHE mapping

 A method to represent the mapping between SNOMED-APACHE following SNOMED CT standards

o Update of mapping from SNOMED CT to APACHE-IV with the July 2015 SNOMED CT version

o Classification rules to automatically derive APACHE-IV classes for trauma patients

 Evidence for guidelines to design a UI for terminology-based data entry coming from usability experiments with potential users

1.5 Outline of the thesis

In chapter 2 some background is provided about medical terminology systems in general and the APACHE-IV model in particular. Readers that are already familiar with these topics, can skip reading them. In chapter 3 the derivation of the APACHE-IV classification from data in the EMR is described. In chapter 4 the usability experiment with the DT at the ICU is reported. Finally, in chapter 5 and 6 the discussion and conclusions of the overall results are summarized and discussed.

(11)

11

2. Background

This chapter provides background information about medical terminology systems in general and the APACHE-IV model in particular for readers who are unfamiliar with any of these topics.

2.1 Medical terminology systems

2.1.1 The purpose of medical terminology systems

Currently, medical data such as a diagnosis of one patient may have to be registered multiple times by different people for different purposes. Each party may have their own format and requirements to encode the same diagnosis. In the Netherlands, in most hospitals, with variations, diagnoses are recorded redundantly by following persons and for the following purposes:

 By the doctor,

o in the electronic medical record (EMR) for purpose of direct patient care;

 By medical coders,

o using the International Classification of Diseases (ICD)13_{to produce (inter)national}

statistics (delivered to the LBZ14_{, by its acronym in Dutch “Landelijke Basisregistratie}

Ziekenhuiszorg”, meaning national basic registry hospital care);

 By financial administrators,

o in a DBC system15_{(Dutch acronym for “diagnosebehandelcombinatie” meaning}

diagnose treatment combination; a Dutch diagnose related groups - DRG like system) for reimbursement;

 By other clinicians,

o in their own separate systems, sometimes even within the same institution, o for clinical trials/research,

o in quality assurance systems, o for various other purposes.

Medical terminology systems have been developed to facilitate the explicit semantics and multiple use of data from the EMR. This means that the medical data is defined unambiguously and in a standardized format that can be processed by a computer. This allows exchange of medical data between clinicians and the reuse of medical data for auditing, quality improvement, administration, statistics, reimbursement, decision support and research. As a result the clinician only has to encode the medical data once and it does not have to be re-entered again in different forms by the same person or by other parties. This is not only more efficient, but also prevents errors that are introduced each time data is captured again.16

2.1.2 Different types of medical terminology systems

Our language consists of terms that we use to express concepts from our thinking about objects in reality.17_{The triangle of meaning or semiotic triangle in Figure 2 illustrates these relationships}

between terms, concepts and objects. ‘A terminology is a list of terms referring to concepts in a particular domain.’18_{A terminology is also a coding system when it uses codes to designate}

concepts.18_{In this section, interface terminologies, reference terminologies and aggregate}

(12)

12 Figure 2: Triangle of meaning or semiotic triangle17,18

In the Netherlands, a Dutch terminology Diagnosethesaurus (DT)6_{for diagnoses has been introduced.}

The DT is an interface terminology that assists medical specialists in the registration of diagnoses in an electronic format and in the display of diagnostic data in the EMR. Different terms may refer to the same concept, thereby the DT supports the use of synonyms. Each concept has an identifier (a ConceptID) to define it unambiguously. This identifier is meaningless and is only used to store and process the concept in the EMR. This way medical specialists are allowed to use their own jargon, while still using a standardized terminology. Terms also have their own identifiers too (TermIDs). For example, both DT terms ‘comotio cerebri’ with TermID 14436 and ‘hersenschudding’ with TermID 1952831434 (Latin and Dutch for “brain concussion”) designate the DT concept with the ConceptID 11783.

A part of DT is mapped to the reference terminology SNOMED CT7_{. A reference terminology is a more}

formal type of terminology used to store, retrieve and analyse clinical data19_{. SNOMED CT uses}

description logics to define concepts explicitly with relationships between concepts. This allows reasoning, such as classifying “Acute bacterial endocarditis” as a cardiovascular disorder. Each SNOMED CT term, concept and relationship has a unique identifier. SNOMED CT concepts will be designated in this thesis with their identifier and where possible with their fully specified name that includes a description and the semantic category it belongs to (such as disorder or organism).20_For

example, the above DT concept for brain concussion is mapped to the SNOMED CT concept

‘110030002 | Concussion injury of brain (disorder)’. In SNOMED CT this concept is defined as having the Associated morphology ‘708539008 | Concussive injury (morphologic abnormality)’ and Finding site ‘12738006 | Brain structure (body structure)’. It has the descriptions ‘174751018 | Brain concussion’, ‘202904019 | Commotio cerebri’, ‘345267014 | Concussion injury of brain’,

‘3034714010 | MTBI – Mild traumatic brain injury’ and ‘3034729012 | Mild traumatic brain injury’. It is also defined as belonging to the more general concepts ‘708540005 | Concussion injury of body structure (disorder)’ and ‘127295002 | Traumatic brain injury (disorder)’. The users of SNOMED CT can also compose their own concepts by combining existing SNOMED CT concepts and using the relationships that SNOMED CT provides. This is called as post-coordination. When concepts are already predefined in SNOMED CT, these are called pre-coordinated concepts.

An aggregate terminology, or classification system, is used to classify clinical concepts into classes. By using the hierarchies and relationships among concepts in SNOMED CT, concepts can be classified into aggregate terminologies through a mapping with SNOMED CT. The DT used this feature of SNOMED CT in order to get from the DT diagnostic concepts to aggregate terminologies ICD for statistics and DBC for reimbursement. The above mentioned DT term ‘hersenschudding’ as a concept for brain concussion would be classified as ‘S06.00 | Commotio cerebri, without open intracranial wound’ in the ICD for example. The DBC system uses specialist domains, disorders and procedures in order to classify health care provided into reimbursement classes. For example, in orthopaedics, the brain concussion would be classified as ‘3501 | Commotio cerebri’, while it would be classified in paediatrics as ‘3524 | Trauma capitis (commotio, contusion)’.

(13)

13

To summarize, an interface-reference-aggregate terminology mapping supports single data entry for multiple use. Figure 1 displays these relationships between the different types of medical coding systems and Table 1 summarizes the examples of different concepts and terms from different

terminologies to represent a brain concussion. DT, SNOMED CT or other terms can be used in various medical domains as an interface terminology to register medical data. These terms are mapped to the concepts of the DT and SNOMED CT as a reference terminology. From there multiple aggregate terminologies can be derived: ICD, DBC and other aggregate terminologies. In this research project, we are interested in deriving the APACHE-IV reasons for ICU admission classes from diagnoses encoded with the DT. In the APACHE-IV model, we want to classify the brain concussion as a ‘208 | Head (CNS) only trauma’.

Table 1: Registering a brain concussion in 5 different terminology systems

Terminology type Terminology system Concept or term

Interface DT 14436 | commotio cerebri

1952831434 | hersenschudding SNOMED CT 174751018 | Brain concussion

202904019 | Commotio cerebri

345267014 | Concussion injury of brain

3034714010 | MTBI – Mild traumatic brain injury 3034729012 | Mild traumatic brain injury

Reference DT 11783 | commotio cerebri

SNOMED CT 110030002 | Concussion injury of brain (disorder) Aggregate ICD10 S06.00 | Commotio cerebri, without open intracranial

wound

DBC (orthopaedics) 3501 | Commotio cerebri

DBC (paediatrics) 3524 | Trauma capitis (commotio, contusion) APACHE-IV 208 | Head (CNS) only trauma

2.2 APACHE model

2.2.1 Predictive scoring systems

In order to provide a prognosis, predictive scoring systems have been developed to estimate the severity of disease and predict the mortality of patients at the intensive care (IC) 21,22_{. Nowadays,}

these systems are also used for other purposes: to stratify patients in research, to facilitate decision making and to perform quality assurance.21_{Important predictive scoring systems are the Acute}

Physiologic and Chronic Health Evaluation (APACHE) model3_{, the Mortality Prediction Model}

(MPM)23_{, the Simplified Acute Physiologic Score (SAPS)}24_{and the Sequential Organ Failure}

Assessment (SOFA) score25_{. These systems use data such as demographics, diagnoses, and physiology}

and lab values. Within the Dutch National Intensive Care Evaluation (NICE) quality registry, the APACHE-II, APACHE-IV and SOFA scores are being kept.4_{There are several versions of the APACHE}

model, because the developers have been trying to improve its predictive performance over time as new technologies and treatment make other data becoming available. Studies have shown that the APACHE-IV model performs best according to predictive accuracy, while MPM can be a good alternative considering data collection requirements and costs.21

2.2.2 APACHE-IV reason for ICU admission classification

An important parameter in the APACHE-IV model is the reason for admission which is encoded by the APACHE-IV reason for IC unit (ICU) admission classification. There are n=445 different APACHE-IV reason for ICU admission classes.26_{The classes are organised into several groups that facilitate}

(14)

14

browsing. They are either medical, non-operative (n=225), such as “Anaphylaxis”, or procedural, post-operative (n=220), such as “Ablation or mapping of cardiac conduction pathway”. They are also classified into ten organ systems, such as cardiovascular, and otherwise trauma or transplantation classes. For example, “Anemia” is a non-operative hematological class and “Abcess/infection-cranial, surgery for” is a post-operative neurologic class. It includes “other not further specified” classes for those reasons for admission that cannot be categorized into the predetermined APACHE-IV classes, such as “Trauma medical, other” or “Skin surgery, other”. Each class has its own severity score based on historical data. 116 severity scores are distinguished.3_{When there are multiple classes that are}

applicable to one ICU admission, the class with the highest severity score is chosen. Table 2 lists the categories of severity scores for trauma classes. Table 3 gives examples of the head trauma classes with their severity scores in terms of a mortality coefficient and a length of stay coefficient.

2.2.3 Implicit APACHE-IV classification rules

There are classes that have implicit classification rules, such as “Extremity/face trauma” and

“Extremity/multiple trauma”. These are constructed by combining or clustering two separate trauma classes. For example, a patient might be admitted to the ICU with a brain concussion, zygoma, rib fractures and a lung contusion. From this information the “Head/chest trauma” class has to be derived, because brain concussion and zygoma are head traumata, while a rib fracture and contusion of both lungs are chest traumata. If the patient would have had a spinal trauma at the same time, it would rather be classified as a “Head/multiple trauma” and not as a “Chest/multiple trauma”, because the former has a higher severity score than the latter. If the patient would only have a brain concussion and a zygoma it would map to “Head (CNS) only trauma”. If the patient was admitted to the ICU after a surgery for this “Head/multiple trauma”, the admission diagnosis class would rather be “Head/multiple trauma, surgery for”.

Table 2: APACHE-IV trauma severity score classes3_{by trauma type, location, and number n of}

APACHE-IV reasons for ICU admission classes per severity score class

Trauma type Trauma location n

Trauma diagnoses

Trauma involving the head

Head trauma with either chest, abdomen, pelvis, or spine injury 4 Head trauma with extremity or facial trauma 2

Head trauma only 1

Head trauma with multiple other injuries 1

Trauma, chest and spine trauma 2

Trauma, spine only 1

Multiple trauma (excluding head trauma) 25

Trauma surgery Head trauma only 1

Multiple trauma sites including the head 7

Surgery for extremity trauma 1

Multiple trauma (excluding the head) 27

(15)

15

Table 3: APACHE-IV non-operative head trauma classes identifier id, description term and their severity classes APACHE-IV trauma severity class, mortality coefficient mort and length of stay coefficient los26

id Admission class APACHE-IV trauma severity class mort los

208 Head (CNS) only Head trauma only 0.596 0.834

209 Head/abdomen Head trauma with either chest, abdomen, pelvis, or spine injury

-0.372 2.129 210 Head/chest Head trauma with either chest, abdomen, pelvis, or spine

injury

-0.372 2.129 211 Head/extremity Head trauma with extremity or facial trauma -0.364 0.86 212 Head/face Head trauma with extremity or facial trauma -0.364 0.86 213 Head/multiple Head trauma with multiple other injuries -0.068 3.638 214 Head/pelvis Head trauma with either chest, abdomen, pelvis, or spine

injury

-0.372 2.129 215 Head/spinal Head trauma with either chest, abdomen, pelvis, or spine

injury

(16)

16

3. APACHE-IV classes derivation from data in the EMR

In this chapter, steps are taken in order to enable the automatic derivation of the APACHE-IV classes from data in the EMR, by applying and evaluating a framework to update terminology mappings to update the SNOMED-APACHE mapping and by developing classification rules.

Figure 3: The SNOMED CT-APACHE mapping

3.1 Introduction

In order to prevent redundant data entry of admission diagnoses at the IC a mapping between SNOMED CT and APACHE-IV is required. This will allow the derivation of the APACHE-IV reason for ICU admission from the data in the EMR, given that the data in the EMR are captured in SNOMED CT or an interface terminology that is mapped to SNOMED CT (see Figure

3). In 2007, a mapping between SNOMED CT and APACHE-IV was established with the July 2007 release of SNOMED CT, in order to create a subset of SNOMED CT for an interface terminology that could be used at the IC.8_{In this study, it was tried to merge the APACHE-IV classes into the SNOMED}

CT hierarchy, rather than define a pure mapping between SNOMED CT to APACHE-IV classes. More specifically, if an APACHE-IV class was defined by multiple SNOMED CT concepts, it was introduced into the SNOMED CT hierarchy, as is illustrated in Figure 4 by APACHE-IV class A. When an APACHE-IV class could be represented directly by one SNOMED CT concept, an APACHE-IV description was added for that SNOMED CT concept, as is illustrated by APACHE-IV class B in Figure 4. A problem with this approach is that while it was intended to be used as an interface terminology, and that the reference and aggregate terminology were all blended together. This made it hard to maintain and to use. Instead of this approach, we wanted to establish a new mapping where SNOMED CT and

APACHE-IV are not mixed together. For this purpose we wanted to only define mappings between SNOMED CT concepts and APACHE-IV classes, as is illustrated in Figure 5. We expect this to be easier to maintain and to apply in practice.

(17)

17

Figure 4: The 2011 SNOMED-APACHE mapping: SNOMED CT concepts (blue), descriptions of the APACHE classes (dark blue) and a newly introduced concept (light blue)

Figure 5: The 2015 SNOMED-APACHE mapping: SNOMED CT concepts (blue) and APACHE classes (dark blue)

As SNOMED CT evolves and a new release is published twice each year, the mapping may become outdated. Among other changes, terms or concepts are inactivated, new terms or concepts are introduced and sometimes even the concept model of SNOMED CT has changed. Therefore, the mapping between SNOMED CT and APACHE-IV has to be actualized in order to maintain an up-to-date and valid mapping between both terminologies. An upup-to-date of the 2007 mapping was carried out in 2011.9_{At the same time a framework to update mappings between terminologies was developed.}

In the current study, the update had to be carried out again in order to adapt the mapping to the SNOMED CT version of July 2015.

In the 2007 and 2011 mapping some problems were encountered regarding classification. These involved the trauma classes and classes that only had partial matches. The trauma classes have implicit classification rules (see section 2.1.3) that cannot be covered within a mapping. Therefore these rules still had to be designed. Furthermore, SNOMED CT does not handle “or”, “and”, “other”, and “unknown” classes well. These kind of APACHE-IV classes were only partially matched with SNOMED CT concepts, or new concepts with “and” and “or” in it had been introduced in them. The

(18)

18

other and unknown classes required classification rules as well, in order to determine unknown or other classes.

The purpose of this study is to enable the derivation of the APACHE-IV reason for ICU admission classes from SNOMED CT concepts.

 How can reasons for ICU admission classes from the APACHE-IV model be derived from SNOMED CT-based EMR data?

o Is the four-step maintenance process9_{sufficient to update the SNOMED-APACHE}

mapping? What additional steps are needed otherwise in order to realize the update?

 What part of the SNOMED-APACHE mapping from January 2011 has to be updated to the SNOMED CT version of July 2015?

o What format is required to support the SNOMED-APACHE mapping and classification?

 How can the SNOMED-APACHE mapping be migrated from its former format to the newly required format?

o What classification rules are needed to derive the APACHE-IV classes from the mapping?

 What classification rules are needed to derive the APACHE-IV trauma classification?

 What classification rules are needed to derive classes with “unknown” or “other”?

3.2 Materials

3.2.1 Required SNOMED CT file types for mapping

In this section we explain required file types that are used in this study. This information can be found in the SNOMED CT® Technical Implementation Guide20_{. The 2007 and 2011 SNOMED-APACHE}

mapping followed the original SNOMED CT Release Format, now known as SNOMED CT Release Format 1 (RF1). IHTSDO replaced this in January 2012 by SNOMED CT Release Format 2 (RF2). Both formats define the file structure of SNOMED CT releases and include the tables: concepts,

descriptions and relationships; but the structure and content of these tables have changed. Extensions upon SNOMED CT can be made following the same structure as RF2 and conventions to create identifiers. Identifiers consist of a namespace-identifier that is uniquely issued to

organisations to create their own components. For our purposes, we will use the namespace of Ronald Cornet, which has the identifier ‘1000151’. Each item of the extension has an extension item identifier that comes before the namespace identifier. These are followed by a partition identifier and a check digit. The partition identifiers that we need for our purposes are ‘10’ for concepts, ‘11’ for descriptions and ‘12’ for relationships. The check digits are determined by the Verhoeff algorithm and can be used to validate the SNOMED CT identifiers. For example: 11000151106 has extension item identifier ‘1’, namespace ‘1000151’, partition identifier ‘10’ and check digit ‘6’.

A refset is an abbreviation for reference set and is used in SNOMED CT to define additional properties and components associated with SNOMED CT. It can be used to define a subset of SNOMED CT for a particular purpose or define mapping with another terminology system. The “complex map refset” and “extended map refset” file types are specified to define mappings from SNOMED CT to other terminologies. In these mappings SNOMED CT concepts are taken as referenced components and linked to targets of the mapping. Identifiers for these mappings are Universally

(19)

19

Unique Identifiers (UUIDs). We used the extended map refset format to represent the update of the SNOMED-APACHE map.

3.2.2 The 2011 SNOMED-APACHE map

In this section, we describe the database of the 2011 mapping.9_{The MS Access database consisted of}

three tables following RF1: concepts (n=338), descriptions (n=658) and relationships (n=1343). Only the columns that were relevant are discussed here. Each table had their own primary key column to uniquely identify table entries, starting with ICC (signifying intensive care – IC – concept), ICD (signifying IC description) or ICR (signifying IC relationship) respectively. These identifiers had been introduced in the earlier mapping, in order to distinguish them from SNOMED CT concepts. In this way they formed an extension to SNOMED CT that was used to cover the APACHE-IV classification. Pre-coordinated mappings were represented by an entry in the descriptions table where the

ConceptId was a SNOMED CT concept and the text description contained a code with “AP4_” in front of it. Post-coordinated mappings were represented by an entry in the descriptions table where the ConceptId was an ICC code and the description contained “AP4_”. These concepts got an ICC identifier because these concepts were newly introduced (and not available in SNOMED CT). There were also other post-coordinated concepts that were part of the descriptions table, but did not have “AP4_” in the description: these were apparently used in post-coordination of other concepts. Table 4 gives examples of each of these concepts and how they were found in the database.

There were three types of relationships that we found in the relationships table. They were (A) relationships between SNOMED CT concepts themselves, (B) relationships between SNOMED CT and introduced ICC concepts and (C) relationships between ICC concepts themselves (see Figure 6 with corresponding letters A, B and C). These relationships were represented by combining their identifiers in a table row that was identified by a unique ICR code and a SNOMED CT relationship type. Examples of these three relationships are given in the Table 5 below. The descriptions of these ICC and SNOMED CT codes are not important in the case, the point is for this materials section to illustrate the database structure.

The concepts table consisted of post-coordinated concepts with their ConceptId and a fully specified name (different from the description table). You could expand the concept to see all the relationships where the concept was part of as ConceptId1. This is a known as cross-reference drop-down (a MS Access feature) with the relationships table where the concept was ConceptId1. Table 6 gives an example of such a concept. Note that not all APACHE-IV classes were part of the concepts table. Pre-coordinated concepts were only found in the descriptions table as descriptions of SNOMED CT concepts. This made it difficult to extract all APACHE-IV classes at once, because that could only be carried out with a free text search for “AP4” in the descriptions table.

Table 4: Examples of types of rows in the descriptions table in the 2011 SNOMED-APACHE map

Type DescriptionId Conceptid Term

Pre-coordinated APACHE-IV class

ICD002 44103008 Ventricular Rhythm disturbance (AP4_33)

Post-coordinated APACHE-IV class

ICD003 ICC004 Ablation or mapping of cardiac conduction pathway (AP4_226) Used in post-coordination ICD034 ICC0039 Complications of previous

(20)

20

Figure 6: Types of relationships between SNOMED CT and APACHE-IV

Table 5: Examples of types of rows of the relationships table as found in the 2011 SNOMED-APACHE mapping

Type RelationshipId ConceptId1 RelationshipType ConceptId2

A: Existing SNOMED CT relationship ICR1240 44103008 116680003 49601007 B: Post-coordination relationship

ICR027 ICC0015 363702006 ICC0014

C: Post-coordination relationship

ICR008 ICC004 116680003 64915003

Table 6: Example of concepts table as found in the 2011 SNOMED-APACHE mapping

Rows Columns

Concepts table entry ConceptId FullySpecifiedName

ICC0011 Surgery for cranial abscess or infection (AP4_354)

Linked relationships to above concepts table entry

RelationshipId RelationshipType ConceptId2

ICR018 116680003 410771003

ICR019 363702006 27614006

ICR654 116680003 16545005

3.3 Method

Fincan9_{developed a framework for the maintenance of clinical terminology mappings. She applied}

this framework to update the mapping of Bakhshi-Raiez8_{between SNOMED CT and APACHE-IV from}

2007 to 2011. In this thesis we used the same method and materials to update the mapping based onto the July 2015 SNOMED CT version. The framework consisted of four steps. A description logic (DL) reasoner, called SNOB, was used to carry out steps three and four. However, currently, this reasoner is not available anymore.27_{Therefore we could not carry out these steps in the same way in}

this research project. Alternatively, we found another way to carry out these steps partly, in the context of the migration of the database to the new format. Furthermore, we added a step for the database revision, because the wanted to represent the mapping differently (see Figure 4 and 5) and the release format of SNOMED CT had changed (to RF2). Moreover, we carried out extra steps to define the classification rules and the design of the APACHE-IV class derivation process. These steps were necessary in order to complete the derivation of the APACHE-IV classes, because the mapping alone was not sufficient for this purpose. We used a MySQL database (version 5.6.27) with

(21)

21

phpMyAdmin (version 4.0.10) in order to store and operate the new database. We imported the MS Access database in this other database directly. Each step will be explained below and is summarized in Table 7 at the end of this section.

3.3.1 Replace inactive concepts

The first step was the identification of SNOMED CT concepts that had become inactive since the last update.9_{We identified these by taking the SQL “union” of all SNOMED CT concepts found in the}

original database and returning those that have an inactive status in the current SNOMED CT release. The inactive concepts were replaced by alternative concepts, based on suggestions for equivalent concepts by SNOMED CT itself and based on the role the concepts played in the mapping. Equivalent concepts were found with the SNOMED CT browser from IHTSDO28_.

3.3.2 Replace relations that do not comply with concept model

The second step involved checking the compliance of post-coordinated concepts with regard to the concept model.9_{In the current study, we carried out this step by checking the range and the domain}

of each relationship, following the SNOMED CT Technical Implementation Guide19_{. SNOMED CT}

specifies what type of domain and range every type of relationship is allowed to have: the domain is the type of source concept and the range is the type of destination concept of the relationship. In order to test whether the concepts complied to these, we used the transitive closure file. This file contains the relationships of all SNOMED CT concepts with all their parent and ancestor concepts. It can thereby be used determine whether concepts are a subtype or a supertype of each other. For example, the relationship ‘363704007 | Procedure site’ is part of the domain ‘71388002 | Procedure’ and has the range ‘442083009 | Anatomical or acquired body structure’. With the transitive closure file we can test whether concepts in this relationship are subtypes of procedures and anatomical body structures or acquired body structures. Concepts that did not fall in the domain or range had to be replaced by other relationships based on the role they played in the mapping.

3.3.3 Database revision

The descriptions table contained fields with the description as well as the code of APACHE-IV classes in one free text column. This had to be normalized: that is, the code and the description have to be stored in a separate columns. These descriptions were linked to a concept identifier in the

descriptions table. When this identifier was a SNOMED CT concept, it was taken as a pre-coordinated concept; when it was linked to an ICC concept, it was taken as a post-coordinated concept. The pre-coordinated concepts can be taken directly in the extended map refset. We generated the UUIDs for the extended map in MS Excel.29

The concepts in the concepts table were categorized into different groups. The traumata will be addressed in 3.3.6. The AND, OR, NOT and OTHER terms are addressed in section 3.3.5. The concepts that remain are post-coordinated concepts that will be addressed in section 3.3.4 by specifying them in a SNOMED CT extension.

The relationships in the relationships table were also categorized into different groups. Relationships between SNOMED CT concepts, relationships between SNOMED CT concepts and APACHE-IV classes, relationships between SNOMED CT extension concepts and SNOMED CT concepts and relationships between APACHE-IV classes and APACHE-IV classes.

3.3.4 Replace post-coordinated concepts by pre-coordinated concepts

The fourth step was the assessment of post-coordinated concepts, to check if there are pre-coordinated concepts that were introduced since the old SNOMED CT version and could replace these post-coordinated concepts in the new mapping version.9_{As has been mentioned above, this}

(22)

22

step had been carried out before with a description logic reasoner that was not available anymore at the time of the current study. Therefore these steps were skipped in this study. Alternatively, the concepts that were identified in the database revision step 3 as SNOMED extension are actually taken as SNOMED CT concepts in the SNOMED CT extension. That way these post-coordinated concepts are given the status of pre-coordinated concepts. The identifiers were generated based on the conventions explained above in section 3.2.2 and the check digits of these identifiers were determined with the Verhoeff algorithm20_{in Visual Basic for Applications in MS Excel.}

The classes with “and” (conjunctions) or “or” (disjunctions) will be addressed in this step as well. In terminology systems, these are often confused and actually are used to mean the same thing. It is not meant as a logical AND or logical OR operator, but rather as a plus (+), meaning they include any or all that are listed in the conjunction.30_{In the old database, such APACHE-IV classes were mapped}

by introducing a new concept with an “and” or an “or”. For instance, the APACHE-IV class ‘110 | Thyroidectomy and parathyroidectomy’ was mapped by creating a post-coordinated concept for it and giving it the description ‘Thyroidectomy and parathyroidectomy (AP4_110)’. In the post-coordination is was stated that it had an ‘116680003 | Is a’ relationship with both ‘53304009 | Parathyroidectomy (procedure)’ and an ‘116680003 | Is a’ relationship with ‘13619001 |

Thyroidectomy (procedure)’. This is displayed in Figure 7. In the new approach we will drop these relationships and post-coordinated concepts and replace them by a mapping relationship of each concept to an APACHE-IV class.

Figure 7: Example of the mapping of conjunctions (APACHE-IV classes that are actually combinations of different concepts), with SNOMED CT concepts in blue, a newly introduced concept in light blue and an APACHE-IV class in dark blue

3.3.5 Replace partial matches by complete matches

The fourth step was the completion of partial matches9_{, and could not be carried out either, due to}

the unavailability of the description logic reasoner. However, many of these partial matches are due to problems with “other” and “unknown” APACHE-IV classes. An example is the class ’37 | Sepsis, other’. In this step therefore, we resolved these problems by creating classification rules to classify concepts into “other” or “unknown” classes. We used pseudo-code with IF-THEN-ELSE rules to define the classification rules. This is not a real programming code, but can be used to define an algorithm more formally and allows it to be translated in different programming languages and

(23)

23

3.3.6 Define classification rules for trauma classes

The trauma classes are split into non-operative or post-operative, like other classes, and are combinations of 7 body parts and one “other” class. In this step we defined classification rules to derive the APACHE-IV trauma classes from the 7 body parts. We also used IF-THEN-ELSE pseudo-code to define these classification rules.

3.3.7 Design the APACHE-IV derivation process

We designed the process of the APACHE-IV derivation from data in the EMR using a UML (Unified Modeling Language)31_{process diagram.}

Table 7: Overview of stepwise method, the steps with * are taken from the framework to update terminology mappings of the previous update9

# Step Approach

1* Replace inactive concepts9 _{Left join the union of all SNOMED CT concepts in the database}

with all SNOMED CT concepts in SNOMED CT. Identify concepts that were invalid as those that did not join at all, and identify concepts that were inactivated by their active status in the new SNOMED CT version. Replace concepts based on the suggestions by SNOMED CT itself and on the place in the SNOMED-APACHE mapping (by analysing their relationships).

2* Replace relations that do not comply with concept model9

Carry out a domain and a range check of all relationships in the database.

3 Database revision Normalise the database by (1) separating text and codes into separate columns, (2) separating SNOMED CT concepts and APACHE-IV classes, (3) separating SNOMED CT relationships from mapping relationships.

4* Replace post-coordinated concepts by pre-coordinated concepts9

Check all post-coordinated concepts to determine if they can be replaced by newly introduced pre-coordinated concepts. We did not carry out this step with a DL-reasoner. Instead: Identify concepts that were supposed to be missing in SNOMED CT and define them as pre-coordinated concepts in the

extension. 5* Replace partial matches by

complete matches9

We did not carry out this step with a DL-reasoner.

Replace partial matches for the “other” and “unknown” classes by taking them outside of the mapping and solving the problem in the classification.

6 Design classification rules for trauma classes

Make classification rules by combining body parts that are used in trauma classes.

7 Design the derivation process

Use a UML process diagram to describe the derivation of the APACHE-IV classes from data in the medical record.

3.4 Results

3.4.1 Replace inactive concepts

We identified three SNOMED CT concepts in the SNOMED-APACHE mapping that had been

inactivated between January 2011 and July 2015 and one invalid SNOMED CT code that did not exist. Based on suggestions by SNOMED CT for alternative equivalent concepts, and relationships with the APACHE-IV classes, replacements have been chosen. The concepts that were inactivated are listed in Table 8. The relationships these concepts were involved in are listed in Table 9 and the descriptions in Table 10.

(24)

24

‘123397009 | Injury of anatomical site (disorder)’ was only found in the relationships table. There it was stated that ‘417746004 | Traumatic injury (disorder)’ has an ‘116680003 | Is a’ relationship with ‘123397009 | Injury of anatomical site (disorder)’ (see Table 9). The concept ‘417746004 | Traumatic injury (disorder)’ was used to map the APACHE-IV class ‘225 | Trauma medical, other’ (see Table 10). It was decided to drop the inactivated term and this relationship altogether because it is not part of a post-coordinated term and therefore not necessary in the mapping.

‘26174007 | Primary pulmonary hypertension (disorder)’ was used in the relationships table as having an ‘116680003 | Is a’ relationship with ‘50043002 | Disorder of respiratory system (disorder)’ (see Table 9). It was mapped to the APACHE-IV class ‘164 | Primary/idiopathic pulmonary

hypertension’ (see Table 10). Both suggested equivalent concepts were chosen to map to this APACHE-IV class (see Table 8), because APACHE-IV does not seem to distinguish between these concepts. Primary pulmonary hypertension used in the past to cover both new variants of the term.32

The relationship with ‘50043002 | Disorder of respiratory system (disorder)’, however, was not necessary and therefore dropped.

‘280717001 | Spinal structure (body structure)’ was used in four relationships to define spinal trauma classes (see Table 9). These trauma classes distinguish several body parts, of which the spine is one particular one, distinguished from the directly attached structures such as chest or abdomen. Therefore, from the possible equivalents ‘421060004 | Structure of vertebral column (body

structure)’ was chosen because it specifically refers to the spine and not the region around it. Also one concept was found to have an invalid code. This invalid code was found to have an ‘116680003 | Is a’ relationship with ‘ICC232 | Sedatives, hypnotics, antipsychotics or

benzodiazepines overdose (AP4_144)’. The relationships that this APACHE-IV class has in the

database are listed in Table 11. This APACHE-IV class again was defined with overdoses by sedatives, hypnotics and benzodiazepines, while only antipsychotics was not covered (apparently it was a partial mapping). However, from the change log it appeared that it was not covered before either. The relationship was dropped because it did not serve a necessary purpose in the database. Table 8: SNOMED CT concepts used in mapping that are inactive in the new version

Inactive concept Possible equivalents28 _Replacement _n

123397009 | Injury of anatomical site (disorder)

‘609336008 | Traumatic injury by site (disorder)’ or ‘609411003 | Traumatic and/or non-traumatic injury of anatomical site (disorder)’ Dropped 1 26174007 | Primary pulmonary hypertension (disorder)

‘697897003 | Heritable pulmonary arterial hypertension (disorder)’ or

‘697898008 | Idiopathic pulmonary arterial hypertension (disorder)’

‘697897003 | Heritable pulmonary arterial hypertension (disorder)’ and

‘697898008 | Idiopathic pulmonary arterial hypertension (disorder)’

1

280717001 | Spinal structure (body structure)

‘421060004 | Structure of vertebral column (body structure)’ or

‘53418001 | Structure of vertebral region of back (body structure)’

‘421060004 | Structure of

vertebral column (body structure)’ 4

(25)

25

Table 9: Relationships of inactivated terms in 2011 database

Relationship Concept 1 Relationship

ICR304 ICC183 | Surgery for abdomen/spinal trauma 405813007 | Procedure site – Direct 280717001 | Spinal structure (body structure) Replaced in classification ICR324 ICC188 | Surgery for

chest/spinal trauma 405813007 | Procedure site – Direct 280717001 | Spinal structure (body structure) Replaced in classification ICR364 ICC199 | Surgery for

head (central nervous system)/ spinal trauma

405813007 | Procedure site – Direct 280717001 | Spinal structure (body structure) Replaced in classification ICR380 ICC203 | Surgery for

pelvis/spinal trauma 405813007 | Procedure site – Direct 280717001 | Spinal structure (body structure) Replaced in classification

Table 10: Concepts involved in inactivated terms mapped to APACHE-IV

DescriptionID SNOMED CT Concept Database description

ICD351 417746004 | Traumatic injury (disorder) Trauma (AP4_225) ICD171 26174007 | Primary pulmonary

hypertension (disorder)

Primary/idiopathic pulmonary hypertension (AP4_164)

Table 11: Relationships of APACHE-IV class that the found invalid term mapped to

Relationship Concept 1 Relationship Type Concept 2

ICR430 ICC232 | Sedatives,

hypnotics, antipsychotics or benzodiazepines overdose (AP4_144)

116680003 | Is a 295808006 | Overdose of drug groups primarily affecting the central nervous system (disorder)

ICR542 296015009 | Sedative overdose (disorder)

116680003 | Is a ICC232 | Sedatives, hypnotics, antipsychotics or

benzodiazepines overdose (AP4_144)

ICR543 296053004 | Benzodiazepine overdose (disorder)

116680003 | Is a ICC232 | Sedatives, hypnotics, antipsychotics or

ICR549 ICC232 | Sedatives,

hypnotics, antipsychotics or benzodiazepines overdose (AP4_144)

116680003 | Is a 7895008 | Poisoning by drug AND/OR medicinal substance (disorder)

(26)

26

overdose (disorder) antipsychotics or

ICR1517 296016009 | ??? 116680003 | Is a ICC232 | Sedatives, hypnotics, antipsychotics or

3.4.2 Replace relations that do not comply with concept model

In this step we checked whether the relationships that were found in the old database complied to the allowed domain and range. The domain check did not identify any incorrect relationships. But the range check returned 7 relationships that were out of range. They are listed in Table 12. Four of these referred to ‘280717001 | Spinal structure (body structure)’ as a ‘405813007 | Procedure site – Direct’. These were found because they referred to an inactivated concept, as has been shown in the previous paragraph. This method therefore can also be used to return inactivated concepts.

Table 12: Relationships that do not comply to the SNOMED CT concept model based on range check

Relationship Source Concept Relationship Type

Concept 2 n Decision

ICR1515 ICC257 | Sepsis unknown 363713009 | Has interpretation 128601007 | Infectious disease of lung (disorder) 1 Dropped ICR1514 ICC254 | Uncontrolled hypertension 363713009 | Has interpretation 19032002 | Uncontrolled (qualifier value) 1 Dropped, needs alternative in later revision See 3.4.1 See 3.4.1 405813007 | Procedure site – Direct 280717001 | Spinal structure (body structure) 4 See 3.4.1

ICR1398 ICC376 | APACHE IV medical disorder 42752001| Due to 71388002 | Procedure (procedure) 1 Dropped

The ‘363713009 | Has interpretation’ relationship has an allowed range of only ‘260245000 | Findings values’. Neither the concept ‘128601007 | Infectious disease of lung (disorder)’, nor the concept ‘19032002 | Uncontrolled (qualifier value)’ is a findings values concept, and therefore this these relationships were not allowed.

‘ICC257 | Sepsis unknown’ was found to be mapped with this relationship to ‘128601007 | Infectious disease of lung (disorder)’. However, a sepsis is not always a lung disease. It seemed to be mistaken. It was mapped as well as ‘91302008 | Sepsis (disorder)’. This relation was dropped, because it was unclear why it was in the database and because the unknown classes will be addressed through the classification rules (see section 3.4.5).

‘ICC254 | Uncontrolled hypertension’ was found to be mapped as having the interpretation of ‘19032002 | Uncontrolled (qualifier value)’ and having an ‘Is a’ relationship with ‘38341003 |

Hypertensive disorder, systemic arterial (disorder)’. It is not clear what concepts can be used instead to define the class. This should be addressed in another project, to review all mappings and the representation of APACHE-IV classes in SNOMED CT concepts, clinically (if it is medically valid) and semantically (regarding their meaning). That was out of scope of the current study.

(27)

27

The ‘42752001 | Due to’ relationship has an allowed range of only ‘404684003 | Clinical Finding (finding)’ or ‘272379006 | Event (event)’. However, the ‘71388002 | Procedure (procedure)’ is neither of these. It should rather be mapped with a ‘363702006 | Has focus (attribute)’ or ‘47429007 | Associated with (attribute)’ relationship, where ‘71388002 | Procedure (procedure)’ is an allowed value within the range. It is not necessary for the SNOMED-APACHE mapping and will therefore be dropped.

3.4.3 Database revision

A table with all the APACHE-IV classes, their APACHE-IV codes, ConceptIds and descriptions was made by separating the code from the description of the classes. Of all 455 APACHE-IV classes, 246 classes were directly linked to SNOMED CT concepts and thus are pre-coordinated terms; while 199 classes were linked to concepts defined in the mapping itself (ICC) and were thus post-coordinated. The post-coordinated concepts were ranked into categories depending on whether they are: (1) conjunctions or disjunctions, (2) trauma categories, (3) meta concepts, (4) and in other cases potentially new SNOMED CT concepts. It was assumed that conjunctions were those concepts with “and” or “or” in their description. Later we found that there might be more conjunctions that are overlooked this way and this has to be checked another in a next review round. See Table 13. The SNOMED CT concepts are already part of SNOMED CT and therefore do not have to be included in the SNOMED CT extension. The conjunctions and disjunctions from the APACHE-IV classification had been included in the 2011 mapping as an extension, but will now be mapped separately, directly from the SNOMED CT subclasses to the APACHE-IV classes, as is explained and illustrated in Figure 7 in the method section above. The trauma classes have been isolated separately as well, because they will be handled in step 6 to define classification rules. Furthermore, there were some meta concepts, like an APACHE-IV code attribute. These concepts were not necessary for the new migration and could thus be left out.

Table 13: Categories of concepts found in the 2011 concepts table that were identified to separate them for different steps in the update of the mapping

Type ConceptId

e.g.

FullySpecifiedName, e.g.

n

Potentially new terms ICC0012 Surgery for arteriovenous malformation (AP4_356) 152

Trauma ICC156 Extremity only trauma (AP4_203) 137

Conjunction or disjunction

ICC0011 Surgery for cranial abscess or infection (AP4_354) 45

Meta term ICC001 APACHE IV code (attribute) 4

Total 338

See Figure 8 and Table 14 for the different types of relationships that were distinguished and found in the database. The relationships (A) among SNOMED CT concepts (n=195) are already part of SNOMED CT and can thus be left out. Only n=9 of these are actually found in SNOMED CT. We validated the rest of them with the transitive closure table. The relationships between extension concepts (n=23), denoted with a B below, and the relationships between concepts in the extension and those SNOMED CT itself (n=328), denoted with a C below, will become part of relationships in the SNOMED CT extension. The relationships between SNOMED CT or the extension and APACHE-IV (n=335), denoted as a D below, will form the mapping of SNOMED CT to APACHE-IV. The

Terminology system-based data encoding for intensive care: Deriving the APACHE-IV reasons for ICU admission classification through SNOMED CT and optimizing the user interface for diagnostic data entry

Terminology system-based data encoding

for intensive care

Terminology system-based data encoding

for intensive care

Contents

Summary

Dutch Summary: Samenvatting

Keywords

1. Introduction

1.1 Medical domain context: intensive care

1.2 Problem definition

1.2.1 Redundant diagnostic data entry

1.2.2 Incomplete SNOMED-APACHE mapping

1.2.3 Encoding medical data by clinicians

1.3 Purpose and research questions

1.4 Approach and expected results

1.5 Outline of the thesis

2. Background

2.1 Medical terminology systems

2.1.1 The purpose of medical terminology systems

2.1.2 Different types of medical terminology systems

2.2 APACHE model

2.2.1 Predictive scoring systems

2.2.2 APACHE-IV reason for ICU admission classification

2.2.3 Implicit APACHE-IV classification rules

3. APACHE-IV classes derivation from data in the EMR

3.1 Introduction

3.2 Materials

3.2.1 Required SNOMED CT file types for mapping

3.2.2 The 2011 SNOMED-APACHE map

3.3 Method

3.3.1 Replace inactive concepts

3.3.2 Replace relations that do not comply with concept model

3.3.3 Database revision

3.3.4 Replace post-coordinated concepts by pre-coordinated concepts

3.3.5 Replace partial matches by complete matches

3.3.6 Define classification rules for trauma classes

3.3.7 Design the APACHE-IV derivation process

3.4 Results

3.4.1 Replace inactive concepts

3.4.2 Replace relations that do not comply with concept model

3.4.3 Database revision