Method and system of unifying data
A system, method and database design is provided for unifying data from a plurality of databases, each having business-context related data and a data access mechanism. A database is created which contains a node for each dimension of an industry. For each data source accessible via the system, a set of data source specific dimensions is created and mapped to the corresponding industry business context dimension(s). A set of templates (e.g., UniViews) is created to query the data sources. Each UniView contains a specific question for a specific dimension designed for a specific data source. A central server coordinates the system and facilitates use of the system through an interface (e.g., the UniViewer). UniViewer allows a user to query the data sources by identifying an industry business context dimension, a dimension instance and at least one UniView. Multiple UniViews can be combined, cached and saved to facilitate complex queries.
Latest Datatrak International, Inc. Patents:
This application is a Continuation of U.S. patent application Ser. No. 12/275,639, filed Nov. 21, 2008, which is a Divisional of U.S. patent application Ser. No. 10/628,884, filed Jul. 28, 2003, now U.S. Pat. No. 7,464,087, which claims the benefit of U.S. Provisional Application No. 60/398,841, filed Jul. 26, 2002, all of the foregoing of which are hereby incorporated by reference in their entireties.
TECHNICAL FIELD OF THE INVENTIONThe present invention relates to the database management arts. It finds particular application as a method and system for accessing heterogeneous data in a plurality of databases.
BACKGROUND OF THE INVENTIONMost modern businesses employ a multitude of different software applications which collect and store huge amounts of data. These applications store data in a multitude of different ways (e.g., a flat file, a relational database or an object database) and in a format specific to the application in question (e.g., a binary file format). Access to this data is achieved through a variety of differing mechanisms (e.g., a direct database query, various reporting tools, or via an application program interface (an “API”)), each offering differing levels of flexibility, ease of use and coherence to the business concepts underlying the data. This data is generally heterogeneous but also generally related in terms of the underlying business concepts which drive and populate the databases.
It is generally desirable for such a business to pull together all of this data and access it centrally, with data from different applications merging together to afford views which span the multiple and disparate applications and which further offer overall pictures relating to the underlying business concepts. Such an aggregation is difficult, however, as each data source may have its data stored in a unique, individual way on some form of persistent hardware which is not necessarily compatible with the ways and hardware of other data sources. Furthermore, the actual format of the data is usually very complex and not directly business-relevant, which exacerbates the difficulty in aggregating, or unifying, the data in the multiple data sources.
To attempt to alleviate these difficulties, it is desirable for each data source to offer some form of data access mechanism (e.g., a set of pre-built queries or a set of API's) to facilitate access to itself. These mechanisms offer access to sets or subsets of information which are more abstract and meaningful in a business sense than the raw data stored in each data source. For example, a pre-built query may query a data base to retrieve all information relating to a particular individual and return only information relevant to such an individual. While such data access mechanisms are beneficial for obtaining business-relevant information from a single database (or at least a single type of database), such data access mechanisms are specific to the application which relates to the database. The design and technical specifications for any particular data access mechanism generally differs significantly from that of another particular data access mechanism. As such, a data access mechanism for a particular database is not likely useable for a different database, let alone for each of the many disparate databases which make up the information store of a modern business. Such access mechanisms are not readily adaptable to facilitate views which span multiple databases and which further facilitate overall pictures relating to underlying business concepts.
The need exists, therefore, to provide a method and system for unifying data from a plurality of heterogeneous databases, each having business-context related data and a data access mechanism.
SUMMARY OF THE INVENTIONIn accordance with one embodiment of the present invention, a system for unifying data relating to an industry having a plurality of industry business context dimensions is provided. The system includes a plurality of data sources, each having data which is capable of grouping into at least one data source specific dimension, and at least one having a physical or logical structure differing from at least one other. The system further includes a database having a first and a second plurality of nodes, each of the first plurality representing an industry business context dimension, and each of the second plurality representing a data source specific dimension. The system still further includes a plurality of data source query function calls, each call querying a single data source regarding a single data source specific dimension.
In accordance with another embodiment of the present invention, a system for managing data in a plurality of data sources is provided. The system includes a UniDimNet and a plurality of UniViews. The UniDimNet includes a plurality of UniDims representing industry business context dimensions and a plurality of DataSourceDims representing data source specific dimensions of each data source. Each UniDim is related to at least one other UniDim, and each DataSourceDim is related to at least one UniDim. UniViews may be combined into complex queries. A complex query may have a set of input parameters, which do not include identification of a particular data source.
In accordance with yet another embodiment of the present invention, a method for managing data in a plurality of data sources is provided. The method includes the steps of identifying a plurality of industry business context dimensions, identifying at least one data source specific dimension for each data source, providing a UniDimNet, providing a plurality of UniViews, formulating a complex query and providing the results of the query.
In accordance with still another embodiment of the present invention, a method for querying data in a plurality of data sources is provided. The method includes the steps of receiving a dimension to be queried, providing a plurality of data source query function calls to select from, creating a result set including columns defined by the selected function calls, receiving the identity of at least one dimension instance to query, and populating the columns with the results of the query.
An advantage of the present invention is that a plurality of data sources containing heterogeneous data may be unified and queried. A further advantage of the present invention is that a plurality of data sources having differing logical or physical structures can be queried by a single system using the data access mechanisms which are provided for each data source. Still a further advantage of the present invention is that complex queries for the data sources can be created, modified and carried out across the complete set of data sources. An additional advantage is that related data within multiple data sources can be queried without having to identify each particular data source in the query.
These and other aspects and advantages of the present invention will be apparent to those skilled in the art from the following description of the preferred embodiments in view of the accompanying drawings.
In the accompanying drawings which are incorporated in and constitute a part of the specification, embodiments of the invention are illustrated, which, together with a general description of the invention given above, and the detailed description given below, serve to example the principles of this invention.
The following includes definitions of exemplary terms used throughout the disclosure. For illustrative purposes only, and not to limit the disclosure of the invention set forth herein, an exemplary industry and an exemplary group of databases will be used herein to illustrate examples of certain embodiments of the present invention. The exemplary industry is the pharmaceuticals industry, and particularly the pharmaceuticals industry as such relates to clinical trials and clinical trial evaluations of certain drugs on certain patients.
In the pharmaceuticals industry, a sponsor is an entity (e.g., a drug or medical device company) which is desirous of having a drug (or other medical device) tested for, inter alia, FDA approval. Such tests are conducted as one or more clinical trials, or studies. Each study typically incorporates one or more sites (e.g., a particular hospital or doctors' practice group) at which one or more patients uses the drug on a trial basis. Records are kept of the patient and the patient's use of the drug, including any symptoms. Such records are oftentimes captured electronically via an electronic data capture (“EDC”) suite of software applications and stored in associated database(es). Although the present example is described in terms of clinical trials and the pharmaceuticals industry, those skilled in the art will readily appreciate that the invention will find application in any industry which uses multiple heterogeneous databases as set forth herein.
In the following definitions of exemplary terms, both singular and plural forms of all terms fall within each meaning Except where noted otherwise, capitalized and non-capitalized forms of all terms fall within each meaning:
As used herein, “data” is used generically and includes but is not limited to information in a form suitable for processing by a computer. Except where noted otherwise, “data” is information (including operational and legacy) which is contained or capable of being contained in a data source (as defined below). In the pharmaceuticals example, “data,” includes but is not limited to individual patient information such as height, weight, sex and age; study information such as particular EDC response(se); and study information such as the identity of the drug.
As used herein, “data source” is used generically and includes but is not limited to a database and/or software application which provides and/or stores data. In the pharmaceuticals example, a “data source” is a database which contains information relating to a sponsor, site, study, patient or any other entity related to the pharmaceuticals industry.
As used herein, “data source instance” is a particular installation of a data source. In the pharmaceuticals example, a “data source instance” is a real installation of a data source accessed by a system of the present invention. For example, a database containing information for a study which was not previously accessed by a system of the present invention would be considered a new “data source instance” to the system.
As used herein, “data access mechanism” is used interchangeably with “data retrieval mechanism” and is used generically, including but not limited to a software application or module of a software application which facilitates access to and retrieval of data from a data source. Typically a data access mechanism is specific to the database and/or software application (or database type or software application type) to which it is related, being customized to access same in response to a query. Exemplary data access mechanisms include, but are not limited to, pre-built database queries, pre-built database views and sets of application program interfaces (API's).
As used herein, a “dimension” is a specific logical concept within an industry. In the pharmaceuticals example, “dimensions” include but are not limited to “sponsor,” “study,” “site” and “patient,” each of which defines a specific logical concept within the pharmaceuticals industry. In this example, “dimensions” can be conceptualized as a set of interrelated entities (e.g., sponsor, study, site and patient) which correspond to specific interrelated industry concepts (e.g., the sponsors of clinical trials, studies for particular drug(s), site(s) at which the drug is tested, and patient(s) which participate in the study).
As used herein, “industry business context” is a set of dimensions which define the data pertinent to an industry. In the pharmaceuticals example, the “industry business context” is the set of dimensions which define all the data which is pertinent to the pharmaceuticals industry and which is to be accessible by a system or method of the present invention. Generally speaking, the complete set of data which is defined by the pharmaceuticals industry and which is accessible by a method or system of the present invention is grouped or categorized into logical concepts (dimensions), the complete set of which defines the industry business context of the pharmaceuticals industry.
As used herein, “industry business context dimension” is used interchangeably with “dimension.”
As used herein, “dimension instance” is a particular embodiment (or record) of a dimension. In the pharmaceuticals industry example, wherein “patient” is a dimension, a particular person who is a patient (e.g., Joe Smith) is a “dimension instance” of that dimension.
As used herein, “data source specific dimension” is a specific logical concept within a data source. In an embodiment, a “data source specific dimension” is a set or subset of data contained within a data source which is more abstract and meaningful in a business sense than the raw data stored in the data source. In the pharmaceuticals industry example, a particular database contains data from a particular study, including data relating to the sites of the study, the patients in the study and EDC responses from the study. In this example, “data source specific dimensions” can be conceptualized as a set of interrelated entities (e.g., “study,” “site,” “patient” and “EDC responses”) which correspond to the data in the data source and are defined for that particular data source. In an embodiment, a “data source specific dimension” is a set of conceptually-related data which can be retrieved from a data source or a plurality of data sources.
As used herein, “data source business context” is a set of data source specific dimensions which define the data in a particular data source. Generally speaking, the complete set of data which is contained in a data source is grouped or categorized into logical concepts (data source specific dimensions), the complete set of which defines the “data source business context” of the data source.
As used herein, “logic” is used generically and includes but is not limited to hardware, software and/or combinations of both to perform a function.
As used herein, “software” is used generically and includes but is not limited to one or more computer executable instructions, routines, algorithms, modules or programs including separate applications or from dynamically linked libraries for performing functions as described herein. Software may also be implemented in various forms such as a servlet, applet, stand-alone, plug-in or other type of application. Software can be maintained on various computer readable mediums as known in the art.
As used herein, “network” is used generically and includes but is not limited to the Internet, intranets, Wide Area Networks, Local Area Networks and transducer links such as those using Modulator-Demodulators (modems).
In an embodiment, the present invention is directed to a system, method and database design for unifying data from a plurality of heterogeneous databases, each having business-context related data and a data access mechanism. A database is created (the UniDimNet) which contains a node for each dimension of an industry. For each data source which is accessible via the system, a set of data source specific dimensions is created and mapped to the corresponding industry business context dimension(s). A set of templates (UniViews) is created to query the data sources. Each UniView contains a specific question for a specific dimension designed for a specific data source. UniViews query the database they are associated with by using the data access mechanism of the associated database. A central server (the UniServer) coordinates the system and facilitates use of the system through an interface (the UniViewer). The UniViewer allows a user to query the data sources by identifying an industry business context dimension, a dimension instance and at least one UniView. Multiple UniViews can be combined, cached and saved to facilitate complex queries. Although the present invention is described with reference to an exemplary set of databases relating to clinical trials for the pharmaceutical industry, those skilled in the art will readily appreciate that the invention will find application in any type of database management setting involving the management of a plurality of heterogeneous databases, for example, in the management of heterogeneous databases involved with payroll or corporate human resources applications.
With reference to
With reference to
With reference to
Each industry business context dimension which is used in system 100 is represented by a UniDim, the complete set of which for system 100 is represented at 310. A UniDim is an entry and description in the UniDimNet 210 database which represents and defines a unique industry business context dimension within system 100.
The complete set of UniDims 310 can be represented in UniDimNet 210 by any suitable mechanism. In an embodiment, each UniDim 380 is a node in a network which defines UniDimNet 210 and which acts as a single point of reference for all information relating to the specific industry business context dimension represented by the UniDim. The complete set of dimensions for an industry of system 100 is defined by any suitable mechanism. In an embodiment, the complete set of dimensions is defined by analyzing the industry and the industry's use of data sources to determine which business concepts can be naturally grouped together or most advantageously grouped together by relevance. In another embodiment, the complete set of dimensions is defined by analyzing the data of a given industry to determine which concepts in the data are most frequently referenced, cited and/or queried. In still another embodiment, the complete set of dimensions is defined by reviewing all data sources accessible to a system 100 and determining logical groupings of the data based upon the business context of the industry, irrespective of the physical and/or logic groupings from the native data sources.
With reference to
Each UniDim is related to at least one other UniDim. As illustrated in
With reference again to the UniDimNet 210 in
With reference to
Exemplary data sources and corresponding data source specific dimensions are illustrated in
With reference to
Further in this exemplary embodiment, data source 174 comprises a data source which is organized to facilitate generic SQL data queries. In such a SQL database (generally speaking, a relational database), the original data of the database is stored in tables which directly represent a particular business-context grouping. In this regard, the data source specific dimensions for such a data base may be derived directly from the tables in which the data is stored. For example, the database may contain a table for “patient” which contains patient information. Such a table may be consistent with a data source specific dimension for “patient.” Alternatively, data source specific dimensions may be defined which span multiple tables, as long as the data selected from each table is related in a business context. Once the complete set of data source specific dimensions is defined for data source 174 and the specific data source specific dimensions thereof created, the complete set 330 is stored in UniDimNet 210 as representative DataSourceDims. With reference to
Still further to this exemplary embodiment, data source 176 comprises a data source which is fully generic and not designed to include any specific tables for any specific concepts, such as exemplary DATATRAK EDC Database (DATATRAK EDC) provided by DATATRAK International, Inc. Such a database is accessed by an API (such as DATATRAK QUESTIONVIEW®) and does not contain any internal structure which would aid in creating data source specific dimensions. In such a case, data source specific dimensions are created by any suitable mechanism. In an embodiment, data source specific dimensions for such a database are created by accessing metadata regarding the data stored in the database and by analyzing the data contained in the database in light of the industry business context. Once the complete set of data source specific dimensions is defined for data source 176 and the specific data source specific dimensions thereof created, the complete set 340 is stored in UniDimNet 210 as representative DataSourceDims. With reference to
With reference again to
With reference to
In an embodiment, each DataSourceDim is a node in the network which defines UniDimNet 210, similar to each node defined by each UniDim. By mapping each DataSourceDim node onto the two dimensional UniDimNet network defined by the UniDims and their relationships with each other, the UniDimNet network is expanded into three dimensions. In this context the UniDimNet 210 is a three-dimensional network of nodes stored as related data in the UniBase 110.
In another embodiment, UniDimNet 210 is a series of interrelated tables, with each node in the UniDimNet 210 being represented by a table. As such, each UniDim and each DataSourceDim in the UniDimNet 210 are represented by a table. Each dimension instance in a data source accessible by system 100 is represented by a row in at least one Unidim of the UniDimNet 210 and at least one DataSourceDim of the UniDimNet 210. With reference to
Each UniDim table contains an entry (e.g., a row in the table) for each dimension instance of the dimension represented by the UniDim which is contained in a data source which is accessible by system 100. Each entry (e.g., row 852) in the UniDim table contains a globally unique identification 853 which uniquely identifies the dimension instance represented by the entry. Each entry may also contain a creation timestamp 854 and an update timestamp 855 for each entry, representing the time the dimension instance was entered into system 100 and the last time the dimension instance was updated, respectively. Each entry may further contain additional information (i.e., additional record fields) regarding each dimension instance in the table. Any suitable information may be added. For example, a field 856 identifying the DataSourceDim related to the dimension instance may be added. It will be appreciated that the amount of information contained in each UniDim entry depends upon the response time desired for system 100 and the data storage space available for the UniBase. In general, the more information that is contained in each UniDim entry, the fewer the data source look-ups need to be performed by system 100 (because much of the information regarding the dimension instance will already be stored in the UniDim entry), thus generally speeding up performance of the system. However, such additional information uses additional storage space, which may add to the cost of the system and, depending upon the database management software used to maintain the UniDimNet, may slow the system down if the size of the UniDim tables becomes too large.
Similarly to the UniDim tables, each DataSourceDim table contains an entry for each dimension instance of the dimension represented by the DataSourceDim which is contained in the data source which is related to the DataSourceDim. Each entry (e.g., row 862) in the DataSourceDim table contains a reference 864 to the data source in which the dimension instance is contained, key information 863 (such as a data source unique identifier) required to retrieve the dimension instance (and the data associated therewith) from the data source, and the unique identification 853 for the dimension instance as contained in the UniDim entry relating to the dimension instance. Each entry may also contain a creation timestamp 854 and an update timestamp 855 similarly to the related UniDim entry. Also as with UniDim entries, DataSourceDim table entries may contain additional information relating to the particular dimension instance, and may further contain additional information regarding the data source and the UniDim to which the DataSourceDim is related. It will be appreciated that the same factors relating to speed and size which dictate the amount of information contained within a UniDim entry are also applicable to determining the amount of information contained with a DataSourceDim entry.
With reference again to dimension instance 800, an entry relating to dimension instance 800 is contained in DataSourceDim table 860 (entry 862) and in UniDim table 850 (entry 852). These entries are related to each other by any suitable mechanism. In one embodiment, the relation is contained in a DataSourceDim identifying field 856 of a UniDim record. In another embodiment, the relation is further defined by each entry containing the same UniDim unique identification 853.
A UniDim table may be related to more than one DataSourceDim table. With further reference to
With still further reference to
In an embodiment, each dimension instance contained within all data sources accessible to system 100 has a corresponding entry in at least one UniDim table and at least one DataSourceDim table. UniDimNet 210 thus facilitates querying of dimensions and dimension instances spanning all data sources irrespective of the physical and logical structure of each data source. Such queries (relating to dimensions or dimension instances, not to particular data sources or specific records in each data source) may be performed by templates, or UniViews.
A UniView is logic (e.g., a software component, routine or object) which performs an actual data request to a data source within system 100. A UniView is a specific question for a specific dimension designed for a specific data source. With reference to
result=exact_request_for_information (instance_parameter)
wherein “result” is the requested information which is returned from the data source in response to the query, “exact_request_for_information” is the specific request (query) to the data source for specific information, and “instance_parameter” is the specific dimension instance the request regards. For example, a UniView querying for the height of patient “Joe Smith” would define “result” as being a field for containing the value of Joe Smith's height and could take the form of:
result=what is the height of the patient (patient=“Joe Smith”)
Upon a successful query to the appropriate data source, the exemplary UniView would return the value of Joe Smith's height as recorded in the data source.
In an embodiment, the “result” and the “specific request” of a UniView is created and stored while the “instance parameter” is left as a variable, thus allowing the UniView to be used and reused each time the same question for the same dimension for the same data source is made (a value for the “instance parameter” may be passed to the UniView in order to complete the UniView). In this manner, a single UniView may be selected and passed multiple instance parameters to effectuate multiple queries to the same data source for multiple dimension instances.
Each UniView is created for a specific data source. In an embodiment, upon incorporating a data source into system 100, a plurality of UniViews are created in system 100 for querying the new data source. Each UniView contains the necessary information and instructions to facilitate access to a data source via the data access mechanism for that particular data source. For example, exemplary data sources DATATRAK EDC and DATATRAK CA are accessible via the DATATRAK QUESTIONVIEW API. A UniView for either of these data sources will be created with the ability to access and use the DATATRAK QUESTIONVIEW API for querying each database. The UniView will contain the required parameters, instructions and information necessary to instruct the API to query the databases and return certain results (in the format of “results”). In this sense the UniDimNet 210 is removed from particular details of the structure and physical requirements of each data source. The UniViews receive a dimension-specific query and facilitate access to a data source to respond to the query. While the above example has illustrated use of an API as a data access mechanism to a data source, it will be appreciated that any data access mechanism which is capable of querying a data source may be used.
It will be appreciated that the number and extent of UniViews which are created for any specific data source depends upon the number and type of dimension instances within the data source and a user's desire to query the data source. Any suitable number of UniViews for a particular data source may be created and used in system 100. It will be appreciated that to the extent a data source has voluminous data representing many instances, numerous UniViews will be created. UniViews may be stored in any appropriate element (or database) of system 100 such as, e.g., within UniBase 110. In an embodiment, UniViews (or “definitions” of UniViews) are stored in (with reference to
System 100 optionally includes additional functions to assist in the management, use and creation of UniViews, including but not limited to using a UniViewInterface, using CompoundUniViews, UniView caching and UniView creation via an automated process such as, e.g., a UniBot. UniViewInterfaces are illustrated with reference to
A UniViewInterface is a mechanism for combining multiple UniViews to facilitate queries which would require use of multiple UniViews. A UniViewInterface takes generally the same form as a UniView (i.e., a function call) wherein a plurality of UniViews are called by the single UniViewInterface. However, generally the “result” of a UniViewInterface is a result set, the contents of which is a collection (or array or table) of retrieved data which corresponds to a plurality of dimension instances retrieved by the plurality of UniViews which are called by the UniViewInterface. Furthermore, the “exact_request_for_information” in a UniViewInterface is not data source specific, as it is in a UniView. Instead, the “exact_request_for_information” relates only to the information requested (e.g., from a dimension), irrespective of the data source. Still furthermore, the “instance_parameter” is an array of dimension instances, rather than a single dimension instance. The array of dimension instances is defined by the set of dimension instances which are desired to be queried.
Use of a UniViewInterface is illustrated with reference to
UniViewInterface 1010 is created with “result” as a collection for containing patient characteristic information for a plurality of patients. The “result” of a UniViewInterface 1010 query will be a collection of patient characteristics data, with each patient being an entry in the “result.” The “exact_request_for_information” is a query of the dimension “patient” 440 (with reference to
With reference to
UniView caching is a mechanism for speeding up system 100 response time by caching the results of executed UniViews. In subsequent executions of such UniViews, the cached results are analyzed to determine if an update to the corresponding data source has occurred since the time of the caching. Generally speaking, if no update has occurred, the cached results can be returned for the execution of the UniView, thus saving the time and system resources required for accessing the data source directly in response to the UniView. If an update has occurred, the cache is ignored, the UniView queries the data source, and the response to the query is cached over the old cached data.
To facilitate such caching, in an embodiment, system 100 creates a cache results table for each UniView of system 100. The cached results tables may be stored in any suitable location within system 100. In an embodiment (with reference to
UniView creation can be afforded by any suitable mechanism, including manually (i.e., a single UniView is coded by a user). In an embodiment, system 100 provides tools to assist in the creation of UniViews. With reference to
In an embodiment, data source class logic 1230 assists in creation of UniViews. Upon becoming accessible to system 100, a data source class is defined which sets forth the necessary information, steps, processes and access mechanisms for querying data source(s) of that class. The data source class contains information required by a UniView to create the “exact_request_for_information” element of the UniView (i.e., the specific information required by the UniView to facilitate a query to the data source via an appropriate data access mechanism). This information is formatted to facilitate use in a UniView directed to querying a data source of this class. In this manner, when it is desirous to create a UniView which queries a data source of this class, the author of the UniView can “port” or “copy” the formatted data class information into the UniView, thus saving time in re-creating the same code for each such UniView. To facilitate the creation of the data source class, (with reference to
In an embodiment, UniBot 1240 facilitates generation of a set of “standard” UniViews for a data source. UniBot 1240 includes any suitable steps, methods, processes and/or code to facilitate such generation. UniBot 1240 may optionally be automated. Based upon user input regarding what a “standard” set of UniViews includes (e.g., how may UniViews for a data source of such a class; which dimensions are to be queried; what data is routinely queried from data sources of such a class; etc.), UniBot 1240 accesses the relevant data source(s) and determines the information necessary to create a standard set of UniViews. In an embodiment, UniBot 1240 access the relevant data sources and determines the information necessary to create the DataSourceDims for the data source for incorporation into a UniDimNet. In a embodiment, UniBot 1240 retrieves such information and creates a set of UniViews according to user-defined specifications.
With reference to
In an embodiment, manage UniDimNet logic 1300 facilitates management of the UniDimNet. Manage UniDimNet logic 1300 includes any steps, processes, methods and/or software code to facilitate adding, updating and deleting UniDims and DataSourceDims from the UniDimNet, distributing UniDimNet structure to the UniBase, and other actions relating to the UniDimNet not otherwise facilitated by other elements of system 100. In an embodiment, manage data source logic 1305 facilitates management of the data sources accessible to system 100. Manage data source logic 1305 includes any steps, processes, methods and/or software code to facilitate management of the data sources and the relationships (including interactions) with the dimensions. In another embodiment, route connections logic 1310 manages connections between elements of system 100. Route connections logic 1310 includes any steps, processes, methods and/or software code to facilitate the routing of connections (including communications) between system 100 elements, including but not limited to the UniBase, the data sources and any user(s).
In a further embodiment, UniServer 120 optionally includes UniView query logic 1315 for coordinating system 100 actions and interaction during execution of a UniView. UniView query logic 1315 includes any steps, processes, methods and/or software code to facilitate coordination of system 100 resources during execution of a UniView. In an embodiment, UniView query logic 1315 is configured to facilitate one or more than one of the following UniView execution configurations: (1) ShowSourceBasedDataOnly. Under this configuration (exemplified in
In an embodiment, compound UniView logic 1320 facilitates processing of a CompoundUniView. Compound UniView logic 1320 includes any steps, processes, methods and/or software code to facilitate processing (execution) of a CompoundUniView. Particularly, compound UniView logic 1320 manages execution of a CompoundUniView and further acts as a virtual data source therefore. For each UniView which is called by a CompoundUniView, compound UniView logic 1320 performs a table cache check and (depending upon the nature of the cached data, if any) a data source query similarly to steps illustrated above for ShowSourceBasedDataOnly. While compound UniView logic 1320 has been described herein with relation to a ShowSourceBasedDataOnly configuration, it will be appreciated that compound UniView logic 1320 may be configured to follow any suitable configuration.
In an embodiment, snapshot and versioning logic 1325 facilitates retaining “snapshots” of UniView query results and further facilitates labeling such snapshots with version identifiers. Snapshot and versioning logic 1325 includes any steps, processes, methods and/or software code to facilitate creating snapshots and versions of UniView query results. When a UniView query result is returned, it is optionally stored in a table corresponding to the UniView in the UniBase. Under one optional configuration of the UniServer, this cached data is overwritten the next time the same UniView returns an updated result from a query. Snapshot and versioning logic 1325 optionally allows any cached data to remain in the table. In an embodiment, a particular cached result is stored as an entry (e.g., a row) in the cache table. Snapshot and versioning logic 1325 facilitates subsequent returned results being stored as additional row(s) in the cache table. Furthermore, such cached results can be labeled with versioning identifiers to facilitate version comparisons. In this regard, multiple “snapshots” (i.e., former returned results from earlier executions of the UniView) are retained in the cache table, and may be compared to each other (e.g., for version comparision).
In an embodiment, logic for facilitating external data access 1330 facilitates access to system 100 by an external application, such as an OLE database data provider or an ODBC source. Logic for facilitating external data access 1330 includes any steps, processes, methods and/or software code to facilitate such access by an external application. In this regard system 100 can be used to function as a direct data supplier for queries from third-party systems. In an embodiment, such systems need not be configured in any specific way (other than enabling an ODBC connection, for example) to be able to access the data sources of system 100 and the querying power of system 100.
The dimension instances in the data sources are rarely static. To incorporate changes made to a dimension instance in a data source, system 100 optionally includes (with reference to
Change workflow logic 1510 optionally facilitates triggering of notifier 140 and referral to rule books 1500. Change workflow logic 1510 includes any steps, processes, methods and/or software code to facilitate triggering of notifier 140 and referral to rule books 1500. Any change to a dimension instance can be considered a “triggering event” which triggers notifier 140, and, specifically, change workflow logic 1510. It will be appreciated that a triggering event may include but not be limited to creation of a dimension instance, deletion of a dimension instance or any change to a property of a dimension instance, including the value of any data therein. Upon occurrence of a triggering event, change workflow logic 1510 is triggered. Change workflow logic 1510 accesses rule books 1500 to determine what workflow steps are to be implemented in order to assimilate the modified dimension instance into system 100. Change workflow logic 1510 performs and/or facilitates all steps set forth in the rule book to incorporate the modified instance into system 100. While change workflow logic 1510 has been illustrated as an element of system 100 outside of the UniServer 120, it will be appreciated that change workflow logic 1510 (and all of notifier 140) can optionally be included in UniServer 120.
User access to and use of system 100 can be achieved by any suitable user interface. In an embodiment, with reference to
With reference to
With reference to
With reference to
Once the query has been defined by the user by selecting UniView(s), with reference to
While the above example has been illustrated with UniViews which represent properties of the dimension selected (e.g., each of the three selected UniViews returned properties of the dimension selected—“site”), it will be appreciated that selectable UniViews (1610) may have multiple ways of being associated with the selected dimension. For example, with reference to
With reference to
While UniViewer 150 has been described with reference to the GUI created by system 100, it will be appreciated that any appropriate steps, methods or logic may be implemented by system 100 to facilitate the GUI of UniViewer 150 and the results of any user query made therewith. In an embodiment, while system 100 is running, the UniDimNet is loaded into memory (e.g., RAM). When a user initially selects a reference (start) dimension for a new query, a “results set” object is created and attached to the selected dimension in the UniDimNet. The “results set” object may be any suitable object, including a collection, table or an array, and may be “zeroed out” (i.e., empty) upon creation. Upon dragging a UniView onto the results area, the results set object may be modified accordingly. For example, depending upon the dimension context of the UniView, the result set object may be repositioned within the UniDimNet. In this example, if the UniView returns “visit information” and is dragged onto a “patient” dimension (as selected by the user), the result set object will be moved to a “lower” level (assuming the hierarchy of the UniDimNet defines the UniDim “patient” as being higher than “visits,” which will occur if “patient” is defined as having one to many “visits”). As the UniView is dragged onto the results area, columns (e.g., 1710, 1720 and 1730 with reference to
It may be desirable during use of system 100 to add an additional data source or data sources to system 100. In this event, system 100 is modified in any suitable manner to accommodate the addition of such new data source(s). In an embodiment, with reference to
After creation of the new UniView class (or if such class was not created), at 2045 the UniServer is restarted. At 2050 UniViews for the new data source(s) are created by any suitable means, including manually or with assistance from the UniBuilder (particularly the UniBot if new UniView classes have been created). At 2055 the new UniViews are included in the UniView Tree. At 2060 the new data source instances are registered with system 100, including registration and storage of all required information regarding each instance in the UniDimNet. The Notifier will react to the new instances (not shown) to further assimilate the new instances into system 100.
It will be appreciated that security regarding access to and use of a system 100 can be effectuated by any suitable mechanism. In an embodiment, the complete set of UniViews available to a user is defined by the access rights of the user. Each user may have a strictly defined set of UniViews which that user can view and/or access. In this sense, access to data sources (and certain data therein) can be controlled (e.g., if a UniView to a particular piece of data does not exist, the data will not be returned to the user; furthermore, if no UniViews to a particular data source are accessible to a user, the user will not be able to access the data source). Furthermore, access to dimension instances may also be restricted via user-specific access rights (i.e., a user can be prohibited from receiving data regarding a particular instance if the user is not given access rights to that instance).
With reference to
It will be appreciated that the method described above may include any additional appropriate steps and that each step described above may comprise additional substeps. For example, with reference to
Those skilled in the art will appreciate that the invention may be realized without utilizing all the above-described steps of the exemplary embodiment, nor must the steps be carried out in the described order.
The invention has been described with reference to the preferred embodiments. Modifications and alterations will occur to others upon a reading and understanding of this specification. It is intended to include all such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.
Claims
1. A system for unifying data, comprising:
- one or more computers;
- a plurality of separate data sources, each data source having a respective data access mechanism for facilitating querying thereof, each data source having stored thereon data for a particular clinical trials patient, and the plurality of data sources comprising (a) an electronic data capture (“EDC”) data source having EDC study data stored thereon, including EDC study data for the particular clinical trials patient, and (b) a patient diary data source having patient diary data stored thereon, including patient diary data for the particular clinical trials patient;
- a plurality of data source query function calls, each query function call querying a single data source, and each query function call using the data access mechanism of the single data source to facilitate access to the single data source;
- a first complex query calling a plurality of the data source query function calls, including, in response to a user query about the particular clinical trials patient, calling a query of the EDC data source for EDC study data for the particular clinical trials patient and a query of the patient diary data source for patient diary data for the particular clinical trials patient; wherein the first complex query does not identify any data source to query;
- wherein, in response to the first complex query, EDC study data for the particular clinical trials patient is retrieved from the EDC data source and patient diary data for the particular clinical trials patient is retrieved from the patient diary data source to populate at least one result set;
- a second complex query, in response to a user passing dimension instance parameters in the form of a list of a plurality of clinical trials patients, calls a first query of a first data source for patient characteristics data for a first clinical trials patient, calls a second query of a second data source for patient characteristics data for a second clinical trials patient, and calls a third query of a third data source for patient characteristics data for a third clinical trials patient;
- wherein the second complex query does not identify any data source to query; and wherein, in response to the second complex query, patient characteristics data for the first clinical trials patient is retrieved from the first data source, patient characteristics data for the second clinical trials patient is retrieved from the second data source, and patient characteristics data for the third clinical trials patient is retrieved from the third data source to populate at least one result set.
2. The system of claim 1, wherein the first complex query comprises a clinical trials patient quality of life complex query.
3. The system of claim 1,
- wherein the plurality of data sources further comprises another data source having a data access mechanism for facilitating querying thereof and having stored thereon data for the particular clinical trials patient; and
- wherein the first complex query calls, in response to the user query about the particular clinical trials patient, a data query of the other data source for other data about the particular clinical trials patient; and
- wherein, in response to the first complex query, EDC study data for the particular clinical trials patient is retrieved from the EDC data source, patient diary data for the particular clinical trials patient is retrieved from the patient diary data source, and other data for the particular clinical trials patient is retrieved from the other data source to populate at least one result set.
4. The system of claim 1, wherein:
- the first data source is a study database;
- the second data source is a first EDC study database; and
- the third data source is a second EDC study database.
5. The system of claim 1, wherein the first complex query calls, in response to the user query about the particular clinical trials patient:
- (a) a query of the patient diary data source for patient diary data about the particular clinical trials patient;
- (b) a query of the patient diary data source for patient pain level data about the particular clinical trials patient; and
- (c) a query of the EDC data source for EDC medication data about the particular clinical trials patient; and
- wherein, in response to the first complex query, patient pain level data for the particular clinical trials patient is retrieved from the patient diary data source, EDC medication data for the particular clinical trials patient is retrieved from the EDC data source, and other patient diary data for the particular clinical trials patient is retrieved from the patient diary data source to populate at least one result set.
6. The system of claim 5,
- wherein the plurality of data sources further comprises another data source having a data access mechanism for facilitating querying thereof and having stored thereon data for a particular clinical trials patient; and
- wherein the first complex query further calls, in response to the user query about the particular clinical trials patient, a query of the other data source for other patient data about the particular clinical trials patient; and
- wherein, in response to the first complex query, patient pain level data for the particular clinical trials patient is retrieved from the patient diary data source, EDC medication data for the particular clinical trials patient is retrieved from the EDC data source, other patient diary data for the particular clinical trials patient is retrieved from the patient diary data source, and other data for the particular clinical trials patient is retrieved from the other data source to populate at least one result set.
7. The system of claim 1, further comprising:
- a first plurality of nodes storing information defining a corresponding plurality of business context dimensions for the industry, including clinical study, clinical trial site, and clinical trial patient dimensions, each node of the first plurality of nodes representing an industry business context dimension, with one node of the first plurality of nodes for each dimension, and wherein the first plurality of nodes includes a clinical study node, a clinical trial site node, and a clinical trial patient node; and
- wherein the system includes mapping data for mapping the first plurality of nodes to the plurality of data sources on a dimension by dimension basis; and
- wherein, in response to the first complex query, the system uses the first plurality of nodes and the mapping data to retrieve EDC study data for the particular clinical trials patient from the EDC data source and retrieve patient diary data for the particular clinical trials patient from the patient diary data source to populate at least one result set.
8. The system of claim 7, wherein the industry business context dimensions include clinical trial sponsor, clinical study, clinical trial site, clinical trial patient, and clinical trial visit dimensions and further wherein the first plurality of nodes includes a clinical trial sponsor node, a clinical study node, a clinical trial site node, a clinical trial patient node, and a clinical trial visit node.
9. The system of claim 7,
- wherein each dimension has a plurality of dimension instances, each dimension instance being a particular embodiment of a dimension; and
- wherein information defining each business context dimension instance within the plurality of data sources is stored in the corresponding node of the first plurality of nodes defining the corresponding business context dimension, the first plurality of nodes including a first business context node storing information defining a first business context dimension, a first dimension instance of the first business context dimension, and a second dimension instance of the first business context dimension instance.
10. The system of claim 7, wherein the mapping data comprises a second plurality of nodes for mapping the first plurality of nodes to the plurality of data sources on a dimension by dimension basis, each node of the second plurality of nodes representing a data source specific dimension of at least one of the data sources,
- a second plurality of nodes storing information relating data stored within the plurality of data sources to at least a portion of the plurality of business context dimensions for at least one of
- (a) each data source type represented within the plurality of data sources, and
- (b) each data source instance represented within the plurality of data sources, with the second plurality of nodes mapped to the first plurality of nodes based on corresponding business context dimensions, each node of the second plurality of nodes storing information defining at least one business context dimension instance from the plurality of data sources, each business context dimension instance relating to an instance of stored data within the corresponding data source instance associated with the corresponding business context dimension; and
- wherein, in response to the first complex query, the system uses the first plurality of nodes and the second plurality of nodes to retrieve EDC study data for the particular clinical trials patient from the EDC data source and retrieve patient diary data for the particular clinical trials patient from the patient diary data source to populate at least one result set.
11. A system for unifying data, comprising:
- one or more computers;
- a plurality of separate data sources, each data source having a respective data access mechanism for facilitating querying thereof, each data source having stored thereon data for a particular clinical trials patient, and the plurality of data sources comprising (a) an electronic data capture (“EDC”) data source having EDC study data and EDC medication data stored thereon, including EDC study data and EDC medication data for the particular clinical trials patient, (b) a patient diary data source having patient diary data and patient pain level data stored thereon, including patient diary data and patient pain level data for the particular clinical trials patient, and (c) another data source having other data stored thereon, including other data for the particular clinical trials patient;
- a plurality of data source query function calls, each query function call querying a single data source, and each query function call using the data access mechanism of the single data source to facilitate access to the single data source;
- a first complex query calling a plurality of the data source query function calls, including, in response to a user query about the particular clinical trials patient, calling:
- (a) a query of the patient diary data source for patient diary data about the particular clinical trials patient;
- (b) a query of the patient diary data source for patient pain level data about the particular clinical trials patient;
- (c) a query of the EDC data source for EDC medication data about the particular clinical trials patient;
- (d) a query of the EDC data source for EDC study data about the particular clinical trials patient; and
- (e) a query of the other data source for other patient data about the particular clinical trials patient; wherein, in response to the complex query, patient pain level data for the particular clinical trials patient is retrieved from the patient diary data source, EDC medication data for the particular clinical trials patient is retrieved from the EDC data source, EDC study data for the particular clinical trials patient is retrieved from the EDC data source, other patient diary data for the particular clinical trials patient is retrieved from the patient diary data source, and other data for the particular clinical trials patient is retrieved from the other data source to populate at least one result set;
- wherein the first complex query does not identify any data source to query; a second complex query, in response to a user passing dimension instance parameters in the form of a list of a plurality of clinical trials patients, calls a first query of a first data source for patient characteristics data for a first clinical trials patient, calls a second query of a second data source for patient characteristics data for a second clinical trials patient, and calls a third query of a third data source for patient characteristics data for a third clinical trials patient;
- wherein the second complex query does not identify any data source to query; and
- wherein, in response to the second complex query, patient characteristics data for the first clinical trials patient is retrieved from the first data source, patient characteristics data for the second clinical trials patient is retrieved from the second data source, and patient characteristics data for the third clinical trials patient is retrieved from the third data source to populate at least one result set;
- a first plurality of nodes storing information defining a corresponding plurality of business context dimensions for the industry, including clinical trial sponsor, clinical study, clinical trial site, clinical trial patient, and clinical trial visit dimensions, each node of the first plurality of nodes representing an industry business context dimension, with one node of the first plurality of nodes for each dimension, and wherein the first plurality of nodes includes a clinical trial sponsor node, a clinical study node, a clinical trial site node, a clinical trial patient node, and a clinical trial visit node;
- wherein each dimension has a plurality of dimension instances, each dimension instance being a particular embodiment of a dimension;
- wherein information defining each business context dimension instance within the plurality of data sources is stored in the corresponding node of the first plurality of nodes defining the corresponding business context dimension, the first plurality of nodes including a first business context node storing information defining a first business context dimension, a first dimension instance of the first business context dimension, and a second dimension instance of the first business context dimension instance;
- wherein the system includes mapping data which comprises a second plurality of nodes, for mapping the first plurality of nodes to the plurality of data sources on a dimension by dimension basis, each node of the second plurality of nodes representing a data source specific dimension of at least one of the data sources;
- wherein the second plurality of nodes store information relating data stored within the plurality of data sources to at least a portion of the plurality of business context dimensions for at least one of (a) each data source type represented within the plurality of data sources, and
- (b) each data source instance represented within the plurality of data sources, with the second plurality of nodes mapped to the first plurality of nodes based on corresponding business context dimensions, each node of the second plurality of nodes storing information defining at least one business context dimension instance from the plurality of data sources, each business context dimension instance relating to an instance of stored data within the corresponding data source instance associated with the corresponding business context dimension; and
- wherein, in response to the at least one first complex query, the system uses the first plurality of nodes and the second plurality of nodes to retrieve patient pain level data for the particular clinical trials patient from the patient diary data source, EDC medication data for the particular clinical trials patient from the EDC data source, EDC study data for the particular clinical trials patient from the EDC data source, other patient diary data for the particular clinical trials patient from the patient diary data source, and other data for the particular clinical trials patient from the other data source to populate at least one result set.
12. The system of claim 11, wherein:
- the first data source is a study database;
- the second data source is a first EDC study database; and
- the third data source is a second EDC study database.
13. A system for unifying data relating to an industry having a plurality of industry business context dimensions which define logical groupings of data related to the industry, the system comprising:
- one or more computer systems;
- data storage space associated with the one or more computer systems for storing data suitable for processing by at least one of the one or more computers;
- a plurality of data sources, at least two data sources having a physical or logical structure differing from at least one other data source, each data source, having data which is capable of a logical contextual grouping into at least one data source specific dimension which contains data related to at least one industry business context dimension, and each data source having a data access mechanism for facilitating querying thereof, wherein each industry business context dimension has at least one dimension instance and each of the at least two data sources have data relating to a dimension instance;
- a database having a first and a second plurality of nodes, each of the first plurality of nodes representing an industry business context dimension including clinical study, clinical trial site, and clinical trial patient, each of the second plurality of nodes representing a data source specific dimension of at least one of the data sources, each of the first plurality of nodes related to at least one other of the first plurality of nodes, and each of the second plurality of nodes related to at least one of the first plurality of nodes, wherein the database is stored in the data storage space, and further wherein the first plurality of nodes includes a clinical study node, a clinical trial site node, and a clinical trial patient node;
- a plurality of data source query function calls, each query function call querying a single data source, and each query function call using the data access mechanism of the single data source to facilitate access to the single data source;
- a first complex query calling a plurality of data source query function calls, including, in response to a user query about a particular clinical trials patient as a dimension instance of the clinical trials patient industry business context dimension, a query of an electronic data capture (“EDC”) data source having EDC study data stored thereon, including EDC study data for the particular clinical trials patient;
- wherein the first complex query does not identify any data source to query, the first complex query calling the plurality of data source query function calls to perform the querying of the at least two data sources for the data relating to the dimension instance, wherein the data relating to the dimension instance is retrieved from each of the at least two data sources, including EDC data for the dimension instance being retrieved from the EDC data source, to populate at least one result set object;
- a second complex query, in response to a user passing dimension instance parameters in the form of a list of a plurality of clinical trials patients, calls a first query of a first data source for patient characteristics data for a first dimension instance, calls a second query of a second data source for patient characteristics data for a second dimension instance, and calls a third query of a third data source for patient characteristics data for a third dimension instance;
- wherein the second complex query does not identify any data source to query; and
- wherein, in response to the second complex query, patient characteristics data for the first dimension instance is retrieved from the first data source, patient characteristics data for the second dimension instance is retrieved from the second data source, and patient characteristics data for the third dimension instance is retrieved from the third data source to populate at least one result set object.
14. The system of claim 13, wherein the first complex query calls, in response to the user query about a particular clinical trials patient:
- (a) a query of a patient diary data source having patient diary data stored thereon, including patient diary data for the particular clinical trials patient, and
- (b) the query of the EDC data source; and
- wherein patient diary data for the dimension instance is retrieved from the patient diary data source and EDC data for the dimension instance is retrieved from the EDC data source to populate at least one result set object.
15. The system of claim 13 wherein the first complex query comprises a clinical trials patient quality of life complex query.
16. The system of claim 13, wherein:
- the first data source is a study database;
- the second data source is a first EDC study database; and
- the third data source is a second EDC study database.
17. The system of claim 13, wherein the first complex query calls, in response to the user query about a particular clinical trials patient:
- (a) a patient diary data query of the patient diary data source;
- (b) a patient pain level query of the patient diary data source; and
- (c) an EDC medication query of the EDC data source; and
- wherein patient pain level data for the dimension instance is retrieved from the patient diary data source, EDC medication data for the dimension instance is retrieved from the EDC data source, and other patient diary data for the dimension instance is retrieved from the patient diary data source to populate at least one result set object.
18. The system of claim 17 wherein the industry business context dimensions include clinical trial sponsor, clinical study, clinical trial site, clinical trial patient, and clinical trial visit dimensions and further wherein the first plurality of nodes includes a clinical trial sponsor node, a clinical study node, a clinical trial site node, a clinical trial patient node, and a clinical trial visit node.
5442791 | August 15, 1995 | Wrabetz et al. |
5555403 | September 10, 1996 | Cambot et al. |
5596744 | January 21, 1997 | Dao et al. |
5634053 | May 27, 1997 | Noble et al. |
5873093 | February 16, 1999 | Williamson et al. |
5995961 | November 30, 1999 | Levy et al. |
6009422 | December 28, 1999 | Ciccarelli |
6092099 | July 18, 2000 | Irie et al. |
6199059 | March 6, 2001 | Dahan et al. |
6222533 | April 24, 2001 | Notani et al. |
6272488 | August 7, 2001 | Chang et al. |
6285998 | September 4, 2001 | Black et al. |
6341281 | January 22, 2002 | MacNicol et al. |
6381595 | April 30, 2002 | Kleewein et al. |
6408292 | June 18, 2002 | Bakalash et al. |
6643639 | November 4, 2003 | Biebesheimer et al. |
6804674 | October 12, 2004 | Hsiao et al. |
6853994 | February 8, 2005 | Gupta |
6988109 | January 17, 2006 | Stanley et al. |
7028023 | April 11, 2006 | Wang |
7165221 | January 16, 2007 | Monteleone et al. |
7464087 | December 9, 2008 | Shlaes et al. |
7620621 | November 17, 2009 | Fuselier et al. |
8234294 | July 31, 2012 | Shlaes et al. |
20010052545 | December 20, 2001 | Serebrennikov |
20020059264 | May 16, 2002 | Fleming et al. |
20020169771 | November 14, 2002 | Melmon et al. |
20030036683 | February 20, 2003 | Kehr et al. |
20030225856 | December 4, 2003 | Pietrowski et al. |
20040133543 | July 8, 2004 | Shlaes et al. |
20040236221 | November 25, 2004 | Eder |
2493269 | September 2012 | CA |
11-250073 | September 1999 | JP |
2166792 | May 2001 | RU |
2172012 | August 2001 | RU |
2333530 | September 2008 | RU |
00/42553 | July 2000 | WO |
00/75849 | December 2000 | WO |
02/21259 | March 2002 | WO |
02/39250 | May 2002 | WO |
2004/012057 | February 2004 | WO |
- European Search Report dated Feb. 1, 2013, for related European Patent Application No. 12153336.8.
- Examination Report dated Feb. 5, 2013, for related European Patent Application No. 03772021.6.
- Response to European Search Report filed Sep. 6, 2013, for related European Patent Application No. 12153336.8.
- Response to Examination Report filed Aug. 15, 2013, for related European Patent Application No. 03772021.6.
- “IBM Life Sciences Solutions: Turning Data into Discovery with DiscoveryLink” Mar. 2002.
- International Search Report for International Patent Application No. PCT/US03/23656 dated Jan. 14, 2004.
- IBM DiscoveryLink product information, Apr. 12, 2004.
- Supplementary European Search Report for European Patent Application No. 03772021.6 dated Sep. 27, 2007.
- Examiner's First Report for Australian Patent Application No. 2003259281 dated Jan. 8, 2009.
- Office action from U.S. Appl. No. 10/628,884 dated Oct. 31, 2006.
- Response from U.S. Appl. No. 10/628,884 dated Apr. 2, 2007.
- Notice of Allowance from U.S. Appl. No. 10/628,884 dated Aug. 13, 2007.
- Office action from U.S. Appl. No. 10/628,884 dated Mar. 25, 2008.
- Response from U.S. Appl. No. 10/628,884 dated Jun. 23, 2008.
- Notice of Allowance from U.S. Appl. No. 10/628,884 dated Aug. 8, 2008.
- Communication from EP Application No. 03772021 dated Jan. 22, 2010.
- Office action from Indian Application No. 0078/CHENP/2005 dated Mar. 13, 2006.
- Office action from Israeli Application No. 166,517 dated Mar. 24, 2009.
- JP Office Action dated Apr. 27, 2009 from 2004-524998.
- Russian Office Action from 2005105305 dated Jul. 10, 2007.
- Communication from European Application No. 03772021.6 dated Dec. 10, 2010.
- Annevelink, et al., “Heterogenous Database Integration in a Physician Workstation”, pp. 368-372, Proceedings of the Annual Symposium on Computer Application in Medical Care, 1992.
- De Smedt et al., “A Physician's Workstation as an Application of Object-Oriented Database Technology in Healthcare”, pp. 234-252, Lecture Notes in Computer Science, vol. 819, 1994.
- Request for Ex Parte Reexamination for related U.S. Patent No. 7,464,087 and accompanying attachments submitted to the U.S. Patent Office on Oct. 28, 2011, 176 pgs.
- Billhardt, H., et al., A New Method for Unifying Heterogeneous Databases, Second International Symposium Medical Data Analysis Proceedings, Jose Crespo, et al. eds., Springer-Verlag Berlin Heidelberg, New York, 54-61 (2001).
- Marks, C, Extensible Multi-Agent System for Heterogeneous Database Association Rule Mining and Unification, (unpublished M.S. thesis, Air Force Institute of Technology Air University) (on file with the Air Force Institute of Technology Air University), 1-91 (Mar. 1999).
- Marrs, K., et al., Unifying Heterogeneous Distributed Clinical Data in a Relational Database, Proceedings of the Symposium on Computer Applications in Medical Care, C. Safran, ed., McGraw-Hill, New York, 644-648 (1994).
- Paepcke, A., An Object-Oriented View Onto Public, Heterogeneous Text Databases, Proceedings of the 9th International Conference on Data Engineering, 484-493 (1993).
- Ram, S., etal., A Unifying Semantic Model for Accessing Multiple Heterogeneous Databases in a Manufacturing Environment, Interoperability in Multidatabase Systems, 212-215 (1991).
- Sheth, A., et al., Federated Database Systems for Managing Distributed, Heterogeneous, and Autonomous Databases, ACM Computing Surveys, 22(3): 183-236 (1990).
- Smith, J.M., et al., Multibase-integrating heterogeneous distributed database systems, National Computer Conference, 487-499 (1981).
- Sujansky, W., A Formal Model for Bridging Heterogeneous Relational Databases in Clinical Medicine, (Ph.D. dissertation, Stanford University), 1-302 (Jan. 1996).
- Sujansky, W., Heterogeneous Database Intergration in Biomedicine, Journal of Biomedical Informatics, 34(4): 285-298 (2001).
- Templeton, M., et al., InterViso: Dealing with the Complexity of Federated Database Access, VLDB Journal, 4: 287-317 (1995).
- van Wingerde, F.J., et al., Using HL7 and the World Wide Web for Unifying Patient Data from Remote Databases, Proc AMIA Annu Fall Symp., 643-647 (1996).
- Order Granting Request for Ex Parte Reexamination dated Dec. 16, 2011, for related U.S. Reexamination Control No. 90/011,985.
- Non-Final Office Action dated Dec. 16, 2011, for related U.S. Reexamination Control No. 90/011,985.
- Tang et al., “Physicians' Workstations: Integrated Information Management for Clinicians,” Proc Annu Symp Comput Appl Med Care, at 569-573 (1991).
- Young et al., “An Open System Architecture for Development of a Physician's Workstation,” Proc Annu Symp Comput Appl Med Care, at 491-495 (1991).
- Ex Parte Reexamination Interview Summary dated Feb. 14, 2012, for related Reexamination Control No. 90/011,985.
- Amendment in Response to Reexamination Non-Final Office Action filed Feb. 16, 2012, in response to Non-Final Office Action dated Dec. 16, 2011, for related Reexamination Control No. 90/011,985.
- Executed Declaration of Christopher Lee Wilke filed Feb. 16, 2012, in response to Non-Final Office Action dated Dec. 16, 2011, for related Reexamination Control No. 90/011,985.
- Patent Owner's Statement of the Substance of the Interview filed Mar. 14, 2012, for related Reexamination Control No. 90/011,985.
- Final Office Action filed Apr. 6, 2012, in response to Non-Final Office Action dated Dec. 16, 2011, for related Reexamination Control No. 90/011,985.
- Response After Final filed May 7, 2012, in response to Final Office Action mailed Apr. 6, 2012, for related Reexamination Control No. 90/011,985.
- Advisory Action mailed Jun. 4, 2012, for related Reexamination Control No. 90/011,985.
- Communication for EP Application No. 03372021.6 dated Oct. 16, 2007.
- Response filed Dec. 21, 2007, in response to Communication for EP Application No. 03372021.6 dated Oct. 16, 2007.
- Response filed Nov. 17, 2010, in response to Communication for EP Application No. 03372021.6 dated Jan. 22, 2010.
- Amendment to Claims filed Jul. 26, 2012, for EP Application No. 03372021.6.
- Record of Oral Hearing dated Jan. 28, 2014, for related Reexamination Control No. 90/011,985.
- Patent Board Decision dated Mar. 4, 2014, for related Reexamination Control No. 90/011,985.
Type: Grant
Filed: Jun 14, 2012
Date of Patent: Oct 7, 2014
Patent Publication Number: 20130073590
Assignee: Datatrak International, Inc. (Cleveland, OH)
Inventors: Marc J. Shlaes (Shaker Heights, OH), Jochen van Berkel (Cologne), Hermann Engel (Cologne), Mario Jugel (Herschbach)
Primary Examiner: Anh Tai Tran
Application Number: 13/523,402
International Classification: G06F 17/30 (20060101);