Page 2: First example: diagnosis appropriate?

Contents

With the help of ontologies and ECL, a formal definition can now be found and applied. A concrete example: We want to check whether the gender of a patient matches their diagnosis. To do this, we define the diseases that can only occur in male patients(<<*:363698007=<<10052007) and include over 1300 terms with this simple ECL expression. It should be clear that a list will hardly be complete - nor efficient. Try to elicit the complete list or at least a list with more than 100 entries of "male diagnoses" from a current LLM!

Drug and therapy safety

In any ageing population, patient care is characterized by multimorbidity and polypharmacy. Every second elderly patient suffers from more than four chronic diagnoses and takes more than five medications on a permanent basis. Often there are even significantly more medications, as many active ingredients have side effects that compensate for other active ingredients. Patients with arthritis are often prescribed painkillers such as diclofenac, but these can cause stomach problems, particularly heartburn. On the other hand, active ingredients such as omeprazole and pantoprazole are used, which in turn can promote osteoporosis. A chain that can be continued indefinitely.

Explanatory box elements AMTS

The specific pharmaceutical knowledge represented in an ontology typically includes indications, contraindications (contraindications), interactions (interactions), cross-allergies and adverse effects (side effects). A very simple example is shown in the figure for the excerpt from the semantic definition of the diagnosis, whereby it should be noted that each of the "outer" boxes has its own semantic description. The end result is a huge network of content-related connections, which is ultimately filtered using the data of a specific patient. This makes it possible to analyze even very complex situations, such as patients with many diagnoses and many medications.

Such automatic analyses are also particularly important for medications that are used in different specialist areas. For example, certain active ingredients used to treat depression interact with those used to treat athlete's foot. In the typical day-to-day treatment of a GP, something like this can easily be overlooked or the doctor does not have all the information. If, in future, all data is stored centrally in an electronic patient file, then there is at least a theoretical possibility of implementing efficient AMTS testing throughout the entire healthcare system.

However, many active ingredients not only have drastic side effects, but also interact with each other. The simultaneous administration of simvastatin (an active ingredient that lowers cholesterol levels) and clarithromycin (used to treat respiratory infections) can lead to the dissolution of the striated muscles (rhabdomyolysis) and consequently to kidney failure. This is a life-threatening situation. Patients may also have intolerances, so the dose must be adapted to the patient's condition and age. The same applies to the duration of use and even the time at which a medication is taken can be decisive. So how can a doctor prescribe a medication safely? What support can he expect?

With ontologies that contain pharmaceutical knowledge and the "CDSS tools", an efficient tool can be implemented that addresses this problem – which is referred to as "drug and therapy safety (AMTS)" in everyday clinical practice.

Standardization / Semantic interoperability

Terminologies and ontologies can not only generate knowledge, but also transport it. By mapping a textual description to a terminological term, we leave the level of human language and ultimately enter abstract mathematics or algorithms. A term can have many different narrative descriptions and is described in terms of content (semantically) via ontologies. A certain "understanding" of a term can thus be generated at the level of algorithms. The second part of the article series described how terms are derived from human language and the effort involved, but there is also an effort to communicate terms from the outset instead of free text.

Instead of the word "myocardial infarction", for example, the term "I21.9" (ICD-10) or "22298006" (SNOMED CT) is conveyed. With suitable tools, such as terminology servers, these terms can be processed directly: They can be resolved backwards. This means that a display text is generated for a specific language. These can be related to each other and clarify, for example, whether a term belongs to a certain category or not. This is known as semantic interoperability. In a nutshell: This is a form of communication in which the sender and receiver not only understand each other syntactically, but in which the receiver is in principle able to understand the content of the communication.

Meta-level and description of the data

It is important to distinguish between two levels at which terminologies are used to achieve semantic interoperability. First, there is the meta-level, which describes the data descriptively. And then the data itself must be described. In particular, the content of a table with the term 419076005 (SNOMED CT for allergy) could be described at the meta level.

A system can use this to conclude that, in principle, these are diagnoses and that an allergen must exist. A line in this table can now contain, for example, 91936005 (SNOMED CT for penicillin allergy), which on the one hand defines the allergen (penicillin), but can also be validated by asking a terminology whether a penicillin allergy is an allergy. As I said, on a purely conceptual, mathematical level! However, this also works prospectively: if the term "91936005" is received, terminology servers can be used to check in which table this term must be stored.

In Germany, semantic interoperability is seen as a central focus of digitalization in the healthcare sector. This keyword can therefore also be found in numerous laws. Specifications should be defined as "semantically interoperable", which is why terminology such as SNOMED CT can also be found there. The specifications themselves are usually implemented in the HL7 FHIR format.

Despite all the successes of modern machine learning (ML) approaches, we should not forget tried and tested tools. All technologies have their weaknesses, and the challenge is to bring the respective strengths to the fore by skillfully combining them. Terminologies and ontologies are complex to create and use, but they give us a promising opportunity to further improve ML approaches.

Newer approaches are investigating the possibility of "enriching" data for machine learning in advance with the help of ontologies and even making it comprehensible (keyword "prior knowledge"). It should also be possible to create new ontologies more efficiently with the help of ML models. Rule-based systems are an important backbone for semantic interoperability and ensure the transparent quality that is so important for medical devices - ultimately, we want to be treated by doctors who can rely on their software.

(mma)