Laboratory Analyzer TCP connection to Middleware

Technical Implementation Guide

Overview

This document describes the successful implementation of direct communication between a laboratory analyzer and custom middleware, bypassing traditional laboratory middleware solutions like REMISOL Advance.

Architecture

Laboratory Analyzer (Client)
    ↓ ASTM Protocol over TCP/IP
Middleware/Script Communicator (Server)
    ↓
Laboratory Information System (LIS)

Implementation Requirements

1. Network Configuration

Critical Requirement: Both devices must be on the same network subnet.

Configuration Used:

• Network Subnet: 192.168.150.0/24
• Middleware Server IP: 192.168.150.50
• Analyzer IP: 192.168.150.x (any available IP in same subnet)

2. Middleware Server Setup

Server Configuration:

• Application: Script Communicator (or custom middleware)
• Mode: TCP Server
• IP Address: 192.168.150.50
• Port: Typically 1210, 3000, or 4000 (configured to match analyzer)
• Protocol: ASTM E1381/E1394
• State: Listening for incoming connections

Server Startup Sequence:

1. Configure Script Communicator as TCP Server
2. Bind to IP address 192.168.150.50
3. Set appropriate port number
4. Start server in listening mode
5. Verify listening state with: netstat -ano | findstr :<PORT>

3. Analyzer Configuration

Analyzer Settings:

• Communication Mode: TCP Client
• Protocol: ASTM
• Server IP Address: 192.168.150.50
• Server Port: Match middleware configuration
• Connection Type: Manual Send (user-initiated)

Here’s the simplest, reliable way to identify the correct IP address your analyzer should connect to, on both Linux and Windows. This is the IP of the machine running your middleware server.

Find Middleware IP address

Windows

1. Using Command Prompt

ipconfig

Look for the active network adapter (Ethernet/Wi-Fi):

• IPv4 Address → This is your middleware server’s IP.

Example output:

Ethernet adapter:
   IPv4 Address. . . . . . . . . . : 192.168.150.50

2. Confirm the analyzer can reach it

From the analyzer’s network or any device on the same LAN:

ping 192.168.150.50

Linux

1. Using terminal

ip addr show

or a shorter version:

hostname -I

Look under the interface connected to your LAN (usually eth0, ens33, or wlan0).
Find the line containing:

inet 192.168.150.50/24

The number before the / is the IP you configure in the analyzer.

2. Confirm reachability

ping 192.168.150.50

Important real-world tips

• If the middleware server has multiple network interfaces, choose the one on the analyzer’s network (e.g., the dedicated instrument VLAN).
• Avoid using Wi-Fi unless the analyzer supports routing through it.
• If the IP changes on reboot, configure the server machine to use a static IP matching the analyzer’s expected subnet (e.g., 192.168.150.x).

Communication Protocol

ASTM Message Format

The analyzer transmits results using ASTM protocol:

<STX>1H|^&|||ANALYZER|||||||P|1<CR><ETX>
2P|1||PATIENT_ID||LAST^FIRST<CR><ETX>
3O|1||ORDER_ID||^^^TEST_CODE<CR><ETX>
4R|1|^^^PARAMETER|RESULT|UNITS|REFERENCE<CR><ETX>
5L|1|N<CR><ETX>

Key ASTM Components:

• H Record: Header (instrument identification)
• P Record: Patient demographics
• O Record: Order/test request information
• R Record: Result data (multiple per message)
• L Record: Message terminator

Operational Workflow

Result Transmission Process

1. Test Completion: Analyzer completes sample analysis
2. User Action: Operator clicks “SEND” button on analyzer
3. Connection: Analyzer initiates TCP connection to 192.168.150.50
4. Data Transfer: ASTM-formatted results transmitted to middleware
5. Acknowledgment: Middleware sends ACK back to analyzer
6. Disconnect: Connection closes after successful transmission
7. Processing: Middleware processes and forwards to LIS

Manual Send Requirement

Important: This implementation requires manual operator intervention. After each test:

• Results appear on analyzer screen
• Operator reviews results
• Operator manually clicks “SEND” to transmit
• Prevents automatic transmission of unreviewed results

Advantages of Direct Integration

Benefits Over Traditional Middleware

1. Simplified Architecture
   • Eliminates intermediate REMISOL Advance layer
   • Direct analyzer-to-LIS communication
   • Reduced points of failure
2. Cost Reduction
   • No expensive middleware licensing fees
   • Reduced hardware requirements
   • Lower maintenance costs
3. Greater Control
   • Custom data processing logic
   • Flexible validation rules
   • Direct database integration
4. Improved Transparency
   • Full visibility into data flow
   • Easy troubleshooting
   • Custom logging and auditing

Technical Validation

Connection Verification

On Middleware Server:

# Verify server is listening
netstat -ano | findstr :<PORT>
# Expected: TCP 192.168.150.50:<PORT> LISTENING

# Monitor incoming connections
netstat -ano | findstr ESTABLISHED

Test Connectivity:

# From analyzer network
telnet 192.168.150.50 <PORT>
# Success: Connection established

Troubleshooting Guide

Common Issues and Solutions

Security Considerations

1. Network Isolation: Use dedicated VLAN for laboratory network
2. Access Control: Restrict middleware server access
3. Audit Logging: Log all transmissions with timestamps
4. Data Validation: Implement checksum verification
5. Encryption: Consider TLS/SSL for sensitive data (if supported)

Compliance Notes

This implementation maintains compliance with laboratory standards:

• CLSI AUTO03: Supports ASTM E1381 protocol
• Data Integrity: All results logged and traceable
• Manual Review: Operator must review before sending
• Audit Trail: Complete transmission history maintained

Conclusion

Direct analyzer-to-middleware integration provides a cost-effective, transparent alternative to proprietary middleware solutions. Success requires:

✓ Proper network configuration (same subnet)
✓ Middleware server in listening mode
✓ Correct ASTM protocol implementation
✓ Manual send workflow for quality control

This architecture enables laboratories to maintain full control over their data flow while reducing costs and complexity.