The data model was designed to be minimal and simplistic. The objective is to make it easy to insert data and for anyone to use the data model for analysis. Because this is not an "on-line" database it can take certain design liberties, such as de-normalization of data, to make it easy to understand. The tables have been separated into two distinct groups. "Data" tables contain the actual test request and test result data and are stored in a database instance named OpenLDRData. "Dictionary" tables hold the standardized lists and coded information used for look-ups and supplemental information and are stored in a database instance named OpenLDRDict. This separation into separate database instances is not strictly necessary but allows for more flexibility in data storage.
The column names within the tables have been chosen to be descriptive, and where they refer to a coding system, the name is prefixed by the coding system acronym. The data model also provides for the coding system used by specific LIMS implementations. These codes are prefixed by LIMS. The following are the coding system prefixes used
Flexibility
The table design takes into consideration the need to receive data from many different sources without requiring the data be coded to some standard. If the LIMS provider does not have all of their tests and results codified to a standard (e.g. LOINC) the data can still be stored in the columns identified as data being provided directly from a LIMS (the raw LIMS data). The organization managing the OpenLDR can then decide where to put efforts towards standardization; whether it be helping all the data providers codify their data the same or whether they want to write their own method of resolving codification differences.