The data model was intentionally designed to be simple. Individual implementations are expected to extend the model with related table to enhance the data with more information and expand upon codes and data from the various data providers. Even though there are only two primary tables the way the data is provided and stored is worth more explanation. This page contains a basic introduction to the tables but you should also refer to the following pages to learn more about the relationships between the data in the Requests and LabResults tables.
https://sites.google.com/site/openldr/design-documents/sending-data-to-the-ldr
Requests
(Table: Requests)
This table holds all relevant data related to a laboratory test request. This table is very similar to the HL7 OBR segment, but it also contains demographic fields from the HL7 PID, PV1 and PV2 segments. In designing the requests table, it was noted that each tests request form carries the patient's demographics - however, since laboratories often (usually?) do not see the patients, and since the data for the same patient may vary on subsequent requests. In these cases the laboratory has no way of knowing which of the two is correct (it may be neither) and so it needs to act on the information on the request form; e.g. the laboratory reports normal ranges based on age and sex as specified on the request form - and once a report has been released, the demographics and results that depend on this should not change. Common LIMS data models are usually either "patient-centric", "sample-centric" or "request-centric". OpenLDR has chosen a request centric model and keeps the history of these demographics is stored with each request. In practice, and because the OpenLDR has no patient identifiers, there is very little overhead in not having a "Master Patient Index" - Thus, instead of creating data hierarchy with patients at the apex, OpenLDR has requests at the apex and each request carries the "demographics as at the time of request".
OpenLDR does, however, allow requests from the same patient to be "linked" via a "Match Key", which the LIMS provider may optionally provide. This allows for other LIMS system designs to be accommodated (patient-centric, sample-centric and request-centric).
Results
(Table: LabResults)
The results table holds the results of all the test requests. A result may be for a single item, such as a Potassium result, or the test may comprise multiple items such as a Complete Blood Count. Results are identified by both LOINC codes and LIMS vendor codes. Results may be either numerical or coded values or text. For numerical values, the results and reference ranges must be converted to SI units at the time of loading into the results table and stored as floating point numbers. The value, as printed on thereport by the LIMS, is stored as text. These may be the cutoff value e.g. ">10.00", whereas internally, the value may be 11.5. The units, reference ranges and flags, as printed on the report are also stored as text. Thus, the full result, as printed on the report, can be re-recreated although no calculations can be done on them. By contrast, the results in SI units are able to be used for research and calculations, but cannot be used to reproduce the report exactly. The abnormality flags are stored as per the HL7 standard.
For coded values, the LIMS code is stored, as well as the full text description.
Text results are stored as text. Text may comprise multiple lines, as allowed by the HL7 OBX segment. Text is marked with an indicator as to whether the text is a result or commentary/notes.
Dates and times of testing and reviewing are kept. Provision is made for Work Units and Cost Units in order to allow workload and cost calculations, but these are not used at present.
Monitoring
(Table: Monitoring)
The Monitoring table has two functions. Firstly it contains the results all the organism identified by the Microbiology department, and if drug sensitivities were determined, it contains their results. This information is not stored in the result table. Secondly, it contains the results of items identified in the surveillance dictionaries. This information is included in the results table, but is repeated here for ease of reporting for surveillance requirements.