Topic: Data Science
Podium Presentation in Room 3 on Wednesday at 11:40 (Chair: Will Slade)
Authors: Wesley Hampton, Brent Merryman, Elizabeth Spencer, Jade Wilson, David Vanlandingham, Dustin R. Bunch
Introduction: In a clinical laboratory, data is essential to driving business and properly managing the various resources of the department. Historically, getting the data necessary to perform these functions has not been structured or centralized. At our institution, laboratory data was retrieved from the laboratory informatics system primarily using a PC with Microsoft Access® (Redmond, Washington, USA). This solution performed well but lacked documentation, full institutional security measures, was reliant on an individual PC without redundancy and proper backup, and was largely developed and understood by a single individual. Herein we discuss the progress from a singular software solution towards multiple software packages to create a stable and secure data analytics pipeline.
Methods: Phase one identified all the Access programs currently supporting the operation of the laboratory. A program to search a network shared folder for all Access files was created that recorded the path, modification date, size and owner. Phase two was to analyze each program to identify inputs and outputs, the key stakeholders, and the downstream use of the data including additional dependent systems. Two central files were created to document and classify each application at a high level, containing information such as an identifying screenshot, the business impact, the purpose of the program, and any file and database dependencies. Interviews were conducted with stakeholders during this phase to understand the problem each program was intended to solve. The third phase, currently ongoing, is performed on a per-application basis informed by the identified priority and business impact from phase two. Key activities in this phase are more detailed interviews, identification of software that could replace the programs and the work involved in migrating to the new solution. Our team preferred solutions whereby a single new program could replace multiple Access programs.
Results: Close to 2,000 Access files were found present on the network servers, however, only 119 were determined to be actively in use. There were 3-5 stakeholders/file that required 1-3 hrs of meetings to determine best conversion options. The primary themes from the programs were reporting, workflow aids, QC/QA metrics, and automated resulting (e.g. mass spectrometry). Reporting needs were met with scheduled R scripts for any automated data extraction, Qlik for common and frequently asked questions (e.g. volumes, data exploration), R Shiny for real-time or highly interactive and custom needs, and Data Innovations to replace apps which were involved in lab transactions (orders/results) and QC/QA metrics.
Conclusion: While 35/119 of legacy applications have transitioned into the new software solution ecosystem 84/119 programs still require conversion. However, this solution created an architecture of structure and stability to convert the remaining programs and new use cases.
|Planning to mention or discuss specific products or technology of the company(ies) listed above:||