Chapter 9 Medical Data and Regulations
HIPAA (US)
GDPR (EU)
Three-Ministry Two-Guideline Framework (Japan)
9.1 Confidentiality of Medical Information
Why Medical Information Receives Special Treatment
Medical information is specially protected under the laws of each country as information that requires a higher level of confidentiality than general personal information.
| Region | Legal Classification | Legal Basis |
|---|---|---|
| Japan | Sensitive Personal Information (requires special care) | Act on the Protection of Personal Information (APPI) |
| US | Protected Health Information (PHI) | HIPAA |
| EU | Special Category Data | GDPR Article 9 |
| Classification | Examples | Risk upon Leakage |
|---|---|---|
| General personal information | Name, address, phone number | Privacy violation |
| Medical information (specially protected) | Medical history, diagnosis results, test data | Cause of discrimination/prejudice, impact on insurance/employment |
Unique Characteristics of Medical Information
- Irreversibility: Once leaked, medical history cannot be retracted
- Potential for discrimination: Leakage of information about specific diseases may lead to social discrimination
- Lifelong impact: Medical history information has implications throughout an individual's lifetime
- May be obtained without consent: Tests may be performed without the individual's consent, such as during emergency transport
Implications for Smart Assist Engineers
In operations in Japan and other regions, Smart Assist handles microscope images and anonymized specimen IDs, and does not contain directly identifiable personal information. However, as engineers working on a system that handles medical data, it is essential to be aware of the confidentiality of medical information.
Note (US version): In the US, to meet CLIA requirements, the transmitted data includes specimen IDs (barcode IDs), date of birth, and sex, which constitute PHI (Protected Health Information). Therefore, engineers working on the US version of Smart Assist must have an understanding of HIPAA regulations regarding the handling of PHI. (See Chapter 2, Section 2.2)
9.2 What Is PHI?
Definition of PHI
PHI (Protected Health Information) refers to individually identifiable medical information. While it is a concept defined by the US HIPAA law, it is widely used as a common international term in medical IT.
Examples of Information That Qualifies as PHI
| Category | Examples |
|---|---|
| Personal identifiers | Name, address, date of birth, phone number, email address |
| Medical record numbers | Patient ID, chart number |
| Medical information | Diagnosis results, prescription information, test results |
| Biometric information | Fingerprints, facial photographs, genetic information |
| Insurance information | Insurer number, insured person number |
PHI Identifiers (18 Items)
HIPAA defines medical information containing any of the following 18 items as PHI.
- Name
- Address (geographic information more specific than state)
- Dates (date of birth, admission date, discharge date, etc.)
- Phone number
- Fax number
- Email address
- Social Security Number (SSN)
- Medical record number
- Health plan beneficiary number
- Account number
- Driver's license number
- Vehicle identification number
- Device identifier
- Web URL
- IP address
- Biometric identifiers (fingerprints, voiceprints, etc.)
- Facial photograph
- Any other unique identifying number
Relationship with Smart Assist
In operations in Japan and other regions, the first step in regulatory compliance is to confirm and explain that the transmitted data from Smart Assist does not contain any of the above 18 identifiers.
Note (US version): In the US version, due to CLIA requirements, specimen IDs (barcode IDs), date of birth (item 3: Dates), and sex are included in the transmitted data. Since these qualify as PHI, protective measures based on the HIPAA Security Rule are required.
9.3 HIPAA (US)
What Is HIPAA?
HIPAA (Health Insurance Portability and Accountability Act) is a US federal law enacted in 1996. It establishes security and privacy standards for the electronic handling of medical information.
Key HIPAA Rules
| Rule | Description |
|---|---|
| Privacy Rule | Regulations on the use and disclosure of PHI |
| Security Rule | Technical and administrative standards for protecting electronic PHI (ePHI) |
| Breach Notification Rule | Notification obligations in the event of a PHI breach |
Three Types of Safeguards under the Security Rule
| Safeguard | Description | Example in Smart Assist |
|---|---|---|
| Administrative safeguards | Security policies, risk analysis, training | Training through this textbook |
| Physical safeguards | Data center access control | Physical security of AWS data centers |
| Technical safeguards | Access control, encryption, audit logs | TLS encryption, authentication tokens |
BAA (Business Associate Agreement)
Under HIPAA, it is mandatory to execute a BAA (Business Associate Agreement) with external entities (Business Associates) that handle PHI. AWS supports BAA execution, enabling the construction of HIPAA-compliant environments.
9.4 GDPR (EU)
What Is GDPR?
GDPR (General Data Protection Regulation) is a data protection law that came into effect in 2018 and applies across the entire EU. It is a comprehensive regulation on the handling of personal data, with medical data requiring even stricter protection as "Special Category Data."
Key GDPR Principles
| Principle | Description |
|---|---|
| Lawfulness, fairness, and transparency | Data processing requires a legal basis |
| Purpose limitation | Data is collected only for clearly defined purposes |
| Data minimization | Only the minimum necessary data is processed |
| Accuracy | Data must be kept accurate and up to date |
| Storage limitation | Data is retained only for the period necessary for its purpose |
| Integrity and confidentiality | Data is protected with appropriate security measures |
Key Requirements for Medical Data
| Requirement | Description | Smart Assist Response |
|---|---|---|
| DPIA (Data Protection Impact Assessment) | Prior assessment is mandatory for high-risk processing (Article 35) | Required because the system handles medical data |
| DPA (Data Processing Agreement) | Contract between data controller and processor (Article 28) | Executed between the hospital (controller) and the vendor (processor) |
| DPO (Data Protection Officer) | Appointment is mandatory for large-scale processing of Special Category Data (Article 37) | Confirmed with the hospital |
| Data transfer restrictions | Legal basis required for transfers outside the EEA (Articles 44-49) | EU-based regions are used for EU deployments |
| Breach notification | Supervisory authority must be notified within 72 hours (Article 33) | Incident response procedures are in place |
Penalties for GDPR Violations
| Type of Violation | Penalty |
|---|---|
| Inadequate technical measures, etc. | Up to EUR 10 million or 2% of annual global turnover, whichever is higher |
| Violation of basic data processing principles | Up to EUR 20 million or 4% of annual global turnover, whichever is higher |
Related EU Regulations
| Regulation | Description |
|---|---|
| EU MDR (Medical Device Regulation 2017/745) | Regulation on medical devices. Also applies to SaMD (Software as a Medical Device) |
| NIS2 Directive | Cybersecurity requirements for critical infrastructure including healthcare institutions |
9.5 Three-Ministry Two-Guideline Framework (Japan)
What Is the Three-Ministry Two-Guideline Framework?
This is the common name for the guidelines governing the handling of medical information in Japan. It refers to the following two guidelines.
| Guideline | Governing Ministry | Target |
|---|---|---|
| Guidelines for the Secure Management of Medical Information Systems | Ministry of Health, Labour and Welfare (MHLW) | Medical institutions, pharmacies |
| Guidelines for Secure Management by Providers of Information Systems and Services Handling Medical Information | Ministry of Economy, Trade and Industry (METI) / Ministry of Internal Affairs and Communications (MIC) | Information system and service providers |
Key Requirements
| Requirement Category | Description |
|---|---|
| Organizational safeguards | Development of security policies, appointment of responsible personnel |
| Physical safeguards | Access control for server rooms, theft prevention for equipment |
| Technical safeguards | Access control, encryption, log management |
| Personnel safeguards | Employee training, enforcement of confidentiality obligations |
| External storage | Requirements for storing medical information in the cloud, etc. |
Requirements for Cloud Service Usage
The Three-Ministry Two-Guideline Framework specifies requirements for storing medical information in the cloud.
| Requirement | Description |
|---|---|
| Data center location | Preferably within Japan |
| Communication encryption | Use of appropriate encryption methods |
| Access control | Only authorized users may access the data |
| Audit logs | Recording and retention of access histories |
| Responsibility demarcation | Clarification of the scope of responsibility between medical institutions and vendors |
| Contracts | Execution of SLAs, procedures for data deletion |
Smart Assist Compliance Status
Smart Assist engineers need to be able to explain the following points to hospitals depending on the deployment region.
Common items (all regions):
- Communications are encrypted using TLS 1.2 or higher
- Access control and audit logs are properly implemented
- Responsibility demarcation is documented
Region-specific items:
| Region | Key Points to Explain |
|---|---|
| Japan | Uses the Tokyo Region (ap-northeast-1), and data is stored within Japan |
| US | BAA (Business Associate Agreement) has been executed with AWS. Operated in a HIPAA-compliant environment |
| EU | Uses an EU-based region, and data is stored within the EEA. DPA (Data Processing Agreement) has been executed |
9.6 Regulatory Comparison Summary
The following is a comparison summary of regulations across countries.
| Item | Japan | US | EU |
|---|---|---|---|
| Primary legislation | Act on the Protection of Personal Information (APPI), Three-Ministry Two-Guideline Framework | HIPAA, HITECH Act | GDPR, EU MDR |
| Legal classification of medical information | Sensitive Personal Information (requires special care) | PHI (Protected Health Information) | Special Category Data |
| Supervisory authority | Personal Information Protection Commission (PPC), MHLW | HHS OCR (Office for Civil Rights), FDA | National DPA (Data Protection Authority), EDPB |
| Breach notification obligation | Promptly (to the PPC) | Within 60 days (to HHS OCR, for 500+ records) | Within 72 hours (to national DPA) |
| Data storage location | Preferably within Japan | No explicit requirement (BAA execution is mandatory) | Within the EEA in principle (SCCs required for transfers outside EEA) |
| Contract for outsourcing | Documentation of SLA and responsibility demarcation | BAA (Business Associate Agreement) | DPA (Data Processing Agreement) |
| Penalties | Up to JPY 100 million (corporate), recommendations/orders | Up to approx. USD 2 million per violation/year | Up to EUR 20 million or 4% of annual global turnover |
| Medical device regulation | PMD Act (PMDA approval) | FDA 510(k) / PMA | EU MDR (CE marking) |
9.7 Data Retention and Responsibility Demarcation
Data Lifecycle
Data handled by Smart Assist requires rules regarding retention periods and deletion.
Considerations for Data Retention
| Consideration | Description |
|---|---|
| Retention period | How many days data is retained in the cloud after classification is complete |
| Purpose of retention | Quality control, re-verification, statistical analysis |
| Deletion method | Logical deletion or physical deletion; issuance of deletion certificates |
| Backups | Retention period and deletion of backup data |
Responsibility Demarcation Points
In the operation of Smart Assist, the scope of responsibilities between the hospital and the vendor must be clearly defined.
Key Points for Documenting Responsibility Demarcation
| Item | Description |
|---|---|
| Definition of demarcation points | Clearly specify physical and logical boundaries |
| Incident response | Contact information, escalation flow |
| Liability for data breaches | Methods for root cause investigation, criteria for determining liability |
| Periodic review | Reconfirm responsibility demarcation at contract renewal |
Legal Frameworks for Responsibility Demarcation by Region
| Region | Framework | Hospital Role | Vendor Role |
|---|---|---|---|
| Japan | Three-Ministry Two-Guideline Framework / SLA | Information management officer | Service provider |
| US | HIPAA / BAA | Covered Entity | Business Associate |
| EU | GDPR / DPA | Data Controller | Data Processor |
9.6 How to Read the Document: HIPAA Risk Assessment Report
Document Overview
"ARKRAY 2025 HIPAA Risk Assessment Report" is a report in which an independent third-party audit firm (ecfirst) evaluated ARKRAY's HIPAA compliance status. It was conducted in April 2025 and comprehensively assessed all items under the HIPAA Security Rule, Privacy Rule, and Breach Notification Rule.
Corresponding file:
ARKRAY 2025 HIPAA Risk Assessment Report
What Is a HIPAA Risk Assessment?
HIPAA Security Rule Section 164.308(a)(1)(ii)(A) requires Covered Entities and Business Associates to conduct periodic risk assessments. This risk assessment is "a process for identifying and evaluating potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI (electronic Protected Health Information)."
ARKRAY serves as a Business Associate in the operation of Smart Assist and conducts this risk assessment as a legal obligation.
Report Structure
| Section | Content | What Staff Should Understand |
|---|---|---|
| Executive Summary | Assessment overview, key findings, Compliance Report Card | Critical Findings: None -- No critical non-compliance issues were detected |
| SWOT Analysis | Analysis of strengths, weaknesses, opportunities, and threats | Evaluation of organizational security maturity |
| Security Rule Risk Analysis | Full item evaluation of administrative, physical, and technical safeguards | Compliance status and risk level for each control item |
| Privacy Rule Risk Analysis | Compliance status regarding rules on PHI use and disclosure | Appropriateness of PHI handling policies |
| Breach Notification | Evaluation of breach notification procedures | Preparedness of incident response framework |
Three Safeguards under the HIPAA Security Rule
The HIPAA Security Rule is divided into the following three categories. The risk assessment evaluates all of them.
| Category | Description | Examples of Evaluated Items |
|---|---|---|
| Administrative Safeguards (Section 164.308) | Administrative security measures | Security management processes, workforce security, access management, security awareness training, incident response procedures, contingency planning |
| Physical Safeguards (Section 164.310) | Physical security measures | Facility access control, workstation use/security, device and media controls |
| Technical Safeguards (Section 164.312) | Technical security measures | Access control (user ID/automatic logoff/encryption), audit logs, data integrity, transmission security (TLS encryption) |
How to Explain to Hospital IT Staff
| Question | Direction of Response |
|---|---|
| "Is there evidence of HIPAA compliance?" | We conduct an annual HIPAA Risk Assessment by an independent third party (ecfirst), and no Critical Findings have been detected |
| "Have all Security Rule items been assessed?" | All Implementation Specifications across Administrative / Physical / Technical Safeguards are included in the assessment scope |
| "Can we review the report?" | The report can be made available for review after executing an NDA. The report is treated as Confidential |
| "Are there Breach Notification procedures in place?" | Breach Notification procedures based on HIPAA Sections 164.404 through 164.414 are in place and have been evaluated in the report |
9.7 How to Read the Document: ISO/IEC 27001 Certificate
Document Overview
"MSA-IS-718 Certificate of Registration" is a certificate proving that UHW (Universal Healthware, Inc.), which develops and operates Smart Assist, has obtained ISO/IEC 27001:2022 certification.
Corresponding file:
MSA-IS-718_Certificate of Registration (English)
What Is ISO/IEC 27001?
ISO/IEC 27001 is an international standard for Information Security Management Systems (ISMS). It defines requirements for organizations to systematically manage information security risks and continually improve.
Certification Details
| Item | Details |
|---|---|
| Certification number | MSA-IS-718 |
| Certified organization | Universal Healthware, Inc. |
| Location | 59 Kanuincho, Kamigyo-ku, Kyoto (within Yojuin Temple) |
| Applicable standard | JIS Q 27001:2025 (ISO/IEC 27001:2022 Amd 1:2024) |
| Scope of certification | Software development and web service development/management for medical laboratory data management systems |
| Initial certification date | September 26, 2024 |
| Expiration date | September 25, 2027 |
| Certification body | Management System Assessment Center Co., Ltd. (MSA) |
Why ISO 27001 Certification Is Important
| Perspective | Explanation |
|---|---|
| Smart Assist development and operations are covered | The scope of certification explicitly includes Smart Assist software development and web service management |
| Complementary to SOC 2 | SOC 2 covers the AWS infrastructure layer; ISO 27001 covers the application development and operations layer. Combining both provides full-stack security assurance |
| Relationship with HIPAA Risk Assessment | HIPAA Risk Assessment evaluates regulatory compliance; ISO 27001 is an international standard certification for security management systems. They provide assurance from different perspectives |
How to Explain to Hospital IT Staff
| Question | Direction of Response |
|---|---|
| "Do you hold ISO 27001 certification?" | UHW, which develops and operates Smart Assist, has obtained ISO/IEC 27001:2022 certification (Certificate No.: MSA-IS-718, valid through September 2027) |
| "Does the certification scope include Smart Assist?" | The scope of certification is "Software development and web service development/management for medical laboratory data management systems," which includes Smart Assist |
| "Can you provide a copy of the certificate?" | An English-language certificate can be provided |
Overall Picture of Security Certifications and Assessments
The following provides an overview of the certifications and assessments related to Smart Assist.
| Certification/Assessment | Target | Assessor | Coverage |
|---|---|---|---|
| ISO/IEC 27001 | UHW (development/operations) | MSA (certification body) | ISMS for application development and operations |
| SOC 2 Type II | AWS (infrastructure) | Ernst & Young | Controls for cloud infrastructure |
| HIPAA Risk Assessment | ARKRAY (PHI handling) | ecfirst (third-party audit) | HIPAA regulatory compliance status |
| BAA | ARKRAY <-> Hospital | Contracting parties | Responsibility demarcation for PHI handling |
This three-layer structure (infrastructure -> application -> regulatory compliance) ensures that Smart Assist's security is evaluated and assured from multiple angles.
In the next chapter, we will learn practical troubleshooting techniques for issues that arise during the deployment and operation of Smart Assist.