Clinical Safety Standard
Responsible AI governs how our models behave. This standard governs what happens when they are wrong — how we identify clinical hazards, control them, and refuse to ship without doing so.
Intended use, and its limits
eazyCare.Ai provides health information, symptom guidance and access to licensed healthcare professionals. It helps a person understand what they may be experiencing and decide what to do next, and helps clinicians prepare for and follow up on consultations.
eazyCare.Ai does not diagnose, does not prescribe, and is not a substitute for professional medical assessment. It is not intended for use in a medical emergency — in an emergency, contact local emergency services.
Software of this kind can fall within medical-device regulation depending on what it claims to do and the jurisdiction it operates in. We assess classification per market before launch, and treat the applicable regulatory requirements as binding rather than optional. Where a feature would move us across that boundary, the classification assessment happens before the feature is built, not after.
The clinical risk management cycle
Every feature that touches clinical information moves through these six stages. A feature that has skipped one is not ready to release.
Define intended use
Before building, state what the feature does clinically, who it is for, and — just as importantly — what it must never be relied on to do.
Identify hazards
Work through what happens when the feature is wrong, unavailable, or misused in a way that is reasonably foreseeable. Each hazard is logged with severity and likelihood.
Apply controls
Design mitigations that do not depend on the model behaving correctly. Deterministic checks, mandatory escalation routes and human handoff are preferred over prompt instructions.
Clinical review
A qualified clinician reviews the hazard analysis and residual risk for anything touching triage, escalation or clinical guidance.
Release gate
Residual risk must be acceptable and documented before release. Unresolved hazards above minor severity block the release rather than being deferred.
Post-market surveillance
Monitor for safety signals in live use, accept incident reports from users and clinicians, investigate them against the hazard log, and feed findings back into the cycle.
Known hazard categories
The failure modes we consider inherent to an AI-assisted health platform, and the controls that address them. This is a starting register, not the whole hazard log — feature-level hazards are added as features are designed.
| Hazard | Example | Severity | Control |
|---|---|---|---|
| Missed red flag | A user describes symptoms of a stroke, heart attack or sepsis and is not escalated to emergency care. | Catastrophic | Red-flag pattern matching runs independently of the model. Emergency escalation content is mandatory in symptom-related output and is verified by an automated check before release. |
| False reassurance | Output implies a serious presentation is benign, and the user delays seeking care as a result. | Major | No diagnostic or prognostic phrasing permitted. Uncertainty is stated explicitly, and every symptom flow ends with a route to professional assessment. |
| Incorrect medication information | A specific dose is stated, or a user is told to start, stop or change a medication. | Catastrophic | Dosage output is blocked at the safety-audit layer. Medication questions are routed to a clinician rather than answered generatively. |
| Outdated clinical guidance | Content reflects a superseded guideline or threshold after the underlying standard changes. | Major | Published health content carries source citations and is re-audited on a scheduled cadence, with a defined review interval for guideline-dependent material. |
| Language or translation error | Clinical meaning shifts in translation across the languages used in our markets. | Major | Clinical content is validated per language rather than machine-translated from a single source, and evaluation is reported per language. |
| Record attribution error | Health data is shown against the wrong patient, or a clinician sees a record they should not. | Catastrophic | Role-based access separation between patient, doctor and clinic contexts, with identity checks on every record read. |
| Over-escalation | Excessive urgency causes avoidable anxiety and unnecessary load on emergency services. | Moderate | Escalation thresholds are clinically reviewed and tuned, not set by model confidence alone. |
Rules for developers
Check your work against these before opening a pull request that touches clinical behaviour.
You must
- →Write an intended-use statement for any feature touching clinical information, including what it explicitly does not do.
- →Add a hazard-log entry before building a feature that could influence a care decision.
- →Keep red-flag and emergency-escalation logic deterministic and independently testable — never solely model-generated.
- →Preserve a route to a human clinician at every step of a clinical flow.
- →Treat a clinical-safety defect as a release blocker, at any severity above minor.
- →Record the clinical source for any threshold, cut-off or guideline value in code.
You must not
- ×Ship a change to triage, escalation or clinical-content logic without clinical review.
- ×Let a model decide, unaided, whether a presentation is an emergency.
- ×Present AI output as a diagnosis, prognosis or treatment recommendation.
- ×Remove a disclaimer, escalation path or safety check to simplify a screen.
- ×Expand what a feature clinically claims to do without updating its intended-use statement and hazard entries.
- ×Assume a threshold validated in another population applies unchanged in ours.
Standards this is built on
Clinical safety is a solved discipline with established standards. We follow them rather than improvising.
DCB0129 / DCB0160 — Clinical Risk Management for Health IT
The clinical safety process we model ours on: a named Clinical Safety Officer, a maintained hazard log, and a Clinical Safety Case Report produced before release and updated after material change.
ISO 14971:2019 — Risk Management for Medical Devices
Risk identification, estimation, control and residual-risk evaluation across the product lifecycle, including risk arising from reasonably foreseeable misuse.
IEC 62304 — Medical Device Software Lifecycle
Software safety classification, structured development and maintenance processes, and problem resolution for software in a health context.
IEC 82304-1 — Health Software Product Safety
Product-level safety requirements for health software distributed without dedicated hardware.
IMDRF — Software as a Medical Device framework
Risk categorisation based on the significance of the information provided and the seriousness of the health situation, plus clinical evaluation expectations.
Regional regulators
Malaysia's Medical Device Act 2012 (Act 737) and MDA guidance; Singapore HSA software medical device guidelines and MOH's AI in Healthcare Guidelines; Indonesia's Ministry of Health requirements; and the Philippine FDA — assessed per market as we launch in each.
Building against a standard is not the same as being certified against it. eazyCare.Ai is pre-launch and holds no certifications — see security for exactly where we stand.
Report a clinical safety concern
If you are a patient, clinician or researcher and you believe something on eazyCare.Ai could lead to harm, tell us. Safety reports are investigated against our hazard log, and we would rather hear about a false alarm than miss a real one.
safety@eazycare.aiRead alongside our Responsible AI Standard.