Case posting, OT review, anaesthesia review, pre-op checklist completion, inventory readiness, admin visibility, surgery progression, and post-op closure are separate steps.
01 / 10
Stakeholder review deck
Aetheris Perioperative Intelligence
Stakeholder Review for Hospital Reviewers
Non-production POC review: synthetic data, draft-only AI, workflow feedback only.
Not production ready
Not clinical validation
Not integration readiness
02 / 10
Problem
Problem
Perioperative readiness is often fragmented
A surgical case may look scheduled while important readiness items are still unresolved.
Different roles often own these steps and coordinate through informal channels.
When blockers are not visible early, delays, postponements, coordination work, and audit gaps can increase.
Does this match how surgical coordination actually breaks down in your setting?
03 / 10
What Aetheris is
Proposed role
A focused perioperative workflow layer
Aetheris is intended to support the perioperative workflow around surgical cases. It is not positioned as a full hospital information system.
- Surgical case lifecycle
- OT review and scheduling readiness
- Anaesthesia readiness
- Pre-op checklist status
- Inventory and equipment readiness
- Basic insurance and admin visibility
- Day-of-surgery movement
- Post-op closure status
- Draft-only AI support
- Workflow audit evidence
Aetheris should support coordination and visibility. It must not replace human clinical judgment or hospital governance.
04 / 10
Current POC
Current POC
Read-only, synthetic, non-production dashboard
The current POC is a controlled demonstration of a proposed workflow model.
- Synthetic surgical cases only
- Mock hospital, patient, encounter, role, and workflow context
- Separate readiness channels rather than one generic status
- Example complete, blocked, and postponed journey patterns
- Draft-only AI labels and review states
- Seeded audit-style timeline evidence
What it does not do
- Use real patient data
- Call CARE runtime APIs
- Connect to Open Health Network or production systems
- Create, update, approve, prescribe, bill, send, finalize, clear, or close clinical records
- Prove production authentication, authorization, audit compliance, clinical validation, or operational readiness
05 / 10
Under-the-hood process
Under the hood
Structured workflow signals, not autonomous decisions
Approved hospital context may later come from HIS, CARE, Open Health Network, or other validated systems.
Aetheris would maintain surgical case status, OT review, readiness channels, blockers, postponement reasons, and audit events.
Role owners review or update relevant workflow state according to hospital policy.
AI may generate draft summaries, prompts, handoff notes, or audit summaries from approved structured inputs.
A human reviewer must accept, edit, reject, or ignore every AI draft before use.
Audit evidence preserves who did what, when, why, and from which source.
AI drafts assist review. They do not make decisions, clear readiness, or finalize clinical content.
06 / 10
CARE / Open Health Network status
Integration boundary
Future integration area, not current runtime validation
- CARE and Open Health Network are not integrated in the current POC.
- Mock CARE context is synthetic and not validated CARE runtime behavior.
- No CARE runtime API calls are made by the current POC.
- No Open Health Network production or staging connection is claimed.
Possible future role after validation
- Patient and encounter context
- Facility and location context
- User, role, and permission context
- Resource or form references where supported
- Links between hospital context and Aetheris workflow objects
Which data should remain in HIS/CARE/Open Health Network, and which workflow data should Aetheris own?
07 / 10
Responsibility split
Responsibility split
Keep ownership explicit
| Area | Likely owner |
|---|---|
| Patient identity, encounter, facility, and core hospital context | HIS / CARE / Open Health Network, if validated and approved |
| Surgical case lifecycle, OT review, readiness channels, blockers, postponement, workflow audit | Aetheris perioperative workflow layer |
| Anaesthesia readiness and clinical review | Authorized anaesthesia team |
| Pre-op checklist completion | Authorized nursing or pre-op team |
| Inventory and equipment readiness | Stores, inventory, biomedical, or OT operations team |
| AI draft review and clinical or operational decisions | Authorized human reviewer and hospital staff under hospital policy |
Aetheris can make readiness visible. Humans remain responsible for decisions and approvals.
08 / 10
Demo journeys
Demo journeys
Three synthetic journey patterns
Use the demo to review patterns without relying on real patient data.
Complete journey
Case posting, OT review, readiness completion, final confirmation, day-of-surgery movement, post-op closure, draft review, and audit evidence.
Blocker journey
Shows why provisional scheduling should not be confused with final readiness.
Postponed journey
Shows postponement reason, ownership, deferred readiness, and traceable next action.
Separate readiness channels
Clear owners
Draft-only AI
09 / 10
Feedback needed
Feedback
Validate workflow truth before product decisions
- Does the workflow reflect real perioperative coordination?
- Which roles are missing or incorrectly assigned?
- Which readiness channels are essential before final OT confirmation?
- Which blockers most often delay or postpone surgery?
- Which status names match hospital practice?
- Which sign-offs are required, and by whom?
- Which data should come from HIS, CARE, Open Health Network, inventory, or billing systems?
- Which AI draft use cases are useful, unsafe, or governance-sensitive?
- What evidence would leadership, quality, or audit teams need?
- What must be true before any pilot discussion?
10 / 10
Next steps
Next steps
Convert feedback into a responsible validation path
The immediate goal is feedback on workflow fit, not production approval.
- Run the stakeholder demo with clear non-production and synthetic-data boundaries.
- Capture feedback in the stakeholder requirements matrix.
- Separate must-have workflow requirements from later-stage ideas.
- Confirm role ownership, sign-offs, blockers, escalation paths, and audit evidence.
- Identify what must remain in HIS/CARE/Open Health Network versus what Aetheris should own.
- Define AI draft governance: allowed drafts, reviewers, labels, audit trail, and prohibited uses.
- Prepare a pilot-readiness gap list only after workflow requirements are confirmed.
- Plan separate validation for privacy, security, access control, integration, auditability, clinical governance, and CARE/Open Health Network runtime behavior.
Presenter reminder:
This is a non-production Aetheris POC using synthetic demo data only. It does not connect to CARE, Open Health Network, or any hospital production system. AI outputs are draft-only and require human review.
After reviewing the demo, please share workflow-level feedback using the stakeholder feedback form. Do not enter patient information, confidential hospital data, credentials, production URLs, passwords, API keys, or sensitive operational details.