=Paper=
{{Paper
|id=Vol-2753/paper44
|storemode=property
|title=Medical Content Processing in Intelligent System of District Therapist
|pdfUrl=https://ceur-ws.org/Vol-2753/paper29.pdf
|volume=Vol-2753
|authors=Vasyl Lytvyn,Andrii Hryhorovych,Viktor Hryhorovych,Lyubomyr Chyrun,Victoria Vysotska,Myroslava Bublyk
|dblpUrl=https://dblp.org/rec/conf/iddm/LytvynHHCVB20
}}
==Medical Content Processing in Intelligent System of District Therapist==
Medical Content Processing in Intelligent System of District Therapist Vasyl Lytvyna, Andrii Hryhorovychb, Viktor Hryhorovycha, Lyubomyr Chyrunc, Victoria Vysotskaa and Myroslava Bublyka a Lviv Polytechnic National University, S,.Bandera street, 12, Lviv, 79013, Ukraine b Drohobych Ivan Franko State Pedagogical University, I.Franko street, 24, Drohobych, 82100, Ukraine c Ivan Franko National University of Lviv, University street, 1, Lviv, 79000, Ukraine Abstract The processing by the district therapist data in this article is analyzed. All documents and reports that exist in the subject area are considered. It is substantiated that non-normalized relations describe the subject area most adequately. With the help of non - normalized relations, a model of data of the system of district therapists is built. Keywords 1 Non-normalized relationships, nested relationships, subject area analysis, medicine, disease data about diseases, accounting 1. Introduction The first stage of creating any information system is the description and modeling of the subject area. The problem of adequate data presentation at this stage does not lose its relevance. The classical relational data model is not adequate in an extremely wide range of applications. Various programs of processing databases, such as systems for getting information ( Information Retrieval Systems ) or system of automatic design and manufacturing (Computer - Aided Design and Manufacturing , CAD / CAM) require handling structured entities. Non-normalized relations [1] successfully solve the problem of representation of nested entities. 2. Analysis of recent researches The possibilities of non-normalized relationships are implemented in many DBMS on the market (System 2000 and ADABAS [2], OASIS [3], IMS [4], EXODUS [5], POSTGRES [6], Oracle [7, 8]) and are widely used in many parts of human activity [9]. Special attention deserves automation in the field of medicine [10-13]. Thus, researchers have recently published a number of works that: Use technologies of inaccurate sets to derive rules from the data table and further assess the quality of the classifier based on these rules [10]; A hypercube of data for the ambulance service is built and operations with it are described, in particular - an algorithm for constructing a decision tree and forming a set of dependencies [11]; The peculiarities of the researched area are described and the ways of presenting hierarchical information as lists and frames are considered, the information restructuring scheme is given [12]; IDDM’2020: 3rd International Conference on Informatics & Data-Driven Medicine, November 19–21, 2020, Växjö, Sweden EMAIL: Vasyl.V.Lytvyn@lpnu.ua (V. Lytvyn); a.hryhorovych@gmail.com (A. Hryhorovych); viktor.grigorovich@gmail.com (V. Hryhorovych); Lyubomyr.Chyrun@lnu.edu.ua (L. Chyrun); victoria.a.vysotska@lpnu.ua (V. Vysotska); my.bublyk@gmail.com (M. Bublyk) ORCID: 0000-0002-9676-0180 (V. Lytvyn); 0000-0002-5361-8854 (A. Hryhorovych); 0000-0002-5828-067X (V. Hryhorovych); 0000- 0002-9448-1751 (L. Chyrun); 0000-0001-6417-3689 (V. Vysotska); 0000-0003-2403-0784 (M. Bublyk) ©️ 2020 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). CEUR Workshop Proceedings (CEUR-WS.org) The formation of the knowledge base in the form of logical functions by finding patterns in databases about patients and building on their basis a system of making a decision for predicting diagnosis are described [14-18]; Comparing the impact of ways of choosing a set of examples to build a decision tree on the quality of prognosis are made [19-24]; Assessment of dependence quality of prognosis in a group of patients with different methods of discretization of a continuous parameter, which is the patient's age, is given [25-29]; Recommendations considering organization of the data preparation process aware also given [13]. Thus, the problem of implementation of information technology in medicine is important and urgent; an enormous amount of publications of different kinds is devoted to it. 3. Setting the intent of the article Analysis of subject area for information system of processing medical information, which is contained in the medical passports and other documents and is used, for example, used by district therapists, is given in this research. The required information about the structure of data and tasks, which are solved in the subject area, provided by the district therapist of Drohobych medical district number 13 - Bihunyak Halyna Yaroslavivna. The purpose of the article is to show that an adequate data model for the system of processing of medical information can built with the help of non-normalized relations. 4. Documents and forms that formed and processed by the district therapist The professional activity of a district therapist is to treat patients of a medical district. The effectiveness of this work largely depends on the objectivity and completeness of information about the patient's health, previous illnesses and medications. Thus, the designed information system must ensure the accumulation of information and its effective processing. The main source of data is a medical passport. In the current practice, the medical passport (form number025/о of medical documentation) performs the task of information accumulation. A medical passport is issued for each patient in order to accumulate medical information. In addition, a sheet with immunization, a sheet with health insurance and a least of major deferred diseases and surgical interventions are filled. Each time during the examination of the patient by the district therapist, the relevant data are entered. The diagnosis (primary, clarifying, final) is determined, information on treatment, data on temporary incapacity for work is recorded and the date of control appearance is appointed. If necessary, the results of specialist consultation and laboratory tests are entered. The general structure of the form of the Medical passport is shown in Fig. 1 – as rectangles are marked sub - tables. It is seen that the information contained in the medical passport, it is natural to present through non-normalized (nested) relationships. We should note that not every sub-table is a nested relationship - if the sub-table contains only one row (such as the value of the field "blood type" in the sub-table Signal marks for life), then such an attribute should transferred from the nested relationship to the level up. In addition, there are sub-tables (for example, Critical diseases) that contain only other sub-tables and do not contain atomic attributes. In this case, there is no need to create a separate nested non- normalized relation for the external sub-table. It is easier to represent the internal sub-tables by nested relations of the first level of the hierarchy - see Fig.1 (the proposed relations are marked on the right above the corresponding rectangles) and Fig. 2 (general structure of the relationship Medical passport - dotted lines indicate relationships that may be empty). Let us consider the structure of the abnormal relation R 1 (Medical Passport) in more detail. Its atomic attributes and nested relationship can described of next so. Primary key attributes: K1a (District code) and K1b (Patient code). The domains of the attributes a1 (Surname), b1 (Name), c1 (Patronymic), f1 (Passport) are letter strings - previously unknown values, the domain of the attribute d1 (Date of birth) are valid dates of birth. The e1 (Gender) attribute can only take two values: "M" and "W". The g1 (Address) attribute is actually compound: g1 ≡ {g1a, g1b, g1c, g1d}, although it is not reflected in the form of a medical passport - it consists of the attributes g1a (Settlement), g1b (Street), g1c (House number), g1d (Apartment number). Attribute domains g1a and g 1b contain the names of settlements and streets that are part of the site. Therefore, it cannot be arbitrary letter strings: when designing a data scheme, it would be a good idea to provide directory tables with the names of settlements and streets, which will be the values of the substitution for the attributes g1a and g1b. Figure 1: General structure of a medical passport Figure 2: General structure of non-normalized relationship The user must update these directory tables. The domain of the g 1c attribute also contains letter strings (because the house number can also include the case number, for example "89/2"), but it is impractical to create a separate reference table for the values of house numbers. Finally, the domain of the g1d attribute contains integers - valid apartment numbers. It should be noted that dom(g1d) - that is, the attribute g1d can take empty values ( NULL ) in case the address does not contain an apartment number (private house). The h1 (Home phone) domain of attribute contains letter strings that are phone number values (or NULL values if there is no phone). Domain of attributes i1 (place of work or study) and k1 (Occupation) contains literal string or the value NULL, - should provide relevant and tables and - directory tables should be updated by the user. Attribute l1 (Retirer) - compound (l1 ≡ {l1a, l1b}) - it describes whether the patient is retired and gives the characteristics: l1a - from what year the patient retired and l1b - reasons for it. If the patient is not retired, the attributes {l1a, l1b} will be empty. The attribute domain l1a (From year) contains integers whose value is the year of retirement. Attribute l1b (Cause) acquires one of the values "by illness", "by length of service", "by age" (fixed set of values from which the choice is made), "other reason" - an arbitrary text value entered by the user - these values should be selected from the directory table that is updated by the user. Attribute m1 (Attached for medical examination) - is also composed: m1 ≡ {m1a, m1b}. The domain of the attribute m1a contains the numbers of medical sites (integers or NULL values), and the domain of the attribute m1b - their names (letter strings) or NULL values, you should implement a directory table of names of sections, the values of which will be updated by the user. The domain of attribute n1 (Special account) is the value NULL or letter strings, which acquire the following values: "participant in the war", "liquidator of Chernobyl", "pupil", "student", "lonely", "repressed" - they should provide the appropriate reference table that can be updated by the user. The domain of attribute o 1 (Blood group) contains only four values («I», «II», «III», «IV»), attribute p 1 (Rhesus factor) acquires only one of two values («+», «-»). The domain of the attribute r 1 (Observed in … from… year) is the value NULL or integers - the corresponding years. Thus, we obtain a refined scheme of atomic attributes of the non-normalized relation R1 and the domains of the values of these attributes can described as follows: dom (R1.K1a) { integer } dom (R1.K1b) { integer } dom (R1.a1) { varchar } dom (R1.b1) { varchar } dom (R1.c1) { varchar } dom (R1.d1) { date } dom (R1.e1) { varchar } {“M”, “W”} – only fixed values dom (R1.f1) { varchar } dom (R1.g1a) { varchar } directory table which is updated by the user dom (R1.g1b) { varchar } directory table which is updated by the user dom (R1.g1c) { varchar } dom (R1.g1d) { integer } dom (R1.h1) { varchar } dom (R1.i1) { varchar } directory table which is updated by the user dom (R1.k1) { varchar } directory table which is updated by the user dom (R1.l1a) { integer } dom (R1.l1b) { varchar } directory table which is updated by the user dom (R1.m1a) { integer } dom (R1.m1b) { varchar } directory table which is updated by the user dom (R1.n1) { varchar } directory table which is updated by the user dom (R1.o1) { varchar } {“I”, “II”,“III”, “IV”} – only fixed values dom (R1.p1) { varchar } {“+”, “–”} – only fixed values dom (R1.r1) { integer } The nested relation R1.1 (pathogenic carrier) consists of two attributes a1.1 (Year) and b1.1 (Name). The domain of attribute a1.1 (Year) contains integers; and the domain of the attribute b1.1 (Name) - the corresponding letter strings "staphylococci", "streptococci", "HIV", and "viral hepatitis antigen". For improve the processing of this data it will be necessary to implement a directory table that contains lists of relevant values and can be updated by the user. Each of the three nested relationship R1.2 (Chronic and occupational diseases), R1.3 (Past surgery), R1.4 (Past infectious diseases) consists of two attributes: Name of illness or surgery - а1.2, а1.3, а1.4 and Year - b1.2, b1.3, b1.4. The domains of the attributes а1.2, а1.3, and а1.4 (Name of the disease or operation) will be a set of letter strings - so you should think about the appropriate directory table that will supplemented by the user. The domains of attributes b1.2, b1.3, b1.4 (Year) will be integers. The nested relation R1.5 (Special marks - lifelong) contains three attributes a1.5 (Privilege category), b1.5 (identity card number), and c1.5 (Seal and signature of the head of the department). The nested relation R1.6 (Special marks- variables) contains three attributes a1.6 (Name), b1.6 (Year), c1.6 (Doctor's signature). The domain of the attribute a1.5 (Privilege category) will be the letter rows that should select from the directory table to populate by the user. The domains of attributes c1.5 (Seal and signature of the head of the department), a1.6 (Name) and c1.6 (Doctor's signature) will be arbitrary letter lines; a domain attribute of b1.5 (Identity card number) and b1.6 (Year) - integers. The nested relation R1.7 (Dispensary group) contains two attributes a1.7 (Year) and b1.7 (Group). The domain of the attribute a1.7 (Year) will be integers; and the domain of the attribute b1.7 (Group) - letter strings ("D1", "D2", "D3", "D4"). The nested relation R1.8 (Letter of preventive vaccinations) contains the attributes a1.8 (Name), b1.8 (Date), c1.8 (Dose), d1.8 (Series), e1.8 (Reaction), f1.8 (Signature). The domain of the attribute a1.8 (Name) will be the letter rows that should selected from the directory table to be populated by the user; domain attribute b1.8 (Date) - valid dates. The domain of the attribute c1.8 (Dose) consists of real numbers. The domain of attributes d1.8 (Series), e1.8 (Reaction) and f1.8 (Signature) will be arbitrary letter strings. The nested relation R1.9 (Letter of voluntary health insurance) contains the attributes a1.9 (Insurance company), a1.9 (Type), c1.9 (Amount), d1.9 (Term: from), e1.9 (Term: to), f1.9 (Signature). Domain of attributes a1.9 (Insurance Company) and b1.9 (View) will be alphabetic strings, which should selected from the table – directory table that will updated by the user; attribute domain c1.9 (Amount) - monetary values. The attribute domains d1.9 (Term: from) and e1.9 (Term: to) will be valid dates. The domain of the attribute f1.9 (Signature) consists of arbitrary letter strings. The nested relation R1.10 (Temporary disability) contains the attributes a1.10 (Start date), b1.10 (End date), c1.10 (number of letter or certificate), d1.10 (Name of disease), e1.10 (Information about hospitalization), f1.10 (Doctor's signature). The domains of the attributes a1.10 (Start Date) and b1.10 (End Date) will be valid dates. Attribute domain c1.10 (number of letter or certificate) - arbitrary letter strings; the domain of the attribute d1.10 (Name of the disease) will be the letter rows that should selected from the reference table, which is filled in by the user; the attribute domains e1.10 (Information) and f1.10 (Doctor's Signature) consist of arbitrary letter strings. The nested relation R1.11 (Disability) contains the attributes a1.11 (Date of certification and re- certification), b1.11 (number of certificate), c1.11 (Name of disease), d1.11 (Category), and e1.11 (Signature of the head of department). The domain of attribute a1.11 (Date of certification and re-certification) consists of valid dates. The domain of attribute b1.11 (number of certificate) contains arbitrary letter strings; the attribute domains c1.11 (Name of disease) and d1.11 (Category) will be the letter rows that should selected from the corresponding user table -reference books. The domain of attribute e1.11 (Signature of the head of department) consists of arbitrary letter strings. The nested relation R1.12 (Letter of final (revised) diagnoses) contains the attributes a1.12 (Date), b1.12 (Final (revised) diagnosis), c1.12 (Diagnosis established), and d1.12 (Doctor's name). The domain of attribute a1.12 (Date) consists of valid dates. Attribute domain b1.12 (Final (refined) diagnosis) contains letter rows that should selected from the reference table to populate by the user. The domain of the attribute c1.12 (Diagnosis established) consists of the letter values "+", "-". The domain of the attribute d1.12 (Doctor's last name) contains arbitrary letter strings. The nested relation R1.13 (Review therapist) contains the attributes: a1.13 (Date), b1.13 (Complaints), c1.13 (History), d1.13 (General condition), e1.13 (Revitalisation), f1.13 (Skin), g1.13 (Lymph nodes), h1.13 (Thyroid gland), i1.13 (Bone and joint system), j1.13 (Frequency of respiration in one minute), k1.13 (Respiration in the lungs), l1.13 (Percussion pulmonary sound), m1.13 (Heart tones), n1.13 (BP), o1.13 (Pulse), p1.13 (Oropharynx), q1.13 (Teeth), r1.13 (Tonsils), s1.13 (Other data), t1.13 (Abdominal palpation), u1.13 (Liver), v1.13 (Chair), w1.13 (Urination), x1.13 (Edema), y1.13 (Additional information), z1.13 (Diagnosis), aa1.13 (Group of follow-up), ab1.13 (L / leaf number), ac1.13 (From), ad1.13 (To), ad1.13 (Regime), af1.13 (Active surveillance), ag1.13 (Control visit), and ah1.13 ( Doctor ). The scheme of connections of the non-normalized relation R1 with all reference tables is shown in Fig. 3 (directory table with fixed attribute of values is marked with a shaded rectangle with a bold font; relationships that can be empty are indicated by a dotted outline). Figure 3: The relations scheme for the non-normalized relation Medical passport with directory tables If necessary, the doctor refers the patient for examination with the help of a referral c for consultation, examination, procedure, transfusion. The scheme of connections of non-normalized relation R2 with its references - in Fig. 4. The non-normalized relation R2 (A referral for consultation, examination, procedure, transfusion) contains the attributes: a2 (Date), b2 (Where), c2 (Doctor's code), d2 (Doctor's name), e2 (Patient's name) ), f2 (Patient's name), g2 (Patient's father's name), h2 (Settlement), i2 (Street), j2 (House), k2 (Apartment), l2 (Directed), and nested relation R2.1 (Consultations, studies, procedures, transfusions). The nested relation R2.1 is filled in during consultations, surveys, etc. and contains the attributes a2.1 (study code) and b2.1 (performer code). Figure 4: The scheme of connections of the non-normalized relation referral coupon for consultation with directory tables Results of laboratory tests, fixed on appropriate standard forms, were receive from the laboratory department: Analysis of blood - a form number225/о.; Urine analysis - form number 45, Analysis of fecal for helminths and protozoa - a form number220 /o , Liver function tests , biochemical analysis of blood - a form number228 / o , Analysis of sputum. These documents do not contain sub-tables and are represented by using relations R3 , R4 , R5 , R6 , R7 , R8. The relation of R3 (Blood test) is a flat table. It contains the attributes a3 (Surname), b3 (Name), c3 (Patronymic), d3 (Settlement), e3 (Street), f3 (House), g3 (Apartment), h3 (Division), i3 (HB), j3 (Erythrocytes), k3 (Leukocytes), l3 (ESR), m3 (Haematocrit), n3 (Date), o3 (Signature). The scheme of relations of the relation R 3 with its directory table is shown in Fig. 5. Figure 5: The scheme of connections of the relation analysis of blood with directory table The relation of R4 (Urine test) is a flat table. Its attributes are a4 (Laboratory), b4 (Surname), c4 (Name), d4 (Patronymic), e4 (Department office), f4 (Quantity), g4 (Colour), h4 (Transparency), i4 (Specific gravity), j4 (Reaction), j4 (Protein), l4 (Sugar), m4 (Acetone), n4 (Bile pigments), o4 (Urobilin), p4 (Indicant), q4 (Epithelium - flat), r4 (Epithelium - transitional), s4 (Epithelium - urethral), t4 (Epithelium - renal), u4 (Leukocytes), v4 (Erythrocytes - unchanged) ), w4 (Erythrocytes - changed), x4 (Cylinders - gealin), y4 (Cylinders - granular), z4 (Cylinders - waxy ), aa4 (Cylinders - epithelial), ab4 (Cylinders - cylindroids), ac4 ( Mucus). The scheme of connections of the relation R4 with directory table is shown in Fig. 6. Figure 6: The scheme of connections of the relation Urine test with directory tables The relation of R5 (Fecal analysis) is a flat table (Fig. 7). Its attributes: K5 (number analysis) - identifying, a5 (Date of biomaterial collection), b5 (Surname), c5 (Name), d5 (Patronymic), e5 (Age), f5 (Institution ), g5 (Department), i5 (Eggs of helminths - is) - the set of its values: {«+», «-»}, j5 (Eggs of helminths), k5 (Fragments of helminths), l5 (The simplest), m5 (Date of issue of the analysis), n5 (Laboratory assistant). There is a connection between the attributes i5 and j5: if i5 = «–», then j5 is empty (NULL). In fact, there are ambiguous and functional depending’s: i5 j5 and j5 i5. The relation of R6 (Liver function test) is a flat table (Fig. 8). Its attributes - K6a (date), K6a (number of analysis) - identifying, a6 (Name), b6 (Surname), c6 (Middle name), d6 (Department), e6 (Chamber), f6 (Bilirubin - total), g6 (Bilirubin - direct), h6 (Bilirubin - indirect), i6 (Sulem test), j6 (Thymol test), k6 (Veltman test), l6 (B-lipoproteins), m6 (ACT), n6 (ALT), o6 (Cholesterol), p6 (Signature of the laboratory assistant). The relation of R7 (Biochemical analysis of blood) is a flat table (Fig. 9). Its attributes are a7 (Date), b7 (Surname), c7 (Name), d7 (Patronymic), e7 (Age), f7 (Institution), g7 (Department), i7 (Total protein), j7 (Albumin), k7 (Globulin), l7 (1), m7 (2), n7 (), o7 (), p7 (Fibrinogen), q7 (Lipids total), r7 (Total cholesterol), s7 ( Triglycerides), t7 (Total phospholipids), u7 (-lipoproteins), v7 (Total bilirubin), w7 (Direct bilirubin), x7 (Bilirubin indirect), y7 (Potassium), z7 (Sodium), aa7 (Calcium), ab7 (Magnesium), ac7 (Iron), ad7 (Phosphorus), ae7 (Chlorine), af7 (Alanine aminotransferase), ag7 (Aspartate aminotransferase), ah7 (amylase), ai7 (Creatine phosphokinase), aj7 (Lactate dehydrogenase), ak7 (Alkaline phosphate), al7 (Cholinesterase), am7 (Other), an7 (Date of issue of the analysis), ao7 (Laboratory assistant). Figure 7: The scheme of connections of the relation fecal analysis with directory tables Figure 8: The scheme of connections of the relation for liver function test with directory tables Figure 9: The scheme of connections of the relation for biochemical analysis of blood The relation of R8 (Analysis of sputum) is a flat table (Fig. 10). Its attributes are a8 (Surname), b8 (Name), c8 (Patronymic), d8 (Settlement), e8 (Street), f8 (House), g8 (Apartment), h8 (Department), i8 (Colour), j8 (Character), k8 (Macrophages), l8 (Leukocytes), m8 (Erythrocytes), n8 (Epithelium squamous), o8 (Eosinophils), p8 (Kurshman Spiral), q8 (VC), r8 (Flora), s8 (Attila cells), t8 (Pnevmotsysty), u8 (Charcot-Leyden Crystals), v8 (Сells of heart defects), w8 (Dietrich cells), x8 (Laboratory assistant). Figure 10: The scheme of connections of the relation for biochemical analysis of blood During the doctor`s appointment, information about each patient with acute cerebral is filled Statistical coupon for registration of final (specified) diagnoses (medical documentation form number025-2 / o) , which is represented by the relation of R9, and is maintained an Outpatient sheet. Relation R9 (Statistical form for registration of final (revised) diagnoses) -a flat table (Fig. 11). Its attributes are a9 (Surname), b9 (Name), c9 (Patronymic), d9 (Age), e9 (Gender), f9 (Location), g9 (Street), h9 (House), i9 (Apartment), j9 ( Precinct ); k9 (Does he live in the service area) - its value is "yes" or "no"; l9 (Type of diagnosis) - its value is "final" or "specified"; m9 (Diagnosis); n9 (diagnosis that is for the first time) - its value is "+" or NULL; o9 (ICD-X code), p9 (Instead of a previously established diagnosis), q9 (Contingents), r9 (When the disease is detected), s9 (Type of injury and poisoning), t9 (Date), u9 ( Doctor ). Since the document form Outpatient sheet contains a sub-table, it can represented by the non- normalized relation R10 (Fig. 12). Figure 11: The scheme of connections of the relation of Statistical form for registration final diagnoses Figure 12: The scheme of connections of the non-normalized relation for Outpatient leaflet The non-normalized relation R10 (Outpatient leaflet) contains the attributes a10 (Date), b10 (Doctor), c10 (Office), d10 (Code of the place of doctor`s appointment) and the nested relation R10.1 (Record of doctor`s appointment). Attributes of the nested relationship R10.1 (Record of doctor`s appointment): a10.1 (Surname), b10.1 (Name), c10.1 (Patronymic), d10.1 (Year of birth), e10.1 (Settlement), f10.1 (Street) ), g10.1 (House), h10.1 (Apartment), i10.1 (Reason code of going to the doctor ); j10.1 (Change of dispensary group ) - its values are "D1", "D2", "D3", "D4", NULL; k10.1 (Diagnosis of the reason for going to the doctor ), l10.1 (Diagnosis that has been established so far); m10.1 (Dynamics - D / LF), n10.1 (Dynamics – opening date), o10.1 (Dynamics - continuation), p10.1 (Dynamics - closing date), q10.1 (When an operation, a procedure, a manipulation are done), r10.1 (The case is over) - its value is "+", "-". If necessary, the doctor writes a prescription (medical documentation f-1), fills in The card of the patient of the day hospital , the inpatient care at home (form number 003/2-o) and Extract from the medical card of an outpatient, inpatient ( form number027 / o) , which are submitted by relations R11, R12 and R13 respectively. The relation of R11 (Recipe) is a flat table (Fig. 13). Its attributes: a11 (Type of recipe) - the value of this attribute: "adult", "child"; b11 (Date), c11 (Surname), d11 (Name), e11 (Patronymic), f11 (Age), g11 (Doctor), h11 (Recipe), i11 (Validity) - the value of this attribute: "10 days", "2 months". Figure 13: The scheme of connections of the relation for Recipe with directory tables Document form the card of the patient of the day hospital, the inpatient care at home contains sub-tables, the structure of the document is shown in Fig. 14 - so it would be natural to present this document as a non-normalized relation R12 (Fig. 15). Figure 14: The general structure for the day hospital, the inpatient care at home Figure 15: The scheme of connections of the non-normalized relation Form of the day hospital, the inpatient care at home with directory tables Non-normalized relation R12 (The card of the patient of the day hospital, the inpatient care at home) contains the attributes a12 (Surname), b12 (Name), c12 (Patronymic), d12 (Date of birth), e12 (Settlement), f12 (Street), g12 (House), h12 (Apartment), i12 (Place of work), j12 (Job), k12 (Start of treatment), l12 (End of treatment), m12 (Diagnosis), n12 (Code for ICD-X), o12 (L / leaf - from), p12 (L / leaf - to), q12 (Treatment results), r12 (Transferred to hospital), r12 (Date), t12 (Physician), and nested relation of R12.1 (Diary of patient observation and fulfilment of appointments), R12.2 (Diagnostic examinations), R12.2 (Surgical operations). The nested relation R12.1 contains the attributes a12.1 (Assignment), b12.1 (Execution date) and b12.1 (Signature). The nested relation R12.2 contains the attributes a12.2 (Assigned), b12.2 (Execution date) and c12.2 (Signature). The nested relation R12.3 contains the attributes a12.3 (Name of the operation), b12.3 (Date). Non-normalized relation R13 (Extract from the patient's medical record) contains the following attributes: a13 (Patient's category) - the value of this attribute: "outpatient", "inpatient"; b13 (Name of the institution to which the extract is directed), c13 (Location of the institution), d13 (Street of the institution), e13 (House of the institution), f13 (Surname), g13 (Name), h13 (Patronymic ), i13 (Date of birth), j13 (Settlement), k13 (Street), l13 (House), m13 (Apartment), n13 (Place of work), o13 (Occupation), p13 (Date of outpatient illness), q13 (Date of hospitalization), r13 (Date of admission to hospital), s13 (Date of discharge from hospital), t13 (Short history/anamnesis), u13 (Treatment and labour recommendations), v13 (Date), w13 (Physician). The nested relation R13.1 (Full diagnosis) contains the attributes: a13.1 (Diagnosis) and b13.1 (Type of disease) - the value of this attribute: "underlying", "concomitant", "complication" (Fig. 16). Figure 16: The scheme of connections of the relation for Extract from the patient’s medical card To obtain a sanatorium voucher, a Certificate for obtaining a sanatorium voucher (form number070 / о) is issued. The relation R14 represents it. Relation R14 (Reference for obtaining a sanatorium voucher) - a flat table (Fig. 17). Its attributes: a14 (Valid until), b14 (Surname), c14 (Name), d14 (Patronymic), e14 (Diagnosis), f14 (Recommended resort), g14 (Sanatorium profile); h14 (Type of treatment) - the value of this attribute: NULL, "outpatient", "course"; i14 (Profile of the local sanatorium); j14 (Season) - the value of this attribute: "winter", "spring", "summer", "autumn"; k14 (Date), l14 (Physician), m14 (Head of department). Figure 17: The scheme of connections of the relation for Extract from the patient’s medical card After presenting a sanatorium voucher, a sanatorium card is issued (form number072 / o). The form of the document The sanatorium contains a sub-table - therefore it will be natural to present this document by the non-normalized relation R15 (Fig. 18). The non-normalized relation R15 (Sanatorium card) contains attributes: K15 (number of cards) - identifying attribute, a15 (Date), b15 (Address of the medical institution - region), c15 (Address of the medical institution - district), d15 (Address of medical institution - city), e15 (Address of medical institution - street), f15 (Doctor's surname), g15 (Doctor's name ), h15 (Doctor's patronymic), i15 (Surname), j15 (Name), k15 (Patronymic), l15 (Sex), m15 (Date of birth), n15 (Settlement), o15 (Street), p15 (House), q15 (Apartment), r15 (Place of work), s15 (Occupation), t15 (Complaints, old disease, history, previous treatment) , u15 (Basic diagnosis), w15 (Conclusion), x15 (Recommended resort), y15 (Sanatorium profile); z15 (Type of treatment) - the value of this attribute: NULL, "outpatient", "sanatorium"; aa15 (Profile of the local sanatorium); ab15 (Season) - the value of this attribute: "winter", "spring", "summer", "autumn"; ac15 (Physician), ad15 (Head of Department). Figure 18: The scheme of connections of the relation for Sanatorium card with directory tables The nested relation R15.1 (Brief data of clinical, laboratory, radiological and other studies) contains the attributes: a15.1 (Date), b15.1 (Study result). The nested relation R15.2 (Concomitant diseases) contains a single attribute: a15.2 (Diagnosis). Quarterly, the therapist submits: Report on the disabled, Analysis of the implementation of the diphtheria vaccination plan, Oncology examination of the population and Data on FR examination for the implementation of the order number233. Report on the disabled can represented by a cross table - a hypercube of data C1, which contains 5 dimensions: C1.dim1 (Date) = set of reporting dates C1.dim2 (number of a district) = { R1.K1a } C1.dim3 (Categories of dialled people) = {"Participants in the war", "Invalids of the Great Patriotic War", "Invalids of the army", "Disabled children", "Families of the dead", "Invalids of Afghanistan", "Liquidators of Chernobyl accident", "Rehabilitated, repressed", "General diseases"} C1.dim4 (Groups of disabled people) = {“Combatants”, “Non-combatants”, “Group 1”, “Group 2”, “Group 3”} C1.dim5 (Dynamics) = {“Was registered”, “New registered”, “Deregistered”, “Including died”, “Dropped of”, “Is registered”, “Group 1”, “Group 2”, “Group3”} Analysis of the implementation of the diphtheria vaccination plan report can represented by a cross table - a hypercube of data C2, which contains 3 dimensions: C2.dim1 (Date) = set of reporting dates C2.dim2 (number of a district) = { R1.K1a } C2.dim3 (Categories of population) = {“Total population”, “To be vaccinated”, “Vaccinated I”, “Vaccinated II”, “Vaccinated III”, “Retirees”, “Adolescents”, “Mothers in maternity”, “Not vaccinated”, “Mothers in maternity”, “Not recommended”, “Refusals”, “Vaccinated for the previous year”} Oncology examination of the population report can represented as a cross table – a hypercube of C3, which includes 5 dimensions: C3.dim1 (Date) = set of reporting dates C3.dim2 (number of a district) = { R1.K1a } C3.dim3 (Sex) = {“man”, “woman”} C3.dim4 (Examination) = {“Gynaecologist (w)”, “Dairy glands (w)”, “Pr (m)”, “Others”} C3.dim5 (Categories of population) = {“District`s population”, “Subjected to oncological examination”, “Pathologies are detect”} Data on FR examination report can represented by a cross table - a hypercube of data C4, which contains 5 dimensions: C4.dim1 (Date) = set of dates of reporting C4.dim2 (number of a district) = { R1.K1a } C4.dim3 (Kind of population) = {“FR of population”, “Population that is not organised”} C4.dim4 (Dynamics) = {“Subjected”, “Passed”} C4.dim5 (Deteched at first) = {“Accute patologies”, “Chronic patologies”} The analysis of activity is made out in the form of the Report on dispensary group for a year, quarterly in the form of Analysis of work, monthly - in the form of the analysis Precancerous diseases. Report on dispensary group can represented by a cross table - a hypercube of data C5, which contains 6 dimensions: C5.dim1 (Year) = set of years of reporting C5.dim2 (number of a district) = { R1.K1a } C5.dim3 (Doctor) = set of surnames of doctors C5.dim4 (Nurse) = set of surnames of nurses C5.dim5 (Diagnosis) = set of names of diagnoses C5.dim6 (Dynamics) = {“Registered in total”, “Registered with +”, “Were registered”, “Taken in total”, “Taken with +”, “Deregistered”, “Registered at the end of the year”, “From them retirees”} Analysis of work report can represented by a cross table - a hypercube of data C6, which contains 6 dimensions: C5.dim1 (Year) = set of years of reporting C5.dim5 (Guarter) = set of numbers of quarters C5.dim2 (number of a district) = { R1.K1a } C5.dim3 (Doctor) = set of surnames of doctors C5.dim4 (Nurse) = set of surnames of nurses C5.dim6 (Categories and dynamics) = a set of names of categories of the population and names of changes of a condition Precancerous diseases report can represented by a cross table - a hypercube of data C7, which contains 6 dimensions: C7.dim1 (Date) = set of dates of reporting C7.dim2 (number of a district) = { R1.K1a } C7.dim3 (Doctor) = set of surnames of doctors C7.dim4 (Nurse) = set of surnames of nurses C7.dim5 (Nosology) = set of names of diagnoses C7.dim6 (Dynamics) = {“Was registred on «D»”, “Taken”, “Deregistred”, “Deregistred because of recovery”, “Moved to c-r”, “Other”, “Registred now”} All these reports display the number of corresponding records of the ratio R1 - that is, the fact table for each hypercube is based on the corresponding queries to R1. Let's summarize the considered document flow that is connected with the activity of the district therapist (see the scheme shown in Fig. 19). Each time during the examination of the patient by the district therapist, the relevant data are entered in the Medical Passport (R1). If necessary, the doctor refers the patient for examination using a referral for consultation, examination, procedure, transfusion (R2). The laboratory department receives the results of laboratory tests: Blood test (R3), Urine test (R4), Analysis of fecal for helminths and protozoa (R5), Liver function test (R6), Biochemical blood test (R7), Analysis of sputum (R8).During admission, a statistical coupon for registration of final (revised) diagnoses (R9) is filled in for each patient with an acute diagnosis, and an Outpatient sheet (R10) is kept. If necessary, patients are prescribed a Prescription (R11), fill in The card of the patient of the day hospital, the inpatient care at home (R12) and The extract from the patient's medical card (R13). To obtain a sanatorium voucher, a Certificate for a sanatorium voucher (R14) is issued. After presenting a permit for sanatorium or outpatient treatment, a sanatorium card is issued (R15). Quarterly, therapist submits Report on the disabled (C1), Analysis of the implementation of the plan of diphtheria vaccination (C2), Oncology examinations of the population (C3) and data on FR examination (C4). Figure 19: The diagram of the document flow of the district therapist Analysis of activity takes the form of Reports on dispensary groups (C5) per year, Analysis of work (C6) - quarterly, Analysis of precancerous diseases (C7) - monthly. 5. Conclusions The world that surrounds us contains mostly complex objects - those that contain simpler components. Therefore, it is not surprising that it is possible to build models of such a large number of subject areas by means of non-normalized relations. The article shows that medical data is hierarchical in its nature - documents that describe medical information are tables that contain sub- tables. Consequently, the system of processing medical data can adequately implemented by using non-normalized (nested) relationships. The document flow, related to the activity of the district therapist is analysed; Based on the analysis, a data scheme that consists of a set of non-normalized relations is constructed, the domains of all attributes are defined, and connections and dependencies between attributes are described. The designed scheme can use in the implementation of a computer information system for processing medical information. 6. References [1] A. Makinouchi, A consideration on normal form of not-necessarily-normalized relation in the relational data model, in: Proceedings of 3rd International Conference on Very Large Databases, Tokyo, 1977, pp. 447-453. [2] T.W. Olle, Introduction to ‘Feature Analysis of Generalized Data Base Management systems’, in:CACM, volume 14. No (5), 1971. doi:10.1145/362588.362590 [3] G. Wiederhold, Database Design (2nd ed.) McGraw-Hill, 1983. [4] W.C. McGee, The Information Management System, IMS/VS, Part 1: General structure and Operation, IBM Syst. J., volume 16(2), 1977. doi: 10.1147/sj.162.0084 [5] M.J. Carey, D.J DeWitt., J.E. Richardson, E. Shekita, Object and File Management in the EXODUS Extensible Database System, in: Proceedings of Int. Conf. on VLDB, Aug. 1986. [6] M. Stonebraker, L.A. Rove, The Design of POSTGRES, in Proceedings of CAN SIGMOD Int. Conf. on Management of Data, May 1986. [7] S. Feuerstein, B. Pribyl, C. Dawes, Oracle PL/SQL Language Pocket Reference: A Guide to Oracle's PL/SQL Language Fundamentals, O'Reilly Media, Inc., 2015. [8] S. K. Gupta, Oracle Advanced PL/SQL Developer Professional Guide, Packt Publishing Ltd, 2012. [9] R. E. N. Yingqiao, Medical Information Database Construction Based on Oracle and ArcGIS, Geospatial Information, volume 4:17, 2017. [10] M. A. Alshraideh, B. A. Mahafzah, H. S. E. Salman, I. Salah, Using genetic algorithm as test data generator for stored PL/SQL program units, Journal of Software Engineering and Applications, volume 6(02), 65, 2013. doi: 10.4236/jsea.2013.62011 [11] R. Bergenthum, J. Schick, Verification of Logs-Revealing Faulty Processes of a Medical Laboratory, Transactions on Petri Nets and Other Models of Concurrency X. Springer, Berlin, Heidelberg, 2015, pp. 1-18. doi: 10.1007/978-3-662-48650-4_1 [12] L. Byczkowska-Lipińska, A. Wosiak, Multimedia NoSQL database solutions in the medical imaging data analysis, Przegląd Elektrotechniczny, volume 12, 2013, pp. 234-237. [13] D. R. Schlegel, J. P. Bona, P. L. Elkin, Comparing small graph retrieval performance for ontology concepts in medical texts, Biomedical Data Management and Graph Online Querying, Springer, Cham, 2015, pp. 32-44. doi: 10.1007/978-3-319-41576-5_3 [14] V. Lytvyn, Y. Burov, P. Kravets, V. Vysotska, A. Demchuk, A. Berko, Y. Ryshkovets, S. Shcherbak, O. Naum, Methods and Models of Intellectual Processing of Texts for Building Ontologies of Software for Medical Terms Identification in Content Classification, CEUR Workshop Proceedings, Vol-2362, (2019) 354-368. [15] V. Vysotska, V. Lytvyn, Y. Burov, A. Gozhyj, S. Makara, The consolidated information web- resource about pharmacy networks in city, CEUR Workshop Proceedings, (2018) 239-255. [16] L. Chyrun, E. Leshchynskyy, V. Lytvyn, A. Rzheuskyi, V. Vysotska, Y. Borzov, Intellectual Analysis of Making Decisions Tree in Information Systems of Screening Observation for Immunological Patients, CEUR Workshop Proceedings, Vol-2362, (2019) 281-296. [17] A., Sachenko, V., Kochan, V., Turchenko, V., Tymchyshyn, N.Vasylkiv, Intelligent nodes for distributed sensor network, in: Proceedings of IEEE Instrumentation and Measurement Technology Conference 3, 1999, pp. 1479-1484. doi: 10.1109/IMTC.1999.776072 [18] M. Komar, V. Golovko, A. Sachenko, S. Bezobrazov, Intelligent system for detection of networking intrusion, in: Proceedings of the 6th IEEE International Conference on Intelligent Data Acquisition and Advanced Computing Systems: Technology and Applications, IDAACS, 2011, pp. 374-377. doi: 10.1109/IDAACS.2011.6072777 [19] O. Cherednichenko, O. Kanishcheva, O. Yakovleva, D. Arkatov, Collection and Processing of a Medical Corpus in Ukrainian, CEUR workshop proceedings, Vol-2604, (2020) 272-282. [20] M. Odrekhivskyy, V. Pasichnyk, N. Kunanets, A. Rzheuskyi, G. Korz, D. Tabachyshyn, The Use of Modern Information Technology in Medical and Health Institutions of Truskavets Resort, CEUR Workshop Proceedings, Vol-2631, (2020) 184-197. [21] R. Perkhach, D. Kysil, D. Dosyn, I. Zavuschak, Y. Kis, M. Hrendus, A. Vasyliuk, M. Sadova, M. Prodanyuk, Method of Structural Semantic Analysis of Dental Terms in the Instructions for Medical Preparations, CEUR workshop proceedings, Vol-2604, (2020). 662-669. [22] O. Cherednichenko, N. Babkova, O. Kanishcheva, Complex Term Identification for Ukrainian Medical Texts, CEUR Workshop Proceedings, Vol-2255, (2018) 146-154. [23] S. Fedushko, Adequacy of Personal Medical Profiles Data in Medical Information Decision- Making Support System, CEUR Workshop Proceedings, Vol-2544, 2020. [24] N. Melnykova, O. Markiv, Semantic approach to personalization of medical data, Computer Sciences and Information Technologies, CSIT, 2016, pp. 59-61. doi: 10.1109/STC- CSIT.2016.7589868 [25] N. Melnykova, N. Shakhovska, T. Sviridova, The personalized approach in a medical decentralized diagnostic and treatment, 14th International Conference The Experience of Designing and Application of CAD Systems in Microelectronics, CADSM, 2017, pp. 295-297. doi: 10.1109/CADSM.2017.7916139 [26] S. Fedushko, N. Shakhovska, Y. Syerov, Verifying the medical specialty from user profile of online community for health-related advices, CEUR Workshop Proceedings 2255 (2018) 301- 310. [27] Y. Kryvenchuk, N. Shakhovska, I. Shvorob, S. Montenegro, M. Nechepurenko, The smart house based system for the collection and analysis of medical data, CEUR Workshop Proceedings 2255, (2018) 205-214. [28] I. Perova, Y. Bodyanskiy, Fast medical diagnostics using autoassociative neuro-fuzzy memory, International Journal of Computing, 16(1), (2017) 34-40. [29] I. Perova, Y. Bodyanskiy, Adaptive human machine interaction approach for feature selection- extraction task in medical data mining, International Journal of Computing, 17(2) (2018) 113- 119.