What I do
Ten years at the operational layer.
Where systems actually break.
I am not an integration architect — yet. What I am is a practitioner who has spent a decade at the exact point where healthcare systems fail: tracing broken messages, diagnosing distributed failures, building tooling that didn't exist, and translating between clinical and engineering teams who speak different languages. That operational depth is the foundation everything else is built on.
// 01
HL7 & X12 Integration Analysis
Reading, tracing, and diagnosing HL7 and X12 message flows across interface engines and downstream systems. I analyze transformer logic, identify where messages are failing or being silently dropped, manage payer mapping configurations, and work through integration issues with clients and engineering teams. I do not build Mirth channels from scratch — I understand them deeply enough to find what is wrong with yours.
Most integration problems are not where the error appears. They are three hops upstream.
// 02
Multi-System Root Cause Diagnosis
When an error message does not explain itself, I trace the failure chain: browser dev tools to Datadog, Datadog to database, database to Kafka or message queue, back to the source. I build Datadog reports to compare and contrast system behavior over time, write custom Python and Bash scripts to parse logs and extract signal, and produce detailed engineering escalations — sometimes including the specific code segment where the failure occurred.
The error message is a symptom. The log trail is the diagnosis.
// 03
Custom Tooling & Automation
I build tools that solve specific operational problems: log parsers that surface patterns across thousands of entries, report generators that make Datadog data usable for client conversations, scripts that automate repetitive data manipulation tasks. I have also built AI-assisted tools including a grammar and writing analysis assistant and a Latin language tutor — practical demonstrations of applying AI to structured knowledge problems.
If you are doing it manually more than twice, there is a script for that.
// 04
Clinical–Technical Coordination
I sit at the boundary between clinical teams who do not understand the technical system and engineering teams who do not understand the clinical workflow. I translate in both directions: helping clients articulate what is missing from their data, helping engineering understand the clinical consequence of an integration gap, writing bug reports and implementation guides that are detailed enough to actually be actionable. I am currently the designated technical representative for a major enterprise health system client.
The gap between clinical and technical is where most healthcare IT problems live.
A note on scope
What I can do. What I am building toward.
This site is honest about the difference. The work above is what I do now and do well — operational diagnosis, analysis, tooling, and coordination in healthcare IT environments. It is the work of someone who has been close to these systems for a long time and understands how they actually fail.
The architecture work — designing integration systems from scratch, owning infrastructure end-to-end, leading the technical strategy of a platform — is what I am building toward deliberately. The certifications, the documentation practice, the AI tooling, the journal: all of it compounds toward that goal. That trajectory is real and on a defined path. It is just not complete yet.
How I think