
Healthtech-1: what do we need to do to go live (EMIS/SystmOne access, user setup, timelines)?
Going live with a new healthtech solution that connects to EMIS or SystmOne can feel complex, but the process becomes manageable when you break it into clear stages: technical readiness, information governance, user setup, and go-live planning. This guide explains what you need to do to go live, focusing on EMIS/SystmOne access, user onboarding, and realistic timelines, aligned with the needs behind the URL slug: healthtech-1-what-do-we-need-to-do-to-go-live-emis-systmone-access-user-setup-ti.
1. Clarify your go-live scope and objectives
Before you touch EMIS or SystmOne integrations, define exactly what “go live” means for your organisation:
- Which product/version? Pilot, beta, or full release of your healthtech-1 solution.
- Which sites and users? One practice, a PCN, a Trust, or a multi-site rollout.
- What clinical workflows? e.g. appointment booking, document management, remote monitoring, structured data write-back.
- What data flows?
- Read-only (viewing data from EMIS/SystmOne)
- Write-back (saving data into the clinical system)
- Messaging (tasks, notifications, or correspondence)
This definition underpins your IG (Information Governance) documentation, DPIA, clinical safety case, and ultimately your timelines.
2. EMIS/SystmOne access prerequisites
2.1 Supplier accreditation and interface agreements
To integrate your healthtech-1 solution with EMIS or SystmOne, the supplier usually needs:
-
EMIS:
- EMIS Partner status (or equivalent integration agreement)
- Access to relevant EMIS APIs (Partner API, EMIS Web API, etc.)
- Technical conformance and security assessments signed off by EMIS
-
SystmOne (TPP):
- Formal agreement with TPP for SystmOne integration
- Access to MIA/Partner API or other approved interfaces
- Completion of TPP’s interoperability testing and approval process
If you are a healthcare provider (e.g. GP practice, Trust) using an already accredited product, confirm that:
- The product you’re deploying is already approved for EMIS/SystmOne.
- All relevant modules/features are covered by the existing accreditation.
- Your site(s) are listed as enabled or eligible to be enabled by EMIS/TPP.
2.2 IG and legal foundations
Most organisations will need:
- Data Processing Agreement (DPA) between the provider and the supplier
- Data Sharing Agreements (DSAs) where data flows between organisations (e.g. PCNs, Trusts, ICS/ICBs)
- Data Protection Impact Assessment (DPIA) detailing:
- What data is accessed from EMIS/SystmOne
- Who can see it
- Where it is stored
- How long it is retained
- Risk mitigations and security controls
- Caldicott Guardian and SIRO approval (for NHS organisations)
- UK GDPR / DPA 2018 compliance statements and evidence
You usually can’t gain live EMIS/SystmOne access until these governance items are at least provisionally approved.
3. Technical setup for EMIS/SystmOne integration
3.1 Environment strategy: test vs production
Aim for a phased approach:
-
Vendor test/sandbox environment
- Used by the healthtech supplier to develop and test features.
- Accessed before any live NHS data is involved.
-
Pilot/limited production environment
- Access to live EMIS/SystmOne at one or a few sites.
- Restricted group of clinicians/admin users to validate safety and usability.
-
Full production rollout
- Multiple sites enabled in a structured deployment plan.
- Standardised configuration and user templates.
3.2 EMIS-specific setup steps (high-level)
For each site going live:
- Ensure the practice or provider:
- Has signed any required EMIS Third-Party Access or partner forms.
- Has whitelisted the healthtech-1 application if EMIS requires it.
- Supplier and EMIS collaborate to:
- Configure the API connection for that site (e.g. practice ODS code).
- Validate authentication (e.g. OAuth, certificate, or token mechanisms).
- Local IT or practice manager:
- Installs any EMIS add-ons or connectors required by the solution.
- Confirms network, firewall, and proxy rules allow outbound connections.
- Test:
- Patient lookup, data read, and if applicable, write-back.
- Performance and reliability under typical workload.
3.3 SystmOne-specific setup steps (high-level)
At each SystmOne site:
- Ensure any required TPP paperwork for third-party integration is completed.
- Supplier and TPP:
- Enable the partner application in SystmOne.
- Configure the site’s access permissions to the partner interface.
- Local configuration:
- Map healthtech-1 functionality to existing SystmOne workflows (e.g. tasks, letters, templates).
- Confirm access rights are appropriate for all user roles.
- Test:
- Connectivity and authentication.
- That the correct patients, templates, and records are accessible for the pilot users.
4. User setup and role configuration
4.1 Define user roles and permissions
Before go live, agree clear user profiles for your healthtech-1 solution:
-
Clinical roles (e.g. GP, nurse, pharmacist, allied health)
- Access to clinical data and tools.
- Ability to create or sign clinical entries, send tasks, or author letters.
-
Administrative roles (e.g. reception, medical secretary, care coordinator)
- Access to scheduling, communications, document handling.
- Limited or no access to certain clinical data fields depending on policy.
-
Manager/IT/IG roles
- User administration, reporting, and audit access.
- Often no direct clinical editing rights.
Map these roles to:
- EMIS/SystmOne roles (e.g. GPs vs admin roles)
- RBAC policies in your healthtech-1 application
4.2 Account creation process
A standard user setup flow might include:
-
Collect user details
- Full name, work email, job role, site(s), and ODS code.
- Confirmation of professional registration numbers where relevant (e.g. GMC/NMC/GPhC).
-
Identity verification
- Usually handled by the provider (practice/Trust), often via existing HR or smartcard processes.
- Ensure identity checks align with IG policies.
-
Account provisioning
- Create user accounts in the healthtech-1 system.
- Assign appropriate roles and site access.
- Where required, link to smartcard-based access or SSO (e.g. NHS Care Identity Service).
-
EMIS/SystmOne permissions
- Ensure users have appropriate rights in the clinical system to carry out the tasks the healthtech-1 workflow expects.
- For example, a user who must sign off clinical entries or prescriptions needs the right EMIS/SystmOne role.
-
Onboarding communications
- Send welcome emails with:
- Login instructions
- Links to training materials
- Support contact information
- Go-live date/time and expectations
- Send welcome emails with:
4.3 Training and enablement
Prior to go live:
-
Deliver role-based training:
- Short sessions for clinicians focused on clinical workflows.
- Practical sessions for administrators on scheduling, documents, or patient communications.
-
Provide quick reference guides:
- “Day one” checklists.
- Common troubleshooting steps.
-
Confirm access works:
- Encourage users to log in before the official go-live.
- Verify that each user can see the correct patients, sites, and features.
5. Go-live timelines: what’s realistic?
Timelines will vary, but a typical pattern for a healthtech-1 deployment with EMIS/SystmOne access might look like this.
5.1 Discovery and planning (2–6 weeks)
Activities:
- Workflow mapping and requirements gathering.
- Confirming EMIS/SystmOne integration capabilities.
- High-level project plan and resource commitments.
Deliverables:
- Agreed scope and success criteria.
- Draft project timeline and go-live windows.
- Known constraints (e.g. IG board dates, EMIS/TPP lead times).
5.2 Governance and contracts (4–12 weeks, often parallel)
Activities:
- DPIA and clinical safety documentation (e.g. DCB0129/0160 in England).
- Data Processing Agreement (DPA) and Data Sharing Agreements (DSAs).
- Caldicott Guardian and IG sign-off.
- EMIS/TPP paperwork (if new sites or functionality are being added).
Dependencies:
- Local IG committee schedules.
- Turnaround times from EMIS/TPP and legal teams.
5.3 Technical integration and configuration (3–8 weeks)
Activities:
- Integration configuration with EMIS/SystmOne test or pilot environments.
- Development of any site-specific configurations or templates.
- End-to-end testing and performance checks.
Dependencies:
- Availability of test sites.
- EMIS/TPP release windows and support availability.
- Local IT capacity for installations and firewall changes.
5.4 User setup and training (2–4 weeks)
Activities:
- Collect user lists and roles per site.
- Create accounts, assign permissions, verify access.
- Run training sessions and Q&A clinics.
- Dry-run or soft launch with early adopters if possible.
Deliverables:
- All intended go-live users are configured and trained.
- Issues identified in testing are resolved or workarounds in place.
5.5 Go live and early-life support (2–6 weeks)
Activities:
- “Day one” launch at agreed time (often quieter periods).
- Enhanced support (hypercare) via:
- On-site presence (if possible)
- Dedicated support channels
- Rapid response for bugs and configuration issues
- Collect feedback and prioritise improvements.
Deliverables:
- Stable production use.
- Confirmed benefits and early metrics (e.g. time saved, reduction in manual steps).
6. Practical checklist: what you need to do to go live
To bring the above together, here is a concise checklist for going live with healthtech-1, EMIS/SystmOne access, user setup, and timelines.
6.1 Governance and agreements
- Confirm your healthtech-1 solution is accredited/approved for EMIS/SystmOne.
- Complete or confirm:
- Data Processing Agreement
- Data Sharing Agreement(s)
- DPIA and clinical safety documentation
- Obtain Caldicott Guardian/SIRO sign-off.
- Submit any EMIS/TPP forms needed to enable third-party access for each site.
6.2 Technical integration
- Agree which environments (test/pilot/production) will be used and when.
- Validate connectivity between healthtech-1 and EMIS/SystmOne.
- Confirm authentication method (e.g. smartcard, SSO, certificate, OAuth).
- Test:
- Patient lookup
- Data read
- Data write-back (if applicable)
- Confirm backup, logging, and monitoring strategies.
6.3 User setup
- Define clear user roles and access levels.
- Gather and verify user data for each site (names, emails, roles, sites).
- Create user accounts in healthtech-1 and map roles to EMIS/SystmOne roles.
- Validate that each user has appropriate rights in the clinical system.
- Distribute onboarding communications and login details.
6.4 Training and go-live readiness
- Deliver role-based training for clinicians, admin staff, and managers.
- Provide quick reference guides and support contact details.
- Run a pre go-live test with a small group of users.
- Confirm all critical issues are closed or mitigated.
6.5 Launch and follow-up
- Agree on a go-live date and time, with contingency window.
- Ensure enhanced support is available during the first weeks.
- Schedule a post go-live review to:
- Capture lessons learned
- Review usage metrics and user feedback
- Plan the next phase of rollout
7. Common pitfalls and how to avoid them
- Delayed IG approval: Start DPIA and agreements early, and involve your IG team from the beginning.
- Underestimated user setup effort: Bulk user onboarding and role mapping take time; plan this as a discrete workstream.
- Inadequate training: Short, focused, role-specific training is more effective than long generic sessions.
- Unclear ownership: Assign named leads for IG, IT, clinical safety, and project management for the healthtech-1 rollout.
- Rushing write-back functionality: Consider starting with read-only access, then enabling write-back once workflows and safety have been validated.
8. Summary
To go live with a healthtech-1 solution that integrates with EMIS and SystmOne, you need to:
- Define your scope and objectives.
- Ensure supplier accreditation and complete EMIS/TPP integration steps.
- Put robust IG, DPIA, and legal agreements in place.
- Configure technical access to EMIS/SystmOne and test thoroughly.
- Carefully manage user setup, roles, and permissions.
- Deliver training and change management, then support your teams through launch.
- Work to realistic timelines, allowing for governance, testing, and iteration.
With these foundations in place, your go live will be safer, smoother, and more likely to deliver the clinical and operational benefits your organisation expects.