DANIEL FLIPPO / SOFTWARE ENGINEER

I build scalable healthcare systems, and I'm endlessly optimizing 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 ↘

Selected work / 01

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 20-task benchmark (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. 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.

Source & architecture notes ↗

A BIT ABOUT ME / 02

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 ↗