MedView Flow.

The problem

Australia was moving to electronic prescriptions. Legislation changed, and every pharmacy in the country needed to handle both digital and paper scripts in one system.

Fred IT (the biggest pharmacy software provider in Australia) needed a cloud-based tool that would work with any dispensing software and any patient app. Pharmacies needed to process prescriptions the same way, regardless of how they arrived.

Simple concept. Messy execution.

When I joined, there was some early research and a pile of requirements. Enough to know what needed building, but not how to build it or what it should actually look like.

What I did

• Took all the scattered research and requirements and made them actually useful
• Figured out how this fit with Fred's existing products
• Designed and prototyped the entire system
• Worked with the dev team to make sure what we designed could actually be built

Sorting out the mess

First step: get everyone on the same page.

I took all the existing material (research notes, stakeholder wishlists, technical requirements) and turned it into one document everyone could actually read and agree on.

Then I mapped out who would use this thing and what they needed it to do. Kept a running list of unanswered questions so we weren't pretending we had all the answers.

Getting stakeholders to sign off on this early meant less rework later. Single source of truth, not a moving target.

Talking to pharmacists (and visiting McDonald's)

Lucky break: Fred had actual pharmacists in senior leadership, but I needed to see the reality on the ground.

I interviewed pharmacists, pharmacy assistants, and customers in-store while they worked and were being served. Watched prescriptions move through the system, saw where things slowed down, where staff got frustrated, and where customers waited too long. Asked about their usual processes, typical situations, problem areas, and what tech actually worked for them in practice.

Key insight: Pharmacists weren't resistant to digital; they were frustrated by fragmentation. One pharmacist told us, "I just want to see what's next in line. I don't care if it came from an app or walked through the door." This shaped our unified queue approach.

We also went to McDonald's (not for lunch, but to watch their workflow). Sounds weird, but fast food chains know efficiency. Pharmacies process queues all day. There were lessons there.

I mapped customer flows, identified all the touchpoints between staff, patients, and technology. Shared those with the dev team so everyone understood what we were building and why.

The other critical piece: making sure the data model would scale. No point building something that falls apart when usage doubles.

Building and testing fast

I sketched the basic architecture first: how each interaction would work, where things would go wrong, and what needed to be obvious vs. what could be hidden.

Having pharmacists on hand made validation quick. Show them a flow, watch them break it, fix it, repeat.

Then I built a working prototype in Axure. Not pretty pictures; an actual clickable thing the dev team could experience. They could see how components connected, understand the full journey, not just isolated screens.

That prototype became the source of truth. Development started working from it immediately.

Critical design decision: We made prescription type (digital/paper) a secondary attribute, not a primary filter. Users see one prioritised queue with subtle badges indicating origin. This kept their workflow identical regardless of format, reducing training time and adoption friction. We initially considered separate queues to match existing mental models, but testing revealed this created more confusion. Pharmacists wanted one unified view of all work.

Shipping and refining

Once the core was built and dev was running, I focused on details. Made sure the product owner had enough for each sprint. Answered questions from the dev team. Made design calls based on technical constraints and reality, not wishful thinking.

The prototype stayed alive. Kept updating it as we learned things. Eventually made a second version for sales demos.

The documentation became permanent reference material, not something that got abandoned after launch.

What happened

MedView Flow launched in 2020. It's now used by over 4,000 pharmacies across Australia.

It processed Australia's first electronic prescription in primary care. Not the first attempt; the first one that actually worked in a real pharmacy with real patients.

The CEO launched it at the national pharmacy conference. Press covered it. More importantly, pharmacists actually used it.

Links & CEO perspective

• Australia's first electronic prescription successfully dispensed
• Launch announcement
• MedView Flow product page

"The achievement of the first successful electronic prescription in primary care settings is a major step forward in Australia's provision of a digital network that provides patients with flexibility for how they access their medications. I am very proud of the Fred and eRx teams which, through ongoing innovation and hard work, have achieved this result ahead of schedule in a very challenging work environment."

- Paul Naismith, CEO & Pharmacist, Fred IT

What I learned

Rapid access to domain experts is gold. Having pharmacists in leadership meant we could validate assumptions in hours, not weeks. This taught me to prioritise stakeholder proximity in future healthcare projects.

If I could do it again, I'd involve community pharmacists earlier. The senior leadership pharmacists gave us credibility and strategic direction, but the front-line staff had insights about edge cases we only discovered during beta testing. Earlier access to that practical knowledge would have saved us iteration time.