ES2362837B1 - REAL-TIME DATA MANAGEMENT SYSTEM BASED ON KNOWLEDGE. - Google Patents

Abstract

Knowledge-based real-time data management system. # Two types of data stores participate in the system: an object-relational database (1) and a shared memory area (2), the latter intended to hold data that need to be accessed at high speeds. In addition to these structures, a configuration file (4) is included in the system, customizable by the users of the system, which will keep information on what data should be in the shared memory area. Likewise, a module for the attention of requests and queries (3) to both data structures, a module that manages the system startup (5) and a module responsible for the dump between the memory segment and the database base participate in the system. relational object data and vice versa (6).

Description

These new technologies are capable of monitoring

Real-time data management system based on knowledge. Object of the invention

The present invention aims at a system that allows the storage and management of data of a heterogeneous nature and with strong time constraints. In the healthcare context, when integrated into a telecare architecture, these capabilities serve to support systems for generating personalized patient knowledge in real time. The system object of the invention is constituted by two types of data structures, which allow the storage of complex data and knowledge generated by other modules within the architecture where the system is integrated, and by several subsystems that have the ability to provide and give real-time access to data and knowledge stored in real time by said modules. In turn, the system allows the acquisition and registration in real time of data from different sources. Background of the invention

The creation of new knowledge, based on existing data, information and knowledge, and its exchange and storage have been and have been the object of incessant study since the last decade in multiple sectors: companies, industries, health, etc. In particular, in the healthcare environment this interest is reflected in the need for an exchange of knowledge originated by the rapid evolution of health information systems, which have gone from being independent systems to being part of knowledge-based architectures that allow connecting hospitals, clinics, pharmacies and users. Similarly, the importance of knowledge in the healthcare environment is evident in clinical decision making during the diagnostic process by healthcare professionals, since proper knowledge management favors the effectiveness of treatments and improves quality welfare.

To achieve this, it is essential to have timely and relevant knowledge regarding the patient's clinical context, which also depends critically on its collection, analysis and exchange within and between the different institutions. As a consequence, the design of a health care system must not only provide a good technical infrastructure, but must also be able to integrate the different applications present in the system in order to acquire data that is accurate and complete, and store them in Supported formats

On the other hand, in the health information systems there has been an important growth of the data that can be processed and stored, mainly due to the increase in therapeutic and diagnostic procedures. These data are often of a very diverse nature and come from very heterogeneous sources: clinical analysis, medical images of different kinds such as x-rays, ultrasound or molecular images, biomedical signals collected from different devices such as electrocardiograms, etc. In addition, it is necessary to include in this set, the new types of data that have appeared, for example, at the molecular or proteomic level, and those obtained in real time through new technosing the health status of patients, making it easier Obtaining information in real time. These technologies include portable devices with sensors and without manual intervention and data acquisition platforms for blood pressure, heart rate or patient temperature. In this way, it is possible that medical personnel can identify trends more easily and in a matter of minutes. Other types of devices allow monitoring of an electrocardiogram

or the patient's breathing, while he continues to develop his normal life, so it would be possible to determine at any time if the patient needs healthcare. Likewise, portable sensors are being developed to monitor human movement, so that it is possible, for example, to detect falls and impacts and transmit such information remotely.

On the other hand, some authors have conducted studies in order to provide new technological, organizational and management perspectives on the best way to incorporate knowledge management in health care. These studies pointed to the difficulties encountered when individual knowledge is transformed and transferred into a collective. In addition, there are other specific problems such as the complexity of medical data, data entry problems, security and confidentiality of the data, or the absence in many countries of a single national patient identifier.

Also added to these problems are the lack of norms or the slow adoption of existing norms and that, historically, health care has been carried out by independent organizations and autonomous units, which has led to the few benefits that could be obtained. of information exchange.

In turn, these problems are exacerbated by the heterogeneous and distributed nature of current healthcare technologies. The needs of the different professional users involved, from the primary care physician with only a hundred patients to the thousands of patients treated in large hospitals, from an X-ray department to an intensive care unit, are so varied that it is inevitable Having to adopt a wide variety of IT solutions.

Collecting all these needs and problems, it becomes a key objective of health information systems to provide, to authorized users, access to relevant patient data in the form of a record, regardless of the source of the data or the form in which they were acquired.

Similarly, the storage of all this information acquired makes it possible to identify trends in medical data, which can help to formulate research priorities, identify the causes and epidemiology of diseases, the evaluation of the clinical efficacy of procedures and the personalization of patient data, in order to know what type of information is relevant to a user and how that information is represented. This implies the development of knowledge-based expert systems that offer the possibility of performing complex analyzes on different types of knowledge. The Clinical Decision Support Systems fulfill these functions, since they can access and combine relevant information from a large number of sources of medical knowledge simultaneously.

On the other hand, despite the existence of technology capable of providing data acquired in real time, the data is usually sent to databases that currently can only store a small amount of this data and in most cases it is specific and proprietary solutions that provide limited services.

Similarly, some data must be collected periodically, such as when measuring heart rate, electrocardiogram signals or blood pressure, for certain applications. These require monitoring of the patient's conditions within a certain period of time and the data must be accessible within a range that defines their validity. Otherwise, the data would not reflect the current state of the patient's health.

On the other hand, current research on clinical decision support systems provides a design of these systems based on knowledge management procedures. These knowledge-based data managers must also have the ability to provide accurate and complete information effectively to clinical decision support systems so that they can generate new, complete and personalized patient knowledge.

To solve these problems, current telecare systems need real-time data managers that allow them to interact with other different systems, since, as previously mentioned, patient data often resides in highly heterogeneous and independent environments. others. Likewise, a management system with a good cost / efficiency relationship in terms of access to information at all levels is necessary.

In the health field, and more specifically in patient monitoring systems, the use of stream databases for real-time monitoring of variables acquired through the technologies discussed in previous paragraphs is frequent. Normally, the real-time databases that are used are nothing more than memory buffers, to increase the use of the data to generate new knowledge and improve the quality of patient care, taking the data after analysis to a or several relational databases.

In industrial environments, there are database systems that allow you to manage information in real time. These databases are usually integrated into control and supervision systems, commonly known as SCADA systems (Supervision, Control and Data Acquisition systems). Such databases usually have two types of storage subsystems, one for static data and one for data that has strong time constraints. Normally, real-time data has a short life cycle and in a synchronized way, they are periodically transferred to the static database. On the other hand, there are real-time database solutions, which are proprietary solutions or databases embedded within other systems.

In any case, in all the studies studied, it is agreed that the nature of the data, the way in which they are acquired and the reasons for their analysis and processing are the key factors in deciding what type of database is necessary. in each case. This raises an important question, and that is when we have an architecture formed by heterogeneous systems that must share the data, information and knowledge with which they work.

Description of the invention

The invention proposes a new clinical data management system based on knowledge that solves the aforementioned problems. This system has the advantage of being able to operate with real-time data without losing the benefits that object-relational databases provide. These systems have the advantages of relational models, in that they are capable of supporting applications for large data transactions, and those of object-oriented systems, since they can manage very complex relationships between their components and at the same time adapt more easily to new types and formats of data, of great interest in the healthcare environment; also providing the means to expand the possibilities of a database to develop functions and types of data defined by users.

In accordance with the above, to store the data structures the system uses on the one hand an object-relational database and on the other, a shared memory area. Hereinafter, when we talk about a database we will refer only to the object-relational database and when we talk about memory we will refer to the shared memory area. It is, in this memory, where the data structures that must be accessed, either in writing or reading, are located very quickly. With the division of the system into these two modules for the storage of information we managed to maintain the functions provided by systems based on object-relational databases and also, thanks to the use of memory, quick access to variables necessary for Operate in real time. Finally, wrapping and managing both the database and memory, there is a layer of agent processes.

The data management system is characterized by the ability to store clinical data of patients, both those taken in real time and those taken with sampling times longer than one hour, as for example with data from analytics. It also stores data referring to the patient's medical history while maintaining a relationship between own identifiers, local to the data management system, and identifiers that refer to an existing database in the health center that contains the complete data of the patient history Likewise, it records alarm situations, monitoring the alarm status in real time and taking the data of the alarm to the corresponding historical record when it has been processed.

It also contains information of interest about the different professional users of the system. In this way, certain useful information is recorded: access to the system, restricting users' permissions to certain parts of the system only accessible to administrators; alarm recognition, obtaining in real time knowledge of the user who has recognized a previously generated alarm; requests made, providing personalized information to each user based on the requests made. Finally, it stores data associated with the con fi guration of devices and system processes and maintains a fl exible historical record, understanding as fl exible that in addition to a conventional historical record, the professional user may request to save certain useful data for him.

The data structure maintained in the shared memory is divided into two parts: on the one hand, tables for storing values and on the other hand, tables that function as dictionaries that facilitate the translation of data from memory to the database and vice versa. In turn, there is in the system a configuration file that can be modified by the professional user that indicates which variables must be accessible in memory at all times.

As mentioned before, the system consists of a layer of agent processes that involve both the database and the shared memory zone. These agent processes are responsible for managing all the data and attending to the requests that arrive at the data management system and is composed of modules distinguished by the functionality they perform: starting the system, initially and while it is running, dump the data from the base of data and vice versa or attend the requests and queries that arrive at the system from the different processes connected to it.

As already mentioned, two types of boot are distinguished in the module that manages the system startup. On the one hand, an initial startup in which the object-relational database is started, the data structures of the shared memory zone are created, the synchronization mechanisms to manage the shared memory zone are started and initialized and they are dumped in memory from the object-relational database the data indicated by the con fi guration file. On the other hand, a start called "hot", which starts when the initial start ends. This is responsible for detecting, while the system is running, changes in the configuration file and dump the new data indicated by the file to the shared memory area.

Second, the process layer is responsible for transferring data between memory and database. Thus, two cases are distinguished: on the one hand the dump of data from memory to the database and in the opposite case, the transfer of data from the database to shared memory. In the latter case, the set of processes responsible for carrying out this task is characterized by being composed of a series of search mechanisms that allow the data to be found in the database, which the configuration file indicates that they have to be in memory , optimally. In the case of the processes responsible for transferring data from memory to the database, they are characterized by having the ability to perform simple operations with the data in memory before they are stored in the database. That is, not all memory data becomes part of the database records. In this way, it is allowed that the processes that are working with the data in memory, can add new data to the tables of the memory structures without the database running the risk of being saturated by this new data. For this, the processes also have the ability to maintain a correspondence between the original data and those that are added or modified. In addition, an independent module is responsible for dumping the data sets registered in memory as an update and periodically as the associated timers expire, indicated in the con fi guration file.

To complete the management layer of the data structures, there is a module in charge of responding to requests and queries from all processes external to the system. These processes can be local, that are on the same machine as the data management system, or remote, that are on different machines but that are part of the same network with the information management system.

Finally, although for simplicity there has been talk of a database, a shared memory module and a process layer, it is necessary to highlight the distributed nature of the described data management system. That is, the system can be part of a distributed architecture, being composed of several interconnected databases and shared memory areas sharing data and information and integrating knowledge from the different data sources available within that architecture. Description of the drawings

The present document is attached as an integral part of the description and in accordance with a preferred example of practical implementation of the invention, with a set of drawings in order to help understand the characteristics and functionality granted to both the global system and each of the modules that make it up.

Figure 1. Shows a schematic representation of the new knowledge-based real-time data management system, which is the object of the present invention.

Figure 2. Shows a block diagram that schematically represents the initial system boot subsystem.

Figure 3. Shows a block diagram similar to the previous one but for the “hot” boot subsystem of the system.

Figure 4. Finally, it shows an entity-relationship diagram that aims to represent, by way of example, a part of the internal data model of the object-relational database. Preferred Embodiment of the Invention

In Figure 1, the data management system can be observed globally with all its components, among which an object-relational database (1) and a shared memory area (2) participate, in the latter they will be stored the data that requires access in real time. Managing these data structures, there is a request and query service module (3), a module responsible for system startup (5) and comprising two subsystems: one for the initial startup of the management system (5a) and another for the so-called "hot" start-up of the management system (5b), and finally, a module for data dump that is also divided into several subsystems depending on the function they perform: a subsystem for data dump from memory to the database (6a), another one in charge of the periodic data dump from memory to the database (6b) and another one for the dump of data from the database to memory (6c). Both the system boot module (5) and the data dump module (6) must have access to what has been called the configuration file (4) in order to know what data should be accessible in the area of shared memory (7).

In Figure 2 it can be observed, schematically, how the initial start-up of the data management system could take place. First, a user with administrator privileges must start the startup process that automatically starts the system (11). This process starts a thread that starts the object-relational database (12). Once finalized, the necessary data structures are created in the previously reserved shared memory zone (13). The control and synchronization mechanisms necessary for the management of shared memory are then initialized (14). The next step is the creation of another process thread that calls the subsystem that will dump the data from the database to memory (10). This thread of the data dump module (6c), looks in the configuration file (4) and dumps the data indicated in the file to memory. Once the process is finished, the response is sent to the thread of the boot process that has been put on hold (10). If there has been a failure in the data dump (17), the user is informed of an error code and the process itself automatically, restarts the shared memory area and for the database, that is, aborts all processes (16). The user would be in charge of starting the system startup process once the problem is solved. In the event that the dump was successful, a thread would be created that initiated the “hot” start process (18) that would remain in the background while the initial start process ends (19).

Likewise, although in Figure 2 it has been omitted for simplicity, the initial startup subprocess of the system is responsible for starting, before finalizing, the processes of the request attention module (3) and the periodic dump part of data from memory to database (6b). These processes run independently of all others along with the "hot" boot module.

In Figure 3, we can see a block diagram similar to that of the initial start-up process that shows how a “hot” start-up process could be possible. Once the process has been started from the initial start-up process (18), it is checked periodically if there is any change in the configuration file (7). If the file (4) is modified by the user to indicate what data should now be in the memory data structures, the verification process will give a positive response (7). In that case, it is checked that there is no process writing in the shared memory zone (20). If there is, the “hot” boot process is placed at the end of the write queue (21), managed by the request and query service module. Once all the write requests that remain pending have been met, the memory access to all processes (22) is closed and a copy of the contents of the memory structures (23) is made as a security measure for possible errors so as not to lose information. The subsystem responsible for dumping the data from memory to the database (6a) is then called and awaits the response. This process, thanks to an existing dictionary in memory, translates the data in memory into the relational tables of the database. If there has been an error in the information transfer (24), the corresponding error code is generated but the next step (25) is continued. If there has been an error, it will mean that the memory data will not have been copied to the database since we are talking about transactions, that is, that they are made successfully or all the changes made in case of error are aborted . In the latter case, it will be the mission of the user in charge of monitoring the application that takes the appropriate measures upon receiving the generated error code. In any case, as mentioned, the process is continued and the data dump module is called from the database to memory (6c). In this case, the subsystem must access the con fi guration file and, depending on what is indicated in it, the appropriate data will be dumped from the database tables to memory. In this case, if the result of the information transfer fails (26), it is not continued, but what was stored in memory of the backup made at the beginning of the execution is restored, the corresponding error code is generated and it goes back to the beginning waiting for a new modification in the con fi guration file (27). It will be the mission of the administrator user to correct the errors produced. If the transfer has been successful, it is also reported and returns to the beginning of the start-up process pending further changes in the con fi guration file (28).

As already mentioned in the description of the system, the request attention module manages queries to both the database and the shared memory zone (9). To do this, it will use several process threads in parallel, so that it allows multiple processes to be read from memory or from the database. In the case of writing, it will allow a single process to be written in memory and a single process to write to the database.

The periodic data dump sub-module will make use of the dictionaries available in the shared memory area to check when the associated timers expire independently of the shared memory variable sets.

With respect to the object-relational database, the information is organized in a series of data stores. These stores correspond to data entities that include tables that follow an object-oriented relational model. First, there will be a communications data store that contains data corresponding to the establishment and maintenance of the connections that may exist between the data management system and the different devices and / or processes that have the ability to access either reading or reading. writing to data structures. Second, there will be a field variable monitoring store. This warehouse is made up of a set of tables that reflect the current state of the users of the system by means of measured variables. These variables are obtained through a pretreatment based on the values of the communications store. On the other hand, a configuration store and dictionaries, with data related to the system configuration, from the brands and characteristics of the devices connected to the system, to the tables that establish which variables are stored in the records and in what way. And finally, in the first system design, a data history store has been included, which includes information related to users who have requested a specific data record. That is, that personalized and flexible historical records are maintained.

Figure 4 shows a simplified relationship entity diagram that aims to show by way of example how a part of the internal data model of the relational database would be structured. Specifically, the representation corresponds to part of the field variable monitoring store and the configuration store and dictionaries. The entities represented are: measured variables (29), types of groups of variables (30), measurement devices and registered processes (31), types of existing devices and processes (32), attributes or characteristics (33), patients (34 ), professional users (35) and types of access available in the system (36). The diagram also shows some of the most essential relationships between these entities. Thus, a set of variables (29) can belong to (41) a set of groups (30) in an N: M relationship, following a certain hierarchy level (55). In the same way a certain measurement of variable (29) is taken by (37) by a device (31) participating in a 1: N ratio. In turn, a device (31) belongs to

(39)

to a certain type of device (32) with a 1: N ratio. Both variables (29) and devices

(31)

they have associated (45 and 40) a series of attributes (33), in the case of the variables, each measure will be related to some attributes with a 1: N relation and for the devices, N: M. On the other hand, each recorded measure (29) will be taken to (38) a patient (34),

with a 1: N ratio. Each patient (34) will be assigned to (42) a professional user (35), through an N: M relationship, since for example in the case that the professional user is a doctor, several doctors can treat the same patient, and Several patients may have the same doctor assigned. These professional users (35) may have (44) different types of access (36) and in the case of certain users, they must be in charge of the supervision (43) of different devices (31). In both cases with an N: M ratio.

In the diagram, the most important attributes involved in the entities and their relationships have also been represented: Tag or label to identify an object (46), extended definition of an object (47), value of a measurement variable (48), time in which a specific measurement is taken (49), identification code of a variable (50), identification code of a device or process belonging to the system (51), code to identify the types of devices or processes that can exist within the system (52), code that identifies a certain attribute (53), group identification code to which a variable can belong (54), group hierarchy level (55), unique patient identifier (56), identifier that allows the same patient to be associated in two different databases (57), a unique local identifier to the system for the professional users involved in the system with which they are allowed access to it (58), DNI, used as a universal identifier for the professional user (59), password for access to the system (60), name of the user (61), last name of the user (62) and identification code of the types of access existing in the system ( 63).

Claims (8)

1. Data management system for storing, managing and integrating clinical and demographic information of patients, data for the monitoring of alarms in real time, information on professional users of the system, configuration data of devices and processes connected to the system and historical records , which is made up of: a) a data structure in an object-relational database (1) to maintain said information in a stable manner; b) a data structure in a shared memory zone (2) to maintain said information, the part that needs to be accessed in very fast times by the processes connected to the system; Y c) a layer of processes, algorithms and agents (3, 5 and 6) to manage both data structures; characterized in that:

-

The process, algorithms and agents layer consists of modules that manage the system startup (5), the transfer of data between memory and database (6) and the attention of requests and queries to the system from the outside (3) ;

-

the information that will be stored in the data structure in shared memory is determined by a configuration file (4) to which both the boot management processes and the processes in charge of data transfer (7) have access;

-

The module (3) attends requests and queries both to memory and to the database (9).

2.

Data management system according to claim 1, further characterized in that the shared memory area (2) is structured in a set of tables for storing values and by another set of tables as dictionaries.

3.

Data management system according to claim 2, further characterized in that for the transfer of data from shared memory to the database

it makes use of independent timers for each type of variable, defined by the users and indicated in the con fi guration file.

Four.

Data management system, according to claim 3, further characterized in that the system boot module has a subsystem capable of starting new data structures in the shared memory area when changes are made to the configuration file, without stopping the database relational object or requests made to it.

5.

Data management system, according to claim 4, further characterized in that in the object-relational database there are a set of tables that maintain relationships between identifiers of patients local to the system and others already existing in databases previously installed in the health center where the management system object of the invention is located.

6.

Data management system according to any one of claims 1 to 5, wherein the real-time accessible data structure is part of shared memory segments organized and managed in a distributed manner.

7.

Data management system according to any one of claims 1 to 5, wherein the entire set of data structures and the process layer, algorithms and agents that manage said data structures, are part of a distributed, composite architecture in this case of:

several object-relational databases interconnected with each other and distributed throughout the architecture; several segments of shared memory interconnected with each other and with the databases and also distributed throughout the architecture; Y a layer of processes, algorithms and agents, whose elements and modules of management and processing are distributed throughout the architecture managing the mentioned data structures. SPANISH OFFICE OF THE PATENTS AND BRAND Application no .: 200900970 SPAIN Date of submission of the application: 04.13.2009 Priority Date: REPORT ON THE STATE OF THE TECHNIQUE 51 Int. Cl.: G06F17 / 30 (2006.01) RELEVANT DOCUMENTS

Category

Documents cited Claims Affected

X

US 7395258 B2 (INTERNATIONAL BUSINESS MACHINES CORPORATION) 01.07.2008, column 2, lines 17-40; column 3, lines 20-33.51-64; column 4, line 47 - column 5, line 23; column 7, line 7 - column 8, line 22; column 9, lines 25-50; column 11, lines 15-19; Figures 2,3,7,9. 1-7

X

US 6192370 B1 (SAP AG) 20.02.2001, column 2, line 50 - column 3, line 23; column 5, lines 5-45; column 7, line 14 - column 8, line 29; column 12, line 21 - column 13, line 35; column 13, line 65 - column 14, line 22; Figures 3-6.8. 1-7

X

ZHOU N. et al, "Open Real-time Database and it's Application in Dispatching Automation Systems". International Conference on Power System Technology, 2006. PowerCon 2006. Page 1-6, 22-26 Oct. 2006. The whole document. 1-7

Category of the documents cited X: of particular relevance Y: of particular relevance combined with other / s of the same category A: reflects the state of the art O: refers to unwritten disclosure P: published between the priority date and the date of priority submission of the application E: previous document, but published after the date of submission of the application

This report has been prepared • for all claims • for claims no:

Date of realization of the report 27.06.2011

Examiner J. Cotillas Castellano Page 1/5

REPORT OF THE STATE OF THE TECHNIQUE Application number: 200900970 Minimum documentation sought (classification system followed by classification symbols) G06F Electronic databases consulted during the search (name of the database and, if possible, terms of search used) INVENES, EPODOC, XPI3E, NPL, INSPEC, XPESP State of the Art Report Page 2/5  WRITTEN OPINION Application number: 200900970 Date of Completion of Written Opinion: 06.27.2011 Statement

Novelty (Art. 6.1 LP 11/1986)

Claims Claims 1-7 IF NOT

Inventive activity (Art. 8.1 LP11 / 1986)

Claims Claims 1-7 IF NOT

The application is considered to comply with the industrial application requirement. This requirement was evaluated during the formal and technical examination phase of the application (Article 31.2 Law 11/1986).  Opinion Base.- This opinion has been made on the basis of the patent application as published. State of the Art Report Page 3/5  WRITTEN OPINION Application number: 200900970 1. Documents considered.- The documents belonging to the state of the art taken into consideration for the realization of this opinion are listed below.

Document

Publication or Identification Number publication date

D01

US 7395258 B2 (INTERNATIONAL BUSINESS MACHINES CORPORATION) 01.07.2008

D02

US 6192370 B1 (SAP AG) 02.20001

2. Statement motivated according to articles 29.6 and 29.7 of the Regulations for the execution of Law 11/1986, of March 20, on Patents on novelty and inventive activity; quotes and explanations in support of this statement Document D01 is considered the closest in the state of the art to the object of claims 1 to 7, and as regards these claims this document appears to affect the inventive activity of said claims, as explained below.  Independent claim 1: Document D01 describes a data management system, which would be suitable for storing and managing, among others. information, patient clinical information, data for real-time alarm monitoring, configuration data of devices, etc., which consists of: -a data structure in the form of a database (see column 3, lines 20 to 25), -a data structure in a shared memory area that maintains the data that needs to be accessed in very short times due to the processes connected to the system (see column 3, lines 20 to 25), -a layer of processes to manage both data structures, composed of modules that manage the transfer of data between memory and database and attention to requests and queries to the system from outside (see figure 7). Where: -the process layer is composed of modules that manage the transfer of data between memory and database (see column 7, line 57 to column 8, line 2, and figure 7), and the attention of requests and queries to the system from outside (see figure 7). -the module that responds to requests and queries, does it both in memory and in the database (see column 7, lines 8 to 16). The main differences between the claimed invention and what is disclosed in D01 are: 1-In the system described in D01 it is not specified that the database be of the object-relational type. 2-In the invention described in D01, the information that will be stored in the data structure in shared memory is configured by sentences executed by the database processes (see column 4, lines 62 to 67), instead of being determined through a configuration file accessible both by boot management processes and by those in charge of data transfer. As for the first difference, the associated objective problem would be how to provide the database with the ability to handle data types of a more complex nature. However, this difference is not considered to imply an inventive activity, since an expert in the field, in this case a computer expert faced with this technical problem, would consider using an object-relational database, without the need for make an inventive effort, since the use of such databases is generally widespread (see document D02, for example). Regarding the second difference, its technical effect would be to save in a file the configuration related to the information that will be stored in the shared memory, instead of directly configuring it in the database. Associated to this effect, the objective technical problem would be to facilitate said configuration, since it would not be necessary to interact directly with the database. However, it is considered that the use of a configuration file to solve this type of problem is a common technique that a person skilled in the art would select according to the circumstances, without the exercise of inventive activity, to solve the problem posed. Therefore, claim 1 would lack inventive activity (Article 8.1 LP). State of the Art Report Page 4/5  WRITTEN OPINION Application number: 200900970  Dependent claims 2 to 7: These claims do not appear to have additional or different characteristics, in combination with the claims on which they depend, which give them novelty or inventive activity compared to what is already described in D01, since they are either disclosed in said document (such as the use of timers for the transfer of data from shared memory to the database as in claim 3) or they are mere particular executions that do not go beyond the usual practice followed by an expert in the field, such as the use of Value tables and dictionaries (claim 2), the loading of data structures when the configuration file is modified (claim 4) or the distributed organization of the data structures (claims 6 and 7). Therefore, in view of the known state of the art, the application would not satisfy the inventive activity requirement set forth in Article 8.1 LP. State of the Art Report Page 5/5