Journal:A model for design and implementation of a laboratory information management system specific to molecular pathology laboratory operations

From LIMSWiki
Revision as of 16:43, 16 April 2022 by Shawndouglas (talk | contribs) (Saving and adding more.)
Jump to navigationJump to search
Full article title A model for design and implementation of a laboratory information management system specific to molecular pathology laboratory operations
Journal The Journal of Molecular Diagnostics
Author(s) Tomlinson, Eban; Goodman, Jennifer; Loftus, Margaret; Bitto, Stephen; Carpenter, Erica; Oddo, Richard; Judis, LuAnn; Ali, Shabab; Robinson, Wyatt E.; Carver, Miranda; Ganea, Mariana; McDonnell, Kristen; O'Neill, Diane; Starbuck, Jennifer; Johnson, Eric; Meister, Erik; Pohl, Jonathan; Spildener, Jessica; Shurtleff, Sheila; Sovie, Sheryl; Melendez, Cathleen; Krebs, Pamela; Riley, Jacquelyn D.; Wensel, Christine; Astbury, Caroline; Azzato, Elizabeth M.; Bosler, David S.; Brock, Jay E.; Cook, James R.; Cheng, Yu-Weu; Tu, Zheng J.; Cruise, M.; Henricks, Walter H.; Farkas, Daniel H.
Author affiliation(s) Semaphore Solutions, Cleveland Clinic
Primary contact Email: farkasd2 at ccf dot org
Year published 2022
Volume and issue S1525-1578(22)
Page(s) 00012-5
DOI 10.1016/j.jmoldx.2022.01.002
ISSN 1525-1578
Distribution license Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International
Website https://www.jmdjournal.org/article/S1525-1578(22)00012-5/fulltext
Download https://www.jmdjournal.org/action/showPdf?pii=S1525-1578%2822%2900012-5 (PDF)

Abstract

The Molecular Pathology Section of Cleveland Clinic (Cleveland, OH) has undergone enhancement of its testing portfolio and processes. An electronic- and paper-based data management system was replaced with a commercially available laboratory information management system (LIMS) solution, a separate bioinformatics platform, customized test-interpretation applications, a dedicated accessioning service, and a results-releasing solution. The LIMS solution manages complex workflows, large-scale data packets, and process automation. However, a customized approach was required for the LIMS since a survey of commercially available off-the-shelf (COTS) software solutions revealed none met the diverse and complex needs of Cleveland Clinic's molecular pathology service. The project utilized the expertise of clinical laboratorians, pathologists, genetics counselors, bioinformaticians, and systems analysts in partnering with software-engineering consultants to design and implement a solution. Concurrently, Agile software development best practices were formulated, which may be emulated for scalable and cost-effective laboratory-authored software.

Keywords: molecular pathology, laboratory information management system, LIMS, bioinformatics, software development, Agile-Scrum

Introduction

Data management needs in clinical molecular pathology laboratories differ in substantive ways from those in other clinical laboratories and anatomical pathology labs. [1,2,3,4] Conventional laboratory information systems (LISs) historically have not inherently supported the needs of molecular pathology laboratories to the extent that they have in other laboratory disciplines and operations. [2] Molecular pathology laboratories have often relied on a combination of manual methods, spreadsheets, and nonintegrated and/or modular software to meet data management and operational needs.

Such was the situation in the Molecular Pathology Section, Pathology & Laboratory Medicine Institute, Cleveland Clinic (Cleveland, OH) in early 2017. A revitalization and growth plan for the section—which included expansion of personnel, equipment, testing platforms, and test development—was undertaken. An improvement deemed fundamental to this re-invention process was a new laboratory information management system (LIMS) to reduce and eventually replace the outdated, largely paper- and electronic spreadsheet–based information and workflow management system.

While the overhaul of the laboratory service was substantial, the focus of this report is limited to a description of a replicable process for the modernization of information and workflow management specific to a clinical molecular pathology laboratory. The process employed a customer–vendor relationship. Out of necessity, the relationship was a partnership due to the complementary and nontechnical skill sets of each party. The overall goal was to digitize workflow based on paper and Excel (Microsoft, Redmond, WA) across a complex, multidisciplinary molecular pathology and cytogenomics clinical laboratory service. This digitization was accomplished through a custom-architected software solution.

This article describes a model for the design and implementation of a LIMS that meets the diverse information management needs of a full-service clinical molecular pathology laboratory, emphasizes the integral importance of a well-structured development process, and describes a novel application of modern software-based project management methods and third-party partnerships for building and deploying a LIMS suitable for a modern molecular pathology laboratory.

Materials and methods

Scope definition

The goal of the project was to deploy a LIMS to modernize data and workflow management of the clinical molecular pathology laboratory, including cytogenomics workflows. The project encompassed a complete overhaul of paper and electronic spreadsheet–based data handling methods into a comprehensive, integrated electronic platform. Objectives were identified to define the scope and focus priorities of the project:

  1. Design and implement an electronic information system to support the specialized requirements and workflow of a full-service clinical molecular pathology laboratory, and to fulfill needs unmet by conventional LISs.
  2. Support the range of clinical testing performed, including adult, pediatric, and somatic mutation detection in tumor tissues, blood, and bone marrow; chromosome analysis; germline genetic testing for diagnosis and/or carrier screening; and pharmacogenomics.
  3. Support the range of complex data management of analytical methods (and applications) in use, including polymerase chain reaction (PCR); reverse transcription polymerase chain reaction (RT-PCR); next-generation sequencing (NGS); B- and T-cell gene rearrangement (PCR + capillary electrophoresis); chromosomal microarray analysis; fluorescence in situ hybridization (FISH); cytogenetic testing; and (genotyping by) mass spectrometry.
  4. Integrate into the information technology (IT) environment of the institution for accessioning and resulting, particularly the electronic health record (EHR) system and the conventional clinical laboratory and anatomical pathology information systems. (More specifically, Cleveland Clinic was using Sunquest Laboratory version 7.2 [Sunquest Information Systems, Tucson, AZ] and CoPathPlus version 2014 [Cerner, N. Kansas City, MO] at the time, but these are now in the process of being replaced by Epic Beaker version November 2020 [Epic Systems, Verona, WI].)

Needs assessment and partner selection

Given the complexity and multifaceted nature of the project, two key needs were recognized: professional project management guided by domain expertise in molecular testing laboratories, and experienced and expert software development professionals who could bring to bear state-of-the-art software development tools and techniques. Between two and four software developers were dedicated to the project at various stages. One business-based quality assurance analyst was included, who served as the conduit for the translation of laboratory-specific requirements into software requirements. A Ph.D.-level molecular biologist with project management expertise was hired to apply process rigor and organization to direct LIMS development and implementation (among other projects). [5] Laboratory-based personnel participated in their various subject matter domains as their primary responsibilities to patient care allowed. Partnership with a team of software engineers was established. This team worked with molecular pathologists and laboratory personnel (subject matter experts) to design and build the full software solution. Peer-to-peer relationships were formed between the clinical laboratory project manager and software project managers as control points for the project.

Prior to the beginning of this extensive development project, due diligence was undertaken to evaluate whether, or to what extent, commercially available information systems could meet the needs at hand. This assessment indicated that some systems on the market could provide some of the functional requirements, and that development entirely from scratch was not required. NGS–centric LIMS software was selected for licensure (BaseSpace Clarity LIMS by Illumina, San Diego, CA). As licensed, this software was focused narrowly on supporting particular elements of NGS workflows. Its distinguishing characteristics were customizability and extensibility that could ultimately support the objectives of the laboratory, including a wide portfolio of molecular diagnostics tests performed and the need for systems integration. Compatibility with the third-party commercial bioinformatics software that the laboratory had previously chosen (Clinical Genomics Workspace version 6.15.1 by PierianDx, Creve Couer, MO) was another key deciding criterion.

Technology platforms and software tools

The software engineering team used Jira and Confluence web-based software (Atlassian, San Francisco, CA) to organize development tasks and to project documentation, respectively. Version control was implemented in the web-based GitHub software host (San Francisco, CA). A continuous-integration pipeline (Table 1) was built using TeamCity software version 2019.1 (JetBrains, Prague, Czech Republic). The PyCharm version 2019.1 (JetBrains), Docker Desktop Community version 2.1.0.5 (Docker, Palo Alto, CA), VirtualBox version 6.1 (Oracle, Austin, TX), and Postman version 8.1 (Postman, San Francisco, CA) software solutions were used to facilitate local testing and development.

Table 1. Definitions of terms for the Agile-Scrum software development method applied.
Term Definition
Stakeholders The group of individuals who work with, and would be impacted by, the software system being developed (i.e., laboratory and medical directors, laboratory managers, laboratory supervisors, medical/laboratory technologists, pathologists, geneticists, bioinformaticians, staff scientists, clinical systems analysts, and a revolving cast from the larger Cleveland Clinic information-technology group).
Agile project management A system of practice to manage project delivery using an iterative approach. Optimization is achieved via continuous releases that include changes based on stakeholder review at each iteration. The process is useful for addressing highly complex problems in a mechanistic, incremental way.
Scrum Agile framework that encourages cross-functional team progress through short, measured iterations. Each problem is addressed in focused iterations called sprints, in which engineering management and build practices are used for addressing the complexity at hand. Outcomes are predicted and control of risk is assessed incrementally and via empirical observation.
LIMS workflow Clinical laboratory test workflows have three components: i) pre-analytical, ii) analytical, and iii) post-analytical. A LIMS, or other supporting software, digitally models test workflows, storing and classifying large volumes of laboratory workflow data, while also automating laborious, repetitive workflow tasks that risk compounding human error. The term "LIMS workflow" alludes to customized, digital workflow models that span the pre-analytical, analytical, and post-analytical stages.
External program plug-in (EPP) A Clarity LIMS–specific term that refers to a standalone script file accessible within the LIMS to perform calculations, transformations, or integrations too complex or cumbersome to configure within the LIMS itself.
Application programming interface (API) Software intermediary that serves to connect multiple applications, allowing them to exchange information. An API dictates what information can be sent and received by a given application and may add security restrictions. It also abstracts underlying code when interacting with other software. An analogy is a person (application A) ordering at a restaurant (application B); the menu represents the API.
Continuous integration (CI) pipeline The practice of automating the grouping of changes (typically software code, but also software build pipelines and automated tests) from multiple contributors into a single software project; this is software industry best practice, allowing developers to incorporate code changes into a central repository where builds and tests can be run more frequently and easily.
Development environment System in which new features are actively developed.
Test environment System in which newly developed features are tested. User-acceptance testing occurs in this environment; if the test fails, the software goes back to development, and if it passes, it is promoted to staging.
Staging environment System used for validating changes prior to promotion to production. The system should mirror production in all ways except those new changes to be tested.
Production environment The active system processing patient samples. This environment processes protected health information (PHI) and needs to be treated in accordance with HIPAA regulations.

Python (Python Software Foundation, Wilmington, DE), a popular, general-purpose, high-level programming language with well-documented, well-supported engineering standards, was used to develop external program plug-ins, automated test scripts, report templates, and other services. A report-generation and sign-out application named AVRO (analytically validated reporting object; see subsequent sections) was built on a Python server with an Angular JavaScript front-end. For LIMS workflows, the open-source Python S4-Clarity library[1] was used to support batch-analyte data (spreadsheet-formatted) parsing, laboratory instrument integrations, complex library pooling, de-multiplexing, and other computations on analytes. The Jinja web-based template engine library[2] was used for default report-content templating to support clinical interpretation and clinical report generation in AVRO.

Project management

The general project management process used was Agile-Scrum in Jira, chosen by the owner of the critical path for project completion (i.e., the software development team). In the project, Agile-Scrum was supplemented with additional roles and processes tailored to work in the hybrid clinical laboratory service/software development consultant environment. It became obvious that definitions and vocabulary differed between these two groups of subject matter experts (i.e., clinical laboratory and software engineering professionals). Selected terms are defined in Table 1. Key roles and activities of the Agile-Scrum development process, as applied in this project, are described in the next subsection.

Key roles

Four key roles corresponding to major development and validation phases were identified as gatekeepers of the development process. These gatekeepers controlled the promotion of a deliverable through the process and, thus, control of a rapidly evolving process was retained. The subject matter experts in these roles worked in tight collaboration to ensure that the highest possible quality was achieved. Note that at relevant steps, bioinformatics professionals, Ph.D.-level laboratory director-designees, and/or M.D.-level pathologists reviewed and approved changes as appropriate.

Key Role 1: Business Analyst (Extant within Software Development Team)

The business analyst assumed responsibility and accountability for the elicitation and decomposition of requirements into granular requirements that were logically defined and complete. This work output was added to the stakeholder consensus process.

Key Role 2: Software Development Team

The software development team was the consumer of approved granular requirements and the developer of software designed to meet those requirements. This team was involved in developing automated tests to validate that the software written did in fact meet the granular requirements as specified. This work output was collected into a release candidate and, upon passing the automated tests, was released into Phase 3, user acceptance testing. This team was self-organizing and chose the Scrum framework to align themselves into two-week iterations (.e., sprints).

Key Role 3: Clinical Systems Analyst (Extant within Laboratory Team)

The clinical systems analyst served as the first round of testing for the laboratory service, owing to the proximity of the role to the laboratory and to the expertise in the laboratory's process and informatics architecture. The work assigned to this role was to coordinate and, in some cases, to perform the tasks in development/validation (Phase 3), user acceptance testing. The output of this work was a pass/fail decision that either sent the release candidate back to development or promoted the release candidate to staging.

Key Role 4: Laboratory Manager

The laboratory manager signed documentation approving the release candidate for promotion to the production environment after review of successful pre-production runs that were performed using test samples in the laboratory and after verification that all test plans and checklists were completed.

Key activities

The major phases of software development and validation are shown in Figure 1. All activities were coordinated utilizing a series of modular processes that worked together to produce a performant and validated software installation consisting of licensed software, configuration of that software, and customized software to supplement the licensed software (e.g., AVRO and the Health Level 7 (HL7) version 2.3 [Health Level Seven International, Ann Arbor, MI] interface.)


Fig1 Tomlinson JofMolDiag2022 S1525-1578-22.jpg

Figure 1. Representation of the four major phases of software validation and development.

The highest-order process consisted of four development/validation phases:

  • Phase 1: Identify requirements and group them into architecturally independent release candidates logically small enough to enable rapid development (requirements elicitation).
  • Phase 2: Monitor and facilitate the development of automated testing and peer-review process on release candidates (software development).
  • Phase 3: Coordinate the promotion of release candidates from the development environment to the testing environment (user acceptance testing).
  • Phase 4: Coordinate the promotion of the release candidate from the testing environment to the staging environment for preproduction run, and subsequently to the production in silico environments in such a way as to avoid patient-care impacts (preproduction runs, progression to user-accepted version, and deployment).

Development/Validation Phase 1: Requirements elicitation

The project consumed hundreds of person hours in elicitation meetings, the goals of which were to:

  1. Establish the location of relevant domain knowledge.
  2. Establish detailed requirements and shared terminology.
  3. Achieve stakeholder group consensus on each granular requirement.
  4. Promote granular requirements to the approved backlog of work.

Translation of end-user system functionality into workable development items was a task shared between the laboratory and software teams. The laboratory team solicited input from subject matter experts and prepared documentation. The software business analyst then used that documentation to produce software development work items that fulfilled the final system requirements specified by the laboratory team. System requirements documentation included written requirements, text-based documents, logic tables (e.g., user-role permission maps, diagrams, and flowcharts), spreadsheets, native-instrument data files, laboratory standard operating procedures, and test validation plans.

Software deliverables were detailed and tracked in Jira. Laboratory objectives were described in common language, then passed to the software team for decomposition. Software development tasks were identified during decomposition and completed by the software team using Scrum. The percentage of completion reports for each objective were tracked using Jira and reviewed weekly by the joint project management group. Impediments to progress were identified and delegated to the appropriate team members for resolution. Common impediments included:

  • language ambiguity of requirements,
  • technical difficulty in mapping laboratory requirements to the software, and
  • requirements without a test plan or for which generating a test plan to be used in practice was challenging.

Development/Validation Phase 2: Software development

Software development proceeded in two-week iteration cycles (sprints). Members of the clinical laboratory and software engineering teams continuously evaluated and improved the software development processes throughout the project. The teams incorporated the requirements of the Health Insurance Portability and Accountability Act (HIPAA) to ensure that protected health information was handled appropriately. For example, scripting of mock samples was developed with convincing, yet mock, data. This scripting enabled the engineering team to test the system in a realistic fashion without the use of patient information.

The engineering team adhered to the following technical process while working within sprints:

  1. A team member chose a development task from the approved requirements to work on during the current iteration (sprint backlog).
  2. Once completed, each development task was peer-reviewed by other software engineers prior to inclusion in the master codebase, an industry-standard quality assurance practice.
  3. Automated tests were generated during development and run before and after each development task was committed to the master codebase, to identify problems in the task and in the integration of the task into the codebase, respectively. Automated tests generally consisted of scripts that generated representative mock samples and utilized the Clarity LIMS application programming interface to move those mock samples through the workflow while replicating user interaction at each step, again using the API.
  4. When the development of a full software deliverable was completed (release candidate), it was assembled atop all previous deliverables on a replica LIMS (test server).
  5. The release candidate was tested for both successful and potentially erroneous scenarios, in accordance with the requirement specification(s).

Development/Validation Phase 3: User acceptance testing

In Phase 3 of software validation, functional testing was performed by the laboratory team and led by the clinical systems analyst, who reported results and discrepancies back to the software team at each stage for collaborative triage. A go/no-go decision was made based on the severity of the discrepancy and the viability of a workaround being utilized until the next release candidate could be deployed. Discrepancies were addressed by the software team in order of priority and redeployed through reiteration of the above process.

Development/Validation Phase 4: Preproduction runs, progression to user-accepted version, and deployment

The following process was used for preproduction runs, progression to user-accepted version, and deployment:

  1. After all tests were passed, the software vendor deployed the validated release candidate to the staging environment of the laboratory.
  2. Successful execution of the user acceptance testing phase triggered full system–level preproduction runs by laboratory personnel in the staging environment.
  3. Successful preproduction run completion was followed by scheduled deployment of the release candidate to the production environment, which, in some cases, constituted several releases at once.
  4. Full deployment was facilitated jointly by software and laboratory IT personnel. Full system–level tests, as well as preproduction run checklists and end-to-end testing scripts, were utilized to validate the performant nature of the final deployment(s).

Results

System design: Workflow analysis and support

The LIMS organizes and handles the workflows of the clinical laboratory, from specimen accessioning through to laboratory analysis and issuing reports to ordering physicians. The system also coordinates tasks among staff. The LIMS automates several laboratory processes, such as spreadsheet parsing or container tracking, and is compatible with laboratory instrumentation, such as automated liquid handlers and quality control instruments, either through an off-the-shelf or custom-built integration. Substantial customized LIMS workflow design and engineering were required to model the testing procedures of the laboratory and to organize the constituent processes, including sample accessioning, nucleic acid (i.e., DNA, RNA, or total nucleic acid) purification, direct PCR testing, genotyping by mass spectrometry, sequencing, chromosome testing, data analysis, and all associated quality control steps.

A key project requirement was organization and refinement of workflows within the LIMS. Wherever possible, shared processes were identified and excluded from test-specific workflow building. For example, sample accessioning and DNA extraction were built out as shared protocols. Templating (sharing) at the step and protocol layers were combined with unique elements to generate end-to-end workflows specific to each test.

The LIMS was engineered to support the build of workflows in a hierarchical fashion in which workflows contain protocols which, in turn, contain steps (Table 2). In steps, the work of the end user is performed, on either a single sample or a batch of samples. Protocols are a collection of steps organized around the standard operating procedures of a laboratory, and workflows comprise the protocols required to execute a test. Custom-built workflows are shown in Table 3.

Table 2. Test component organization.
LIMS component Example Scope
Step DNA extraction Single wet laboratory process contained in a single work session, in one physical location
Protocol Sample extraction Collection of steps that facilitate one stage of the workflow
Workflow Fragile X carrier screening End-to-end sample processing, from accessioning to report issuance
Table 3. Shared workflow components. Indicates universally shared component. Note that pre-analytics was able to be shared across all workflows, while sample preparation extraction was shared, but only within the MDx group of tests.
LIMS workflow Workflow components
Cytogenetics (CytoG) Pre-analytics > (CytoG) wet laboratory sample extraction > wet laboratory analysis > clinical reporting > long-term data archiving
Chromosomal microarray (CMA) Pre-analytics > (CMA) wet laboratory sample preparation > wet laboratory analysis > clinical reporting > long-term data archiving
Carrier screening Pre-analytics > sample preparation extraction > (carrier screening) wet laboratory analysis (per test code) > clinical reporting > MDx long-term data archiving
Molecular diagnostics (MDx) Preanalytics > samplepreparation extraction > wet laboratory analysis (per test code) > clinical reporting > MDx long-term data archiving

System features and integration

LIS–HL7 interface for sample accessioning

LIS applications typically connect to other patient health care applications such as health insurance policy administration systems and EHRs. [6] To function effectively, an LIS must be interoperable with these health care record systems through the adoption of a common standard. [2] The HL7 standard was utilized as the form of communication between the LIS and the LIMS through a customized interface (Figure 2).


Fig2 Tomlinson JofMolDiag2022 S1525-1578-22.jpg

Figure 2. A laboratory information management system (LIMS) supports clinical laboratory test workflows, systems interfacing, and traceability by classifying and storing laboratory workflow data like accessioning, pre-analytics, analytical wet bench, and analytical interpretation paired to clinical interpretation (i.e., results reporting). Traceability refers to the record keeping in each of the systems shown above (i.e., data received, sent, and transformed, that happen in between). AVRO, analytically validated reporting object; EPP, external program plug-in; LIS, laboratory information system. CoPathPlus, Cerner (N. Kansas City, MO); Epic Beaker version November 2020, Epic Systems (Verona, WI); HL7, Health Level Seven International version 2.3, Health Level Seven International (Ann Arbor, MI); Sunquest software version 7.2, Sunquest Information Systems (Tucson, AZ).

The interface between the existing Sunquest Laboratory and CoPathPlus LISs of the laboratory and the new LIMS streamlined the flow of patient data received from the health care record systems into sample accessioning. A customized HL7 listener service was built and configured to interface with the LIS. This service verifies whether the HL7 message received is valid and, if so, generates a sample with all required sample information fields and accessions it directly into the LIMS. Required sample fields including, but not limited to, medical record number, last name, and collection date are extracted from the HL7 message and mapped to user-defined LIMS fields to preserve vital information for mapping test results to the correct patient downstream. The original inbound HL7 message was preserved on the sample to resolve any ambiguous data mapping in the LIMS. Error logs are generated for review when HL7 messages either cannot be processed or produce errors.

The LIS application was integrated with the HL7 interface while its essential functionality and interoperable links were preserved. After software build, the LISs still collected and organized patient health care data. However, software management of the clinical test workflows and process automation were improved with LIMS implementation.

Instrumentation

Integration with nucleic acid purification robotics and spectrophotometers (pre-analytical) and molecular diagnostics–related analytical platforms were facilitated through file transfer systems built on shared network locations. Integrations followed the same process:

  1. A plate map was generated and displayed to laboratory personnel at the appropriate LIMS workflow step.
  2. After the requisite samples were plated and the instrument completed its full cycle, an output file was directed to a shared network location available at each LIMS workstation.
  3. Laboratory personnel uploaded the output file to the appropriate (usually next) step in the LIMS workflow.
  4. An external program plug-in parsed data from the output file and saved discrete pieces to user-defined fields on the sample in the LIMS.

Clinical reporting application

To address the ultimate goal of every high-complexity clinical laboratory test (i.e., the issuance of a patient report for the physician who ordered the test), the customized AVRO was built. AVRO serves as an interface to manage the interpretation (post-analytical) component of laboratory test workflows. AVRO utilizes the authentication system of the LIMS, and therefore only LIMS users with the correct permission setting can access AVRO. AVRO runs on its own server, links directly to the LIMS, and polls specific steps to import reporting objects. It then determines which report template to assign based on the test code and displays test data to professional staff reviewers. This reporting application generates standards-compliant clinical reports for annotation and sign-out by molecular pathology professional staff. Upon sign-out, AVRO sends text reports to the automated clinical results–releasing service, which submits HL7-formatted data and issues a text-based copy of the report to the appropriate recipient.

AVRO was designed and implemented to harmonize results reporting and formatting within a dynamic multicomponent system of EMRs and LISs (Epic Beaker, Sunquest Laboratory, CoPathPlus, and Rhapsody version 6.6 [Lyniate, Boston, MA]) while maintaining a flexible LIMS configuration. (Rhapsody is an interface engine that sits between Epic and ancillary systems, e.g., Sunquest Laboratory, CoPathPlus.) Given that report fields are populated directly from LIMS user-defined fields, all LIMS data are available to the report template. Using Jinja2 Python templating enabled a programmatic approach to reporting (i.e., rules can be applied to text and data formatting). AVRO uses the LIMS application data layer and the LIMS-managed user credentials that can be integrated with Lightweight Directory Access Protocol (LDAP) systems to support data provenance and added security. This approach obviated the architectural generation of a separate database and the duplication of user credentials. AVRO thus facilitates professional actions on samples that exist entirely within the LIMS.

The concept of report-based content defaults was identified from feedback after early implementations had been tested by the reporting professional staff. Reporting templates were customized for each test and then served the correct template by mapping test codes to those templates. Templates could be mapped to multiple test codes and were maintained independently for maximum flexibility in content.

Opening a report in AVRO presents a template based on the above logic, populated with interpretation text derived from the results interpretation code applied in the analysis portion of the workflow. The molecular pathologist user is able to modify and customize all of the populated content prior to sign-out. At any point during the report-building process, AVRO allows the user to preview the report.

A customized results–releasing service was built into the LIMS as a set of external program plug-ins for report release. This step was designed such that the system monitors for newly signed-out reports in AVRO every 30 seconds via the AVRO API. The report is generated and sent back to the LIS, and then the report file(s) are attached to the completed step in the LIMS.

Audit trails were available as base functionality in the LIMS and did not require customization. Building AVRO atop the audit trail data layer facilitated auditing through the reporting process up until submission of the outbound HL7 message. HIPAA compliance as implemented in the LIMS thus persisted through the reporting process, an efficiency afforded by leveraging of the existing software validation work extant in the off-the-shelf product. The LIMS tracks all of the elements specified by audit trail-related items per the College of American Pathologists Laboratory General Accreditation Checklist.

Resulting end-to-end software solution

References

  1. Semaphore Solutions (6 April 2021). "SemaphoreSolutions / s4-clarity-lib". GitHub. https://github.com/SemaphoreSolutions/s4-clarity-lib. Retrieved 04 August 2021. 
  2. Ronacher, A. (18 May 2021). "pallets / jinja". GitHub. https://github.com/pallets/jinja. Retrieved 04 August 2021. 

Notes

This presentation is faithful to the original, with only a few minor changes to presentation, grammar, and punctuation. In some cases important information was missing from the references, and that information was added. Everything else remains true to the original article, per the "NoDerivatives" portion of the distribution license.