Replacing your practice management system: What actually matters

Q: Angela, you've been through a few of these now. What's the first thing you tell a practice facing a system change?

Angela: Honestly? Don't start with the software. I know that sounds backwards when everyone's itching to book demos and see what's out there, but the practices that struggle the most are the ones that jump straight to comparing products. You need to sit down first and document, in real detail, how your people actually work today. Things like how patients move through the practice, from community nursing teams right through to your specialist clinicians, data analysts, and finance. Write it all down properly before a single vendor conversation happens. Think of it a bit like buying a house. You wouldn't walk through open homes and let the agent tell you what you need. You'd work out your own requirements and then go looking for something that fits. This is a decision you'll likely be living for a long time, so you want to get it right.

Q: Some practices are facing some kind of end-of-life deadline on their current system right now. If it's a year or two out, then it can feel like there's plenty of time. Is it?

Angela: It can, but it really isn't a lot of time when you look at what needs to be done. I say that to every practice I talk to, whatever their actual date happens to be. Once you add up scoping your requirements, actually looking at options properly, making the decision, migrating the data, testing, training everyone, and then going live, that adds up to months, not weeks. And you want to make sure you build a buffer in there, because you're doing all of this on top of running a busy practice. My honest advice is to start now. Because the organisations that begin early get to make calm, well-considered decisions. The ones that leave it late end up rushed, under pressure, and that's exactly when things get missed.

Q: What's the biggest misconception when practices start looking at systems?

Angela: One big misconception is that a system built for someone else's workflow will somehow flex to fit theirs. Most practice management systems on the market were originally designed for a single GP running a single calendar, seeing patients one after another in an appointment book. That's a perfectly good model, if that's the kind of practice you're running. It's a poor fit if, for example, you're running a mix of inpatient and outpatient care, or you’re running a specialist practice where several clinicians need to work in parallel across the same day on shared diagnostic workflows. I've sat in more requirements sessions than I can count where it becomes obvious the team has been running half the practice on spreadsheets alongside the 'real' system, because the real system was never built for how they actually work. That's not a knock on any particular vendor, by the way. It's just what happens when a system's data model is based on a different kind of practice to the one using it. And don't assume a newer system automatically fixes it. If it's built on the same assumptions, you'll be right back in the same place.

Q: You mentioned spreadsheets running alongside the 'real' system. What do you mean by that, exactly?

Angela: When a core system can't do something basic that a team genuinely needs, staff don't just stop and complain - they will typically just build something else. That might be an Excel sheet or a home-grown database that somebody in the office maintains, or even a Word document that lives in Teams and gets printed out and filed back into the record later. These are often clever, well-intentioned fixes. But the problem is that these two systems typically drift apart. Then that can result in things like a patient accidentally getting missed on a workaround list. And because the core system was never showing a proper filtered view of who needs following up, nobody notices until later. To be clear, that’s not a people problem. The staff did exactly the right thing given what they were working with. So, if you find shadow spreadsheets propping up your PMS, treat that as one of your clearest, most concrete requirements for the next system. Don't file it away as 'just a necessary workaround'.

Q: On that point about people, how much of a system change is a people challenge versus a technical one?

Angela: More than people expect, honestly. In my experience, the single biggest predictor of whether a new system actually succeeds has less to do with the software and more to do with how early, and how genuinely, the whole team was brought into the decision. If leadership picks the system and hands it down just before go-live, it will never go well, no matter how good the product is. And the thing is, if people don't feel real ownership of the choice, the old workarounds tend to stick around. Those spreadsheets and side databases have a habit of reappearing around the new system just as fast as they grew up around the old one, unless the people who built them were genuinely part of choosing what replaces it.

Q: Is there anything that looks fine in a vendor demo but turns out to be a real headache once it's live?

Angela: Remote access, every time. I find that it rarely makes it onto a requirements checklist, but it matters enormously to anyone working outside your four walls. We've heard more or less the same complaint, in different words, from nurses at more than one organisation: getting into the system remotely from a patient's home, or a car in between visits, means working through terminal servers, a remote desktop gateway, and multi-factor authentication, just to open a record in the field. If you compare that with a browser-based system that opens with single sign-on and a bookmark, and the difference to someone's actual day is huge, even though both systems tick the same 'remote access' box on a vendor questionnaire. My advice is always to test it properly – in the real world. Ask to see it done on an ordinary laptop or phone, over an ordinary connection, the way your staff would actually use it. Don’t just see how it’s done through a curated demo environment.

Q: Every vendor conversation seems to mention AI now. What should practices actually be asking?

Angela: It's everywhere, isn't it? Usually it’s an AI scribe that listens to a consultation and drafts the clinical note. This is genuinely useful, and worth having. But where people can get tripped up is that the terms 'native AI' and 'AI add-on' get used almost interchangeably in sales conversations, and the difference matters more than the marketing lets on. People need to ask the same questions they’d ask about any clinical data handling, such as which model is actually doing the work, is it processing in the cloud or does the patient audio and text stay on premises, how long is that data retained and where, and what happens to it if you switch to a different tool down the track. A vendor with a genuinely native capability should be able to answer all of that clearly and specifically. If the answer is vague, or you realise a third-party tool is just being repackaged under the PMS's own branding, that's worth knowing before you agree to proceed and sign a contract.

Q: Is there anything about pricing that tends to catch people out?

Angela: Absolutely. Practices need to look at how a per-patient or per-enrolment pricing model behaves over time for their kind of practice, rather than the kind of practice it was designed around. That type of pricing makes sense for a general practice with a relatively stable, capitation-based enrolled list. But it behaves very differently for a specialist practice, where clinicians steadily accrue patients over years with very little natural drop-off. What initially looks like a modest monthly cost in a sales demo can escalate significantly once you model it honestly over five years of a growing caseload. So, the key is to ask the vendor to run that projection using your own numbers, not their standard example, and show you what it looks like at year three and year five, not just year one.

Q: Data migration sounds important but a bit scary. How do you de-risk it?

Angela: You have to treat it as its own workstream, rather than an afterthought once the new system's chosen. Work out who owns your backup and what format it's in. Get your IT provider involved early, and get specific, in writing, about exactly what the new vendor can and can't import. Then test it with real data before go-live, not on the day. I recall one evaluation where a vendor told the panel, quite openly, that demographics would import cleanly but a patient's full clinical history would arrive as a single attached PDF. It was an honest answer, and it didn’t go down well with the clinicians in the room, for good reason, because a PDF file that you can't search, filter or report on isn't really migrated data. It's an archive you now have to work around. If a vendor isn't prepared to export your history properly, in a structured, usable form, you need to find one who is, or bring in independent expertise to hold them to it during the contract, not after you've already switched the old system off.

Q: What about the integrations, things like ACC, patient messaging and accounting, and security?

Angela: Integrations are the thing nobody remembers is there until it breaks. The longer a system has been in place, the less likely anyone currently on staff can list everything it's connected to. It gets set up once, works reliably for years, fades into the background, and then someone tries to replace the system underneath it and discovers a dependency nobody remembered or documented. If your team can't confidently map every integration your current system relies on, that's not a gap you can close by simply asking people. You close it with independent technical help before you start scoping. And security's much the same, just higher stakes. Vendor answers on encryption, data residency, access controls and breach notification can often be quite dense with lots of acronyms, so it's easy to nod along without really understanding what you've agreed to. If it doesn't make complete sense, don't try to figure it out with a quick Google search. You need to bring in someone who actually works in security. The cost of getting it wrong can have serious consequences. It could lead to a genuine data breach and a difficult conversation with patients about why their records weren't as protected as they were told. I definitely think that's worth an hour or two of specialist time before a contract is signed.

Nicki Shirley

40 minutes ago

10 min read

An interview with CIO Studio COO, Angela Whittle

Replacing a Practice Management System (PMS) is one of the biggest operational changes a healthcare organisation will make, and one of the most avoidable sources of stress if it's planned well. A growing number of New Zealand practices are facing decisions about their current system, either as ageing platforms lose vendor support or need to be replaced to meet new requirements.

I sat down with CIO Studio's Chief Operating Officer, Angela Whittle, who has sat in on more requirements sessions, vendor demos and go-lives than she can easily count, to talk through what actually matters: the good, the messy, and the bits that often get missed.

Angela, you've been through a few of these now. What's the first thing you tell a practice facing a system change?

Angela: Honestly? Don't start with the software. I know that sounds backwards when everyone's itching to book demos and see what's out there, but the practices that struggle the most are the ones that jump straight to comparing products. You need to sit down first and document, in real detail, how your people actually work today. Things like how patients move through the practice, from community nursing teams right through to your specialist clinicians, data analysts, and finance. Write it all down properly before a single vendor conversation happens. Think of it a bit like buying a house. You wouldn't walk through open homes and let the agent tell you what you need. You'd work out your own requirements and then go looking for something that fits. This is a decision you'll likely be living for a long time, so you want to get it right.

Some practices are facing some kind of end-of-life deadline on their current system right now. If it's a year or two out, then it can feel like there's plenty of time. Is it?

Angela: It can, but it really isn't a lot of time when you look at what needs to be done. I say that to every practice I talk to, whatever their actual date happens to be. Once you add up scoping your requirements, actually looking at options properly, making the decision, migrating the data, testing, training everyone, and then going live, that adds up to months, not weeks. And you want to make sure you build a buffer in there, because you're doing all of this on top of running a busy practice. My honest advice is to start now. Because the organisations that begin early get to make calm, well-considered decisions. The ones that leave it late end up rushed, under pressure, and that's exactly when things get missed.

What's the biggest misconception when practices start looking at systems?

Angela: One big misconception is that a system built for someone else's workflow will somehow flex to fit theirs. Most practice management systems on the market were originally designed for a single GP running a single calendar, seeing patients one after another in an appointment book. That's a perfectly good model, if that's the kind of practice you're running. It's a poor fit if, for example, you're running a mix of inpatient and outpatient care, or you’re running a specialist practice where several clinicians need to work in parallel across the same day on shared diagnostic workflows.

I've sat in more requirements sessions than I can count where it becomes obvious the team has been running half the practice on spreadsheets alongside the 'real' system, because the real system was never built for how they actually work. That's not a knock on any particular vendor, by the way. It's just what happens when a system's data model is based on a different kind of practice to the one using it. And don't assume a newer system automatically fixes it. If it's built on the same assumptions, you'll be right back in the same place.

You mentioned spreadsheets running alongside the 'real' system. What do you mean by that, exactly?

Angela: When a core system can't do something basic that a team genuinely needs, staff don't just stop and complain - they will typically just build something else. That might be an Excel sheet or a home-grown database that somebody in the office maintains, or even a Word document that lives in Teams and gets printed out and filed back into the record later. These are often clever, well-intentioned fixes. But the problem is that these two systems typically drift apart. Then that can result in things like a patient accidentally getting missed on a workaround list.

And because the core system was never showing a proper filtered view of who needs following up, nobody notices until later. To be clear, that’s not a people problem. The staff did exactly the right thing given what they were working with. So, if you find shadow spreadsheets propping up your PMS, treat that as one of your clearest, most concrete requirements for the next system. Don't file it away as 'just a necessary workaround'.

On that point about people, how much of a system change is a people challenge versus a technical one?

Angela: More than people expect, honestly. In my experience, the single biggest predictor of whether a new system actually succeeds has less to do with the software and more to do with how early, and how genuinely, the whole team was brought into the decision. If leadership picks the system and hands it down just before go-live, it will never go well, no matter how good the product is. And the thing is, if people don't feel real ownership of the choice, the old workarounds tend to stick around. Those spreadsheets and side databases have a habit of reappearing around the new system just as fast as they grew up around the old one, unless the people who built them were genuinely part of choosing what replaces it.

Is there anything that looks fine in a vendor demo but turns out to be a real headache once it's live?

Angela: Remote access, every time. I find that it rarely makes it onto a requirements checklist, but it matters enormously to anyone working outside your four walls. We've heard more or less the same complaint, in different words, from nurses at more than one organisation: getting into the system remotely from a patient's home, or a car in between visits, means working through terminal servers, a remote desktop gateway, and multi-factor authentication, just to open a record in the field. If you compare that with a browser-based system that opens with single sign-on and a bookmark, and the difference to someone's actual day is huge, even though both systems tick the same 'remote access' box on a vendor questionnaire. My advice is always to test it properly – in the real world. Ask to see it done on an ordinary laptop or phone, over an ordinary connection, the way your staff would actually use it. Don’t just see how it’s done through a curated demo environment.

Every vendor conversation seems to mention AI now. What should practices actually be asking?

Angela: It's everywhere, isn't it? Usually it’s an AI scribe that listens to a consultation and drafts the clinical note. This is genuinely useful, and worth having. But where people can get tripped up is that the terms 'native AI' and 'AI add-on' get used almost interchangeably in sales conversations, and the difference matters more than the marketing lets on. People need to ask the same questions they’d ask about any clinical data handling, such as which model is actually doing the work, is it processing in the cloud or does the patient audio and text stay on premises, how long is that data retained and where, and what happens to it if you switch to a different tool down the track. A vendor with a genuinely native capability should be able to answer all of that clearly and specifically. If the answer is vague, or you realise a third-party tool is just being repackaged under the PMS's own branding, that's worth knowing before you agree to proceed and sign a contract.

Is there anything about pricing that tends to catch people out?

Angela: Absolutely. Practices need to look at how a per-patient or per-enrolment pricing model behaves over time for their kind of practice, rather than the kind of practice it was designed around. That type of pricing makes sense for a general practice with a relatively stable, capitation-based enrolled list. But it behaves very differently for a specialist practice, where clinicians steadily accrue patients over years with very little natural drop-off. What initially looks like a modest monthly cost in a sales demo can escalate significantly once you model it honestly over five years of a growing caseload. So, the key is to ask the vendor to run that projection using your own numbers, not their standard example, and show you what it looks like at year three and year five, not just year one.

Data migration sounds important but a bit scary. How do you de-risk it?

Angela: You have to treat it as its own workstream, rather than an afterthought once the new system's chosen. Work out who owns your backup and what format it's in. Get your IT provider involved early, and get specific, in writing, about exactly what the new vendor can and can't import. Then test it with real data before go-live, not on the day. I recall one evaluation where a vendor told the panel, quite openly, that demographics would import cleanly but a patient's full clinical history would arrive as a single attached PDF. It was an honest answer, and it didn’t go down well with the clinicians in the room, for good reason, because a PDF file that you can't search, filter or report on isn't really migrated data. It's an archive you now have to work around. If a vendor isn't prepared to export your history properly, in a structured, usable form, you need to find one who is, or bring in independent expertise to hold them to it during the contract, not after you've already switched the old system off.

What about the integrations, things like ACC, patient messaging and accounting, and security?

Angela: Integrations are the thing nobody remembers is there until it breaks. The longer a system has been in place, the less likely anyone currently on staff can list everything it's connected to. It gets set up once, works reliably for years, fades into the background, and then someone tries to replace the system underneath it and discovers a dependency nobody remembered or documented. If your team can't confidently map every integration your current system relies on, that's not a gap you can close by simply asking people. You close it with independent technical help before you start scoping.

And security's much the same, just higher stakes. Vendor answers on encryption, data residency, access controls and breach notification can often be quite dense with lots of acronyms, so it's easy to nod along without really understanding what you've agreed to. If it doesn't make complete sense, don't try to figure it out with a quick Google search. You need to bring in someone who actually works in security. The cost of getting it wrong can have serious consequences. It could lead to a genuine data breach and a difficult conversation with patients about why their records weren't as protected as they were told. I definitely think that's worth an hour or two of specialist time before a contract is signed.

There are several systems on the market. How should a practice choose without getting overwhelmed?

Angela: It’s really important to score them against your own requirements, not their feature lists. A demo will almost always look impressive, but the real question is whether it does the specific things your specialty needs, day in and day out. Talk to practices like yours who actually use it. And a formal RFP process is itself a useful test, not just of the software but of the company you'd be signing a multi-year contract with. Some vendors handle RFPs comfortably, because they've done it before. Others visibly aren't comfortable, because their usual way of winning business is through word of mouth rather than a structured written response, and that tells you something. I remember one process that covered a core patient management system and a separate, more specialised reporting component. Most vendors answered every question anyway, even the parts that clearly weren't their product, and their scores suffered for it. The one vendor confident enough to say 'that's not us, don't score us on it' told us far more about how honestly they'd scope work later, during implementation, than any demo could.

How do people avoid being mislead once they're down to a shortlist and the sales process really kicks in?

Angela: Be honestly sceptical of self-reported vendor scorecards. In our evaluation work, they tend to drift in the same few directions. First, a genuine gap gets marked as 'met with standard configuration'. Second, something that flatly isn't supported gets a token score instead of a zero. And lastly, an integration that's really just a future possibility gets scored as though it already exists. And it’s typically not that the vendor is being deliberately dishonest. It's just what happens when the person filling in the form is motivated to win the deal.

I will trust a vendor more if they do the opposite: tell you plainly if something is on the roadmap and give you a genuine estimate - six months or twelve - rather than let it score as already built. So, the key is to verify anything that materially affects your decision. Ask for a live demonstration of that specific item, and when you check references, ask for a site that matches your own scale and complexity, not the vendor's happiest customer. If you can, go and see the system running for real, on an ordinary day. A short in-person visit tends to surface far more than a scripted reference call ever does.

What's different about going through this in a specialist practice, specifically, and does it change much if you're running more than one site?

Angela: Specialists often have very particular workflows and a lot of customisation built up over years. That's often exactly why their current system has suited them so well for so long. So the bar for a replacement is higher, and the migration is more involved. It makes early planning even more important. And if you're running clinics across more than one location, there's a whole extra dimension: does the system behave the same way at every site, and does it keep working as you add new ones? A system that performs well for one busy clinic can start to strain once several sites are booking into shared diaries, referring patients between locations, and needing one reliable group-level view instead of several separate ones. You should ask a vendor to walk you through adding a new site, not just show you the ones you already have. Whether it scales gracefully isn't really a yes-or-no question. It comes down to what starts to break first.

If a practice does just one thing after reading this, what should it be?

Angela: Start. Put a date in the calendar this month to map your requirements and your integrations, and decide whether you're doing this yourselves or bringing in help. Momentum is everything. Once you've actually started, it stops being this cloud on the horizon and becomes a plan.

How does CIO Studio help with this?

Angela: We're independent. We don't sell a practice management system, so our job is purely to help practices choose and implement the right one. We map the requirements, shortlist and evaluate the options properly, and build a realistic roadmap. And we can manage the migration, integrations, training and go-live so a practice can keep running throughout the whole process. Whether someone wants a second opinion or a partner for the whole journey, that's what we do.

If your practice is facing an end-of-life deadline on your current system, or you're simply weighing up a change, you can find out more about how CIO Studio helps on our PMS replacement page or we'd be glad to talk it through. Book a free, no-obligation PMS replacement consult with the CIO Studio team.