Platform
AuroraMed Packaging
The engine that assembles a customer-specific version of AuroraMed from a signed configuration: a modular, puzzle-piece approach with safety pieces that cannot be removed.
How it works
A runtime that only shows what a signed manifest allows
Choose
Pick modules from a catalog of 13, set brand, permissions, chain of command, alert catalog, layout and form fields.
Validate
Live checks refuse settings that would lower a safety or privacy floor, or grant a sensitive permission below its tier.
Sign and build
The manifest is signed, and can produce a signed package, a static web bundle or a customer-named Windows portable app.
Publish with two people
Two different vendor operators must propose and approve. The hub re-verifies the signature and floors, and the push is written to the audit chain.
Proven presets
| Small Clinic | Hospital | |
|---|---|---|
| Look | Light teal | Dark blue |
| Modules | No Memo Desk, code catalog, break-glass or privacy views | All 13 |
| Passwords | 12 characters minimum | 14 characters minimum |
| Chain of command | Preset default | Four levels |
Two layers of control
A disabled module is not shown in the app, and its server routes refuse requests for that customer. Hiding a menu item is never the only control. The same floors are applied again when the app runs, so a forged manifest cannot raise privileges.
Honest limits
- Custom fields, reports and templates, a rollback screen and staged rollout are not built.
- Signing uses a demo key. Production key custody is undecided.
- Customers are separate facilities on one shared hub. A dedicated deployment per customer is planned, not built.
- The engine app and customer builds are unsigned and have not been run on Windows beyond the developer's own machine.
- A customer-facing demo-mode switch is not documented as built.
Curious how your clinic would be assembled?
Tell us your size and roles; we will show a preset on synthetic data.