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.