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 for planning your rollout
Use these six stages to agree the project plan. Timing, deliverables and services need confirmation; this sequence is not a promise that every service is included.
- Discover the working scope
- Map the facility’s services, people and external connections. Select the relevant plans and modules, and identify availability or dependency questions before agreeing the implementation scope.
- Configure the agreed model
- Review facility settings, service information and staff access within the selected products. Record decisions so the configuration can be checked against the organisation’s working model.
- Define data migration
- Agree which source records need to move, their quality and the acceptance checks. Migration tools, historical coverage and responsibility must be confirmed for the project.
- Plan role-based training
- Identify the tasks each team needs to practise and agree the training format and deliverables. Do not assume a particular training package is included without confirmation.
- Validate alongside current work
- Decide whether a parallel run is appropriate and define representative acceptance tests. Agree the people who will review clinical, financial and operational results before cutover.
- Agree go-live readiness
- Confirm outstanding issues, responsibilities and support arrangements before authorising go-live. Agree the transition plan rather than treating a configured account as 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 imply that every local requirement is already supported, so exceptions should be reviewed before they enter the implementation commitment.
The project plan needs to distinguish product capability from delivery services. A spreadsheet import described for Engage does not establish a complete historical migration service for every product. Likewise, branch entitlements do not replace staff training, data checks or the organisation’s own decision that a facility is ready to operate.
Use a representative workflow to review the proposed setup with the people who will run it. NextHealth’s healthcare operating and consulting background helps frame that discussion, while your team agrees acceptance and accountability. Confirm available modules, implementation services and support terms together so the project begins with an understandable scope.
Make support responsibilities part of the agreement
Support hours, channels, contacts and response commitments have not been specified in the brief. Use these points to define them before implementation.
- Support coverage
- Agree service hours, time zones and any out-of-hours arrangements for the deployment. No round-the-clock support commitment is made by this page or the implementation sequence.
- 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 supplier contacts responsible for decisions and escalation. Named contacts and delivery roles must be agreed; 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 the owner-confirmed uptime commitment.
Common questions
-
No fixed duration is established in the brief. 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.
-
Support hours and channels have not been confirmed in the supplied brief. Agree coverage and escalation arrangements explicitly rather than inferring continuous support from the uptime commitment.
Plan the first workflow with your team
Bring your current process and the people who run it. Agree the product scope, readiness checks and delivery services needed for implementation.