The registration function as a critical dependency in a lifetime clinical record (LCR)

Over the past two years, we have successfully migrated the Regenstrief Clinical Information System into our hospital. Integral to this process was the need to develop interfaces and processes supporting movements of patient identification data between the existing clinical management system (Unity, SMS) and Carebase (RCIS). Critical to the implementation of Carebase was the development of an interface between Carebase and the registration system based upon a unique medical record number. Even more critical was the development of stable processes that supported the accurate patient identification and assignment of medical record numbers. The medical record number at our institution is assigned or verified at the time of registration. Major problems occurred when patients presented during system down-times and existing medical record numbers could not be accessed, resulting in multiple registrations and medical record numbers for the same patient. This resulted in data fragmentation and required merging at a later date. Other more serious problems resulted from the assignment of the same medical record number to separate patients and with the mixing of data from multiple patients into one patient record. This was largely due to the failure of clerical personnel to appropriately identify patients at the time of registration, or multiple patients sharing identification documents, a common problem in our geographic area. Given that clinical data was to be maintained and added to the repository for several decades, errors such as these in registration would prove catastrophic. The interfaces between the various clinical systems that pass data to Carebase are all HL-standard and largely prevent data passage if registration data is inaccurate. During the early stages of implementation, approximately 300 exceptions per day were generated from clinical systems attempting to pass data to the repository. Following re¿engineering of the registration process, education of clerical personnel, and analysis of exception type, the number of exceptions due to faulty registration data fell to less than one per week. To achieve improvement in exception volume, several innovative measures were undertaken. Firstly, down-time procedures were changed to require query of the LCR for existing registration data. The LCR was maintained on a separate platform that experienced essentially no down-time and was available for this purpose. This largely eliminated the need for the use of "down-time numbers" or medical record numbers that could be temporarily assigned to patients registered when the registration system was unavailable (data would subsequently be merged into existing patient records if the patient was found to be currently in the system). If the patient was not in the LCR, then a permanent number was assigned in sequence. A registration dataset was developed and encoded onto a magnetic card (Carecard, Eltrax) and carried by patients. This enabled the rapid verification of registration data on subsequent visits to the parent institution or affiliated clinical sites. The issue of fraudulent use of the card and encoded registration dataset, however, remained problematic. Currently, a new imaging system is being installed that will soon enable the inclusion of a photograph of the patient as a component of the registration dataset. Perhaps the most significant change in the registration process involved the education of central registration and admitting personnel. An educational program was developed that reinforced the need for accuracy in collecting registration data, identifying patients, and assigning medical record numbers; more importantly, it stressed the linkage of the registration function and patient care. Lastly, an aggressive approach to monitoring exceptions resulting from errors in registration was developed. A near real-time process for identifying errors in registrations allowed for rapid intervention and feedback to involved de