Chapter 6: Technical Anatomy of Smart Assist Communication Design

6.1 Actual Communication Sequence Diagram

The following diagram shows the communication sequence in chronological order, from when the Smart Assist PC sends unconfirmed images to the AWS cloud until it retrieves the classification results.

Each step is explained in detail in the following sections.

6.2 DNS Resolution Flow

Details of Steps 1 and 2

The first thing the Smart Assist PC does is a DNS query to resolve the destination FQDN to an IP address.

Considerations for Hospital Environments

AWS Environment-Specific Considerations

With AWS services, the IP address for the same FQDN can change dynamically. Therefore, it is recommended to configure firewall allow rules based on FQDNs rather than IP addresses (discussed in detail in Chapter 7).

6.3 TLS Handshake

TLS Certificate (Let's Encrypt Logo Example)

Details of Steps 3 and 4

After the TCP connection is established, the TLS handshake takes place.

Impact of SSL Inspection

If the hospital's proxy or firewall performs SSL inspection, the behavior of the TLS handshake changes.

In this case, the certificate received by the Smart Assist PC is not from AWS but rather a certificate issued by the proxy. This can be the cause of certificate errors (discussed in detail in Chapter 10).

6.4 Image Data Transmission Flow

Details of Steps 5 and 6

After the TLS handshake is complete, image data is transmitted as an HTTPS request over the encrypted channel.

HTTPS Request (Illustration):

  POST /api/v1/images HTTP/1.1
  Host: smartassist.example.com
  Content-Type: multipart/form-data
  Authorization: Bearer <authentication token>

  [Image binary data]
  [Specimen ID]
  [Auto-classification result]
  [Timestamp]

Communication Characteristics

Response Content

HTTPS Response (Illustration):

  HTTP/1.1 200 OK
  Content-Type: application/json

  {
    "status": "accepted",
    "request_id": "abc-123-def"
  }

This response is a confirmation that the data has been accepted; the classification results are not yet returned.

6.5 Classification Result Retrieval Mechanism

Details of Steps 7 and 8

After the remote technician completes the classification, the Smart Assist PC queries the cloud to retrieve the results.

HTTPS Request (Illustration):

  GET /api/v1/results?since=2025-01-15T10:00:00Z HTTP/1.1
  Host: smartassist.example.com
  Authorization: Bearer <authentication token>

HTTPS Response (Illustration):

  HTTP/1.1 200 OK
  Content-Type: application/json

  {
    "results": [
      {
        "request_id": "abc-123-def",
        "specimen_id": "SP-20250115-001",
        "classifications": [
          { "image_id": "img-001", "category": "RBC", "confidence": 0.95 },
          { "image_id": "img-002", "category": "WBC", "confidence": 0.92 }
        ],
        "classified_by": "technician-A",
        "classified_at": "2025-01-15T10:30:00Z"
      }
    ]
  }

Polling Mechanism

The Smart Assist PC periodically queries the cloud for results. This is called polling.

6.6 What Does "Outbound Only" Mean?

Definition

"Outbound Only" means that all communication is initiated from within the hospital network to external destinations.

Communication Direction Classification

A Response Is Not Inbound

From a firewall perspective, the critical point is that a response to an Outbound communication is not "Inbound communication."

Security Implications of Being Outbound Only

6.7 Why There Is No Direct External Intrusion

Technical Basis

This section organizes the technical grounds for asserting that there is no direct intrusion from the outside (internet) into the hospital network in Smart Assist's communication design.

Basis 1: No Inbound Ports Are Open

Since no firewall rule exists to allow new connections from outside to the hospital network, external connections are physically blocked.

Basis 2: Behind NAT

The hospital PCs are located behind NAT, and there is no way to directly reach private IP addresses from the outside.

Basis 3: No Listening Services

The Smart Assist PC does not run any services that listen for connections from outside (such as web servers or SSH servers). Even if an attacker could pass through the firewall, there would be no process to accept the connection.

Basis 4: Communication Protection via TLS

TLS prevents eavesdropping, tampering, and impersonation on the communication path. Interception of communication via man-in-the-middle (MITM) attacks is also difficult.

Summary: Explanation for Hospital IT Administrators

6.8 How to Read the Documentation: Network Explanatory Materials

Overview of the Document

"SmartAssist Network Explanatory Materials" is a technical document that illustrates the system architecture and network connection methods for the Smart Assist cloud using diagrams. It is used by hospital IT departments when evaluating firewall settings and connection methods.

Corresponding File: UHW-PRJ2024040-L-2025-007a_SmartAssist Network Explanatory Materials

Components of the Smart Assist Cloud

The Network Explanatory Materials show the overall picture of the AWS services that comprise the Smart Assist cloud. Field engineers need to understand the role of each service.

Security and Audit Services

The following AWS security services are enabled in the Smart Assist cloud.

Three Connection Options

The Network Explanatory Materials present three options for connecting from the hospital to the Smart Assist cloud.

Important: With any option, no static inbound configuration is required. The communication direction is always Outbound from the hospital side to the cloud.

Physical Connection Configuration

The connection configuration between AUTION EYE and PC/LIS is also documented in the materials.

In the next chapter, we will learn about the firewall design to enable this communication and how to submit requests to hospital IT administrators.