MDMatrix AIDemo
guide
Healthcare operations · Demo guide

Explore the cases.
See what happens next.

Follow the work from patient preparation to payment. Choose an example to see its context, evidence, and next staff action.

79Synthetic
patient stories
20Claims across
13 statuses
25Authorization
examples
One connected dataset. Cases appear across multiple workflows.

Schedule & preparation

25 upcoming visits and 5 appointment histories.

Synthetic examples
30 examples

A four-case walkthrough

Start with preparation, then follow the revenue story.

01 · PreparationA missing PCP referral02 · Claim correctionA rejected subscriber ID03 · Staff reviewAn appeal awaiting review04 · Payment historyA payment after appeal
The app, in plain English

What is a workflow?

Jump to every screen ↓

Think of each patient as a folder. The screens help different people look after that folder: when the visit happens, what is missing, who needs to act, and whether the bill was paid. A workflow is the shared checklist that keeps the next step clear.

  1. 1Something needs attention
  2. 2Read the facts
  3. 3Prepare the next step
  4. 4Check ownership & approval
  5. 5Save what happened

The map is the checklist. The case is the record. Workflow settings describe the intended path. Open an individual work item to see its actual messages, decisions, and receipts.

The three workflows in the settings screen

01

Patient readiness

Get the paperwork ready before the visit.

Starts when
An upcoming appointment has an administrative gap.
MIRAI checks
Read the booking, insurance, referral, and preparation evidence.
MIRAI prepares
A task that says what is missing, who owns it, and when it is due.
A person handles
Staff resolve the missing information. Clinical readiness remains a clinician's decision.
Saved result
The task and its evidence are saved with the visit. A ready badge does not mean a clinical clearance or a new booking.
S15: Neil Porter has an appointment, but the PCP referral is missing. Staff need to obtain the document.
02

Revenue recovery

Find what is stopping a bill from moving forward.

Starts when
A completed visit has a claim or billing exception.
MIRAI checks
Read the claim, its responses, and the supporting administrative evidence.
MIRAI prepares
A claim review packet explaining the issue and proposed next step.
A person handles
The billing team reviews the proposal. Any supported action must follow the existing permissions and approval rules.
Saved result
The review and action receipt stay with the claim. Preparing a packet does not mean the insurer received a claim or paid it.
C03: Carlos Rivera's claim is held because a required referral is missing. The next step is evidence collection.
03

Post-visit handoff

Give the next team what it needs after the visit.

Starts when
A verified completed encounter needs a documentation or billing handoff.
MIRAI checks
Check the encounter and its outstanding documentation or coding-review requirements.
MIRAI prepares
An administrative handoff showing the remaining work and its owner.
A person handles
Staff complete and verify the source work. Clinicians handle clinical documentation and signing.
Saved result
A recorded handoff and clear follow-up. The scheduled end time alone does not prove the patient attended.
S27: Eva Morgan's visit is complete, but the signed summary is still missing. Staff request the summary.

How everyday work fits into that picture

BillingPut the visit's bill in order.

Start with the visit and supporting records. Check the patient, payer, services, and required evidence. Staff resolve gaps and review the next supported submission step. The claims screen then keeps track of responses and balances.

C04 shows a packet ready for review before submission. ↗
Pre-approval / prior authorizationTrack the insurer's required review before the service.

Collect the service and supporting information, track the payer's status, and assign anything still needed. If the payer requests a clinician conversation, clinical staff handle that step. An appointment can be booked while authorization still needs work.

S19 shows a peer-to-peer review request awaiting the clinician's next step. ↗
Rejections, denials, and appealsRead why the bill stopped, then fix or challenge the right thing.

A rejection means the submitted claim was not accepted for processing; a denial is a payer decision on payment. Staff review the reason and supporting evidence, then use the appropriate correction or appeal path. Payment is a separate result that needs its own evidence.

C07 is a rejection, C12 is an appeal draft, and C14 is a different patient's historical payment after appeal. ↗
Referral and patient intakeHelp a patient get from a referral to a usable intake record.

A referring office supplies the request. The patient completes the requested information and consent steps. Staff review missing details and prepare the handoff. The new examples are in MIRAI and Intake Records; the separate Referrals screen retains its original examples.

P07 shows Diego Ramos partway through the Spanish-language intake. ↗
Open-slot coordinationFind a suitable patient for a possible opening.

Check the time, service, location, preparation lead time, and patient response. An accepted offer still needs a confirmed booking. This guide's opening cases are coordination scenarios; they do not reserve capacity or demonstrate a live waitlist engine.

O17 shows an accepted offer with booking still unconfirmed. ↗
Cancellation and no-show follow-upMake the next contact clear when a visit does not happen.

Keep the canceled or missed appointment in its history, assign staff follow-up, and review a future date with the patient. A missed appointment in the past does not create a bookable slot in the past, and a callback request is not a new confirmation.

S29 shows Julia Park after a missed visit, asking to rebook. ↗

What the work statuses mean

Needs staff
A person has a decision or next step.
Working
The system has recorded work in progress; inspect the case for the actual step.
Waiting
The next step depends on a response or another event.
Blocked
Something required is missing or prevents progress.
Failed
An attempted step did not complete; review the reason.
Completed
This work item is complete. It does not mean every part of the patient's journey is complete.
Simulated
This evidence is a demonstration, not proof of a real external action.
A screen-by-screen guide

What is each screen for?

Back to examples ↑

Each screen answers a different question. Navigation depends on the signed-in role and clinic configuration.

For the clinic team

MIRAIThe team's shared to-do list.
The question it answers
What needs attention, and who is handling it?
What you do here
Open a work item, read the next step, and see whether it is waiting, blocked, or complete.
A simple example
Find Neil Porter's missing-referral task.
Open this screen in MDMatrix ↗
MIRAI case workspace and conversationOne job's folder and conversation.
The question it answers
What happened on this particular case?
What you do here
Read its messages, proposed action, saved output, and event history. An output marked simulated is a demo example.
A simple example
C07 keeps the rejected claim and its administrative review together.
WorkflowsThe rulebook for repeating jobs.
The question it answers
Which steps should this kind of work follow?
What you do here
Review the configured path, responsible team, target time, and escalation time. The map describes the path; the case records actual progress.
A simple example
Patient readiness prepares an owned administrative task.
Open this screen in MDMatrix ↗
Patient FlowThe clinic's big-picture scoreboard.
The question it answers
How many people start and finish the patient journey?
What you do here
Review counts and trends, then narrow the reporting period or other available filters.
A simple example
Compare completed intake activity with unfinished journeys.
Open this screen in MDMatrix ↗
Schedule — calendarThe appointment book.
The question it answers
Who is coming, when, and where?
What you do here
Choose a date, provider, or location and open a patient visit.
A simple example
September 15 contains ready, blocked, and review examples.
Open this screen in MDMatrix ↗
Schedule — preparation and visit detailThe checklist beside the appointment.
The question it answers
What still needs to happen before or after this visit?
What you do here
Inspect each requirement, its source evidence, attendance history, and staff next step.
A simple example
S22 has authorization approval but unconfirmed preparation pickup.
Open this screen in MDMatrix ↗
Intake Records and record detailThe information the patient has supplied.
The question it answers
What do we already know, and what is incomplete?
What you do here
Open the patient's record to inspect answers, administrative information, events, and available chart handoff evidence.
A simple example
P07 is an unfinished Spanish intake record.
Open this screen in MDMatrix ↗
ScreeningA closer look at how patients move through screening.
The question it answers
Where do people stop, and which outcomes are recorded?
What you do here
Inspect the screening funnel, outcome mix, channels, languages, and completion trend. This staff screen reports recorded activity.
A simple example
The guide includes direct-access, GI-consult, no-action, and unfinished examples.
Open this screen in MDMatrix ↗
Prior AuthThe insurer-review checklist before a service.
The question it answers
Is a review needed, and what is its current status?
What you do here
Review the packet, missing information, payer status, deadlines, and notes.
A simple example
S19 needs peer-to-peer review; S13 has an expired authorization.
Open this screen in MDMatrix ↗
Payer & Claims — queue and case detailThe bill tracker.
The question it answers
Which claim is stuck, and what is the next billing action?
What you do here
Open a claim to see its issue, evidence, administrative work, history, and balances.
A simple example
C15 has both a remaining payer balance and a patient balance.
Open this screen in MDMatrix ↗
Payer & Claims — overview and stage viewsDifferent shelves for different billing work.
The question it answers
How is billing progressing, and which group should the team work on?
What you do here
Use the overview and available stage views to focus on the relevant billing or referral-performance records.
A simple example
Separate a claim needing correction from one waiting for a payer response.
Open this screen in MDMatrix ↗
Referrals — referral queueRequests coming from referring offices.
The question it answers
Who is waiting on a patient, missing information, or ready for handoff?
What you do here
Select a referral and inspect its stage, patient details, and delivery history. This screen has its own existing fixture set.
A simple example
Waiting on patient and Sent to team are different stages.
Open this screen in MDMatrix ↗
Referrals — patient requests and today's visitsTwo focused lists beside the referral queue.
The question it answers
Which patients asked for help, and which related visits are happening today?
What you do here
Switch to Patient requests or Today's visits to review the corresponding records and available staff actions.
A simple example
A patient's request can need office follow-up before it becomes a completed referral.
Open this screen in MDMatrix ↗
Referrals — new, share, and settingsPrepare the front door for a referral.
The question it answers
How does an office create or share a referral request?
What you do here
Use the new-referral form, the share-link/QR screen, or referral-specific settings as appropriate.
A simple example
Share a referral entry point separately from a staff-only case link.
Open this screen in MDMatrix ↗
Clinic confirmations and operator reviewThe clinic's decision desk.
The question it answers
Has the clinic accepted a pending appointment request?
What you do here
The authorized clinic operator reviews its scoped queue and records the permitted decision. Access depends on the clinic and role.
A simple example
A patient request awaiting clinic confirmation is not yet a confirmed visit.
DomainsThe address book for clinic website names.
The question it answers
Which clinic should a website address open?
What you do here
Platform administrators inspect and manage the relevant hostname mappings.
A simple example
A clinic's public website address is different from its staff workspace.
Open this screen in MDMatrix ↗
Tenants — clinic detail and configurationSeparate settings for each clinic workspace.
The question it answers
Which clinic's rules and configuration are we managing?
What you do here
Platform administrators select a tenant and inspect its details and configuration. Tenant scope keeps work assigned to the right clinic.
A simple example
The seeded examples belong to the default demo tenant.
Open this screen in MDMatrix ↗
Sign-inThe key to staff-only screens.
The question it answers
Which staff account and workspace am I using?
What you do here
Sign in with an existing account. What appears in navigation depends on the account's role and demo profile.
A simple example
Public guide links do not give someone staff access.
Open this screen in MDMatrix ↗

For patients and referring offices

Clinic home, doctors, locations, and appointment entryChoose where to start.
The question it answers
Which doctor, location, or appointment path fits the patient's request?
What you do here
Browse the clinic's directory or enter its supported appointment-request flow.
A simple example
Starting a request does not itself book a visit.
Screening questions and resultAnswer questions and see the recorded next path.
The question it answers
What does the existing screening flow say happens next?
What you do here
Complete the clinic's questions and read the explanation for the displayed outcome.
A simple example
Direct access, GI consult, and no action are separate recorded outcomes; this guide does not calculate them.
Patient information and consentTell the clinic who you are and complete the required consent steps.
The question it answers
Whose record is this, and which required steps remain?
What you do here
Provide the requested identity and contact details and review the applicable consent prompts.
A simple example
P04 is an example of unfinished identity capture.
InsuranceGive the clinic the right insurance details.
The question it answers
Which payer and member record should staff check?
What you do here
Supply the card or entered details, select the payer, and review the member and subscriber information.
A simple example
P05 has unfinished insurance capture; S14 has an inactive eligibility response.
Care team, referral, and pharmacy stepsTell the clinic which other people and documents are involved.
The question it answers
Who is the PCP, who referred the patient, and what information is still needed?
What you do here
Complete the applicable care-team and referral fields and the available pharmacy selection.
A simple example
The PCP and referring clinician may be different people, as in P18.
Booking — location, doctor, day, and timeChoose a possible appointment.
The question it answers
Which offered option does the patient want?
What you do here
Select from the supported booking options and continue through the required handoff.
A simple example
A selected time becomes a confirmed appointment only when confirmation evidence is recorded.
Checkout and paymentReview the financial step attached to the request.
The question it answers
What estimate or payment step is being presented?
What you do here
Review the displayed details and follow the configured checkout path. Demo checkout examples are labeled as such.
A simple example
Payment evidence and appointment confirmation are separate facts.
Confirmation and preparation handoffCheck what was confirmed and what still needs doing.
The question it answers
Is the visit confirmed, and what are the next preparation steps?
What you do here
Read the displayed confirmation status, appointment details, and preparation information.
A simple example
A confirmed visit can still have an unfinished preparation checklist.
Public referral form and secure intake linkLet an office start the request and the patient finish their part.
The question it answers
What information does the receiving clinic need?
What you do here
The referring office supplies the request; the patient completes the applicable secure intake steps.
A simple example
P07 illustrates an intake in progress. This seeded guide does not issue usable patient access links.
Secure visit taskComplete one task for one visit.
The question it answers
What specific preparation information is being requested?
What you do here
An authorized, scoped task link presents the relevant instructions and completion step when supported.
A simple example
A preparation task is different from a general chat or a new appointment booking.
Staff summary and clinic handoffGive the receiving team the useful summary.
The question it answers
What has been collected for staff to review?
What you do here
Authorized staff inspect the summary and the remaining administrative requirements.
A simple example
A chart preview is evidence of prepared demo content, not a live EHR write.

This guide covers the operational screens and their patient-facing steps. About, contact, and directory pages provide clinic information. Design-lab and mock-checkout routes are support tools; general Settings and Help are not active screens in this build.

Words you might hear in the demo

Payer
The insurance organization shown on the case.
Claim
The bill submitted to a payer for a service.
Prior authorization
A payer review tracked before a service when required.
Referral
A request or supporting document from another clinician or office.
Appeal
A request to reconsider a payer decision, with supporting evidence.
Handoff
Passing the useful information and remaining work to the next team.
Evidence / receipt
A recorded source or result that supports what the case says happened.
Escalation
The configured point at which overdue work should receive more attention.
837P / 277CA / 835
Electronic records for a professional claim, its acceptance or rejection acknowledgement, and payment or adjustment details.

Fictional patients. Specific situations.

Every name, case, message, and payment example here is synthetic. The guide presents a curated snapshot of the demo dataset, not live patient information. Different views may refer to the same patient or claim.

Staff stay in control.

No message, payer submission, payment, or clinical decision is triggered by this guide. Links into MDMatrix require staff sign-in. Opening and referral scenarios illustrate coordination; they do not demonstrate live capacity or patient outreach.