I Led an E-Prescribing Integration by Myself. Here's What Actually Happened.
I've worked on e-prescribing vendor integrations at three telehealth companies. At one of them, I led the entire integration solo. This is what that looked like.
We started with the easy option. It didn't scale.
We needed to send electronic prescriptions to mail pharmacies. We picked a vendor and went with their iframe plan — the fastest path to something working. We got it running. Then we hit two problems.
First, even with preselected medication lists, providers kept picking the wrong drugs. We couldn't match what they selected back to our internal medication catalog, so we couldn't send orders. Second, because the iframe solution relied on webhooks to push data back to our system, we were at the mercy of timing. Webhooks arrived late. We expected one status and got a different one.
We couldn't scale it. So we decided to do the full API integration.
Four months, one engineer, daily calls
At a previous company, a team of four or five engineers spent close to a year building a similar integration. I didn't have a team. It was just me.
What I did have was a great vendor support team. They didn't have to meet with me every day, but they did. Those calls weren't status updates. They were pair programming sessions. The vendor would walk me through what we were building that day. I'd start by wiring up the real endpoint — no mock data — so I always had actual responses to work against. Then I'd build the UI, and they'd tell me if I needed more fields on a screen or if it was enough to pass.
The hardest part was understanding how all the pieces connect. Rx changes, eligibility checks, medication history, medication alternatives. I didn't have time to study it upfront. I learned by building. The vendor team sequenced the work, and the understanding came as I went.
After four months, the full integration was done. I was proud of that.
Certification was built into the process
Because the vendor team took screenshots as we built, there was no scramble to assemble a certification package at the end. It was already done.
We still had to do a formal certification call with Surescripts — walking through a set of test scenarios live. It took two rounds. The first time we had minor UI bugs. The second time we passed clean.
Why it took months, not a year
The previous company had engineers, designers, and product managers all involved. A lot of decisions had to be made before anyone wrote code. Too many cooks.
I was the designer, the product manager, and the engineer. Every decision was instant. We shipped function first and made the UI prettier after certification. That, plus daily calls with the vendor, cut the timeline from a year to four months.
What I'd do on day one
- Get on real endpoints immediately. Don't waste time with mock data. Build against actual API responses from day one so you catch real problems early.
- Push for daily calls with your vendor team. This was the single biggest reason I finished in four months. The more access you have, the faster you learn.
- Keep the team as small as possible. Every extra person adds coordination cost. One engineer who can make product and design calls will move faster than a full cross-functional team.
- Ship ugly, then clean up. Get through certification with a working product. Polish the UI after.
A full e-prescribing integration takes months of patience, resources, and deep vendor knowledge. That's the problem we're solving at Noga Health — building that integration once so engineering teams don't have to.