TECHNICAL FIELD

This application relates to a method for handling distributed data and applications, a system for handling distributed data and applications and an apparatus for handling distributed data and applications.

BACKGROUND

In today's society where digitalization of services and records are the norm many computer and data systems carry information that is necessary for other systems to access. One environment where this is common is in the health care systems. Other environments are economic and financial systems, technological databases, design systems, traffic systems, delivery systems, security systems, tourism as well as so called cloud application environments. To illustrate the difficulties facing an integration of locally distributed data systems some examples from the health care systems will be given.

To ascertain that the correct care is provided to a patient there is a lot of data that a care giver needs to be aware of. For example, during a response to an emergency call, a paramedic will find great use of the following information. The patient's:

• position;

• medical status;

• identity;

• ongoing care programs;

· allergies;

• current medications;

Other factors that the paramedics might find useful are:

• who else have been sent out as a response?

• is any special equipment needed?

· Information on family doctor.

• Information on insurance and insurance coverage. All this information is not retrievable from the same system and using contemporary emergency procedures the emergency personnel relies on a number of systems to retrieve the needed information. In the health care environment it is of utmost important to be able to retrieve the correct data at the correct time.

In order to provide all data to a user many different systems need to be connected and integrated so that they can work together. However, since most of the systems are already implemented and operational they can not be easily changed.

Designing new systems, migrating data to such systems or modifying existing systems to adapt to a different system standard are all activities requiring huge investments, both time-wise and money- wise. In the health care environment it is also politically difficult since many databases and systems are under the operation of separate government agencies.

Furthermore, if a change is made to one system, that change has to be propagated to all the other systems causing those systems to also change. This is an immense operation if the change to one system is fundamental. If the change to a system takes place during operation, such as a change of the content of a database, that change will still have to be propagated to the rest of the system either via the use of a centralized register or via local awareness of the other systems. The first alternative introduces a delay in the system as the central register has to be queried for all queries and the second alternative requires a lot of data to be propagated through the system unnecessarily as the update is not relevant to all systems.

As would be obvious to a person skilled in data systems, further problems of harmonizing differing systems exist.

There is thus a need for a manner of connecting subsystems of varying and/or differing architecture into one system and for maintaining data integrity in such a system allowing various units to retrieve the correct data, and at the correct time.

Furthermore, the integration of the subsystem should be as minimally invasive (as in requiring no or a minimum of modifications) to the subsystems architecture as possible.

Furthermore there is a need to be able to quickly and reliably retrieve the most important information regarding a patient SUMMARY

It is an object of the teachings of this application to overcome the problems listed above by providing a method for use in a data system (100) comprising at least one first unit (110), at least one second unit (160), wherein said first unit (110) is data dependant on said second unit (160) and wherein said first unit (110) is configured to send a request according to a first format and said second unit (160) is configured to receive a request according to a second format, wherein said first format and second format are different, said method comprising: receiving said request from said first unit (110); determining the recipient of the request to be the second unit (160); determining if a transformation of said request is necessary, and, if so, transforming said request; and forwarding said request to said recipient (160).

It is also an object of the teachings of this application to overcome the problems listed above by providing a signaling unit (130) for use in a data system (100) comprising at least one first unit (110) and at least one second unit (160), wherein said first unit (110) is data dependant on said second unit (160) and wherein said first unit (110) is configured to send a request according to a first format and said second unit (160) is configured to receive a request according to a second format, wherein said first format and second format are different, said signaling unit (130) being configured to: receive said request from said first unit (110); determine the recipient of the request to be the second unit (160); determine if a transformation of said request is necessary, and, if so, transform said request; and forward said request to said recipient (160).

It is also an object of the teachings of this application to overcome the problems listed above by providing a control unit (150) for use in a data system (100) comprising one or more first units (110), one or more second units (160) and a signaling unit (130), said control unit (150) being configured to: receive an update from said first unit (110); determine if said update is relevant to said signaling unit (130), and, if so, send an update to said signaling unit (130).

It is also an object of the teachings of this application to overcome the problems listed above by providing a computer readable storage medium encoded with instructions that, when executed by a processor, performs any of the methods according to the teachings herein. By taking advantage of signaling units the system is able to distribute the integration logic so that the various units or components can operate without being modified according to the rest of the system, while still having access to the whole system. This enables an application in one subsystem to access data in another system without being modified.

The use of signaling units provides a communicating language that is easy to adapt to a specific application and it is thereby easy to integrate different systems and applications. The control unit enables easy maintenance of the communicating language of the signaling units.

It is a further object of the teachings of this application to overcome the problems listed above by providing an adaptor unit comprising a signaling unit according to herein and a cache database.

The adaptor unit according to herein allows for various computer and data systems to be easily interconnected without modifications to the computer or data systems.

The system as disclosed herein is adapted to alleviate the latency built-in to integrated systems using contemporary data sharing technologies.

The teachings herein find use in the health care system. Other environments where the teachings herein are beneficial are economic and financial systems, technological databases, design systems, traffic systems, delivery systems, security systems, tourism as well as so called cloud application environments.

Other features and advantages of the disclosed embodiments will appear from the following detailed disclosure, from the attached dependent claims as well as from the drawings.

Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/an/the [element, device, component, means, step, etc]" are to be interpreted openly as referring to at least one instance of the element, device, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated. BRIEF DESCRIPTION OF DRAWINGS

The invention will be described in further detail below under reference to the accompanying drawings, in which

Figure 1 shows a schematic view of a system according to one embodiment of the teachings of this application;

Figure 2 shows a schematic view of a system according to one embodiment of the teachings of this application;

Figure 3 shows a schematic time diagram for a function of a system according to one embodiment of the teachings of this application;

Figure 4 shows a schematic time diagram for a function of a system, wherein a change has been made, according to one embodiment of the teachings of this application;

Figure 5 shows a schematic view of a signaling unit according to one embodiment of the teachings of this application;

Figure 6 shows a schematic time diagram for an update function of a system according to one embodiment of the teachings of this application;

Figure 7 shows a schematic time diagram for an alternative function of a system according to one embodiment of the teachings of this application;

Figure 8 shows a schematic time diagram for a cache function of a system according to one embodiment of the teachings of this application;

Figure 9 shows a schematic time diagram for a transformation function of a system according to one embodiment of the teachings of this application;

Figure 10 shows a schematic view of a control unit according to one embodiment of the teachings of this application;

Figure 11 shows a schematic view of an adaptor unit according to one embodiment of the teachings of this application;

Figure 12a shows a flowchart for a method according to an embodiment of the teachings herein; and

Figure 12b shows a flowchart for a method according to an embodiment of the teachings herein. DETAILED DESCRIPTION

The disclosed embodiments will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein;

rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Like numbers refer to like elements throughout.

Figure 1 shows a schematic overview of a system 100 according to one embodiment of the teachings of this application. The system 100 comprises an application 100 and one or more databases 160. In figure 1 only one database is shown, but it should be noted that the system 100 is adapted to comprise more than one database 160. The application 110 is dependant on data that is stored in the database 160. The application can for example be a patient information retrieval application in an ambulance service. Such an application is dependant on a number of different data, for example, the patient's address, medical history and special needs (allergies or such). These data are often stored at different databases 160 and it is therefore important for the application 110 to be able to access several different databases 160 all possibly using a different language or command structure as has been discussed in the background section. In one embodiment the application 110 is configured with a local database (not shown).

The application 110 is connected to an interface 120 through which the application is connected to a message broker 140. The message broker 140 is configured to forward a request from one entity to another entity and adapt the request according to the different entities' interfaces. However, a contemporary broker 140 is only able to adapt a request according to the interfaces used. The application 110 is also connected to a signaling unit 130. The signaling unit 130 is configured to receive a request from a sender (110) in a command structure or language of the sender, find out the correct recipient (160) based on the request and transform the request into a command structure or language of the recipient. In one embodiment the signaling unit 130 is connected between the interface 120 and the message broker 140, but it should be noted that the signaling unit 130 can be connected anywhere between the application 110 and the message broker 140.

In one embodiment the database 160 is also connected to the message broker 140 through an interface 125 and a signaling unit 135. In one embodiment the interface 125 is configured for allowing data to be sent through a data connection 115. Such data connections 115 may be a VPN (Virtual Private Network) tunnel or other commonly known data connections, such as RS232 or a USB (Universal serial Bus).

The system 100 also comprises a control unit 150. The control unit 150 is connected so that it can communicate with all the signaling units 130, 135. In one embodiment the control unit 150 is connected to the message broker 140. The control unit 150 is configured to update the signaling units 130, 135 according to changes in the system.

In one embodiment the control unit 150 has a user interface (not shown) for allowing manual manipulation of the signaling units 130, 135. In one embodiment the user interface is a web-based interface.

In one embodiment the system 100 also comprises a transforming unit 190. The transforming unit 190 is configured to receive a request to transform data, to transform the data accordingly and return the transformed data.

In one embodiment the system 100 also comprises a logging unit 180. The logging unit 180 is configured to maintain a log of the requests and responses sent through the system 100.

In one embodiment the system 100 also comprises a backup unit or cache database 170. The cache database 170 is configured to store requests issued by the application 110 and the corresponding responses. The cache database 170 is also configured to store a timestamp for the requests and corresponding responses. In one embodiment the cache database 170 is connected to the application 110 as seen in figure 1. In one embodiment the cache database 170 is connected to the signaling unit 130, 135, not shown. Figure 2 shows a schematic view of a larger system 200. The system 200 of figure 2 is a scaled-up version of the system 100 of figure 1. In the system 200 a number (4) of subsystems are connected to one another through a series of message brokers 240. Each subsystem comprises a number of databases 260 and applications 210. It should be noted that not all subsystems have both a database 260 and an application 210. There can exist a subsystem having solely databases 260 (one or more), such as a storing facility. There can also exist a subsystem having solely applications 210 (one or more). As for the system 100 of figure 1 the subsystems of figure 2 may comprise one or more databases 260 and/one or more applications 210 even though only one of each is shown in figure 2. The applications 210 are connected to each a signaling unit 230. In one embodiment as shown in figure 2 the databases 160 are also connected to each a signaling unit 235. In one embodiment not all databases 260 and/or applications 210 are connected to a signaling unit 230, 235.

As in the system 100 of figure 1 a control unit 250 is connected so that it can communicate with all signaling units 230, 235. In the embodiment of figure 2 the control unit 250 is connected to the signaling units 230, 235 through a series of message brokers 240.

Figure 3 is a schematic time diagram showing a basic functionality of the systems 100, 200 of figures 1 and 2. In this diagram the description will focus on a subset of units to explain the basic functionality.

An application 310 issues a request (REQ) for data. The request is issued in a command structure or language of the application 310. In this example the application 310 is not aware of where the data requested is stored. The request is sent to a signaling unit 330 and the signaling unit 330 is configured to parse or otherwise analyse the request to determine the recipient of the request. In this example the signaling unit 330 determines which database 360 that store the requested data. The signaling unit 330 is further configured to transform the request into a command structure or language of the recipient (REQ') and sends this request to the message broker 340. The message broker transforms the request if needed into a format suitable for sending to the database (REQ") and forwards the request to the database 360. It should be noted that the transformations done by the signaling unit 330 and the message broker 340 are different in their nature even though the same word "transform" is used herein. The signaling unit 330 is configured to transform the request on one or several higher command levels, for example changing from an application specific routine call to an SQL language command, and also, to determine who is the recipient of the request. A message broker 140 is commonly adapted to transform messages for transport through differing media such as a conversion from TCP/IP (Transmission Control protocol/Internet Protocol) to MAC OS X protocols.

As the database 360 receives the request (REQ") , which is now in a format according to the command structure or language of the database 360, the database 360 processes the request and returns a response (RESP") in the command structure or language of the database 360. The request (RESP") is sent via the message broker 340 (RESP') to the signaling unit 330 which transforms the response into the command structure or language of the application 310 and forwards the response (RESP) to the application 310.

By allowing the application 310 to communicate with the rest of the system through the signaling unit 330 the application does not need to be altered in any way to be able to keep track of where different data is stored, how to communicate with various other units and it is thus easy to incorporate different local systems and data storages into a distributed system even though all units use a different format. This is particularly beneficial for systems that are to comprise local components or units that are already developed and possibly in use as no modifications are needed to the local units. The units (110, 160) only need to be connected via a signaling unit 130, 135 to the system.

In systems with many different data storages it is a problem to keep an updated centralized record of where all data is stored. Such a centralized record would have to be queried once for each request to make sure that the request is sent to the correct recipient. This adds a huge load on the communication system and also increases the latency for any request sent in the system. Alternatively, the record keeping is distributed. This has two major disadvantages, namely that each component or unit will have to keep a complete record of where all data is stored and this requires that any update is communicated to each and every unit and also that each unit have to be modified to carry the record and to handle updates.

Figure 4 is a schematic time diagram showing a further beneficial functionality of the systems 100, 200 of figures 1 and 2. In this diagram the description will focus on a subset of units to explain the further function.

In one embodiment the signaling unit 130, 430, 435 is configured to keep a record of a backup or replacement unit. The replacement or back up unit is in one embodiment the database 460b that data has been moved to from the original database 460a. In one embodiment the signaling unit is configured to keep a register of replacement unit for a data unit. A backup database 460b is a database 160 that is to be used if the original database 460a is down or, possibly, experiencing heavy traffic load. This allows the signaling unit 130,430,435 to easily reroute any request to the appropriate recipient should a request for data that has been moved be received.

A request (REQ) is sent from an application 410 via a signaling unit 430 which determines the recipient to be a first database A (460a). The request is transformed to a language or command structure of the database 460a (REQ '(A)) and forwarded via the message broker 440, which possibly also modifies the request (REQ"(A)), to the signaling unit 435 of the receiving database 460a. The signaling unit 435 a is configured to check any incoming request to make sure that the database does in fact store the requested data. In this example the data has been moved to a second database 460b and the signaling unit 435 a transforms the request to reflect this

(REQ"(B)) and, if necessary, also into a command structure or language of the second database 460b. The request is then forwarded via the message broker 440 to the second database 460b via its signaling unit 435b. The database 460b processes the request and returns a response (RESP") to the message broker 440 via the signaling unit 435b. The message broker 440 forward the response (RESP') to the signaling unit 430 of the requesting application 410 where it is transformed into a command structure or language of the application (RESP) and forwarded to the application 410.

The requesting application is thus able to request data without knowing the storage point of the data even though the data has been moved and the system not yet been updated concerning the data move. This has great beneficial use in a system with distributed data storages.

Figure 5 shows a schematic view of a signaling unit 500. The signaling unit 500 comprises a home interface 520 which is connected to the unit that the signaling unit 500 belongs to. In figure 1 the signaling unit 130 is connected to the application 110 via the home interface 520. The signaling unit 500 further comprises a system interface 530 which is connected to the rest of the system. In figure 1 the signaling unit 130 is connected to the message broker 140 via the system interface 530. The signaling unit 500 has a controller 510. The controller 510 is in one embodiment implemented as a central processing unit (CPU). In one embodiment the controller 510 is implemented as a computer process. The controller 510 may be implemented using instructions that enable hardware functionality, for example, by using executable computer program instructions in a general-purpose or special-purpose processor that may be stored on a computer readable storage medium (disk, memory etc) to be executed by such a processor. In one embodiment the controller 510 of the signaling unit 500 is configured to keep a record 540 of the data dependency for the home unit. The record 540 is thus designed to keep track of which request (REQ) is dependant on which unit (recipient)(REC) and the format (FORM)for the request that the recipient requires. The controller 510 is configured to receive a request via the home interface 520 and to parse or analyse the request by determining the corresponding recipient and to transform the request into a format suitable or requested for the recipient. The controller 510 is further configured to send the transformed request via the system interface 530.

To allow even faster and efficient communication in a system 100, 200 a control unit 150 is configured to receive update information from one unit and from this update determine the affected units or applications 110 and update the corresponding signaling units 130, 135.

The control unit 150 is thus configured to keep a record of which unit is dependant on which other unit. This is a great simplification in that not all units need to be amended or changed to know which system it is dependant on. Figure 6 is a schematic time diagram showing an update functionality of the systems 100, 200 of figures 1 and 2. In this diagram the description will focus on a subset of units to explain the update function. The description will be made with concurrent references to figure 10 which shows a schematic view of a control unit 650, 1000.

A database 660 has been modified as regards its content, that is, the data stored thereon. Such a modification may relate to the deletion of a register, the move of a register or added information to a register. An update notification (UPDATE) regarding the modification is sent to the system, via the message broker 640, which forwards the notification to the control unit 650, 1000. The control unit 650, 1000 comprises a controller 1010 and a system interface 1020. The controller 1010 is in one embodiment implemented as a central processing unit (CPU). In one embodiment the controller 1010 is implemented as a computer process. The controller 1010 may be implemented using instructions that enable hardware functionality, for example, by using executable computer program instructions in a general-purpose or special-purpose processor that may be stored on a computer readable storage medium (disk, memory etc) to be executed by such a processor. The controller 1010 is configured to receive an update notification (UPDATE) via the system interface 1020 and to analyse the update to determine which unit the update relates to, what data it relates to and what units that are affected by the update. The control unit 650, 1000 comprises a semaphore record 1040 that is configured to correlate one unit (UNIT A), its data dependencies (DATA DEP1, DATA DEP2) with the corresponding unit and the formats involved.

In the example of figure 10 a unit, the application 610, has a data dependency in that the patient information (PATIENT) is stored on the database 660, which should always be queried in SQL. In this embodiment the register is based on data dependencies for units and is adapted to register which units a unit is dependant on. In one embodiment the semaphore register is based on a unit and which other units are depending on it. In one embodiment the semaphore register is based a combination where a register is adapted to keep track of a unit and which units it depends on as well as which units are dependant on it. It should be noted that there exist any possibilities of how such a register is implemented. In one embodiment the controller 1010 is configured to receive an update and to parse through the semaphore register 1040 to find affected units, to update the semaphore register 1040 to reflect the update and to notify the affected units. Thus, only the affected units are involved in the data traffic through the system and this reduces the traffic load on the system compared to if all units were to receive the same updates.

Returning to figure 6, the controlling unit 650 receives the update, updates the semaphore register 1040 as described above. The controller 1010 of the controlling unit 650 is further configured to send out updates to the signaling units 630 of the affected units 610. In figure 6 this notification is sent via the message broker 640. Upon receipt of such an update notification the signaling unit 630 updates its own records 540.

As is indicated by the dashed box in figure 6, the application 610 and the signaling unit 630 may be seen as one unit from the system perspective. This provides an easy model of the system to implement as any unit may be added or deleted from the system without affecting the unit's internal working or the system. This allows for a scalable system.

In an alternative embodiment the control unit 150, 250 is configured to determine and register all applications functions and the corresponding data

dependencies. In such a system, the control unit 150, 250 is configured to store a number of semaphores and their corresponding meaning and connections for the various units 110, 160 in the system 100. The signaling units 130 are configured to transform a request into a semaphore which is then sent to the control unit 150. The control unit 150 is configured to transform the semaphore into a corresponding semaphore for a receiving unit and send the corresponding semaphore to the recipient. In such a system, the applications and databases 110, 160 need only be coupled to a simple signaling unit 130 which is arranged to transform he request into a basic semaphore.

In one embodiment a semaphore is a standardized command that is mapped to a function. Examples of such semaphores are: F1(A,B) = REQUEST DATA A FROM B; F2(A) = STORE DATA A; F3(A) =UPDATE DATA (A). The signaling units are thus configured to transform a request into the corresponding standard semaphore. Figure 7 is a schematic time diagram showing a basic functionality of the systems 100, 200 of figures 1 and 2 according to the alternative embodiment described above. In this diagram the description will focus on a subset of units to explain the basic functionality.

An application 710 sends a request (REQ) to a signaling unit 730. The signaling unit transforms the request into a semaphore (SI) and sends it to the control unit 750 via the message broker 740. The control unit checks the semaphore's meaning, determines the recipient and possibly transforms the semaphore, if necessary, into a semaphore (S2) (not shown in figure 7) specific to the recipient 760, and forwards the semaphore to the recipient, via the message broker 740. In figure 7 the semaphore is transformed into a request (REQ') understandable to the database 760. The database processes the request and returns a response (RESP") which is returned to the control unit 750. The control unit transforms the response and forwards it to the signaling unit 730 which transforms the response to a format that is understandable to the requesting application 710.

Such a system has the benefit over the prior art that it allows various components or units to communicate with each other without explicitly knowing the format or command structure of the other units, or even which unit is responsible for what in the overall system.

In many distributed data storage systems a request for data is time- sensitive and a response must be received within a foreseeable time window. The system according to herein is adapted to provide responses within such time window even when parts of the system are down.

Returning to the systems 100, 200 of figures 1 and 2 the applications 110, 210 are connected to a database 170, 270 configured to cache data requests as has been explained above. Figure 8 is a schematic time diagram showing a basic functionality of the cache database 170, 270 of the systems 100, 200 of figures 1 and 2. In this diagram the description will focus on a subset of units to explain the cache function.

An application 810 sends a request (REQ) via the interface 820, signaling unit 830 and the message broker 840 to some other part of the system 100, 200. The signaling unit 830 is configured to determine whether a response is timely received from the message broker 840 or not.

A timely response is a response that is received. A reason for no response being received is that the system or the corresponding subsystem is off line at the moment. In one embodiment a timely response is a response that is received within a time limit.

In one embodiment the signaling unit 830 is configured to determine whether a timely response has been received or not, and, if not, send a query to the cache database 870 for the request (REQ). The cache database 870 is configured to receive the query and in response thereto provide a previous response (RESP) to the request and send the response to the signaling unit 830 together with a timestamp indicating the time at which the response was last valid. The signaling unit 830 forwards the response to the application 810 which can now use the data while waiting for the current data to arrive, assuming that the time stamped data is still valid.

In one example (not shown) an application 810 receives a request via the interface 820, signaling unit 830 and the message broker 840 from another part of the system 100, 200. The signaling unit 830 is configured to determine whether a response is timely received from the application or not.

In one embodiment the signaling unit 830 is configured to determine whether a timely response has been received or not, and, if not, send a query to the cache database 870 for the request. The cache database 870 is configured to receive the query and in response thereto provide a previous response to the request and to send the response to the signaling unit 830 together with a timestamp indicating the time at which the response was last valid. The signaling unit 830 forwards the response to the message broker 840 for further forwarding to the requesting application which can now use the data while waiting for the current data to arrive, assuming that the time stamped data is still valid.

In one embodiment the signaling unit 130 is configured to determine whether the timestamped response should be used or not. In one embodiment the receiving application 810 is configured to determine whether the timestamped response should be used or not. In one embodiment a control unit 130 is configured to determine whether a received response is valid or not, and if not, query the cache database 170, 870 for a temporary response as for when a timely response is not received. A response may not be valid due to bit corruption, outdated data, or data format for example.

A cache database 170, 870 is configured to monitor the connection from and to the signaling unit 130,830 and to store requests and the corresponding responses. In one embodiment the cache database 170,870 is configured to store the last N requests, where N is a number depending on a memory size of the cache database. In one embodiment the cache database 170,870 is configured to store requests and corresponding responses having a priority.

In one embodiment an application 810 or a database 860 is configured to pre-load a cache database 170, 870 with information that is important and/or has a high priority. Such information can for example be medical information relating to a patient. This allows a system to always have a response at hand even if parts of the system is experiencing connection disruptions.

In some instances the format of a request or data is to undergo a transformation that the signaling unit 130 is not able to perform. This allows for signaling units 130 of low complexity to be implemented in the system. The signaling unit 130 is, in such an embodiment, configured to determine whether a request or the resulting data needs to be additionally transformed. One example of such a

transformation is a unit converter. If, for example, the application 110 is designed to work with SI units and the database 160 is designed to store Imperial units the signaling unit 130 will register this in the register and for each related request an additional transformation will be effected.

Figure 9 is a schematic time diagram showing a basic transformation functionality of the systems 100, 200 of figures 1 and 2 according to the alternative embodiment described above. In this diagram the description will focus on a subset of units to explain the basic transformation function.

An application 910 sends a request (REQ) via a signaling unit 930 and a message broker 940. The request is forwarded and processed by the cache database 970 and the resulting response (RESP') is returned to the signaling unit 930. The signaling unit is configured to determine whether an additional transformation is required, and, if so, forward the response (RESP') to the transformation unit 990. The transformation unit 990 is configured to receive a data structure and according to specified

transformation criteria, transform the data structure and return it. The response is thus returned to the signaling unit as a transformed response (RESP"). The signaling unit 930 thereafter forwards the response to the application 910 in a format (RESP) that is understandable to the application 910.

In one embodiment relating to health care systems the database 160 is configured to store a collection of important information relating to a patient. Such a collection can be stored separately in different databases, but accessed through one common request. In one embodiment the collection of important data is stored in one database 160.

Collecting and compiling important data relating to one topic or in this example a patient, in an easily accessible manner allows for a quick recall of the important information.

In one embodiment the cache database 170 is configured to store said collection of important information.

To allow an application or other unit to be connected to a system the teachings herein provide for an adaptor unit that is easily connected between the application and the system.

Upon connection the control unit 150 is updated accordingly to reflect the application's different dependencies.

Figure 11 shows such an adaptor unit 1100. The adaptor unit 1100 comprises a signaling unit 1130, an interface 1120 and in one embodiment a cache database 1170. The adaptor unit further comprises a memory 1140 for storing the record of the signaling unit 1130 and a controller for performing the tasks of the signaling unit 1130, the interface 1120 and in one embodiment the cache database 1180. In one embodiment the controller 1110 is central to the adaptor unit performing the tasks of one or more units 1120, 1130, 1170. In one embodiment the controller 1110 is distributed between the units 1120, 1130, 1170. The controller 1110 may be

implemented using instructions that enable hardware functionality, for example, by using executable computer program instructions in a general-purpose or special-purpose processor that may be stored on a computer readable storage medium (disk, memory etc) to be executed by such a processor.

The adaptor unit 1100 may be implemented as a computer, as an integrated circuit board, such as an Application-Specific Integrated Circuit, ASIC, as an arrangement of integrated circuits or for example using a number of embedded systems, virtual computers or workstations.

Figure 12a shows a flowchart for a method according to the teachings herein. First a request is received 1210 from a first unit 1 10, being an application in one embodiment. The recipient of the request is determined 1220. Then it is determined if a transformation of the request is necessary, and, if so, the transformation is done 1230 after which the request is forwarded to the recipient 1240.

Figure 12b shows a flowchart for a method according to the teachings herein, which method continues from the method described above in relation to figure 12a. After the request has been forwarded to the recipient 1240 for processing, the response is received 1250 from the second unit 160. It is then determined if the response needs to be transformed and if so the response is transformed 1260. After that the response is forwarded 1270 to the first unit 110.

As would be realized by a skilled person in computer systems a computer system is implemented using a number of workstations and servers. The exact configuration of the workstations and servers are, of course, dependant on the system architecture. In one embodiment the message broker is implemented on a server. In one embodiment the application is implemented as a program running on a workstation. In one embodiment the database is implemented on a server.

A server comprises an interface for receiving requests and sending responses and a controller for controlling the server in accordance with instructions stored in a memory to process the received requests.

A workstation comprises an interface for receiving commands, sending commands and receiving responses and a controller for controlling the work station in accordance with instructions stored in a memory to process the requests and received responses. The controller of a work station or a server may be a central processing unit and may be implemented using instructions that enable hardware functionality, for example, by using executable computer program instructions in a general-purpose or special-purpose processor that may be stored on a computer readable storage medium (disk, memory etc) to be executed by such a processor.

The databases discussed herein may be implemented using commonly known memory arrangements such as secondary memories such as hard drives, magnetic tapes, discs or primary memories such as ROM, RAM, SRAM, DRAM, CMOS, FLASH, DDR, SDRAM or some other memory technology.

It should be noted that even though the control unit 150 has been described above as communicating with the signaling units 130, 135 through a message broker 140, the control unit can, also be implemented to communicate directly with one or more signaling units 130, 135.

Even though the message broker 140 has been described as taken part in communications between units in the examples given above, it should be noted that the use of a message broker is not essential to the teachings herein and any form of connection between the units is possible under the scope of the teachings herein. For example, the message broker 140 is in one embodiment replaced with a network hub or a Wi-Fi router to connect the various subsystems.

References to 'computer-readable storage medium', 'computer program product', 'tangibly embodied computer program' etc. or a 'controller', 'computer', 'processor' etc. should be understood to encompass not only computers having different architectures such as single /multi- processor architectures and sequential (Von

Neumann)/parallel architectures but also specialized circuits such as field- programmable gate arrays (FPGA), application specific circuits (ASIC), signal processing devices and other devices. References to computer program, instructions, code etc. should be understood to encompass software for a programmable processor or firmware such as, for example, the programmable content of a hardware device whether instructions for a processor, or configuration settings for a fixed- function device, gate array or programmable logic device etc. One benefit of the teachings herein is that a system that is highly flexible and that is able to provide sensitive and reliable information in real time and under strict time constraints is achieved.

The invention has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.