Please note that as of 17-May-18 changes have been proposed to the way FacilityCodes are stored in the LDR. We hope to have these changes finalized and the website updated by the end of May 2018.
The OpenLDR is not a software package, it is a set of guidelines for implementing a centralized repository for laboratory related data. With that in mind, here are the key steps discussed in detail if you want to create an implementation. Creating the actual databases is only a small part of the process; what's more important is understanding and coordinating how to populate the data. The rest of the this website has a lot of information about the data; this page will bring up some of the most important issues to get you started.
This page is only an overview of the most important aspects of getting started with the OpenLDR. Each of these points has additional pages elsewhere on the website with more detail.
Database creation scripts
Basic scripts supplied
Coordinating Important data elements between data providers
Planning the values for identifying tests and other important information
Required data elements
What data elements are required for reporting
Populating list of Facilities and Healthcare Areas
Coordination of Facility Codes and populating reference tables
Getting data into the OpenLDR
Decide on the best method to get data into your OpenLDR
Database creation scripts
SQL Create OpenLDRData.sql
SQL Create OpenLDRDict.sql
These two scripts (attached to this page) create the database and table structure for the two databases which make up the OpenLDR. There are not currently any views included in these scripts but other pages on this website supply examples of data extraction views, table joins and useful functions. The general concept behind the views is similar from implementation to implementation but each country's views are slightly different.
Understanding and Coordinating Important data elements
Some data elements have suggested formatting and others need coordinated between data providers for uniqueness reasons.
RequestID - {Country(2)+LIMS(4)+LabIdentifier(20)}
As stated elsewhere in the system the RequestID is very close to a unique Specimen identifier in the system. The RequestID along with the OBRSetID/LIMSPanelCode uniquely identify a group of tests to be performed on a specimen.
The RequestID is a unique identifier for database and must be unique between systems. For that reason the suggestion is to make it a multi-component string.
Two digit country code
LIMS identifier. There are two different thoughts on this. This helps make the code unique between data providers (e.g. LIMS). For a LIMS system that first centralizes all of it's results and then sends the data to the LDR this might simply be a code identifying the LIMS manufacturer, like DISA for DisaLab, LBWR for LabWare, GXAL for Gene Expert Alert, etc. However, the important part is to help with uniqueness so if multiple LIMS with the same manufacturer are sending in the similar LabIdentifier components the LIMS identifier can help make it more unique by actually putting in facility identifier or unique lab identifier in there.
The LabIdentifier is a unique code often used within the LIMS or data system supplying the data. Some LIMS may even have their own structure for this identifier; e.g. they may put a three character code at the beginning to identify the laboratory or lab section first receiving the specimen.
There is another column in the Requests tables named LIMSSpecimenID. Some data providers have the need to provide their own internal ID for trace-backs and later validation. This could be the LabIdentifier or it could be something else that's internal to the data provider system.
The Requests table can have multiple rows with the same RequestID but they must have different OBRSetIDs and thus LIMSPanelCodes.
LIMSPanelCode/LIMSObservationCode (and OBRSetID)
OBRSetID is an internal id used to join from Requests to LabResults but it also uniquely identifies different groups of tests requests (Panels). While OBRSetID resets for each RequestID, the actual group of tests requested is specified in the LIMSPanelCode column. LIMSPanelDesc is a longer test description of the LIMSPanelCode
As an administrator for the LIMS it's important to coordinate the LIMSPanelCodes different data providers are sending. It's okay if they send different codes for the same or similar panels but you don't want them to use the same code for two different groups of tests; that just makes things more difficult.
LIMSObservationCode / LIMSObservationDesc
These are columns in the LabResults table and they uniquely identify a data element that describes the outcome of a Request/OBRSetID (and thus RequestID/LIMSPanelCode). Normally it's easiest to think of these as uniquely identify a row in the database that's an outcome or result of one of the requested tests related to the LIMSPanelCode. However, because of the amount of data the LIMSObservationCode really identifies a data element describing something about the Panel. It could be the test result but it could also be some other data element like the unit of measure or even hold some patient registration information that was submitted along with the test request. There is a lot more information about this with numerous examples on other pages on the website.
FacilityCodes
You will need to coordinate what each data provider is using to identify each facility. Ideally, everyone is using an official facility code identified by the Ministry of Health for each facility. However, this is seldom the case. Many LIMS systems will only send their own internal identifiers for facilities which are often different from the MOH official list. See the Facilities table discussion below for more information.
There are currently four facility code columns collected in the Requests table: RequestingFacilityCode, ReceivingFacilityCode, TestingFacilityCode, LIMSFacilityCode. Each of these is described in more detail elsewhere.
Required data elements
Very few of the actual columns are required to insert a record in the database but that doesn't mean the minimum fields will provide you with enough useful data to create reports.
Go through the list of reports you want to create and list the data elements you will need to create those reports. Then go through the list of columns specified in the OpenLDR tables. This will inform you as to which data elements you will need to require data providers to submit.
The OpenLDR specification has locations for a lot of data elements to be collected and a facility for flexibly collecting even more data elements. If there isn't an explicit column for a data element you need read the following page for a suggestion on how to store the data.
Facilities and HealthcareAreas tables
https://sites.google.com/site/openldr/design-documents/facilities-and-healthcareareas
These tables are reference tables for finding more information about facilities. The Requests table has four FacilityCode columns (RequestingFacilityCode, ReceivingFacilityCode, TestingFacilityCode, LIMSFacilityCode). Each of these columns can be joined to the Facilities.FacilityCode column. Keep in mind that the Facilities table could have more than one entry for the same facility. This allows one data provider to use a set of codes that's different from another data provider but when they join to the Facilities table they will find the same Facility Description and the same geographic identifiers. For example, you should have one listing for each facility that has the official MoH facility code in the FacilityCode column. Another entry for the same facility could have XYZ in the FacilityCode column because that's what vendor 1 has listed internally for that facility. A second data provider might send the official facility code. A third vendor might send ABC for that same facility code and thus you will need a third row in the Facilities table.
The Facilities table also has some useful columns to help coordinate and to use for tracking purposes. The MOHFacilityCode helps coordinate multiple codes for the same actual facility. For example, if three rows have different FacilityCodes but they all point to the same facility they will all have the same MoHFacilityCode value. This helps keep things aligned with the official facility list. There is also the possibility that a laboratory is not technically identified with the same FacilityCode as the facility where it is located; this is often the case but with bigger facilities they often have multiple laboratories under the same facility and need to distinguish between them. These laboratories will often be given their own pseudo FacilityCode but the official MoHFacilityCode can be found using the Facilities.MOHFacilityCode column. For this same reason there is a flag in the Facilities table to identify facilities that are truly only laboratories. IsLaboratory. This is primarily used for reporting where you want to list all possible Laboratories regardless of where they have submitted data that falls within the filter for the query or report. Another column to provide more flexibility for reporting is the ParentFacilityCode column so the user can group multiple facilities or laboratories under a single facility for data aggregation purposes. Typically, a laboratory entry row will be able to identify it's parent facility by the MoHFacilityCode, however, ParentFacilityCode gives another layer of possible aggregation.
There is another webpage that discusses the population and use of the HealthcareAreas table. This is the table used to identify geographic levels used for aggregations in reporting.
Please note that MoHFacilityCode, ParentFacilityCode and IsLaboratory are currently undergoing review to be added as standard columns in the OpenLDRDict.Facilities table.
Getting data into the OpenLDR
See the following page as a start towards data collection methodologies.
https://sites.google.com/site/openldr/design-documents/sending-data-to-the-ldr
Direct database inserts: One LIMS vendor is inserting their data directly into the OpenLDR database
MirthConnect standardized file import: There is a MirthConnect import channel that imports a file the conforms to a standard format
There are also individual efforts which use Mirth to import files of varying formats but we are trying to consolidate to a single file format if possible.
This is an evolving import channel and more functionality has been specified to be added in the future.
MirthConnect API channels: One country has developed web APIs to receive data and to send out data.
Security and Topology: Keep in mind that if you are sending files to the OpenLDR for Mirth or another process to import you will need to locate the server somewhere an external process can send the files. SFTP is a good option but there are many other. MirthConnect also has the option to provide an HTTP server or to go out and retrieve data via different protocols like SFTP or HTTP.
Reporting and Data Extracts
The current standard is that each country has been producing views that represent data for a specific program or reporting need. For example, there are views for general workload as well as views specific to TB and view specific to Viral Load. The web site has some more specifics on building some standardized views.
Many different styles of reporting have been used across different countries. Views extracted to Excel, Crystal Reports, and a few efforts at web based reporting and web dashboards. It's worth reviewing what's already been done in case it's possible to save yourself a lot of work by using similar views and slight changes to be specific to your implementation's specific LIMSPanelCode and LIMSObservationCode values.