Skip to content

Device Communication Workflow: From Analyzer to Patient Record

Category: Medical Device Integration Tags: Medical Devices, LIMS, Laboratory, Analyzer, Communication, Workflow, HL7

The Complete Communication Chain

Let me trace exactly how a chemistry analyzer result travels through each system, showing you the real technical workflow between devices.

Step 1: Inside the Analyzer - The Starting Point

The Roche Cobas c702 Chemistry Analyzer

When a blood sample for a Basic Metabolic Panel (BMP) is loaded onto the analyzer:

Internal Processing: The analyzer pipettes exactly 2 microliters of serum and mixes it with specific reagents. For glucose testing, it uses the hexokinase method - glucose reacts with ATP to form glucose-6-phosphate, which then creates NADPH that absorbs light at 340nm. The photometer measures this absorption and calculates the glucose concentration.

Data Generation: The analyzer doesn't just measure glucose as "120 mg/dL." It generates a complete data package: - Raw absorbance readings: 0.234, 0.235, 0.236 (multiple measurements) - Calculated result: 120 mg/dL - Quality flags: No interference detected, sample volume adequate - Calibration reference: Calibrator lot #ABC123, calibrated 2024-01-15 - Timestamp: 2024-01-09 14:23:15 - Sample dilution factor: 1:1 (no dilution needed) - Reagent lot numbers and expiration dates

Internal Result Processing: Before sending anything external, the analyzer runs internal validations: - Checks if result falls within analytical measurement range (10-600 mg/dL for glucose) - Compares against instrument-specific control limits - Verifies reagent integrity and temperature stability - Confirms sample identification barcode was read correctly

Step 2: Analyzer to Interface Engine Communication

The Physical Connection Layer

Network Connection: The Cobas c702 connects via Ethernet cable to a managed network switch. The analyzer has a fixed IP address (192.168.10.50) and communicates on port 4001.

Communication Protocol: The analyzer uses ASTM E1381 protocol over TCP/IP. This is a serial-like protocol that was adapted for network communication.

The Actual Data Transmission

When the glucose test completes, the analyzer formats the data into an ASTM message:

STX                           [Start of transmission]
H|\^&|||Cobas^c702^1.2.3||||||P|E1381|20240109142315  [Header record]
P|1|||SMITH^JOHN^A||19580315|M|||||||||||||20240109141500  [Patient record]
O|1|LAB123456|||GLU|||||||A||||Serum||||||||||20240109142000  [Order record]
R|1|GLU|120|mg/dL|70-105|H|||F||||20240109142315  [Result record]
C|1|I|Reagent lot: XYZ789, Cal: ABC123|G  [Comment record]
L|1|N  [Terminator record]
ETX                           [End of transmission]

Real-time Transmission: The analyzer doesn't wait to batch results. The moment glucose testing completes (14:23:15), it immediately sends this message to the interface engine. The entire transmission takes about 200 milliseconds.

Step 3: Interface Engine Processing

Data Innovations Instrument Manager (The Interface Engine)

The interface engine receives the raw ASTM message and begins processing:

Message Parsing: The interface engine breaks down the ASTM message into component parts: - Extracts patient identifier: SMITH^JOHN^A - Identifies test code: GLU (glucose) - Captures result value: 120 - Notes units: mg/dL - Records reference range: 70-105 - Flags abnormal result: H (High)

Data Validation: Before forwarding anything, the interface performs critical validations: - Patient Verification: Queries the LIMS to confirm patient LAB123456 exists and has a pending glucose order - Test Code Mapping: Converts analyzer's "GLU" code to LIMS standard "GLUCOSE" code - Units Conversion: Verifies mg/dL matches what LIMS expects (some systems use mmol/L) - Range Checking: Confirms 120 mg/dL falls within plausible limits (not obviously wrong like 1200 or -5)

Autoverification Processing: The interface engine applies sophisticated rules:

IF glucose_result >= 70 AND glucose_result <= 105 THEN
    status = "Normal - Autoverify"
ELSE IF glucose_result > 105 AND glucose_result <= 200 THEN
    status = "Abnormal - Review Required"
ELSE IF glucose_result > 400 THEN
    status = "Critical - Immediate Alert"
    trigger_critical_value_protocol()
END IF

Since John's glucose is 120 mg/dL, it gets flagged for technologist review.

HL7 Message Construction: The interface converts the ASTM data into HL7 format that the LIMS understands:

MSH|^~\&|INSTRUMENT_MGR|LAB|LIMS|HOSPITAL|20240109142316||ORU^R01|MSG12345|P|2.5
PID|1||LAB123456||SMITH^JOHN^A||19580315|M
OBR|1||LAB123456|GLU^GLUCOSE^L||20240109142000|||||||20240109142315|||F
OBX|1|NM|GLU^GLUCOSE^L|120|mg/dL|70-105|H|||F||||20240109142315
NTE|1|L|Reagent lot: XYZ789, Calibrator: ABC123

Step 4: Interface Engine to LIMS Communication

The HL7 Transaction Process

Connection Establishment: The interface engine initiates a TCP connection to the LIMS server (IP: 192.168.10.100, Port: 6661).

Message Transmission: The complete HL7 message is sent to the LIMS. The LIMS must respond with an acknowledgment within 30 seconds or the interface will retry.

LIMS Acknowledgment: The LIMS responds immediately: 

MSH|^~\&|LIMS|HOSPITAL|INSTRUMENT_MGR|LAB|20240109142317||ACK^R01|MSG12345|P|2.5
MSA|AA|MSG12345|Message accepted successfully

This acknowledgment confirms the LIMS received and accepted the glucose result.

Step 5: LIMS Internal Processing

Sunquest Laboratory Information System

Result Ingestion: The LIMS receives the HL7 message and processes it:

Patient Matching: The LIMS uses the patient identifier (LAB123456) to locate John Smith's record and confirms: - Patient demographics match (John A. Smith, DOB 3/15/1958) - Active glucose order exists from Dr. Johnson - Sample was collected and accessioned properly - No duplicate results already exist for this specimen

Data Storage: The result is stored in multiple database tables: - Patient_Results: Links result to patient record - Test_Results: Stores the actual glucose value (120 mg/dL) - Result_Flags: Records the "High" flag - Audit_Trail: Timestamps every action for compliance - QC_Links: Associates this result with quality control data from the same analyzer run

Business Rules Processing: The LIMS applies laboratory-specific rules: - Delta Check: Compares 120 mg/dL to John's previous glucose from last week (95 mg/dL). The 25 mg/dL increase triggers a "significant change" flag. - Critical Value Check: 120 mg/dL doesn't meet critical glucose threshold (>400 mg/dL), so no immediate alert. - Autoverification: Because of the abnormal flag AND significant delta change, this result cannot be auto-verified and goes to technologist review queue.

Review Queue Assignment: The result is automatically assigned to Sarah, the morning shift chemistry technologist, based on workload balancing rules.

Step 6: Technologist Review Process

Human-Computer Interaction

Review Interface: Sarah sees John's glucose result on her LIMS workstation with full context: - Current result: 120 mg/dL (HIGH) - Previous result: 95 mg/dL (normal) - Patient location: ICU Room 15B - Ordering physician: Dr. Johnson - Clinical indication: "Diabetic monitoring" - Sample quality: No hemolysis, adequate volume

Decision Making: Sarah reviews the result and makes clinical judgment: - The increase from 95 to 120 mg/dL is clinically significant but not unexpected for a diabetic patient - No obvious analytical errors (good sample quality, QC passed) - Result is consistent with patient's clinical condition

Result Approval: Sarah clicks "Approve" in the LIMS, which triggers several automatic actions: - Result status changes from "Pending Review" to "Verified" - Timestamp records Sarah's approval at 14:25:30 - Result becomes available for reporting to HIS

Step 7: LIMS to HIS Communication

Hospital Information System Integration

HL7 Result Message: The LIMS immediately constructs an ORU (Observation Result Unsolicited) message to send to the Epic HIS:

MSH|^~\&|LIMS|HOSPITAL|HIS|HOSPITAL|20240109142531||ORU^R01|RPT78901|P|2.5
PID|1||MRN987654||SMITH^JOHN^A||19580315|M|||123 MAIN ST^^ANYTOWN^ST^12345
PV1|1|I|ICU^15B^1|||||||||||||||V
OBR|1||LAB123456|GLU^GLUCOSE^L||20240109142000|20240109142315||||||TECH123^SARAH^SMITH|||||F
OBX|1|NM|GLU^GLUCOSE^L|120|mg/dL|70-105|H|||F||||||20240109142531|LAB
NTE|1|L|Verified by: Sarah Smith, CLS

Message Routing: This HL7 message travels through the hospital's integration engine (often Rhapsody or similar) which handles routing, transformation, and delivery assurance.

Step 8: Rhapsody Integration Engine Processing

Message Transformation and Routing

Message Receipt: Rhapsody receives the HL7 message from the LIMS on its inbound TCP listener (port 6001).

Transformation Rules: Rhapsody applies hospital-specific transformation rules: - Converts LIMS patient ID (LAB123456) to hospital MRN (MRN987654) - Maps laboratory test codes to Epic-specific codes - Adjusts message format to match Epic's exact requirements - Adds hospital-specific routing information

Quality Assurance: Rhapsody validates the transformed message: - Confirms all required fields are present - Verifies patient exists in Epic - Checks that the ordering physician has Epic access - Ensures message format compliance

Delivery: Rhapsody sends the final message to Epic HIS via secure HL7 connection.

Step 9: Epic HIS Integration

Electronic Medical Record Processing

Message Processing: Epic receives and processes the glucose result:

Patient Record Update: Epic automatically: - Locates John Smith's electronic medical record using MRN987654 - Adds the glucose result to his laboratory results section - Updates his problem list (diabetes monitoring) - Calculates trending information (glucose increasing over time)

Clinical Decision Support: Epic's built-in rules engine evaluates the result: - Recognizes John has diabetes diagnosis - Notes glucose is elevated but not critically high - Generates no immediate alerts (would alert if >250 mg/dL) - Updates diabetic flow sheet for trending

Physician Notification: Epic sends notification to Dr. Johnson through multiple channels: - In-Basket message: "New lab result available for John Smith" - Mobile app push notification (if Dr. Johnson is on-call) - Email alert (if configured for abnormal results)

Step 10: Clinical Access and Action

Physician Workflow

Result Review: Dr. Johnson opens Epic on his workstation and sees: - John's glucose: 120 mg/dL (HIGH) - resulted at 14:25 - Trending graph showing increase from 95 mg/dL last week - Clinical context: Patient is diabetic, on insulin therapy - Location: ICU Room 15B

Clinical Decision: Dr. Johnson determines that a glucose of 120 mg/dL requires insulin adjustment. He enters a new order in Epic: - "Increase insulin sliding scale - notify if glucose >150" - Order is automatically sent back through the system to nursing

Documentation: Epic automatically creates an audit trail: - Dr. Johnson reviewed glucose result at 14:28 - Clinical action taken: insulin adjustment - Next glucose check scheduled for 18:00

The Complete Timeline

Here's the complete device communication timeline for John's glucose result:

  • 14:23:15 - Cobas analyzer completes glucose measurement
  • 14:23:15 - ASTM message sent to interface engine (< 1 second)
  • 14:23:16 - Interface engine processes and validates result (< 1 second)
  • 14:23:16 - HL7 message sent to LIMS (< 1 second)
  • 14:23:17 - LIMS receives and stores result (< 1 second)
  • 14:23:17 - Result queued for technologist review (automatic)
  • 14:25:30 - Technologist approves result (2 minutes human time)
  • 14:25:31 - LIMS sends HL7 result to Rhapsody (< 1 second)
  • 14:25:31 - Rhapsody transforms and routes to Epic (< 1 second)
  • 14:25:32 - Epic receives and processes result (< 1 second)
  • 14:25:33 - Dr. Johnson notified of new result (< 1 second)
  • 14:28:00 - Dr. Johnson reviews and takes action (3 minutes human time)

Total automated processing time: Less than 10 seconds Total time including human review: 5 minutes

Error Handling and Recovery

What Happens When Communication Fails

Analyzer to Interface Failure: If the network connection drops: - Analyzer stores results in internal memory (can hold 10,000 results) - Continuously attempts reconnection every 30 seconds - When connection restored, automatically transmits all stored results in sequence - Interface engine processes backlog and identifies any duplicate transmissions

Interface to LIMS Failure: If LIMS is unavailable: - Interface engine queues messages in local database - Attempts delivery every 60 seconds - Messages remain queued for up to 24 hours - Automatic alert sent to IT if queue exceeds 100 messages

LIMS to HIS Failure: If Epic is down for maintenance: - LIMS stores results locally and continues normal operations - Results marked as "Pending HIS Delivery" - When Epic comes back online, batch transmission sends all pending results - Epic processes backlog chronologically to maintain proper patient timelines

Quality Control Integration

How QC Data Flows Through the Same Path

QC Sample Processing: Every morning at 6:00 AM: - Analyzer automatically processes quality control materials - QC results follow identical communication path: Analyzer → Interface → LIMS - LIMS applies Westgard statistical rules to validate QC performance - If QC fails, LIMS automatically suppresses all patient results until QC issues resolved

Real-time QC Monitoring: Throughout the day: - Every 50th patient sample triggers automatic QC verification - QC results are processed in real-time through the same interface systems - Statistical trending occurs continuously in LIMS - Predictive algorithms alert when QC is trending toward failure

This complete device communication workflow shows how a simple glucose measurement becomes a coordinated effort involving six different systems, each adding value and ensuring quality while maintaining complete traceability and audit compliance.