DANIEL FLIPPO / SOFTWARE ENGINEER

I build scalable healthcare systems, and endlessly optimize my projects (and, frankly, my life) for the AI-enabled world we've found ourselves in.

I'm a software development engineer on the Product Development team at Etactics, a medical revenue-cycle company, where I've owned healthcare EDI features from requirements through release for 2+ years. I'm based in Northeast Ohio, and right now I'm most into the frontier of agentic AI development and how it plugs into real applications.

Explore my work

Currently Sept 2026 Iterating on my subscription-agnostic Agent Harness, practicing for disc golf tournaments, and getting ready for hockey season.

Tap a label in the orbit.

Selected work / 01

A real run on my tower, recorded at phone size: a task in a throwaway scratch folder asks to pip install pytest, I approve it, and all 7 tests pass. Slow stretches are sped up and labelled.

AI TOOLING / PERSONAL PROJECT

Agent Harness

Agent apps from the big labs have an uneven mobile experience, and remote sessions in particular kept breaking for me. I wanted one place to control every tool I use and keep track of all my sessions, with options when a provider's usage pool runs low, and room to try new ideas before they show up in the labs' own products. I experiment with it daily, though not exclusively.

The surprise: while configuring it for local models, simplifying the harness and limiting how much of the context window it uses made it faster than popular open-source harnesses. On my own benchmark of 10 hard coding tasks, each run twice and graded mostly by hidden tests (Qwen3.6-35B-A3B, 32k context, one RTX 4070 Ti SUPER), Agent Harness passed 19/20 at about 47 s per task, versus 18/20 at about 81 s for OpenCode 1.18.30 and 18/20 at about 126 s for OpenHands CLI 1.16.0.

PythonFastAPIDocker sandboxesLocal inference

Explore the project

HEALTHCARE / JAVA

FHIR CRD Router

Hospitals and clinics have to check with each insurer's system before certain orders. Every insurer runs its own endpoint, so finding the right one is a mess. This Java library maps an insurer's ID to the right connection, so a provider can keep track of them all in one place.

Read the case study

CASE NOTES / FHIR CRD ROUTER

Keep the directory separate from the patient data.

The problem

New federal interoperability requirements are pushing payers to stand up CRD endpoints, and each one is another connection to manage on top of the EDI connections we already run: batch file exchanges and realtime ones like eligibility inquiries. Running those connections day to day is labor-intensive, and the legacy process makes it hard to see which connections exist.

The decision

I kept the core to discovery only: it resolves a payer ID to a connection record and never touches patient data, so an organization can adopt it without sending PHI to code outside its own walls. Credentials sit behind a pluggable provider interface, so each organization decides where secrets live and which connections it supports. The alternative I passed on was an all-in-one solution that also collects and maintains the connections.

The tradeoff

It isn't an all-in-one solution. Organizations still have to collect and maintain their own connection records; the library gives that work a clear structure but doesn't do it for them.

What's proven so far

It builds and passes 39 unit tests, plus 2 live tests against the HL7 reference server, and CI runs on Java 17 and 21. The quickstart also runs end-to-end against an in-process mock CDS Hooks server with synthetic connection records. It has not been tried against a real payer sandbox. A companion workbench now onboards two synthetic mock payers with deliberately different auth and response behavior, and when a connection fails it says which check failed and how to fix it. Both payers are mocks, so this shows the diagnosis, not real-payer interoperability. Next: test against a real payer sandbox, then add notifications for credentials that are close to expiring or that fail authentication.

Try it The clinician is waiting: why the 500 ms budget matters

In US healthcare, claim denials are among the biggest headaches for patients and providers alike. Eligibility checks aren't enough on their own, because they tell you about the money behind a patient's coverage, not what's required for approval. A clinical decision support (CDS) service that answers at the moment of ordering tells the provider exactly what to supply, but a slow one gives that up. Run the demo and watch what happens to the clinician's screen once the response time passes the 500 ms budget.

Simulated in your browser with synthetic data. Not a real EHR or payer.

MOCK EHR · ORDER ENTRY HOOK order-sign · BUDGET 500 ms

Order

MRI, lumbar spine

Draft

Clinician's screen

Sign the order to fire the hook.

Call trace

Ready when you are.

A slow answer can be as good as no answer.

CDS Hooks guidance is that services respond on the order of 500 ms. The spec doesn't say what an EHR must do when they don't, so the cutoff and the "sign without guidance" behavior here are illustrative; real EHRs vary. Card actions are inert.

Try it Watch a payer connection break, and see why

Routing a request to the right payer is only half the job; the other half is working out why a new connection fails. These are recorded runs of the payer onboarding workbench against two synthetic payers, both healthy and with faults injected on purpose. Pick a scenario to replay its steps, then see the failing check and the suggested fix.

Recorded run against a synthetic mock payer. Passing here does not prove real-payer interoperability.

Source & architecture notes Workbench source

Integration failure lab / 02

Most of my work is moving healthcare data between systems that don't fail politely. Messages time out, arrive twice, show up out of order, or change shape without warning. Break a small claims pipeline on purpose here, then turn on the safeguards that real integrations rely on and see what each one costs.

Simulated in your browser with synthetic data. In guided mode you can also replay real runs recorded from a Java 21 / Spring Boot version that executes the same scenarios over HTTP. Source & tests

A BIT ABOUT ME / 03

Hi, I'm Daniel.

Portrait of Daniel Flippo: a smiling man with auburn hair, a red beard, dark-framed glasses, a white shirt and a patterned tie, with a harbor and hills blurred behind him.

I studied computer science and engineering with an AI specialization at Ohio State (graduated 2024), and joined Etactics that July as a software development engineer on the EDI product team. Since then I've designed a payer enrollment portal that cut client managers' processing time 75%, synced it with Jira Service Management, own the real-time REST API behind insurance discovery, and won an internal hackathon with a Claude-assisted tool that reproduces production errors and generates regression tests. I also work on a new claims processing service built on Daffodil (X12/EDI) schemas.

I live in the Greater Cleveland area. Outside work I'm a big fan of the current hyperpop and electropop scene, plus EDM, alongside new metalcore and post-hardcore. On repeat: underscores, Ninajirachi, and Sleep Token. I'm an avid disc golfer (home courses include Punderson State Park and Astorhurst DGC) and I've been training my hockey skills, while cheering for the Columbus Blue Jackets.

I'm open to new opportunities, collaborations, and conversations. Email me at dflippo.jr@gmail.com or find me on LinkedIn.

Resume (PDF) · GitHub · LinkedIn