AuroraMed v0.2.0 is a synthetic-data pilot. See exactly what's built →

Clinical safety

Safety principles: care first

The design rule is care first, confidentiality second in emergencies, audit third and always after the fact.

How to read status labels: In the pilot (v0.2.0, synthetic data) Simulated in the pilot Coming (Wave 2, rolling out) Designed, not yet built Open decision Not offered / no claim made Planned partner integration

C0001Could a security control ever lock a clinician out during an emergency?

The design forbids it: no security component may be a hard single dependency for emergency access. Break-glass exists for declared emergencies, with mandatory after-the-fact review. The pilot implements break-glass with reason codes and review; the wider emergency ladder is designed.

Designed, not yet builtPermalink

C0002What happens when a nurse needs a chart they are not assigned to?

In the pilot, chart access is scoped by care relationship. A clinician can declare break-glass with a reason code and text. Access is time-limited, raises a security alert, and forces a privacy review afterwards.

In the pilot (v0.2.0, synthetic data)Permalink

C0003Does AuroraMed replace a doctor's clinical judgment?

No. Decision support beyond simple alerts is out of scope for now. Any AI feature is designed to be off by default and to produce drafts that a human must accept.

Designed, not yet builtPermalink

C0004Is AuroraMed a certified medical device?

No. The pilot is not a medical device, is not cleared by any regulator, and must not be used for real patient care. Device classification of any future function is an open legal question.

Not offered / no claim madePermalink

C0005Who is responsible for the clinical meaning of alert codes?

The facility. Code meanings vary by state and hospital, so AuroraMed ships editable templates labelled typical usage, and each facility sets its own meanings with dual approval.

Designed, not yet builtPermalink

C0006Can a single administrator change an alert policy quietly?

No. In the pilot, alert policy and code-catalog changes are proposed by one person and must be approved by a different person. Every alert stores the version of the definition it used.

In the pilot (v0.2.0, synthetic data)Permalink

C0007How does the system avoid alert fatigue?

Priorities separate full-screen emergencies from banners and toasts, and Do-Not-Disturb silences only the lowest classes. Routine pings are rate-limited per user while emergency alerts are exempt. Tuning against real workloads is still to be done.

Designed, not yet builtPermalink

C0008Are critical lab results guaranteed to reach a clinician?

The design escalates unacknowledged critical results to an alternate clinician, then a supervisor. The pilot files results to the chart and alerts the care team, with a fallback chain when no care team exists, using synthetic data. No live lab connection exists.

Designed, not yet builtPermalink

C0009Is a blank allergy list treated as "no known allergies"?

Never. The pilot records allergy status explicitly as unknown, none, or active allergies, so an empty list cannot read as safe.

In the pilot (v0.2.0, synthetic data)Permalink

C0010Can a medication list be saved without reviewing each drug?

In the pilot, medication reconciliation will not save until a decision is recorded for every active medication: continue, stop, or change.

In the pilot (v0.2.0, synthetic data)Permalink

C0011Does the system check drug interactions?

Not yet. Interaction checking belongs to a later decision-support package and is not part of the pilot. Nothing on this site should be read as a clinical decision-support claim.

Designed, not yet builtPermalink

C0012Who validates critical-value thresholds?

The clinical committee of each customer. The design ships no authoritative lists; critical value lists and early-warning thresholds are open clinical content that the facility owns.

Open decisionPermalink

C0013How are unsafe design changes prevented from reaching production?

The design calls for a clinical safety case, signed releases, staged rollout and a change log. Only part of that exists in the pilot. A formal clinical safety process is still to be adopted.

Designed, not yet builtPermalink

C0014Is there a record of who acknowledged an urgent alert?

Yes in the pilot: an acknowledgement roster shows delivered, displayed, and acknowledged per recipient, and history is readable by privacy and governance roles.

In the pilot (v0.2.0, synthetic data)Permalink

C0015What if two people disagree on a patient record merge?

Merges are two-person. The pilot performs a virtual merge that a second person approves, and it can be unmerged, so a wrong merge is reversible.

Designed, not yet builtPermalink

C0016Can duplicate patient records be created by mistake?

The pilot warns live on likely duplicates using deterministic and fuzzy matching at registration. Matching has not been tuned on real data, so staff still verify identity.

In the pilot (v0.2.0, synthetic data)Permalink

C0017Are downtime procedures part of clinical safety?

Yes in the design: a read-only emergency data set on encrypted appliances, sealed printed reports and paper forms, with drills for each unit. The pilot has no downtime mode yet.

Designed, not yet builtPermalink

C0018What clinical safety standard will AuroraMed follow?

Undecided. Whether standards such as IEC 62304 or ISO 14971 apply, and which, is an open item for the owner, the clinical lead and counsel.

Open decisionPermalink

C0019Does AuroraMed guarantee no patient harm?

No software can, and no such guarantee is made. The design aims to reduce risk and make every action traceable.

Not offered / no claim madePermalink

C0020How will near-misses be captured?

Quality and safety roles are designed to review incident data in minimum-necessary form. A reporting workflow is not part of the pilot.

Designed, not yet builtPermalink
See the synthetic-data demo first.Request a demo