Chapter 4: The Reality of Hospital Network Architecture
4.1 Medical Device Segment
Overview
The medical device segment is the network area where various analyzers, including AUTION EYE, are connected. It is one of the segments within the hospital network that has the most physical devices connected.
Characteristics
| Characteristic | Description |
|---|---|
| Connected Devices | Analyzers, specimen transport systems, barcode readers, etc. |
| Communication Destinations | Primarily the LIS server |
| External Connections | None in principle (Smart Assist is the exception) |
| IP Address Scheme | Static IPs are commonly assigned |
| OS Generation | Older OS generations such as Windows 7/10 may still be in use |
Relationship with Smart Assist
The PC running the Smart Assist client is placed in this segment. This means a communication path from the medical device segment to the internet must be secured.
4.2 LIS Server Segment
Overview
This is the segment where the LIS server is located. The core system for the laboratory department operates here, requiring high availability and security.
Example of a server rack (rack-mounted servers and network equipment)
Configurations like this are also installed in hospital server rooms
Characteristics
| Characteristic | Description |
|---|---|
| Deployed Equipment | LIS server (main/backup), database server |
| Communication Destinations | Medical device segment, Electronic Medical Records (EMR) segment |
| External Connections | None |
| Access Control | Accessible only from authorized devices and terminals |
Relationship with Smart Assist
AUTION EYE (Smart Assist client) has two NICs (LAN connectors), each connected to a different network.
| NIC | Connection Destination | Purpose |
|---|---|---|
| LIS-side NIC | LIS segment (hospital LAN) | Test order reception and result transmission with LIS only |
| Internet-side NIC | Line connecting to the internet | Dedicated to communication with the Smart Assist cloud |
These two NICs are physically separate LAN connectors, connected to different network segments. The LIS-side NIC handles only LIS communication, and no Smart Assist cloud traffic flows through it.
The internet-side NIC connects to the internet access LAN line provided by the hospital. If the hospital has difficulty providing an internet line, our company may provide a mobile router for the connection.
Terminology: A NIC (Network Interface Card) is a LAN connector (LAN port) used to connect a PC to a network. AUTION EYE (Smart Assist client) has two NICs, physically separating the hospital network and the internet.
4.3 Clinical LAN
Overview
The clinical LAN is the network area used by doctors, nurses, and administrative staff for their daily work. Electronic Medical Records (EMR) terminals, nurse call systems, revenue cycle management systems, and similar equipment are connected here.
Characteristics
| Characteristic | Description |
|---|---|
| Connected Devices | EMR terminals, printers, nurse call terminals |
| Users | Doctors, nurses, administrative staff |
| Internet Access | Depends on the facility (some completely block it) |
| Security | Terminal authentication and VLAN separation are common |
Relationship with Smart Assist
Smart Assist does not communicate directly with the clinical LAN. However, hospital IT administrators are often responsible for managing this segment, so they are in a position to understand the overall network configuration.
4.4 DMZ
What is a DMZ?
A DMZ (DeMilitarized Zone) is an intermediate network area placed between the external network (internet) and the internal network (hospital intranet).
Role of the DMZ in Hospitals
| Equipment Placed in the DMZ | Role |
|---|---|
| Reverse Proxy | Relays and inspects incoming communications from external sources |
| Mail Gateway | Relays email sending and receiving |
| Web Server | Public-facing servers such as the hospital website |
| VPN Appliance | Termination device for remote maintenance access |
| Jump Server | Relay server for remote maintenance (records operation logs) |
Relationship with Smart Assist
Since Smart Assist communication is outbound only, there is no need to place a server in the DMZ. However, depending on the hospital, a proxy server may be placed in the DMZ, and Smart Assist communication may pass through that proxy.
Remote Maintenance and Jump Servers
When remotely maintaining the AUTION EYE (Smart Assist client) PC, the medical institution may set up a jump server for remote maintenance in the DMZ.
Case Study: Osaka University Hospital:
- Our company's (UHW) maintenance personnel log into the jump server in the DMZ
- Through the jump server, they connect to the AUTION EYE PC via Remote Desktop
- The jump server records operation logs, enabling the hospital to audit security
In this configuration, the AUTION EYE (Smart Assist client) requires a third NIC.
| NIC | Connection Destination | Purpose |
|---|---|---|
| NIC 1 (LIS-side) | LIS segment (hospital LAN) | Test order reception and result transmission with LIS |
| NIC 2 (Internet-side) | Internet line | Communication with the Smart Assist cloud |
| NIC 3 (Remote maintenance-side) | DMZ segment | Remote Desktop via the jump server |
Each NIC is a physically separate LAN connector, connected to a different network segment. This ensures that LIS communication, cloud communication, and remote maintenance communication are physically separated, maintaining security.
4.5 Internet Exit Point Controls
How Exit Controls Work
Communication from the hospital to the internet is strictly controlled, even for outbound traffic.
Common Control Methods
| Control Method | Description |
|---|---|
| Firewall | Permits/denies traffic based on source IP, destination IP, and destination port |
| Proxy Server | Relays HTTP/HTTPS traffic and filters by URL |
| URL Filtering | Controls destinations using category-based or whitelist methods |
| IDS/IPS | Detects and blocks malicious traffic patterns |
| SSL Inspection | Decrypts and inspects the contents of HTTPS traffic |
Firewall Appliance
(Cisco ASA 5510)
L2 Switch (Installation Example)
(Cisco Catalyst 2950)
Router
(Cisco 2800)
Example Communication Path for Smart Assist
Smart Assist communication must be permitted at every one of these points. If it is blocked at even one point, the communication will fail.
As you can see from the diagram above, the communication path passes through multiple points. When "communication fails," trying to examine everything at once leads to confusion.
The key is to check one point at a time, starting from the nearest. Verify in order: Smart Assist PC → Router → Proxy → FW → Internet → AWS, asking "Does it pass through up to this point?" The first point where it fails is the cause.
Specific commands and procedures will be explained in detail in Chapter 10, but please remember this "start from the nearest and work outward" approach for now.
4.6 The Presence of Proxy Servers
Why Proxy Servers Matter
In many hospitals, HTTP/HTTPS communication to the internet is configured to pass through a proxy server. In deploying Smart Assist, the presence and configuration of proxy servers is one of the most frequent causes of trouble.
Types of Proxy Servers
| Type | Description |
|---|---|
| Forward Proxy | Relays communication from hospital terminals to the internet |
| Transparent Proxy | No configuration required on the terminal side; automatically relays traffic on the network path |
| Authenticating Proxy | Requires user ID/password input during communication |
When you ask hospital IT administrators "What are your proxy settings?" they may respond with "We use an auto-configuration script." This is the proxy.pac (or wpad.dat) file.
A proxy.pac file is a JavaScript file that determines on a per-URL basis whether to "use a proxy or not." Browsers can interpret this, but the Smart Assist application may not be able to interpret pac files.
In environments using proxy.pac, ask to see the contents of the pac file and verify which proxy Smart Assist's destination is routed to. Directly specifying that proxy's address:port is the most reliable approach.
What to Verify in Proxy Environments
| Verification Item | Details |
|---|---|
| Proxy Existence | Whether a proxy server exists at all |
| Proxy Address | IP address or hostname, and port number |
| Authentication | Whether authentication is required, and if so, the authentication method |
| Exclusion Settings | Whether specific destinations can be excluded from the proxy |
| SSL Inspection | Whether the proxy decrypts and inspects HTTPS traffic |
Typical Problems Caused by Proxies
| Symptom | Cause |
|---|---|
| Connection Timeout | Proxy settings are not configured and traffic cannot reach the destination |
| 403 Forbidden | The destination is blocked by the proxy's URL filter |
| SSL Certificate Error | The certificate has been replaced due to SSL inspection |
| Authentication Error | Credentials for the authenticating proxy are not configured |
Transparent proxies require no configuration on the terminal side, so you won't notice they exist until you ask the hospital IT administrator. Even when you ask "Do you have a proxy?" and they answer "No," there are quite a few cases where a transparent proxy was actually in place.
The way to identify it is through the output of curl -v. If the destination IP address differs from the nslookup result, or if the certificate issuer has an unfamiliar name, suspect the presence of a transparent proxy.
During interviews, rather than just asking "Do you have a proxy?", it is best to ask "Do you have any URL filtering or SSL inspection products deployed?" This phrasing will also catch transparent proxies.
The methods for diagnosing these problems are described in detail in Chapter 10.
Note (International Context): The hospital network configurations presented in this chapter represent typical patterns found in Japanese medical institutions. In the United States, large health systems (using Epic/Oracle Health, etc.) often build centrally managed network architectures. In Europe, configurations vary by country, such as NHS Trusts (United Kingdom) and Krankenhaus groups (Germany). Across all regions, the fundamental principles of "medical device segment isolation" and "external connection control" are common, but it should be noted that implementation methods and governance structures differ. In recent years, the adoption of SASE (Secure Access Service Edge) and zero-trust architecture has been advancing, primarily in the United States and Europe.
Epic Systems
Oracle Health
NHS (United Kingdom)
In the next chapter, we will learn the fundamentals of network communication and build the foundation for understanding the communication design of Smart Assist.