Mindful Compliance: a complete visual walkthrough
Synthetic demonstration captured 2026-10-08.

00:00:00.000  Your tour of Mindful Compliance
Where: /demo
Welcome to Mindful Compliance. This tour explains where everything lives, what each screen does, and how the pieces work together. We are using Cedar Harbor Recovery, a fictional program with twenty clients and sixteen staff members. These are real screenshots of the running demonstration. You can pause, jump to a chapter, and use the quick sheet while exploring the application yourself.

00:00:22.533  Where to find everything
Where: /auditor
Read the left navigation as three groups. The system area contains the record auditor, Note Review, assigned work, reminders, and Ask Mindful. The Agent area contains intake, clocks, chart checks, cases, correspondence, and outcomes. Education opens the Resource hub. Additional links above the auditor include the weekly brief, run history, settings, and import. Home and Record auditor currently lead to the same program overview.

00:00:47.667  Meet the fictional clients
Where: /demo#clients
The client directory is the easiest starting point. Each row gives you a fictional name, an opaque client identifier, a level of care, a payer, and a scenario to explore. Maya shows an attended day with a missing note. Sofia shows billing and version problems. Avery shows paid claims. Click a client name to open the connected record. The identifier in parentheses is what the engine stores and matches.

00:01:12.133  Meet the staff and providers
Where: /demo#providers
The staff directory introduces the people behind the assignments. You can identify counselors, the approver, the clinical director, intake, billing, nursing, compliance, and other positions. Credential types, license dates, exclusion screening dates, and payer credentialing entries are visible. The names are fictional. Responsibility is determined by the configured staff identifier and position, so the same person can be followed from a record finding into the work queue and reminder ledger.

00:01:42.000  Read the program overview
Where: /auditor
The program overview is the morning starting point. It brings together the current client population, findings, approval work, and skipped checks. A finding is an exception that needs investigation. A skipped check means the required evidence or qualified rule was unavailable; it is not a passing result. Use the client list to move from the program view to the actual record. The date at the top identifies the frozen synthetic observation date.

00:02:08.333  Open Maya’s connected record
Where: /client/C-0002
Maya's record is the central place to connect the pieces. The header identifies the client, level of care, payer, and admission date. Below it are episode clocks, findings, authorization units, Note Review, messages, documents, structured facts, and billing. You do not need to infer which client a finding belongs to. Start with the issue, read its evidence and owner, then continue into the relevant section or linked page.

00:02:32.600  Understand a finding
Where: /client/C-0002
A finding row tells you which rule failed and which record or service it concerns. The payer, priority, assigned owner, due date, and evidence help you decide what to inspect next. Acknowledging means someone has taken ownership. Disputing records a source disagreement. A compliance waiver records an exception. These actions do not prove the underlying issue was fixed. Resolution requires a later run that actually executes the same check with the needed inputs and passes.

00:02:59.667  Read the authorization ledger
Where: /client/C-0002
The units ledger connects authorization to actual services. Compare units authorized, delivered, approved, billed, and remaining. The unit basis matters: a day is not an hour, and the application should not silently convert one into the other. The authorization end date helps utilization review plan the next step. Unknown or unsupported inputs remain visible as gaps. A paid claim, an approved note, and an authorized service are separate facts that must be matched.

00:03:26.667  Find a client’s review and messages
Where: /client/C-0002
The record includes a compact Note Review table. Click a note identifier to open its readiness checks and current review stage. Beside it, mailbox and team lines show correspondence linked to this client. A receipt says a reply was cataloged. A clarification says follow-up is open. A team line is a local record of coordination. Receiving a message does not resolve a chart finding, and recording a message here does not send it.

00:03:52.667  Inspect the supplied documents
Where: /client/C-0002#record-documents
The document section is the inventory of supplied record artifacts. It distinguishes a note, assessment, treatment plan, consent, medication list, authorization, and other document types. Each row shows its date, author, status, and version. Expand a row to see the supplied demo artifact and structured elements. These new demo texts are placeholders. This desk inspects what was supplied; it does not write clinical documentation or propose clinical note wording.

00:04:22.133  Connect diagnoses, medication and plans
Where: /client/C-0002#record-facts
Structured record facts connect the documents. Diagnoses show their source document and recorded author. Medication entries can be compared across a medication list and plan. Planned services include frequency and target dates. Consent and coverage show their scope, recipient, dates, and evidence. The medication codes and doses in this demonstration are placeholders. Inconsistency or missing evidence should lead to review of the source, not automatic correction of the clinical record.

00:04:52.733  Follow a paid claim
Where: /client/C-0020#billing
Avery demonstrates how billing evidence connects. The claim table identifies the service date, code, units, payer, status, and related note. The remittance table records the payer's decision and follow-up dates. A claim line is matched to its service and current approved note. A paid remittance is a separate event. This screen displays supplied claim and payment evidence; it does not submit, change, or void a claim, and it does not move money.

00:05:18.667  Investigate Sofia’s billing problem
Where: /client/C-0004#billing
Sofia's record demonstrates a claim without a ready approved note and an unworked denied remittance. Her changed Note Review version is another issue, so do not treat all exceptions as one problem. Investigate the claim-to-note match, then the payer decision, then the recorded follow-up. The house follow-up deadline and a sourced payer appeal deadline are different clocks. Use the finding and source evidence to decide which work is actually due.

00:05:43.867  Choose a review stage
Where: /note-review
Mindful Note Review is the approver's workspace. The stage tabs separate all notes, needs action, ready, approved, posted, reconciled, returned, changed versions, and notes not yet reviewed. Counts change as the demonstration is used. The examples in the next screens are different supplied notes illustrating each stage. QA approval applies to the exact supplied version. A changed note cannot borrow approval from an older version.

00:06:09.867  Ready: check the evidence first
Where: /note-review?note=N-DEMO-READY
The ready example belongs to Avery. Readiness checks cover the applicable sources, qualified level, complete export, clinical signature, required co-signature, units, structured elements, human semantic review, timing, coverage, and authorization. Ready means the configured checks passed for this supplied version. An assigned approver can then record QA approval. The approval button records a review decision. It does not sign a clinical note and does not post anything to an electronic health record.

00:06:41.000  Approved: a person performs the EHR step
Where: /note-review?note=N-DEMO-APPROVED
Sam's example is approved. That means the local QA decision exists for the current version. The next control records an attestation that a person posted the note in the electronic health record. The application itself does not perform that posting. This distinction matters when explaining the system to someone else: local review history, a clinical signature, and an EHR posting are separate steps, even when a demonstration shows them beside each other.

00:07:07.467  Posted: wait for a later export
Where: /note-review?note=N-DEMO-POSTED
The posted example is Avery's note with a human posting attestation. Posted is not the final confirmation. A later read-only export is needed to compare the observed version with the reviewed version. In this synthetic app, the simulation control performs that later-import check locally. It can check other posted entries as well, so queue counts may change together. No live EHR connection is used by this demonstration.

00:07:33.467  Reconciled: the observed version matches
Where: /note-review?note=N-READY
Maya's reconciled example has passed the later-export comparison. Reconciled means the observed supplied version matched the reviewed version for that import. It is not a promise that every other record or billing check is clean. Open version history to see the actions and actors that led here. If the content or relevant fields later change, the system needs a new readiness and approval decision for the changed version.

00:07:58.933  Returned: send the work back for review
Where: /note-review?note=N-DEMO-RETURNED
The returned sample belongs to Maya. Returned separates work that has been sent back for review from work that is approved or complete. The supplied note remains inspectable, and the action history remains visible. This tool does not provide replacement clinical wording. The appropriate person deals with the source record through the program's normal process, and the current supplied version must go through readiness and review again before a new approval is recorded.

00:08:25.200  Changed version: approval no longer matches
Where: /note-review?note=N-FLOW
Sofia's note demonstrates a version mismatch. You may see a ready badge beside a mismatch badge. They answer different questions: the current fields can pass readiness while the earlier review applies to another version. Do not treat the older approval as approval of the current note. Inspect version history, then repeat the readiness and approval process for the current supplied version with the assigned reviewer.

00:08:48.867  Late entries require a compliance decision
Where: /note-review?note=N3
A late-entry example shows why timing is not just another green badge. An entry outside the configured business-day rule is held from billing readiness until a compliance lead records a decision for the exact version. The controls distinguish keeping the hold from recording eligibility for further review. Eligibility is not automatic approval, and it does not rewrite a signature date. The underlying clinical record remains the responsibility of the person using the EHR.

00:09:18.800  Work by position
Where: /audit-work
Work by position turns exceptions into assigned work. Filter by author, approver, clinical director, intake, utilization review, billing, compliance, or credentialing. Each row keeps the client and underlying rule connected to the person responsible. Missing or inactive assignments can fall back to the clinical director and remain a visible routing gap. Use this screen to coordinate ownership; it is not a record that the underlying issue has already been resolved.

00:09:46.667  The local reminder ledger
Where: /audit-outbox
The local outbox records reminder and escalation decisions. Each entry identifies the recipient, client, rule, time, and state. Quiet hours, daily caps, and missing authorized recipients can suppress a reminder. Suppressed is a recorded reason for not delivering it. In this build, all entries are local records and none are sent or posted. A reminder is a coordination event; a later complete passing check is what can resolve a finding.

00:10:13.467  The director’s weekly brief
Where: /audit-scorecard
The weekly brief condenses the current program into operational measures. It includes attended days, missing-note days and percentage, open findings, late-entry holds, approval backlog, approved notes without claims, unworked denials, and skipped checks. These are measures of the supplied synthetic baseline. Trends require later complete imports. When the denominator is unavailable, the metric stays unknown rather than inventing a percentage. Use the brief to choose where to investigate next.

00:10:44.733  Audit runs and repair history
Where: /audit-runs
The run log tells you which synthetic audit ran and when. Expand a run to inspect its evidence hash and individual receipts. The finding history records opening, ownership actions, exceptions, resolution, and reopening. A later run must execute the same rule and subject with required inputs present before a failing finding can resolve. Removing a document or omitting a table from an export does not count as fixing the issue.

00:11:10.733  Settings and the 36 program questions
Where: /audit-settings
Settings determine how the program's local workflow behaves. The configuration includes review mode, staff assignments, versioned house policies, billing settings, notification controls, and thirty-six program questions. These answers are explicitly synthetic in the demonstration. Do not read them as the real client's confirmed answers. A configuration change must pass validation. Payer rules and evidence are separate from program preferences, so a house policy should not be presented as a verified payer requirement.

00:11:43.600  Payer profiles retain their evidence
Where: /audit-settings
The payer-profile section connects a rule value to its source record and source file. Inspect the value, unit, anchor, and any conflict instead of assuming every payer uses one deadline. A field that was not read remains unavailable; the engine can use a labeled default or skip when appropriate. These profiles support the synthetic calculations shown elsewhere. They do not establish a real payer contract or qualify a live program for production use.

00:12:10.533  Validate an import before applying it
Where: /audit-import
Import preview is the boundary between supplied data and the desk. You can validate an explicitly mapped synthetic envelope or preview the bundled sample. Identity values become keyed fingerprints, and failed input is not echoed into stored findings. Applying a validated import replaces the current supplied chart while retaining eligible review and finding history. A blank or scanned document needs reviewed extraction. A working preview is not proof of a live vendor connection.

00:12:41.200  Ask Mindful reads this local desk
Where: /ask?q=tell+me+about+C-0002&level=
Ask Mindful is a conversational entrance to the local desk. Ask about a client identifier, a deadline, a case, a draft, or a rule. Here the local answer summarizes Maya's supplied episode, authorization, work, and linked cases. Follow the links back to the underlying record instead of treating the answer as a separate chart. The demonstration answer comes from the local data and deterministic desk. This tour does not invoke an external model.

00:13:07.800  Intake turns notices into cases
Where: /intake
Intake shows notices already supplied with the snapshot and the cases they opened. The manual intake form identifies the episode and notice type before a person provides the notice text. This is notice intake, not a replacement for a full patient registration system. An imported audit notice, denial, or extension request needs the correct case track and evidence. Its presence creates work to inspect; it does not establish that the payer's conclusion is correct.

00:13:35.667  Countdown shows the clock engine
Where: /countdown
Countdown brings the computed deadlines together. Look at the due date, status, client, and source rule. Dates are computed from the episode's supplied anchors, such as admission, authorization, service, discharge, or receipt of a notice. Business-day and calendar-day clocks are different. A deadline for one level should not be copied onto a different level. Use the client record to connect an urgent clock to its evidence and responsible work.

00:14:01.067  Chart check is the focused QA view
Where: /chartqa
Chart check is a focused view of the deterministic chart QA checks. It groups exceptions by client and shows severity, source evidence, and the next human review. It complements the broader record auditor, which also connects structured completeness, revenue, and workflow checks. Both read the same current supplied chart in this build. Use this page for a quick chart-focused review, then open the record to inspect authorizations, messages, review versions, and billing.

00:14:29.667  Review queue is for cases and packets
Where: /queue
There are two different review areas. Note Review is for clinical-note QA state. The Review queue here is for procedural cases and packet drafts. It separates blocked work from drafts whose source, evidence, consent, and reviewer-role gates are satisfied. A ready packet still needs the appropriate person's review. Open a case to inspect what is missing or what supports it. A green gate does not cause an appeal to be sent automatically.

00:14:55.000  Inside a procedural case
Where: /case/CASE-D-SHOW-13
Owen's procedural example shows the inside of a ready case. The case has a track, a draft, evidence pointers, source citations, consent checks, and a required reviewer role. Read the assessment and gates before the next step. The example is an administrative packet fixture, not newly authored clinical documentation. Recording a review or a signature in this local demonstration is separate from actually submitting anything to a payer.

00:15:21.000  A blocked case tells you what is missing
Where: /case/CASE-AUD-AUD-1
A blocked case is useful information. The verifier explains the missing evidence, source support, consent, role, or required packet inputs. Follow those specific gaps instead of treating the red state as a generic failure. A person can supply an appropriate missing input through the normal workflow, but the gates still apply to the resulting draft. An audit defense is also a different track from a member appeal, even when both originate from payer correspondence.

00:15:47.867  The audit room
Where: /audit
The audit room gathers audit-defense cases and related program clocks. It does not treat an audit finding as a member appeal. The existing procedural engine checks the applicable defense layers and evidence before the required person can review a packet. This demonstration contains a blocked audit example, so you can see where the process stops. Use the record auditor for routine record exceptions and the audit room for the separate case-based defense workflow.

00:16:14.733  The send desk records a manual filing
Where: /send
The Send desk holds signed procedural packets waiting for a person to perform the filing. Amara's fictional packet is the queued example. The operator records the channel and an opaque proof reference after the human action. The application records that attestation locally; it does not transmit the packet. Keeping the proof reference connects the filed case to its outcome and history. Never explain this screen as an automatic email, payer portal, or submission integration.

00:16:41.333  The Inbox catalogs payer replies
Where: /inbox
The Inbox catalogs replies from a payer, managed-care organization, or provider. A receipt, question, or clarification stays linked to the matched client identifier. The demo also records an outbound follow-up that a person would send. Raw identity should not appear in the saved channel summary. A cataloged receipt does not close a chart exception or prove filing. This build stores the communication record locally and does not connect a real mailbox or send an email.

00:17:11.533  A mailbox tool has a local catalog form
Where: /inbox/mailbox
A mailbox tile opens a tool-specific catalog form. It shows the sender category, subject, and message inputs, and the local records for that tool. This is how the demonstration makes the correspondence workflow concrete. It is not an authenticated live mailbox. Match the correct client identifier, inspect the cataloged result, and follow the record link for context. The form's success means the local line was recorded, not that anything was delivered outside the desk.

00:17:41.600  The Team page records coordination
Where: /team
The Team page records coordination through tools a program might use, including Asana, Slack, and Teams. A team line identifies the selected tool, client, and update. The same client link connects it to the record and work queue. The current status explicitly says not posted. These are local coordination records, not live messages in those services. An assignment, a reminder, and a completed source-record repair should remain separate events in your explanation.

00:18:08.800  The Asana example
Where: /team/asana
The Asana example makes the team workflow visible for one tool. Choose the client identifier and enter the coordination update, then inspect the resulting local line. Other team tiles use the same local catalog behavior with their own labels and status. The client name shown in the demonstration is a presentation alias for the identifier. No account is connected, and recording this update here does not create a live task or post a message in Asana.

00:18:36.533  Read the recorded outcomes
Where: /outcomes
Outcomes connects a filed procedural case to a recorded result. The fictional examples include won, partial, lost, and pending. The case and client remain linked, and the plan summary counts the results that were actually recorded. These figures are descriptive history, not a prediction of whether another appeal will win. A person records the real outcome through the appropriate process; the demonstration fixtures represent that history without an actual external filing.

00:19:03.800  Levels of care show the coverage boundary
Where: /levels
Levels of care explains where the current rule coverage applies. All fifteen levels have demonstration clients, but the presence of data is different from a qualified rule pack. Supported clocks and checks remain specific to their level and population. Levels such as outpatient one point zero, withdrawal management, OTP, OBOT, and OBAT have explicit gaps in this build. Read the coverage label before interpreting a record as assessed or clean.

00:19:29.533  An OTP record can be visible and unassessed
Where: /client/C-0009
Riley's OTP record demonstrates the boundary clearly. The client, documents, medication placeholders, consent, and coverage can be displayed while qualified checks remain unavailable. The warning says rules are not loaded and the record is not called clean. This is a useful distinction when sharing the demonstration: data visibility shows the interface can represent the record, while rule qualification determines whether the tool can make a supported assessment for that service.

00:19:59.000  The connection wall
Where: /connections
Connections is a registry and capability wall. It shows EHR and other system options, the route each vendor makes available, and the actual development status of the adapter. A tile may be planned, mapped, waiting for a sample, or otherwise limited. These labels matter more than the existence of a vendor name. Opening a tile gives evidence and a local sample path. This tour does not sign into any vendor or establish a live connection.

00:20:25.000  Inspect the Noteable connection details
Where: /connections/noteable
The Noteable detail page distinguishes the available file-drop route from API access that remains unconfirmed. Inspect the evidence, development status, and sample export explanation. A mapping exercised on our synthetic sample is not a vendor's production golden test. A real mapped export sample and the required production agreements are still needed before working with real records. The demonstration lets you inspect the connection design without calling a vendor API or marking the integration complete.

00:20:58.000  The Resource hub is the learning side
Where: /resource/
The Resource hub is the education area. It explains the learning library, clocks, touchpoints, and available listening material. It is separate from the operational client record and case desk. This hub includes legacy learning material. Confirm the current rule and date in the auditor's source evidence before relying on it. The Back to the Agent link returns to operations. This tour shows the hub interface without reproducing private copyrighted course decks.

00:21:24.400  Listen and read
Where: /resource/#listen
Listen and read collects the hub's available briefing and reading material. Use the displayed playback or reading controls where an asset is actually provided. This is education content; listening to a briefing does not run a client audit, approve a note, or resolve a finding. The operational work remains on the record and case pages. You can use this section to orient a new viewer before walking them through Maya's connected example.

00:21:49.733  Browse the rule library
Where: /resource/#rules
The rule library lets you browse the hub's source-backed learning entries. Read their scope and evidence instead of assuming a familiar rule applies everywhere. The operational auditor has its own source snapshot, which can be newer than this educational hub. A law, a payer policy, and a house preference are different kinds of evidence. Library browsing explains a rule; the current execution receipt tells you whether the applicable check actually ran on a supplied record.

00:22:16.267  Learn the deadline clocks
Where: /resource/#clocks
The educational clock section explains which event starts a deadline and how a date is derived. Keep business-day and calendar-day calculations separate, and read the relevant level and source. Some educational material is older, so confirm the current operational evidence. The calculated due date for a supplied client appears on Countdown and the record. Learn the clock here, then inspect the synthetic anchor and execution receipt on the working desk.

00:22:42.667  The touchpoint map
Where: /resource/#map
The touchpoint map explains where the information used by the desk comes from. Documents, signatures, coverage, authorization, attendance, notes, claims, payer replies, and staff information have different sources and owners. A complete-looking screen is not proof that all required source inputs were supplied. Use this map to understand the upstream responsibility, then inspect the import and record evidence for the actual demonstration. Missing inputs remain gaps rather than fabricated values.

00:23:13.400  A practical daily routine
Where: /demo
Here is a practical daily routine. Start with the program overview and choose an exception. Open the client record, read the source evidence, and identify the responsible person. Use Note Review for the exact note version, and compare authorization, attendance, claims, and remittances when billing is involved. Coordinate locally through work, reminders, Inbox, and Team. Finish with the weekly brief and run history. The quick sheet gives you the same route without watching the entire video again.