The Requests table represents the Observation Request, Patient Identity and Patient visit segments (OBR/PID/PV1) of the HL7 message. Some fields from the Observation (OBX) are also include to allow laboratory management reports (such as workload and TAT) to be derived directly from this table.
Required fields versus Desirable fields: The database table requirements regarding which columns are required are minimal. This was done in order to make sending data into the system as easy as possible for smaller systems which might not collect large amounts of data about each interaction. However, in order to make the data useful for analysis there are some fields that are considered highly "desirable" and it is hoped the data providers will provide as many fields as possible. Please also refer to the pages that discuss the additional registration data for Viral Load related data and how that data is stored. Those data elements are all highly desirable to collect but fall under a slightly different structure when they are submitted to the LDR.
Unique Identifiers (RequestID, LIMS, LabIdentifier, LIMSVendorCode)
The RequestID is intended to be a unique identifier for a specimen in the system. Combined with the OBRSetID denotes a panel of tests assigned to specimen within a LIMS and the two make up the unique key for the Request table. The four character LIMS portion of the RequestID is used in case multiple LIMS systems in the country reuse the LabIdentifier portion of the RequestID. A vendor may coordinate the LabIdentifier portion throughout the entire country; for example by including a “lab prefix” or “identifier” built into that portion of the code. In that case they could use the same LIMS from lab to lab. If the unique lab identifier portion is not coordinated between laboratories then the four digit LIMS code within the RequestID will need to be used for that.
LIMSVendorCode identifies a specific LIMS system configuration that is the source of the data. Within a country this helps uniquely identify LIMS configurations that may use different codes internally such as ReceivingLabCode and TestingLabCode. Other codes specific to a LIMS implementation could also be combined with this code to do LIMS specific lookups. The combination of LIMSVendorCode/ReceivingLabCode or LIMSVendorCode/TestingLabCode are used to join to the Laboratories table to find information about a laboratory. In the future this functionality could be extended for use with the LIMSPanelCode and LIMSObservationCodes. This lowers the burden of the LDR managers coordinating unique code between data providers. While this is convenient for Panel and Observation codes a better use of normalizing those codes is to use the universal LOINC values when reporting or looking up information.
FacilityCodes and LabCodes
The May 2018 changes to the FacilityCode columns helps more precisely identify laboratories rather then the more general and official FacilityCodes.
Most of the OpenLDR installations are running V1 so the FacilityCode columns have not been updated to the more precise naming conventions.
LIMSRequestingFacilityCode (previously LIMSFacilityCode);
LIMSReceivingLabCode (previously ReceivingFacilityCode)
LIMSTestingLabCode (previously TestingFacilityCode)
LabCodes join to the Laboratories table using these columns plus the LIMSVendorCode column.