Interactive example · fictional data
The conversation ended. The work did not.
Events, deadlines and owners keep the case active after the conversation, up to the confirmed appointment; the exam itself is a later event.
Conceptual demonstration. It does not represent a customer case or prove available features.
Video
Transcript
[Illustrative example · fictional data] [“My doctor ordered an MRI.” · 10:05] A patient says: the doctor ordered an MRI.
[NebulaOS · Starya builds and connects within the scope of the operation · Provider schedule] [Illustrative interface · Features and integrations depend on the deployment.] On NebulaOS, connected by Starya within the scope of the operation, the case is kept across channel, authorizations and schedule.
[Conversation ended · 10:20] [Case: open · waiting for the medical order] [Service desk · deadline Day 2, 09:00] [Day 1 · 13:10] [Medical order] The conversation ends. The case doesn’t: it stays open, with an owner and a deadline. The medical order arrives, and NebulaOS resumes the case.
[Authorization granted] [Provider schedule · Slot requested · 18:00] [Day 1 · 18:00 → Day 2 · 10:00] [Deadline passed · Scheduling team takes over] [Requests received · Scheduling team · Day 2 · 10:05] [Request · Day 1, 18:00 · recorded] [New deadline · Day 3, 10:05] Authorization granted. An authorization is not an appointment. The next day, the schedule doesn’t answer on time. The team checks that the request is recorded and contacts the provider, without repeating it.
[Day 2 · 14:05] [Appointment confirmed · exam pending] [Slot: day 4 at 07:30 · AG-7730 · fictional] [Patient informed · of the confirmed stage only · Day 2 · 14:10] [The exam itself, its result and the follow-up with the doctor come later.] The schedule confirms the slot, and only that stage is communicated. The exam itself is a later event.
[The conversation ended. The operation continues.] [Starya · We accelerate your AI strategy. NebulaOS is the operating foundation.] The conversation ended. The operation continues.
What confirms completion
The provider schedule confirms the slot, and only that stage is communicated to the patient. The exam itself is a later event.
What NebulaOS supports in this scenario
In this scenario, NebulaOS keeps the case with state, deadline and owner across the service channel, the authorization system and the provider schedule, connected within the scope of the operation, and resumes the work when an event arrives. Which events each system emits, and the follow-up deadlines, depend on the deployment.
- NebulaWorks Brings together the work, owners, pending items and process artifacts.
- Starya / FDE Tracks missed deadlines, reminders and late provider answers to adjust the follow-up deadlines.
Try it yourself
Walk through the steps of this scenario and see what changes with each choice. Fictional data; no system is accessed.
Open the simulation
Illustrative simulation · no system is accessed
The conversation ended. The operation continues until the next confirmation
Goal Take an MRI request from the conversation to a confirmed appointment, with the operation resumed by events, including on another day, and nothing communicated before it is confirmed.
- 01Request
- 02End of conversation
- 03Document
- 04Request authorization
- 05Authorization
- 06Request a slot
- 07Schedule
- 08Communicate
Simulation clock Day 1 · 10:05
What we know now · v1 · Day 1 · 10:05 · In progress · step 1 of 8
The message arrived: “My doctor ordered an MRI.”
The service desk opens the case with a state and an owner. The patient says they will send a photo of the medical order later.
Who answers now Service desk
System Service channel
Preserved history
Every event, deadline, decision and answer stays here, with the simulation time, in this session only. Starting over clears the simulation.
- v1 · Day 1 · 10:05Message from the patient: “My doctor ordered an MRI.”
Systems and responsibilities
| System | What it answers for | How it takes part |
|---|---|---|
| Service channel | Conversation, medical order sent by the patient and messages from the team | Receives the request and the documents. The team writes through it after the conversation ends |
| Authorization system | Status of the authorization for the exam | Receives the request and is the only one that grants the authorization |
| Provider schedule | Time slot for the exam | Receives the slot request and is the only one that confirms the appointment |
Questions to take to your team
- Systems and data Which event moves the task forward again?
- Systems and data How long can a response stay pending?
- Owner Who takes over when the deadline or the condition changes?
- Result Which confirmed step can be communicated, and what remains pending?
Use these questions with the guide What to ask about AI already in use
Related content
Steps
Owner, system, state and pending item of the experience’s 8 steps, with decisions and limits
Step 1 · Request
Today · open the case
The MRI request arrives in the conversation and the case is opened with a state and an owner. The medical order has not been sent yet.
- Owner
- Service desk
- System
- Service channel
- State
- Case opened
- Pending
- The medical order is missing.
Step 2 · End of conversation
Today · end the conversation
The conversation ends. The case stays open, waiting for the medical order, with a follow-up deadline.
- Owner
- Service desk
- System
- Service channel
- State
- Waiting for the document
- Pending
- Closing the channel does not close the task.
Step 3 · Document
Event · medical order received
The document arrives through the channel and resumes the case without a new conversation. If the deadline passes first, the service desk sends a reminder asking only for what is missing.
- Owner
- Service desk
- System
- Service channel
- State
- Document received
- Pending
- The authorization still needs requesting.
Step 4 · Request authorization
Request the authorization
With the medical order, the authorization is requested from the responsible source.
- Owner
- Authorization team
- System
- Authorization system
- State
- Authorization requested
- Pending
- Requesting is not authorizing.
Step 5 · Authorization
Event · authorization granted
The authorization answer arrives and allows a slot to be requested from the provider. An authorization is not an appointment.
- Owner
- Authorization team
- System
- Authorization system
- State
- Authorization granted
- Pending
- The slot still needs requesting.
Step 6 · Request a slot
Request the slot
The slot request goes to the provider schedule, the only system that can confirm it.
- Owner
- Scheduling team
- System
- Provider schedule
- State
- Slot requested
- Pending
- The provider’s answer is still missing.
Step 7 · Schedule
Event · appointment confirmed
The schedule confirms the slot. If it does not answer on time, the owner checks whether the request is recorded before repeating it and contacts the provider, without promising a time.
- Owner
- Scheduling team
- System
- Provider schedule
- State
- Appointment confirmed
- Pending
- The patient still needs to be told.
Step 8 · Communicate
Tell the patient
The scheduling team tells the patient only what was confirmed, with preparation instructions.
- Owner
- Scheduling team
- System
- Service channel
- State
- Patient informed
- Pending
- The exam itself, its result and the follow-up with the doctor come later.
Decisions to explore
- Late document
- Provider does not answer
- Events on time up to the confirmed appointment
Pending items and limits
- Authorization, appointment and the exam itself are separate confirmations, from separate systems.
- A reminder before the exam, the exam itself, its result and the follow-up with the doctor need events of their own and stay outside this scope.
- Follow-up deadlines, days and times are fictional.
Text version
The main content, without depending on the video or the simulation.
Initial request “My doctor ordered an MRI.”
The conversation ends, but the case continues with a state and an owner. The medical order, the authorization and the provider schedule arrive as events, including the next day. When a deadline passes with no answer, the owner acts before any new attempt. Only the confirmed stage is communicated; the exam itself and its result are future events.
The patient says the doctor ordered an MRI. The case is opened with a state and an owner, and the conversation ends while the medical order is awaited. When the document arrives, the case resumes and the authorization is requested; if the deadline passes first, the service desk sends a reminder asking only for the document. When the authorization is granted, the scheduling team asks the provider for a slot. If the schedule does not answer on time, the team checks whether the request is recorded before repeating it and contacts the provider, without promising a time. When the schedule confirms, the scheduling team tells the patient about that stage only. The exam itself, its result and the follow-up with the doctor are later events.