/ How to start
Start without changing everything.
Start with one clinic. Your existing IT provider can continue operating everything else. We agree the scope, the responsibilities on each side and the support path before anything changes at a clinic.
/ How to start
Start without changing everything.
Adopt a defined scope while your existing IT team or provider continues supporting the rest. Two ways in, both operated to the same supported standard.
Adopt a defined scope
Bring selected clinic functions onto Surya's supported configurations, with security controls and staff support included from the start.
- Qualified module selection and an approved transition.
- The Surya security baseline applied as the module enters service.
- Defined support and escalation for the accepted scope.
- The agreed recovery method for covered devices.
Existing providers retain excluded systems. A device can only be separated where shared identity, network or management dependencies allow it.
Start here →Open or convert a clinic
Deploy the agreed clinic standard at a new location, or at a location ready for change.
- Site and dependency review.
- Supported modules, deployment and staff readiness.
- Security controls, support handoff and documented recovery.
- Existing providers can retain corporate systems and shared services.
Compatibility, implementation scope and availability are confirmed before a date is agreed.
Start here →These are entry scopes, not product tiers. Security controls, support and an agreed recovery method belong to every module from the moment it is accepted into service.
How a scope is qualified.
/ 01
Review the locations in scope
Clinic workflow, current technology and application dependencies.
/ 02
Compare against the supported standard
What qualifies for reuse, and what must be replaced, excluded or separately qualified.
/ 03
Confirm dependencies and responsibilities
Identity, network, access, licenses and the named owner for each retained system.
/ 04
Agree the scope and the transition
Modules, support path, recovery method and the sequence for the first location.
Qualification is a bounded step before deployment, not a consulting engagement or an audit opinion.
/ How responsibility expands
What Surya operates, and what your current provider keeps.
| Scope | Surya operates | Typically retained |
|---|---|---|
| Qualify a scope | Review the locations in scope, compare against the supported standard and confirm dependencies | Current support, configurations and remediation of retained systems |
| Introduce the standard | Qualify and deploy selected Surya modules with their security baseline | Legacy technology and shared services outside the agreed module boundary |
| Operate supported modules | L1/L2, configuration maintenance and agreed operational controls for accepted modules | Excluded systems and named upstream services |
| Extend recovery | Qualified local replacements, replenishment and wider agreed recovery options | Retained platform, carrier and application responsibilities |
| Replicate the clinic standard | Approved rollouts into additional locations and acquisitions | Remaining estate and any deliberately retained services |
These are separable scopes, not mandatory calendar phases. Additional replacement infrastructure can be introduced later where it adds value.
/ Working alongside your current IT
Start without changing everything.
Coexistence works when the boundary is explicit. Before work begins we map the shared dependencies, confirm the access and authority Surya needs, and name who owns each retained system.
One accountable operator per responsibility
A device may depend on several services. Each control or responsibility has a single named owner.
Shared dependencies are mapped first
Identity, network, EHR access, device management and security tools need an agreed operating boundary before anything changes.
Authority and access are confirmed
Surya must hold the access and authority required to deliver the commitments in its own scope.
Licenses are accounted for
Required licensing and entitlements are identified before deployment, not discovered afterwards.
Routing is agreed and tested
We keep an existing help-desk entrance where feasible, or provide a clearly scoped Surya contact path for clinic staff.
Change approval has a route
Changes touching a retained system follow the agreed approval path with the named owner.
Unsupported technology stays with its operator
Anything outside the agreed scope remains the responsibility of the team or provider that operates it today.
Required access, contract boundaries, licenses and provider coordination are assessed before Surya accepts scope. Surya cannot commit to security or uptime for retained systems it does not control.
/ When to expand
Expand at the natural change points.
Expand when the next change creates a reason to do so. Each agreed deployment follows the same supported standard.
- Equipment refreshes
- New hires where the dependencies fit
- New clinics
- Acquisitions
- Planned conversions
Failed-device replacement fits here only where the Surya configuration and its upstream dependencies are already qualified. An emergency is not a moment for an unplanned migration.
/ The sequence
From qualification to a proven standard.
- 01
Review the clinic
Workflow, current technology and application dependencies.
- 02
Select and scope
Choose supported modules and define the transition and responsibilities.
- 03
Validate at one location
Confirm the scoped setup, staff support path and recovery procedures.
- 04
Expand on the standard
Use the agreed standard as the basis for additional locations.
/ The operating line
Put the supported standard where the work happens.
Backup inventory sits at the Surya RTP distribution center. Surya maintains the supported configurations, deployment, staff support, replenishment, recovery and chain of custody within the agreed scope. You choose the scope and approve the transition. Surya defines and operates the supported technical standard.
Standardize One Clinic.
Bring your clinic list, your current support arrangement and the applications each location depends on.
Standardize One Clinic