The EHR has been encrypted by ransomware. A USB stick has gone missing. A document intended for one patient was handed to another. In each case, separately from technical recovery, someone must decide whether a reporting duty has been triggered.
Looking this up mid-incident always costs time. Japan's Act on the Protection of Personal Information uses a two-stage structure — a preliminary report and a final report — each with its own deadline. And healthcare providers face a tighter threshold than most: clinical records are special-care-required personal information, so a breach of any size may be reportable.
This article organises the reporting decision so it can be embedded in an incident response plan. Because details change with amendments and interpretation, always confirm deadlines and forms against the Personal Information Protection Commission's own publications.
Disclaimer: This article is general information. The authoritative sources are the Act, its enforcement rules, the Commission's guidelines, and the guidance for medical and long-term care providers. Decide specific cases on the primary sources and legal advice.
When a Reporting Duty Arises
The Act requires reporting to the Commission, and notification of affected individuals, where a leak, loss, or damage to personal data carries a high risk of harming an individual's rights and interests. The categories are set out in the rules and can be summarised as follows.
| Category | Content | Healthcare example |
|---|---|---|
| Includes special-care-required data | Medical history, clinical records | EHR encryption or exfiltration, misdirected test results |
| Risk of financial harm | Data susceptible to fraudulent use | Leak of data including payment details |
| Committed with wrongful intent | Deliberate acquisition by a third party | Ransomware, unauthorised access, insider exfiltration |
| Large scale | Breaches above a defined number of individuals | Loss of an entire patient database |
The first category is decisive for healthcare. Because clinical information is special-care-required data, even a single record may be reportable. "Too few people to matter" is not an available argument.
Where ransomware encryption leaves even the provider unable to restore data, the event may need to be treated as loss or damage, or as a risk of leakage, even without confirmed exfiltration. How to treat the period when exfiltration is unknown is a contested question — consult specialists and counsel early (verify against primary sources).
Preliminary Report, Then Final Report
| Stage | Purpose | Content | Timing |
|---|---|---|---|
| Preliminary | Let the Commission learn of the case early | What is known so far; "under investigation" is acceptable | Promptly after discovery (commonly cited as roughly 3–5 days under the enforcement rules — verify against primary sources) |
| Final | The full picture and preventive measures | Cause, scope, response, prevention | Commonly cited as within 30 days, or 60 days where unauthorised access is involved — verify against primary sources |
Three practical points.
First, the preliminary report is not meant to be complete. Waiting for the investigation to finish blows the deadline.
Second, the clock starts at discovery, not at occurrence. Without a record of who knew what and when, you cannot evidence the start point — which is why the time-stamped log described in First Response to Ransomware matters.
Third, the final report deadline is also your investigation deadline. If an external investigation is needed, it must be commissioned during first response.
Notifying Individuals
Notification exists so people can protect themselves, which makes speed and clarity the priorities. Notices generally cover: what happened, which data items were involved, the cause, any secondary harm or risk of it, and what the individual can do, with a contact point.
The healthcare-specific difficulty is that the notice itself can expose sensitive information — a household member learns of a consultation; a returned undeliverable envelope creates a second problem. Choose the channel (post, telephone, explanation at the next visit) with the patient's circumstances and the nature of the data in mind.
Where notification is genuinely difficult, substitute measures such as public disclosure are available. "Difficult" is not a casual judgement, however: the reasons must be recorded in a form you can explain. Who decides on disclosure and who fields enquiries belongs in the incident response plan.
When the Breach Happens at a Supplier
Cloud-hosted EHRs, outsourced claims processing, third-party data centres: much of a provider's personal data sits in someone else's hands. A breach at a processor generally leaves the reporting duty with the provider who entrusted the data.
| Situation | Practical handling |
|---|---|
| Breach occurs at the supplier | Notifying the entrusting party can relieve the supplier of its own duty; the provider still must report (verify against primary sources) |
| The supplier does not tell you | You cannot know, and the clock starts late. Put a notification duty and deadline in the contract |
| Investigation depends on the supplier | You cannot assemble the final report. Contract for cooperation with investigations |
In other words, readiness to report only works if it is written into contracts: notification on detection with a time limit, cooperation with investigation, provision of logs and evidence, and reporting of preventive measures. See Writing SLAs and Demarcating Responsibility, Security Check Sheets for Vendors, and Demarcating Responsibility.
Building It into the Plan
| Artefact | Content |
|---|---|
| Decision flow | Starting from "does this include special-care-required data?" — built to lean toward reporting when unsure |
| Named roles | Who judges, who approves, who files |
| Record template | Time of discovery, discoverer, data affected, counts, cause, response — paper-capable |
| Contact list | The Commission, public health centre, counsel, specialist responders |
| Draft notices | Skeleton texts by incident type |
| Disclosure criteria and spokesperson | Who decides, who speaks |
Design the flow to lean toward reporting. The downside of failing to report something reportable exceeds the downside of over-reporting. In healthcare, the guidance for medical and long-term care providers applies alongside the general rules; for the wider guideline landscape see The Three-Ministry Guidelines.
For structures see Building a Security Governance Structure, and for awareness Designing Staff Training and Drills. Frontline staff recognising "this might be reportable" and escalating it is where the whole process actually starts.
Conclusion
- Clinical records are special-care-required data, so in healthcare even one record may be reportable
- Reporting is two-stage: a prompt preliminary report, then a final report covering cause and prevention (verify the day counts against primary sources)
- The deadline runs from discovery, so you need records of who knew when
- Notification serves self-protection; in healthcare the channel itself can expose sensitive facts
- A breach at a supplier still obliges the provider to report. Contract for notification and cooperation
- Hold it as a procedure, not knowledge: decision flow, templates, contacts — leaning toward reporting
Readiness depends on law, contracts, records, and frontline awareness together. Pottech advises on governance and supplier management from the standpoint of building and running medical information systems — contact us. To evaluate a supplier's management system, see What Is an ISMS (ISO/IEC 27001)?.
References and Sources
- Personal Information Protection Commission
- Guidelines for the Safe Management of Medical Information Systems | MHLW
- Information-technology Promotion Agency (IPA)
Note: whether reporting is required, and the deadlines, forms, and filing methods, may change with amendments and interpretation. The day counts given here are indicative; confirm the current position with the Commission's publications.