Plan the rollout around your facility’s actual work
Start with the workflows your teams need to run. Agree product scope, configuration and readiness checks before go-live, with migration, training and support arrangements made explicit in the implementation plan.
Configure a shared platform around your services
NextHealth uses one codebase. Begin with the products, settings and entitlements that fit your facility, then evaluate any requirement beyond that scope rather than assuming every difference needs a separate software build.
A proposed sequence, and who does what
Use these six stages to agree the project plan. Timing, deliverables and services are confirmed in your implementation scope. This sequence is not a promise that every service is included.
- Discover the working scope
- NextHealth maps the facility’s services, people and external connections with you, selects the relevant plans and modules, and raises availability and dependency questions. Your team names the services, sites and decision makers.
- Configure the agreed model
- NextHealth sets up facility settings, service information and staff access within the selected products and records the decisions. Your team reviews the configuration against how the facility works and approves it.
- Assess data migration
- NextHealth assesses which source records can move and what the products support. Your team supplies the records, checks their quality and accepts the result. Migration tools and historical coverage are confirmed for each project.
- Plan role-based training
- NextHealth agrees the training format and deliverables with you. Your team names the people in each role and the tasks they must practise. A training package is not assumed until it appears in the scope.
- Validate alongside current work
- NextHealth supports representative acceptance tests and a parallel run where you choose one. Your team runs the tests and reviews clinical, financial and operational results before cutover.
- Sign off go-live readiness
- Both teams confirm outstanding issues, responsibilities and support arrangements. Your accountable people authorise go-live. A configured account is not a completed operational rollout.
One codebase, with scope agreed facility by facility
A shared codebase supports a configuration-led approach as facilities and branches adopt the platform. Care plans, Engage add-ons and Flow module selections define the working scope. Configuration does not mean every local requirement is already supported, so exceptions are reviewed before they enter the implementation commitment.
The project plan distinguishes product capability from delivery services. A spreadsheet import described for Engage does not establish a complete historical migration service for every product. Branch entitlements do not replace staff training, data checks or your organisation’s own decision that a facility is ready to operate.
Review the proposed setup with the people who will run it, using a representative workflow. NextHealth’s healthcare operating and consulting background helps frame that discussion. Your team agrees acceptance and holds accountability for it.
Agree support before go-live
Agree support hours, channels, contacts, escalation routes and response commitments in the implementation scope before go-live. This page publishes no service level.
- Support coverage
- Agree service hours, time zones and any out-of-hours arrangements for the deployment. Neither this page nor the implementation sequence makes a round-the-clock support commitment.
- Contact routes
- Confirm the channels the team will use to raise an issue and share updates. Do not assume telephone, chat or a named ticketing service is included.
- Named responsibilities
- Identify the facility and NextHealth contacts responsible for decisions and escalation. Named contacts and delivery roles are agreed in the scope. A dedicated account manager is not assumed.
- Issue priorities
- Agree how severity, response and resolution expectations are defined. These support terms are separate from product availability and from the uptime commitment on the hosting page.
Common questions
-
There is no fixed duration. Scope, data, interfaces and readiness affect the plan; agree the schedule and acceptance criteria after reviewing the actual facility requirements.
-
Full historical migration is not confirmed. Agree the datasets, source quality, tools, attachments and acceptance checks for your project rather than assuming every legacy record can be transferred.
-
The approach is configuration-led, using the selected products and entitlements. Review the available settings and any gaps before assuming either a custom build or an unsupported configuration is included.
-
Training scope and deliverables need confirmation in the implementation agreement. The proposed rollout sequence identifies training as a planning stage, not an automatic commercial inclusion.
-
Agree support hours, escalation routes and response commitments in the implementation scope before go-live, rather than inferring continuous support from the uptime commitment.
Not answered here? Contact the team
NXH Flow