Simplicity
The OpenLDR is designed to be simple to use and to understand. It is also designed to be simple to update (either directly from the LIMS database into the SQL repository database, or via an HL7 interface).
To attain this simplicity, the designers of the LDR have adopted a minimalistic approach. The initial design has only three data tables support by a limited number of dictionary (code lookup) tables. Where codes are used, the design includes both standardized codes and LIMS vendor codes; both were accommodated so the LDR can be used to produce meaningful reports using either of these without first requiring LIMS data mappings to be completed other than for facility code mappings. Where LIMS vendor codes are used, LIMS vendor descriptions are also provided for. This means that there is no need to maintain LIMS vendor code-lookup dictionaries. The drawback to this design decision is that the data is not as compact as it could be - in technical terms, it is not fully normalized - but we feel the benefits to the ease of use and understanding are worth the trade-off.
The names of tables and columns have been carefully chosen and are mostly in-line with the names chosen within the HL7 standard. The names include the standards they refer to - for example HL7SexCode. This will simplify the task of a LIMS vendor in developing an HL7 interface to OpenLDR. This also simplifies the task of documenting the OpenLDR, as the majority of definitions already exist within the HL7 standard - and only the exceptions are documented within the OpenLDR specification (see annexures).
Report Oriented
OpenLDR is designed in such a way that it can be used with a variety of SQL based tools in a straightforward manner. Many reports can be run against a single table or database view. SQL based reporting tools available include
Raw SQL commands (e.g from within SQL server management studio)
Spreadsheets, e.g. MS-Excel and Open-Office
Report writers e.g. SAP Crystal Reports, MS SQL Reporting Services (SSRS),
Cognos Impromptu (see http://stackoverflow.com/questions/18952/what-is-yourreporting-tool-of-choice)
Geographical Information System (GIS) tools e.g. Crystal Report Maps, ArcGIS.
Anonymous Patient Data
OpenLDR does not hold any Patient identifiers. This allows the LDR to be used by various authorized parties with compromising patient confidentiality. However, should the need arise to know who the patient is (for example if a patient follow up is required by a health professional as a result of an analysis of the data), Open LDR does contain the laboratory reference number to allow the user to go to the laboratory and request them to identify the actual patient from within their own laboratory database. This places the onus of data privacy on the laboratory - where it was in the first place.
Based on International Standards
The following standards have been chosen for OpenLDR
SI Units of reporting
HL7 Messages (v2.5) for updating the LDR and for most codes within the messages
LOINC identifiers for laboratory test
Latin names for Organisms
English generic names for drugs
ICD10 and ICD-M for disease coding and morphology.
Note that the chosen OpenLDR standards are included in the standards supported by the Unified Medical Language System (UMLS) developed by the U.S National Library of Medicine. With regard to drug and organism names, OpenLDR follows the LOINC recommendations. SNOMEDCT is not included in the OpenLDR desgin at this stage because of associated licensing costs.
Useful at both central and local levels / Work with standardized and/or LIMS vendor code sets
The OpenLDR has been designed such that it can be used at a local level (e.g. single laboratory facility), national level (e.g. Health Department data repository) or super-national level (e.g. in support of the East Africa Public Health Laboratory Networking Project (EAPHLNP)). At a local level, the OpenLDR can be used without mapping to standardized codes - that is to say, reports can be created using vendor specific codes. If the data needs to be aggregated from multiple LIMS vendors, codes will have to be mapped as part of the data loading process. However, even if codes are not mapped, the data can still be usefully extracted, provided that the appropriate vendor codes are known. For example, if a report is required on HIV results, as long as the person creating the report knows all the vendor codes for the HIV test and for its result, it is still possible to produce a unified report. As part of making the OpenLDR usable at all levels, the design keeps both standardized raw data and the LIMS specific "as reported" data, and it is thus possible to re-create laboratory reports which, apart from patient identifiers, are exactly the same as the original result issued. As stated earlier, this duplicate storage of raw and coded versions of data is considered as minimal impact when compared to the flexibility it brings.