Chapter 2 Understanding the Business Structure of Smart Assist
2.1 Automatic Analysis and Unconfirmed Classification
The Automatic Classification Process of AUTION EYE
AUTION EYE captures images of urine specimens and automatically classifies the formed elements found in those images. When the instrument has sufficient confidence in its classification, the result is marked as "Confirmed." When it does not, the result is marked as "Unconfirmed."
Criteria for Confirmed vs. Unconfirmed
| Decision | Meaning | Subsequent Flow |
|---|---|---|
| Confirmed | The instrument had sufficient confidence in its automatic classification | Results are sent to LIS as before |
| Unconfirmed | The instrument did not have sufficient confidence in its automatic classification | Routed through Smart Assist for classification by a remote medical technologist |
Typical Cases Where Unconfirmed Results Occur
- Overlapping elements: Multiple formed elements overlap, making individual identification difficult
- Atypical cells: Cells with morphology that does not fit standard classification categories
- Background noise: Image quality degraded due to the condition of the specimen
- Rare elements: Elements appear for which training data is scarce
The key point for engineers is that the occurrence of unconfirmed data is normal behavior. The occurrence of unconfirmed results is not a system failure in itself.
2.2 External Transmission of Unconfirmed Data
Contents of Transmitted Data
Image data classified as unconfirmed is transmitted to the AWS cloud through the Smart Assist client.
Data included in the transmission:
| Data Item | Contents |
|---|---|
| Captured images | Microscope images of formed elements classified as unconfirmed |
| Specimen identification | An ID that uniquely identifies the specimen. *A global sequence ID issued by the cloud server when the specimen is transmitted |
| Automatic classification results | Primary classification candidates from AUTION EYE |
| Timestamps | Capture date/time, transmission date/time |
Data NOT included in the transmission (in Japan):
- Patient name
- Date of Birth
- Hospital name
- Other personally identifiable information
U.S. Operations: Transmission of PHI
In the United States, the laboratory of the remote medical technologists working on the cloud (Smart Assist server) must meet CLIA (Clinical Laboratory Improvement Amendments) requirements. For this reason, the following PHI (Protected Health Information) is included in the transmitted data in U.S. configurations.
| Data Item | Contents |
|---|---|
| Specimen ID | Barcode ID |
| Patient Date of Birth | Required for CLIA compliance |
| Patient Sex | Required for CLIA compliance |
Because the design involves transmitting PHI, the security review by IT departments at U.S. healthcare facilities is more stringent than in Japan. The knowledge of communication design and security measures explained in this textbook is essential for meeting such rigorous review requirements.
Technical Mechanism of Transmission
2.3 Classification by Remote Medical Technologists
Role of the Remote Technologists
Unconfirmed images that arrive at the Smart Assist server on the AWS cloud are reviewed and classified by clinical laboratory technologists working remotely. The screen used by the remote technologists is the same manual classification screen as on the AUTION EYE instrument itself, displayed in Remote Technologist Mode, providing an operating environment equivalent to that of a technologist standing in front of the instrument.
Classification Workflow
| Step | Description |
|---|---|
| 1. Image display | Unconfirmed images are displayed on the classification screen in Remote Technologist Mode |
| 2. Primary classification reference | The automatic classification candidates from AUTION EYE are reviewed |
| 3. Technologist decision | The technologist determines the final classification based on their professional expertise |
| 4. Result entry | The confirmed classification result is entered into the system. If classification is not possible, a microscopy flag is assigned |
| 5. Result confirmation | The entered result is saved on the Smart Assist server |
When Classification Is Not Possible
There are cases where even a remote technologist cannot determine a definitive classification from the image alone. In such cases, a microscopy flag is returned to the AUTION EYE. Upon receiving this flag, the laboratory performs a separate microscopy examination (manual visual classification by a laboratory technologist), and registers the result in LIS.
Key Points for Engineers
- Remote technologists work using the same classification screen as the AUTION EYE instrument in Remote Technologist Mode
- The technologist's work environment and the hospital's internal network are not directly connected
- The technologist's classification results are stored in the cloud and retrieved by the hospital PC during its next communication cycle
- The microscopy flag for unclassifiable cases is returned through the Smart Assist communication path (no additional communication path is required)
2.4 Result Return Flow
How Results Are Returned to the Hospital
Classification results confirmed by remote technologists are retrieved when the Smart Assist client (hospital PC) queries the cloud.
Critical Design Principle
The most important point here is that the return of results is NOT a "push" from the cloud.
- The hospital PC periodically queries the cloud (polling)
- The cloud returns results in response to the query (response)
- Communication is always initiated by the hospital PC
This design ensures that no direct access from the cloud to the hospital's internal network ever occurs.
2.5 How Confirmed Results Are Sent to LIS
Forwarding Cloud-Retrieved Results to LIS
Confirmed results retrieved from the cloud by the Smart Assist client are sent to LIS within the hospital's internal network.
End-to-End Flow Summary
| Step | Communication Segment | Communication Method | Direction |
|---|---|---|---|
| 1. Unconfirmed image transmission | Hospital PC → AWS | HTTPS (Internet) | Outbound |
| 2. Remote technologist classifies | Within AWS | — | — |
| 3. Result query | Hospital PC → AWS | HTTPS (Internet) | Outbound |
| 4. Result response | AWS → Hospital PC | HTTPS (same session) | Response |
| 5. Result sent to LIS | Hospital PC → LIS | Internal protocol | Internal comm. |
| 6. Report to EMR | LIS → EMR | Internal protocol | Internal comm. |
Steps 1 through 4 are communications specific to Smart Assist, while steps 5 and 6 follow the same internal hospital flow as before.
2.6 Accurate Understanding of Bidirectional Communication (What Is a Session Response?)
A Common Misconception
When explaining Smart Assist communication, the phrase "results come back from the cloud" can lead to the following misconception:
Misconception: "The cloud connects to the hospital's internal network and pushes the results in"
This is completely incorrect.
The Correct Understanding: Session Response
HTTPS communication consists of "request and response" pairs.
How to Use This in Explanations to Hospital IT Staff
During hospital security reviews, the primary concern is "whether external communications enter the hospital network." It is critical to be able to answer this question accurately as follows:
"All Smart Assist communication is HTTPS outbound traffic initiated by the hospital PC. The return of results from the cloud is a response to an HTTPS session initiated by the hospital PC, and no new inbound connections from the cloud to the hospital network ever occur."
Whether or not you can provide this explanation is the deciding factor in gaining the trust of hospital IT staff.
In the next chapter, we will understand the perspective from which hospital IT staff evaluate Smart Assist, and acquire the knowledge needed to prepare for security reviews.