Overview
bLIS can send automated email notifications for important laboratory events. This ensures stakeholders are informed about critical results, holds, invoices, and report availability without needing to constantly check the system.
Notification Types
bLIS supports notifications for:
- Reports: When final reports are ready
- Invoices: When invoices are generated
- Holds: When accessions are placed on hold
- Test Results: When specific test results meet criteria
- Uploads: When data uploads complete or fail
Email Notifications
Organization Email Settings
Configure email notifications at the organization level:
- Navigate to Administration → Organizations
- Select the organization
- Go to Email Notifications
- Add email addresses and select notification types
Email Notification Fields
| Field | Description |
|---|
| Organization | Which org these notifications apply to |
| Email | Recipient email address |
| Notification Types | JSON array of enabled notification types |
["REPORT", "INVOICE", "HOLD"]
Adding Recipients
Multiple email addresses can be configured per organization:
organization_id: 1
├── billing@lab.com → ["INVOICE"]
├── pathologist@lab.com → ["REPORT", "HOLD"]
└── admin@lab.com → ["REPORT", "INVOICE", "HOLD"]
Use distribution lists (e.g., lab-team@example.com) to notify multiple people with a single notification entry.
Test Result Notifications
Send alerts when specific test results are ready or meet certain criteria.
Configuration
Test result notifications link:
- Organization: Who receives the notification
- Test Spec: Which test triggers notifications
- Test Result Spec: (Optional) Specific result condition
Use Cases
Common scenarios for test result notifications:
- Critical Values: Alert pathologist immediately for abnormal results
- Reference Lab Results: Notify when send-out test results are received
- Specific Tests: Alert for high-priority tests (e.g., blood cultures, COVID-19)
- Quality Control: Notify QC manager when control tests complete
Setting Up Result Alerts
- Navigate to Administration → Test Specifications
- Select the test spec
- Go to Notifications tab
- Configure which organizations should be notified
Test result notifications are per organization. If multiple organizations order the same test, configure notifications separately for each.
Notification Status
Each notification has a lifecycle status:
| Status | Description |
|---|
PENDING | Queued for sending |
SENT | Successfully delivered |
FAILED | Delivery failed (see payload for error) |
PROCESSING | Currently being sent |
Monitoring Delivery
Track notification delivery:
- Check the Notifications log in Administration
- Filter by status to find failed deliveries
- Review payload for error details
- Retry failed notifications if needed
Failed Notifications
Common reasons for delivery failure:
- Invalid email address
- Email server temporarily unavailable
- Recipient inbox full
- Email rejected as spam
Failed notifications should be:
- Reviewed promptly
- Corrected and resent if critical
- Used to update email addresses in settings
Notification Payload
Each notification includes a JSON payload with relevant data:
Report Notifications
{
"reportId": 12345,
"accessionNumber": "20260215001",
"caseId": "P123456",
"reportUrl": "https://tenant.blis.app/reports/12345.pdf",
"finalizedAt": "2026-02-15T10:30:00Z"
}
Hold Notifications
{
"holdId": 789,
"accessionNumber": "20260215002",
"description": "Hemolyzed specimen - recollection required",
"createdBy": "tech@lab.com",
"createdAt": "2026-02-15T14:15:00Z"
}
Invoice Notifications
{
"invoiceId": 456,
"organization": "Regional Hospital",
"totalAmount": 1250.00,
"lineItemCount": 15,
"generatedAt": "2026-02-15T16:00:00Z",
"downloadUrl": "https://tenant.blis.app/invoices/456.csv"
}
Communication Protocols
Currently, bLIS supports:
- EMAIL: Standard email delivery
Future versions may support:
- SMS text messages
- Slack/Teams integrations
- HL7 messaging
- Custom webhooks
Best Practices
Configuration
- Use role-based distribution lists rather than individual emails
- Test notifications in a staging environment first
- Document who receives which notification types
- Review and update recipient lists regularly
Email Management
- Use professional email addresses (not personal)
- Configure email whitelisting to prevent spam filtering
- Include clear subject lines in notification templates
- Provide unsubscribe or preference management
Monitoring
- Check failed notifications daily
- Set up alerts for high failure rates
- Maintain backup notification methods for critical alerts
- Log notification delivery for compliance
Security
- Don’t include sensitive data in email subjects
- Use secure links rather than attaching PHI
- Implement email encryption for sensitive notifications
- Audit who has access to notification settings
Notification Workflows
Critical Result Alert
- Test result finalized with critical value
- System checks for test result notifications configured
- Email generated with accession and result summary
- Notification sent to configured recipients
- Status tracked as PENDING → SENT
- Delivery confirmed and logged
Invoice Distribution
- Invoice generation completes
- System looks up email notifications for organization
- Filters for recipients with “INVOICE” type enabled
- Email sent with invoice summary and download link
- Delivery status tracked
- Failed deliveries retried according to policy
Hold Alerts
- User creates hold on accession
- Hold notification triggered
- Email sent to configured recipients for that organization
- Includes hold description, accession info, and link to resolve
- Status updated as email is processed
- Escalation if hold not resolved within threshold
Troubleshooting
Notifications Not Sending
Check configuration:
- Verify email notification is enabled for the organization
- Confirm recipient email is correct
- Check notification types array includes the event type
- Ensure email server settings are configured
Check notification log:
- Look for PENDING notifications stuck in queue
- Review FAILED notifications for error messages
- Verify notification was created at all
Duplicate Notifications
Common causes:
- Multiple email notification entries for same address
- Test result notification configured multiple times
- System retrying failed deliveries
Solutions:
- Review and deduplicate email notification entries
- Check for overlapping test result notification rules
- Adjust retry policies if needed
Wrong Recipients Receiving Notifications
Verify:
- Notification types array for each email entry
- Organization settings match intended recipients
- Test result notifications linked to correct org
- Email addresses haven’t been repurposed
Delayed Delivery
Investigate:
- Check email server queue and processing time
- Review notification status (PENDING vs PROCESSING)
- Look for system load or performance issues
- Verify email server connectivity
Compliance Considerations
Audit Trail
- All notifications are logged with timestamps
- Track what was sent, when, and to whom
- Maintain records of notification delivery status
- Include notifications in compliance reporting
PHI Protection
- Minimize protected health information in emails
- Use secure links instead of including data
- Implement email encryption if required
- Configure retention policies for notification logs
Regulatory Requirements
- HIPAA: Ensure email notification meets security requirements
- CLIA: Document critical result notification processes
- State laws: Comply with notification timing requirements
