BA Work Examples

Real deliverables from 20+ years in regulated industries

These are the kinds of artifacts I produce. Business cases, architecture decisions, compliance frameworks, process maps, root cause analyses. Each example is drawn from real work across healthcare, payments, and behavioral health.

Business Case Architecture Decision Compliance Framework Process Maps Root Cause Analysis Gap Analysis Transcript to Deliverable Entity Relationship Data Glossary

Business Case: Behavioral Health EHR Platform

Produced from stakeholder interviews with Clinical Director and facility administrators. Used for C-level investment approval.

Problem Statement

Behavioral health facilities operate on EHR systems built in the 2000s-2010s. Clinicians spend 40-60% of their time on documentation instead of patient care. Revenue leaks through undocumented services. Compliance is manual and error-prone.

Pain Point Matrix

Pain Point	Impact	Proposed Solution
Documentation takes 20-30 min per note	Clinician burnout, lost billable hours	Voice-to-BIRP: 2-3 min per note
Services delivered but never documented	~20% revenue gap (billed vs reimbursable)	AI note generation captures every service
Triple data entry (Excel + email + EHR)	Wasted admin time, data inconsistency	Single entry, auto-generated reports
Compliance is manual spreadsheets	Audit risk, missed deadlines	Automated alerts, policy library
No residential-specific features	Census, bed management all manual	Purpose-built residential module

Market Sizing (TAM)

Segment	US Facilities	Price Range	Market
PRTF	341	$36-60K/yr	$12-20M
SUD Residential	~2,000	$24-48K/yr	$48-96M
SUD Outpatient	~14,000	$6-18K/yr	$84-252M
Community BH	~10,000	$12-36K/yr	$120-360M
Total Addressable	~26,000		$264-728M

Risk Assessment

Risk	Likelihood	Impact	Mitigation
Regulatory changes (state-level)	Medium	High	Rules engine is state-configurable, not hardcoded
Incumbent EHR lock-in	High	Medium	Data migration tooling, parallel-run capability
Clinical adoption resistance	Medium	High	Built with practitioners, voice-first workflow
HIPAA breach	Low	Critical	Encryption at rest/transit, RBAC, audit logging, BAAs

Deliverable Format

Business cases include: Executive Summary, Problem Statement with Pain Point Matrix, Proposed Solution with Technical Approach, Financial Analysis (development investment, revenue projections, break-even, unit economics), Market Analysis (TAM/SAM, competitive landscape), Risk Assessment, Go-to-Market Strategy, and Recommendation with immediate next steps.

Architecture Decision Record (ADR)

100+ ADRs across active projects. Every "why" documented. Enables onboarding, audit, and future decision-making.

ADR-0003: Story Points Velocity Tracking

Status: Accepted
Authors: Bert Carroll, Claude Code
Related: ADR-0001 (AI Collaboration), ADR-0002 (Project Tracking)

Context

Activity is not productivity. Tracking commits-per-day or hours creates perverse incentives. Developers make small, frequent commits to inflate velocity. Large refactors get split into artificial chunks. Code quality suffers when optimizing for commit count.

Decision

Use story points (1, 2, 3, 5, 8) as the primary unit for measuring task complexity. Story points measure complexity, scope, uncertainty, and risk. They are independent of who does the work or how long it takes.

SP	Category	Example
1	Trivial	Fix typo, update constant, simple config change
2	Small	Add simple component, single API endpoint
3	Medium	New UI component with state, API endpoint with validation
5	Large	New page/feature, auth flow, complex integration
8	Very Large	Major feature, architectural refactor, multi-system change

Consequences

Positive: Accurate planning, cross-feature comparison, reveals hidden work
Negative: Learning curve (5-10 tasks to calibrate)
Mitigation: Start rough, refine over time, use reference tasks

ADR Structure

Every ADR follows: Context (what problem), Decision Drivers, Decision (what we chose), Rationale (why), Considered Options (with pros/cons), Consequences (positive/negative/neutral), Implementation (files affected, migration steps, rollback plan), and Related Decisions.

Compliance Framework: Policy Matrix

Version-controlled policies mapped to regulatory frameworks (HIPAA, SOC 2, NIST). Git-tracked review cycles with automated reminders.

Policy Coverage Matrix

Policy ID	Title	Status	HIPAA	SOC 2	NIST	Next Review
SEC-001	Acceptable Use Policy	Active	Yes	Yes	Yes	2026-11-08
SEC-002	Access Control & Authorization	Draft	Yes	Yes	Yes	Pending
SEC-003	Password & Authentication	Active	Yes	Yes	Yes	2026-11-08
SEC-004	Incident Response & Reporting	Active	Yes	Yes	Yes	2026-11-08
SEC-005	Remote Work & MDM	Active	Yes	Yes	-	2026-11-08
PRIV-001	Data Privacy & Security	Active	Yes	Yes	Yes	2026-11-08
COMP-001	IT Governance & Compliance	Active	Yes	Yes	Yes	2026-11-08
HR-001	Employee Training & Awareness	Active	Yes	-	-	2026-11-08

Policy Structure

Each policy follows a standard template: Purpose, Scope, Policy Statement, Roles & Responsibilities, Procedures, Exceptions, Compliance & Enforcement, References, and Revision History. Frontmatter includes policy ID, version, status, category, owner, approvers, effective date, review dates, and mapped compliance frameworks.

Compliance Safeguards (HIPAA Example)

Safeguard Type	Controls
Administrative	Security management policies, workforce training, incident response procedures
Physical	SOC 2 Type II certified data centers, endpoint security controls
Technical	Encryption at rest/transit (TLS 1.3), RBAC, comprehensive audit logging, SSO + MFA
Organizational	Business Associate Agreements with all third-party providers

How This Works in Practice

Policies live in a Git repository. Pull requests require review. GitHub Actions send automated review reminders when policies approach their next-review date. Every change is version-controlled with full audit trail. Compliance officers can see exactly what changed, when, and who approved it.

Process Maps & Workflow Diagrams

Used for requirements elicitation, stakeholder alignment, and gap analysis. Rendered as interactive diagrams, not static images.

Patient Intake Workflow (Behavioral Health)

flowchart TD A[Referral Received] --> B{Referral Source?} B -->|Self| C[Online Pre-Screen Form] B -->|Provider| D[Upload Referral Packet] B -->|Court/Probation| E[Legal Referral + Order] C --> F[AI Extracts Demographics] D --> F E --> F F --> G[Verify Insurance / Auth] G --> H{Authorized?} H -->|Yes| I[Schedule Assessment] H -->|No| J[Submit Prior Auth] J --> K{Approved?} K -->|Yes| I K -->|No| L[Notify Referral Source] I --> M[ASAM / Clinical Assessment] M --> N{Level of Care?} N -->|Residential| O[Check Bed Availability] N -->|Outpatient| P[Schedule First Appointment] O --> Q{Bed Available?} Q -->|Yes| R[Admit - Generate Face Sheet] Q -->|No| S[Add to Waitlist] R --> T[Nursing Intake] T --> U[Treatment Plan Generation]

Portfolio Migration Process (Payment Processing)

flowchart LR A[Current State
Assessment] --> B[Merchant Data
Extraction] B --> C[Gap Analysis:
Source vs Target] C --> D[Business Rules
Mapping] D --> E[Pilot Migration
50-100 merchants] E --> F{Validation
Pass?} F -->|Yes| G[Phased Rollout
by Portfolio Segment] F -->|No| H[Root Cause
Analysis] H --> D G --> I[Parallel Processing
Period] I --> J[Cutover +
Decommission]

Revenue Cycle Management Triage

flowchart TD A[Identify Revenue
Leakage Area] --> B[Pull Claims Data
Last 12 Months] B --> C[Categorize by
Denial Reason] C --> D[Pareto Analysis:
Top 5 Root Causes] D --> E[Triage Workshop
with Stakeholders] E --> F[Quantify Each
Opportunity] F --> G[Rank by ROI:
Effort vs Recovery] G --> H[Build Business Case
for Top 3] H --> I[Present to
Leadership] I --> J[Approved Items
Enter Backlog]

Deliverable Format

Process maps are rendered as interactive Mermaid diagrams embedded in shareable web pages. Current-state and future-state diagrams are presented side by side for gap analysis. Each workflow includes decision points, error paths, and stakeholder swim lanes where appropriate.

Root Cause Analysis (RCA)

Blameless post-incident analysis. Focus on systems and processes, not individuals. Five Whys methodology with concrete prevention controls.

RCA: Payment Processing Timeout During Peak Hours

Severity: High | Downtime: 2.5 hours | Users Affected: ~340 merchants

Timeline

Time	Event
14:22	First timeout alerts from monitoring
14:28	Investigation started, identified database connection pool exhaustion
14:45	Root cause identified: unindexed query on settlement table
15:10	Index deployed, connection pool drained
16:52	All queued transactions processed, incident resolved

Five Whys

#	Question	Answer
1	Why did transactions time out?	Database connection pool was exhausted
2	Why was the pool exhausted?	Queries were taking 8-12 seconds instead of <100ms
3	Why were queries slow?	Settlement reconciliation query lacked an index on created_date
4	Why was the index missing?	Table grew from 50K to 2M rows; no performance testing at scale
5	Why no performance testing?	No load testing in CI/CD pipeline for database-heavy operations

Prevention Controls

Control	Type	Status
Add composite index on settlement(created_date, merchant_id)	Immediate fix	Implemented
Connection pool monitoring + alerting at 80% threshold	Automated	Implemented
Query performance regression tests in CI	Automated	Planned
Monthly slow query log review	Manual	Planned

RCA Structure

Every RCA includes: Summary, Impact Assessment, Timeline, Five Whys Analysis, Root Cause Statement, Resolution (immediate fix + commits), Mitigation (completed, short-term, long-term), Lessons Learned, and Prevention Controls with status tracking.

Gap Analysis: Current State vs. Target

Used for platform evaluations, migration planning, and build-vs-buy decisions. Maps current capabilities against requirements with effort estimates.

EHR Feature Gap Analysis (Residential Behavioral Health)

Capability	Current State	Target State	Gap	Effort
Clinical Documentation	Paper forms, scanned PDFs	Voice-to-BIRP, AI-generated notes	Critical	8 SP
Assessment Instruments	Paper ASAM, manual scoring	Digital ASAM, C-SSRS, SA with auto-scoring	Critical	5 SP
Treatment Plans	Word templates, copy-paste	Generated from intake data, cascading updates	Major	8 SP
Census / Bed Management	Excel spreadsheet	Real-time dashboard, admission/discharge workflow	Major	5 SP
Insurance Verification	Phone calls, manual entry	Payer API integration, auto-eligibility check	Major	5 SP
Billing / RCM	Separate billing system	Integrated claims, denial tracking, reporting	Major	8 SP
State Compliance (DBHDD)	Manual tracking, audit scramble	131 rules encoded, automated alerts	Critical	5 SP
Patient Portal	None	Secure access to records, appointment scheduling	Moderate	5 SP
Reporting / Analytics	Ad-hoc Excel reports	Real-time dashboards, outcome tracking	Moderate	3 SP

Gap Severity Distribution

pie title Gap Severity "Critical" : 3 "Major" : 3 "Moderate" : 2 "Minor" : 1

Build vs. Buy Decision Matrix

Decision	Capability	Rationale
Build Custom	Clinical Documentation	Core differentiator. Voice-first workflow doesn't exist in market.
Build Custom	Treatment Plans	Must cascade from intake data. Tight integration with assessments.
Build Custom	State Compliance (DBHDD)	Highest strategic value. No off-the-shelf state rules engine.
Evaluate	Billing / RCM	High complexity. Consider integration with existing clearinghouse.
Evaluate	Insurance Verification	Payer APIs exist but integration is non-trivial.
Integrate / API	Assessment Instruments	Standard instruments (ASAM, C-SSRS). Build forms, not the science.
Integrate / API	Census / Bed Mgmt	Moderate complexity. Standard CRUD with real-time dashboard.
Buy / SaaS	Patient Portal	Low strategic value. Many white-label options available.
Buy / SaaS	Reporting / Analytics	Standard BI tooling. Embed Metabase or similar.

Deliverable Format

Gap analyses include: capability inventory (current vs target), severity classification, effort estimation, dependency mapping, and a build-vs-buy decision matrix. Presented as interactive tables and charts for stakeholder alignment sessions.

Transcript to Deliverable Pipeline

Real workflow: 45-minute stakeholder call becomes a structured summary, opportunity matrix, and shareable web page within hours of the meeting ending.

The Pipeline

flowchart LR A[Raw Transcript
45 min call] --> B[Clean & Structure
Remove filler, ID speakers] B --> C[Executive Summary
Key decisions, quotes] C --> D[Opportunity Matrix
Capabilities, gaps, next steps] D --> E[Shareable Web Page
Branded, interactive] E --> F[Send to Stakeholder
Same day]

Step 1: Raw Transcript (Input)

Raw Input - 45 min discovery call with recovery program author

"...so we have three books in the trilogy, the first one is really the memoir piece, it's my story of recovery, and the second one is more of a workbook that goes along with it, and the third one which isn't out yet is going to be more of a facilitator's guide for how to use the content in group settings..."

~12,000 words of unstructured conversation. Multiple speakers. Tangents, pleasantries, background noise, repeated points.

Step 2: Cleaned Summary (Output)

Structured Meeting Doc

Participants: Recovery Author (Franklin, WI), Platform CTO, Platform CEO
Duration: 45 minutes
Context: Author has published a recovery memoir trilogy and is exploring how a digital platform could extend the reach of the book content into daily recovery support.

Key Discussion Points:

Trilogy structure: memoir (published), workbook (published), facilitator guide (in progress)
Content is currently static (print only) with no digital delivery mechanism
Author has existing relationships with treatment facilities and recovery houses
Interest in spaced repetition model for daily content delivery
Facility licensing as potential revenue model

Step 3: Opportunity Matrix

Capability	Description	Complexity	Revenue Potential
Daily Content Delivery	Morning reading, midday reflection prompt, evening action item from book content	Medium	Per-facility license
Progress Tracking	Completion rates, engagement scores, streak tracking for individuals	Low	Included in license
Facilitator Dashboard	Group progress, discussion prompts, individual engagement flags	Medium	Premium tier
Assessment Integration	Pre/post program outcome measurement tied to book curriculum	High	Research/grant funding
Multi-Stakeholder Access	Individual, counselor, family member, and probation officer views	Medium	Per-seat add-on

Step 4: Shareable Debrief Page

Delivered to Stakeholder - Same Day

Format: Branded, mobile-responsive HTML page with unique URL
Sections: Meeting context, content breakdown, proposed delivery model, capability matrix, brainstorm questions for the author, next steps with owners, contact cards
Features: Interactive checklists (server-synced), print-optimized, view tracking per recipient

The stakeholder receives a shareable link they can forward to their team. No PDF attachments, no "see attached." A living document they can reference and check off action items.

Step 5: Requirements Register (Ongoing)

The transcript isn't just meeting notes. It's a record of who asked for what, and when. Every request, decision, and commitment is traceable back to the original conversation. This becomes a living register I work against to confirm whether assignments are complete.

Source	Request / Decision	Owner	Status
Discovery Call (Mar 5)	Explore daily content delivery model for trilogy	Platform CTO	In Progress
Discovery Call (Mar 5)	Draft facility licensing pricing tiers	Platform CEO	Pending
Discovery Call (Mar 5)	Send facilitator guide outline for content mapping	Author	Pending
Discovery Call (Mar 5)	Identify 2-3 pilot facilities for beta	Author	Pending
Follow-up Email (Mar 7)	Schedule technical walkthrough of platform	Platform CTO	Complete

Why This Matters

Most meetings end with "I'll send you a summary." That summary arrives 3-5 days later as a bullet-point email that gets buried. This pipeline delivers a structured, branded, interactive deliverable the same day. But more importantly, every recorded meeting creates an auditable trail: who asked for what, when they asked, and whether it got done. No "I thought you said..." No lost commitments. The transcript is the source of truth, and the register is the accountability layer on top of it.

Pipeline Stats

Input: ~12,000 words raw transcript | Processing: Clean, structure, extract, render | Output: Meeting doc + opportunity matrix + requirements register + branded web page | Turnaround: Same day

Entity Relationship Diagram

Used for database design, system integration mapping, and ensuring stakeholders agree on data relationships before development begins.

Multi-Tenant Healthcare Platform ERD

erDiagram Organization ||--o{ Region : contains Region ||--o{ Clinic : contains Clinic ||--o{ Staff : employs Clinic ||--o{ Patient : admits Staff ||--o{ ClinicalNote : authors Patient ||--o{ ClinicalNote : "is subject of" Patient ||--o{ Assessment : completes Patient ||--o{ TreatmentPlan : "is assigned" Patient ||--o{ Engagement : generates Patient ||--o{ InsurancePolicy : "is covered by" TreatmentPlan ||--o{ Goal : contains Goal ||--o{ Objective : contains Assessment }|--|| Instrument : "uses" ClinicalNote }|--|| NoteType : "categorized as" Engagement }|--|| EngagementType : "categorized as" Organization ||--o{ BillingAccount : owns BillingAccount ||--o{ Invoice : generates Patient ||--o{ Consent : signs

Entity Definitions

Entity	Description	Key Relationships
Organization	Top-level tenant. Single billing entity, multiple regions.	Parent of all data. Isolation boundary for HIPAA.
Region	Geographic or administrative grouping of clinics.	Reporting rollup. Regional directors see aggregated data.
Clinic	Physical or virtual care location. Has census capacity.	Admits patients, employs staff, generates billing.
Patient	Individual receiving services. PHI-protected.	Central entity. All clinical data traces back here.
Assessment	Standardized instrument completion (ASAM, C-SSRS, etc.)	Scores feed treatment plan generation pipeline.
TreatmentPlan	Clinical plan with goals and measurable objectives.	Generated from assessment data. Cascading updates.
ClinicalNote	BIRP, DAP, or SOAP note documenting a service.	Authored by staff, linked to patient. Drives billing.
Engagement	Patient interaction outside clinical encounters.	SMS responses, content completions, check-ins.
Consent	HIPAA authorization, TCPA opt-in, information sharing.	Required before any PHI transmission or SMS contact.

Deliverable Format

ERDs are rendered as interactive Mermaid diagrams alongside entity definition tables. Each entity includes description, key relationships, and data sensitivity classification (PHI, PII, public). Used in ADRs, technical specs, and stakeholder alignment sessions to ensure everyone agrees on the data model before code is written.

Data Glossary / Business Terms Dictionary

Eliminates ambiguity between business stakeholders, developers, and offshore teams. One source of truth for what terms mean in this system.

Healthcare Platform Glossary (Excerpt)

Term	Business Definition	System Representation	Source of Truth
BIRP Note	Clinical documentation format: Behavior, Intervention, Response, Plan	`ClinicalNote` where `note_type = 'BIRP'`	Clinician (author)
SOBER Score	Composite engagement risk score (0-100). Higher = more engaged in recovery.	`Patient.sober_score` (recalculated daily)	System-generated
Census	Current count of admitted patients in a residential facility.	`COUNT(Patient) WHERE status = 'admitted' AND clinic_id = X`	Admissions system
Face Sheet	One-page patient summary: demographics, insurance, diagnoses, emergency contacts.	Auto-generated PDF from `Patient` + `InsurancePolicy` + `Diagnosis`	Intake coordinator
LOC	Level of Care. Clinical designation (e.g., 3.5 = Residential, 2.1 = IOP) per ASAM criteria.	`Assessment.recommended_loc`	ASAM assessment
Prior Auth	Insurance company pre-approval for services. Has expiration date and approved unit count.	`InsurancePolicy.prior_auth_*` fields	Insurance payer
Touchpoint	Any platform-initiated contact with a patient (SMS, content delivery, check-in prompt).	`Engagement` record with `type` and `channel`	System-generated
TCPA Consent	Patient's explicit opt-in to receive SMS communications per federal law.	`Consent` where `consent_type = 'TCPA'` and `status = 'active'`	Patient (signed)
Spaced Repetition	Learning methodology delivering content at increasing intervals to improve retention.	Fibonacci sequence scheduling in `ContentDelivery` service	Platform algorithm
White-Label	Platform deployed under the client facility's branding, not the platform's.	`Organization.branding` config (logo, colors, domain)	Organization admin

Why This Exists

When a clinician says "census" and a developer hears "user count," you get the wrong feature. When a project manager says "prior auth" and the offshore team builds a login screen, you lose a sprint. The glossary is the contract between business language and system implementation. It's referenced in every requirements doc, every ADR, and every sprint planning session.

Deliverable Format

Data glossaries include: business term, plain-language definition, system representation (table/field/query), source of truth (who owns this data), and data sensitivity classification. Maintained as a living document updated with each new feature. Referenced in onboarding materials for new team members and offshore developers.

These are not theoretical templates. Every example on this page is drawn from live projects in healthcare, behavioral health, and payment technology. 300+ documented development sessions. 100+ Architecture Decision Records. Every requirement traced, every decision recorded, every process mapped. This is what AI-augmented business analysis looks like when documentation is treated as a first-class artifact.

Back to Resume · bert@askthehuman.com · askthehuman.com