Mahlis product
Vitalis OS
An offline-first healthcare environment being designed around dependable local operation, controlled updates and recovery.
Current status: Architecture and prototype development
The operating problem
Healthcare work does not stop when an internet connection becomes slow, unreliable or unavailable. Workers may still need to open approved reference information, document an activity or recover a device safely.
Vitalis OS is being designed around that operational reality. Essential local functions should remain available without treating network access as a permanent requirement.
Design direction
Offline-first operation
Approved local functions should continue working when a network is unavailable.
Controlled updates
Updates should be authenticated, reviewable and recoverable instead of silently changing the system.
Clear responsibilities
Identity, permissions, auditing, storage and recovery should have understandable boundaries.
Dependable recovery
Backup and recovery procedures should be planned before a system is trusted with important work.
Vitalis Kernel
Development begins with the Vitalis Kernel: the small technical core responsible for identity, permissions, auditing, storage boundaries and package verification. Keeping the core focused makes its responsibilities easier to inspect and test.
The kernel is not being presented as a finished clinical product. It is the technical foundation being explored before wider healthcare workflows are added.
Prototype scope
- Boot and operate in a controlled offline environment.
- Separate user identity from application permissions.
- Record understandable local audit events.
- Verify approved software packages before installation.
- Test backup, restore and safe recovery procedures.
- Document hardware and operational assumptions.
Current boundaries
Vitalis OS is not currently a certified medical device, electronic medical record system or replacement for clinical judgment. It is not approved for diagnosis, treatment decisions or emergency use.
Security and compliance documentation support development readiness. They do not themselves establish regulatory approval or compliance certification.
What comes next
- Complete the small kernel architecture.
- Build and test the first offline prototype.
- Document threat, recovery and update models.
- Test workflows with appropriate healthcare participants.
- Review findings before defining a controlled pilot.