How to safely digitise your maternity unit during the COVID-19 pandemic

In these challenging times, many of us are having to adapt the ways in which we work. At K2, we will typically spend as much time as we can on-site at a hospital in order to implement our systems. But with the restrictions imposed as a result of COVID-19 this hasn’t always been possible. Demonstrating remarkable flexibility, K2 Australia has helped hospitals to successfully implement our end-to-end maternity system INFANT-Guardian during the pandemic without needing to physically visit the site.

Ben Fox and Peter Hunt of K2 Australia explain the benefits of a remote go-live, the now fine-tuned process, and what hospitals have to say about the set-up and go-live period.

Which K2 products have been rolled out remotely?

K2AU has successfully implemented INFANT-Guardian intrapartum systems remotely. With the assistance of BIOMEDS/IT infrastructure etc. this includes all hardware as well as software with no K2 presence onsite. We have also achieved a huge customer update completely remotely at one of the busiest birthing hospitals in Australia. This project was to update from a previous iteration of software and operating system. Part of this process was to ‘swap out’ the CF card ‘brains’ of the portals with new ones. We also set-up a one to one K2 – hospital staff buddy system for the go-live day. This was backed up by an SMS text group that communicated any progress/issues/delays etc. to everyone on-site and in the back at base K2 support team. The K2 team kept an MS Teams audio meeting running during the go-live as well so that we could share any updates/issues/discussions in real time.

During lockdown we have also completed several smaller clinical model updates to numerous customers around the country. K2AU is planning a full Athena system implementation scheduled for the first quarter of 2021. Given the geographical scale of West Australia, the vulnerability of remote aboriginal communities, and that K2 can only guarantee one member of staff (interstate restrictions due to COVID-19) plans are being made to support an almost complete remote go-live.

What are the benefits of a remote go-live?

Sometimes a project comes down to money. Just because there is money at this moment in time, if the project is delayed six months there is no guarantee it will still be there. By offering a remote go-live the hospitals that have an immediate need to implement a system can still do so.

By not having to schedule a specific time to be onsite, we as a vendor can realistically spend more man hours with the customer from our office.

What is the process involved in a remote go-live?

Lots of communication! Regular scheduled meetings throughout the life of the project are a must. Even if everything is seemingly in-hand a project control board overseeing the actions is always a good idea.

The life cycle of the project is similar to any other project. Firstly the scope of the project is decided and agreed upon by shareholders. Hardware can be ordered as soon as decisions are made as to how many portals are needed and whether wall mounting or cart mounting is necessary. Good to bring this forward compared to an onsite go-live to consider the availability of local resourcing for cart/portal/wall mount commissioning. With the scope of the project loosely defined it is down to the clinical leads to work with K2 in scoping out the change requests. Whilst this process is ongoing the backend infrastructure can be stood up. This allows us to have an environment by the time the first draft of the customer’s software is completed.

Whilst configuration of the clinical model is taking place any interfacing requirements are being actioned. This allows testing to begin once the non-production environment has been commissioned.

As with all projects the Q&A process is non-negotiable so nothing really changes there. We provide peer review and UAT feedback alongside the customer and feedback to the UK developers. These additional changes are then actioned before the validation and final release can be approved.

What are the challenges and how are they overcome?

We are used to doing lots of scoping work remotely, as a result this process is relatively fine-tuned. If anything, due to COVID-19 we have become even more efficient at using 3rd party software.

For a successful remote implementation the customer needs to fully engage and buy into the product as it is their support throughout the project that makes it a success or not.

Commissioning hardware (trolleys, portals etc.) is a challenge. Not only does the hardware take up lots of physical space but it is awkward to construct. We have found that video calling onsite technicians and walking them through one or two portals helps massively. Whilst the hardware all comes with instructions having a K2 presence even if through a camera really helps clarify things and decrease the chance of mistakes.

Post go-live support is a challenge. We are so used to having an onsite presence for up to two weeks during and after go-live. It is in our nature to enjoy being with customers so that we can hold their hands through the transition of a new system. By making ourselves always available and ensuring good response times to any issues no matter how small we are able to give the customers the support they need.

The best answer for this question and probably in general is good communication. It is a two-way street though. In order to provide the best service to the customer they need to communicate with us. If we are not aware of an issue then we can’t resolve it.

What support do hospitals get during the set-up/go-live period?

We have been lucky that our remote go-lives have been at hospitals where the project managers, clinical leads and IT contacts have all been magnificent. Without a positive and proactive attitude the job would be almost impossible.

By having a clear understanding of who is responsible for which tasks the processes become simple. For example, if I have an issue whereby my webserver isn’t communicating with the central stations, by knowing exactly who is responsible for the network infrastructure between the customer and K2 we can troubleshoot and resolve quickly.

By having an engaged customer that wants ‘your’ system in their hospital the resource afforded to the project makes all tasks possible remotely.

During the first week, we schedule at least one and more often two pre-go-live check meetings. We then schedule go-live status meetings with the customer each day and evening for at least the first week of go-live. On the fifth day, we review progress and confirm with the customer if they are happy to scale these status meetings back to once weekly as things settle down.

What feedback have you had from hospitals who have chosen to roll out a product in this manner?

Overwhelmingly positive! Project leaders/sponsors have been quick to sing our praises with how the implementations have gone. One of our customers went so far as to say the model we adopted was how they wanted future projects to go forward.

How do you educate hospitals during a remote go-live?

Working in liaison with clinical leaders of the projects and midwifery educations we work fluidly to best suit the individuality of the site we are working with. By having local environments configured to match the customers we are able to provide sessions via video conference. A schedule is agreed with the hospital and time slots made available almost around the clock to account for shift workers.

Additional sessions are made for system admins/coders/BIOMEDs etc. at the request of the customer. In addition, we have provided:

• A range of short (3-5 min) narrated videos on common tasks and system overviews. These have been published as part of the Perinatal Training Programme so that project coordinators, midwifery team leaders etc. can keep track of staff’s learning progress
• Swing tags for system overview and troubleshooting, attached to each bedside device
• Wall posters that give users an overview of common actions/system navigation