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

Messaging, Memo Desk and alert requirements

System-wide instant messaging

Internal only.

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

C0977Can staff message people outside the facility?

The system-wide instant messaging part of the specification (REQ-4001) says Instant messaging must be system-wide only: a message can be sent only to another workforce user or group of the same deployment/sphere. External addresses must be impossible by construction. It is one of the few requirements the pilot meets at MVP scope; nothing has touched real data. Pilot detail: Messages only between workforce users of the same clinic. Acceptance check: attempt to add an external recipient fails at the API.

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

C0978What kinds of message threads does the messaging system support?

How would it be tested? The specification says patient-linked thread lists only users with access rights to that patient. That is the check for REQ-4002: the IM must support direct, group/channel and patient-linked threads with membership rules per file 06. The pilot covers part of this. The rest is designed, not built. Where the code stands: Direct and group channels exist; no patient-linked threads.

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

C0979Does messaging keep working when the internet is down?

Not built. What the pilot has is a stand-in, not the feature. In the pilot: Works only while the Cloudflare hub is reachable; spec requires on-site, WAN-down operation. For reference, REQ-4003 (a top-priority requirement, all three tiers) says the IM must run on-site and work with the WAN down. Check: with WAN cut, two terminals exchange messages.

Designed, not yet builtPermalink

C0980What receipts does messaging give?

IM must carry delivery, read and acknowledgment receipts and audit MSG_READ events. That is REQ-4004, a high-priority requirement for all three tiers. The pilot covers part of this. The rest is designed, not built. What v0.2.0 does today: Delivered/read receipts exist; no acknowledgment receipt; IM read not audited. Test in the specification: receipts visible to sender.

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

C0981Are message attachments scanned and limited?

No. The specification describes it, but the pilot does not include it. REQ-4005 says IM attachments must be scanned and limited by class; PHI images follow media rules. Its acceptance check: infected file is quarantined.

Designed, not yet builtPermalink

C0982How long are messages kept?

REQ-4006 is a top-priority requirement for all three tiers: IM retention must be configurable by class within legal minimums; clinical content in patient-linked threads follows the clinical retention rule. Not yet. It is designed in the specification and not built in the pilot. To verify it, the specification says retention policy cannot be set below profile minimum.

Designed, not yet builtPermalink

C0983Can a chat status like Do Not Disturb delay a code alert?

The system-wide instant messaging part of the specification (REQ-4007) says IM must never suppress or delay a code alert; presence DND must not affect code alerts. It is one of the few requirements the pilot meets at MVP scope; nothing has touched real data. In the pilot: Alerts are a separate path; DND bypass for P0/P1. Acceptance check: dND user receives Code Blue.

In the pilot (v0.2.0, synthetic data)Permalink
See the synthetic-data demo first.Request a demo