Metadata automated system

A method can include: providing a schema definition language defining trait observations linked to an entity and the trait observations grouped together in a module with metadata; generating physical tables for the module and the entity having a link therebetween based on at least one of the trait observations; and populating the physical tables with data in accordance with the metadata.

FIELD OF THE INVENTION

Embodiments of the invention relate generally to computer databases and, more particularly, facilitating the management of data structures, including their definition and creation, modification, transformation and population.

BACKGROUND OF THE INVENTION

The automated processing of information has been an enormous benefit to businesses because it has greatly increased the effectiveness and efficiency of decision makers at every point in a decision path. Every enterprise regardless of whether it is a government, commercial business or not-for-profit organization has the operational necessity to manage information.

This information is used to treat patients, acquire customers, input orders, ship product, bill customers, collect invoices, pay employees and vendors, order product, audit inventory and maintain records of transactions between employees, customers and suppliers, for example, in the case of a commercial business.

In the normal course of events, information is acquired, processed and consolidated utilizing software, computer hardware and digital networks in accordance with each organization's internal operational model. Unfortunately, the automated processing of information is fraught with many debilitating problems preventing the useable, timely, and cost effective integration, standardization, and reporting of data.

One previous approach focused on constructing enterprise data warehouses to collect consolidated and standardized data from an entire organization. The typical enterprise data warehouse requires operational data from many sources to be extracted, transformed, and loaded into a third normal form Operational Data Store database which is again extracted, transformed, and loaded into a star and snowflake data vault database. The data vault database can then be loaded into data marts, each dedicated to a particular department or function.

Each database in the enterprise data warehouse formation and functioning process must be designed, maintained, and populated with a custom Extract Transform Load (ETL) function. Furthermore, all stages in the development and use must be completed, in some form, before the organization is able to generate reports and begin to realize benefits from the enterprise data warehouse.

While an enterprise data warehouse achieves standardized data that is centrally managed for an entire organization, this comes at a very high cost. The resources required to implement a comprehensive enterprise data warehouse can be prohibitive to all but a very select few, as monetary costs can be astronomical. Even when monetary resources are not the limiting factor, the time to build and implement an enterprise data warehouse is commonly measured in years.

Another shortcoming of enterprise data warehousing stems from the enterprise data warehouse focus on decision support applications, which emphasize summarized information. An inherent disadvantage to these systems is that transaction details about the customer's identity are lost. Enterprise data warehouses exhibit shortcomings when applied to applications such as customer data analysis. Customer data analysis is a decision support analysis that correlates data to customers' activities, events, transactions, status and the like. Summarized information usually loses the detail level of information about customer identity, limiting the usefulness of enterprise data warehousing approaches in these applications.

Other approaches focus on creating department focused data marts directly from an organizations operational data. Department focused data marts only need to incorporate the data relevant to a single department. Because of this, department focused data marts can be much smaller.

Due to the smaller size department focused data marts generally take fewer resources in terms of time and money to build; however, these benefits also come at a steep cost. Department focused data marts are not centrally managed and do not have consistent standards in terms of quality or data formats.

When department focused data marts are created, the inconsistent standards prevent integration across the organization. Also, since each department focused data mart is created without an overarching plan the total amount of resources invested for each department to have a data mart can be substantially higher than creating a single well planned enterprise data warehouse. The resources to maintain inconsistent department focused data marts can also be much higher than maintaining a single enterprise data warehouse.

Currently, there is no comprehensive solution that resolves the problem of providing useable, timely, and cost effective integration, standardization, and reporting of data. This need has been long felt in the industry.

Prior developments have not taught or suggested any solutions to overcome all of the limitations described above, and thus, solutions to overcome these limitations have long eluded those skilled in the art.

SUMMARY OF THE INVENTION

The claimed invention is directed to methods, articles of manufacture, and systems that utilize a schema definition language having metadata for defining traits linked to entities and the traits grouped together in modules. It is contemplated that the schema definition language is utilized to generate physical tables for the modules and the entities having a links therebetween and based on the traits. The physical tables can be populated with data conforming to the metadata.

It is further contemplated that schema definition language can be referenced to locate the physical tables and determine whether the physical tables for the modules or the entities includes a selected trait. In the same vein, the schema definition language can be referenced to locate the physical tables and determine whether the physical tables include a subsequent selected trait only if the physical tables include the selected trait.

It is further contemplated that one-hop linkages can be determined from the schema definition language if the traits are grouped within the same module as a selected trait. It is further contemplated that the entities can be classified into a matching cohort or a non-matching cohort based on whether a clinical pattern matches the traits associated with the entities.

It is further contemplated that a report data definition can reference the schema definition language to include the modules if the traits associated with the modules are included in the report data definition. It is further contemplated that the physical tables can include longitudinal and non-longitudinal data associated with the modules and the entities, respectively.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In the following description of the embodiments of the invention, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration, exemplary embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention.

For expository purposes, the term “metadata” as used herein is defined as data about data. The term “system” as used herein means and refers to the method and to the apparatus of the present invention in accordance with the context in which the term is used.

Embodiments of the invention provide techniques for applying a unique schema definition language and for utilizing the schema definition language in structuring, generating, and populating data bases or data stores; automatically generating Extract-Transform-Load functions; enabling Business Intelligence tools that reference the schema definition language to pull data from a database or data store. As used herein, Business Intelligence tools refer generally to software applications configured to report, analyze and present data. The data may be stored in a data warehouse, Database, Data store, data mart, or a combination thereof.

According to one aspect, the schema definition language can be implemented in or represented by a schema definition model that exhibits the relationship of traits, entities, and modules defined by the schema definition language. The schema definition language defines the structure and framework for physical tables of an operational data store. The schema definition language may include relationships and locations for mapping the schema definition model to one or more physical entities of physical data. Accordingly, the schema definition language defines and can be used to access a field of the physical data which contains the specific set of the physical data.

Advantageously, embodiments of the invention provide techniques for providing a schema definition language at a higher level of abstraction and providing a platform to interface with the schema definition language to enable Business Intelligence tools to utilize an operational data store with lower cost, and shorter time frame. The schema definition language enables the Business Intelligence tools to operate at a higher level of abstraction so the tools no longer have to be changed when underlying database evolves. Database evolution is easy and non-disruptive when utilizing the schema definition language of the present invention.

Advantageously, Business Intelligence tools utilizing the schema definition language to access and query the physical tables provide an intuitive experience to users by providing options that pertain to the types of traits selected in previous steps. The schema definition language can also be used to provide a simple structure to the physical tables enabling an easy and efficient solution to modeling and designing operational data stores. Further, utilizing the schema definition language allows the automation of extract, transform, and load functions to populate an operational data store quickly based on the schema definition language structure and metadata contained within a schema definition model.

When any of the appended claims are read to cover a purely software and/or firmware implementation, at least one of the elements in at least one example is hereby expressly defined to include a tangible computer-readable media storing the software and/or firmware.

Referring now toFIG. 1, therein is shown an exemplary distributed computer system100according to an embodiment of the present invention. In general, the distributed computer system100is shown as a distributed environment and includes computer system102and a plurality of networked devices104. The computer system102may represent any type of computer, computer system or other programmable electronic device, including a client computer, a server computer, a portable computer, an embedded controller, a PC-based server, a minicomputer, a midrange computer, a mainframe computer, and other computers adapted to support the methods, apparatus, and article of manufacture of the invention.

Illustratively, the computer system102comprises a networked system. However, the computer system102may also comprise a standalone device. In any case, it is understood thatFIG. 1is merely one configuration for the computer system100. Embodiments of the invention can apply to any comparable configuration, regardless of whether the computer system102is a complicated multi-user apparatus, a single-user workstation, or a network appliance that does not have non-volatile storage of its own.

The embodiments of the present invention may also be practiced in distributed computing environments in which tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. In this regard, the computer system102and/or one or more of the networked devices104may be thin clients which perform little or no processing.

The computer system102could include a number of operators and peripheral systems as shown, for example, by a mass storage interface106operably connected to a direct access storage device108, by a video interface110operably connected to a display112, and by a network interface114operably connected to the plurality of networked devices104. The display112may be any video output device for outputting viewable information.

Computer system102is shown comprising at least one processor116, which obtains instructions and data via a bus118from a main memory120. The processor116could be any processor adapted to support the methods of the invention.

The main memory120is any memory sufficiently large to hold the necessary programs and data structures. Main memory120could be one or a combination of memory devices, including Random Access Memory, nonvolatile or backup memory, (e.g., programmable or flash memories, read-only memories, etc.). In addition, memory120may be considered to include memory physically located elsewhere in the computer system102, for example, any storage capacity used as virtual memory or stored on a mass storage device (e.g., direct access storage device108) or on another computer coupled to the computer system102via bus118.

The memory120is shown configured with an operating system122. The operating system122is the software used for managing the operation of the computer system102.

The memory120further includes an access layer124, a schema definition language126, a filter128, a report data definition130, one or more applications132, and a plurality of Business Intelligence tools134. The applications132, the Business Intelligence tools134and the access layer124are software products comprising a plurality of instructions that are resident at various times in various memory and storage devices in the computer system102. When read and executed by one or more processors116in the computer system102, the applications132, the access layer124and the schema definition language126, individually or in combination, cause the computer system102to perform steps necessary for executing various aspects of the invention.

The access layer124(and more generally, any requesting entity, including the operating system122) are configured to issue queries against a database136. Illustratively, the database136is shown as part of a database management system (DBMS)138in storage108. Although only one database is shown for simplicity, the DBMS138may include multiple databases.

Further, the databases may be distributed relative to one another. Moreover, one or more databases can be distributed to one or more of the networked devices104. Illustratively, a networked system140is shown having a DBMS142which includes a database144. Although only a single database144is shown with the DBMS142, for simplicity, the DBMS142may include multiple databases. Further, the databases of the DBMS142may be distributed relative to one another. All such different implementations are broadly contemplated. The storage108or the networked devices104may also include metadata tables, physical tables, the schema definition language126, or a schema definition model, used by the application132to structure filters, provide user feedback, or structure report data definitions for the Business Intelligence tools134.

The databases136and144are representative of any collection of data regardless of the particular physical representation of the data. A physical representation of data defines an organizational schema of the data.

In one embodiment, the database136includes an operational database and the database144includes an operational data store. The operational database includes at least a portion of the physical data contained in the data store. According to one aspect, the data store contains queryable data which is derived from physical data in the operational database. Accordingly, the queryable data in the data store includes a subset of the physical data in the operational database. In addition to the subset of data from the operational database, the data store may include other data.

In one embodiment, queries may be generated in response to input (e.g., user input). The queries can be composed using logical fields defined by the schema definition language126. Queries are executed against the database144using the filter128which can reference the schema definition language126to isolate or define a class of entities404ofFIG. 4represented by physical data within the databases144. Operation of the filter128is described in greater detail below with reference toFIGS. 9-12.

Queries are also executed against the database144using the report data definition130which can reference the schema definition language and structure reports of entities404, modules406, and trait observations408ofFIG. 4, and pull data from physical tables within the database144. Operation of the report data definition130is described in greater detail below with reference toFIGS. 13-15.

Referring now toFIG. 2, therein is shown an exemplary block diagram of a data handling system200according to an embodiment of the present invention. The data handling system200includes a data input block202for extracting data203from one or more external sources204and loading the data203that was extracted into an operational data store206, coupled thereto. For instance, the external sources204can be the database136of the storage device108ofFIG. 1. The operational data store206can be included within the database144of the networked devices104ofFIG. 1.

The management engine208is configured to map and locate at least a portion of the data203in the operational data store206, perform calculations of the location and relationship of the data203based on the schema definition language126for any subsequent allocation processing, mapping, filtering, or reporting.

The data handling system200also includes an information delivery block210, coupled to the operational data store206and to the management engine208, for delivering the data203to a user. The delivery function can be implemented by the Business Intelligence tools134. The Business Intelligence tools134can be filtering tools for example the TransMed Systems Cohort Explorer or the TransMed Systems Clinical Pattern Matcher, described below inFIGS. 9 and 11, respectively. The Business Intelligence tools134can also be reporting tools such as the TransMed Systems Cohort Reporter or the TransMed Systems Cohort Analyzer, described below inFIGS. 13 and 15, respectively.

In addition, the information delivery block210of the data handling system200includes a user interface212for receiving runtime parameters from a user and a task controller214for launching the management engine208in response to the inputs from the user interface212. The user interface212can include hardware and software for bidirectional communication with a user. The task controller214is also in communication with the management engine208, which allows a user to submit parameters and instructions for grouping, filtering, and returning the data203via the user interface212.

The data input block202uses an Extract-Transform-Load (ETL) tool216to extract the data203from one or more of the external sources204and then transform the data203extracted into at least one preferred data format. The data203, which was transformed, can then be loaded into one or more physical tables218in the operational data store206for data storage.

Importantly, the management engine208can provide the schema definition language126as a framework for the Business Intelligence tools134and the physical tables218. The management engine208can automatically generate the ETL tool216to populate the physical tables218with the data203from the external sources204utilizing the schema definition language126.

The operation of automating the ETL tool216and populating the physical tables218is described below with regard toFIGS. 7 and 8. The management engine208can further provide the schema definition language126as a framework upon which the Business Intelligence tools134can operate to structure reports and filter searches.

The schema definition language126includes entity types220, traits222, and module types224. The traits222are linked to the entity types220with a link226. The traits222can be grouped together in the module types224based on whether the traits222are observed together.

The entity types220, the traits222, and the module types224can be metadata constructs of the schema definition language126that provide structure for the formation of the schema definition model400described below with regard toFIG. 4that will provide the structure and relationship of the physical tables218in the operational data store206. The schema definition language126further provides a framework for how the data203will populate the physical tables218.

For illustrative purposes and ease of understanding, the entity types220, traits222, and the module types224will be described below with reference to the health care field. Those skilled in the art will recognize that such is for illustrative purposes only and is not intended to be limiting of the invention.

It is contemplated that the entity types220can define types of physical objects. The entity types220are abstractions and metadata302, ofFIG. 3, of actual entities404ofFIG. 4, which are data constructs. The actual entities404are concrete instances of the entity types220having trait observations408ofFIG. 4and a lifetime. A lifetime as used herein is defined as a time-span within which the physical object exists in a state in which the reasonable observer would recognize the physical object as one of the entity types220. Trait observations408are herein defined as observable facts about an entity404.

In relation to the health care field the entity types220can be exemplified as a patient, physician, or facility. The entity404can be exemplified as a specific hospital, patient, physician, or payer. That is to say, the entity404can be Dr. Jones, or Suburban Hospital.

It is contemplated that the module types224can define specific records or moments that result in the observation of trait observations408. The module types224are abstractions and metadata302of actual modules406ofFIG. 4, which are data constructs. The actual modules406are concrete instances of the module types224, the modules406can list trait observations408observed for an entity404that are normally observed together. As used herein module406is defined as a collection of related trait observations408for an entity404often observed together. The module types224can include start and end dates for the observation of the traits222. The module types224lists the traits222associated with the module types224and identifies the module types224start and end date. It is further contemplated that the module types224can include only a single date or time stamp the same start and end time stamp for events without duration.

The module types224can be exemplified as an encounter (admission date, discharge date), a diagnosis (diagnosis date), treatment (treatment start and end date), and lab order (lab order date). The modules406themselves can be exemplified as a specific encounter, diagnosis, treatment, or lab order. That is to say, the module406can be Mike Johnson admitted to the Suburban hospital emergency room on Feb. 5, 2012, Mike Johnson diagnosed with pneumonia on Feb. 5, 2012, Dr. Jones administered Benzylpenicillin to Mike Johnson on Feb. 5, 2012 to treat Mike Johnson's pneumonia, or Dr. Jones orders a complete blood count without differential test for Mike Johnson on Feb. 5, 2012.

It is contemplated that the traits222can define a single observable property or trait observation408of or for an entity404. The traits222have names and specify particular data types410ofFIG. 4such as Integer, Real, DateTime, Text, Choice, Module Pointer, or Entity Pointer. The traits222are abstractions and metadata302of observed trait observations408, which are data constructs. The trait observations408are concrete instances of observations of facts about an entity404. The trait observations408match the traits222data type410.

The traits222can be exemplified for a diagnosis module type as a diagnosis date with a data type410of time, ICD9 selection with a data type410of choice, physician notes with a data type410of text, or severity selection with a data type410of choice. The traits222can further be exemplified for an encounter module type as admission date with a data type410of DateTime, discharge date with a data type410of DateTime, Primary payer with a data type410of choice, or discharge disposition with a data type410of choice.

The traits222can include longitudinal and non-longitudinal trait observations408. Longitudinal trait observations408, as used herein, are defined to mean trait observations408corresponding to events treated as occurring within the lifespan of an entity404. Usually longitudinal trait observations408have duration of less than the lifetime of the entity404that is observed to possess them. Non-longitudinal trait observations408, as used herein, are defined to mean trait observations408that are treated as lasting for the lifespan of the entity404such as a name, a blood-type, or a patient ID. The non-longitudinal traits may change but they are not necessarily related to a specific event. The entity types220can be assigned a special one of the module types224to capture the non-longitudinal traits for an entity404. Longitudinal traits, on the other hand, will be assigned a date of occurrence for the entity404and will be grouped with the standard module types224.

It has been discovered that utilizing the schema definition language126implemented as the metadata302and represented by the metadata tables300ofFIG. 3semantically represents the entities404linked to the trait observations that are grouped by the modules406and therefore provides a simple and effective framework for the physical tables218. This framework, coupled with the schema definition language126of the metadata tables300, enables quick, simple, and effective use of the physical data tables218by referencing the metadata tables300. The physical data tables218can be filtered and used to generate reports by referencing the schema definition language126in the metadata tables300.

The schema definition language126captured as metadata302in the metadata tables300allows the physical data tables218to be filtered and used to generate reports in an intuitive way while simultaneously decreasing implementation costs and timelines. Implementation timelines can be significantly reduced by utilizing the schema definition language126because in a typical data warehouse the data structure needs to be normalized and placed in dimensional tables; however, by utilizing the schema definition language126, the data203can simply be associated with metadata constructs and data constructs. Once the association is provided the ETL tool216can be automatically generated and the physical tables218populated. As soon as the physical tables218of the operational data store206are populated, the Business Intelligence tools134can utilize the schema definition language126to filter, report, and query the data in the operational data store206rather than requiring multiple additional steps of normalization, and populating dimensional tables with an extract, transform, load action between each step.

It has further been discovered that the schema definition language126providing the traits222with a predefined data type410allows for automatic generation of the ETL tool216thus decreasing implementation costs and timelines significantly.

To enable the Business Intelligence tools134to operate effectively and provide the user with an intuitive experience, the information delivery block210is coupled to the management engine208to reference the schema definition language126. The management engine208can further include the filter128and the report data definition130. The filter128can be a one dimensional filter used to generate a class of the entities404based on the trait observations408of the entities404. The filter is described in greater detail below with regard toFIGS. 9-12. The report data definition130can be a set of the entity types220, the module types224, and the traits222that are required or desired for a report and which will be utilized to retrieved the data203from the operational data store206. The report data definition130is described in greater detail below with regard toFIGS. 13-14.

Referring now toFIG. 3, therein is shown exemplary metadata tables300according to an embodiment of the present invention. The metadata tables300represent the schema definition language126ofFIG. 1. The schema definition language126can be used as the metadata302to describe the data203of the physical data tables218ofFIG. 2. The metadata tables300can include a plurality of relational links304therebetween. The metadata tables300can include an entity type table306linked to a trait table308. The entity type table306and the trait table308can be linked to a module type table310.

The entity type table306, the trait table308, and the module type table310can correlate to the entity types220, the traits222, and the module types224ofFIG. 2, respectively. The metadata tables300can include the entities404, the modules406and the trait observations408ofFIG. 4as rows within the entity type table306, the module type table310, and the trait table308, respectively.

The metadata tables300contain the metadata302that maps, by semantic representation, the physical data tables218. As an example, the trait table308can contain rows that correspond to the trait observations408. As an example, ICD9 choices are trait observations408that can be contained as rows within the trait table308. The ICD9 choices of the trait table308can include pointers or references to the modules406and or the entities404that can be associated with the trait observations408. For example, an ICD9 trait observation408might point to a diagnosis module406and to a patient entity404.

Because the metadata tables300include a semantic representation or map of the structure of the physical data tables218, the metadata tables300can be used to locate the data203contained within the physical data tables218. The metadata tables300can also be used to determine the relational links304between the data203of the physical data tables218.

The relationship of the module type table306, the entity type table306, and the trait table308show the relationship of the entity types220, traits222, and the module types224described in greater detail above with regard toFIG. 2.

The relational links304between the metadata tables300is a map for how the data203will eventually be structured within the physical tables218of the operational data store206ofFIG. 2. The relational links304are a pictorial representation of the trait observations408pointing or referencing the modules406, the entities404, or other data or metadata constructs.

The relational links304of the schema definition language126provide the relational structure for the physical tables218that will eventually hold the data203. The schema definition language126can provide a map for the location of the physical tables218and the relationship between the physical tables218.

As an example, if a user selects a trait observation408to filter an entity404or module406by, the Business Intelligence tools134ofFIG. 1can reference the schema definition language126locate the trait observations408and determine how the trait observations408are linked to the entities404and the modules406. Once the modules406and entities404linked to the trait observations408are determined by the metadata tables300, other trait observations408that belong to the same modules406or entities404as the user selected trait observation408.

By providing the relationship of the trait observations408to the entities404and modules406the management engine208ofFIG. 2can provide options to the user for selecting other trait observations408related to the first trait observation408selected or can provide options to the user for selecting other modules406. The management engine208can utilize the schema definition language126to return other trait observations408to the user from the same module406as selections options for the user. In this way the schema definition language126can be utilized to provide relevant filter or report options to users based solely on the structure of the data203within the physical tables218as required and contained within the schema definition language126.

The relational links304between the metadata tables300show many-to-one links312. The entity type table306and the module type table310also include recursive links314allowing for hierarchical relationships between entities404.

Other tables can make up the metadata tables300including a data type table316, a choice type table318, a choice table320, and an authority table322. It is contemplated that the metadata tables300can include more tables without departing from the invention. As an example, the metadata tables300may include a module type member table or a unit of measure table. It is further to be understood that tables can be combined or deleted without departing from the scope of the invention.

Referring now toFIG. 4, therein is shown an exemplary schema definition model400according to an embodiment of the present invention. The schema definition model400can be the application of the schema definition language126ofFIG. 1into a data context. Continuing with the health care example for illustrative purposes only, the entity types220, module types224, and the traits222have been mapped to metadata302for the entities404, the modules406, and the trait observations408.

The metadata302can be associated with the entities404, the modules406, the trait observations408, as well as the entity types220, the module types224, and the traits222. As will be shown through illustrative example below, the metadata302contained within the schema definition model400can define how the trait observations408are linked to the entities404and how the trait observations408are grouped together in the modules406.

As an illustrative example the entities404can be a patient, sample, experiment, or genetic variant. The entities404are shown having non-longitudinal trait observations408grouped therewith. As an illustrative example the trait observations408grouped with the entities404identified as patients can include an ID, birth date, death date, gender, ethnicity, primary payer, and current vital status.

The trait observations408grouped with the modules406are shown as longitudinal trait observations408. As an illustrative example the traits grouped with the modules406having the metadata302for radiation can include boost dose, boost treatment modality, number of treatments, radiation anatomic site, radiation volume, and regional dose. The modules406can also include pointers which will be foreign keys to other modules406such as a pointer for treatment modules406in the modules406corresponding to radiation.

The modules406and the entities404are not depicted as the actual data203ofFIG. 2in the schema definition model400but instead are shown having the metadata302. The trait observations408are also shown having the metadata302in the form of a data type410. The data type410can specify the type of the data203that will eventually populate the physical tables218ofFIG. 2.

Due to the recursive relationship of the entity type table306and the module type table310ofFIG. 3the entities404and the modules406can include sub-entities and sub-modules, respectively. The sub entities can be entities404that originate from a specific entity404. The sub-modules can be modules406that originate from a specific module406.

Referring now toFIG. 5, therein is shown an exemplary schema definition model table500according to an embodiment of the present invention. The schema definition model table500is shown in a simplified format for ease of description.

The schema definition model table500is shown having a plurality of columns and rows. Each row corresponds to the trait observations408. The cells of the table are filled with metadata302rather than the actual data203that will populate the physical tables218of the operational data store206ofFIG. 2.

In a similar manner toFIG. 4, the trait observations408can be linked to entity types220and module types224. The entity types220can be represented by a first column while the module types224can be represented by a second column. In like manner, the rows of the trait observations408will pass through columns indicating other features of the trait observations408. The trait observations408can be associated with a display trait502, a sequence504, a trait name506, a data type410, choice type508, vertical indicator510, target entity type512, target module type514, unit of measure516, multiple selection indicator518, and a protection indicator520.

The entity types220, of the first column, can be the entities404that the trait observations408are associated with. The entity types220can, for example, include patient, sample, experiment, genetic variant, hospital, or physician if the preceding health care field example is utilized. The module types224, of the second column, can be the modules406that the trait observations408are associated with. The module types224can include patient information (which is a special module to contain non-longitudinal trait observations408for the entities404), cancer diagnosis, chemotherapy, medication, radiation, surgery, treatment, labs and vitals, consent, sample information, experiment information, genetic variant observation, and others.

The display trait502, of the third column, can indicate whether the trait observations408should be displayed as a default ID trait for a module406. The display trait502can identify the trait observations408as either an identified trait or a de-identified trait. An example of an identified trait associated with a patient info module for a patient entity can be a patient ID. An example of an identified trait associated with a diagnosis module for a patient entity can be an ICD9 value. An example of a de-identified trait associated with a patient info module for a patient entity can be a birthday since this trait would be less helpful as a default value in working with the entities404.

The sequence504, of the fourth column, can indicate the order in which the trait observations408can be displayed within the modules406. The trait name506, of the fifth column, can identify the trait by name. As an example of the trait name506for a medication module, the trait observations408can be identified as drug dosage, drug frequency, drug name, drug route of administration, medication treatment, or medication diagnosis. Each of the module types224can include unique trait names506that will correspond to the data203mapped to the trait observations408in the physical tables218.

The data type410, of the sixth column, can indicate the type of data that the trait observations408will be stored in. The trait observations408can include integer data, real data, text data, long text data, date data, date time data, choice data, module pointers, or entity pointers.

The choice type508, of the seventh column, will be used if the data type410corresponds to choice data. The choice type508can be a list of all valid choices for the trait observations408associated with choice data. As an example choice type508can include yes/no, or male/female. The choice type508can also include longer such as a list of potential types of chemotherapy for a treatment or chemotherapy module. This type of choice type508may be a list including Mechlorethamine, Cyclophosphamide, Chlorambucil, Melphalan, Ifosfamide, Thiotepa, Hexamethylmelamine, Altretamine, Procarbazine, Dacarbazine, Temozolomide, Carmustine, Lomustine, Streptozocin, Carboplatin, Cisplatin, or Oxaliplatin.

The vertical indicator510, of column8, can indicate how the trait observations408will be stored in the physical tables218of the operational data store206. If the vertical indicator510is an ‘N’ indicating the trait observations408are not stored vertically, the trait observations408will be stored in a column in the table representing the module406the trait is associated with. If the vertical indicator510is a ‘Y’ indicating the trait observations408are stored vertically, the trait observations408will be stored in a separate table with each of the trait observations408having a separate row.

The target entity type512, of the ninth column, will be used if the data type410is an entity pointer. The target entity type512can be used to indicate the entity types220referenced by the module406that the trait observations408are associated with. As an example one of the trait observations408corresponding to an entity pointer and associated with a cancer diagnosis module might reference the entity type220of ‘sample’ if the cancer diagnosis was arrived at with a biopsy.

The unit of measure516, of the eleventh column, can be used to indicate the unit of measure for the trait observations408when they are numeric. As an example the unit of measure516can be pounds or kilograms.

The multiple selection indicator518, of the twelfth column, can be utilized when the data type410is choice to indicate whether the user can choose multiple selections or only a single selection. As an example, if multiple selection indicator518is an ‘N’ then only one choice is valid, when the multiple selection indicator518is a ‘Y’ then multiple selections are valid.

The protection indicator520, of the thirteenth column can indicate whether the trait contains sensitive information. For example if the protection indicator520is a ‘Y’ the trait may contain patient identifying information and should be treated differently.

The schema definition model table500will be used to generate the physical tables218of the operational data store206. Each of the modules406will be a separate table within the operational data store206. Each of the trait observations408will be columns within the tables of the modules406to which they are associated. The data203will occupy the cells within the physical tables218.

Referring now toFIG. 6, therein is shown exemplary physical tables218according to an embodiment of the present invention. The physical tables218can be the physical tables218of the operational data store206ofFIG. 2.

As described below, the physical tables218can be generated by referencing the metadata302ofFIG. 3contained within the schema definition language126ofFIG. 1alone or in combination with the schema definition language126represented in the metadata tables300ofFIG. 3, the schema definition model400ofFIG. 4, the schema definition model table500ofFIG. 5or a combination thereof. The physical tables218can include tables for the modules406and the entities404ofFIG. 4having links therebetween based on at least one of the trait observations408ofFIG. 4.

Continuing with the healthcare example previously discussed and utilizing the schema definition language126, the physical tables218are shown correlating to the modules406defined in the module types224column or, the second column of the schema definition model table500. Each of the modules406defined in the schema definition model table500have a unique physical table602created in the full list of the physical tables218.

The physical tables218can include a table title604and then a list of column names606. The column names606are the trait observations408contained in the rows of the schema definition model table500. Furthermore, when the trait observations408of the schema definition model table500are module pointers or entity pointers, these trait observations408are depicted in the physical tables218as links608. In general the links608can include one-to-one relationships or many-to-one relationships.

For example an entity table610can have a one-to-one relationship with an ODS_PatientInfo table612. This means that for every entity the entity table610will include one foreign key pointing to the ODS_PatientInfo table612. Likewise, the ODS_PatientInfo table612will include one foreign key pointing to the entity table610.

The physical tables218can further include many to one links. For example the ODS_PatientInfo table612can include many foreign keys from multiple ODS_Medication tables614, but each ODS_Medication table614will include only a single foreign key for the ODS_PatientInfo table612.

Another solution presented by the use of the schema definition language126is provided by the vertical indicator510flag. Typically when the vertical indicator510flag is a negative or ‘N’, each trait observations408in the schema definition model table500will be a column in the physical data tables218. This is illustrated by the ODS_LabsVitals table616. However, when the trait observations408become very numerous the vertical indicator510can be set to a positive or a ‘Y’. When the vertical indicator510is positive it indicates that the trait observations408should not be structured as columns within the physical data tables218but should occupy rows within a separate table illustrated as the ODS_LabsVitals_Vertical table618. As an example trait observations408such as white blood cell count and red blood cell count would occupy the ODS_LabsVitals_Vertical table618along with other numerous traits.

The data requirements described with regard toFIG. 1throughFIG. 6as well as the data requirements for the flow charts ofFIG. 7,FIG. 8,FIG. 9,FIG. 11,FIG. 13, andFIG. 15can be fixed on or saved within non-transitory computer-readable media. These data requirements cannot be accessed or modified without the use and implementation of hardware and changes in data values can represent physical, non-transitory transformations of hardware records in the form of bits.

Having described the data requirements for the implementation and use of the operational data store206ofFIG. 2, we now describe the process for implementation and use of the operational data store206. The process steps for implementing and using the operational data store206, in the flow charts described with regard toFIG. 7,FIG. 8,FIG. 9,FIG. 11,FIG. 13, andFIG. 15, can be implemented in hardware, software, firmware, or any combination thereof. Furthermore, the step boundaries commonly vary and functions are implemented together, as well as separately in different embodiments.

Referring now toFIG. 7, therein is shown an exemplary control flow700for implementing and populating an operational data store according to an embodiment of the invention. As an example the operational data store206ofFIG. 2might be implemented and populated in a similar manner.

The control flow700includes a provide schema definition language step702. The provide schema definition language step702can be invoked to provide the schema definition language126. By providing the schema definition language126a designer can utilize the data and metadata constructs.

Coupled to the provide schema definition language step702is a model schema definition step704. During the model schema definition step704designers will utilize the schema definition language126to define the schema definition model400using data elements contained in existing files, existing operational data stores, or existing databases. The schema definition language126is actually implemented by the designers by utilizing the metadata and data constructs described in greater detail above with regard toFIG. 2andFIG. 3.

The model schema definition step704can be coupled to a capture schema definition model step706. During the capture schema definition model step706the schema definition model400can be captured within the schema definition model table500providing a row for each of the trait observations408and assigning or correlating them to the entities404and modules406ofFIG. 4. It is contemplated that the capture schema definition model step706may be skipped and that the schema definition language126can be used in place of the schema definition model table500for referencing and querying the metadata302. The schema definition language126can be used as the metadata tables300ofFIG. 3, the schema definition model400, or a combination thereof.

The capture schema definition model step706can be coupled to a generate operational data store (ODS) step708. The generate ODS step708includes generating the physical tables218of the operational data store206from the schema definition language126contained within the schema definition model table500and creating the links608ofFIG. 6therebetween.

Specifically, during the generate ODS step708one of the physical tables218is first generated for each of the modules406. If the vertical indicator510of the schema definition model table500is an ‘N’ then a column is created in the physical table602ofFIG. 6for the module406associated with the trait observations408. When the column is created for the trait observations408, the data type410indicator ofFIG. 5determines the type of data the column will include.

During the generate ODS step708a foreign key will be generated for the trait observations408that are of the data type410choice for reference to a choice table. Likewise, during the generate ODS step708a foreign key will be generated for the trait observations408that include an indicator in target entity type512or target module type514of the schema definition model table500. If the target entity type512includes an indicator a foreign key referencing an entity table610ofFIG. 6will be generated. On the other hand, if the target module type514includes an indicator a foreign key referencing a one of the module tables will be created.

If the vertical indicator510of the schema definition model table500is a ‘Y’ then a column will not be generated for the trait observations408. Instead, this type of trait observation408will be loaded into the modules406associated vertical table, one trait observation408per row. Finally, trait observations408corresponding to longitudinal timestamps will be associated with the physical tables218of the modules406.

The generate ODS step708is coupled to a generate ETL step710. Once the physical tables218of the generate ODS step708are completed along with the schema definition model table500completed in the capture schema definition model step706, the ETL tool216can be automatically generated based on the schema definition model table500and the schema definition language126. The generation of the ETL tool216will be described in greater detail below with regard toFIG. 8.

The generate ETL step710is coupled to a populate ODS step712. Once the ETL tool216is generated automatically from the schema definition model table500and the schema definition language126, and once the physical tables218are created, the ETL tool216is utilized in the populate ODS step712to extract the data203from the external sources204ofFIG. 2, transform the data203ofFIG. 2into a format that is compliant with the data type410, choice type508, or other columns of the schema definition model table500. Once the data203is compliant with the requirements of the schema definition model table500and the schema definition language126, the data203is loaded into the physical tables218of the operational data store206.

It is understood that when reference or use of elements including the schema definition language126, the schema definition model400, or the schema definition model table500in the flow charts ofFIG. 8,FIG. 9,FIG. 11,FIG. 13, andFIG. 15that it is contemplated that either one or some combination thereof can be referenced or used in place of or along with the named element. For ease of description, the schema definition model table500is generally used as an example of reference for the flow charts.

Referring now toFIG. 8, therein is shown an exemplary control flow800for generating an extract transform load function according to an embodiment of the invention. The control flow800illustrates an exemplary method of automatically generating the ETL tool216ofFIG. 2by referencing the schema definition language126ofFIG. 1. The schema definition language126can be referenced in regard to the metadata302contained within the metadata tables300ofFIG. 3, the schema definition model400ofFIG. 4, the schema definition model table500ofFIG. 5, or a combination thereof. As will be described below, the physical tables218ofFIG. 2can be populated with the data203ofFIG. 2by automatically generating the ETL tool216in accordance with the metadata302.

Generally, the data203from the external sources204ofFIG. 2flows through non-conformed staging tables802and conformed staging tables804before ultimately landing in the operational data store206ofFIG. 2. The management engine208ofFIG. 2can automatically generate the non-conformed staging tables802and the conformed staging tables804from the schema definition language126.

The data203that is unclean source data must first be parsed and scrubbed in the non-conformed staging tables802before moving into the conformed staging tables804. Adapters and APIs can be provided to parse the data203and kick out records that fail syntax verifications. The data203that is clean can flow directly into the conformed staging tables804. Table and database level verifications can be performed in the conformed staging tables804.

The ETL tool216routines, which move the data from the non-conformed staging tables802and the conformed staging tables804into the operational data store206, can be automatically generated. This process is described in greater detail with regard to steps806-824, below.

Initially, a retrieve step806can retrieve the data203as non-confirming source data. This can be in the form of a flat file; however, it is contemplated that the data can be in any useable form. As a flat file, the data203can be of a text string type of data203. The source data can include data203corresponding to the entities404and to modules406ofFIG. 4. As an example a source data in the non-conformed staging tables802can include a patient info flat file, which can correspond to a special module type holding non-longitudinal data for the entities404and entity types220ofFIG. 2.

The non-conformed staging tables802can further include module tables corresponding to the modules406and module types224ofFIG. 2. As an exemplary example the non-conformed staging tables802can include a cancer diagnosis flat file which corresponds to diagnosis module types224and a cancer diagnosis module406.

The data203in the non-conformed staging tables802corresponding to the modules406can include a foreign key pointing to the entities404with which they are associated. On the other hand, the data203in the non-conformed staging tables802corresponding to the entities404can include a primary key (such as patient ID) as a primary key for the entities404as well as the modules406specially created only to hold the non-longitudinal data for the entities404.

Coupled to the retrieve step806is a process step808. The process step808can collect and or organize the metadata302of the schema definition language126into choice type conformed stage tables810and choice conformed stage tables812. Each observed choice available from the schema definition language126can be placed in the choice type conformed stage tables810and can be assigned a primary key, and a choice type ID such as gender, ethnicity, ICD9, etc.

The choice conformed stage tables812can include a foreign key of the choice type conformed stage tables810and a primary key for each choice available. The choices might include male, female, Caucasian, Hispanic, Asian, 173.0-malignant . . . , 174.4-Paget's . . . , or 174.6-Neoplasm. A last date modified can also be included in the choice type conformed stage tables810and the choice conformed stage tables812. When performing an incremental load, the choices available can be from the operational data store206.

Coupled to the process step808is a conformed load step814. The conformed load step814can include the conformed staging tables804. Definitions contained within the metadata302of the schema definition language126for the modules406and the trait observations408ofFIG. 4stored within the metadata tables300, the schema definition model table500, or the schema definition model400can be used to determine how the data should be loaded into the conformed staging tables804. For example the metadata302may require the data type410ofFIG. 4to be a Date. In that case the data203extracted from the non-conformed staging tables802should be in the Date format when it is loaded into the conformed staging tables804.

The entities404contained within the non-conformed staging tables802can be loaded into the conformed staging tables804. Each row of the conformed staging tables804can include a single instance of the entities404. Each of the entities404is assigned a conformed staging table primary key. The entities404, which are sub-entities of the entities, will be loaded and given a pointer to the parent entity. For example patient may have had a sample taken therefrom. The sample will be considered a sub-entity and have a pointer back to the patient. The pointer can be the conformed staging table primary key of the patient. The entities404themselves and not the non-longitudinal data203, is first loaded into the conformed staging tables804.

Once the entities404are loaded into the conformed staging tables804, the data203associated with the modules406can be loaded into the conformed staging tables804. In the conformed load step814, the non-conformed staging tables802is opened and parsed.

As each row of the non-conformed staging tables802is processed, the conformed load step814converts the value of the data203to the target data type410, ensures non null trait observations408have a trait value, and verifies valid constraints for the trait observations408. When the constraints for the trait observations408is verified, value range constraints for dates and numeric trait observations408are verified, valid characters and valid lengths for text trait observations408are verified, and valid references to the entities404is verified. Verifying the validity of references to other modules406is performed during a second pass.

Any error during the conformed load step814causes the record associated with one of the modules406to be placed in an error table816. Each row that is successfully processed will be assigned a unique conformed staging table primary key. The conformed staging tables804can include a first row indicating the primary and foreign keys, a second row indicating the data type410of the column, and the third row can indicate the column names for the conformed staging tables804. The conformed staging tables804mirror the operational data store206schema with the exception that the trait observations408referencing other modules406.

The continuing with the flat file example described above, the flat file text values can be converted into the proper data type410. And references to the entities404are replaced with the conformed staging table primary key.

When a record fails the validity checks of the conformed load step814, the record can be placed into the error table816. For example if a record containing the non-longitudinal data203for the entities404includes an improper birth date the record can be placed in the error table816. Further, when the data corresponding to a module referencing the entities404in the error table816, the modules406record is also placed within the error table816.

Once the modules406are loaded into the conformed staging tables804in the conformed load step814, the references between the modules406can be updated in an update step818. The update step818, coupled to the conformed load step814, ensures proper dependencies for the modules406by including the references only after all the modules406are loaded into the conformed staging tables804.

The update step818can create two extra columns for each of the trait observations408that reference another module406within the staging tables804. The two extra columns can include the referenced module name as well as the referenced module foreign key. As an example, treatments refer to the diagnosis, the treatment trait observations408will include the additional columns treating diagnosis and treating diagnosis foreign key.

The columns including the referenced module foreign key can include the conformed staging table primary key of the referenced module406. At this point, any of the trait observations408referencing invalid, missing, or modules406in the error table816are deleted and placed within the error table816. The update step818can include adapters so that installations can insert their own, custom validation at this point in the process.

Couple to the update step818is an operational data store load step820. After the update step818the conformed staging tables804includes validated data. The operational data store load step820generates a SQL Server Merge statement for each of the conformed staging tables804. The operational data store load step820can generate the SQL Server Merge statement for the choice type conformed stage tables810, then the choice conformed stage tables812, then the conformed staging tables804including the entities404, then the conformed staging tables804including the entities404non-longitudinal data203, and finally the conformed staging tables804for the other modules406.

Since the data203within the conformed staging tables804is all verified, only environmental problems can cause the merge to fail. The environmental problems can include problems such as not enough disk space. If a merge does fail, the operational data store load step820logs the error and stops.

Coupled to the operational data store load step820is a delete step822. The delete step822applies during incremental loads into the operational data store206. During incremental loads, a delete flag is loaded into conformed staging tables804and the ODS. The delete step822validates that the record to be deleted does exist in the operational data store206. If the record to be deleted does not exist in the operational data store206, the record is routed to the error table816. Once the load is complete, the delete step822deletes the records having the delete flag with cascading to ensure referential integrity.

Coupled to the delete step822as a truncate step824. The truncate step824can truncate all the conformed staging tables804to prepare for a subsequent incremental load if the load was successful. Once the data203has been loaded into the operational data store206, users can fully utilize and access the data203using the Business Intelligence tools134ofFIG. 1described in greater detail below with regard toFIGS. 9-15.

Referring now toFIG. 9, therein is shown an exemplary control flow900for filtering a cohort according to an embodiment of the invention. The exemplary control flow900can be an exemplary illustration of how the filter128ofFIG. 1operates against the schema definition language126ofFIG. 1. The metadata302of the schema definition language126can be referenced from the metadata tables300ofFIG. 3, the schema definition model table500ofFIG. 5, the schema definition model400ofFIG. 4, or a combination thereof.

As soon as the operational data store206ofFIG. 2is populated, in the populate ODS step712, the Business Intelligence tools134ofFIG. 1are fully functional because they operate against the schema definition language126. When the operational data store206is populated a total cohort902will be available. The total cohort902can include all of the entities404ofFIG. 4represented within the operational data store206.

The total cohort902can be the starting point for filtering the operational data store206. The entities404of the total cohort902can be filtered using any of the trait observations408ofFIG. 4within schema definition language126. The trait observations408within the schema definition language126can be identified by the metadata302ofFIG. 3associated with the trait observations408.

In a select trait step904, which is coupled to the populate ODS step712, a user can select a selected trait905. The selected trait905can be one of the trait observations408. As an extension of the healthcare examples utilized above, a user may want to determine a patient class of the entities404with an ICD9 diagnosis for breast cancer.

The Business Intelligence tools134return, from the schema definition language126, all trait observations408such as valid ICD9 choices. The User could select one of the trait observations408as the selected trait905and further filter the selected trait905, such as selecting the ICD9 traits and filtering them for only the ICD9 codes that correspond to breast cancer.

After the user selects the selected trait905with which to filter the total cohort902, the Business Intelligence tools134can query the schema definition language126for the modules406ofFIG. 4and entities404associated with the selected trait905in a query metadata step906. The schema definition language126query can return the metadata302about the modules406, entities404, and other trait observations408related to the selected trait905. Further, the modules406and entities404associated with the selected trait905can be identified within the physical data tables218ofFIG. 2. The Business Intelligence tools134can further return the entity types220and module types224ofFIG. 2associated with the selected trait905.

After the schema definition language126is queried an associate trait step908, coupled to the query metadata step906, can return the modules406and the entities404from the schema definition language126that are associated with the selected trait905. If the selected trait905is only associated with the entities404, no modules406are associated with the selected trait905and only the entities404are returned.

With the return of the entities404and modules406associated with the selected trait905, a calculate step910, coupled to the associate trait step908, can calculate a current cohort912and all one-hop linkages914. When the calculate step910calculates the current cohort912, the schema definition language126can be used to locate the physical tables218of the operational data store206that correspond to patients having the selected trait905.

A query can be generated based on the metadata302of the schema definition language126to extract the data203ofFIG. 2of the entities404associated with the selected trait905. The calculate step910can automatically generate SQL instructions915to query the physical tables218and return the current cohort912associated with the selected trait905by locating the links608and physical tables602ofFIG. 6of the trait observations408, modules406, and entities404. The schema definition language126can be referenced as the metadata tables300which can be used to find the columns for each of the physical data tables218where the data203is physically located.

The Business Intelligence tools134can return the current cohort912as a number of the entities404that are associated with the selected trait905. The calculate step910can also calculate the one-hop linkages914and present them as selection options to the user to further refine the filter128.

The one-hop linkages914can be the other unselected trait observations408that correspond to the entities404and modules406that the selected trait905correspond to. That is, the one-hop linkages914are unselected traits from the same modules406and entities404that the selected trait observations408are associated with. Along with calculating unselected traits, the calculate step910can also return the modules406and entities404as one-hop linkages914. When the modules406and entities404associated with the selected trait905are pointed to by other unassociated modules406or entities404, these unassociated modules406or entities404can be returned as one-hop linkages914. That is to say, when the target entity type512ofFIG. 5or the target module type514ofFIG. 5for any trait observations408include a data pointer to the modules406or entities404associated with the selected trait905, the modules406and entities404associated with the trait observations408having the data pointer will be returned as one-hop linkages914.

To illustrate the calculation of the one-hop linkages914utilizing the example of filtering based on breast cancer, the calculate step910can calculate the one-hop linkages914for the entities404associated with the selected trait905such as age, gender, weight, and other non-longitudinal trait observations408corresponding to the entities404. The calculate step910can further calculate the one-hop linkages914for the modules406associated with the selected trait905such as date of diagnosis, age at diagnosis, primary site, or other longitudinal trait observations408corresponding to the modules406.

The calculate step910can also return the one-hop linkages914of other modules406or entities404unassociated with the selected trait905. For example, if the trait observation408selected by the user included an ICD9 for breast cancer, the ICD9 trait corresponds to a diagnosis module and the calculate step910can then return an option to the user to filter with a treatment because the treatment module includes a pointer in the target module type514to the diagnosis module.

Coupled to the calculate step910is a select another trait option916. If the user decides not to select more trait observations408, the select another trait option916will terminate the operation of the filter128in an end step918. When the end step918is invoked the current cohort912can still be utilized or saved for further use with the Business Intelligence tools134.

If the user decides in the select another trait option916to select another trait, a subsequent selected trait919can be selected in a select another trait step920coupled to the select another trait option916. The user can select the subsequent selected trait919in a similar manner to the way the user selected the selected trait905in the select trait step904.

One difference between the user's experience in the select another trait step920opposed to the select trait step904is that in the select another trait step920the user is given the one-hop linkages914as selection options and the current cohort912is displayed rather than the total cohort902.

Once the user selects the subsequent selected trait919, the subsequent selected trait919can be linked to the selected trait905in a link trait step922, coupled to the select another trait step920. The link trait step922can link the selected trait905to the subsequent selected trait919in order to refine the filter128and restrict the current cohort912. It is assumed that the subsequent selected trait919will restrict the current entities404or modules406of the filter128; however, it is contemplated that the user may override this logical AND operation and utilize a logical OR function for subsequent trait observations408.

As an illustrative example, the user might choose one of the one-hop linkages914corresponding to the entities404associated with the selected trait905like age 35-40 or male. Continuing with the ICD9 breast cancer example, the link trait step922would link the first selected ICD9 trait (the selected trait905) with the subsequently selected age or gender trait observations408(the subsequent selected trait919). The link trait step922would combine both the selected trait905and the subsequent selected trait919to further refine the filter128for only breast cancer diagnoses for patients between the age of 35-40 or that were male.

As a second illustrative example, the user might choose one of the one-hop linkages914corresponding to the modules406associated with the selected trait905like diagnosis date 2007. Continuing with the ICD9 breast cancer example, the link trait step922would link the first selected ICD9 trait (the selected trait905) with the subsequently selected date trait (the subsequent selected trait919). The link trait step922would combine both the selected trait905and the subsequent selected trait919to further refine the filter128for only breast cancer diagnoses in 2007.

As a third illustrative example, the user might choose one of the one-hop linkages914corresponding to linkages608to the modules406or trait observations408associated with the selected trait905like treatment type: surgery. Continuing with the ICD9 breast cancer example, the link trait step922would link the selected ICD9 trait (the selected trait905) with the subsequently selected pointer trait (the subsequent selected trait919). The link trait step922would combine both the selected trait905and the subsequent selected trait919to further refine the filter128for only breast cancer diagnoses treated by surgery.

The link trait step922is coupled to the query metadata step906. Once the user selects the subsequent selected trait919, and the selected trait905and subsequent selected trait919are linked in the link trait step922, the query metadata step906will query the schema definition language126in a similar manner to that discussed above.

Once the query metadata step906has queried the schema definition language126, the associate trait step908can operate in a similar manner to that described above with the exception that all selected trait905are used and operate like a logical AND function. Likewise, the calculate step910can calculate the one-hop linkages914for the subsequent selected trait919in a similar manner to that discussed above and return the current cohort912by utilizing the schema definition language126to query the physical tables218of the operational data store206in a similar manner as described above.

Referring now toFIG. 10, therein is shown a screenshot1000of the filter128as implemented in the Business Intelligence tools126. The screenshot1000depicts an example of the selected trait905linked to the subsequent selected trait919. The subsequent selected trait919can be linked to the selected trait905as a second trait observations408with which to filter the total cohort902. The link can represent a logical AND requirement; however, it is contemplated that the user may toggle the link icon to invoke a logical OR filtering of the total cohort902.

The total cohort902is shown as the starting cohort for the filter128. The selected trait905is shown to be an ICD9 value filtered for breast cancer. The selected trait905is linked contextually to the subsequent selected trait919.

The subsequent selected trait919is shown to be a diagnosis date that is filtered to return dates between Jan. 1, 2010 and Jan. 1, 2013. The current cohort912is depicted as a group of the entities404along with the number of the entities404within the current cohort912.

Referring now toFIG. 11, therein is shown an exemplary control flow1100for filtering a cohort utilizing a pattern according to an embodiment of the invention. The exemplary control flow1100can be another or further exemplary illustration of how the filter128ofFIG. 1operates against the schema definition language126ofFIG. 1. The metadata302of the schema definition language126can be referenced by utilizing the metadata tables300ofFIG. 3, the schema definition model table500ofFIG. 5, the schema definition model400ofFIG. 4, or a combination thereof.

This presents yet another method for identifying classes of the entities404ofFIG. 4and by scanning the operational data store206ofFIG. 2, looking for entities404who match a particular series of trait observations408ofFIG. 4that correspond to clinical events. Users can select trait observations408, as the selected trait905, to define clinical patterns and use the Business Intelligence tools134ofFIG. 1to identify the entities404who match the clinical pattern and who do not match the clinical pattern.

When the operational data store206is populated a total cohort902ofFIG. 9will be available. The total cohort902can include all of the entities404represented within the operational data store206. The control flow1100can operate from the total cohort902or from the current cohort912calculated by the calculate step910. In this illustrative example, the calculate step910providing the current cohort912will be used to further refine the filter128by using the control flow1100for filtering the current cohort912based on a pattern.

Coupled to the calculate step910is a select trait step1102where trait observations408can be selected as the selected trait905. The trait observations408that a user can select include the one-hop linkages914but can also include unrelated trait observations408. Once the user selects the selected trait905, the Business Intelligence tools134will feed back the trait and the current cohort912in a show trait module1104coupled to the select trait step1102. The user then has the option of selecting another trait in a select option1106coupled to the show trait module1104. If the user does want to select more trait observations408the select option1106will bring the user to the select trait step1102and the user can select a subsequent trait. In this way the user can select trait observations408that correspond to clinical events and define a pattern with which to restrict the filter128.

Continuing with the health care field example utilized above, suppose a user wishes to identify which appendectomy patients were readmitted to the hospital within 30 days of discharge. The user can select the trait observations408for appendectomy and the Business Intelligence tools134tools can finds all entities404who had an appendectomy utilizing the control flow900ofFIG. 9. Once all the entities404correlated with the appendectomy trait observations408have been identified in the current cohort912, the user can create a new clinical pattern beginning in select trait step1102. The user can select the trait observations408for a hospital discharge followed by the trait observations408for a hospital admission. The trait observations408for the hospital admission can be restricted by the trait observations408indicating that the admission occurred within 30 days of the discharge. This example clinical pattern would involve selecting two trait observations408(discharge and admission) coupled with selecting a restriction on the one-hop linkages914for a maximum of 30 days apart. As mentioned above, the one-hop linkages914are unselected trait observations408belonging to the same modules406ofFIG. 4or entities404associated with the selected trait905.

The user saves the pattern with the name—“Appendectomy readmits within 30 days”.

If the user has defined the clinical pattern by selecting the trait observations408that correspond to a clinical pattern, the user can select a calculate matches step1108as well as save the clinical pattern. The calculate matches step1108is coupled to a query metadata step1110that references the schema definition language126to determine the links608ofFIG. 6and the location of the physical tables218ofFIG. 2that contain the selected traits905.

The query metadata step1110is coupled to a generate SQL step1112. The generate SQL step1112can utilize the relationships and locations of the physical tables218returned from the schema definition language126in the query metadata step1110to automatically generate SQL instructions1114to query the physical tables218of the operational data store206.

A run SQL step1116, coupled to the generate SQL step1112, can run the SQL instructions1114automatically generated from the generate SQL step1112to query the physical tables218of the operational data store206. Coupled to the run SQL step1116is a return step1118. The return step1118can return a matching cohort1120and a non-matching cohort1122.

The matching cohort1120can be the entities404that correspond to the selected trait905as a clinical pattern. The non-matching cohort1122can be the entities404that do not correspond to the selected trait905as a clinical pattern.

The matching cohort1120and the non-matching cohort1122can be saved for later processing or further restriction by the Business Intelligence tools134. When the return step1118returns the matching cohort1120, the user can view the details of the entities404within the matching cohort1120. For example, the user can view the IDs and the can view when the matches to the clinical pattern defined by the selected trait905occurred.

Referring now toFIG. 12, therein is shown a screenshot1200of the filter128ofFIG. 1as implemented in the Business Intelligence tools126ofFIG. 1. The screenshot1200depicts an example of the trait observations408. The trait observations408can be displayed for a user to select in a selection box1202.

The trait observations408that the user selects can be shown in a pattern box1204. The selected trait905along with the subsequent selected traits919can be shown linked together in the pattern box1204. The selected trait905can, for example, be a treatment or procedure filtered for an appendectomy.

A first subsequent selected trait1206can, for example, be a discharge. A second subsequent selected trait1208can be, for example, a readmission. A pattern filter1210can be included to restrict the return of the first subsequent selected trait1206and the second subsequent selected trait1208to less than 30 days of each instance of the trait observations408. In other words, the pattern filter1210can restrict the entities404ofFIG. 4returned to the entities404that had an appendectomy, were discharged, and were readmitted within thirty days of discharge.

Referring now toFIG. 13, therein is shown an exemplary control flow1300for generating a report according to an embodiment of the invention. The exemplary control flow1300can be an exemplary illustration of how the report data definition130ofFIG. 2operates against the schema definition language126ofFIG. 1. The metadata302of the schema definition language126can be referenced using the metadata tables300ofFIG. 3, the schema definition model table500ofFIG. 5, the schema definition model400ofFIG. 4, or a combination thereof.

Once the operational data store206ofFIG. 2is populated, users are able to report on any of the entities404ofFIG. 4within the operational data store206. The users can define the report data returned. The Business Intelligence tools134ofFIG. 1utilize the metadata302of the schema definition language126to construct the report data definition130defined in terms of the entities404, modules406, and trait observations408ofFIG. 4. The Business Intelligence tools134executes the report data definition130to extract the data203ofFIG. 2from the operational data store206and presents the results through one or more spreadsheets. Users also view and summarize the spreadsheet data through various report viewers described below in greater detail with regard toFIG. 15.

The report data definition130is initiated in a start report step1302. The start report step1302includes the current cohort912, which the report data definition130can operate against. It is contemplated that the total cohort902ofFIG. 9, matching cohort1120ofFIG. 11, or even the non-matching cohort1122ofFIG. 11can be used by the report data definition130to operate against; however, for the sake of illustration, the current cohort912is shown.

Coupled to the start report step1302is a define data step1304. The define data step1304includes the report data definition130. The report data definition130specifies which entities404and trait observations408are to be included in a report1308. The report data definition130includes the default entities404and trait observations408. The default entities404are the current cohort912(or any currently selected cohort), while the default trait observations408are the entities404IDs and the trait observations408used to select the entities404as described above in greater detail with regard toFIGS. 9 and 11.

Once the report data definition130is created and defined with the default trait observations408and entities404the user has the option to modify the report data definition130in a modify option1309coupled to the define data step1304. If the user wishes to change the report data definition130a modify entity option1310or a modify trait option1312, coupled to the modify option1309can be selected.

If either the modify entity option1310or the modify trait option1312are selected by the user, the schema definition language126will be referenced by the Business Intelligence tools134. When the user selects to modify the entities404within the report data definition130, the user will select the modify entity option1310.

If the user decides to modify the entities404by adding an entity a reference step1314will reference the schema definition language126and determine all the links608ofFIG. 6to other entities404, this is especially important when adding entities404that are sub entities of the current cohort912. The links608are determined in a link step1316coupled to the reference step1314.

Once the links608are determined between the additional entities404and the previous entities404the one-hop linkages914ofFIG. 9are calculated in a calculate step1318. The one-hop linkages914can be the trait observations408that correspond to the newly selected entities404. That is, the one-hop linkages914are trait observations408the newly added entities404are associated with. The modules406can also be returned as one-hop linkages914. When the newly added entities404are pointed to by other modules406or entities404or, in the alternative, when the newly added entities404point to other modules406or entities404, these pointed at or pointed to modules406or entities404can be returned as one-hop linkages914.

The calculate step1318is coupled to a display step1320that can display options1322. When entities404are appended, added, or linked to the report data definition130the user will be provided with the options1322. The options1322include longitudinal options, such as first, last or all observations. The options1322can further include filtering options, such as filtering based on the type of trait included in the report. The filtering options will only keep results which meet the filter criteria. The options1322further include constraint options, such as limiting, non-limiting. The constraint option semantics are equivalent to SQL inner joins vs. outer joins.

After the options1322have been provided to the user an update step1324will update the report data definition130with the newly required entities404and their links608to the current cohort912. When adding trait observations408to the report data definition130the Business Intelligence tools134utilize a similar flow.

When a user wishes to modify trait observations408that that the report1308will display the modify trait option1312can be selected. The Business Intelligence tools134will determine whether the trait observations408that the user wishes to add belong to modules406currently in the report data definition130within a determination option1326. If the modules406are not currently part of the report data definition130the reference step1314is used to reference the schema definition language126. The links608are calculated in the link step1316and finally the one-hop linkages914is calculated in the calculate step1318.

The one-hop linkages914can be the other unselected trait observations408that correspond to the entities404and modules406that the trait observations408added by the user correspond to. That is, the one-hop linkages914are un-added traits from the same modules406and entities404that the added trait observations408are associated with. Along with calculating un-added trait observations408, the calculate step1318can also return the modules406and entities404as one-hop linkages914. When the modules406and entities404associated with the selected trait905are pointed to by other unassociated modules406or entities404, these unassociated modules406or entities404can be returned as one-hop linkages914. That is to say, when the target entity type512or target module type514ofFIG. 5having any trait observations408that include a data pointer to the modules406or entities404associated with the trait observations408added by the user the modules406and entities404associated with the trait observations408having the data pointer will be returned as one-hop linkages914.

In a similar manner to the addition of the entities404described immediately above, the display step1320displays the options1322to the user. The options1322displayed when adding the entities404and the modules406can be the same; however, it is contemplated that additional options or options unique to the entities404or modules406can be displayed differently and dependent upon which is being added.

After the options1322have been provided to the user the update step1324will update the report data definition130with the newly required modules406and their links608to the current cohort912and the modules406therein. When the determination option1326is invoked and determines that the trait observations408are associated to modules406already within the report data definition130, the reference step1314simply references the schema definition language126and the link step1316determines the links608required for incorporating the trait observations408into the report data definition130.

If the trait observations408are associated with modules406already within the report data definition130the calculate step1318and the display step1320do not need to be invoked to calculate the one-hop linkages914or display the options1322. The update step1324can be invoked to update the report data definition130and return the user to the modify option1309.

Continuing from the ICD9 breast cancer example utilized above, the user may wish to report on quality trait observations408corresponding to molecular experiment modules406run on tumor sample entities404for cancer patients returned as the current cohort912, but stratified by the trait observations408indicating the type of breast cancer. Here, the user simply adds the trait observations408“Cel File Quality” and “Triple Negative” to the report data definition130. The schema definition language126is referenced to provide the links608for the breast cancer diagnosis trait observations408to their diagnosing tumor entities404and also properly link to the molecular experiment modules406run against these tumor entities404when adding the Cel File Quality trait observations408. Because the Triple Negative trait observations408are a member of the Cancer Diagnosis modules406already included within the report data definition130.

When the user no longer wishes to modify the report data definition130the user may execute the report within an execute step1328coupled to the modify option1309. The schema definition language126can be referenced to determine the location of the physical tables218within the operational data store206that contain the trait observations408, modules406, and entities404within the report data definition130by a reference schema step1330coupled to the execute step1328.

SQL instructions1332can be automatically generated by a generate SQL step1334coupled to the reference schema step1330. The SQL instructions1332can be generated based on the information gathered from the reference schema step1330because the location of the physical tables218and the links608therebetween for the data203requested can be determined from the schema definition language126.

Once the SQL instructions1332is run on the operational data store206, the report1308can be presented as a spreadsheet to the user in a presentation step1336, coupled to the generate SQL step1334. The report1308can be filtered, displayed and analyzed in a reporting step1338coupled to the presentation step1336. The reporting step1338is discussed in greater detail below with regard toFIG. 15.

As an example the reporting step1338can provide a pivot table reporting tool and prompt the user to populate the values and dimensions of the pivot table with the data203extracted with the report data definition130.

Referring now toFIG. 14, therein is shown a screenshot1400of the report data definition130ofFIG. 1as implemented in the Business Intelligence tools126ofFIG. 1. The screenshot1400depicts an example of the traits222along with the trait observations408correlated thereto.

The trait observations408included by default can include the patient ID and the trait observations408that were used to filter the entities404ofFIG. 4. As an illustrative example, the trait observations408that are the defaults in the screenshot1400are patient ID and ICD9.

To generate a report for a temporary cohort1402, a user may select other trait observations408that should be included for analysis. As an example, the user can select Cel File Quality and Triple Negative. As depicted, the Business Intelligence tools126can include the entities404corresponding to the newly added trait observations408.

For the trait observations408Cel File Quality the entities404Experiment and Sample can be added along with their corresponding trait observations408Experiment ID and Sample ID. As is further depicted the trait observations408for Triple Negative already have the modules406included by default. Specifically, cancer diagnosis was already included as the module406corresponding to the ICD9 trait observation408.

Referring now toFIG. 15, therein is shown a control flow1500for analyzing a report according to an embodiment of the invention. The control flow1500depicts a portion of the steps from the previous control flow1300ofFIG. 13with additional steps for analyzing the report1308ofFIG. 13.

As depicted a refine step1502can be coupled to a pull data step1504. The refine step1502and the pull data step1504can comprise the steps of the control flow1300. For example, the refine step1502can comprise the define data step1304, the modify option1309, the modify entity option1310, the modify trait option1312, the reference step1314, the link step1316, the calculate step1318, the display step1320, and the update step1324ofFIG. 13in order to refine or modify the report data definition130ofFIG. 1.

The pull data step1504can comprise the steps execute step1328, reference schema step1330, and generate SQL step1334ofFIG. 13to pull the data203ofFIG. 2within the report1308and display the report1308to a user. Once the report1308is pulled in the pull data step1504, a tool select step1506coupled to the pull data step1504can prompt the user to select an analysis tool1508.

The tool select step1506can include analysis tool selections such as ANOVA (One Way) tools, ANOVA (Two Way) tools, Contingency tools, Cox Regression tools, Cox Regression (Multiple Control Variables) tools, Kaplan Meier (Two Dates) tools, K-Means Clustering tools, LiMMA tools, Logistic Regression tools, Mann Whitney tools, One Sample t-test tools, and other analysis tools. Once the analysis tool1508is selected in the tool select step1506, the Business Intelligence tools134ofFIG. 1can prompt the user to select inputs required for the analysis tool1508to run. The inputs can be solicited within a prompt step1510coupled to the tool select step1506.

Once the user defines the inputs, the user maps the data203from the report1308to the inputs in a map step1512. Once the data203is mapped to the analysis tool1508inputs, the Business Intelligence tools134will execute the analysis and display the analysis to the user. Continuing with the ICD9 breast cancer example above, suppose the user wishes to compare and analyze survival time trait observations408ofFIG. 4for breast cancer patient entities404ofFIG. 4, grouped by the various treatment protocol trait observations408ofFIG. 4administered to the patient entities404. The user refines the report data definition130to include the trait observations408required to complete the analysis; namely—age at diagnosis trait observations408, survival time trait observations408, treatment protocol trait observations408and a flag trait observations408indicating whether the patient passed away from the breast cancer.

The report1308is pulled in the pull data step1504. The user can then select the analysis tool1508Cox Regression in the tool select step1506. The user maps the data203from the report1308the inputs in the map step1512and executes the analysis. The Business Intelligence tools134preforms the analysis and presents the results to the user in various formats such as a visual Kaplan Meier curve backed by a statistical comparison of each pair of treatment protocols.

Advantageously, embodiments of the invention provide techniques for providing a schema definition language at a higher level of abstraction and providing a platform to interface with the schema definition language to enable Business Intelligence tools to utilize an operational data store with lower cost, and shorter time frame. The schema definition language enables the Business Intelligence tools to operate at a higher level of abstraction so the tools no longer have to be changed when underlying database evolves. Database evolution is easy and non-disruptive when utilizing the schema definition language of the present invention.

The resulting processes and configurations are straightforward, cost-effective, uncomplicated, highly versatile, accurate, sensitive, and effective, and can be implemented by adapting known components for ready, efficient, and economical, application, and utilization.

Accordingly, the invention is intended to embrace all such alternatives, modifications, and variations, which fall within the scope of the included claims. All matters hithertofore set forth herein or shown in the accompanying drawings are to be interpreted in an illustrative and non-limiting sense.