Skip to content

    Iterum Systems · Operational problem-solving for Medicaid, behavioral health, housing / homelessness, crisis & public systems

    The problem isn’t always where the system says it is.

    Organizations spend considerable time and money addressing symptoms of problems they haven’t fully understood.

    Iterum examines how people, policies, resources and decisions interact in one piece of work—a stalled referral, an unreachable provider, an unowned handoff, a report nobody agrees on. We test the accepted explanation, then develop a practical response that works in the real operating environment.

    We start with the problem. Not a product.

    First engagement: a bounded assessment of one breakdown you define. You receive an evidence and workflow map, tested causes, ownership gaps and a prioritized repair plan.

    Assessment scope & deliverables →

    Start with the breakdown

    What is breaking?

    Reporting numbers don’t agree

    • Different reports answer the same question differently.
    • Staff rebuild a history from spreadsheets, notes and memory.
    Hypotheses to test—not a diagnosis
    Definitions, dates, source systems or ownership may differ. Test those differences before blaming staff or replacing software.
    What we investigate
    Trace one metric from the original record through each transformation, exception and approval.
    Example intervention
    Create a definition register, reconciliation workflow and explicit exception owner.
    Specific deliverable
    Metric lineage map, reconciliation rules and an accountable reporting workflow.
    Investigation details & questions Discuss one operational problem

    How we think

    We start with the problem. Not a product.

    1. 01

      See beyond the presenting problem

      The complaint that starts the work is usually a symptom. Trace where the decision, handoff or report actually goes wrong.

    2. 02

      Connect what operates separately

      Policy, staffing, data, funding and frontline practice are often managed apart. Examine how they interact in the same piece of work.

    3. 03

      Challenge the accepted explanation

      Treat “staff aren’t following the process” or “we need new software” as hypotheses. Test them against records and the people doing the work.

    4. 04

      Identify a practical intervention

      Name the change, who owns it, what it depends on and how anyone will know whether it worked.

    5. 05

      Build only what is necessary

      A clarified owner, SOP or definition is often enough. Software is built only when the problem requires it.

    Where we work

    Public systems where handoffs carry consequences

    • Medicaid health plans and care coordination
    • Behavioral health
    • Housing and homelessness programs
    • Crisis response
    • Public and human-service systems

    Experience in these sectors comes from Maurice Cloutier’s professional history. The method may apply in other settings, but no results are claimed outside the work described here.

    What we’ve developed

    Evidence of the method, with its limits

    These projects came from working a specific problem. They show the reasoning, not a product catalogue.

    Triad

    Problem
    Referrals depend on resource knowledge held by a few people, and nobody can see why a handoff failed.
    Reasoning / intervention
    Make source provenance and routing criteria visible, flag uncertainty, and keep a staff member responsible for verifying every proposed referral.
    Evidence maturity
    In development / testing.
    Limits
    No deployed accuracy or client outcome claim.

    Rural Medicaid Access

    Problem
    Coverage on paper does not show whether a listed provider is reachable.
    Reasoning / intervention
    Compare service locations against distance and access constraints, then surface the transport, staffing and availability questions to verify before acting.
    Evidence maturity
    Working New Mexico demonstration. Separate Nevada history is prior professional work, not an Iterum client engagement.
    Limits
    Not live, verified provider availability, a client pilot or a measured access improvement.

    Housing Stabilization Training

    Problem
    Placement and a completed checklist do not establish practical tenancy support.
    Reasoning / intervention
    Six modules connect housing-transition skills with a pre/post/follow-up evaluation model and a proposed staff support workflow.
    Evidence maturity
    Deployed training site and documented design.
    Limits
    Improved housing outcomes, agency pilots and production integrations are not established; current access and active features need confirmation.

    All developed work, documented designs & professional history

    Inspect every evidence item

    In development / testing

    Triad

    AI-assisted referral decision support designed around source provenance, feedback and human verification.

    Decision scenario & limits

    Illustrative decision scenario

    Input:
    A service need and candidate resource sources
    Applied rule:
    Check provenance and routing criteria; flag uncertainty
    Output:
    A proposed referral with review questions
    Human review:
    A staff member verifies suitability and current source information
    Observable measure:
    Proposed test: unresolved sources and reviewer corrections

    Design example only. No deployed accuracy or client outcome claim.

    Historical Nevada access platform: county service-location comparison
    Historical Nevada interface from prior professional work; separate from the New Mexico public demo. On-screen figures are interface context, not verified outcomes.

    Public demonstration

    Rural Tool — New Mexico Demo

    Explore geographic access constraints; the separate Nevada platform documents prior professional work.

    Decision scenario & limits

    Illustrative decision scenario

    Input:
    A geography and listed service locations
    Applied rule:
    Examine distance and access constraints
    Output:
    A geographic comparison for investigation
    Human review:
    Verify transport, staffing and current availability directly
    Observable measure:
    Proposed check: unresolved access gaps

    Illustrative scenario using a real demo—not live provider availability. Nevada history is not an Iterum client engagement.

    Documented framework / prior professional experience

    ILOS Operations Framework

    Translate housing-related benefit requirements into authorization, referrals, documentation and audit workflows.

    Decision scenario & limits

    Illustrative decision scenario

    Input:
    A benefit requirement and an intake scenario
    Applied rule:
    Apply verified state / payer requirements and ownership
    Output:
    A documented next step and handoff
    Human review:
    Program leads validate local requirements and exceptions
    Observable measure:
    Proposed check: missing documentation and unowned handoffs

    Illustrative application of documented work. No payer endorsement or universal compliance claim.

    Documented system / prior professional experience

    Cognos Operating System

    Align reporting definitions, source lineage and governance around an operational question.

    Decision scenario & limits

    Illustrative decision scenario

    Input:
    A metric and conflicting report values
    Applied rule:
    Compare definition, date range and source transformation
    Output:
    An explained discrepancy and reconciliation action
    Human review:
    The metric owner signs off on definitions and exceptions
    Observable measure:
    Proposed check: unreconciled differences

    Illustrative scenario—not a verified customer result or employer endorsement.

    Documented reporting framework

    Reporting Core

    Make reporting definitions, reconciliation and accountability repeatable.

    Decision scenario & limits

    Illustrative decision scenario

    Input:
    Source records and a reporting requirement
    Applied rule:
    Use shared definitions and explicit reconciliation rules
    Output:
    A traceable report and exception list
    Human review:
    Accountable staff resolve and document exceptions
    Observable measure:
    Proposed check: exceptions without owners

    Design application—not measured ROI or an attributed commercial case study.

    Deployed training site / documented design

    Housing Stabilization Training

    Six modules for practical transition skills, with a pre/post/follow-up evaluation model.

    Decision scenario & limits

    Illustrative decision scenario

    Input:
    A tenant transition skill or support need
    Applied rule:
    Match it to training content and follow-up questions
    Output:
    A proposed learning and support plan
    Human review:
    Staff and participants assess relevance and needed support
    Observable measure:
    Evaluation model: pre/post and follow-up responses

    Illustrative application. Active deployment features and access arrangements require confirmation; improved housing outcomes are not proven here.

    Publicly functioning project

    Lantern

    No-account service navigation, weather safety and English / Spanish access.

    Decision scenario & limits

    Illustrative decision scenario

    Input:
    A person looking for a nearby service
    Applied rule:
    Use location and service categories to narrow navigation
    Output:
    Resource information and weather-safety context
    Human review:
    The person or supporting staff verifies hours and availability
    Observable measure:
    Proposed check: resource information needing correction

    Illustrative scenario using the real project. Listings do not establish service availability.

    Public framework

    Relational Mirror Model

    A trauma-responsive, nonclinical workforce framework for reflection and relational engagement.

    Decision scenario & limits

    Illustrative decision scenario

    Input:
    A difficult frontline interaction
    Applied rule:
    Use structured reflection rather than automatic judgment
    Output:
    A practice question and possible next response
    Human review:
    Staff and supervisors review context and appropriate boundaries
    Observable measure:
    Proposed check: consistency of reflective review

    Conceptual practice scenario—not therapy, a clinical intervention or a proven treatment outcome.

    Specific engagements behind the three paths

    Scope, outputs and boundaries

    Assessment

    Operational Breakdown Assessment

    A scoped review of one operational problem: intake, evidence and workflow mapping, causal and ownership analysis, and a prioritized repair plan.

    • Current-state evidence and workflow map
    • Causal hypotheses and ownership analysis
    • Prioritized repair plan with validation questions

    One agreed breakdown. Implementation is scoped separately.

    Assessment scope & deliverables Discuss one operational problem

    Implementation

    Workflow & Reporting Repair

    Apply Reporting Core’s approach to one reporting chain: agree what a metric means, trace how it is calculated, and assign responsibility for exceptions and changes before rebuilding a dashboard.

    • Metric definition register: calculation, source, date rules and named owner
    • Source-to-report lineage and reconciliation / exception workflow
    • Change-review process and delivery checks aligned to the operating cycle

    Work within agreed existing tools and source constraints. Makes upstream data problems visible; correcting them requires a separate scope.

    Inspect Reporting Core Discuss one operational problem

    Implementation

    Benefit / Program Implementation

    Translate a benefit or program requirement into work staff can carry out.

    • Operational requirements and dependency map
    • SOPs, documentation and referral handoffs
    • Launch readiness and QA checklist

    State and payer requirements must be supplied and verified. Not legal or licensure advice.

    Discuss one operational problem

    Custom build

    Decision-Support Prototype / Access Mapping

    Test a specific operational decision before committing to a larger build.

    • Scope and data-source inventory
    • Working prototype with source and validation rules
    • Human review, override and testing plan

    A prototype is not a clinical decision-maker or a guarantee of provider availability.

    Discuss one operational problem
    Scoping process & when we’re not a fit →

    About / experience

    Maurice Cloutier

    Experience, boundaries & field work

    Maurice Cloutier, principal, has more than 20 years across Medicaid community care coordination, behavioral health, housing, homelessness, crisis response and public systems—including director-level statewide operational responsibility.

    Iterum grew out of repeatedly finding that the visible problem was not the one causing the failure. The software projects on this site exist because a specific problem needed them; the judgment that located the problem is the service.

    That experience includes translating program requirements into frontline work, cross-sector implementation, nonprofit / Continuum of Care participation and relational engagement. Lived experience of homelessness informs the attention to what happens after a referral or placement.

    This is Maurice’s professional history, not a list of Iterum commercial clients. Former employers do not endorse Iterum. No historical outcome figures are claimed here.

    Speaking & Field Engagements

    Conference Session

    Nevada Statewide Homelessness Conference

    The Keys Are Not the Finish Line: Housing Stabilization After Placement

    Housing Stabilization Training addresses what follows placement: the skills, support, and operating structure that help housing hold.

    Placement is not stabilization.

    Discuss one operational problem

    What is breaking in the work?

    What is happening, what does it cost operationally, and what has already been tried? We’ll clarify fit and scope before discussing paid work.

    Do not submit confidential client or member information, health records, case details or other sensitive personal data.

    maurice@iterum.systems

    Iterum Systems is Maurice Gerard Cloutier’s sole-proprietor practice. Clark County DBA registration is not yet submitted or approved. No payer contracting or regulated-compliance certification is represented.