INTRODUCTION

According to Davis et al. [¹], a knowledge representation is an ontological model for intelligent reasoning and man-to-machine communication. This definition reveals one of the main uses of knowledge representation: the development of models for complex problems as the first stage for solving them.

After performing a systematic literature review by following the guidelines provided by Kitchenham and Charters [²], we found some different ways to graphically represent some topics related to cancer patients: informal flowcharts [³]-[⁵], architectural diagrams [⁶]-[⁸], and concept sketches [⁹]- ¹⁴]. However, such proposals fail to comply with the roles assigned to knowledge representations due to the following reasons:

In this paper, we deal with the previously stated reasons and then we propose a model of the cancer patient with some features:

The selected syntax for such a model belongs to the pre-conceptual schemas [¹⁵] intended to represent knowledge in any domain. We hope our model can be instantiated to resemble the real world of a cancer patient and her surroundings. In addition, we expect an easy integration with some health standards such as Health Level 7 (HL7) and the International Classification of Diseases (ICD).

This paper is organized as follows: we present and discuss the background in the next Section; then, we propose the methodology; next, we propose our model and show some results; finally, we discuss some conclusions and propose some future work.

BACKGROUND

We develop a systematic literature review by following the guidelines provided by Kitchenham and Charters [²]. We are looking for proposals with graphical representations of some information about cancer patients. We use keywords like "cancer patient", "information about cancer processing", and "graphical representation of cancer information". We obtain 12 proposals as primary studies after performing the entire process. They are then classified into informal flowcharts, architectural diagrams, and concept sketches.

Informal Flowcharts

Wittmann et al. [³] propose an informal flowchart to represent the timeline for the activities to be followed in order to survive prostate cancer (see Figure 1). Even though the representation is well-structured, it lacks details for reaching an implementation and it is focused on just one type of cancer.

Source: Wittmann et al. [³].

FIGURE 1 TIMELINE FOR THE ACTIVITIES TO BE FOLLOWED TO SURVIVE PROSTATE CANCER 

Imoto et al. [⁴] developed a workflow for identifying breast cancer prognostic factors from biochemical reactions (see Figure 2). This representation is general to cover all types of cancer, is human-readable, and exemplified, but it lacks efficient computation since its syntax is incompatible with other types of knowledge representation.

Source: Imoto et al. [⁴].

FIGURE 2 WORKFLOW FOR CANCER PROGNOSTICS FROM BIOCHEMICAL REACTIONS 

Meier et al. [⁵] describe the process of oncological treatment by using an informal workflow (see Figure 3). The workflow includes a defined syntax close to the usual flowcharts, but it lacks details for implementation and the human readability is limited since the information seems to be incomplete.

The informal flowcharts we present in this Section share some disadvantages in terms of knowledge representation: they fail in the reasoning capabilities and the standard representation for machine-to-machine and man-to-man communication. Also, they lack general information about the patient and her surrounding environment.

Source: MEIER ET AL. [⁵].

FIGURE 3 PROCESS OF THE ONCOLOGICAL TREATMENT 

Architectural Diagrams

Jayadevappa and Chhatre [⁶] include several domains for patient-centered care treated as architectural elements (see Figure 4). The domains resemble some concepts and attributes, but the syntax is inconsistent since the same elements are used for representing heterogeneous elements, e.g., the same symbol is used for clinical convenience, clinical characteristics, and outcomes when they seem to be completely different architectural elements. Consequently, communicative intention is difficult to understand for humans and machines.

Source: Jayadevappa and Chhatre [⁶].

FIGURE 4 DOMAINS FOR PATIENT-CENTERED CARE 

Berliner and Lemke [⁷] depict the architecture of a therapy imaging and model management system (see Figure 5). The elements of the system are clearly defined with their own symbols, but the architectural diagram lacks enough details for implementation purposes, so the ontological commitment is incomplete.

Similarly, Eschrich et al. [⁸] summarize the architecture of a molecular data warehouse (MDW) and the integration with an existing healthcare-based warehouse (see Figure 6). They use the same syntax for representing the architecture and they exhibit the same disadvantages regarding the roles of a knowledge representation in terms of the detail level and the communicative intention.

Source: Berliner and Lemke [⁷].

FIGURE 5 ARCHITECTURE OF A THERAPY IMAGING AND MODEL MANAGEMENT SYSTEM 

Source: Eschrich et al. [⁸].

FIGURE 6 ARCHITECTURE OF MOLECULAR DATA WAREHOUSE 

Concept Sketches

Yang et al. [⁹] propose a conceptual framework with some of the relevant concepts for managing a cancer patient (see Figure 7). Such a framework lacks a formal syntax, so communicative intention is difficult to understand for humans and machines. However, the concepts exhibit attributes and some relationships with some detail.

Halmai and Carvajal-Carmona [¹⁰] created a sketch about genomic data for characterizing the risk factors associated with some types of cancer (see Figure 8). The drawings and the heterogeneous syntax make it difficult to understand the model for machines. Also, the implementation seems to be complex if we start from this sketch.

Source: Yang et al. [⁹].

FIGURE 7 CONCEPTUAL FRAMEWORK FOR MANAGING A CANCER PATIENT 

Source: Halmai and Carvajal-Cardona [¹⁰].

FIGURE 8 GENOMIC DATA FOR CHARACTERIZING THE CANCER RISK FACTORS 

Lemke et al. [¹¹] integrate information about patients and diseases from some viewpoints into a specific patient model (see Figure 9). Even though the drawing is general enough to be used in any kind of cancer, the level of detail is very low, so implementation is difficult from such a sketch.

Source: Lemke et al. [¹¹].

FIGURE 9 AN INTEGRATED PATIENT MODEL FROM SOME VIEWPOINTS 

The Board on Health Care Services [¹²] adapts information from some sources and integrates it into a model of patient-centered care (See Figure 10). The model lacks enough detail to be implemented and its syntax is difficult to understand for both people and machines.

Source: Board on Health Care Services [¹²].

FIGURE 10 MODEL OF PATIENT-CENTERED CARE 

Hassankhani et al. [¹³] propose some palliative care models used for cancer patients (see Figure 11). The model is very informal, but we can infer some information about the patients, like the stage of the cancer and some processes. However, such information lacks details for implementation and the syntax is confusing for both people and machines.

Source: Hassankhani et al. [¹³].

FIGURE 11 PALLIATIVE CARE MODELS FOR CANCER PATIENTS 

Tralongo et al. [¹⁴] propose a conceptual framework of patient-centered care based on four dimensions (see Figure 12). Even though Tralongo et al. [¹⁴] include what they define as dimensions and concepts, the syntax is unclear about which of the elements belongs to any category. Also, the level of detail is minimal, so the implementation is difficult to achieve from such a framework.

Source: Tralongo et al. [¹⁴].

FIGURE 12 DIMENSIONS OF THE PATIENT-CENTERED CARE 

METHODOLOGY

The proposals identified as primary studies in the previous section reveal some problems to be solved to improve the information about cancer patients. We follow a step-by-step process for selecting a type of representation with this aim. The steps are the following: (i) identifying the need; (ii) establishing the criteria; (iii) relating the need with the criteria; and (iv) selecting the notation for the representation by justifying the criteria.

Some authors identify the need for precise information related to the cancer patient. Eschrich et al. [⁸] discuss the importance of modeling cancer patients in terms of lowering the complexity of querying data. Jayadevappa and Chhatre [⁶] discuss some benefits in terms of the quality of the information, the effectiveness and accuracy of the communication, and the identification of patient preferences. Lemke et al. [¹¹] also point out the importance of identifying and defining the relevant information entities (the main concepts of the model) as a way to deal with future calculation/statistics about the process, as well as a structured way to store the growing information of the cancer patients.

The relevant information about the cancer patients can be modeled by using a knowledge representation. Davis et al. [¹] propose the following roles we can use as criteria for a knowledge representation, and we can relate them to the need:

(i) A substitute for the thing itself, i.e., a model of such a thing. This criterion is intended to lower the complexity of querying data.

(ii) An ontological commitment with enough concepts and relationships to resemble the domain of interest. This criterion is intended to define the relevant information entities and create a structured way to store the information of cancer patients.

(iii) A fragmentary theory of intelligent reasoning with the capabilities for inferring knowledge from the previous ontological commitment. This criterion is intended to identify patient preferences and improve the quality of the information.

(iv) A medium for pragmatically efficient computation, i.e., a way to communicate the previous roles to machines. This criterion is intended to improve the accuracy of the communication.

(v) A medium of human expression, i.e., human-understandable expressions of the model. This criterion is intended to improve the effectiveness of the communication.

Such roles/criteria help modelers to deal with the overwhelming complexity of the natural world. In fact, knowledge representations can support guidance in deciding what part of the world we need to attend to and which one we need to ignore. Consequently, complex human problems can be decomposed and understood by representing them into models.

We can summarize the proposals studied in the previous version in Table 1 by considering the roles discussed by Davis et al. [¹] (columns 2 to 6), the level of detail of the information included in the proposals (column 7), and the applicability to cancer types (column 8).

According to the summary included in Table 1, about the proposals found in the state of the art, we need a solution closer to the knowledge representation world with detailed information for implementation and covering the concepts, attributes, and relationships identified for all the cancer types. The roles of the knowledge representations discussed by Davis et al. [¹] are difficult to accomplish for most of the usual conceptual schemas related to software engineering. We explore the usage of some notations like mental maps, conceptual maps, class diagrams, entity-relationship diagrams, and flow charts, but they fail in one or more roles/criteria of a good knowledge representation. Consequently, we select in this final step the pre-conceptual schemas proposed by Zapata et al. [¹⁵] as knowledge representations by justifying the coverage of the five roles/criteria in the following ways:

The main syntax we will use for the pre-conceptual schemas is depicted in Figure 13. We explain the main elements as follows:

Source: adapted from Zapata et al. [¹⁵].

FIGURE 13 MAIN ELEMENTS OF THE PRE-CONCEPTUAL SCHEMAS 

Some of the main concepts included in the solution can be extracted from the proposals of the state of the art and they should be complemented for implementation purposes with enough attributes for being exemplified. We select pre-conceptual schemas for proposing our solution because they accomplish the five roles of a knowledge representation. The method for constructing the cancer patient model is depicted in Figure 14 and explained as follows:

RESULTS AND DISCUSSION

Concept Identification

Concepts coming from the different proposals we analyze in the background Section are included in Table 2. Be advised that we have patient care in mind in order to identify the main elements we can extract from each proposal. Also, we need to unify certain terms, e.g., cancer characteristic instead of disease, provider instead of oncologist or hospital, etc. We use some special syntax in Table 2:

Source: own elaboration.

FIGURE 14 METHOD FOR CONSTRUCTING THE CANCER PATIENT MODEL 

• ■ Colon is used for defining possible values of a concept.

• ■ Slash is used for separating possible values of a concept.

• ■ Parentheses are used for expressing attributes of a concept.

TABLE 2 CONCEPT IDENTIFICATION FROM PREVIOUS PROPOSALS 

Proposal	Concepts identified
Wittmann et al. [3]	Surgery: treatment, patient, breast: diagnosis, location
Imoto et al. [4]	Patient, cancer characteristic, breast: diagnosis, location
Meier et al.[5]	Patient, diagnosis, immunotherapy: treatment
Jayadevappa and Chhatre [6]	Patient (date of birth, marital status, social security number, ethnicity), provider, treatment
Berliner and Lemke [7]	Lab value, diagnosis, treatment, patient
Eschrich et al. [8]	Cancer characteristic (treatment), provider, radiation: treatment, patient
Yang et al. [9]	Patient (date of birth, gender, marital status, social security number), diagnosis (stage, location)
Halmai and Carvajal-Carmona [10]	Lung/breast/stomach/liver/kidney/colon/rectum/ovary/prostate: diagnosis, location, immunotherapy/chemotherapy: treatment, patient (ethnicity), risk factor, lab value
Lemke et al. [11]	Patient, cancer characteristic, surgery/radiation: treatment
Board on Health Care Services [12]	Patient, provider
Hassankhani et al. [13]	Patient, diagnosis (stage), provider, lab value
Tralongo et al. [14]	Patient, cancer characteristic, provider

Source: own elaboration.

Concept Representation

We use the syntax we present in Figure 13 for classifying all of the concepts identified in Table 2. We have some hints for defining such classification:

• ■ Concepts with attributes (denoted with parentheses) are class concepts, while attributes are leaf concepts linked to class concepts using a has structural relationship.

• ■ Lists of possible values (heading colon) are included in dotted rectangles, while the concept assigned is classified as a leaf concept linked to the possible values using a dotted line.

• ■ Entities are class concepts even though they lack attributes.

• ■ Specific concepts are leaf concepts even though they lack a linked class concept.

• ■ Arrows are provided for linking concepts to relationships and vice versa.

The resulting pre-conceptual schema is depicted in Figure 15. Be advised that the complete set of concepts identified in column 2 of Table 2 are included in Figure 15 and we have two isolated concepts (provider and lab values).

Source: own elaboration.

FIGURE 15 INITIAL PRE-CONCEPTUAL SCHEMA FOR REPRESENTING THE IDENTIFIED CONCEPTS FROM TABLE 1  

Missing Information Identification

The initial pre-conceptual schema of Figure 15 was validated by performing a focus group, according to the guidelines provided by Anderson [¹⁷]. The composition of the focus group was restricted to two experts in information systems with 5-or-mo-re years of experience in modeling cancer situations with different kinds of tools. After reviewing some candidates, we selected two experts from a Cancer Center in the United States. The focus group session lasted two hours as recommended by Anderson [¹⁷] and the discussion was moderated towards the quality of the initial information, the clarity of the concepts and relationships, and the completeness of the information. The last part of the focus group was devoted to providing additional information for completing the cancer patient model according to their needs and standards. The experts validated the contents of the initial pre-conceptual schema, and they provided some information regarding the system they use in the Center, along with other information regarding the regulations in the United States related to cancer patients and the information we must include by accomplishing some standards like HL7.

We should complete the model by using the new information to identify where the concepts/relationships are missing as follows:

• ■ Leaf concepts missing from some class concepts: We need more information from the patient (birthplace, first name, middle name, last name, religion, and medical record number). Regarding the diagnosis, we need the date and the patient's age at the moment of the diagnosis. Regarding the cancer characteristics, we need the grade differentiation, the first treatment date, the tumor sequence number, the histology, and the behavior.

• ■ Possible values belonging to some leaf concepts: Some treatments are missing, i.e., biopsy, hema_endo, and hormone. Also, some risk factors like alcohol use and tobacco use.

• ■ Class and intermediate concepts (with their leaf concepts) for linking to other concepts and adhering to standards: The provider is linked to the patient and the cancer characteristic by using an intermediate concept called scheduled appointment. Such a concept has some leaf concepts like lab value (present in the model) and others (vital sign assessment, location, date, and type). Also, a scheduled appointment can be considered an encounter, and this is a concept needed for adhering to the HL7 standard. Another concept needed for adhering to standards is the comorbidity of the patient, which is linked to a code in the international classification of diseases and has a name.

• ■ Additional relationships for completing the meanings: We need a structural relationship for linking the provider with a scheduled appointment and an is a structural relationship for linking a scheduled appointment to an encounter.

The encounter is one of the main terms required by the HL7 standard, which is a set of standards for easing the electronic exchange of clinical information. Even though the HL7 is intended for general diseases, the cancer patient model needs information for adhering to such a standard. The same can be applied to the International Classification of Diseases, from which the cancer diagnosis is just a part. Both standards can be met with the cancer patient model we depict with the final pre-conceptual schema shown in Figure 16. We are going beyond the encounter information and the different specificities of the cancer disease with a model easy to understand and complete enough to detail the diagnosis of the cancer while adhering to international standards. In addition, the leaf concepts we provide in our model can be exemplified and instantiated for filling in the specific characteristics of an encounter/patient/provider. This feature is completely absent from the different kinds of representation we presented in the background Section of this paper.

Source: own elaboration.

FIGURE 16 FINAL PRE-CONCEPTUAL SCHEMA AFTER ADDING THE MISSING INFORMATION 

CONCLUSIONS AND FUTURE WORK

In this paper, we proposed a pre-conceptual schema for modeling the cancer patient and their surroundings. We selected the pre-conceptual schemas for representing our solution due to the close relationship they have with knowledge representations and the five roles they can play: a model, an ontological commitment, a theory for inference, a machine-to-machine language, and a person-to-person language. We also went further with the typical restrictions of patient-based models related to cancer, commonly oriented towards a special kind of cancer and linked to the information of encounters, and we guaranteed adherence to some standards like HL7 and ICD.

Our pre-conceptual schema is the result of solving the main problems we found in the previous proposals about the information related to cancer patients in terms of informal flowcharts, architectural diagrams, and concept sketches. We also solved problems related to the coverage of the information and its level of detail.

The process for obtaining our pre-conceptual schema followed a method with the following activities: identification of concepts from the previous proposals, representation of such concepts into a pre-conceptual schema, and identification of missing information to complete the information and adhere to well-known standards.

We propose some lines of future work from the pre-conceptual schema we proposed in this paper: