Keywords

1 Introduction

There are numerous cancer registries around the world collecting data about cancers diagnosed and/or treated in a given area. This data is used to monitor cancer (incidence rates, survival rates, etc.) and to evaluate cancer care (diagnosis, treatment, etc.). To produce comparable data, common definitions (e.g. terminologies like the International Classification of Diseases (ICD)) and coding practices [5] have to be followed. However, the broadness and complexity of these standards make the work of the medical staff in charge of coding (operators) more difficult.

The aim of this research is to address this complexity, by assisting both operators and coding experts in the interpretation of coding best practices.

As an illustrating example, let us consider the case denoted by exmpl of a particular woman. In 2016, multiple pulmonary opacities were discovered within her right lung. A CT scan indicated no mediastinal adenopathy.Footnote 1 A histological analysis of a sample identified the morphologyFootnote 2 of the cancer as adenocarcinoma. The TTF1 marker test was positive. After further testing, another tumor is found in the ovaries. An operator might wonder which topographyFootnote 3 should be coded (lung or ovaries?) and can request help. For the Luxembourg National Cancer Registry (NCR), operators ask their questions using an online ticketing system. With free text description provided by operators, coding experts provide a solution, i.e. an answer with their reasoning in the form of a motivated argument.

Section 2 describes an approach to assist the data collection process for cancer registries and how case-based reasoning (CBR [1]) is applied. In Sect. 3, a prototype and preliminary results are discussed. Section 4 presents a conclusion and points out what further efforts need to be undertaken in the future.

2 Case-Based Interpretation of Best Practices

This article summarizes the work presented in [9] and adds a description of the developed prototype and some preliminary results.

2.1 Preliminaries

RDFSFootnote 4 is a knowledge representation language of the semantic web. SPARQL (See footnote 4) is a query language for RDFS web.

A case \(({\texttt {srce}}, {\texttt {sol}}({\texttt {srce}}))\) is composed of two parts: (1) srce is a problem given by a question (i.e. a subject) and a patient record, and (2) sol(srce) a solution for the problem srce.

The question indicates the subject (incidence date, topography, tumor nature, etc.). In the example, the question is about the topography.

The patient record represents the data from the hospital patient record (patient features, tumors, exams, treatments, etc.) needed to answer the question. The relevant data depends on the subject and is defined by coding experts. The patient record is represented by an RDFS graph [3] (see Fig. 1). Body parts and cancer morphologies use classes from the SNOMED Clinical TermsFootnote 5 ontology.

The solution contains the answer to the question and the most important arguments in favor of (pros) and against (cons) this answer. In the example, the answer is to consider the topography to be the ovaries. The presence of multiple pulmonary opacities is an argument in favor, as they are indicative of a lung metastasis and thus the tumor is unlikely to have originated in the lungs.

Fig. 1.
figure 1

Short patient record in RDFS. This graph represents a woman with a single biopsy (exam), identifying the tumor as adenocarcinoma (which is coded as M-8140/3). The circles represent blank nodes.

Full size image

The arguments have two uses. They help explain the answer to operators and serve as a reminder for coding experts. They are also used in the proposed approach during the retrieval step. Three types of arguments will be considered: strong pros, weak pros and weak cons. The difference between a strong and a weak argument comes from their reliability for a given conclusion. A strong argument is considered to be a sufficient justification for an answer, unlike a weak argument which is more of an indication or clue. It can be noted that there are no strong cons in the source cases. Indeed, such an argument would be an absolute argument against the given answer. Formally, an argument is a function that associates a Boolean to a case and is stored as a SPARQL ASK query. The following shows an argument arg, followed by an explanation:

figure a

arg says that a TTF1 positive adenocarcinoma is in favor of a primitive lung cancer. The argument checks that the morphology of the tumor is of type adenocarcinoma and that the tumor is positive for the TTF1 marker. This argument applies for the example described in the introduction, i.e. arg(exmpl) = TRUE.

2.2 Global Architecture

The proposed approach uses a 4-R cycle (retrieve, reuse, revise, retain) adapted from [1] and four knowledge containers [8] (case base, domain knowledge, retrieval knowledge, adaptation knowledge), as shown in Fig. 2.

Fig. 2.
figure 2

Adapted 4-R cycle and knowledge containers for the proposed approach.

Full size image

2.3 Retrieve

The proposed approach relies on arguments to find similar cases. Indeed, similar answers should be based on similar reasoning and thus the same arguments should apply. Our method checks the applicability of arguments from source cases on the target problem tgt and uses this to determine the preferred source case to solve tgt. This preference relation is denoted by the preorder \(\preccurlyeq _{{\texttt {tgt}}}\). The comparison between two source cases i and j relies on three criteria, \(\mathcal {C}_\mathtt {s}\) for strong arguments, \(\mathcal {C}_\mathtt {w}\) for weak arguments and \(\mathcal {C}_\mathtt {dist}\) for patient records.

An argument arg is applicable for a case c if the preconditions of the argument are met in the patient record of c. For the argument arg described in the preliminaries, arg applies for a case if the patient record contains at least two exams, one identifying the morphology as adenocarcinoma and another exam reporting a TTF1 positive tumor. Formally an argument arg is applicable for a case c if arg(c) = TRUE.

For the criterion \(\mathcal {C}_\mathtt {s}\), the source case with more applicable strong arguments is preferred. Formally, \(\mathcal {C}_\mathtt {s}\) is met if \(\mathtt {\Delta _{i,j}^{s}}> 0\), where \(\mathtt {\Delta _{i,j}^{s}}\) is defined as

and \({\mathcal {N}}^{\texttt {args}}({\texttt {srce}}, {\texttt {tgt}})\) denotes the number of arguments of type args of a the source case srce which are applicable for a case tgt, i.e.

$$\begin{aligned} {\mathcal {N}}^{\texttt {args}}({\texttt {srce}}, {\texttt {tgt}}) = | \{ {\texttt {a}} \in {\texttt {args}}({\texttt {srce}}) \,|\, {\texttt {a}}({\texttt {tgt}}) = {\texttt {TRUE}} \} | \end{aligned}$$

and args \(\in \) {sp, wp, wc} is an argument type. sp \((\) srce \()\) is the set of strong pros, wp \((\) srce \()\) the set of weak pros and wc \((\) srce \()\) the set of weak cons of srce.

For the criterion for weak arguments \(\mathcal {C}_\mathtt {w}\), a combination of pros and cons is used. Intuitively, if more weak pros and less weak cons are applicable, the source case is preferred. Formally, \(\mathcal {C}_\mathtt {w}\) is met if \(\mathtt {\Delta _{i,j}^w}> 0\), where \(\mathtt {\Delta _{i,j}^w}\) is defined as

where \(\mathtt {\lambda _p}\) and \(\mathtt {\lambda _c}\) are two nonnegative coefficients that are currently fixed to \(\mathtt {\lambda _p}\) \(=\) 3 and \(\mathtt {\lambda _c}\) \(=\) 2. When more data are available, these parameters values will be reevaluated.

For the criterion \(\mathcal {C}_\mathtt {dist}\), a graph edit distance between patient record RDFS graphs is used [4]. Formally, \(\mathcal {C}_\mathtt {dist}\) is met if \(\mathtt {\Delta _{i, j}^{dist}}\ge 0\), where \(\mathtt {\Delta _{i, j}^{dist}}\) is defined as

The three criteria are considered lexicographically, first \(\mathcal {C}_\mathtt {s}\), then \(\mathcal {C}_\mathtt {w}\) and finally \(\mathcal {C}_\mathtt {dist}\) (see [9]). \(\mathtt {srce_i}\) is preferred over \(\mathtt {srce_2}\), i.e \(\mathtt {srce_i}\) \(\preccurlyeq _{{\texttt {tgt}}}\) \(\mathtt {srce_j}\), ifq

$$ \mathtt {\Delta _{i,j}^{s}}> 0 \;{\texttt {or}}\; (\mathtt {\Delta _{i,j}^{s}}= 0 \;{\texttt {and}}\; (\mathtt {\Delta _{i,j}^w}> 0 \;{\texttt {or}}\; (\mathtt {\Delta _{i,j}^w}= 0 \;{\texttt {and}}\; \mathtt {\Delta _{i, j}^{dist}}\ge 0))) $$

2.4 Reuse

Once an appropriate source case has been found, the solution associated to the source case is copied: sol(tgt) := sol(srce). The arguments that do not apply to the target problem, if any, are removed.

2.5 Revise and Retain

The newly formed case \(({\texttt {tgt}}, {\texttt {sol}}({\texttt {tgt}}))\) can be reviewed by a coding expert, to modify the answer, the arguments and/or the patient record. A coding expert may choose to remove unnecessary information from the patient record, removing unwanted specificity. Thus, \(({\texttt {tgt}}, {\texttt {sol}}({\texttt {tgt}}))\) is substituted by \(({\texttt {tgt}}', {\texttt {sol}}({\texttt {tgt}}'))\), where tgt \('\) is more general than tgt. \(({\texttt {tgt}}', {\texttt {sol}}({\texttt {tgt}}'))\) is a generalized case that has a larger coverage than \(({\texttt {tgt}}, {\texttt {sol}}({\texttt {tgt}}))\) [6].

Fig. 3.
figure 3

Example of a solved case. The top displays the new question asked and the provided solution. The bottom displays the source case used to solve the new question.

Full size image

3 Prototype and Preliminary Results

The prototype designed for the NCR serves as a ticketing system, where operators ask coding questions and experts provide answers. It assists operators in structuring questions, making it easier for the NCR and coding experts to find similar questions later. For topography questions, it will also provide a tentative answer. This answer is calculated using the approach described in [9]. All the answers are reviewed by experts. The prototype presents itself as a single page application built using AngularFootnote 6 with a backing REST API built with Go (See footnote 6) and the Gin framework.Footnote 7 The data is stored in a triple store Apache Jena and exposed as a SPARQL endpoint using Apache Fuseki.Footnote 8 Figures 3 and 4 show screenshots of the prototype.

Fig. 4.
figure 4

Form used to describe coding questions and patient records. The French labels for body parts and morphologies are taken from the SNMIFRE (a French translation of SNOMED, http://bioportal.lirmm.fr/ontologies/SNMIFRE).

Full size image

The prototype was tested internally, to perform a first assessment of its usability and utility. Some old cases concerning the topography were formalized and coded, with some domain knowledge. For the arguments, great care was given during modeling in order to make them more broadly applicable. Then new questions were presented to the system, and the proposed solution compared with the expected ones. While the prototype answered every question, not all of them were correct. The main reasons for the difference were the small amount of cases (15 originally, however the case base will be enriched by routine usage) and the simple reuse method used at this stage. Indeed, as the arguments have been formalized to be more general, some of the provided answers might be slightly incorrect (e.g. answering upper lung lobe instead of lower lung lobe). Despite this, as the prototype displays the reused source case, an operator should be able to make the necessary adaptation to the provided solution. For the questions concerning other subjects, the prototype relies entirely on the coding experts to provide answers.

To the best of our knowledge, few other research attempts to use arguments in the context of the retrieval process. The closest method found is a work by McSherry [7]. The proposed approach creates explanations afterwards, using the closest source case to provide the conclusion and the closest source case with the opposite conclusion to compute which attributes favor the conclusion and which attributes do not. Unlike our approach, each argument is linked to a single attribute. Thus they cannot show how the combination of attributes might influence a given outcome.

4 Conclusion

Recently there has been a growing interest for case-based reasoning applications in health sciences [2]. In this paper, an approach to assist operators in the interpretation of best medical coding practices has been proposed. This approach is based on discussions with operators and coding experts on actual coding problems. A dozen tricky problems were discussed in detail, among a hundred simpler problems. The coding questions asked by the operators are compared to previous questions and solved by reusing the pros and cons of previously given solutions. The results discussed are only preliminary and a more thorough evaluation, including the operators and coding experts, is planned.

At the moment the reasoning process is only partial. Arguments are only a part of a more complex reasoning process. The formalization of this process and the eventual integration of the coding standards remains an interesting avenue for future work.

After the prototype has been validated and improved by routine usage, a second version will be designed that is less domain-dependent. The objective is to build a generic system for argumentative case-based reasoning using semantic web standards.