OpenELIS 3.1 (In Development)
The following features are scheduled for development. Each represents a significant enhancement to laboratory operations, data management, or system usability.
Clinical and Order Management
Lab Notebook (OGC-53)
Status: In Progress | Priority: Highest
A comprehensive digital lab notebook system that allows laboratory staff to document procedures, observations, and notes directly within OpenELIS. This feature addresses the common need for laboratories to maintain detailed records of laboratory activities beyond standard test results.
Key capabilities:
Real-time documentation of laboratory procedures and observations
Searchable and auditable record-keeping
Integration with existing orders and test workflows
Structured note templates for consistency across staff
Why this matters: Laboratories frequently need to document quality control observations, unusual sample conditions, equipment maintenance notes, and procedural deviations. Currently, this information often lives in paper notebooks or separate systems, making it difficult to correlate with specific orders or retrieve during audits. The Lab Notebook brings this critical documentation into the primary laboratory system where it can be properly associated, searched, and audited.
Add Diagnoses to Lab Order (OGC-50)
Status: In Progress | Priority: High
Enables clinicians and order entry staff to include provisional clinical diagnoses and clinical notes when submitting laboratory orders. This information helps laboratory staff understand the clinical context and prioritize appropriately.
Features include:
Provisional Clinical Diagnosis field (free text)
Notes from Clinician field (free text)
Optional file attachments for clinical documentation
Fields appear on the Program page during order entry
Why this matters: Clinical context significantly impacts how laboratory staff approach testing, particularly for complex cases. Pathologists need diagnostic information to properly evaluate specimens. Quality control staff can better validate results when they understand the clinical picture. This feature closes the communication gap between clinical and laboratory teams.
Configurable Sample Sub-Options / Tags (OGC-51)
Status: Community To Do | Priority: Medium
A flexible tagging system for sample metadata that can be configured through the data dictionary. Allows laboratories to capture and track sample-specific conditions that affect testing or interpretation.
Configurable tags include:
Fasting status
Pregnancy status
Timed collections
Custom laboratory-defined tags
Why this matters: Different laboratories track different sample conditions based on their testing menu and clinical requirements. A rigid set of fields cannot accommodate this variability. The tag-based approach allows each laboratory to define exactly what sample information they need to track, making OpenELIS adaptable to diverse laboratory workflows without custom code changes.
Sample Management and Processing
Sample Aliquoting (OGC-54)
Status: In Progress | Priority: High
Comprehensive sample splitting and aliquoting functionality that allows technicians to divide original samples into multiple aliquots, each with tracked volumes and assigned tests.
Core features:
Volume tracking on the Add Order page, Sample tab
New "Sample" menu item (accessible to results entry role)
Search by Order Number or Sample ID
Display of Sample ID, Type, Collection Date/Time, Collector, Volume
Split sample functionality:
Specify number of aliquots
Assign volumes to each aliquot
Assign specific tests to each aliquot
Print labels for aliquots
Future: Location assignment within storage
Why this matters: Many laboratory workflows require dividing samples for different types of testing, storage, or reference laboratory submission. Without proper aliquoting support, laboratories use workarounds that break the chain of custody, make sample tracking difficult, and create opportunities for errors. This feature provides a structured approach to sample subdivision that maintains traceability and supports complex testing algorithms.
Sample Storage Management (OGC-60)
Status: In Progress | Priority: High
A comprehensive system for tracking sample storage locations, conditions, and lifecycle from collection through disposal. Links storage requirements defined in the test catalog to actual sample handling and monitoring.
Test Catalog Enhancements:
Storage Conditions field (e.g., 2-8°C, -20°C, room temperature)
Storage Duration (maximum time before testing)
Disposal Method (e.g., biohazard incineration, chemical deactivation)
Disposal Timeframe (e.g., within 7 days after testing)
Special Instructions (e.g., light protection, avoid freeze/thaw)
Version History for storage/disposal instruction changes
Order Entry Features:
Display of storage requirements for selected tests
Ability to override storage instructions (with required justification)
Audit trail of all storage-related modifications
Role-based permissions for overrides
Why this matters: Proper sample storage is critical for result accuracy and laboratory safety. Many laboratories struggle to track storage requirements, particularly when managing hundreds of different test types with varying needs. This feature ensures that storage requirements are documented at the test level and communicated to staff handling samples. The override capability with audit trail allows for exceptional circumstances while maintaining accountability.
Additional Storage and Disposal Information (OGC-48)
Status: Community To Do | Priority: Medium
Expands the sample handling documentation beyond basic storage to include comprehensive preservation, safety, and disposal information.
Enhanced fields:
Detailed preservation methods
Safety precautions for sample handling
Regulatory compliance information
Links to waste management protocols
Special handling requirements
Why this matters: Regulatory compliance for sample storage and disposal is increasingly complex, with requirements varying by sample type, test, and jurisdiction. This feature ensures that all handling requirements are documented, communicated to appropriate staff, and followed consistently. It's particularly important for laboratories pursuing accreditation or operating in highly regulated environments.
Box of Samples for Referral (OGC-14)
Status: Community To Do | Priority: Medium
Creates a structured workflow for assembling samples that will be sent to reference laboratories, including packaging lists, tracking, and status management.
Functionality:
Create sample shipment containers/boxes
Add samples to boxes by scanning or selection
Generate packing lists and shipping labels
Track box status (prepared, shipped, received)
Documentation of shipping conditions and couriers
Why this matters: Most laboratories regularly send samples to reference facilities for specialized testing. Managing these referrals manually leads to lost samples, unclear tracking, and difficulty following up on results. A structured box management system ensures that every sample sent to a reference laboratory is properly documented, tracked, and can be reconciled when results return.
Quality Control and Compliance
Westguard Rules Dashboard for Analyzers (OGC-41)
Status: In Progress | Priority: Medium
An automated quality control monitoring system that applies Westguard rules to analyzer quality control data and provides visual dashboards for compliance tracking.
Dashboard features:
Overview of compliance status with color-coded indicators (Green: compliant, Yellow: warning, Red: non-compliant)
Instrument-specific cards showing:
Current compliance status
Triggered rules
Latest data point timestamp
Interactive Levey-Jennings charts with:
Westgard rule limits overlaid
Highlighted violations
Drill-down capability for details
Trend graphs with filtering options
Real-time alerts via email and system notifications
Corrective action logs and task assignments
Why this matters: Quality control monitoring is time-consuming when done manually, and violations can be missed or addressed too late. Automated Westguard rule checking catches quality control failures immediately, preventing the release of potentially inaccurate results. The dashboard provides at-a-glance visibility into instrument performance across the entire laboratory, helping supervisors identify patterns and allocate resources effectively.
External Quality Assurance Module (OGC-61)
Status: Community To Do | Priority: Medium
A dedicated module for managing external quality assurance (proficiency testing) programs, including sample tracking, result submission, and performance reporting.
Expected features:
EQA sample registration and tracking
Integration with major EQA providers
Result entry and submission workflows
Performance tracking and trending
Automated reporting of EQA results
Management of corrective actions for failed proficiency tests
Why this matters: External quality assurance participation is mandatory for most accredited laboratories, but managing EQA samples often requires manual processes outside the main LIS. This creates opportunities for samples to be mishandled or results to be submitted late. A dedicated EQA module ensures proficiency testing is managed with the same rigor as routine samples and provides visibility into laboratory performance over time.
Data Interoperability and Integration
FHIR Interoperability Enhancements (OGC-19, 21, 22, 23)
Status: Backlog | Priority: Medium
A set of improvements to OpenELIS's FHIR capabilities that enable bi-directional data exchange and tighter integration with health information systems.
Components:
Two-Way FHIR Communication (OGC-22):
Accept incoming FHIR resources (patients, orders) from external systems
Synchronize changes from FHIR server back to OpenELIS data model
Support for FHIR subscriptions and notifications
FHIR Facade Investigation (OGC-23):
Evaluate architectural approaches for exposing OpenELIS data via FHIR
Assessment of direct FHIR implementation vs. facade pattern
Performance and maintainability considerations
Historical Data Pipeline (OGC-21):
Improved bulk transformation of existing OpenELIS data to FHIR format
Performance optimization for large datasets
Data quality validation during transformation
Tighter JPA Server Integration (OGC-19):
Reduce latency between OpenELIS operations and FHIR availability
Improved synchronization mechanisms
Enhanced error handling and recovery
Why this matters: FHIR is becoming the standard for health data exchange globally. While OpenELIS currently supports FHIR for outbound data sharing, true interoperability requires bi-directional exchange. These enhancements position OpenELIS to participate fully in health information exchanges, accept electronic orders from hospital systems, and serve as a data source for analytics platforms—all while maintaining data integrity and security.
Analyzer Interface and Mapping Improvements (OGC-5, 45, 49)
Status: In Progress | Priority: Medium
Enhancements to how OpenELIS connects with laboratory analyzers, making configuration more flexible and reducing the need for custom code.
Features:
User-Configurable Mapping (OGC-5):
GUI for mapping analyzer test codes to OpenELIS tests
No programming required for common analyzer integrations
Potential OpenFN integration for complex transformations
GeneXpert Testing Environment (OGC-45):
Dedicated VM infrastructure for testing GeneXpert interfaces
Both HL7 and ASTM protocol testing
Validation of test mapping and result flow
Result Select List Mappings (OGC-49):
Map analyzer categorical results to OpenELIS result select lists
Handle qualitative results (Positive/Negative, Detected/Not Detected)
Support for multiple result formats from different analyzers
Why this matters: Analyzer integration is one of the most time-consuming aspects of laboratory system implementation. Each analyzer may use different codes, formats, and protocols. Current integration often requires custom programming, making it expensive and slow. These improvements make analyzer connections more configurable, allowing laboratory staff to set up new analyzers without developer assistance. This dramatically reduces implementation time and cost.
System Usability and User Experience
Help Menu Overhaul (OGC-8)
Status: Complete | Priority: High
Comprehensive redesign of the help system to provide contextual, easily accessible documentation within the application.
Delivered features:
Help menu integration with user manual content
In-application access to documentation (no PDF download required)
Tutorial content for common workflows
Release notes accessible from the help menu
Why this matters: Traditional PDF user manuals are difficult to navigate and rarely consulted. By breaking documentation into logical sections and embedding it in the application, users can quickly find answers without leaving their workflow. This improves efficiency and reduces training burden.
Menu Simplification (OGC-17)
Status: Complete | Priority: Low
Streamlined navigation by removing unnecessary submenu layers for Pathology, IHC, and Cytology sections.
Changes:
Direct navigation to dashboards from main menu items
Reduced clicks required to access common functions
Simplified menu structure
Why this matters: Every extra click adds friction to daily workflows. For frequently accessed sections like Pathology, removing submenu navigation saves time for users who access these areas dozens of times per day.
Dashboard Filtering Improvements (OGC-16)
Status: Complete | Priority: Medium
Added "In Progress" filter to Pathology and Cytology dashboards, matching the functionality already available in Immunohistochemistry.
Filter options:
In Progress: Shows all work that is not yet complete
By specific workflow stage
All: Shows completed and in-progress work
Why this matters: Pathologists and cytotechnologists typically want to focus on work that requires attention, not cases that are already finalized. The "In Progress" filter reduces visual clutter and helps staff quickly identify what needs their attention. Having consistent filtering across all departments creates a more predictable user experience.
Technical Infrastructure
Code Base Refactoring (OGC-58)
Status: Backlog | Priority: Medium
Systematic restructuring of the OpenELIS codebase to improve maintainability, testability, and performance.
Focus areas:
Improved package structure and organization
Separation of concerns between layers
Reduction of code duplication
Enhanced modularity for easier feature development
Updated dependencies and removal of deprecated code
Why this matters: As OpenELIS has evolved, some areas of the codebase have become complex and difficult to maintain. Strategic refactoring makes the system easier for developers to understand and modify, reducing the time and cost to add new features. It also reduces the likelihood of bugs by making code behavior more predictable.
Enhanced Installation Experience (OGC-56)
Status: Backlog | Priority: Medium
Improvements to the installation process that provide better visibility into progress and make troubleshooting easier.
Features:
Real-time log display during installation
Progress indicators for long-running operations
Clear error messages with resolution guidance
Installation success verification
Why this matters: Installation problems are frustrating and time-consuming, particularly when the installer provides no feedback about what it's doing. Visible logs allow implementers to understand installation progress and quickly identify issues. This reduces support burden and improves the experience for sites deploying OpenELIS.
Visual Schema for Data Model (OGC-55)
Status: Backlog | Priority: Low
Creation of comprehensive visual documentation of the OpenELIS database schema, showing table relationships and key fields.
Deliverables:
Entity-relationship diagrams
Table documentation with field descriptions
Relationship documentation
Integration with developer documentation
Why this matters: Understanding the OpenELIS data model is essential for developers adding features, creating reports, or integrating with other systems. Visual schema documentation significantly reduces the time needed to understand data structures and relationships. This is particularly valuable for new developers joining the project or implementers creating custom reports.
Enhanced Logging (OGC-18)
Status: Backlog | Priority: Medium
Comprehensive expansion of logging throughout the application to improve troubleshooting and system monitoring.
Improvements:
Consistent logging patterns across all modules
Appropriate log levels (INFO, DEBUG, ERROR)
Performance-related logging for slow operations
Security event logging
Integration with log aggregation tools
Why this matters: When problems occur in production, detailed logs are essential for diagnosis. Insufficient logging forces support teams to reproduce issues in test environments or add logging and redeploy—both time-consuming approaches. Comprehensive logging allows most issues to be diagnosed from production logs alone, dramatically reducing problem resolution time.
Google Summer of Code 2025 Projects
OpenELIS Global is participating in Google Summer of Code 2025, with talented contributors working on significant enhancements across the platform. These projects represent important improvements to quality assurance, data interoperability, billing integration, and internationalization.
Improve Integration Tests Coverage
Contributor: TBD | Mentor: Herbert Yiga
Project Description:
Expand integration test coverage for the OpenELIS backend service layer to achieve at least 60% test coverage. Integration tests verify that different components of the system work together correctly, catching issues that unit tests might miss.
Expected Outcomes:
Comprehensive integration tests for service layer components
Achievement of 60% test coverage milestone
Documentation of testing patterns and best practices
Improved continuous integration pipeline
Reduced risk of undetected critical bugs
Required Skills: Java, Spring, JUnit
Why this matters: Higher test coverage reduces the likelihood of bugs reaching production and makes it safer to refactor and enhance the codebase. Integration tests specifically catch issues that arise from component interactions, which are common sources of subtle bugs in complex systems like OpenELIS. This work provides confidence that changes won't break existing functionality and helps maintain system reliability as the codebase evolves.
Add Support for OpenELIS to Use OCL for Data Dictionary
Contributor: Vishal Sharma | Mentor: Reagan Makoba
Project Description:
Enable OpenELIS to consume data dictionaries from Open Concept Lab (OCL), a terminology management system. This allows laboratories to import standardized test definitions, codes, and concepts rather than manually creating each entry. The project integrates OpenELIS with OCL's API to retrieve concept collections and automatically populate the test catalog.
Expected Outcomes:
Integration with OCL API for retrieving concept collections
Initializer for parsing OCL collections into OpenELIS format
Test catalog population from OCL sources
Support for updating definitions from OCL
Built-out test catalogs through using new initializer to parse new collections
Required Skills: React, TypeScript, Java, Spring, REST
Project Implementation:
The integration includes:
Automated synchronization of test definitions from OCL collections
Mapping of OCL concepts to OpenELIS test catalog structure
Support for LOINC codes and standard terminologies
Version control for concept updates from OCL
View demo video showing concepts being passed from OCL and added to OpenELIS.
Why this matters: Manual data dictionary creation is time-consuming and error-prone. Different laboratories often need the same test definitions, leading to duplicated effort. OCL integration enables laboratories to import standardized, community-maintained test definitions, dramatically reducing setup time and improving consistency across implementations. This facilitates the use of standard terminologies like LOINC, improving interoperability with other health information systems and supporting regulatory compliance requirements.
Integrate OpenELIS with Odoo (OpenERP)
Contributor: Vickabire | Mentor: Reagan Makoba
Project Description:
Create an integration layer between OpenELIS and Odoo (OpenERP) to support automated billing and financial management workflows. This enables laboratories to automatically generate invoices and track payments based on laboratory orders, eliminating manual billing processes.
Expected Outcomes:
Bidirectional integration between OpenELIS and Odoo
Automatic creation of invoices in Odoo when orders are finalized
Synchronization of patient and order data
Billing status visibility within OpenELIS
CSV-based test-to-product mapping for flexible pricing
Required Skills: React, TypeScript, Java, Spring, REST
Technical Architecture:
The integration uses a Service-Oriented Architecture (SOA) with clear separation of concerns:
OpenELIS (LIMS) → Integration Service → Odoo (ERP)Core Components:
OdooClient – Handles XML-RPC communication (authentication, CRUD operations, invoices)
OdooIntegrationService – Business logic for invoice creation
TestProductMapping – CSV-based test-to-product mapping for pricing
Event Handling – Uses Spring events for asynchronous processing
Key Features:
Automatic patient creation in Odoo if they don't exist
Duplicate prevention using national IDs or names
Error resilience – failures in Odoo don't stop OpenELIS operations
Externalized configuration via environment variables
Health check endpoint for monitoring integration status
Integration with odoo-initializer for automated Odoo configuration
Event-Driven Workflow:
Sample created in OpenELIS
Event fired:
SamplePatientUpdateDataCreatedOdooIntegrationService finds or creates patient in Odoo
Maps lab tests to Odoo products using CSV configuration
Invoice automatically created in Odoo
Benefits:
Automated Billing – invoices created instantly
Data Consistency – no mismatched records between systems
Operational Efficiency – reduced administrative work
Real-Time Financial Visibility – track revenue seamlessly
Scalability – flexible SOA design for future features
Why this matters: Many laboratories need to bill for services but lack integrated billing systems. Manual billing processes are error-prone, create reconciliation challenges, and require significant administrative time. Odoo integration provides laboratories with professional billing and accounting capabilities without requiring a separate laboratory billing system. This is particularly valuable for private laboratories and laboratories operating on cost-recovery models, where accurate and timely billing is essential for financial sustainability.
Add Support for Multiple Translation Languages via Transifex
Contributor: TBD | Mentor: Casey Iiams-Hauser
Project Description:
Expand OpenELIS language support beyond English and French by integrating with Transifex, a translation management platform. Spanish will serve as the initial use case, with the framework supporting additional languages in the future. OpenELIS has already integrated its codebase with Transifex to enable community-driven localization across 50+ languages.
Expected Outcomes:
Transifex integration for translation management
Spanish language support as proof of concept
Automated translation updates from Transifex
Framework for adding additional languages
Community translation contribution process
Support for backend, frontend, and concept dictionary translations
Required Skills: TypeScript, React
Translation Workflow:
The translation process is split into three main sources:
Backend translation strings – Built into backend modules with automatic synchronization from Transifex
Frontend translation strings – UI localization keys automatically synced from Transifex
Concept dictionary – Laboratory terminology and test names
How to Contribute Translations:
Sign up via OpenELIS Transifex project
Join the OpenMRS/OpenELIS translation team
Select a project and language to translate
Submit translations through the Transifex web interface
Reviewers approve translations for quality and accuracy
Key Features:
Web-based translation interface requiring no technical knowledge
Translation memory to maintain consistency
Context information to guide accurate translations
Review and approval workflow for quality assurance
Automatic synchronization of approved translations to OpenELIS releases
Why this matters: OpenELIS is deployed globally in countries with diverse languages. While the system currently supports English and French, many implementations need additional languages to serve their user communities effectively. Transifex integration enables community members worldwide to contribute translations without requiring technical knowledge or access to the source code. This democratizes the localization process, making it easier to support the full range of languages where OpenELIS is used. Spanish support will open OpenELIS to Latin American markets, and the framework established will enable rapid addition of other languages based on community needs. Improved usability for non-English speakers increases adoption and reduces training barriers in multilingual laboratory settings.
GSoC 2025 Timeline and Status
OpenELIS Global's participation in Google Summer of Code 2025 follows the standard GSoC timeline:
Community Bonding: May 8 - June 1, 2025 (Complete)
Coding Period: June 2 - August 25, 2025 (In Progress)
Midterm Evaluations: July 14-18, 2025 (Complete)
Final Evaluations: September 1-8, 2025 (Standard projects)
Extended Timeline Projects: Through November 17, 2025
All GSoC 2025 projects are currently in active development, with student contributors working under the guidance of experienced mentors from the OpenELIS community. These projects represent significant enhancements that will be integrated into future OpenELIS releases upon successful completion.
For more information about GSoC 2025 and OpenELIS Global's participation, see the GSoC 2025 page.