Abstract:
A system and method for real time updating and displaying medical diagnostics data, wherein the information stored in databases comprising large amounts of sensitive data that is being updated frequently are provided herein. By using a batch table for data filtering and a snapshot table for data retrieval, the system&#39;s performance remains substantially predictable and stable regardless of the base tables&#39; size.

Description:
FIELD OF THE INVENTION 
       [0001]    The present invention relates to system for analysis and display of information related to medical diagnostic devices. In particular the invention relates to displaying relevant data which is constantly added and updated. 
       BACKGROUND OF THE INVENTION 
       [0002]    In the field of medical diagnostics, medical instruments may utilize methods such as chromatography to analyze blood samples from patients. Each chromatographic analysis may result in more than 200 kilobyte data cluster. Typical medical diagnosis equipment may be used in a hospital or a clinic for over 20 years, and provide analysis results for up to about 6000 samples each day. Thus, huge amounts of data related to the performed medical diagnosis data are accumulated over time. 
         [0003]    Unlike traditional databases common to software applications in other fields, medical diagnostics may comprise little or no redundant data which can be ignored or even deleted. Every data record may potentially contain information which may be critical to a correct diagnosis of a patient. More so, each of the data records may contain information pertaining to the condition of the medical instrument as a whole or its parts, the operators of the instrument or the like, information which may be relevant in the detection of machine or human related malfunctions in the diagnosis process. 
         [0004]    With medical instrumentation, data records regarding new samples are constantly generated and updated in a database. 
         [0005]    Client applications typically access the database to obtain a recent snapshot of the data, usually by defining a filter indicating relevant records and data portions. A paging mechanism is typically used to obtain the snapshot, so that it can be displayed to a user, typically a machine operator or a member of the medical staff. 
         [0006]    Traditional paging, however, does not allow the snapshot to be updated without user intervention when new records join the database. The user is typically not made aware of the ongoing changes and additions taking place in a relatively large dataset. Thus, the display rarely represents an accurate filtered, sorted view of relevant events in real-time. 
         [0007]    Client-side paging is not effective when it comes to dealing with very large databases (VLDBs). Handling paging at the business logic level is not effective because each client may require different filtering and sorting. With specific server-side paging, each paging component utilizes its own set of data, procedures and logic within the database. More so, frequent database updates may eventually result in excessive memory consumption. 
       SUMMARY OF THE INVENTION 
       [0008]    Typical medical diagnostics databases consume large disk space: the number of data records increases rapidly, and each data record may be, and typically is large (for example and without limitation ˜200 Kb or more per single record). Medical records are highly sensitive, and thus records may need to be maintained in the databases without compromising long-term data integrity. Medical equipment is typically robust and long-lasting, as medical diagnostic systems often have a life span of ˜20 years, and monitor diagnostics data taken from thousands of samples per day. The data aggregated may comprise not only pure medical laboratory test results, but also information about the physician, the patient, the diagnostics device, the time of day or the like. 
         [0009]    The system is configured to keep client views comprising medical diagnostics data records automatically updated in real time. Each client view is defined by data selection filters according to specified criteria. The system uses the data selection filters for arranging and sorting large medical diagnostic event databases according to the selected criteria. The system is further capable of analyzing incoming events according to existing filters, and updating client views with relevant incoming events at real time. Filters are used by the clients to sort and display the information according to their needs. For example, there could be a plurality of client classes such as: 
         [0010]    1. Medical care givers, such as doctors, that may be interested in reviewing records of a specific patient. These may want to view the progress of a specific test type such as cholesterol level or glucose level over time, or view results of different tests associated with a specific patient. Such client may be interested to view and compare similar results from a related group of patients, for example to discover family trends, etc. 
         [0011]    2. Medical researchers that may be interested in reviewing records of a group of patients and perform statistical analysis of these records. 
         [0012]    3. Lab technicians entering records or performing laboratory tests. 
         [0013]    4. Billing and administration personnel, reviewing or modifying billing information. 
         [0014]    5. System administrators, reviewing the operation of the IT system and monitoring the information flow. 
         [0015]    6. Service personnel, monitoring the physical integrity and test accuracy. 
         [0016]    Within each client class, individual clients may have different needs or preferences. 
         [0017]    A method for updating and displaying medical diagnostics data according to some embodiments of the present invention may include: generating by at least one data generator a data record and a data notification associated with the generated data record and inserting the generated data record to a database; and applying to the data notification at least one client filter associated with at least one client. 
         [0018]    Upon determination that the data notification matches the client filter, the method may further include generating and submitting a database query to the database by a data provider. The database may provide to the data provider, in response to the query, a record set associated with an updated view including the generated data record. The data generator may submit to the at least one client data objects associated with the record set. The at least one client may display the updated view comprising information derived from the record set. 
         [0019]    In some embodiments of the present invention, the applying of the at least one client filter is performed by the data provider. In other embodiments, the applying of a client filter is performed by the at least one client, the applying further includes: submitting the data notification, by the data provider to the at least one client; applying to the data notification by the at least one client a respective filter associated with the at least one client. In such cases, the generating of a database query may include, upon determination that the data notification matches the client filter, generating and submitting a page request by the at least one client to the data provider; and generating by the data provider a database query associated with the page request. 
         [0020]    According to some embodiments of the present invention, the at least one client may be one of a plurality of clients, and/or the at least one data generator may be one of a plurality of data generators. 
         [0021]    It is another aspect of the current invention to provide a method of fetching, navigating within, and displaying a part of large medical diagnostics dataset, the method may include creating a list of results, which may include: receiving from a client, by a data provider at a server, selected search criteria; submitting the search criteria to a Data Access Layer (DAL); converting by the DAL the search criteria to database type search criteria and sending the database type search criteria to a database; and creating a list of matching results in a temporary table in the database and returning a list identifier of the list to the client. 
         [0022]    Further, the method may include navigating over the list of results, which may include: receiving, by a data provider at a server, a page request including a list identifier of the created list and a page range; submitting the page request to the DAL; converting by the DAL the page request to a database type page request and sending the database type page request to the database; creating a page size list of results matching the page request and returning the page size list of results to the client; and displaying the page size list of results. 
         [0023]    In some embodiments of a method according to embodiments of the present invention, the selected search criteria may include a selected filter and selected sort criteria. The creating of a list of results may be repeated, for example, by receiving from a client, by a data provider at a server, different selected search criteria, comprising the selected filter and different sort criteria. The navigating over a list of results may be repeated, for example, by receiving, by a data provider at a server, a page request including a list identifier of the created list and a different page range. 
         [0024]    Although demonstrated herein through a specific example of medical diagnostics data, the system is generic and can be applied to other types of information stored in databases comprising large amounts of sensitive data that is being updated frequently, for example and without limitation financial and legal data. By using a batch table for data filtering and a snapshot table for data retrieval, the system&#39;s performance remains substantially predictable and stable regardless of the base tables&#39; size. 
         [0025]    Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of the present invention, suitable methods and materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and not intended to be limiting. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0026]    For a better understanding of the invention and to show how it may be carried into effect, reference will now be made, purely by way of example, to the accompanying drawings. 
           [0027]    With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of the preferred embodiments of the present invention only, and are presented in the cause of providing what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the invention. In this regard, no attempt is made to show structural details of the invention in more detail than is necessary for a fundamental understanding of the invention; the description taken with the drawing making apparent to those skilled in the art how the several forms of the invention may be embodied in practice. In discussion of the various figures described herein below, like numbers refer to like parts. The drawings are generally not to scale. 
           [0028]    In the accompanying drawings: 
           [0029]      FIG. 1  schematically illustrates a typical physical environment of the medical diagnostics system; 
           [0030]      FIG. 2  schematically depicts a simplified block diagram showing the interaction of a client with a machine computer. 
           [0031]      FIG. 3  schematically shows the concept of paging used for viewing data by the user at client. 
           [0032]      FIG. 4  schematically depicts the process of transferring requested data from the database to the client. 
           [0033]      FIG. 5  schematically depicts a method of inserting a new data into the database while concurrently updating the client&#39;s page, provided that the new data is associated with the page currently viewed by the user. 
           [0034]      FIG. 6  shows some details of a page-loading and navigation process. 
           [0035]      FIG. 7  is a schematic data flow of serial data insertion into a data storage unit; 
           [0036]      FIG. 8  is a schematic data flow of data insertion into a data storage unit wherein the data is first parsed before it is inserted into a database. 
           [0037]      FIG. 9  is a schematic data flow of data insertion into a data storage unit, wherein the data is first parsed before it is inserted into a database and concurrently filtered, first by a first filter and then by a second filter. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0038]    Before at least one embodiment of the invention is explained in detail, it is to be understood that the invention is not necessarily limited in its application to the details set forth in the following description or exemplified by the Examples. The invention is capable of other embodiments or of being practiced or carried out in various ways. 
         [0039]    It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination or as suitable in any other described embodiment of the invention. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements. 
         [0040]    In discussion of the various figures described herein below, like numbers refer to like parts. The drawings are generally not to scale. For clarity, non-essential elements were omitted from some of the drawing. 
         [0041]    Various embodiments of a system and method for analysis, archiving, retrieval and display of medical diagnostics related data are disclosed hereinbelow. 
         [0042]    Reference is now made to  FIG. 1  schematically illustrating a typical physical environment of the medical diagnostics system embodiment  100 . In this embodiment, system  100  comprises three medical lab devices  10   a ,  10 B and  10 C, a server  20 , a database serving as a data storage unit  30  and two clients  40   a  and  40 B. However, it should be noted that number of components may be different or larger. Devices  10  may be operated automatically or by an operator such as a physician or a technician. Devices  10  are capable of running medical processes, for example and without limitation: perform examinations to patients or to perform laboratory examinations on biological sample. For example, Devices  10  may conduct chromatography or spectroscopic tests on blood or urine samples taken from patients, etc. Devices  10  are also configured to produce diagnostic data records  111  related to the medical process. Diagnostic data records are sent to at least one server  20 , and stored in at least one data storage unit  30 . Optionally or additionally backup devices for database  30  (not seen in these figures) may be used. 
         [0043]    Diagnostic data records typically accumulate such that patients&#39; overall data stored in the data storage unit may comprise information such as but not limited to: 
         [0044]    1. Patient personal &amp; contact information: unique ID, sex, age, marital status, address, phone, insurance company, financial balance, etc. 
         [0045]    2. Patient medical information: medical background, diagnosed diseases, visits to medical care facilities, previous lab results, etc. 
         [0046]    3. Diagnostic device information: device ID, operator ID, etc. 
         [0047]    4. Specific sample information: time and date records of sample gathering, time and date of sample analysis by the medical device, medical device measured raw or processed data, analysis results, etc. 
         [0048]    Diagnostic data records are periodically produced by physical medical devices  10 . Time intervals between subsequent diagnostic data records creation are generally predictable, and bound by measureable parameters such as but not limited to the number of medical devices producing the data records. Smart arrangement of diagnostic data records in the data storage unit during the record insertion process facilitates efficient retrieval of relevant data for substantially real time diagnostic data displays. 
         [0049]    In some embodiments, specifically when a single device  10  is used, a machine computer  120  associated with said device may assume the functionality of the server  20 . However, even when one device  10  is used, a plurality of processors or processes within the device may generate data records  111  and are thus termed data generators  140 . The Data Generator generates records of data such as results, orders, logs and the likes. This situation is illustrated in  FIG. 2 . In other embodiments, (for example, but not limited to) where a plurality of devices  10  interacts with one or a plurality of clients  40 , data generators  140  are located in the devices  10 , while other computing functions, such as data provider  130  and database  30  are located in server  20 . Thus, the functions of machine computer  120  may encompass the functionality of server  20 . 
         [0050]    A user interacts with the system using a viewing unit represented by the client  40 . For the purpose of this discussion, the term “Client  40 ” refers to the UI (User Interface component). The viewing may be done using a computer such as a PC, a terminal or a mobile device and may be situated in proximity to server  20  or remotely. Generally, the client  40  has at least a display such as a screen and input devices such as keyboard and a mouse. The client has a limited processing power and limited data storage capacity, usually the processing and storage capabilities of the client are substantially less than the corresponding capabilities of the server. 
         [0051]      FIG. 2  schematically depicts a simplify block diagram  110  showing the interaction of a client  40  with a machine computer  120 . 
         [0052]    For drawing clarity, only one data generator  140  (namely  140   a ) and one client  40  (namely  40   a ) are seen. Data provider  130  is used for transferring needed data from database  30  to client  40   a.    
         [0053]    When a new data  111   a  is generated by the data generator  140   a , it is added to database  30 . Concurrently, data generator  140   a  issues a “new data notification”  145   a  to notifies the data provider  130  which transfers that new data to the client  40   a.    
         [0054]    It should be noted that there can be several clients  40  and several Data generators  140 , but only one Database  30 . Preferably there is one Data Provider  130  serving all clients  40 , however in some embodiments each client  40  is served by a dedicated data provider  130 . The client (or clients)  40  may be either local (executed on the same computer with the DB  30 ) or remote (running from a remote computer). 
         [0055]    The Data Provider  130  provides the data to the client  40 . The Data Provider enables the client to run on a remote or a local computer seamlessly. It also acts as a buffer between the Client and the Database. 
         [0056]      FIG. 3  schematically shows the concept of paging used for viewing data by the user at client  40 . 
         [0057]    As can be seen in illustration  310 , at any given time, a user  312  views, using the client  40  display, a view  314  with a small amount  316  of the data out of the large data  318  in database  30 . The user may choose to display information selected from the large database  30  by defining criteria for filtering and/or sorting the information. Getting all the Data from the database  30  to the client  40  would result in: Very large communication block sent through the communication channels; and a necessity to store and sort the large amount of data at the client&#39;s side. This poses high burden on the speed of the communication channels, the storage capacity at the client and the clients processing power and speed, thus increasing the system cost. 
         [0058]    The filtering and/or sorting may be performed according to embodiments of the present invention by optimized search tables that may be customized to match the client&#39;s search/view criteria, wherein the search tables may be updated in real time. 
         [0059]    The Paging Mechanism seen in illustration  320  is capable of managing data transfer from the database  30  to a client  40  in an optimized way. 
         [0060]    The paging mechanism is combined of two complementary phases: Server side paging and Client side paging. 
         [0061]    The Server side paging mechanism comprises interfaces for creating a list of results according to the criteria given by the user; and interfaces for navigating over the generated list of results by providing the list ID and the range of requested results. The interfaces are accessed via server side components hosted on the WAS (Data Providers) and the actual list of results is stored optimally in the database. The result object that returns to the client when creating a list of results includes the created list ID and the number of results in the list. 
         [0062]    The client side of the paging mechanism is done by determining a page size and requesting the server to transfer chunks of data. Each chunk size is a page size such as page 1 or page 2 ( 319   a ,  319   b  and  319   c  respectively, but number of pages may be larger or there may be only one page associated with a specific criteria). The client requests only for the needed pages and not for all the data (which may be very large). 
         [0063]    Using the paging method, the client loads load only the relevant portion of the data needed for viewing. When the user changes the view position, loading of new data as required. 
         [0064]    In some embodiments, when two or several pages are associated with viewing criteria, the client may request, obtain and pre-load into a local storage at least one, and optionally few of the next pages to be viewed according to the sorting and viewing criteria. Next-page pre-loading enables rapid scrolling or page-switching with only modest increase of the client local storage capacity. Pre-loading make uses of the time the user spends reviewing the current page to pre-load the next anticipated view. Obviously, if the user chooses to change the filtering or sorting criteria and review different type of data, the pre-loading actions were wasted. Thus, pre-loading imposes some burden on the communication channels. 
         [0065]    After reviewing the displayed data, the user may want to view other portion of the data associated with the same filtering and sorting criteria by: scrolling or by Jumping to a new location (random access), for example by using the slider. 
         [0066]    Using pages larger than the actual display may prevent delays when scrolling (as long as the scrolling is within the loaded page). Pre-loading the adjacent pages may also prevent delays when scrolling. 
         [0067]    However, jumping to a new location may cause a delay until the new data is fetched. Using smaller page size may decrease this delay. The page size is thus optimized: not too large—to avoid a fetch delay in a single call to the DB, and not too small because if the page size is too small many requests will be issued to the DB when the user scrolls down. 
         [0068]      FIG. 4  schematically depicts the process of transferring requested data from the database  30  to the client  40 . For drawing clarity, only one client is seen, and the data generator and data insertion into the database were omitted from the drawing. 
         [0069]    The user may request to view a subset of the data records by specifying a filter to narrow the number of data records to view. Additionally, the user may want to view the data in a specific order or arrangement using defined sorting criteria. The filter and the sort type are specific to each implementation and user. Generally, a plurality of filtering and sorting combinations may be defined by the users. According to some embodiments of the present invention, the filtering and/or sorting may be performed by optimized search tables that may be customized to match the client&#39;s search/view criteria, wherein the search tables may be updated in real time. 
         [0070]    When a user choose to change the display on his client, he selects a new filter and/or sort combination. 
         [0071]    The user&#39;s client  40  sends a page request  410  to the data provider  130  which interfaces with the database  30  via the Data Access Layer ( 420 ). The DAL  420  provides interface for accessing the database via an assembly reference. It provides the interface for creating a generic list of results represented by the returned list ID, and the interfaces for navigating a results list by list ID and range. The DAL  420  exposes database&#39;s common data objects in its interfaces to the Data Provider  130  (or data providers  130   a, b , etc., if dedicated data providers are used with each client), and it is charge of converting them to the DB types exposed in the matching DB stored procedures. 
         [0072]    The Data Provider  130  (or data providers  130   a ,  130   b , etc.) are the server side components, hosted on the server  20  or the machine computer  120 , which serve as the client&#39;s façade to the database  20  for interactions related to paging. Optionally, the data provider comprises a Results Provider which implements the paging mechanism for fetching results. 
         [0073]    The clients ( 40   a ,  40   b , etc.) send the user&#39;s search and sorting criteria along with its client unique ID to the appropriate data provider and gets a unique list ID for that identifies the created list of results in the database. The client then communicate with the data provider and uses the given list ID to navigate over the results list, by defining the range of expected results (start and end index of requested results within the list). 
         [0074]    The Data Access Layer (DAL)  420  (DALs  420   a ,  420   b , etc.) provides interface for accessing the database via an assembly reference. It provides the interface for creating a generic list of results represented by the returned list ID, and the interfaces for navigating a results list by list ID and range. The DAL exposes the database&#39;s common data objects in its interfaces to the Data Providers, and it is charge of converting them to the DB types, exposed in the matching DB stored procedures. 
         [0075]    The DB is requested  412  to bring specific pages according to the defined filter and sort and thus the filtering and the sorting may be done by specifying an appropriate query  412  to the DB  30  that will be implemented in the DAL  420 . In each page request the client sends the filter and the sort type along with the page request. Note that each filter and sort change requires the client to reload its data. 
         [0076]    Database  30  provides the data  414  to client  40  via DAL  420  and data provider  130 . 
         [0077]    The client loads the new data by loading the current page and swapping out all other pages in its memory. 
         [0078]      FIG. 5  schematically depicts a method of inserting a new data into the database while concurrently updating the client&#39;s page, provided that the new data is associated with the page currently viewed by the user. 
         [0079]    Some embodiments of the present invention may provide smart insertion, arrangement, and processing of a new result introduced to the system. A new data record may be validated against various filters applied by clients of the system, and an appropriate notification may be sent to the relevant clients. 
         [0080]    When new records are generated by one of the data generators  140  while at least one client  40  is active, the new data  510  is inserted to the DB  30 . 
         [0081]    Preferably, the new data  510  is to be reflected in client&#39;s view as soon as possible. However, if the client is looking at a part of the view which does not contain these new records, no updating is needed at the client. Since the client page is updated by a page request  410  as seen in  FIG. 4 , client has no way of knowing to which page this new record was entered. It would be a high burden on the system to reload the current page every time a new record had been entered, as reloading current page is similar to the operation which is needed for a filter change or a sort change. 
         [0082]    A method for updating and displaying medical diagnostics data according to embodiments of the present invention may include generating by at least one data generator a data record and a data notification associated with the generated data record and inserting the generated data record to a database. 
         [0083]    For example, the following process may used to ensure efficient and fast page update: 
         [0000]    1. When a new record is generated by the data generator  140  and is inserted into the database  30  in its proper place.
 
2. The data generator  140  further issues a new data notification  512  to data provider  130 .
 
         [0084]    Additionally, the method may include applying to the data notification at least one client filter associated with at least one client. For example, the following steps may take place: 
         [0000]    3. The new data notification  512  is passed to the client  40  via the data provider  130 . Optionally, the new data notification does not include the entire information in the new record, but only enough information that enables the system to determine if the new record meets the criteria of the current filter, and optionally to sort the new record and to determine if the new record is included in the current page or the current user&#39;s view.
 
4. Client  40  examines the new data notification, and only if it determine that the new record is needed at the client (that is—the new record is associated with the current viewed page), it issues a page request  514  to the data provider  130 . Optionally, Data provider  130  performs the examination of the new data notification, and only if it determine that the new record is needed at the client it sends the notification to the client  40 .
 
         [0085]    Upon determination that the data notification matches the client filter, the method may further include generating and submitting a database query to the database by a data provider. The database may provide to the data provider, in response to the query, a record set associated with an updated view including the generated data record. The data generator may submit to the at least one client data objects associated with the record set. The at least one client may display the updated view comprising information derived from the record set. 
         [0086]    For example, the following steps may take place: 
         [0000]    5. Page request  514  prompts the data provider  130  to issue a database query  516  to database  30 .
 
6. Database query  516  prompts data base  30  to send a record set  518  to data provider  130 .
 
7. Data objects  522  associated with the current page (already updated with the new record  510 ) is sent by the data provider to the client that uses the updated page to update its view.
 
         [0087]    In some embodiments of the present invention, the applying of the at least one client filter is performed by the data provider. In other embodiments, the applying of a client filter is performed by the at least one client, the applying further includes: submitting the data notification, by the data provider to the at least one client; applying to the data notification by the at least one client a respective filter associated with the at least one client. In such cases, the generating of a database query may include, upon determination that the data notification matches the client filter, generating and submitting a page request by the at least one client to the data provider; and generating by the data provider a database query associated with the page request. 
         [0088]    According to some embodiments of the present invention, the at least one client may be one of a plurality of clients, and/or the at least one data generator may be one of a plurality of data generators. 
         [0089]    Optionally, if page pre-loading is used (as depicted above), when the new record is associated with a page or pages pre-loaded at the client (even if that pre-loaded page is not currently viewed by the user), a similar process occurs such that the pre-loaded page (or pages) are re-loaded such that updated copies are present at the client. 
         [0090]    Optionally, a mechanism which enforces a minimum time between updates may be implemented in the client. This mechanism delays the request for new data if data is entered at a high rate to prevent overloading the system and/or to reduce view flickering. 
         [0091]    In some exemplary embodiments the client side is implemented by using a WPF (WebSphere Partition Facility, an IBM facility) DataGrid which supports data virtualization and, by binding the DataGrid to a special class which implements the IList interface and the actual paging. Data virtualization in the DatGrid is supported by specifying special virtualizing attributes. 
         [0092]    The class which supports the Paging is AsyncVirtualizingCollection&lt;T&gt;. This class uses generics to support paging of any data type. It supports both synchronous and asynchronous paging. Synchronous paging means that when there is a page request the client waits for the page to be loaded and only then retrieves the item requested. Asynchronous paging means that when the application requests an item and the page is not loaded—a dummy item is retrieved and later when the page is actually loaded the real item is updated in the client. 
         [0093]    It should be noted that a possible disadvantage of synchronous paging is that it may cause the client to freeze if the data request takes a lot of time. On the other hand, a possible disadvantage of asynchronous paging is that it may causes flickering in the client because of displaying the dummy item and then the real item. This problem is mitigated by choosing a reasonable page size. 
         [0094]    Both the synchronous and the Asynchronous options may be implemented in the client. It was found that in the current application, the synchronous option performs well and looks better. 
         [0095]    The AsyncVirtualizingCollection gets an IItemsProvider&lt;T&gt; in its constructor. The ItemsProvider is a class which knows how to retrieve elements of the specified types. The ItemsProvider may be implemented for each data type which we need paging for. The ItemsProvider operates by simply calling the Model and getting the items according to the range specified. 
         [0096]    The AsyncVirtualizingCollection supports the IVitrualCollectionInfo interface. This interface gives data about the paging state of the collection and it is used to debug the paging mechanism. 
         [0097]      FIG. 6  shows some details of page-loading and navigation process, e.g. a method of fetching, navigating within, and displaying a part of large medical diagnostics dataset according to embodiments of the present invention. 
         [0098]    The paging mechanism is combined of the two following steps: Creating a list of results, and Navigating over a list of results. 
         [0099]    A. Creating a List of Results 
         [0100]    This process describes the process of creating a list of matching results  610  according to the client specification: 
         [0000]    1. The method may include receiving from a client, by a data provider at a server, selected search criteria. For example, the client  40  invokes  611  a “create list” interface on the appropriate data provider with a filter and sorting criteria. The search criteria are sent  612  to the data provider  130 .
 
2. The method may include submitting the search criteria to a Data Access Layer (DAL). For example, the data provider  130  sends the search criteria to the DAL  420 .
 
3. The method may include converting by the DAL the search criteria to database type search criteria and sending the database type search criteria to a database. For example, the DAL  420  converts  613  the search criteria  612  to DB types  614  and calls the matching stored procedure  615 .
 
         [0101]    The method may include creating a list of matching results in a temporary table in the database and returning a list identifier of the list to the client. For example, the following steps may take place: 
         [0000]    4. List of matching results is created  621  in a temporary table in the database and the “list ID”  622  that identifies this list is returned to DAL  420 .
 
5. The DAL  420  returns a list ID  622  that identifies the generated database list of results to the data provider  130 .
 
6. The Data Provider  130  returns the list ID  622  to the client  40 .
 
         [0102]    After receiving the list of results the client can navigate over the generated list as follows: 
         [0103]    B. Navigating Over a List of Results 
         [0104]    This process  650  describes the process of getting the appropriate data from the database to display/facilitate at the client side: 
         [0000]    1. The method may include receiving, by a data provider at a server, a page request including a list identifier of the created list and a page range. For example, the client  40  invokes a fetch page data interface  651 , sending the appropriate data provider  130  a request (Get Page data, or page fetch criteria)  652  with a list ID and a page range (start and end index). 
         [0105]    The method may include converting by the DAL the page request to a database type page request and sending the database type page request to the database. For example, the following steps may take place: 
         [0000]    2. The data provider  130  sends the page fetch criteria  652  to the DAL  420 . Accordingly, the method may include submitting the page request to the DAL
 
3. The DAL  420  converts  653  the Get Page data  652  to DB types  654  and calls the matching stored procedure  655 .
 
         [0106]    The method may include creating a page size list of results matching the page request and returning the page size list of results to the client. For example, the following steps may take place: 
         [0000]    4. The database  30  returns a page size list of results  661  to the DAL  420 .
 
5. The DAL  420  returns a list  662  of the DB requested data objects defined in the fetch interface.
 
6. The Data Provider  130  returns the list of data objects  663  to the client  40 .
 
         [0107]    According to some embodiments of the present invention, the method may further include displaying the page size list of results. 
         [0108]    In some embodiments of a method according to embodiments of the present invention, the selected search criteria may include a selected filter and selected sort criteria. The creating of a list of results may be repeated, for example, by receiving from a client, by a data provider at a server, different selected search criteria, comprising the selected filter and different sort criteria. The navigating over a list of results may be repeated, for example, by receiving, by a data provider at a server, a page request including a list identifier of the created list and a different page range 
         [0109]    Accordingly, to navigate  670  within the same search criteria, the same process B  650  is repeated for any additional paging requests using the same list ID and a different page range. The client uses the “results fetch criteria” to navigate over the list of results, thus this object includes the list ID and the results range (min and max index) 
         [0110]    When the sort criteria are changed, process A  610  is repeated. 
         [0111]      FIGS. 7 ,  8  and  9  illustrate serial and parallel data insertion processes  200 ,  300  and  350  respectively, utilized by system  100  in  FIG. 1 . Data insertion and management as described herein enables real-time update of clients&#39; display as well as quick, effective retrieval of diagnostic data records by clients  40   a  and  40   b , such that they are able to create a substantially real-time view of diagnostic data received from medical lab devices  10 . Additionally, Data insertion and management as described herein enables real-time parsing of the data  60  arriving from medical lab devices  10  such that it is stored in database  30  in a format that enables fast and efficient retrieval by clients  40 . 
         [0112]    Clients  40  (for drawing clarity only two clients,  40   a  and  40   b  are seen in these figures, but number of clients is generally larger) are connected to server  20 . Each client  40  is a workstation such as a PC, a terminal or a viewing station comprising at least a user interface and a display such as a screen. The data seen on the screen is determined by the user by defining a view, which can be characterized by filters  50   a  and  50   b  respectively. For example, client  40   a  may be used by a device technician to view sample results diagnosed by a specific device, and client  40   b  may be used by a physician to view lab results for a specific patient. Client  40   a  will define a filter  50   a  relating to the medical device, and client  40   b  will define a filter  50   b  relating to the patient. For example, filters  50   a  and  50   b  may be or may be executed by optimized search tables that may be customized to match the client&#39;s search/view criteria, wherein the search tables may be updated in real time. 
         [0113]    The client sends a filter definition to the server, and a relevant data query is executed on the data storage unit ( 30  in  FIG. 1 ) to retrieve relevant data which exists in the database. A record list pertaining to the filter is created within the database, such that the record list is associated with a unique ID which will be referred to herein as a “List ID”. The record list may be a duplication of the data, or a hash table which points to relevant data in the database. The record list may contain complete records or records containing selective data, according to the filter definition. The list ID is sent to the client, and is used to retrieve the relevant data which will be presented in the client view. 
         [0114]    When a new data record  60  is to be inserted into the data storage unit  30 , the system first checks the new record against filters  50   a  and  50   b . Checking against multiple filters for multiple views can be done either serially ( FIG. 7 ) or in parallel ( FIG. 8 ). If matched against one or more of the filters, a relevant record list is updated, and a notification with the new data is sent to the client view, thus enabling data to be updated in data snapshot for the client view immediately as new data arrives. The transparent snapshot update eliminates the need to re-fresh the client view. This optional workflow solves the new data update issues. It moves the burden from the UI that needs to pull the data from the server, to the server that needs to push the data to the appropriate clients. 
         [0115]    In  FIG. 9 , the data is first parsed before it is inserted into database  30  and concurrently filtered, first by filter  50   a  and then by filter  50   b.    
         [0116]    It is to be understood that the above description is intended to be illustrative, and not restrictive. For example, the above-described embodiments (and/or aspects thereof) may be used in combination with each other. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the various embodiments of the invention without departing from their scope. While the dimensions and types of materials described herein are intended to define the parameters of the various embodiments of the invention, the embodiments are by no means limiting and are exemplary embodiments. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the various embodiments of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.” Moreover, in the following claims, the terms “first,” “second,” and “third,” etc. are used merely as labels, and are not intended to impose numerical requirements on their objects. 
         [0117]    In the claims, the word “comprise”, and variations thereof such as “comprises”, “comprising” and the like indicate that the components listed are included, but not generally to the exclusion of other components. 
         [0118]    Further, the limitations of the following claims are not written in means-plus-function format and are not intended to be interpreted based on 35 U.S.C. §112, sixth paragraph, unless and until such claim limitations expressly use the phrase “means for” followed by a statement of function void of further structure. 
         [0119]    This written description uses examples to disclose the various embodiments of the invention, including the best mode, and also to enable any person skilled in the art to practice the various embodiments of the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the various embodiments of the invention is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if the examples have structural elements that do not differ from the literal language of the claims, or if the examples include equivalent structural elements with insubstantial differences from the literal languages of the claims. 
         [0120]    Although the invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims. All publications, patents and patent applications mentioned in this specification are herein incorporated in their entirety by reference into the specification, to the same extent as if each individual publication, patent or patent application was specifically and individually indicated to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present invention. 
         [0121]    The scope of the present invention is defined by the appended claims and includes both combinations and sub combinations of the various features described hereinabove as well as variations and modifications thereof, which would occur to persons skilled in the art upon reading the foregoing description.