We talk a lot about data migration at wawa. Probably because it is one of the first questions any clinic asks when they consider changing their core system: how are you going to get all of our data out of what we have today and safely into something new?
It is a fair question, particularly in fertility. The data is often fragmented across different systems, some of it has been collected over decades, cryo data can live in free-text fields, and historical treatment cycles are not always structured or even easily accessible. We have spent a lot of time building technology to deal with that, and increasingly we can automate large parts of the migration itself.
But we talk much less about what happens after the data gets there. Because migrating a clinic and implementing a clinic are two very different things.
Implementation is really about change. You are asking an organisation, sometimes hundreds of people across clinical, nursing, embryology, finance, administration and operations, to change the system they use to do their job every day. Many of those workflows have developed over years. Some are documented, many are not, and there are always small details that only become obvious when someone actually starts doing the work.
This is why our implementation model looks quite different from a traditional software implementation, and why a large part of our company is made up of engineers.
More specifically, we work with a model called Forward Deployed Engineering, or FDE.
It is a concept that has become better known in parts of enterprise technology, but it is still not something you hear much about in fertility, so it is probably worth explaining what we mean by it.
A Forward Deployed Engineer is an engineer who works very close to the customer and the real environment where the software is being used. Instead of having one team gathering requirements, another translating them into product specifications and an engineering team somewhere further down the chain building against those specifications, you bring technical people much closer to the actual problem.
That matters a lot in fertility because the workflows are incredibly specialised. An embryologist should not have to explain why a particular relationship between an insemination event, fertilisation check, embryo grading, biopsy and cryopreservation matters to someone who doesn’t really understand the lab, and then hope that the important parts survive several layers of translation before reaching an engineer.
But the opposite isn’t much better. They also shouldn’t spend hours explaining their workflow to someone who understands exactly what they mean, but cannot actually change anything in the technology. We want the person sitting with them to be able to understand both.
This is why spending time in fertility clinics is part of how our engineers learn at wawa. It is difficult to build good fertility software if you have never watched a clinic operate. You need to see what happens when the first patients arrive in the morning, how nurses manage a cohort of patients at different points in their cycles, how embryologists plan the work in the lab, how the front desk handles doctors, rooms, scanners and patients at the same time, and how all of those workflows depend on each other.
It also changes how we think about configuration. Our goal is for roughly 80% of a clinic’s setup to be configurable directly on the platform. Treatment plans, workflows, forms, appointments, roles, templates and the other building blocks of how a clinic operates should not require custom development every time.
That gives us a strong standardised foundation, but we don’t expect the final 20% to magically disappear. That is where our engineers come in.
During implementation, and particularly in the weeks around training and go-live, our FDEs work closely with the clinic to understand where the standard configuration needs to be adjusted, where something is genuinely different, and where the technology needs to change.
The distinction is important. We are not trying to custom-build wawa for every clinic, and we are also not telling every clinic that they have to change everything they do to fit our software. We configure the majority through the platform, learn from the parts that don’t fit, and have engineers close enough to the organisation that we can make good decisions about what should be configured, what should change in the workflow and what should become part of the product.
I think this is particularly important during go-live because this is when you learn what the organisation actually does, rather than what everyone thought it did.
A workflow can make perfect sense in a discovery document and still fall apart at 8am on a Monday. A field that looks insignificant can turn out to determine what the lab does next. A reception process can have an exception nobody mentioned because it is so normal to the team that nobody thought of it as an exception.
Traditional implementations often put several layers between discovering those things and fixing them. The clinic tells an implementation person, who creates a ticket, which is interpreted by product, prioritised somewhere, handed to engineering and eventually comes back.
With an FDE model, we try to make that loop much shorter. It also means we end up with a slightly unusual type of engineer. Not many software engineers can have a detailed conversation with an embryologist about how Day 0 should be structured, understand why a particular treatment-cycle state matters to the nursing team, then sit with reception and work out why the resource model is creating problems with tomorrow’s schedule.
But that is exactly the knowledge we want our engineers to develop. The more predictable work we can automate, from migration to configuration, the more time our people can spend on the things that require judgement, context and a real understanding of how a clinic works.
We spend a lot of time talking about how to move a fertility clinic’s data from one system to another. That is important, and it is a difficult technical problem. But moving the data is not the same as moving the organisation.
For that, I think you need to bring the people who understand and can change the technology much closer to the people actually doing the work.
Previous:
Article
