Chapter 3 The Hospital IT Administrator's Perspective

3.1 Hospital Information Security Responsibilities

What Hospitals Must Protect

The hospital IT department is responsible for protecting the following information assets.

The Three Principles of Information Security (CIA)

Hospital security policies are designed based on the three principles of information security.

Accountability

The ultimate responsibility for hospital information security lies with the hospital's management. Even for services provided by external vendors, the hospital bears responsibility for deciding to adopt them and permitting their connection to the internal network.

Understanding this point helps explain why hospital IT administrators take such a cautious approach.

3.2 Why Hospital Networks Are Closed

The Principle of Closed/Isolated Networks

In many hospitals, the internal network is designed as a closed/isolated network, segregated from the Internet.

Reasons for Keeping the Network Closed

HIPAA (US)

GDPR / NIS2 Directive (EU)

Three-Ministry Two-Guideline Framework (Japan)

Implications for Engineers

Smart Assist is a service that requires opening a communication path from this closed network to the outside (AWS). In other words, it is in the position of requesting an "exception" to the hospital's security principles.

Engineers must squarely confront this fact and be able to explain "why it is safe" with technical evidence.

3.3 Why External Connections Are the Primary Concern

The Hospital IT Administrator's Mindset

For hospital IT administrators, granting permission for external connections is one of the highest-risk decisions they make.

In most cases, "not granting permission" is judged to carry lower risk. This is the structural reason why proposals for external connections are often rejected.

The Impact of Past Incidents

In recent years, multiple cyberattacks targeting medical institutions have been reported. These cases have heightened the sense of crisis within hospital IT departments, and vigilance toward external connections continues to grow.

As engineers, rather than viewing this vigilance as "excessive worry," it is necessary to adopt an attitude of respecting it as a legitimate concern.

3.4 Typical Concerns About Vendor Proposals

Concerns Held by Hospital IT Administrators

When presented with a proposal for a cloud-integrated service like Smart Assist, hospital IT administrators harbor the following concerns.

Common Mistakes Vendors Make

The Right Approach

• Illustrate and explain specific communication flows with diagrams
• Clearly list transmitted data (what is included and what is not)
• Provide a technical explanation that communication direction is Outbound Only
• Prepare answers to anticipated questions in advance

3.5 Questions That Will Always Be Asked During Security Reviews

Typical Questions and Guidance for Answers

During hospital security reviews, the following questions are almost always presented. Engineers must be able to answer each question with technical evidence.

Q1: What is the direction of communication?

Question: "Is this communication one-way from internal to external, or bidirectional?"

Guidance for answer: The communication is always initiated from the hospital PC side. The return of results from the cloud is a response to the HTTPS session initiated by the hospital PC; no new connections from the cloud to the hospital network occur. (See Chapter 2, Section 2.6)

Q2: What data is transmitted?

Question: "Is any information that can identify patients being transmitted?"

Guidance for answer: In deployments such as Japan, only anonymized Specimen IDs and microscope images are transmitted; no personally identifiable information such as patient names or dates of birth is included.

However, in the United States, to meet CLIA (Clinical Laboratory Improvement Amendments) requirements, PHI (Protected Health Information) including Specimen ID (barcode ID), date of birth, and sex is included in the transmitted data. For this reason, more stringent security reviews are required at US medical institutions. (See Chapter 2, Section 2.2)

Q3: Is communication encrypted?

Question: "Is the communication pathway encrypted?"

Guidance for answer: Communication is encrypted with HTTPS (TLS 1.2 or higher). Communication content cannot be eavesdropped on or tampered with in transit. (Detailed in Chapter 6)

Q4: What is the connection destination?

Question: "Where does it connect to? What is the IP address or FQDN?"

Guidance for answer: The connection destination is a specific FQDN on AWS, and the targets to be permitted on the firewall can be explicitly specified. (Detailed in Chapter 7)

Q5: What is the impact during an outage?

Question: "If the cloud goes down, will all laboratory operations stop?"

Guidance for answer: Even if Smart Assist goes down, results confirmed by AUTION EYE's automatic classification will continue to be sent to the LIS. Only the determination of unconfirmed data is affected.

Q6: Regulatory compliance?

Question: "Is it compliant with guidelines and regulations related to medical information?"

Guidance for answer: Compliance with applicable regulations in the deployment region is explained in documentation. (Detailed in Chapter 9)

3.6 How to Read the Materials: IT/Security Explanatory Materials

Note: The "IT/Security Explanatory Materials" discussed in this section are specific to the US version of Smart Assist. Because the US version handles PHI (Protected Health Information), dedicated security explanatory materials are prepared for hospital IT/ISO departments.

Overview of the Materials

The primary document submitted to hospital IT/ISO departments when considering the adoption of Smart Assist is the "Smart Assist (US) IT/Security Explanatory Materials." This document is created as a template that comprehensively covers the technical and security information necessary for the hospital to make an adoption decision.

Corresponding file: SmartAssist_US_IT_Security Draft-en

Structure of the Materials and How to Read Each Section

Key Points Representatives Should Understand

1. Smart Assist does not perform diagnostic acts — The final verification and approval of test results is the responsibility of the medical institution
2. The scope of PHI is limited — Only date of birth, sex, and specimen identifiers are transmitted. Diagnoses, physician notes, and medical record information are never handled
3. The Outbound Only principle — Only communication from the hospital to the outside. No direct inbound connections from outside to the hospital network are required
4. Third-party certifications are not "absolute guarantees" — HIPAA Risk Assessment, SOC 2, and ISO 27001 demonstrate a certain level of security, but do not automatically guarantee compliance with individual hospital IT policies

Expected Questions and Guidance for Answers

3.7 List of Documents Submitted for Security Reviews

The following shows the complete set of documents that the Smart Assist team can submit for hospital security reviews.

The detailed reading of these documents is covered in each corresponding chapter. The goal is for representatives to be able to present and explain these documents in combination at security review meetings.

In the next chapter, we will understand the specific structure of hospital networks and identify which network segments Smart Assist's communication paths traverse.