Cloud service for differential diagnosis and personalized treatment of inflammatory heart diseases

.


Introduction
Diseases of the cardiovascular system are the main cause of mortality in all categories of the adult population: according to ROSSTAT, there has been a steady increase in the number of cases, especially in recent years [1,2].Diagnosis and treatment of inflammatory heart diseases (myocarditis, pericarditis, endocarditis, etc.) remains one of the most difficult sections of the work of therapists and cardiologists due to the heterogeneity and non-specificity of clinical manifestations.Latent, chronic or atypical course of diseases further increases the difficulty of differential diagnosis.A number of diagnostic algorithms have been proposed to assess the significance of the signs on the basis of which the diagnosis is based.The practice and experience of a particular doctor may not be enough to timely identify any problem that has arisen in the human body.
Decision support systems with access to a huge amount of data, advanced scientific literature and millions of case histories could help to quickly classify a difficult case, propose and justify solutions at any stage of interaction with the patient (prevention, diagnosis, treatment rehabilitation).The benefits of implementing decision support systems in the medical area are primarily expected in the early suspicion of an incipient disease, an increase in the accuracy of diagnosis, and personification of treatment of an established disease.Therefore, the development of clinical decision support systems (CDSS) using modern artificial intelligence methods is a priority task for many countries around the world today.
In recent years, with the choice of decision support systems for implementation in the medical field, interest in explainable AI has grown.Doctors with medical responsibility can hardly trust the system without an explanation of the underlying decision-making process.
The aim of this research is to develop an intelligent service for the diagnosis and treatment of inflammatory heart diseases, differential diagnosis of inflammatory with other heart diseases, explaining their hypotheses, because it is service that provides explanations that can become a useful electronic consultant for a modern cardiologist.
To achieve this goal, we have to solve the following tasks: • to choose sources of knowledge on inflammatory heart diseases, • to choose methods of forming declarative knowledge bases, • to develop knowledge bases for the diagnosis, differential diagnosis of inflammatory heart diseases, for the appointment of treatment and its correction, if necessary, in the process of dynamic monitoring of the patient's treatment process.
• to choose a method for implementing a solver and architecture of a framework with a solver for constructing a service based on declarative knowledge base, • to develop the user interface of an intelligent service (GUI), • to implement a software (intelligent service), • to form the dataset for testing the knowledge base and the service as a whole, • to choose a methodology for testing.

Close research
Automation of support for the detection or diagnosis of certain inflammatory heart diseases (myocarditis, pericarditis) is offered in numerous online symptom checkers 1 2 3 4 , knowledge on some other inflammatory heart diseases (coronary and lymphocytic endocarditis) is rarely embedded in such checkers.Also, checkers do not provide the possibility of combined diagnosis of such diseases and support for their treatment.It is due to the simplified representation of the rules of clinical decisions, as well as the presentation of the clinical picture of diseases and diagnostic rules without taking into account the temporal aspect.Such software products have proven themselves well in the calculation and  analysis of certain risks in cardiology [3][4][5].Representatives such as [6] use machine learning algorithms to identify signs and predict cardiovascular events.
At present, CDDS have been developed for the diagnosis and treatment of certain heart diseases such: as coronary heart disease [7][8][9], as a component of a patient-oriented model of cardiological rehabilitation [10], as the diagnosis and treatment of arterial hypertension [11].As for inflammatory heart diseases, we can focus on such systems as: "Infectious endocarditis", which uses a database of clinical cases of endocarditis, as well as machine learning algorithms to predict the risk of complications and choose the most effective treatment; Cardio-ECO evaluates the degree of damage to the heart valves in endocarditis using echocardiography data.A prototype of the DDS for the management of patients with infectious endocarditis [12], based on the integration of hypertext and knowledge, where qualitative data were analyzed by constant comparison.The use of the system has shown that such solutions are able to provide support for a specific patient to confirm clinical decisions and manage therapy at a higher level.
However, complex knowledge models corresponding to the system of concepts of cardiologists are required for the intellectual support of differential diagnosis and the appointment of personalized treatment of inflammatory heart diseases.Reasoning based on knowledge graphs has become widely used to support and automatically make decisions [13,14] with the development of graph representations of knowledge.In addition to graph representation of knowledge, it is important to integrate their interpreters with medical documents such as personal health records or electronic health records (EHR).Symptom checkers do not provide this opportunity.
Machine learning-based systems do not provide explanations, however there is some interpretation of the result obtained in some cases.Some symptom checkers form a brief explanation according to their simplified knowledge model.

Requirements for the CDSS
A modern electronic consultant for a doctor will be able to become a software service for process of a full diagnosis and appointment of personalized treatment of inflammatory heart diseases that will to: • use data from the EHR or similar document about the patient, • use a trustworthy knowledge base, • offer reasonable hypotheses about the preliminary diagnosis of the disease, • offer after the preliminary diagnosis a request (list) of additional laboratory and instrumental examinations, • carry out differential diagnostics of inflammatory heart diseases among themselves, as well as with other heart diseases, • offer personalized treatment options with the most favorable prognosis and explain such hypotheses about the solution, • form an explanation of the main diagnosis of the disease, or request additional observations for further examination or clarification.

Methods of developing knowledge bases
For the formation of declarative knowledge bases the ontological approach was used, which provides: • reuse of software solvers for medical diagnostics and treatment, • multivariant (i.e.different ways) and collective work on new versions of knowledge bases, • «objectification» of verification of correctness and accuracy of a knowledge base, • «comprehensibility» of knowledge represented in the knowledge base.
To form knowledgebase for diagnosis and differential diagnosis, personalized treatment requires either to choose the ready-made ontologies and make sure they are sufficient or create the new ones.Usually in a given domain there is a single ontological model or set of ontologies for different tasks.The medical portal of the IACPaaS [15] platform has been operating ontology for diagnosis of diseases and ontology of personalized treatment for more than 10 years.The ontological base is filled according to the ontological structure (representation model) and prescribed integrity limitations.
The ontological knowledge base is filled up in various ways.The knowledge described in the literature (from documents, standards, textbooks, scientific articles) can be extracted automatically.This can also be done manually by experts or engineers using specialized (ontological) editing tools.Correctness, completeness and other properties of the knowledge base quality depend on selected sources of knowledge, as well as on methods and tools of formation.In particular, manual filling involves a human factor (on the one hand, it is more conscious, responsible: at the same time an analysis of the relevance of each element is performed, on the other hand errors are expected).
The automatic extraction of patterns and associative relationships from datasets having a tabular appearance is technically attractive, but there are limitations: (a) the amount of knowledge extracted is many times less than contained in textbooks (even for simple enumerated features) (b) datasets do not cover the description of the process of disease development, options for controlled recovery.
Since none of the methods individually provides the completeness of knowledge, it is important to combine at least two options for the formation of the knowledge base.The cycle of forming and updating the knowledge base includes the stages of testing, verifying correctness on a reference set of use cases, that regularly expanded.join nowledge bases can be filled according to the needs of their users.Two options for creating a new base for a new service are common: formation of knowledge on a specific set of diseases or combination knowledge base from previously described diseases and newly created ones.
The IACPaaS platform's medical portal provides appropriate interpreting of formalized knowledge in accordance with agreements on the rules for solving these problems in medicine.At the same time, in the case of diagnosis, it is "advantageous" to work with complex knowledge base: already accumulated formalized descriptions of diagnostic knowledge of a number of diseases expand the possibilities of differential diagnosis of "new" diseases with previously accumulated ones.In all cases, knowledge interpretation is subject to testing (for example, on a set of reference cases).

Sources of knowledge of inflammatory heart diseases
Officially approved clinical recommendations and methodological guidelines of the Ministry of Health of the Russian Federation, as well as educational medical literature and scientific articles were used as a source of knowledge, since clinical cardiologists use it in their work [16,17].Recognition of such texts with full extraction of diagnostic signs and treatment methods automatically does not yet provide full extraction of the "medical meaning" available in them, especially the dynamics of the process, the course of diseases, experts on the formalization of medical knowledge were involved.Subsequent versions of the knowledge base will be created when trustworthy datasets appear, when the Ministry of Health updates clinical recommendations, as well as when interacting with experts from clinical practice interested in formalizing their experience.

Content of knowledge bases
Information resources of the service are represented by the following components: the Database of medical terminology and observations, the Knowledge base of diagnosis of inflammatory heart diseases, the Database of Pharmacological Reference, the Database of the International classifier of diseases (ICD-10), the Knowledge base on treatment of diseases, the Archive of health records.Each information resource is a source of either terms or direct knowledge to diagnosis or treatment of inflammatory heart diseases.Knowledge bases have the semantic representation, formed with the help of the knowledge editor, it allows us to ensure their formation and modification directly by experts of knowledge.The database of medical terminology and observations has been expanded with signs and observations necessary for description of new inflammatory heart diseases.
For the development of knowledge bases the complex of ontologies IACPaaS was used: «Ontology of knowledge about diagnosis of diseases», «Ontology of treatment of diseases».
Formed the Knowledge base on the diagnosis of inflammatory heart diseases includes structured formalized knowledge about the following diseases: infectious myocarditis, infectious pericarditis, acute and subacute bacterial endocarditis, acute pancarditis (4506 concepts).For its diagnosis the following are described: the forms of the disease, possible degrees of severity, the variants of etiology.Additional symptom complexes with the description of specific features are formed for the possibility of detailing the diagnosis of diseases during the medical and diagnostic process and the formation of a developed clinical diagnosis.The IACPaaS ontology of diagnostic knowledge makes it possible to apply special (complex) cases with which doctors meet in clinical practice (and such symptom complexes have been formed into the knowledge base).
Knowledge base has been supplemented and extended by the information resource Knowledge base of diseases of the cardiovascular system for the possibility of differential diagnosis of inflammatory diseases with other heart diseases.It additionally includes descriptions of such diseases as: acute myocardial infarction, angina tension, unstable angina, hypertension, etc.This resource is used by earlier developed service «Diagnosis of diseases of the cardiovascular system» [14].The description of the knowledge base for the diagnosis of diseases includes more than 5000 concepts.
For generation of recommendations on treatment the resource [18] Knowledge base on treatment of inflammatory heart diseases (1311 concepts) was formed.It combines fragments of the clinical picture of the disease, features of disease dynamics and treatment methods based on data on the clinical effectiveness of drugs.This principle will allow us to combine the standard of disease treatment and individual treatment tactics of each patient, as well as to make changes in the treatment process when new clinically significant indicators appear.Prescription of personalized treatment and its correction is possible due to the description in the knowledge base of various therapy schemes of this group of diseases, taking into account the indications and contraindications to the prescription of medicines, based on the individual characteristics of each person according to clinical, genetic, genomic and environmental factors.
3. The method of implementing the solver and the means of constructing the service join nowledge engineering methods are used to automate the solution of intellectual problems with obtaining explanations of hypotheses.For the tasks of differential diagnosis and personalized treatment, ontology, firstly, reflects the structure of the relevant domain knowledge, and secondly, establishes strategies for finding a solution or forming a result.They may depend on the essence of the task, the role of systems with knowledge bases and user preferences (for example, to propose and justify the best solution, to propose all possible solutions, to criticize each user solution, etc.).A specific strategy for hypothesizing the diagnosed abnormal process requires fully confirming some variant of the development of the process or requires finding all non-rejected variants of the development of all abnormal processes.Search strategies are a type of ontological conventions for applying explicit knowledge to specific tasks.Decision-making support for a single task (or solution generation) is performed by an appropriate software reasoner, specialized in the ontology of knowledge for this task and ontological conventions.Such a specialized Solver interprets knowledge: bypasses the ontological knowledge base, in accordance with the conventions, putting forward or refuting hypotheses, argues and collects arguments in favor of some versions, hypotheses (and against others), forming a practically useful explanation.The content of one of the ontological agreements for treatment: "it is possible to eliminate the symptom (type of problem), confirmed by the current input data, if in the knowledge base among the many periods of development (type of consequences of the problem) expected after the current period there is a period in which the symptom will be normal (a component of the normal state), and types of impacts for such consequence are indicated in the knowledge base, and the possibility of these impacts is not rejected by the current input data.
The specialized reasoner to support the solution of the problem regarding the current situation generates an explanation in accordance with the contents of the available ontological database and with agreements.An explanation with reference to possible and detectable causes, consequences, influencing factors, properties, conditions for connecting parts into a structure, etc. is useful to a qualified user.In this regard, the "most understandable" explanation will be one whose structure is close to the structure of knowledge (its analogue or its inversion) -and the essence of the used agreements.The reasoner specialized by ontology applies processing rules in the process of reasoning and searching for hypotheses: linking premises with consequences and searching for information to confirm the premises.Usually the processing has several stages.This is a search in the description of the current situation (input data) for facts to confirm the conditions for the appearance of processes (output to the report is an explanation of each confirmed condition of the process being checked and all the facts corresponding to the confirmed condition); search in the description of the current situation for facts to confirm the process flow variant (output to the report is an explanation of each verifiable flow process variant and all the facts corresponding to it); hypotheses based on confirmed and unverified premises.
When creating algorithms, information processing is distributed to work on the knowledge base, work with facts, work on fixing argumentsexplanations in the explanation report.For example, to create an algorithm for testing a hypothesis about a variant of development and substantiating a variant, one software unit works on the causal relationship "variant of development -signs" and turns to others: checking the presence of a sign (among the facts), checking the hypothesis of the correspondence of the sign value, establishing the status of the verified sign in the "explanation", establishing the status of the verified hypotheses, etc.The program unit, processing its own types of connections between information elements, makes intermediate conclusions of the logical inference process.In the solver algorithm, the procedures for deriving consequences from the processed parcels are alternately called, which record the result of checking the parcels in the explanation.The specialized reasoner was created on the IACPaaS cloud platform, (based on the ontology of knowledge and ontological conventions) and formed declaratively, integrated with the user interface (Figure 1).The reasoner was developed using an agent-based approach: the root agent provides interface functionality and user interaction with the system, and is also responsible for calling agents to perform diagnostic and treatment subtasks.The formal parameters of the solver are the labels of

GUI of Intelligent Service
The GUI of the service consists of three main parts: • Interface for entering EHR • Interface for viewing diagnostic results

• Interface for viewing recommended treatment
The interface for entering medical histories provides an opportunity to enter all available information on the disease (Figure 2).
The peculiarity of the interface for EHR is that it automatically forms and connects knowledge based on heterogeneous ontologies.This ensures a high speed of entering structured case histories based on many different large formalized databases of medical knowledge.Let's take a closer look at how this happens in practice.
Figure 3 shows (in a slightly simplified way) two ontologies that need to be correlated with each other to automate the entry of a sign from the dataset of EHR.On the one hand, these structures are quite similar, because, in fact, they are a description of a feature and, in particular, even have completely identical elements.But, on the other hand, these  structures are far from a complete coincidence: so in the ontology on the right you can see: (1 ) some auxiliary elements ("Type of possible values"), (2 ) division of the attribute into subtypes ("Simple attribute", "Composite attribute").
These structures were not designed the same during ontological engineering, although both are responsible for the essence of "sign", since they are intended for different purposes: the structure of a sign in the EHR is aimed at introducing signs with specific meanings, while in the Database of medical terminology and observations -to describe all variants of the values of the sign, synonymy, normal and reference ranges.For example, the sign "Body temperature" in the EHR will have some specific value, for example, 37.0, and in the Database of medical terminology and observations it will have ranges of values (for example, 35-42).In addition, the idea of automating the creation of the interface is also to try not to depend on the exact coincidence of data structures, but, on the contrary, to provide maximum flexibility in the ability to connect arbitrary knowledge bases with their mismatched structures.Thus, in this task we have two heterogeneous knowledge structures that still need to be automatically correlated with each other.To implement this task, it is proposed to introduce additional structure -a table in which the necessary special relationships will be described to establish correspondence between heterogeneous ontologies.Each Element in this structure describes an element of the initial ontology that must be transformed for the structure of the final ontology.The "Goal" field describes how the "Element" of the initial ontology should be represented in the final one.The following options are possible: if the "Goal" contains a non-null string value, then the element of the initial ontology is renamed according to this value.If the "Goal" does not contain any value or contains the value "null", then this means that the Element of the initial ontology must be "cut out" from the structure of the final ontology.At the same time, "cut out" an element does not mean deleting this element, but only hiding its title, all successor elements of this Element become successor of its parent element (the hierarchical structure of the tree changes).The "Succerssor element" field, on the contrary, serves to ensure that the child element that the specified Element has appears in the final ontology.At the same time, it appeared not as an empty new element, but as an intermediate parent node between the current elements in the final ontology (i.e., the hierarchical structure of the tree is changing again).
To view in the EHR all the entered signs and their characteristics, a hierarchical unfolding tree is provided in the interface.Some branches of this tree are interface-transformed into one, simplifying the visualization of the structure by hiding long chains of knowledge structures that do not affect the result.To introduce new knowledge, the user is provided with a search interface.The interface provides a mechanism for specifying the search by several key criteria-substrings entered through a space.The search can take into account both parts of feature names, their characteristics or string content, and auxiliary information about knowledge, for example, synonymy.
The interface for viewing diagnostic results displays diagnostic results in different forms, depending on the diagnostic results.In case of lack of any data or knowledge, the interface displays all the necessary information and provides an opportunity to enter additional data, automatically performing part of the search work for the user.If the information is

Construction an intelligent service with an evolving knowledge base
On the medical portal of the IACPaaS platform, intelligent services are built as an "assembly" of software components (a specialized solvers) with information (formalized knowledge in the form of knowledge base).Such assembly is based on the development from single ontology.Before linking, each component is tested in the IACPaaS portal with its own test suites.Checking diagnosis' knowledge base requires sets of EHR, where the patient has been successfully diagnosed.Correctness and accuracy are checked.The knowledge base check for personalized treatment requires such EHR kits where the patient has been cured or stabilized.Correctness and completeness are checked.After the assembly, the process of which takes a few minutes, the assembled service is tested on an existing control set of cases (EHR) with the solution of both required subtasks: correct diagnosis and successful treatment (see Figure 4).All participants are responsible for quality.
The possibility of supplementing and expanding knowledge bases, assessing their adequacy and relevance is due to the ontological approach, which allows you to read and edit the knowledge base in familiar terms.It is required to manage diagnostics knowledge base in connection with the discovery of new knowledge: the revealed dependencies of the development of diseases on the categories and characteristics of patients, published (and formalized in accordance with the ontology).The adaptation of clinical system and the management of knowledge base is carried out directly through the transfer of new information into a structured knowledge base with its verification on the existing control set of EHR (or sets of precedents).The addition of a variant of a course of some disease to those already previously formed structured knowledge that will be tested on control set of EHRs is used (automated methods of further verification are used).After positive test results on the EHR control set, the received knowledge base with a new version ("branch" in the structured knowledge base) will be sent to the manager to replace the previous version.
It is necessary to manage treatment' knowledge base in connection with the discovery of new methods of treatment or information about new effects of drugs on patients with specific characteristics.To manage the knowledge base, the addition of a disease treatment option or conditions is used in the formed structure of the model, scheme and type of treatment.The methods of testing the proposed treatment on the EHR control set do not allow us to conclude that the treatment is incorrect if no new method was used in any EHR.But it is required during verification that the updated knowledge base allows you to form a solution with options, one of which is specified in the control case.

Testing materials and testing methodology
At the stage of certification testing an information resource "reference set of real cases" is used to verify the correctness and sufficiency of the knowledge base.
In this set, it is most effective to combine cases (EHR) from the archives of experts, and from developers and from medical users.In this set, it is most effective to combine cases -EHR from the archives of experts, and from developers and from medical users.Based on the flow of such cases (from practice), it is expected that the true diagnosis (documented in EHR) in every case will either be confirmed by the service or not refuted (with the predominant number of confirmed necessary signs).For the cases with a confirmed diagnosis, the tester expects that the service will prescribe the treatment option that corresponds to real case (prescribing all the same medicines or analogues from the same pharmaceutical group).In connection with revealing case from practice (precedent) that does not correspond (or contradict) the explicitly described expert knowledge in a particular knowledge base (or revealing such precedents set), the expert decides either to transfer it (they) to the database of special cases (for application in the search "by the proximity method"), or in training sample (for application in inductive methods).In some cases, the expert may decide to supplement the knowledge base with new formalized knowledge.
The next stage of testing is related to recommended therapy.With clinical compliance of knowledge and medical history data, a therapy scheme is proposed, including drug name, its dosage with a description of intake regimen and duration of its use.
To check the operation of the developed AI service, an EHR archive was created with a reference set of real cases (Figure 5) taken from open publications from the Internet space (on such resources as: www.lvrach.ru,https://cyberleninka.ru , http://heart-master.com , https://www.heartj.asiaand others).10 cases from the compiled collection are uploaded as a dataset (in json format) to https://disk.yandex.ru/d/BF0mSxMufjn0Rg).
The examples of real cases that influenced the improvement of service knowledge.
Example 1.A case study "Acute myocarditis under the guise of myocardial infarction with ST segment elevation" was found in the literature [19].The service recognized it as a case of a heart attack.Therefore, for this variant of disease course, a new symptom complex was been formed: with a description of additional values of signs (complaints, objective examination, laboratory and instrumental data).Then EHR was once again submitted to the service input.The system proposed two hypotheses about the preliminary diagnosis, after the introduction of additional data, the system performed a differential diagnosis with an explanation, testing of the diagnosis was successful.
Example 2. On the medical scientific and practical portal Lvrach.ru, a variant of the atypical course of myocarditis was found «Difficult diagnosis.Acute myocardial infarction or myopericarditis?».After using the case as a test case for the service with the knowledge base, it was decided to add this manifestation option to the database of special cases.
Based on real cases with five myocarditis and five other cases of heart diseases found in open publications (posted in the json dataset), the following results were obtained using the service with knowledge base including different cardiovascular diseases, the following results were obtained.4 true: 4 diagnoses were confirmed, 5 cases received several hypotheses, including the true diagnosis (they had some confirmed signs, the remaining signs were requested), one case turned out to have atypical clinical the picture (and was placed in the special cases database, also used to support the doctor's decisions); for six, treatment similar to the control cases was offered -pharmacological groups of drugs coincided, and for three of the described real cases there was insufficient data in EHR for personification of treatment.
The tested cases were also used to compare the capabilities of other five available medical assistance internet-services.Almost none of them could be fully diagnosed, because their vocabulary of observations is minimal (and not beeing expanded, as follows from repeated experiments at intervals of 3-6 months).There is no way to access EHR, you have to spend time on a new re-entry.For the cases with many observations (from 12 to 35), only a part of them (from 25 to 80%) could be inputed, and the true diagnosis was in the top 5 only in six cases.There are either no explanations, or they are questions with a "yes" answer; at best, a list of those inputed deviations from the norm that are inherent in the hypothesis is displayed.Only one in five such services treats heart disease, but the result differs from that proposed in control cases.There is no explanation.Thus, it was concluded that the available services are not integrated with medical records and do not provide detailed explanations, and the correct hypotheses are given for cases that are obvious or well described in the recommendations.Adaptation to new knowledge there is only in two services; there are no opportunities to expand the vocabulary.

Some labor cost estimates
The Ontology of knowledge about diagnosis of diseases was the result of specialists activity over several years, and after successful approbation in research teams, it became the basis for production of CDSS for various nosologies.It took five man-months to form a knowledge base on inflammatory heart diseases (myocarditis, pericarditis, endocarditis, etc.), including a search in the literature for special, complex cases, as well as the creation of reference EHRs to check knowledge quality.The knowledge base will change as clinical recommendations of the Russian Ministry of Health are updated.It can be supplemented as authoritative sources on new diagnostic and treatment methods become available.
In parallel, knowledge bases for other diseases are being created on the basis of this ontology.It is recommended to combine bases or blocks of knowledge on different diseases for the sake of differential diagnosis.The previously formed block of knowledge on heart attacks and angina pectoris was added to the knowledge on inflammatory heart diseases for this purpose.
Regularly (at least 2 times a month), 2 specialists participate in maintaining relevance and improving of the knowledge base: searching new knowledge (for example, additional variants of disease course manifestation), searching for control cases from practice, checking with their application the quality of solutions, conducting a knowledge refinement procedure.
Because solver and interface do not depend on nosologies, then when adding/changing the knowledge base, no modifications of the program code are required.Which is essential when systems operating.
In the case of automation of medical activities through the "cloud" systems, doctors will have to enter all the data into the proposed DSS.However, this process is supported, all the required terms for describing the patient's condition are supported by a quick entry line for the corresponding sections of the EHR.(For integration with electronic medical records of Medical information systems, state support is needed.) In the cloud paradigm, savings are expected at times due to a single knowledge update center and its regular checks on a single accumulated cases base.The experts can manage the quality of knowledge bases through cloud-accessible tools.

Conclusion
The paper describes basic principles of creating and method of implementation of clinical DSS for differential diagnosis and treatment planning for patients with inflammatory heart diseases.The ability of the service to generate detailed explanations is ensured by its implementation based on an ontological approach.
Ontological knowledge bases for diagnosis and treatment have formed on the basis of corresponding ontologies previously created by the team and tested for other nosologies.The choice of this implementation method is due, also to the need for knowledge bases evolve or change (to bring them into line with the new versions of the clinical recommendations of the Ministry of Health) without changing the solver code.Moreover, on the basis of the corresponding ontologies, the possibility of integrating IACPaaS services with various medical information systems has been tested: a data converter was made from the ontological medical history for data transmission.The formed knowledge bases can be upgraded, for example, expanded by experts.The platform's infrastructure offers tools for this and supports the replacement of knowledge components in an already operational DSS.Although such a replacement is technically carried out "instantly" on the IACPaaS platform, before being put into operation, updated service with knowledge base is tested on set of control and reference cases.
Thus, the implementation of the service on the IACPaaS platform provides the possibility of its continuous development.
Currently, the service is hosted on the platform https://iacpaas.dvo.ru, login -medicine-services@mail.ru (the password is sent on request to the author of the article or the IACPaaS administrator).

1 Symptom 3 "
Checker is developed by a group of professional doctors of various specialties of the Saint Antipas Polyclinic and programmers 2 Healthdirect.Symptom cheker helps Australians to find proper healthcare provider Artificial intelligence Kiberis -individual medicine" is a medical assistant based on artificial intelligence for diagnostics and personalized therapy, selection of drug analogs, checking the safety of prescriptions and auto-filling a medical record.

4 «
ASCVD Risk Estimator Plus» of American cardiology college.

Figure 1 .
Figure 1.Scheme of a specialized reasoner

Figure 2 .
Figure 2. EHR input interface the ontological knowledge bases and input information resources (sets of EHR).

Figure 4 .
Figure 4.The fragments of a dialogue with a doctor when analyzing a possible solution sufficient, the interface displays a complete picture of the diagnosis with detailed explanations for each criterion.The recommended treatment viewing interface displays treatment options in the form of a hierarchical tree in which you can see all the necessary information on treatment methods, medications, periods of their use, etc.