STANDARDIZATION OF MAPPING OF DUTCH DETAILED CLINICAL MODELS TO THE LOINCâ SNOMED CT HARMONIZED CONCEPT MODEL TO FACILITATE INTEROPERABILITY

(1)

1

STANDARDIZATION OF MAPPING OF

DUTCH DETAILED CLINICAL MODELS TO

THE LOINC–SNOMED CT HARMONIZED

CONCEPT MODEL TO FACILITATE

INTEROPERABILITY

A THESIS SUBMITTED TO THE UNIVERSITY OF AMSTERDAM

FOR THE DEGREE OF MASTER OF MEDICAL INFORMATICS

2020

(2)

2

Summary

To tackle the issue of interoperability in the Dutch healthcare system, clinical information was structured in the form of a finite number of clinical models referred to as Clinical Building Blocks (Clinical Building Blocks (CBBs). These CBBs were expressed as technology-agnostic detailed clinical models DCMs in which a care-related concept was described in an Entity-Attribute-Value (EAV) model and annotated with LOINC and SNOMED CT. Nevertheless, their process of terminology binding remained marred with various inconsistencies and gaps.

This thesis sought to address the flaws in the terminology binding process through the development of a standardized methodology for term binding of data elements of Dutch DCMs to the LOINC-SNOMED CT harmonized concept model.

Of the 100 created, 5 molecularly clustered DCMs from the “Measurements” and “Scale/Assessment score” groups were selected. Relying on the guidelines on the combined use of LOINC and SNOMED CT, the SNOMED CT compositional grammar, and rules for matching to a LOINC panel, a standard framework for terminology binding of DCM’s data elements to the LOINC-SNOMED CT harmonized concept model. Application of the developed framework improved terminology mapping in all studied DCMs and allowed the formulation of a number of generic DCM fragments with corresponding SNOMED CT semantics that could, each independently be used for terminology binding.

(5)

5

Samenvatting

Om interoperabiliteit in het Nederlandse zorgsysteem te realiseren is een relatief gering aantal klinische informatiemodellen ontwikkeld, de zogeheten zorginformatiebouwstenen (ZIBs). Deze bouwstenen worden gerepresenteerd als technologie-agnostische Detailed Clinical Models (DCMs), waarin een zorg-gerelateerd concept wordt beschreven aan de ahnd van een UML-gebaseerd Entity-Attribute-Value (EAV) model, geannoteerd aan de hand van LOINC en SNOMED CT. Desalniettemin heeft het relateren van terminologie en informatiemodel, het zogeheten “terminology-binding”, geresulteerd in inconsistenties en omissies.

Deze thesis poogt deze onvolkomenheden te adresseren door een gestandaardiseerde methodologie te ontwikkelen voor terminology-binding van data elementen in Nederlandse DCMs, gebaseerd op het geharmoniseerde concept model van LOINC en SNOMED CT.

Uit de 100 ontwikkelde DCMs zijn 5 moleculair geclusterde DCMs geselecteerd uit de groepen Meting en Scorelijsten. Op basis van de richtlijnen rond het gecombineerd gebruik van LOINC en SNOMED CT, de “compositional grammar” van SNOMED CT (d.w.z. de taal waarin smengestelde concepten worden uitgedrukt) en regels om het meest geschikte LOINC panel te bepalen is een gestandaardiseerd raamwerk ontwikkeld voor het representeren van de data elementen in DCMs aan de hand van het geharmoniseerde LOINC-SNOMED CT conceptmodel. Toepassing van dit raamwerk heeft bij alle geanalyseerde DCMs geresulteerd in een verbeterde koppeling met de terminologieën en heeft geleid tot het formuleren van een aantal generieke DCM-fragmenten met bijbehorende semantiek op basis van SNOMED CT die onafhankelijk van elkaar kunnen worden gebruikt voor terminology binding.

(6)

6

Chapter 1 Introduction

As Information and Communication Technologies (ICTs) claimed a central role in the healthcare domain, and with the widespread implementation of electronic health records (EHRs), there has been significant improvement in the collection of patients’ data and the subsequent provided direct care [1]. It became also evident that this primary use of data was insufficient to answer the increased demands for better health care delivery. Pressured by various demographic, socioeconomic, and technological changes, health care institutions increased their reliance on secondary data use to optimize continuity of care, decision support, quality measurements, research, and to assure their financial sustainability [2].

Nevertheless, the proliferation of heterogeneous EHR systems became a major deterrent towards the vision of interoperable clinical information that can be shared, aggregated, and queried in a uniform and transparent way at any time and at any place [3]. Mechanisms for structuring clinical information lacked common standards within and between healthcare institutions [4,5] The collection, representation, storage, transfer. and processing of clinical information in the absence of a common vocabulary could be inaccurately interpreted, and lead to wrong clinical decisions [5,6].

Defining how clinical information is structured in the systems of a healthcare institution and guaranteeing a structural consistency between different EHR systems as well as the adoption of a common medical terminology became the fundamentals of information correctness. The breadth of knowledge found within the medical record could be effectively exploited with an accurate and reliable communication among computers through a semantically normalized information model [7].

In the Netherlands, once these semantic and structural specifications for the standardization of information used in the care process were defined, they were also established in the form of Health and Care Information models (HCIM), or Clinical Building Blocks (CBBs) (Zorginformatiebouwstenen or zibs in Dutch). To achieve a technology-independent representation of clinical knowledge, DCMs were initially modeled into a generic information model using a UML format and then to the HL7 FHIR template in an attempt to improve their semantics. Data elements were annotated with SNOMED CT, LOINC and coded value lists. Nevertheless, these resources remained semantically weak due to issues inherent to FHIR and various inconsistencies and gaps in their terminology binding.

This thesis tackled the complex subject of interoperability of healthcare systems. More specifically, it sought to answer the question whether a standardized methodology can be developed for term binding of data elements of Dutch detailed clinical models to the LOINC-SNOMED CT harmonized concept model to achieve a coded data of reliable quality.

(7)

7

Chapter 2 Background

2.1 Interoperability in the Healthcare Environment

Data sharing across clinicians, laboratories, hospitals, and other healthcare related institutions is taking a central role in the effective delivery of healthcare [8]. Nevertheless, the healthcare environment is characterized by information silos that are distributed, autonomous, structurally diverse, and semantically heterogeneous [9]. Connecting the different health information models (HIMs) in a coordinated manner that allows the exchange of data without loss of meaning, is becoming imperative to access relevant and accurate clinical information [10].

Hence, interoperability in healthcare is critical in achieving the goal of optimizing health by providing seamless access to the right clinical information needed irrespective of the data’s origin or destination or the applications used. The Healthcare Information and Management Systems Society (HIMSS) defines 4 different degrees of interoperability that are differentiated by the health data exchange architectures and standards applied [11]:

1. Foundational interoperability is the establishment of the interconnectivity requirements that allows sharing and receiving data between 2 systems.

2. Structural interoperability addresses the structure or format of the exchanged data. By adopting standards to the different HISs on how to parse the content exchanged, uniform movement of healthcare data from one system to another can established. A defined syntax preserves meaning of the data and ensures its interpretation at the data field level.

3. Semantic interoperability is the ability of information systems to interpret and use the exchanged information. It relies on applying data model and terminology standards to generate a structured message that contains standardized and coded data.

4. Organizational interoperability adds a non-technical aspect to the technical components. It includes shared process definitions and inter-participant workflow orchestration. Defined clear policies combined with social and organizational components ensure a secure and timely exchange and use of data within and across organizations as well as between individuals.

(8)

8

2.2 Interoperability Status

Foundational interoperability has been successfully addressed through electronic data exchange in understood formats. Syntactic or technical interoperability has been provided by the Health Level 7 (HL7) series of standards that defined how information is packaged and communicated between systems [10]. Health-related information is exchanged as a message with a specific format whose different structural parts are defined [12]. Nevertheless, multiple standards for the content of the HL7 messages were developed that eventually lead to a risk of loss of meaning during message translation among the different HL7 standards [13].

Multiple barriers still impede achieving semantic interoperability of clinical information. These obstacles either relate to the various actors, work processes, and structure of healthcare or to the challenges encountered in the health informatics domain in data representation [14, 15, 16, 17].

1- General healthcare domain challenges: • Healthcare professionals-related:

Collected data is subject to local workflow and clinical practice of healthcare professionals. It is also dependent on the professional’s own perception of the level of detail needed in documentation of clinical information and one’s time availability for this activity. Agreement on the clinical information to be collected in a specific clinical domain is a cumbersome process.

• Complexity of the healthcare sector:

Many actors are involved in a patient’s treatment with each generating a set of clinical information that is of common interest. Administrative and organizational information is also created. The exchange and understanding of the totality of information is crucial for optimal healthcare delivery in a process dependent on the willingness of care-givers to share this information and compatibility of systems’ software.

• Standardization inconsistencies in work processes:

While standardized processes are applied in healthcare, they are often too general and locally interpreted and implemented. Furthermore, many standards exist in healthcare and institutions conform usually to a number of them rather than just one standard. Ultimately, confusion arises with multiple standards, and uniformity is not achieved.

• Legal issues:

Difficult questions on the privacy, security, and ownership of the data remain unanswered. 2- Health informatics domain specific challenges:

• Legacy systems:

Initial electronic medical record systems have limited interoperability capabilities as they were built prior to the introduction of common standards and for the purpose of performing a particular task in a particular institution.

• Heterogeneous structures of clinical information models (CIMs):

In the absence of a common methodology or specifications that direct clinical information modelers on the development of CIMs, the same clinical information is represented with different models. Although each of these CIMs would be semantically correct, clinical information can’t be exchanged as the used systems can’t communicate with each other. • Incompatibility of clinical terminologies and ontologies:

(9)

9

For computer systems to effectively exchange information and understand one another, they must use the same terminology and ontology or mutually compatible ones. However, there has been exponential growth of heterogeneous terminologies and ontologies in healthcare resulting in one clinical concept to have multiple representations.

• Ambiguous clinical terms:

Some collected clinical information lack consensus over their exact definition. Integrating such information from different healthcare providers presents a serious computational challenge.

Despite these early hurdles, the motivation to reach semantic interoperability was unaltered. Its benefits in healthcare have been theorized with high expectations on various aspects of healthcare [15, 17,18]:

• Establishing a continuum of healthcare by facilitating access to a patient’s fragmented clinical information, irrespective of the patient’s and the healthcare giver’s location or data storage in heterogeneous systems.

• Accelerating knowledge discovery by allowing the collection, integration and analysis of large volume data from large populations and from different countries.

• Ensuring the appropriate interpretation of the medical terminology upon execution of all collaborating systems for diagnosis and decision making.

• Reducing the occurrence of medical errors by eliminating inappropriate clinical information through intelligible data formatting for both its structure and content by computer systems.

• Integration of clinical information from autonomously developed applications within a patient’s EHR or across the various organizations within the healthcare system.

• Reducing healthcare cost through the effective sharing and communication of data, information, and knowledge across the different stakeholders.

2.3 The Dutch Initiative: Clinical Building Blocks (CBBs)

As the philosophy that governed healthcare was stretched beyond the simple use of the collected patient data in a specific healthcare institution, the Dutch healthcare domain found itself under pressure to achieve new requirements that would answer increasing demands of patients, clinicians, researchers, and administrators:

• Dutch patients were increasingly more involved in the management of their own health issues. Shared decision making was gaining popularity resulting in a change of dynamics between patients and clinicians.

• In a healthcare system where the general practitioner (GP) is the gateway of healthcare such as the Dutch healthcare system, the exchange and sharing of a patient’s clinical information between the GP and other healthcare institution became core for a successful continuity of care.

• There was a constant expectation from the public for better delivery and quality of healthcare, making it inevitable to resort to the analysis of large amounts of clinical data to determine the best clinical practice and improve quality metrics.

• The need to control increased costs of healthcare became critical to guarantee the sustainability of the current system.

(10)

10

Key to the success of these objectives rested on one principle. No matter the environment where clinical data was collected, it should be possible to use that data in any other environment. Nevertheless, it was clear that after 10 years of EHR development in Dutch hospitals, there was an abundance of collected clinical data that could not be reused. Each hospital (around 100) developed its own information model. Some were using more than one model leading to ineffective interdepartmental exchange of clinical data. Furthermore, the majority of the 180 clinical quality registers used also had different information models with resulting in the duplication of registration work of the same information but in different structures. Data overlaps and gaps were often encountered [19, 20].

To address these issues, the federation of University Medical Centers (UMCs) in The Netherlands (NFU), and with the collaboration of the Dutch national knowledge center for IT and innovation in the healthcare sector (NICTIZ) launched in 2014 a new initiative for the standardization of healthcare data in The Netherlands. The new project aimed at achieving the unambiguous registration of patients’ data in a standardized manner as generated in primary care process to allow its reuse in various contexts such as continuity and quality of care of patients, scientific research, quality objectives, and epidemiology. Recognizing the importance of the project, other medical and health-related bodies (the NVZ, V&VN, and FMS) joined the program.

The program named “Clinical documentation at the point of care” (“Registratie aan de bron” in Dutch) with the slogan “Unambiguous single documentation = multiple use” (“Eenduidige eenmalige registratie = meervoudig gebruik” in Dutch) intended at improving the structural documentation of patients’ data to facilitate its reuse by satisfying 2 core requirements [21, 22, 23]:

1- Retaining the same meaning of the recorded data across different contexts by reaching an agreement on the data’s semantics and structures. was consistent if used in different contexts.

2- Recording the data: (1) only once (if possible), (2) the moment it would be generated (or as close as possible to the care process), (3) and in way that would have allowed its extraction from primary systems used by the healthcare staff for secondary use.

Once these semantic and structural specifications for the standardization of information used in the care process were defined, they were also established in the form of Health and Care Information models (HCIM), or Clinical Building Blocks (CBBs) (Zorginformatiebouwstenen or zibs in Dutch). The idea behind the project was simple. Clinical information must be structured in the form of a finite number of clinical models that would be used to create higher level definitions of information. Referred to as Clinical Building Blocks (CBBs), 100 of these health and care information models were created with distinctive characteristics [23, 24, 25]:

• Large to be of clinical significance and relevance (forming a complete clinical concept), yet small enough to be generic and reusable.

• Case neutral to guarantee their application in a variety of care processes. • Technically neutral and independent of the application or the user using them.

The CBBs created were expressed as technology-agnostic DCMs in which a care-related concept is described by the concept’s data elements and the data types of those elements in an Entity-Attribute-Value (EAV) model, also known as “object-attribute-value model” and "open schema". Widely adopted in clinical systems as a data storage model, the EAV model consists of a fixed

(11)

11

schema structure of three columns, referred to as Entity, Attribute, and Value. The ‘Entity’ column represents and stores the data item being described, the core or focus concept (the entity’s name). The ‘Attribute’ column represents and stores data that describes an entity, a qualifier that adds detail to the entity (the attribute’s name). The ‘Value’ column represents and stores the value of the attribute either as a numerical value or as a concept chosen from a uniquely identifiable set of valid concepts representing the attribute [26].

2.4 Clinical information models

Clinical information models (CIMs) are formal specifications defining the organization of clinical information inside electronic health record (EHR) systems. As the CIMs specify the information structures and the semantic relationships of the clinical content within those systems, their implementation allows the execution of a multitude of tasks. They facilitate registration, storage, display, query, and analysis of clinical data, while providing decision support and allowing data exchange between different EHR systems [27]. Modelling of CIMs relies primarily on 3 distinct approaches [28]:

• HL7 Reference Information Model (RIM) based standards • Two level modelling

• Generic Clinical Information Models (CIMs)

In CIMs, effort is directed on defining generic information structures at a conceptual level, independently of any implementation specifications. Unlike other modeling approaches that rely on developing implementation resources that use specific EHR standards, this approach focuses on defining generic and sharable CIMs that model a clinical concept without any particular implementation specification. These clinical concepts must be mapped to other interoperability standards upon implementation in order to transfer information between EHR systems. It is critical to ensure that mapping from the generic CIM to an implementable specification is always possible [28].

Models based on this approach are:

• The Clinical Information Model Initiative (CIMI) [29]:

CIMI is an international not-for-profit collaborative process that seeks to provide a common format for detailed specifications for the representation of health information content that would allow the creation and sharing of semantically interoperable information in health records, messages and documents. The aim of CIMI is to develop a repository of shared implementable CIMs that are based on a generic and standard-neutral reference model and described through international terminologies.

• Clinical Element Model (CEM) [30]:

CEM was designed to provide a consistent architecture for representing clinical information at EHR systems. The aim was to create a hierarchical and logical model that is robust enough to represent any clinically relevant information. It consists of two abstract models. The abstract instance represents instances of medical data at a general level whereas the abstract constraint model further specifies these general instances with a set of constraints. CEM is designed to provide a means of capturing the computable meaning of clinical information in an EHR system in a consistent and robust manner. It provides

(12)

12

flexible and comprehensive ways to represent wide ranges of clinical data with sufficient detail, using various attributes and qualifiers/modifiers. This specification uses a language called Constraint Definition Language to model the structure of data elements for clinical documentation.

• Detailed Clinical Model (DCM) [31]:

DCMs emerged as a new tool aiming to standardize the representation of clinical knowledge. Intended to be technology-agnostic, these small, standalone information models are neutral with respect to reference model and platform, and their use in any application requires their transformation into platform specific artefacts. These information models are descriptions of items of clinical information made of a discrete set of precise clinical knowledge that can be applicable in different contexts. Conceptually, a DCM specifies the semantics of discrete structured clinical information through data elements, attributes, types of attributes, and possible attributes’ values. A clinical reality that is intelligible to clinical domain experts and modelers is conveyed with unambiguous detail that allows its cross domain and cross discipline use while being standardized and reusable over domains, purposes, standards and implementations [32].

Several initiatives for the development and creation of DCMs have already being developed and implemented in a handful of countries. Nevertheless, these models couldn’t be used interchangeably between the different projects due to important differences in relation with the use or lack of a reference model and their expressiveness. Despite applying the same medical knowledge and using the same data elements and same codes from standardized terminologies, the conceptual, logical, and technical expressions were different in one modeling approach versus another. Fully semantically interoperable specifications couldn’t be attained [33, 34].

2.5 Clinical Terminologies

A clinical terminology is a standardized list of terms and their synonyms that are used in a clinical setting. It is a structured vocabulary that describes diseases, symptoms, surgical interventions, pharmacological treatments, medication, and other complex medical concepts. With its fine granularity, it should support clinical care, research, and quality improvement while being also mappable to broader classifications for financial and administrative use [35].

The origin of the development of medical classifications can be traced back to the latter part of the 16th century with John Graunt’s observations on London’s Bills of Mortality [36]. Since then, numerous challenges are encountered by authoritative bodies that are responsible for the maintenance and development of clinical terminologies. Tightly linked with technological advancement, the scope of clinical information significantly broadened in volume and depth. With new diseases emerging, corresponding new measures of prevention and procedures for cure are constantly discovered. New clinical expressions are added while previous ones require a continuous review for potential modification or deletion. Different clinical expressions for one medical concept are created and huge numbers of concepts and their relationships are added [37]. The shift in healthcare into integrated care increased the need for the integrated management of patients' healthcare data, and for ensuring its semantic interoperability. A structured terminology that covered all aspects of clinical care was required to consistently and unambiguously codify and

(13)

13

standardize the captured data to allow a steady and reliable information flow within and across the various healthcare related institutions.

2.5.1 Issues with standard terminologies

Several problems were encountered with standard terminologies. There were incompatible terminologies of different granularity levels. Guidelines for choosing a terminology over another were absent. and the lack of Systematic means for choosing the adequate concepts from a designated terminology to use in a clinical data model were lacking [37].

2.5.2 Examples of standards terminologies

There are several medical terminologies that are differentiated according to their purpose (e.g. diagnostic, functional capabilities, procedural, pharmaceutical), and the subset of healthcare data they cover (nursing procedures, problem lists). The ICDs (International Classification of Diseases) for disease codes, FMA (Foundational Model of Anatomy) for the human anatomy, RxNorm for clinical drugs, DICOM (Digital Imaging and Communications in Medicine) for imaging, and LOINC (Logical Observation Identifiers Names and Codes) for identifying medical laboratory observations and results are terminologies with specific medical domain coverage. Larger medical terminologies such as the SNOMED CT (Systematized Nomenclature of Medicine - Clinical Terms), the standard for capturing clinical information and encoding EHR data, and GALEN (Generalised Architecture for Languages, Encyclopaedias, and Nomenclatures in Medicine) have a vocabulary covering general clinical care.

2.5.2.1 SNOMED CT

SNOMED CT is an ontology-based clinical terminology created to formally represent the wide range of terms used in the clinical domain [38]. Originally developed by the College of American Pathologists, SNOMED CT is the product of the merge of two systems: SNOMED-RT and Clinical Terms version 3 in 2002. As of 2007, intellectual property rights to SNOMED CT was acquired by the International Health Terminology Standards Development Organization (IHTSDO) alongside with the responsibility of its maintenance and distribution [39]. With over 340000 active concepts (July 2018) that are thematically arranged by 19 - mostly disjoint - subhierarchies, SNOMED CT is the most comprehensive and multilingual clinical healthcare terminology that enables the consistent representation of scientifically validated clinical content in electronic health records [40]. It provides a standardized way for the representation of clinical phrases captured by clinicians, and it allows their automatic interpretation [41].

SNOMED CT is comprised of concepts, their associated descriptions and their interlinking relationships. A concept represents a unique clinical thought and is referenced with a unique numeric machine-readable concept identifier. Modeled according to a set of rules (The SNOMED CT Concept Model), every concept is described by at least one associated description represented by the Fully Specified Name that conveys the meaning of a concept in an unambiguous and unique manner. Additional acceptable descriptions are referred to as synonyms. It has at least one relationship that connects it with another concept.

(14)

14

Concepts are organized in multiple hierarchies with variable degrees of granularity. Clinical data of different levels of specificity is flexibly recorded and can be aggregated at a common general level upon future use.

Relationships are the connections between concepts in SNOMED, with every concept having at least one relationship to another concept. Relationships in SNOMED are unidirectional, extending from a source concept to a target concept. Inverse relationships (from target to source) are not maintained.

Two general kinds of relationships exist in SNOMED: • The Subtype relationship:

The Subtype relationship or the |is a| relationship forms the basis of the SNOMED hierarchies. Unidirectional in nature, the |is a| relationship links a specific source concept or a child concept to a general target concept or parent concept. The child concept’s meaning is subsumed by the parent concept’s meaning. Apart from the general root concept |SNOMED CT Concept|, every concept has at least one |is a| relationship and is a refinement of at least one concept.

• The Attribute relationship:

An attribute relationship comprises its source concept, its relationship type that specifies a defining characteristic or attribute (also a SNOMED concept), and a value (destination concept). These three together are called the “Object-Attribute-Value” (OAV) triplet. The use of the attribute relationship is limited to a defined domain and range. Concepts that are used as source concepts for a specific attribute relationship constitute the domain whereas those used as values or destination concepts for the same attribute refer to the range. Meaning is acquired from the concepts’ hierarchical positions and the axioms connecting them across hierarchies [42]. Logical inferences are drawn as a result of the consistency in SNOMED’s content modeling and the semantics based on Description Logic (DL) [43]. Automation of reasoning that supports retrieval and reuse of clinical information is enabled [44] and rendered more efficient through SNOMED CT’s support of post-coordination. A clinical idea can be represented with the assembly of 2 or more pre-existing concepts – called pre-coordinated concepts – guided by the SNOMED CT compositional grammar.

2.5.2.2 LOINC

The Logical Observation Identifier Names and Codes (LOINC) database [45], created in 1994 by the Regenstrief Institute at the University of Indiana, is the universal code system for the identification of laboratory tests and other clinical observations (diagnostic studies, critical care, nursing measures, medical history, physical, and survey instruments). It was developed with the aim of providing a common terminology that would facilitate the exchange of laboratory results and their retrieval from multiple sources. It addressed the problems arising from terminologies that used local and idiosyncratic names, lacked the necessary granularity for an accurate result description, or focused on administrative needs [46].

(15)

15

A LOINC concept can be identified by its unique LOINC code and by its unique composition of six major axes or dimensions representing the meaning of the code in a clinical or laboratory setting. These axes represent information about protocols (Analyte, Method, Time, and System), alongside the type of expected result values (Scale and Property). Aside from the method-axis whose inclusion is warranted when method distinction has significant implications on the clinical interpretation of a result, entries from the other five major axes are mandatory to form a fully-specified (formal) LOINC name [47]. With the

development of several aspects within LOINC (LOINC term translation, creation of hierarchies that group related LOINC terms, synonyms’ linking, ect), each value of a LOINC term’s dimension was coded. Known as LOINC Parts, they were assigned a non-semantic identifier that begins with the prefix “LP”.

LOINC developed a model for representing variables, answer lists, and the panels that contain them (survey instruments, questionnaires, standardized patient assessments, data collection sets, ect). Like any other LOINC concept, a panel’s fully-specified LOINC name is composed according to the LOINC model of 6 dimensions. Generally, the Component axis has the name of the data set or assessment. The Property and Scale axes are typically populated by a dash (-) due to variations of these attributes across the child elements. The Time Aspect and System axes are often consistent across the primary measures of a panel. Panels are often created with method-less child elements unless the observation is method-specific and method specification is the defining characteristic of the corresponding panel.

Whether referring to a laboratory battery or a clinical assessment, a LOINC panel term is characteristically defined by an enumerated set of child elements and their conditionality, broadly classified as required (R), optional (O), or conditional (C) when the status of a certain variable depends on other factors. The child elements – being observations – can be classified according to the types of results reported. Primary observations or measurements report the key measured results of the entity that is the panel’s subject, or indicate its amount, or either its presence or absence. Derived observations are obtained following the application of mathematical or logical operations on primary observations. Additional observations that provide information needed for the calculation or interpretation of a result are referred to as Ask at order entry observations. Associated observations report additional results that can be reported alongside a primary result. Each of the panel’s child elements is assigned an attribute that indicates its conditionality. Primary measurements are always required within a panel while other measurements are either optional or conditional. Aside from being categorical variables with enumerated answers and clinical variables reporting physical quantities, child elements can also be panel term. Nesting is thus enabled. Some observations have their meaning understood through the tight coupling of the question with the allowable answers. In standardized assessment instruments, a question has often a fixed set of specialized answers. To overcome their lack of an assigned code from existing terminologies, LOINC Answer Lists - structured representations of answer lists - were created and assigned a non-semantic identifier with the prefix “LL”. They are classified according to the nature of their binding to the LOINC observation code

(16)

16

• Normative lists contain a set of answers that are specifically defined by a validated instrument or an authoritative source. Upon the use of a LOINC term bound to a normative answer list, a valid result value can only be an answer found in the specified set of answers. • Preferred lists are those with a recommended set of answers. Users are encouraged to choose an answer from the set of answers; nevertheless, alternate result values are allowed. • Example lists represent possible result values. These lists can be subject to modification by

the addition or subtraction of answers as warranted by their use case.

Individual answers within lists are assigned a non-semantic identifier with the prefix “LA”. If the answers are not defined outside LOINC, an OID number is generated to identify that collection of answers. Answer Lists that are externally defined have the answers drawn from other terminologies (such as ICD-9-CM or CPT) and are indicated by their original code system and its OID. Both LOINC Parts and LOINC Answer Lists can represent value sets [48].

Unlike in SNOMED that uses description logics, no particular formalism is used in LOINC’s terminology. Nevertheless, all formal definitions in LOINC must conform to the 6-axis template and the embedded semantic relation that is associated with every axis, which enables automatic processing [49].

LOINC’s version 2.64, used in this study, contains 79,869 active terms, of which 51,813 relate to laboratory test observations.

2.5.3 SNOMED CT – LOINC agreement

SNOMED CT provided the conceptual content and its rich clinical semantics to LOINC codes – already providing an extensive coverage of laboratory tests and types of clinical. A common framework for the combined use of LOINC and SNOMED CT was created through the alignment of these 2 terminologies in their representation of attributes of laboratory tests and specific measurements (anthropomorphic measurements and evaluations, vital signs, and physiological measurements) [50].

Based on the analysis of several use cases, guidelines have been issued on the combined use of LOINC and SNOMED CT [51]. In a question and answer model approach, the observation, considered as a question, would be coded with LOINC and the observation’s (non-numeric) value, being the answer to the question, would be coded with SNOMED CT [52].

The pairing of LOINC and SNOMED CT was endorsed by the Interoperability Standards Advisory (ISA) for clinical measurements and observations while recommending only LOINC for both question and answer in reported outcome

measures, survey instruments, and other standardized patient assessments or validated scales [53]. At the core of the collaborative work between SNOMED CT and LOINC was the notion that the laboratory observable content expressions in SNOMED CT represented the LOINC term of the

(17)

17

laboratory LOINC. To achieve this end, the Observable entity hierarchy - where laboratory observables were placed - had to be reviewed and refined for its content and its concepts’ model [54]. The hierarchy contained subhierarchies representing functions, activities and other entities that didn’t adhere to the definition of an observable entity leading to a non-homogeneous content. Furthermore, true observative entities lacked object proprieties that defined their meaning.

Carrying a misleading term suggestive of things that could be observed, an observable entity is any information entity that “is about” an observed thing that “is specified” by an observation procedure. From that definition, the concept model being developed for Observable entities contained 2 virtually independent parts, each having its own set of attributes. The first part addressed the specifications of the observed feature of reality that was the observation target (What is being observed?). The second part or the observation procedure part described the defining characteristics of the type of observation being observed (How is the feature observed?). The model supported a feature’s existence irrespective of its observation status, allowing a technique-agnostic representation of the observable entity. Although the number was not definitive, four kinds of Observable entities have been identified up to the writing of this thesis. Sharing a common generic concept model, each observable kind would have its own refined concept model containing kind-specific attributes and their associated ranges and cardinality constraints.

•Quality observable: The most common type of observables and is about a person’s or a thing’s characteristic or feature that is always realized. Despite being always present, it doesn’t have to be readily observed.

•Disposition observable: An observable about a characteristic or feature that is not always realized in full.

•Function observable: An observable about a person’s, system’s, or thing’s ability to perform an activity or to realize a process.

•Process observable: An observable about a process or its outcome.

(18)

18

Observation results, outputs of observation procedures, were either included in the Observative entities hierarchy or represented in the Evaluation Procedure subhierarchy. Referencing the same observed feature of an object, the observation result differed from the observation entity by an additional result value whose exact representation was subject to debate until the writing of this report. A numerical result representation on a ratio or interval scale prompted the broad discussion on the representation of numbers in SNOMED CT definitions. The use of a nominal or ordinal scale for the representation of a non-numerical value could also be problematic. Values of a nominal or ordinal scale could be represented with SNOMED CT concepts representing clinical findings following the rational that a clinical finding would be an interpretation of an observation result. In view of some ontological concerns arising from such equivalence, the definitive representation of an observation result’s value was deferred to a later stage and linked to an ongoing project assessing the Clinical findings hierarchy.

A main design decision was taken on April 2017. The Observables model chosen for implementation would be the non-nested (flat) version of the proposed model. A direct implication of this decision was the inability to effectively coordinate between the Observables’ content and the Procedure’s content. The transformation of an observable result, modeled according to the existing (Evaluation) Procedure’s model, into an observative entity using the non-nested Observable’s model was rendered too difficult. The selection of the non-nested version was

(19)

19

anticipated to force a decision on the future representation of observation results according to either the Observable’s model or the (Evaluation) Procedure’s model.

(20)

20

Chapter 3 Selection of DCMs

DCMs capture and represent any clinical data a clinician would put into a health record about a patient such as a laboratory report, a medication administration, or a clinical finding. DCMs also differ in their composition and are broadly classified either as atomic or molecular [55]. Atomic DCMs consist of 1 single atomic data item that is fully specified with respect to concept, data element, data type, and data element code uniqueness that was derived from a (mostly external) code system. The creation of these DCMs derives either from the distinct role they hold by themselves in a health care process or from the reuse of their data element in other DCMs. Molecular DCMs are combinations of data elements yielded molecular DCMs. There is no established structural nature of such DCMs due to variations in clinical practice documentation. Some of these DCMs might have had several atomic data items clustered around a concept. Others might have had a number of atomic data items that generated a single atomic total score item. If a DCM could be broken into smaller subsets of DCMs, it was considered to be a collection of DCMs or an aggregate DCM.

3.1 Methods: Criteria for DCMs’ selection

Based on structural observations, it was decided by the primary researcher of this project (KM) to subcategorize the molecular DCMs into 3 additional categories:

❖ Molecular clustered DCMs ❖ Molecular non-clustered DCMs ❖ Molecular aggregate DCMs

Atomic DCMs were of simple construct and lack the type of properties and relationships needed for future analysis. Aggregate DCMs had several orders of magnitude and complexity and were also not considered for selection. Five DCMs were set to be selected.

Selection of DCMs that were subject to further analysis relied on 2 factors: • Clinical nature of the DCM:

In view of the decision to map DCMs’ concepts to LOINC and SNOMED CT, it was elected by the study researchers to limit the scope of this study to clinical DCMs representing measurements of observative entities or patient assessment scales.

• Complexity of the DCM

Complexity of a DCM was reflected by the number of data elements and their connectedness in terms of pattern (which elements were related) and nature (how elements were related). As DCMs varied in size; their level of details or granularity changed.

(21)

21

Up to the time of writing the present thesis, there has been three DCM releases. Since the last release 2017, there has been three pre-releases. The latest version (Prerelease 2019-1) was available as of July 2019 and was the version was used for completion of this study.

3.2 Results: Selected DCMs

Hundred DCMs were built. They were already categorized in 10 different groups according to nature of the care-based concept they referred to.

DCMs from the groups “Measurements” and “Scale/Assessment score” were assessed along their structural complexity. As atomic and aggregated DCMs were not considered for selection courtesy of their respective simplicity and complexity, molecular clustered DCMs represented the largest DCM construct used in the categories of interest for this thesis (22 out of 26). Three clustered DCMs from the “Measurements” group and additional two from the “Scale/Assessment score” were selected.

DCMs of the “Measurements” group: • BloodPressure DCM

The purpose of the BloodPressure DCM is also to acquire an idea about the blood circulation by recording the systolic and diastolic pressures as well as clinical information that relate to the cuff size used, the body site where the measurement was done, the patient’s body position, etc. The BloodPressure DCM was chosen because it had the highest number of Attributes

• HeartRate DCM

The HeartRate DCM is intended for use to gain insight on the circulation and the heart function by recording the heart rate as the number of beats per minute. The heart rate’s method of measurement and information about the heart rhythm could also be added. The developers of the HeartRate DCM did recognize that although the heart rate and the pulse rate are distinct physiological functions, their values in individuals with normal circulation are the same and end up being used interchangeably. In practical terms, if a pulse was palpated at a peripheral artery; a heart rate was recorded in the HeartRate DCM.

(22)

22

• PulseRate DCM

The PulseRate DCM is intended for use to gain insight on the overall cardiovascular function by recording the pulse rate which is expressed in the number of tangible arterial pulsations per minute. The PulseRate DCM was considered as a specification of the HeartRate DCM.

DCMs of the “Scale/Assessment Score” group • PainScore DCM:

The PainScore DCM is used to objectify a patient’s subjective pain experience. Pain quantification is done with the use of a pain scale in which endpoints define extreme limits. Typically, a 0 is an indication of absence of pain while a 10 or a 100 (depending on the scale range) is the worse pain ever. As the patient marks his pain level between the two endpoints, an estimate of intensity of pain is obtained. In addition to the measuring method, the PainScore DCM allows the recording of the anatomical location of pain and its laterality

.

• ApgarScore DCM:

The ApgarScore DCM represents the recordings of the Apgar index or assessment of the newborn’s well-being. Recordings are taken at 1, 5 and 10 minutes from birth through assessment of breathing, color, reflexes, heart rate, and muscle tone. Scores ranging from 0 to 2 are assigned for each of the assessment criteria. A total score is calculated by summation of the scores of the 5 assessed criteria taken at 1 point in time.

(23)

23

Chapter 4 Development of a General framework for

DCMs’ terminology binding

Terminology binding is a prerequisite for interoperability. It is defined as the linkage of information model nodes or data elements to representational units in terminologies [56]. In 2013, a ten-year agreement on a formal cooperation on LOINC-SNOMED CT harmonization was announced [52]. The aim of the cooperative work was to improve the clinical quality and relevance of both systems by reducing duplicated efforts and minimizing overlap, aligning future projects and maximizing synergy, and facilitating the exchange of clinical data within EHRs. Key to Dutch DCMs interoperability is their alignment with the LOINC–SNOMED CT harmonized concept model.

4.1 Methods

4.1.1 Choosing the international terminology standard

As per the recommendations on the effective combined use of SNOMED CT and LOINC in a clinical information system, adequate term binding of a DCM’s term with a terminology concept relied primarily on determining a DCM’s purpose. The selection of DCMs was already confined to those representing clinical observations where LOINC should be used for coding the “question”, numerical answers, and answers of a standardized assessment instrument (using LOINC Answers). SNOMED CT was the designated terminology standard for coding other answers and an alternative to LOINC for the mapping of the “question”.

4.1.2 Determining the question/answer form in the DCM

Representing a complete clinical statement, a DCM fragment was structurally composed of the Entity-Attribute-Value triplet in which the Value is the answer. As the Entity held two functionalities, two forms of the question were noted:

• By representing the focus concept of an observation, the Entity combined with an Attribute (a qualifier representing the focus concept in more detail) was considered as the question. • By representing the process or context around the focus concept of the observation, the Entity was excluded from the question’s construct, The DCM’s Attribute was considered as the question.

(24)

24

4.1.3 Establishing semantic relationships A) DCM with LOINC

The selected DCMs belonged to groups represented in LOINC as panels. A DCM’s Entity, in its definition of being the concept containing all the information elements of the model was expected to map to a LOINC panel term. The DCM’s questions (in both their forms) were anticipated to map with a LOINC panel’s child elements although not exclusively. Other LOINC concepts were also accepted provided they satisfied the rules for a LOINC panel equivalence. DCM’s answers from a Scale and Screening Tools DCM representing a standardized assessment instrument were coded with a LOINC Answer.

B) DCM with SNOMED CT

With the scope of the study limited in its mapping of the DCMs concepts to pre-coordinated SNOMED CT concepts, 2 constructs for a valid SNOMED CT expression, generated from the mapping of a DCM fragment, were identified:

• If the DCM fragment included the Entity as part of the question, the corresponding SNOMED CT expression had an Observable Entity as a focus concept (1).

• If not, the Attribute was mapped to a SNOMED CT concept from the Observable Entity hierarchy. The corresponding Value was mapped to a SNOMED CT concept from the Finding hierarchy (2).

Table 2. Rules for matching a panel to a LOINC panel

(25)

25

Determining the full semantics of the first SNOMED CT expression (1) relied on the completion of the following steps:

a- Determining the Observable kind of a DCM’s Entity Focus:

The Observable kind a DCM’s Entity Focus was assigned after retrieving its medical definition and comparing it to SNOMED CT’s definition of kinds of observables. For an Observation Result of a non-standardized assessment test, the corresponding observation entity was also identified.

b- Determining the allowed attributes:

Attributes of each Observable kind were retrieved. The Value of a DCM fragment was expected to map with a SNOMED CT concept from the allowed range of the corresponding SNOMED CT expression’s attribute. Anticipated changes on some existing attributes and their redefined ranges were also taken into account.

4.1.4 Choosing the terminology code

• Searching for the appropriate LOINC code was done using the LOINC website (https://loinc.org). Panels, panel child elements, and other LOINC codes were searched by using the exact DCM term, DCM term’s synonyms, and labels constructed of additional explanatory words to the DCM term.

• Following the document by Casey on how to search in SNOMED CT [57], the search for the appropriate SNOMED CT code was conducted on the SNOMED CT website (https://www.snomed.org/) in a similar fashion to the LOINC search. It also included a top down hierarchic search.

The use of clinical judgement was necessary to choose the most compatible LOINC or SNOMED CT code when several codes for 1 concept were generated.

4.2 Results

4.2.1 Determining the Observative kind of a DCM’s Entity Focus HeartRate DCM:

Heart rate is defined as the number of contractions of the pumping chambers of the heart per minute. The frequency with which the heart beats is calculated by counting the number of QRS complexes or ventricular beats per minute [58]. As such, the heart rate was classified as a process observable.

BloodPressure DCM:

Blood Pressure is the pressure of the blood against the inner walls of the blood vessels, especially of the arteries during different phases of contraction of the heart [59]. Considered as the outcome of the heart beating process, blood pressure was classified as a quality observable.

PulseRate DCM:

The pulse rate is the rate of the arterial pulse that is usually observed at the wrist and stated in beats per minute [60]. Similar to the heart rate, the pulse rate was classified as a process observable.

(26)

26

PainScore DCM:

The pain score is the number given by a patient in rating the intensity of his/her pain. Different types of scales exist for pain intensity assessment allowing the patient to indicate the degree of pain in an objective manner [61]. Since the pain score is merely the outcome of the pain-intensity assessment with a pain-intensity scale, it was considered as an Observation result. Nevertheless, the corresponding Observable Entity (Pain), a quality observable, was considered the DCM’s Entity Focus as all the DCM’s Attributes related to it.

ApgarScore DCM:

The total Apgar score is an objective score of the condition of a baby after birth. It is determined by scoring the heart rate, respiratory effort, muscle tone, skin color, and response to an irritable stimulus. Each of these objective signs receives 0, 1, or 2 points. An Apgar score of 10 means an infant is in the best possible condition while a score of 0 to 3 indicates that the child needs immediate resuscitation. The Apgar score is done routinely 1 minute after infant’s birth and often repeated after 5 and 10 minutes [62]. Since the Total Apgar score is the outcome of the standardized assessment of a newborn’s overall condition, it was considered as an Observation result.

4.2.2 Conducting the terminology binding

Six DCM fragments from 3 DCMs with invalid SNOMED CT expressions were identified and the binding of their data elements to SNOMED CT was adjusted (Figure 8). The result of the coordination of semantics across LOINC and SNOMED with the studied DCMs was illustrated in the following tables (Tables 3,4,5, and 6).

(27)

27

Figure 8. DCM fragments with invalid SNOMED CT expressions and adjustment of the terminology binding of the data elements to render the SNOMED CT expressions valid.

(28)

28

.

Table 3. Terminology binding of the HeartRate DCM.

Table 4. Terminology binding of the PulseRate DCM.

(29)

29

(30)

30

Table 7. Terminology binding of the ApgarScore DCM. Three tables were obtained from the term binding of ApgarScore 1 min DCM, ApgarScore 5 min DCM, and ApgarScore 10 min DCM. The tables had the exact result pattern with respect to their coding. All data elements were coded

(31)

31

Chapter 5 Identification of Semantically-Coherent Generic

DCM Fragments

A DCM is composed of a collection of reusable fragments, each carrying clinical information about the core concept [34]. Identifying the generic form of a fragment and its corresponding semantic relationship to the harmonized SNOMED CT-LOINC would allow the standardization the terminology binding of any built. Model.

5.1 Methods

5.1.1 Identifying consistent semantics for DCM fragments with invalid SNOMED CT relationships

Any DCM fragment with incomplete terminology mapping was retrieved and had the reason for the invalid corresponding SNOMED CT expression identified. If it was not a case of a missing concept in SNOMED CT, the DCM fragment relationship was deemed to have no simple SNOMED CT relationship match. Determining the nature of that semantic relationship as well as a potential semantic relationship between a DCM’s Focus concept and the second SNOMED CT expression (2) was attempted by representing a DCM using the SNOMED CT diagram notation:

a- The suggested SNOMED CT model for an Observable’s kind was used as reference to draw a diagram notation of the DCM’s Entity Focus concept. An Observation Result was set to be assigned the SNOMED CT concept Assessment score |82487009| as parent. b- The diagram was expanded with the SNOMED CT concepts corresponding to the DCM’s

Attributes and Values. Additional relationships and concepts were added in accordance with SNOMED CT’s rules for allowed expressions to ensure that all DCM’s concepts related with each other [63].

Fictitious attributes were used to establish a semantic relationship between the focus concept and the value if no valid SNOMED CT relationship could be found or if it was a combination of several relationships.

5.1.2 Generating generic DCM fragments

DCM fragments of the 5 selected DCMs were considered as extensions of generic DCM fragments. Such generic fragments would have contained clinical information that would have been inherited by the extended DCM fragments with more specific clinical details.

(32)

32

5.2 Results

5.2.1 Drawing a DCM’s diagram notation

Figure 9. Diagram notation of the HeartRate and PulseRate DCMs. Based on the definitions of the measured observations that the DCMs represented - pulse rate as a heart rate measured at systemic artery – the PulseRate DCM was designated as a specification of the HeartRate DCM. As the PulseRate DCM’s Root node was a specification of the HeartRate DCM’s Root node, corresponding Attributes such as Pulse Regularity and Heart beat Regularity and their associated Values should have followed the same relationship pattern when represented with SNOMED CT concepts. Nevertheless, that child/parent relationship was not expressed in those SNOMED CT concepts neither at the Attribute level or the Value level.

(33)

33

Figure 10. Diagram notation of the BloodPressure DCM. The observation on the patient (Attribute: Position) related to blood pressure through its associated findings (Value set of the Attribute: Position) that were found to be preconditions for blood pressure observation s taken with reference to body status. The observation on the device in the BloodPressure DCM (Attribute: CuffType) could have been replaced as to become a refinement of the blood pressure observation by using the SNOMED CT attribute “using device”. The associated value set would have included the concepts covering the various sizes of the blood pressure cuff device. The observation on the blood pressure (Attribute: Diastolic Endpoint) could not be directly related to blood pressure. Its associated findings - if created – would have been the focus of the procedure measuring the blood pressure having auscultation as its method.

(34)

34

(35)

35

Figure 12. Diagram notation of the ApgarScore DCM. Although not warranted as it was only mapped to due to its mapping with LOINC concepts, the diagram notation for the ApgarScopre DCM was done. The focus concept “Apgar score” did not exist in SNOMED

(36)

36

5.2.2 Generating generic DCM fragments

Since the PainScore DCM’s Entity Focus was a quality observable rather than an observation result, it was grouped with the 3 DCMs from the measurement group.

5.2.3 Adding semantics to the generic DCM fragments

Relationship matches with SNOMED CT were determined for were six generic DCM fragments. Two fragments had simple relationship matches. Two other fragments matched with a combination of 2 consecutive SNOMED CT relationships. One fragment had a partial match and another one fragment remained unmatched.

Figure 13. Generic DCM fragments. Three DCM fragments (Pulse Rate-Pulse regularity-Value, Heart Rate- Heartbeat regularity-Value, and Blood Pressure-Diastolic Endpoint-Value, exhibited the same relationship pattern. Each linked a measurement observation to a finding of a feature that related to the observation itself. The DCM relationship displayed in the DCM fragment Heart Rate-Position-Value was considered as to have been of a factor influencing the interpretation of the value of the measured observation. The various fragments of the ApgarScore DCM had the same relationship. The clinical information of any of those fragments addressed a score component of the Apgar test.

(37)

37

(38)

38

Chapter 6 Discussion and Recommendations

This thesis sought to harmonize Dutch DCMs with SNOMED CT or LOINC. After an exhaustive process and via model alignment, that goal was successfully achieved. Following selection of 5 DCMs from the “Measurements” and “Scale/Assessment score” groups, a standard framework for coding was created taking into consideration the LOINC panel structure and SNOMED CT semantics. Application of the developed framework improved terminology mapping in all studied DCMs. The study also identified a number of generic DCM fragments with corresponding SNOMED CT equivalences that could also be used for terminology binding.

To our knowledge, this is the first study to develop a standardized framework for mapping DCMs to SNOMED and LOINC. A similar effort was described by Harris et al., in which they detailed the process of generating a standardized model and terminology for skin and wound assessment based on nursing documentation from six organizations [64]. The authors constructed UML models following recommendations for implementing LOINC and SNOMED CT together. UML attributes were considered the “question” and mapped to LOINC observations and the allowable enumerated values for each attribute were the “answers” and mapped to SNOMED CT concepts. Mapping of the UML’s class and attributes were similar to our mapping of a DCM’s Entity and Attributes, it was unclear how the authors approached mapping of the answers to SNOMED CT. The authors initially stated that values were to be mapped with SNOMED CT concepts from the domain of Clinical Findings; nevertheless, some values were mapped to SMOMED CT concepts from the domain of Qualifiers, raising questions about the consistency of the semantic relationships. Campbell et al., relied on the “Observable” entity hierarchy of the SNOMED CT concept model, SNOMED CT concept expressions, and the intended semantics of LOINC in their study to represent pathology data specified by the synoptic report - a series of observations posed as question-answer pairs - in a computable and machine-readable form with LOINC and SNOMED CT [65]. The investigators similarly found that SNOMED CT content was deficient in its expressivity to define new Observable entities. While we addressed that issue by identifying semantically-coherent relationship between DCM fragments and SNOMED CT

This study highlights the need to reassess the current coding of DCMs’ terms. Generally known to be a combination of terminology issues and ambiguous data modeling [66, 67], coding errors of DCMs’ concepts were mainly differences in synonymy or partial term matching for DCM concepts coded with LOINC and inconsistent modeling of structure and relationships for those coded with SNOMED CT. While identifying the correct LOINC code required a vigorous but directed search in the LOINC website, the task of finding the correct SNOMED CT concept relied on incremental steps that centered on finding the corresponding SNOMED CT relationship for a DCM fragment. The mapping procedure was complicated by inconsistencies in the authoring of DCMs in terms of data representation and terminology coding (DCMs’ labeling, semantics of DCMs fragments), in LOINC a with lack of needed concepts, and with hierarchical incompatibilities in SNOMED CT.

STANDARDIZATION OF MAPPING OF DUTCH DETAILED CLINICAL MODELS TO THE LOINCâ SNOMED CT HARMONIZED CONCEPT MODEL TO FACILITATE INTEROPERABILITY