How I work
Audit & operational systems
I build audit software from the audits I’ve done myself.
When I’m reviewing a claim, I need to know where the information came from and why a finding was reached. That’s what I build into my audit software: a clear connection between the record, the review, and the result.
Start with the record
When I review a claim, I need to know what happened and what the records support. I bring that same discipline to the application. The source information needs to stay connected to the decision, even after it becomes part of a report.
Records
I keep the source information in context and make gaps in the documentation visible.
Rules
I define what a check can establish and where someone still needs to make a judgment.
Review
The reviewer needs access to the evidence and a place to explain the decision.
Findings
Someone reading the result should be able to follow it back to the records that support it.
Leave room for judgment
A missing field needs attention. A conflicting record needs investigation. Neither one tells the whole story on its own. I want the system to help a reviewer see those differences.
I automate checks that can be applied consistently and leave room to investigate what they turn up. Doing the audits myself has taught me how much can depend on the context behind a record.
Fit the application to the team
I start with how the records arrive and how the team works through them. I look at where people lose time, what they need to see together, and how findings reach management. Those details guide the application and the technology behind it.
Show me an audit
Walk me through a record, the criteria you review it against, and the report you need at the end. Include an awkward case that takes longer than it should. That gives me a much better sense of the work than a list of requested features.